10 coisas para afundar um projeto

setSarcasticModeOn();

1. Pegue um projeto com um cliente que não sabe o que quer e feche um prazo de entrega, até mesmo se vc não tiver noção do tamanho do buraco. Se conseguir um projeto complicado é melhor. Se conseguir um projeto complicado e que não seja a atividade fim da empresa, melhor ainda!

2. Monte uma arquitetura ‘perigosa’ – onde requisitos não funcionais vitais, como segurança, por exemplo, devem ser aplicados pelos desenvolvedores, e não pela arquitetura – e que dificulte ao máximo o desenvolvimento. Quanto mais enrolado, melhor.

3. Monte uma equipe, desfaça a equipe, monte outra, treine, desfaça novamente, realoque pessoas, transfira recursos para outro projeto, mesmo que o projeto já tenha começado ou melhor, faça isso no fim do projeto.

4. Na semana da entrega, arrume alguma coisa que impossibilite a equipe de trabalhar… uma boa idéia é a mudança de site da empresa! Não esqueça de proibir os desenvolvedores que levem códigos para as residências e não – em hipótese alguma – disponibilize a estrutura de versionamento para acessos remotos.

5. Fique longe do conhecedor do negocio – vulgo cliente, se possível em estados diferentes. Mas o principal: não tenha contato algum com o cliente. Faça uma barreira entre o time de desenvolvimento e os reais donos do negócio. Por exemplo, quando um desenvolvedor te pergunta “Como é essa regra aqui mesmo?”, responda, “Calma que eu vou mandar um email para o ‘cara’ e daqui a dois dias eu te respondo”.

6. Mude o banco de dados, no dia da entrega, se possível! Acrescente tabelas, campos. Altere relacionamentos.

7. Não faça testes! Nem documentação, javadocs ou coisas do tipo! Isso é coisa para fracos!

8. Tenha os requisitos na mente, e não em papel. User stories é história pra boi dormir. E se possivel, passe essa funcionalidade para uma pessoa que não conhece nada do negócio. Mas não esqueça: conhecimento é como senha: pessoal e intransferível.

9. Como o cliente não está por perto, vá falando para o desenvolvedor as particularidades da funcionalidade sobre demanda. Siga, sempre que possível, o script abaixo:
Desenvolvedor: “Acabei a funcionalidade X”
‘Líder’: “Beleza! Mas vc fez a funcionalidade XPTO?”
Desenvolvedor: “O quê?!? (com cara de WTF?!)”
Líder: “É, existe a regra XPTO que faz isso, isso e isso”
Desenvolvedor: “Mas isso estava descrito aonde?”
Líder: “Lugar nenhum… vc não me perguntou tambem, né!”
Desenvolvedor: “Mas eu terei que mudar muita coisa agora. Vou começar logo com isso então.”

10. Massa de dados é uma coisa que não deve existir. Faça alterações no banco para que cara registro precise ser deletado. Divida o projeto em pacotes/componentes seguindo a metodologia ‘non-sense’. Faça com que qualquer alteração necessite de um build completo, restart do servidor, redeploy e coisas mais que dificultem ainda mais o trabalho de construção.

setSarcasticModeOff();

Atente para 10 coisas que podem levar o seu projeto ao sucesso sem muito esforço.

1. Iterações e prazos reais, tanto para equipe quanto para o cliente
2. Arquitetura é para facilitar, e não para atrapalhar. Tambem não gere código. Diminua a quantidade de código. Menos código, menos falhas.
3. Time antes de tudo! Ela não precisa ser o que o mercado te dá de melhor, mas precisa ser um grupo que passe confiança, internamente e para as outras partes de um projeto. Muitos falam em familia, como a Familia Scolari, a familia Bernardinho. Seleção nada mais é que o melhor elenco disponivel, seja em tempo, dinheiro, geografia, etc.
4. Ambiente de trabalho… preciso dizer mais alguma coisa (caso sim, leia o link)?!
5. O levantamento só precisa ser total ao fim do projeto.
6. Modelagem de banco de dados é uma arte. Modelagem de sistemas (UML, basicamente) tambem é uma arte. Deixemos os artistas trabalharem em conjunto para uma obra final melhor! Porem gênios normalmente brigam entre-si. É nessa hora que vc entra, para fazer a flexibilidade entre os dois mundos.
7. Faça testes, codifique, documente. Faça testes, codifique, documente. Repitam comigo!
8. User Stories são levantadas pelo desenvolvedor com o especialista do negócio. Não crie barreiras nessa comunicação.
9. Documente as peculiaridades. Muitas coisas podem fazer sentido em tempo de desenvolvimento. Talvez, no momento de manutenção, o mesmo código possa não ser tão claro.
10. Monte uma estrutura de projeto. Estrutura mesmo. Build, massa de dados, componentização, facilidade de build, HotDeploy, Mocks, e coisas que vc só deve ter em tempo de desenvolvimento.

Tags: Metodologias Ágeis, Scrum