Estou ministrando um treinamento hands-on sobre desenvolvimento ágil com uma abordagem nova para o nosso time interno de desenvolvimento. Uma das premissas deste treinamento é desconstruir o discurso ágil retórico e frágil que ilude e confunde os desenvolvedores e posiciona-los no ambiente real do dia-a-dia dos projetos onde atuam.

Esse treinamento é baseado no framework de processo Disciplined Agile Delivery. A nova abordagem consiste em simular um ambiente corporativo típico onde existe um ciclo de vida de projeto que entrega uma solução. Este ciclo de vida envolve atividades além da codificação do software apenas. O ponto de partida do treinamento é um contexto de uma necessidade de negócio e cada time tem de se auto-organizar ao longo de todo o ciclo de vida para entregar uma solução suficiente para atender a necessidade solicitada.

Abaixo a tradução da síntese de Scott Ambler sobre a retórica e realidade ágil. Para os praticantes do Scrum é uma provocação referenciando o “Scrum BUT”. :)  O formato é: X MAS Y, onde X é a retórica e Y a estratégia proposta pela entrega ágil disciplinada.

  1. Requisitos evoluem ao longo do ciclo de vida MAS o escopo inicial ainda deve ser aprovado no início do projeto;
  2. Design Simples é melhor MAS a arquitetura deve ser pensada no início do ciclo de vida do projeto;
  3. Os times devem ser auto-organizados MAS eles ainda são restringidos (e melhorados) pelo seu ecossistema organizacional;
  4. Equipes de entrega não precisam de definições de processos prescritivos MAS eles precisam de alguma orientação de alto nível para ajudar a organizar seu trabalho;
  5. Os profissionais de TI sabem o que fazer MAS eles provavelmente não são especialistas em processos;
  6. Os profissionais de TI devem validar o seu próprio trabalho com o melhor de sua capacidade MAS eles provavelmente não são especialistas em testes, portanto precisam de ajuda para escolher as habilidades adequadas;
  7. Times ágeis disciplinados trabalham de forma iterativa MAS ainda seguem um ciclo de vida que é serial ao longo do tempo.

Considerando que os agilistas disciplinados sempre devem pensar antes de agir, os itens pontuados acima são importantes para que o time entenda bem o ciclo de vida de um projeto com objetivo de acomodar as metas, atividades e decisões importantes de cada iteração de acordo com cada fase do projeto. Esse entendimento vai ajudar o time a gerenciar o débito técnico ao longo do desenvolvimento e obter o máximo de produtividade fazendo apenas o suficiente para entregar uma solução adequada.

 

Exibições: 433

Comentar

Você precisa ser um membro de PanGea para adicionar comentários!

Entrar em PanGea

Comentário de Marcio Braga em 27 julho 2012 às 17:53

Muito legal. O ponto chave é esse mesmo: Disciplina. A indo um pouco alem, entendo que um modelo agil se propoe a resolver um dos problemas especificos do gerenciamento atual: Como combinar execucao disciplinada com criatividade e inovacao.

Poderiamos extender execucao disciplinada sobre diversas outras variaveis como tempo, risco, custo, etc. Mas um ponto chave é como abrir espacao para criatividade e inovacao na solucao para o cliente quando se esta trabalhando em um ambiente altamente disciplinado ?

Nao existe espaco para entregar criatividade e inovacao para o cliente, trabalhando em um ambiente do tipo Comando-Controle.

Comentário de Gilberto Silveira Junior em 27 julho 2012 às 16:16

Parabéns pelo post Adriano. 

Como mencionado nos comentários abaixo, podemos ver o modelo ágil sendo empregado por muitos times atualmente de modo incorreto, pelo simples fato de não entender a fundo o que vem ser um modelo ágil. E como você mesmo falou a comunidade vem se movendo para corrigir isso de forma a evitar uma bolha do movimento. Fazendo com que as pessoas venham a refletir mais sobre qual o real funcionamento de metodologias ágeis.

