As três leis que podem facilitar a adoção das técnicas ágeis de desenvolvimento de software

SCRUM e XP estão ganhando cada vez mais adeptos no desenvolvimento dos mais diversos tipos de software (sistemas transacionais, websites, apps para celulares e tablets, etc). Abordagem derivadas do movimento ágil (como DevOps) e técnicas oriundas do “lean” (como Kanban) também ganham espaço crescente nas áreas de operações e prestação de serviços.

No entanto, a adoção de técnicas ágeis não é uma tarefa fácil. Muito embora sua formulação seja bastante simples (vide o “Manifesto Ágil”), sua natureza pouco prescritiva dá ampla margem para interpretação. Além disso, fala-se muito que não basta novas técnicas e ferramentas: é preciso haver também uma mudança cultural – o que torna as coisas ainda mais abstratas e intangíveis.

Três autores encontraram relações muito consistentes de causas e efeitos que foram batizadas como “leis” da engenharia de software. Essas “leis” existem há décadas, mas o fato é que elas aplicam-se perfeitamente aos dias de hoje e, mais que isso, oferecem uma direção segura na adoção das técnicas ágeis. Essas “leis” não são verdades incontestáveis mas sim explicações para situações muito frequentes nos projetos de software.

A primeira é a Lei de Brooks, definida por Fred Brooks Jr:

“Adicionar pessoas a um projeto de software atrasado resulta em um atraso ainda maior.”

BrooksLaw

Ele argumenta que a construção de um software é um empreendimento coletivo, cujo resultado depende da qualidade da comunicação entre os membros da equipe. Colocar pessoas novas em um projeto já em andamento demanda tempo para colocá-las no contexto para que possam integrar-se ao time; isso aumenta o custo da comunicação e a complexidade no gerenciamento das atividades, resultando em queda da produtividade e mais atrasos. Brooks advoga ainda a ideia de times pequenos (que ele chamou de “times cirúrgicos”, como uma equipe médica operando um paciente), facilitando assim a comunicação e a gestão.

A segunda é a Lei de Boehm, enunciada por Barry Boehm, que estabelece que, quanto mais tempo se leva para detectar um defeito (ou “bug”) em um sistema, mais cara é a sua correção.

BoehmsLaw

Isso é bem intuitivo: no início de um projeto, uma dúvida pode ser resolvida com uma conversa com o cliente e a correção do requisito. Quando o sistema já está em produção, o processo é muito mais longo e complexo: um problema é comunicado pelo cliente e precisa ser diagnosticado pela equipe; depois identifica-se o código a ser alterado e os impactos dessa alteração; a seguir vem codificação, integração, testes e a geração de uma versão ou “patch”; a correção deve ser homologada e finalmente ir para produção. Esse custo cresce de forma exponencial: comparado a um erro durante a especificação, um erro em produção não custa apenas 2 ou 3 vezes mais, mas 10 ou 50 vezes mais.

A terceira é a Lei de Conway, criada por Melvin Conway:

“Organizações que desenvolvem sistemas de software tendem a produzir sistemas que são cópia das estruturas de comunicação dessas organizações.”

ConwaysLaw

É a mais sutil destas três leis, pois estabelece uma relação entre coisas pouco tangíveis: o jeito como o software interage com o usuário e a maneira como as pessoas interagem dentro da organização. Essa relação pode ser exemplificada da seguinte forma: organizações mais rígidas e hierarquizadas tendem a produzir sistemas mais monolíticos e com muitos controles; por outro lado, organizações mais flexíveis e com equipes mais independentes tendem a produzir sistemas mais modulares e interligados por interfaces bem definidas.

Então, como essas três leis podem ajudar na adoção das técnicas ágeis?

Pela Lei de Brooks, deve-se otimizar a comunicação e a interação entre os membros do time, se possível com todos trabalhando no mesmo espaço físico (comunicação face a face) e compartilhando informações em formato visual (aqueles famosos quadros com post-it). Essa proximidade também reduz a necessidade de documentação (dúvidas podem ser esclarecidas rapidamente quando necessário). Além disso, times pequenos demandam menos acompanhamento, a ponto de se tornarem auto-gerenciáveis.

Pela Lei de Boehm, o segredo é encurtar o ciclo de feedback, para que omissões e inconsistências sejam detectadas e corrigidas o quanto antes (do contrário podem dar origem a erros cuja correção irá custar muito mais caro). Colocar o cliente (ou outras pessoas com conhecimento de negócio) em contato direto com a equipe permite que os requisitos sejam entendidos e validados antes de iniciar a codificação (aqui cabem técnicas como prototipação e Behavior Driven Development – BDD). O código deve ser testado automaticamente sempre que for alterado, tanto de forma unitária como de forma integrada (através de Integração Contínua e Test Driven Development – TDD). Finalmente, todo trabalho concluído deve ser apresentado ao cliente final, assim a equipe recebe feedback sobre o que foi entregue e pode ajustar o que for necessário.

Pela Lei de Conway, recomenda-se projetar o sistema como um conjunto de componentes interligados, com responsabilidades muito bem definidas e uso controlado através de uma interface (como por exemplo serviços REST). Para isso, deve-se criar times independentes, trabalhando em paralelo e com autonomia para decidir detalhes internos de implementação desses componentes. É importante também estimular a criação de componentes pequenos e extensíveis, sendo assim mais facilmente reutilizáveis.

Podemos concluir dizendo que, em um cenário de rápida evolução das técnicas ágeis e ferramentas de apoio, essas três leis ajudam as organizações a tomarem decisões embasadas nos princípios que forem mais relevantes para as suas necessidades e identificados com a sua cultura.

Por CELSO GONÇALVES JUNIOR

Postado em: 23 de fevereiro de 2017

Confira outros artigos do nosso blog

Como a comunicação influencia em times ágeis?

15 de junho de 2018

Ariane Ferreira Izac

Vamos falar sobre métricas Kanban?

21 de maio de 2018

Ricardo Augusto Shikota

Método Kanban: primeiros passos

10 de maio de 2018

João Paulo Grabosque

Afinal, o que é Scrum Master?

20 de abril de 2018

Fernanda Rogge Barbosa

Deixe seu comentário