No gerenciamento tradicional de projeto é comum se utilizar o conceito de PERT para avaliar o caminho critico e criar os famosos Grant Charts. O modelo para estimativas em PERT é simples e amplamente conhecido. A ideia é definir três valores para a atividade : valor otimista, valor pessimista e valor esperado. Dito de outra forma é definir um valor minimo abaixo do qual a atividade estará com certeza “não pronta”, um valor máximo acima do qual a atividade estará “pronta” e um valor esperado entre o minimo e o máximo que seria o valor aceitável e com menos surpresa.
Por exemplo, para chegar em causa vindo do seu trabalho você demora quanto ? Você sabe que não tem como demorar menos de 1h, então este é o valor otimista (minimo) e nunca demorará mais de 2 horas. Este é o valor pessimista (máximo), mas normalmente vc demora 1 hora e meia, este é o valor esperado.
O modelo PERT ensina então que podemos calcular o valor médio (espectável) fazendo uma simples conta:
valor médio = (Otimista + 4 Esperado + Pessimista) / 6
E que o desvio padrão seria
desvio padrão = (Otimista + Pessimista) / 6
No nosso caso teríamos (1 + 4 x 1.5 + 2) / 6 = 1.50 como média e 0,33 de desvio. Isto significa que esta atividade seria colocada no chart valendo 1.5h com desvio de 20 minutos.
Contudo ainda temos um problema, temos três valores para o desenvolvedor chutar. Ou, dito de outra forma, três oportunidades de errar. Não seria melhor diminuir essa chance de erro?
Analisemos agora a escala de Fibonacci : 1 , 2, 3 , 5 , 8, 13 … que é usada em metodologias de planning poker. O planning poker permite escolher apenas estes valores , o que significa que o valor médio da atividade é determinado pela sequencia. A escala é descontinua, o que significa que se a pessoa acha que é um 4 ela é obrigada a escolher entre 3 ou 5 dependendo se for um “grande 4” ou um “pequeno 4”. Esta mecânica da escolha do planning poker significa que dado um valor na escala o valor otimista é o valor imediatamente atrás e o pessimista o imediatamente à frente.
| Otimista | Esperado | Pessimista |
| 0 | 1 | 2 |
| 1 | 2 | 3 |
| 2 | 3 | 5 |
| 3 | 5 | 8 |
| 5 | 8 | 13 |
| 8 | 13 | 21 |
| 13 | 21 | 34 |
| 21 | 34 | 55 |
| 34 | 55 | 89 |
| 55 | 89 | 144 |
Isto nos leva a um calculo simples que permite usar a formulas do PERT para calcular a média e o desvio (em valores inteiros, porque o planning poker é com valores inteiros)
| Esperado | L | H |
| 1 | 1 | 1 |
| 2 | 2 | 2 |
| 3 | 3 | 4 |
| 5 | 4 | 6 |
| 8 | 7 | 10 |
| 13 | 11 | 16 |
| 21 | 18 | 25 |
| 34 | 30 | 41 |
| 55 | 48 | 66 |
| 89 | 78 | 107 |
Se tomarmos atenção toda a escala de valores está coberta sendo que o desvio dos numero mais baixo é menor que o dos mais altos o que nos leva ao efeito esperado da escala em que os números maiores têm inerentemente mais incerteza ( comprar 1 com 2 é simples, comparar 5 com 13, nem tanto).
A partir do valor 30 ficam alguns hiatos e isso corresponde com o ajuste comum da escala do planning poker que a partir de 20 a escala é de 20 em 20.
Isto significa que a escala e regras de planning poker otimizam o planejamento PERT usando menos contas e menos chutes. O simples uso da escala já compensa os desvios padrão maiores e o fato de que existe uma sobreposição.
O Planning Poker é uma versão moderna do processo Widebrand-Delphi da teoria clássica em que o grande pulo do gato é usar uma escala pré-definida e cartas para obter o consenso. O objetivo – encontrar o consenso entre os pares – é conseguido mais rapidamente deixando mais tempo para a discussão do assunto. Mas ao mesmo tempo a estimativa do planning poker irá afetar a construção dos backlogs de produto e release que são uma versão melhora dos Grantt charts. Portanto, saber que o algoritmo PERT está também incluso no processo significa que com uma tacada só usamos vários métodos já conhecidos do modelo clássico em um processo simples e unificado.
Isto que é agilidade.
Olá Sergio,
Acompanho seu blog há algum tempo e considero muito interessante sua opinião e ideias sobre métodos ágeis.
Estou trabalhando numa empresa que estamos enfrentando alguns problemas de passagem de conhecimento, e a equipe votou e considera o mais válido ter uma documentação/treinamento sobre as regras de negócio, que hoje desconhecem. Realmente a documentação é bem necessária, pois hoje ela não existe, o que temos são uma ou duas pessoas que sabem bastante e que devemos perguntar em caso de duvida. São vários times e vários sistemas, todos muito grandes. Mas a maioria nas equipes são pessoas novas que precisam dar manutenção nesses sistemas, sem conhecer muito deles (o código Java também é difícil de ler).
Alguns erros occorreram com esses sitemas em produção com um impacto grande e achamos que isso ocorreu pela falta de um maior conhecimento do negócio por parte das equipes de desenvolvimento.
Sabemos que documentar tudo é impossível e também impossível de funcionar pela manutenção. Estamos pensando em documentar o que é mais essencial e como uma forma democrática de passar o conhecimento a quem quiser saber.
A dúvida que nos resta é como por isso em prática. Você considera que seja válido criar estórias (usamos Scrum) exclusivas para criar essa documentação? E se ela for feita em par, para que se torne legível e de alta qualidade? Enfim, quais seriam suas ideias?
Abraço
Realmente a passagem de conhecimento é essencial. Existam vários fatores que atuam aqui. Ha o fator da pessoa querer saber. Este é o mais importante. Ha o fator de existirem pessoas que possam explicar. Este ajuda muito a poupar tempo, mas não é essencial pois as regras podem ser inferidas do código (supondo que ele funciona corretamente).
A passagem de conhecimento é um processo continuo. Não ha como criar estórias para isso. Se não usam scrum não é ele que vos vai ajudar. São práticas ageis de engenharia como XP, não de processo como Scrum. Se usam scrum, então ha que criar espaço entre os sprints para a divulgação.
As práticas de engenharia que vos podem ajudar começa por comunicar. Não precisa usar par programing, mas que as pessoas conversem do sistema. Se for possivel usar pair programming, então façam porque realmente é o que mais ajuda à divulgação da informação. Outra coisa que ajuda são quadros brancos com esquemas ou desenhos que ajudem a entender as regras do sistema. Sobretudo o modelo de entidades e serviços pois os conceitos de negócio estão essencialmente ligados a estes dois. Mas pode ser que existam alguam regras de tela. Nesse caso um desenho do fluxo de tela seria util. A ideia aqui é visibilidade, fácil consulta e fácil alteração. Um exercicio possivel, entre sprints, é reunir a equipe em frente a quadro desse e ir criando o quadro compondo as pequenas partes que cada um sabe. Se existe alguem que conhece o fluxo todo, essa pessoa pode desenhar o quadro sozinha e depois explicar rápidamente. Tentem ser rápidos e direto ao ponto. Tentem não usar salas de reunião onde todos ficam sentados porque isso causa acomodação. Mesmo que usem a sala para não atrapalhar os outros colegas, façam algo informal, mais ativos (cada um com um caneta, por exemplo). A ideia é que todos participem simultaneamente.
Se usam scrum, usem o planning poker para conhecer exactamente os detalhes das estórias. O PO é tecnicamente a pessoa que vos pode ajudar mais ou encaminhar para quem pode. Mas se o PO é ausente ou fraco vcs tem que procurar as fontes vcs mesmos.
Documentar parece legal, mas existem diferentes formas. Os quadros brancos com esquemas desenhados são uma forma de documentação. Quando a informação do quadro já tiver sido absorvida e estável ( ninguem adicionou ou removeu nada em alguns meses) é hora de escrever um documento mais perene e deixá-lo acessivel em formato eletronico. Aqui pode ser um simples txt, um doc ou uma wiki. Vai depender da vossa estrutura, o que importa é que não se perca. Se for um doc ou um txt, tem que estar no svn. Uma forma de torna isto util para empresa, é em vez de criar um documento qualquer avulso, incluir as informações no manual do software. O manual é algo mais bem entendido por quem não é tecnico e pode incluir todas as regras e decisões tomadas.
Uma outra forma de divulgar conhecimento é montar um sistema de newsgroup ou forum na vc intranet e usá-lo para conversar sobre duvidas etc… desta forma todas as conversas ficam gravadas para posterior pesquisa.
Documentação tradicional do tipo um cara senta e escreve um doc de 100 páginas não é uma boa forma de divulgar o conhecimento. É apenas uma forma de persistir o conhecimento, e vc precisam de algo mais eficaz num primeiro momento.
Finalmente, em relação ao código, sigam a regra do bom escuteiro e sempre que virem um codigo confuso, mal escrito alterem-o. Limpar o codigo desta forma deixa mais visivel o que ele realmente faz e o torna mais fácil de ler no futuro. O código é o unico documento que sempre está sincronizado com o sistema, por isso ele deve ser cuidado ( como um bonsai) para que sempre esteja livre de parasitas (bugs) e seja agradável de ler. Se necessário procesam a refactoring que deixe as coisas mais legiveis e mais leves para quem procurar entender a regra.
Se usam scrum, adicionem “documentação atualizada” na vossa definição de pronto, e por consequencia no tamanho das historias. Isso vos dará recursos para deixar o codigo legivel e os quadros (wiki, newsgroup, … o que for que usem) atualizados.
Muito obrigado pela resposta Sergio, vou conversar com as pessoas aqui.
Realmente parece ser uma boa ideia uma das pessoas que mais conhecem ir desenhando no quadro a arquitetura, de uma forma bem visual e depois registrarmos isso num Wiki, de uma forma contínua. Vamos ver…