A culminação do capítulo é a seguinte:
A agilidade é um processo em que:
Outros pontos interessantes:
[TOC]
Um constatação em relação a quando um movimento se torna popular (como o movimento ágil) e que no meu entendimento está acontecendo agora (2022) com movimento DevOps.
Infelizmente, uma vez que um movimento se torna popular, seu nome é corrompido por mal-entendidos e usurpações. Os produtos e métodos que não tem a nada a ver com o movimento em si se aproveitam de seus nomes a fim de lucrar com a popularidade e relevância deles. E assim tem sido com a agilidade.
Na manufatura e na indústria em geral, o Taylorismo vinha obtendo um considerável sucesso.
A Administração Científica [ou Taylorismo] é uma abordagem top-down, de comando e controle. Os gerentes usam técnicas científicas a fim de determinar os melhores procedimentos para alcançar uma meta e, em seguida, instruem todos os subordinados a seguirem seu planejamento à risca.
Na década de 70, havia o "pré-ágil" (a metodologia ágil antes de ter esse nome) e o Taylorismo.
Artigo que foi, meio que de maneira equivocada, tido como principal inspiração do método cascata: Managing the development of large software systems, por Winston Royce (1970).
Ainda que Royce não o recomendasse, era o conceito que as pessoas extraíram do trabalho dele e que dominou as próximas três décadas.
(interpretação contestada no capítulo 7 de Bossavit, The leprechauns of Software Engineering)
Regra irrefutável de projetos de software.
Restrição Tripla: escolha somente três dentre
Você não pode ter os quatro.
Um bom gerente de projetos entende que esses quatro atributos têm coeficientes. Ele administra os coeficientes em vez de exigir que todos sejam 100%. A metodologia ágil se esforça para atingir esse tipo de gerenciamento.
Uma das motivações principais para o desenvolvimento de software ágil é fornecer os dados que os gerentes precisam a fim de decidir como definir os coeficientes na Restrição Tripla e conduzir o projeto rumou ao melhor resultado possível. (...)
O desenvolvimento ágil é uma abordagem orientada a feedback. Cada (ação) é orientada pela análise dos resultados das (ações) anteriores e, em seguida, pela realização dos ajustes apropriados. (...) Sem os dados, o projeto não pode ser gerenciado.
Por isso 👆 que tem tudo a ver com a DevOps. As ferramentas de DevOps servem exatamente para 1) colocar o código em produção o mais rápido possível e 2) gerar dados de feedback. (ver OODA loop de John Boyd)
O prazo, uma vez escolhido, é congelado. Imutável.
Seja lá qual for o motivo, é por razões comerciais, e isso não mudará apenas porque alguns desenvolvedores acham que talvez não consigam cumprir o prazo.
Simultaneamente os requisitos estão em constante mudança.
Este é o mundo de uma equipe de desenvolvimento de software. É um mundo em que os prazos são congelados e os requisitos constantemente mudam. E, de alguma forma, nesse contexto, a equipe de desenvolvimento deve fazer com que o projeto tenha um bom resultado.
O problema da ideia do Método Cascata é que ele faz todo o sentido.
Simples. Direto. Óbvio. E errado.
O principal aprendizado desse cenário descrito abaixo é: seja transparente com os stake holders e forneça informações o mais rápido possível.
Determina-se um cronograma sem nem saber quais são os requisitos.
Como fazer análise sem conhecer os requisitos? 🤷
Eis a melhor definição de análise: é o que os analistas fazem.
Não há uma definição clara, no entanto algumas coisas são óbvias:
De repente terminamos a análise. Por que? Porque o cronograma dizia que deveríamos acabar nesta data.
Design de software é quando dividimos o projeto em módulos e projetamos as interfaces entre eles. É também quando determinamos quantas equipes precisamos e quais devem ser as conexões entre essas equipes. (...)
As coisas mudam de forma inesperada durante essa fase. Acrescentam-se funcionalidades novas. Removem-se ou alteram-se as funcionalidades antigas.
Outro milagre acontece: terminamos o Design! Por que? Porque é o que está no cronograma.
Se pudéssemos também apenas dizer que terminamos a implementação... Mas não podemos, porque a questão da implementação é que, na verdade, ela precisa estar pronta.
Isso 👆 me lembrou Code Complete, no primeiro capítulo ele diz "construction is the only activity that's guaranteed to happen on every project".
A implementação tem critérios de conclusão definidos. Não há como fingir que você implementou alguma coisa.
Nessa fase os requisitos ainda estão mudando...
Ao analisar o código e compará-lo com o design, percebemos que devíamos estar fumando alguma coisa bem forte quando criamos esse design, pois claramente o código não está parecido com aqueles diagramas belos e elegantes que desenhamos.
É nessa fase que percebemos que o tempo para conclusão claramente não é suficiente. E então as partes interessadas são informadas de que pode ocorrer um atraso.
Todo mundo está chateado e desmotivado. E promtemos a nós mesmos que nunca mais faremos outro projeto como este.
Uma abordagem ágil é diferente do que o cenário descrito acima 👆.
Um projeto ágil começa com a análise, no entanto é uma análise que nunca termina.
Subdividimos o tempo do projeto em incrementos regulares chamados iterações ou sprints.
Algumas pessoas acham que a metodologia ágil é apenas uma série de mini-Métodos Cascata. Não é o caso. (...) Não se realiza a análise somente no início da iteração, nem se realiza a implementação apenas no final da iteração. Ao contrário, as atividades de análise, arquitetura, design e implementação de requisitos são constantes durante toda a iteração.
A Agilidade Gera Dados
A iteração 1 começa com uma estimativa de quantas histórias serão concluídas. (...) Por enquanto, quais são as possibilidades de a equipe concluir todas as histórias que planejou terminar?
Praticamente zero, é claro. Software não é um processo de estimativa confiável. Nós simplesmente não sabemos quanto tempo as coisas levarão. Não temos como saber exatamente o quanto uma tarefa será complicada até que ela esteja em andamento e seja concluída.
Nota pessoal: acredito que quanto mais experiência você tem fazendo o mesmo tipo de software, mais insumos você tem para fazer uma estimativa próxima da realidade.
No final da iteração, uma parte das histórias que planejamos terminar será concluída. Isso nos fornece nossa primeira avaliação de quanto pode ser concluído em uma iteração. Ou seja, são dados reais. (...) Podemos calcular uma nova data final para o projeto.
É provável que esse cálculo seja bem desanimador. No entanto, essa data nova tem como base os dados reais, logo, não deve ser ignorada.
Isso aqui é importante:
A agilidade gera dados. Os gerentes utilizam esses dados para direcionar o projeto rumo ao melhor resultado possível.
Esse gerenciamento deve sempre levar em consideração a Restrição Tripla (escolher 3 entre bom, rápido, barato e concluído)
Restrição Tripla: escolha 3 entre
(entre parenteses são os termousados no cap. 4 do Programacao eXtrema explicada)
Ações que o Gerente pode tomar, e suas consequências relacionadas aos itens da Restrição Tripla:
| ação | mexe com... |
|---|---|
| mudanças no cronograma | rápido |
| adição de pessoal | - barato - rápido |
| diminuir a qualidade | - bom - rápido |
| mudanças no escopo | - concluído |
Alguns comentários sobre cada ação:
Quanto mais cedo comunicarmos a necessidade de mudanças no cronograma, melhor!
Será que é possível mexer no cronograma? Na maioria das vezes não. Mas o exemplo dado no livro é interessante:
talvez aconteça uma feira em novembro em que eles querem exibir o projeto. Talvez ocorra outra feira em março que seria tão boa quanto. Lembre-se: ainda é cedo. Estamos com somente algumas iterações neste projeto. Queremos dizer às partes interessadas que nossa data de entrega será em março antes que eles aluguem agora o estande para a feira de novembro.
Adicionar pessoas a um projeto de software atrasado resulta em um atraso ainda maior.
Um detalhe que muitas vezes é despercebido é que a lei de Brooks se refere a um projeto já atrasado.
O que acontece é que quando entram mais pessoas no projeto, a produtividade cai. Pois os profissionais experientes precisam despender um tempo explicando o projeto para os novatos. Só após os novatos se tornarem produtivos é que a produtividade começa a ficar maior do que no início.
O principal trade-off aqui é: você precisa de tempo e melhorias suficientes afim de compensar a perda de produtividade inicial.
Outro fator: contratação de pessoal é cara.
Se não despendemos de tempo nem de dinheiro para bancar o custo de adicionar pessoal, temos que pensar em mudar outra coisa.
Fazer as coisas malfeitas não o faz avançar mais rápido, o faz avançar mais devagar.
Lição aprendida depois de trabalhar como programador durante vinte ou trinta anos.
A única forma de avançar rápido é fazer as coisas bem-feitas.
Se queremos reduzir o nosso cronograma, a única opção é aumentar a qualidade.
Nota: Essa constatação é similar ao que vi no Practical Object-Oriented Design:
The programming techniques that make code a joy to write overlap with those that most efficiently produce software.
Se não tem como mexer no cronograma, precisamos decidir quais são as features extremamente necessárias e eliminar as que não são.
Parte interessante (sobre ter os dados):
Os programadores têm os dados. E em qualquer organização racional, os dados levam a melhor.
Se a organização é racional, as partes interessadas acabam por acatar e aceitar, e começam a analisar o planejamento.
A agilidade é um processo em que:
Ao final do capítulo há uma forte propagando pró-XP, do Kent Beck. Fiquei interessado!