Resistência à Mudanças

As metodologias ágeis enfrentam muitas resistências no mercado. Muitas vezes a resistência está em nós mesmos! 

Esse post causou uma boa polêmica e levantou vários pontos que o mercado utiliza para não adotar agilidade (Vejam os comentários aqui). Conheço o Fábio, e ele é um arquiteto de muitíssima competência com várias certificações e demonstra bem o que muitas empresas pensam a esse respeito. Porém uma opinião tem que ser formada quando se conhece bem os opostos. Muitas perguntas passam por nossa cabeça quando a gente depara com um novo paradigma, é normal!

Como estimar prazos em uma metodologia ágil? Como fica o contrato? Como garantir implementar funcionalidades dentro do escopo?

Um dos grandes ganhos da metodologia ágil com certeza é estimativa de prazos. O Scrum tem várias técnicas para estimar um prazo conciso. Mas como estimar? O Scrum tem o Planning Poker.

 

E se a estimativa falhar? É mais difícil isso acontecer pois os sprints (iterações) devem ser curtos, mas se acontecer o Scrum tem o Sprint Retrospective, Sprint Review. 

Como aprender com os erros? Sprint Backlog atualizado. Como manter o time auto-motivado? Daily Scrum. Como fazer códigos melhores? Pair Programming.

O assunto é muito rico. Tem muitos cursos bons no mercado. Para quem gosta de auto-estudo eu recomendo os livros:

• Agile Software Development with SCRUM 
• Agile Software Development, Principles, Patterns, and Practices
• Extreme Programming Explained: Embrace Change (2nd Edition) 
• Extreme Programming (Em Português!)

 

Alguém já pensou nos problemas que a gente enfrenta. Sempre ouvimos a frase “Não reinventar a roda”.

Apenas mais um ditado que gosto muito:

“Um tolo erra e insiste no erro

Um inteligente aprende com os próprios erros

Um gênio aprende com os erros dos outros”

Divisão de Responsabilidades

Quando eu falei sobre divisão de responsabilidades no post anterior eu não quis dizer uma pessoa fazer o trabalho de todos, muito pelo contrário! E para uma equipe maior que umas 9 pessoas pode ser impraticável algumas técnicas do Scrum, por exemplo o Daily Scrum que tem o objetivo de ser rápido. Mas quando ocorre um time tão grande assim? Não é impossível ter muitas pessoas num projeto. Eu particularmente já participei de um time de 11 desenvolvedores. Nesse caso talvez algumas técnicas do Scrum me ajudasse, mas não todas! Porém a maioria das vezes a equipe não é tão grande, então quanto mais técnicas usar, melhor!

Mas vamos pensar um pouco. Um problema que acontece muito nos projetos atuais é o software final não sair da maneira que o cliente esperava, e aí ocorrem os retrabalhos. Por que isso acontece tanto? Não quero generalizar, só vou dar um exemplo. Ocorre porque no levantamento do projeto os analistas de negócio fazem toda a documentação e passam para uma fábrica de software implementar. Os desenvolvedores são cobrados por prazos e muitas vezes não lêem todas as 50 páginas do documento e fazem da forma que entenderam podem interpretar de maneira erronea, a não ser que exista um documento de Visão que não permita esse mal entendimento. Eles não participaram das reuniões com o cliente não sabem o escopo do projeto o que facilitaria o entendimento e possibilitaria ter uma visão macro do projeto. Mesmo se o conhecimento for passado do analista de requisitos para o desenvolvedor por meio de uma conversa, não será tão bom como o próprio cliente passar o conhecimento, pois esse último é o que realmente entende do negócio. As vezes um intermediário pode causar o problema de telefone sem fio. Daí quando o projeto está quase acabando já é tarde demais. Comentei sobre isso nesse post.

Uma metodologia ágil deve dizer que o cliente tem que estar sempre próximo do time, e quanto mais desenvolvedores participarem das reuniões, sobre os requisitos por exemplo, é melhor. No scrum existe os papéis de Product Owner (pode pensar no cliente do exemplo citado), o Time, e o Scrum Master. Isso muitas vezes é o suficiente.

Devemos ter testers? Sim, mas se o time trabalhar com TDD do Extreme Programming pode ser que não precise.

Podemos ter analistas de negócios? Sim, desde que não seja um intermediário.

Metodologia Ágil

Estava conversando sobre metodologias com um amigo, gerente de projeto da empresa o qual trabalho, e quando falei de Scrum ele se mostrou muito interessado no assunto. Porém fui surpreendido quando ele falou que conhecia outra metodologia, o famoso XP, e disse que se o Scrum for como o XP seria uma carta fora do baralho. Curioso em saber o porquê ele me disse que trabalhar em par é coisa de criança, e não tinha mais argumentos para falar sobre o XP. Então eu expliquei que tem o outro lado da moeda. Trabalhar em par possibilita a troca de conhecimentos da equipe e a codificação é revisada a todo momento. E para fazer críticas a uma metodologia temos que pelo menos entendê-la como um todo, e não por causa de uma ou duas regras dessa.

Muita gente ainda tem preconceito de metodologias ágeis pois acha que isso não vai pegar, mas por puro desconhecimento nem imagina que isso já pegou! No Brasil ainda não está muito difundido, mas acretido que o mercado está mudando. Grandes empresas já adotam essa metodologia, como por exemplo a Globo.com com alguns cases de sucesso. Mas por que estão adotando agilidade? Vejamos:

Os projetos atuais e tradicionais não estão tendo sucesso! Gantt Chart não funciona! Processos waterfall não funcionam! As fábricas de software não estão conseguindo cumprir os prazos porque esse modelo tem muitos problemas!

Esse gráfico é antigo, mas acredito que hoje ainda não esteja muito diferente. Ele mostra que apenas 16% tem sucesso e são entregues no prazo.

Muitos comparam a engenharia de informática com engenharia mecânica mas são engenharias completamente diferentes. Na informática a formula ( Progresso = Número de Pessoas / Número de Tarefas) não é verdade.

Um modelo em cascata, também conhecido como waterfall, tem o seguinte aspecto:

Já num modelo incremental essas fases devem ocorrer a todo tempo. Em curtos intervalos de tempo todas essas fases devem ser executadas e revisadas.

Muita gente diz que aplica RUP mas na verdade faz tudo waterfall. Passam meses fazendo páginas e mais páginas de documentação e entregam para desenvolvedores que precisam ler tudo, interpretar os textos e traduzir tudo em código. Sempre ocorre problemas de interpretação e geralmente nem tudo é lido antes de começar o desenvolvimento. Depois vem a frase conhecida do cliente “mas não era isso que eu queria”. Acontece que é difícil manter a documentação porque os requisitos mudam. As vezes o cliente descobre o que realmente queria depois que começa a usar o software, e o que mais vemos é trabalhos e re-trabalhos. Esses documentos, muitas vezes chamados de contrato, serão o alicerce de discussões entre clientes e prestadores. Vejam, eu não sou contra documentação e nenhuma das metodologias ágeis falam que não deve ter documentação! Documentação é importante, mas é mais importante o software funcionando do que o detalhamento de todos os escopos num documento. Melhor ainda se a documentação for executável para garantir que está refletida no código.

Por isso que surgiu as metodologias ágeis, por isso que surgiu o Scrum, por isso surgiu o Manifesto Ágil!

Comecei a utilizar técnicas do Scrum junto com técnicas de XP e obtive melhorias em meu trabalho rapidamente. Essas idéias ágeis formam um framework de processos que resolve a maioria dos problemas conhecidos, então por que não usar? Será que é muito difícil?

É claro que não é a certeza do sucesso, mas se a equipe for bem  qualificada e atenta, dificilmente ocorrerá desvios que possam prejudicar o andamento do projeto.