Comentário de Adriano Tavares em 27 julho 2012 às 15:18

Bruno, o item 5 é sobre processo de desenvolvimento de software. O argumento é que a estratégia a uma década atrás era definir um processo totalmente detalhado. Com o movimento ágil a coisa foi para o outro lado extremo, ou seja, nenhum detalhamento do processo. Agora a tendência na comunidade ágil é assessorar os times para que seja definido um processo personalizado enxuto. O DAD funciona com uma estrutura de processo leve e flexível, para ser usada como base, mostrando como tudo se encaixa do início ao fim de um projeto.

Comentário de Bruno Leite em 25 julho 2012 às 10:44

Parabéns pelo post Adriano, ficou muito bom.

O item 5 se refere a processos de negócio ou processos para desenvolvimento de software? Concordo com este item, considerando processos de negócio.

Dando prosseguimento a discussão...

Excelente observação Gustavo, também já vi isso acontecer e ainda levantarem a mandeira do Agile em prol da anarquia aos processos de desenvolvimento de software.

O ponto colocado pelo Denis é muito pertinente, já discuti algumas vezes com o próprio Adriano e outros amigos. Ao meu ver, não é em qualquer cenário que conseguimos aplicar métodos ágeis. Por exemplo, fábricas de software precisam tornar a construção de software, um processo de criação, em um processo mecânico, de forma que o trabalhador não precise pensar para executar tal trabalho, afinal, é fábrica... Uma tática comum para o cenário descrito é a utilização de um desenvolver pleno ou sênior para comandar uma equipe de desenvolvedores iniciantes (estagiários em muitos casos), com um prazo totalmente surreal imposto pela empresa, tornando inviável a prática de metologias ágeis. Ousaria dizer até que em alguns cenários, nem práticas básicas de engenharia de software (descritas no RUP, Práxis e outros) são seguidos nesses casos.

É importante ressaltar aqui também que fábricas de software não são símbolos de desorganização. Hoje até podemos encontrar fábricas de software certificadas pelo SEI com o selo do CMMI5.

Vejo que precisamos de um time maduro para conseguir aplicar não só metologias ágeis, como práticas de engenharia de software apoiadas no Scrum, XP, RUP, Práxis, LEAN e outros mais.

Comentário de Denis Pinheiro em 24 julho 2012 às 23:21

Olá Luiz, concordo com sua colocação.

Quis enfatizar que "métodos tradicionais" (RUP-like) não exigem times tão experientes e disciplinados, pois esses processos definem o passo a passo a ser seguido, ou seja, o processo organiza a forma de trabalho. Por outro lado, "métodos ágeis" exigem times mais disciplinados com competências de auto-organização, não que os tradicionais não exijam também, porém esse é um dos fatores impacta no sucesso da adoção de "métodos ágeis". Considero que esta seja uma das premissas do do manifesto ágil: "Individuals and interactions over processes and tools" (http://agilemanifesto.org/).

Acho que as retóricas 4, 5 e 7 estão relacionadas direta ou indiretamente com esse fator. O que acham?

Comentário de Gustavo Nunes Ferreira em 23 julho 2012 às 23:48

Excelente post Adriano. Tenho visto muito gente por ai colando uns post-its na parede e dizendo que estão usando SCRUM ou Lean, ser ágil exige muita disciplina e acima de tudo muita maturidade!

Comentário de Denis Pinheiro em 23 julho 2012 às 19:20

Muito bom Adriano, esse post só corrobora que a adoção de métodos ágeis deve ser feita por times altamente disciplinados e organizados !!! 

Comentário de Leonardo Cruz em 23 julho 2012 às 18:16

Ótimo post Adriano, o desenvolvimento ágil não deve ser uma desculpa esfarrapada para o desenvolvimento indisciplinado.

Evento TDC2016

Badge

Carregando...

© 2017   Criado por Adriano Tavares.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço