Concrete Logo
Hamburger button

Ponderações de um veterano sobre práticas ágeis

  • Blog
  • 9 de Outubro de 2012
Share

Venho trabalhando há alguns anos com times ágeis e gostaria de deixar minhas impressões sobre algumas das práticas:

 

A) Engenharia de software

1 – Programação em par:

Já vi funcionar bem nos seguintes casos:

  • – Ambientação/adaptação de novos membros à cultura do time/projeto/empresa;
  • – Capacitação daqueles que estão muito acostumados a lidar só com determinado tipo de tarefa nos sprints. Por exemplo, codificar apenas as camadas de back-end, sem meter a mão em front-end;
  • – Estímulo à comunicação e entrosamento (no islands);

Para times mais maduros tecnicamente e disciplinados, não vejo como necessidade mas como instrumento de apoio para os desafios acima, conforme critério do próprio time;

 

2 – Testes unitários, TDD/BDD

Escrever testes quebrados, antes do código funcional (TDD), é uma prática que exige disciplina e um punhado de “fé” do desenvolvedor, uma vez que os benefícios são de quem o pratica, não de quem ouve falar ou estuda.

Considero que escrever código antes do teste é uma prática perigosa, uma vez que os testes ficam “viciados” pelos resultados já conhecidos pelo programador, além de tendenciar que os testes não cubram todas as possibilidades do plano de execução do algoritmo (if roda, else não roda), afetando code coverage, etc.

 

B) Ambiente de trabalho

3 – Open Space

Super válido quando existe a percepção clara de espaço de uso coletivo, por parte de quem usufrui do mesmo. Conversas paralelas, “piadas internas” ou qualquer tipo de discussão, mesmo válida, em tom de voz mais alto, atrapalha facilmente o colega ao lado que vive em outra realidade. É difícil de contornar.

Um dos nossos projetos tomou a iniciativa de “isolamento” para preservar a capacidade de raciocínio, já comprometida pelo barulho. Com certeza, diminui a integração inter-equipes mas acredito que o projeto deva estar em primeiro lugar.

 

4 – Trabalho remoto

Acho que funciona bem quando o membro precisa de flexibilidade pra conciliar uma questão extra-oficial com o trabalho. Ter a possibilidade de fazer Home-Office é algo legal, mas não quando isso passa a ser usado como primeira opção e não haja a devida transparência sobre o rendimento em H.O. Requer maturidade e isso não é algo que está no currículo.

 

C) Metodologia de gerenciamento de desenvolvimento

5 – Duração dos sprints

A duração de um sprint deve seguir o bom senso e atender as expectativas de avaliação e retorno sobre investimento que os stakeholders/PO venham a manifestar, além das orientações definidas no Scrum Guide.

Com relação ao tempo das reuniões, existem alguns fatores que influenciam positivamente:

    Backlog grooming:

      Quando há o estudo e o entendimento claro sobre os desafios futuros (horizonte maior que um sprint), as reuniões de planejamento se tornam mais curtas e menos cansativas, pois o desafio já é conhecido, bastando validar se o entendimento/estimativa/prioridade estão mantidos, o que toma cerca de 1/3 do tempo médio anteriormente gasto para um item que ainda seria apresentado ao time;

    DoD estabelecido:

      Quando o time tem o conhecimento sobre o desafio e conhece, de forma clara, qual o objetivo a ser alcançado (DoD), cada item é trabalhado de forma a atender a expectativa do PO, sem a necessidade de feedback intenso/contínuo (PO nem sempre disponível). Os reviews tornam-se rápidos e produtivos, pois a distorção entre o esperado/entregue torna-se mínima;

 

6 – Estimativas e Planning Poker

O que tenho visto é que o time, sempre clamando pela autonomia em ditar a solução (e sua complexidade/ esforço), usa o poker como mecanismo de defesa em momentos de pressão, superestimando determinadas tarefas para que o sprint backlog acabe ficando “maior” (menos tarefas).

No fim das contas, a medição/ adaptação ficam prejudicados. Não há como equiparar com segurança o custo de uma tarefa em relação a outra tarefa de mesma complexidade e formar uma base sólida de conhecimento, do time, para estimar com bom senso.

