Há algum tempo venho estudando sobre práticas ágeis, e sua adoção e confesso que sinto-me receioso com a forma mais básica de “adoção ao mundo ágil”. A regra básica é: Adotamos Scrum e “XaZAM”, sou ágil. E antes que algum “Scrum Master” fique chateado, vou explicar-me.
Gosto de Scrum, é leve, simples, direto, eficaz, é voltado a ROI (nada nais justo e óbvio), envolvente, favorece a comunicação e etc. Entretanto, minha opnião é que todo livro ou material de Scrum devia vir com uma tarja preta com a seguinte frase:
“Scrum é um processo centrado em técnicas de gerenciamento de projetos”
Assim, Scrum deliberadamente omite qualquer prática técnica, em contraste (por exemplo) com Extreme Programming (leiam FlaccidScrum). Ou seja ela admite que seu projeto adota boas práticas de desenvolvimento de software.
Como descobrir que as coisas não andam bem:
- Seu projeto adota boas práticas de desenvolvimento? Vc adota práticas ágeis?
- É capaz de entregar software rapidamente, no prazo, mas sempre cria Débito Técnico (os famosos, depois agente ajeita)?
- Como anda sua integração contínua? Consegue liberar uma versão em 15 minutos?
- Como andam seus testes? Cobertura alta? Automatizados?
- Tem medo de alterar código e quebrar em outro canto?
- Equipe energizada e auto organizável?
- A cada Sprint a velocidade da equipe parece diminuir?
- Os BUGs estão em queda constante?
- Sua equipe e seus chefes conhecem e acreditam no manifesto ágil? Ou processo é sagrado e atrapalha mais que ajuda?
Eu compartilhp da visão do Akita, de que geralmente a adoção ocorre de cima para baixo, e isso pode ocultar ou dar menos importância a filosofia ágil e as boas práticas de desenvolvimento, dentro da equipe de desenvolvimento. O que o “James Shore” defina da seguinte forma:
“These psuedo-Agile teams are having dessert every night and skipping their vegetables”
Portanto, apesar de seu chefe achar legal a adoção de Scrum, lembre-se que Scrum não é bala de prata e de nada adianta um software, feito nas cochas, sem nenhuma prática ágil de desenvolvimento. Se tudo é feito as pressas e com milhões de Bugs e débito técnico, seu projeto está fadado ao fracasso.
Nota 1 – Leitura recomendada: Scrum e XP direto das Trincheiras; The Art of Agile Development; Extreme Programming Explained: Curso de Scrum com Rodrigo Yoshima;
Nota 2 - Definições de SCRUM (Processo x Metodologia x Framework x Só de Gestão x De Software .. Eu pouco me importo com a etimologia, importo me com a filosofia ágil) Confira a variedade de definições:
Embora a wikipedia venha com esta definição de Scrum “Scrum é um método ágil para Gerenciamento de Projetos.”, gostaria de lembrar que Scrum foi feito para desenvolvimento de Software (Milfont me chamou atenção disso! foi mal, só copiei a definição do wiki :-P )
“Scrum is an agile software development framework.” definido por Scrum Alliance
“Scrum is an agile process for software development” definido por Mountain Goat
“Scrum is an agile* software-management process” definido por IBM
Fora o problema da "bala de prata". O pessoal diz que tá usando Scrum, por causa da moda, mas não pratica os valores ágeis. O famoso ScrumBut (http://blogs.msdn.com/ericgu/archive/2006/10/13/scrumbut.aspx)
ResponderExcluirQuase todos os projetos que usam ou vão usar Scrum aqui na nossa cidade, e voce já deve ter percebido, vão falhar miseravelmente.
ResponderExcluirPrimeiro fato é que há uma migração de outroas metodologias mas não há migração de cultura.
Segundo fato e decorrente do primeiro é que os valores à direita no manitesto ágil continuam importando mais do que os da esquerda.
Muito bem lembrado Milfont, o manifesto ágil deveria ser o básico para quem quer ser ágil.
ResponderExcluir