A Maldita Comédia: Atendendo a um mercado ágil

Saudações!
Na última edição da revista Época Negócios, observei uma frase bastante interessante atribuída a Kevin Kelly, fundador da revista Wired:

"Não estamos mais numa época de mudanças, mas numa mudança de épocas"

Evoluímos mais do que os modelos de desenvolvimento pudessem suportar. Atualmente necessidades de mercado fazem com que produtos novos sejam lançados a cada seis meses (Apple, Panasonic, Sony, Google, Peugeot, etc já seguem esse padrão), ou até menos. E como nós, no desenvolvimento de software, reagimos a isso? Como nos tornamos eficientes o suficiente para que, a cada ciclo curto de mudanças de mercado, possamos responder com alto valor de negócio a requisitos de sistema?
Desenvolvimento Ágil é a única solução? Resposta clara: não! Mas pode ser uma ótima saída ao engessamento que nossas empresas vem passando. Europa e EUA já fazem isso há algum tempo, quando cairemos na real?

Visando a melhoria contínua de processos, e tendo em mente que algumas práticas de Desenvolvimento Ágil são realmente importantes, algumas sugestões de melhorias. Vejam as práticas:

1) institucionalizar reuniões de feedback, sejam elas em término de uma iteração ou no término de um projeto.

2) melhorar stand-up meetings!
- feitas ao lado do quadro
- ampliar complexidade do quadro informativo
- foco na resolução do problema

3) Pair Programming com maior frequencia...

4) revisão de código (como alternativa e complemento ao uso do TDD/Pair programming)
- sessões rápidas (pouca quantidade de código)
- validação de padrões de código
- possíveis melhorias em algoritmos
- visando ampliar comunicação sobre design/arquitetura

5) iniciar testes automatizados... nem que sejam simplificados
- incentivar a utilizacao de ferramentas de teste
- buscar informações sobre o tema
- implantar TDD

6) formar a cultura em volta da qualidade de software("what does 'done' mean?")
- definicao clara do que é uma funcionalidade terminada, e que possa ser realmente questionada
- deixar os próprios funcionários gerarem conteúdo de valor para a organização
- documentos e mais documentos para leitura e formação
- wikis
- foruns
- listas de discussão

7) Tentar aplicar os principios de desenvolvimento(necessário cobrança/inspeção)
- principio DRY (dont repeat yourself)
- principio KISS (keep it sweet and simple)
- principio "Don´t live with Broken window"/"Stop the line"
- principio YAGNI (you ain´t gonna need it!)

Vou explicar a relação entre as práticas, mostrando como elas se encaixam para tornarem-se uma opção concreta de melhoria para a empresa.

É excepcionalmente importante colocar o feedback no topo da lista de práticas a serem adotadas. A informação gerada durante uma reunião de término de iteração pode ser definida como:

O que de "bom" fizemos nesta Iteração? (se tivéssemos que repetir a iteração, seria mantido igual)

O que poderia ter sido feito diferente? (se tivéssemos que repetir a iteração, esses itens deveriam ser feitos de outra forma)

Em que podemos melhorar? (Idéias concretas sobre como melhorar para o futuro)

Assim, pode-se identificar necessidades e ataca-las com maior conhecimento na próxima iteração. Mais do que isso, é a forma de cultivar a motivação da equipe dentro do projeto, já que suas sugestões de melhoria são realmente ouvidas e podem ser efetivamente aceitas. Até mesmo reuniões de término de projeto, podem dar luz a problemas que possam ter ocorrido durante seu trajeto. Soluções e acordos encontrados nessas reuniões podem servir de base para a melhoria contínua que os métodos Ágeis se propõe.
Este item está intrinsecamente ligado à idéia de formar uma cultura sobre qualidade de software, pois a equipe estará focada em verificar formas de melhorar o próprio trabalho, e aliar essa motivação à Informação é o caminho mais rápido para o desenvolvimento do grupo. Um canal que possa disponibilizar conteúdo relevante sobre práticas de desenvolvimento e qualidade de software pode servir de referência para que todos participem da mudança que a empresa se propõe. É necessário envolvimento real das pessoas para que a cultura se instale na empresa. Como conseguir isso? Responsabilidade! Todos devem tornarem-se responsáveis pela manutenção do modelo de desenvolvimento de software com qualidade. Essa cultura surge à partir da relação que todos tem com o trabalho. Um profissional saberá sempre como tornar seu trabalho mais produtivo. Se existe uma formam dele conhecer mais sobre como melhorar a própria produtividade, ele o fará. E ainda, se lhe for dada a oportunidade de decidir sobre como tornar seu trabalho mais produtivo, ele assumirá o risco.
Assim, também a melhoria do processo de Reuniões Diárias tenta fomentar a melhor circulação de informações entre a equipe. Deve-se criar um Ambiente informativo, onde o número de dados é o mais relevante e o necessário para a tomada de decisão. O aproveitamento da prática pode ser muito ampliado se ela possuir a intenção de alinhar todos da equipe e remover entraves ao desenvolvimento, além de ser o real status do projeto.

Ligado à melhoria do código produzido (entre outros benefícios), as demais práticas estão fortemente ligadas.
Pair programming e ciclos revisão de código são grandes aliados, complementando um ao outro. Essas práticas vão ajudar a divulgar padrões de codificação, formatação, convensões de código e auxiliam na definição de Modelos de Objetos e Arquitetura de software que o projeto pode assumir. São práticas muito ricas para o terminamento de novos desenvolvedores e para criar o que chamamos de Código Coletivo no projeto, pois qualquer um dos desenvolvedores poderá manter o código do sistema, já tudo está padronizado e que, muito provavelmente, algumas pessoas já tenham trabalhado com o código.
Pair programming é a prática mais complexa de se justificar para gerentes, e existe uma forma de tornar a transição menos dramática para todos: inicie ciclos de revisão de código em dupla. Pouco código por vez, apenas o mais crítico à aplicação. Com o tempo, torne uma rotina a resolução de problemas complexos do sistema utilizando uma dupla. O resultado é bastante motivador, e poderá ser assumido pelos desenvolvedores e gerência de maneira mais orgânica.

Simplicidade é a alma do negócio.
Testes de software, inicialmente com poucas pessoas, apenas para validar a utilização da prática no ambiente de produção, já são um motivo para que a codificação fique simplificada. Aliado à programação em dupla/revisão, é o que eu chamo de "Combo da Qualidade Ágil"...
Princípios de desenvolvimento (KISS, DRY, YAGNI,etc) não precisam ser obrigatórios, pois eles naturalmente ganharão notoriedade à medida que as outras práticas estiverem sendo implantadas: utilizar testes obriga a pensar de maneira desacoplada, tentando criar a maior independência possível entre funcionalidades, facilitando a reutilização de código. Por outro lado, como as implementações tem que ser simples e de fácil compreensão, a revisão de código possibilita que sejam feitos refactorings de código apoiados em testes para garantir que tudo continua fucionando após a mudança. Programar em dupla auxilia no que é chamado "pressão da dupla", em que o código produzido pela dupla tende a ser melhor, já que sempre existe uma pessoa ao lado para inspecionar informalmente o código produzido.

Mais uma vez: não estamos aqui brincando de fazer software! Apoiamos um modelo de desenvolvimento bem formulado e com base suficiente para suprir a necessidade do mercado: inovação, respostas rápidas às necessidades do mercado e crescimento sustentável do software.

Referências: