Falando em Agile: Danilo Sato e Francisco Trindade

Danilo Sato e Francisco Trindade, ambos brasileiros e consultores da ThoughtWorks, fizeram uma apresentação bastante interessante: Em sua experiência trabalhando só com "bucha" (sim, vida de consultor nessa empresa não é moleza) a intenção era apresentar alguns anti padrões na implantação de métodos ágeis, que normalmente ocorrem. Pode parecer simples, mas Agilidade é uma questão de coragem e atitude.

Adendo: A ThoughtWorks é uma empresa cuja missão é: Revolucionar a Indústria de Software (Otimista? não! Desafiador!)

A apresentação inicia com o Danilo descrevendo um fator crucial na adoção de métodos Ágeis: pessoas . Pode ser um modelo completamente novo, é necessário uma mudança cultural bastante grande, fato normalmente ignorado, o que gera muitos problemas.

Agile Implementation Anti-Patterns

Agile de malandro

Ótima comparação! É a personificação da maior mal entendido relacionado a métodos Ágeis, descrito maravilhosamente no Dilbert:

Neste anti-pattern, apenas os métodos "fáceis" são incorporados, e normalmente interpretados incorretamente:

• Agile não se preocupa com documentação, então não escrevemos nenhum documento
• Testar é difícil, então só vamos testar os itens mais simples
• Refatorar? não... é muito difícil... já sabemos que está funcionando
• Entregar software, claro! O cliente pede e logo ele recebe... sem preocupação nenhuma com qualidade já que entregar é o que importa

Lembre-se: Agile é, acima de tudo, sobre disciplina e trabalho duro. Num processo Ágil é muito mais fácil de quebrar a cara. Enquanto num processo tradicional você pode esperar 6 meses por uma versão num software, com métodos Ágeis em 1 ou 2 semanas, você precisa entregar algo.

Caso isso não aconteça, você terá decepções bastante frequentes, já que não existe preocupação com a série de princípios por trás dessa "abordagem ágil".

Agile by the Book

No início da implantação de métodos Ágeis, todos nós buscamos uma receitinha de bolo que nos permita usufruir de todo o proder de XP, Scrum, DSDM, Cristal, etc... E lá está você, implantando todas as práticas do livro eXtreme Programming. Mas isto não será suficiente, já que as práticas de um livro, mesmo que te levem a uma melhoria significativa, não possuem conteúdo . É necessário incorporar toda a filosofia de melhoria contínua por trás das práticas, para que se possa ir além. Receitas de bolo ajudam bastante no início da adoção, mas não devem ser encaradas como dogmas. Os princípios é que são importantes! Os princípios.

Equipes Burrocráticas

Não adianta apenas dizer que "somos ágeis", entregando software em uma semana, se estamos todos presos em silos:

• Desenvolvedores escrevem código
• Testadores, longe dos desenvolvedores, verificam erros no software
• Desenvolvedores não querem interagir com o cliente, ouvir suas necessidades

Desenvolvimento Ágil não é apenas uma mudança de processos, mas sobre mudança de cultura. É uma mudança radical na forma de enxergar o desenvolvimento de software: colaboração, participação, respeito, trabalho em equipe... Fechados em silos, nos esquecemos do principal objetivo com o desenvolvimento de software: entregar software . Assim, trabalhamos em objetivos completamente diferentes: desenvolvedores querem o melhor software O principal fator de sucesso em métodos Ágeis é a multidisciplinariedade . É necessário quebrar o paradigma verticalizado: reuna as pessoas!! Foque no Cliente!!

E a velocidade?

Dar valor demais à velocidade como uma medida de performance, causará comportamentos disfuncionais em sua equipe. Normalmente, a equipe trabalhará para mostrar ao gestor o tão sonhado número mágico , esquecendo-se do foco de projetos ágeis: interação entre as pessoas, satisfação do cliente. Assim, o incentivo será o incorreto!

A intenção da velocidade é apenas uma ferramenta para ajudar na estimativa e previsibilidade. Assim, caso "cair a velocidade" possa ser inaceitável para um gestor, a equipe facilmente deixará de lado práticas engenheiristicas de qualidade, gerando software meia-boca. Alem disso, perde-se o valor de Refactoring para seu projeto, que é fundamental para manter a saúde de um sistema. Importe-se com a qualidade , e não com as burocracias. Isto fará sua aplicação perpetuar.

Definição incompleta de "Pronto"

Vindo de outros modelos, esta definição não é normalmente ligada ao valor de negócio que um software deve gerar. Em métodos Ágeis é necessário além de escrever código, escrever os testes automatizados, alguns de aceitação, gerar um pacote para ser implantado no servidor de aplicação e apresentado no cliente para que ele avalie. Somente neste momento uma funcionalidade é tida como Pronta

Num projeto, é preciso existir esta definição. E ela deve estar bastante clara para todos da equipe. Mais informações.

E o que a gente faz com o cliente?

Na visão do Francisco, ser o cliente é o papel mais difícil. Principalmente pelo fato de que é necessário compreender todo o domínio do problema: a entidade perfeita . Nesta visão, seguir todas as intenções e indicações do cliente/Product Owner guiará o projeto ao sucesso. O problema está em transformar esta persona cliente em o dono da verdade, ou deixá-lo sozinho, sem ajudá-lo a compreender o próprio processo de negócio. Normalmente, para algumas funcionalidades, o PÒ não sabe ao certo como será a solução, e por isso é necessário que a equipe, com o conhecimento de software ajude-o a resolver rapidamente seu problema.

Muitas vezes podemos pensar que Software é o centro do mundo, e deixamos a cargo do cliente dar todas as resposta em como produzir software. É necessário colaboração!!

Big Design Up Front

Trazemos vícios de projetos antigos (tradicionais) para os projetos "Ágeis". Assim, algumas vezes, querendo escrever um pouco de documentação sobre o domínio do problema, criamos complexidades completamente desnecessárias. Precisamos nos questionar não apenas se estamos escrevendo certo o software, mas se estamos escrevendo o software certo. (Pense em YAGNI

Backlog Infinito

Pow, legal esse negócio de User Story. Entao, pensa o PO do projeto: vou escrever todas as coisas possíveis de acontecer com o projeto nessa pilha chamada Product Backlog. Na equipe, isto pode gerar um problema. O trabalho em organizar e manter um PBL pode ser bastante problemático. Preocupar-se com um backlog gigantesco trás mais problemas que soluções. Muito provavelmente itens no final da pilha nem serão implementados no decorrer do tempo, e por isso, a equipe não precisa(deve) se preocupar com o que não está no seu campo atual de visão (Sprint)

Agilidade Estacionada

Desenvolvimento Ágil é sobre mudança! É sobre melhoria contínua! Se você está há 3 meses desenvolvendo num projeto ágil da mesma forma, você não está desenvolvendo de forma Ágil. Preocupe-se com as retrospectivas, elas são o mais importante de todo o processo. É SEMPRE necessário refletir sobre como melhorar. Nem que seja um pouco, nem que seja o mínimo.

Bem... muito boa a conversa com os caras. Realmente muita experiência e bastante vontade de compartilhar essa experiência.

Intenção da apresentação:

Ágil é sobre pessoas! Compartilhe, colabore, ouça e faça! Não apenas nos livros, descubre para a sua equipe como trabalhar melhor!

até mais