Como quase tudo em Agile, a maturidade do time é algo determinante para a boa prática do Planning Poker ou qualquer outro método de estimativa menos formal. Isso varia conforme o time e sua configuração.

 

7 – Histórias de usuários

Considero que os itens de backlog que explicam bem o problema e proporcionam uma visão suficiente que permita elaborar uma solução, são bons itens de backlog, sejam histórias ou qualquer outro tipo de descrição de tarefa que agregue valor ao projeto/negócio.

Acho que um dos maiores desafios está na granularidade do problema. Tenho visto itens escritos em poucas linhas de texto, mas que remetem a desafios enormes, mais complexos de estimar e que possuem maior risco agregado (aconteceu no carrinho de compras JavaScript/IFrame de um projeto que participei);

 

8 – Reunião diária

Principal problema a ser contornado nas reuniões diárias é controlar o ímpeto do time em usar o daily scrum para abordar problemas e soluções estritamente técnicas (hoje eu fiz tal tarefa com uma implementação X que funciona assim: blah blah blah blah…), ao invés de dar o devido status e definir objetivo do dia seguinte.

Muitos pensam que o daily é o único momento disponível para promover uma integração entre os membros do time, um momento de se comunicar. Isso é um erro. O Scrum Master pode e deve estar atento a esse padrão, para orientar o time sobre o bom aproveitamento do tempo para comunicar tudo que o time necessitar, sem se prender a momentos formais.

 

9 – Alterações no Sprint

Defendo que o sprint deve seguir estritamente o planejamento. É uma forma de valorizar e amadurecer o próprio processo de planejamento. E também diminuir as variáveis e interferências que o time sofre durante a execução do sprint e que comprometem o resultado final.

Óbvio que não podemos esquecer que o PO tem a autonomia de cancelar um sprint, sempre que isso fizer sentido para ele.

 

10 – Atividades de manutenção de software em produção, correção de bugs de sprints antigos, criação de scripts que facilitem alguma coisa, etc.

Acho que o time sempre deve focar na qualidade do produto de software que está gerando, uma vez que o time não deve se tornar um “produtor de bugs”. No entanto, existem ocorrências que fogem desse contexto (bugs antigos, pequenos ajustes) e não devem ser menosprezados.

Já houve a defesa de que bugs são sempre “prioridade zero” mas também defendeu-se que o PO é quem decide se a correção do bug é mais importante pra ele ou não, no momento presente.

Em certas ocasiões, o próprio time já manifestou resistência em ter alguém dedicado a corrigir bugs.

É uma questão complexa.

 

11 – Product Owner

Acho que alguns POs que já lidamos (eu, no caso) são carentes dos seguintes pontos:

    – Pouco ou nenhum conhecimento sobre as práticas do Scrum
    – Pouca ou nenhuma autonomia para exercer seu papel e tomar decisões
    – Pouco ou nenhum alinhamento entre PO e stakeholders, quanto à expectativa sobre o produto que atenda.

Na minha opinião, o Scrum Master pode e deve atuar conjuntamente com o PO para minimizar as conseqüências do pouco conhecimento sobre Scrum e também sobre a comunicação deficiente entre o Scrum Team e os stakeholders.

Com relação ao problema da autonomia do PO, há um contexto externo a ser tratado e equalizado, para que o PO possa de fato exercer o seu papel. Um PO sem mandato é uma fonte constante de incertezas e frustrações para o time, e pode rapidamente levar um projeto ao fracasso.

 


 
Para resguardar meu direito de evoluir idéias e pensamentos, é importante fazer uma observação quanto a data em que estas opiniões foram expressas:

    Este post foi uma resposta escrita em janeiro de 2012 a uma consulta feita por meu colega Luca Bastos.

    Cada um dos tópicos abordados correspondia a uma pergunta da pesquisa. O objetivo era extrair dos desenvolvedores, o que cada um pensava sobre as práticas ágeis.

    Tudo bem de acordo com o item 1 do manifesto ágil, que diz:

      Indivíduos e interação entre eles mais que processos e ferramentas”

 

E vocês, quais são suas percepções sobre estas e outras práticas ágeis e circunstâncias de projetos?