Keith Swenson recentemente compilou a lista 26 dicas para um desenvolvimento ágil bem sucedido. Keith sugeriu que frequentemente coleta porções de sabedoria em vários temas e a lista é um conjunto destilado de sugestões que realmente importam para o desenvolvimento ágil de software.
Um comentário sobre seu post sugeriu que muito destas dicas podem não ser especificamente ágeis e seria verdadeiro para um melhor desenvolvimento e design de software. Keith respondeu que, para praticantes experientes em agilidade, muitas destas sugestões podem parecer rotina, mas há um público maior lá fora, que é agnóstico a estas práticas. Ele acrescentou,
"Eu estou trabalhando com algumas equipes, no Japão, que usam um modelo de desenvolvimento em cascata muito rigoroso. Para estes times, metade destas sugestões são "surpreendentes" e, possivelmente, conselhos radicais. Coisas como "escrever os testes antes de codificar" e "implementar somente o necessário" são conceitos radicais para eles. Eles se orgulham da "completude" de implementação, ao ponto de inventar casos de uso que não são orientados ao cliente. O resultado é um excesso de código, outro tipo de lixo. Eles esperam, as vezes, 6 meses para implementar os testes. Para quem se baseia em cascata, o teste é uma "muleta" que não é necessária para os desenvolvedores executarem suas tarefas. Surpreendente?"
Algumas das 'não tão comuns', dicas interessantes sugeridas por Keith eram,
- Tenha o caso 1 completamente funcional antes de iniciar o caso 2. Um dos maiores problemas do desenvolvimento de software é começar coisas em paralelo, que inevitavelmente conduziria a algum trabalho que precisa ser descartado e, portanto, desperdiçado. A metáfora da cozinha é: "Servir a refeição atual antes de começar a cozinha a próxima".
- Não tenha medo em tomar uma decisão; não tenha medo em mudar uma decisão inicial. Atrase a decisão o máximo possível e faça quando necessário. Assim que uma nova informação chegar, não tenha receio em mudar uma decisão inicial.
- Avaliar, avaliar, avaliar. Desenvolvimento ágil é ajudar a resolver o problema da incerteza sobre o futuro, mas não deve haver nenhuma incerteza sobre o passado.
- Projeto em torno de pessoas, não sistemas. Frequentemente, desenvolvedores são desviados em projetar para oportunidades técnicas. O sucesso de um software depende em levar as pessoas envolvidas em colaborar efetivamente e acrescentar valor ao negócio.
- Otimização prematura é a raiz de todo o mal. Intuição sobre o que é importante para a performance global é quase sempre equivocada quando baseada somente em um entendimento estático do código. Em vez disso, medir o comportamento do sistema completo e então identificar os problemas de desempenho.
- Nunca sobregeneralize funcionalidade. Também conhecido pela sigla "YAGNI - You Aren't Going to Need It"(Você não vai precisar disso).
- Nunca jamais faça medição de código por contagem de linhas. O número de linhas necessárias para fazer uma tarefa em particular varia imensamente de programador para programador, e de estilo para estilo. Faça a contagem dos casos de uso funcionais.
- Software é plástico. Diferente de manufaturas físicas, software pode ser mudado de várias maneiras, facilmente.
- Não invente novas linguagens. O advento do XML está levando a uma cadeia sem fim de "Linguagem de scripts" especializadas, que estão, supostamente, tornando o desenvolvimento de software genérico. A falha neste raciocínio é que a definição precisa do comportamento das operações quase nunca é bem definido fora de um contexto de uma implementação em particular.
Leia mais na "lista completa de dicas" e deixe uma nota se você achar que uma importante está faltando.