Tenho ouvido ultimamente muitos amigos da área comentando sobre pressão por aumento de produtividade baseada em pontos de complexidade. Isso me deixa bastante preocupado. Embora seja nobre o desejo de aumentar as entregas da área de desenvolvimento, quantificar isso usando os pontos de complexidade das histórias não quer dizer muita coisa.
Contudo antes de simplesmente reclamar contra a pressão, é preciso analisar as possiveis causas de produtividade baixa que possam estimular esse tipo de pressão. Pensando bastante cheguei a três possibilidades, e com elas, possiveis soluções, que seriam mais eficazes do que estimular aumento desse tipo de numero.
1- Não há confiança de que o time esteja trabalhando em seu máximo. Ou seja, o agente gerador de pressão acredita que os integrantes estão fazendo corpo mole ou gastando o dia com amenidades ao invés de se focar na entrega do projeto. A pressão por aumento de pontos de complexidade pode até resolver esse problema temporariamente, mas também pode ser mascarado por integrantes do time que se sentem coagidos a fazer horas extras para cobrir as entregas esperadas. Ou seja, o problema só se resolve mesmo com conversas francas e com uma presença mais ativa do interessado.
2- O time percebendo folga na iteração aproveita para melhorar a qualidade da entrega ainda mais. Esse tipo de preciosismo costuma acontecer com bastante frequência. Muitas vezes o desenvolvedor por ter mais tempo para pensar aproveita para implementar testes e fluxos mais rebuscados evitando bugs que no futuro tomariam o triplo do tempo, e o designer aproveita para criar e rebuscar as interfaces e assim encantar ainda mais o cliente. Neste caso a pressão pelo aumento de entrega de pontos de complexidade apenas estimula a diminuição da qualidade. Ou seja, embora haja um aumento imediato na velocidade, em pouco tempo ela cairá por causa das correções de bugs e dos ajustes visuais.
3- O time é inexperiente ou não conhece a tecnologia adotada. Neste caso pressionar pelo aumento de entrega de pontos de complexidade de nada adianta. De certa forma, com o tempo, naturalmente as entregas serão maiores, ou em muitos casos menores pois o time começará a estimar com menos pontos, demonstrando assim a ineficácia desse numeros para medir produtividade. Para resolver este problema existem diversas opções como, organizar dojos, estimular programação em par, indicar livros e treinamentos, estimular a experimentação com tempo para projetos pessoais.
Todas três possibilidades acima eu vi acontecer de perto nos times em que trabalhei. E quase sempre o problema foi resolvido sem utilizar os pontos de complexidade como parâmetro de medição. E vocês lembram de alguma outra causa de produtividade baixa? Tem idéia de como solucionar? Qual sua opinião sobre o assunto?
Mostrando postagens com marcador scrum. Mostrar todas as postagens
Mostrando postagens com marcador scrum. Mostrar todas as postagens
segunda-feira, 9 de agosto de 2010
sábado, 7 de junho de 2008
EDS: Excell Driven Scrum
Para quem não sabe, EDS é o Excell Driven Scrum. Ou vocês achavam que siglas com a palavra mágica Driven serviam somente para Development? Estavam enganados. O EDS ocorre quando o P.O. elabora previamente um planejamento, sprint a sprint, do que deve ser feito pelo time para um longo período de tempo. Este planejamento é então gravado em um arquivo excell read-only.
Pelo pouco que entendo de Scrum, esse padrão é uma maneira muito equivocada de se pôr em prática um ambiente de desenvolvimento ágil. Isso porque a definição dos sprints deveria ser feita com a particiação do time. E mesmo se esse tal planejamento anual fosse feito com o time, ainda sim eu consideraria errado, pois é impossivel prever com muita antecedência fatores ambientais que fatalmente mudam as necessidades e problemas que precisam ser resolvidos.
Além disso, o fato de termos escopos definidos para cada sprint, faz o sprint planning 1 ficar engessado. O time perde a liberdade de sugerir histórias prioritárias que garantam a qualidade do sistema. Isso acaba causando um desgaste durante a reunião, o time não entendendo como o P.O. pode ignorar os possiveis problemas da aplicação e os riscos que eles podem causar, e o P.O. sem entender porque o time não aceita seguir o planejamento anual.
Acontece que muitas vezes o uso deste padrão não é culpa do P.O., é uma parte da cultura anterior à adoção do Scrum que ainda não foi possivel mudar. Contudo, não se pode fechar os olhos para este problema. Para acabar com o EDS, é preciso que o P.O. brigue corajosamente contra ele. O time também precisa bater o pé o máximo possivel para mudar esta cultura. E a briga não é apenas para mudar a cabeça de quem está acima hierarquicamente, é também para mudar suas próprias mentes.
Portanto, apesar de ter pouca experiência com scrum, acredito que utilizar o padrão EDS não é uma boa alternativa de implantação dele. Pela minha vivência de menos de um ano e a participação em apenas um curso, me parece que um dos principais benefícios que o Scrum traz é a liberdade que o time tem para identificar problemas e resolve-los para garantir a qualidade do produto. Com o EDS isso não é possivel.
Pelo pouco que entendo de Scrum, esse padrão é uma maneira muito equivocada de se pôr em prática um ambiente de desenvolvimento ágil. Isso porque a definição dos sprints deveria ser feita com a particiação do time. E mesmo se esse tal planejamento anual fosse feito com o time, ainda sim eu consideraria errado, pois é impossivel prever com muita antecedência fatores ambientais que fatalmente mudam as necessidades e problemas que precisam ser resolvidos.
Além disso, o fato de termos escopos definidos para cada sprint, faz o sprint planning 1 ficar engessado. O time perde a liberdade de sugerir histórias prioritárias que garantam a qualidade do sistema. Isso acaba causando um desgaste durante a reunião, o time não entendendo como o P.O. pode ignorar os possiveis problemas da aplicação e os riscos que eles podem causar, e o P.O. sem entender porque o time não aceita seguir o planejamento anual.
Acontece que muitas vezes o uso deste padrão não é culpa do P.O., é uma parte da cultura anterior à adoção do Scrum que ainda não foi possivel mudar. Contudo, não se pode fechar os olhos para este problema. Para acabar com o EDS, é preciso que o P.O. brigue corajosamente contra ele. O time também precisa bater o pé o máximo possivel para mudar esta cultura. E a briga não é apenas para mudar a cabeça de quem está acima hierarquicamente, é também para mudar suas próprias mentes.
Portanto, apesar de ter pouca experiência com scrum, acredito que utilizar o padrão EDS não é uma boa alternativa de implantação dele. Pela minha vivência de menos de um ano e a participação em apenas um curso, me parece que um dos principais benefícios que o Scrum traz é a liberdade que o time tem para identificar problemas e resolve-los para garantir a qualidade do produto. Com o EDS isso não é possivel.
quinta-feira, 1 de maio de 2008
Dependência entre tarefas no Scrum
Um problema recorrente nas reuniões diárias do nosso projeto aqui na globo.com é a dependência entre tarefas. Sempre ocorrem interrupções entre o fluxo de "O que eu fiz" e "O que farei" para questionar a algum colega do time se determinada tarefa já foi concluída. No caso afirmativo ele pode então pegar a tarefa que era dependente. Isso acontece frequentemente, e quando ocorre o fluxo desanda e a atenção se dispersa. Começam então algumas conversas paralelas que acabam atrapalhando o andamento da reunião.
O ideal, é claro, é que não houvessem tarefas dependentes entre si em uma história. Mas isso é muito díficil, e segundo minha breve experiência com Scrum, e nesse ponto ela se resume a apenas alguns poucos projetos web, me parece ser impossivel. Como exemplo posso mostrar três tarefas que foram presentes na maioria das histórias dos projetos que participei e que são dependentes entre si:
1- Criar design
2- Criar html e css estático
3- Implementar camada de visualização
A tarefa 2 depende da tarefa 1, e a tarefa 3 depende da tarefa 2. É claro que seria possível paralelizar a tarefa 3 com a 2, fazendo com que a implementação da camada de visualização fosse apenas de um html tosco. Mas mesmo assim seria necessária uma quarta tarefa para fazer o merge do html bonito com a camada de visualização, e esta nova tarefa seria enfim dependente da tarefa 2.
Ou seja, não vejo como paralelizar todas elas. E cabe aqui uma brecha para colaboração dos leitores no caso de terem encontrado alternativas, ficaria feliz de conhecê-las. De qualquer forma, existem outras situações específicas de cada empresa e de cada time que elevam mais ainda o número de dependência entre as tarefas.
Eis então que presenciei em outro time uma boa adaptação da reunião diária. Ao invés de cada membro do time responder as três perguntas, um em seguida do outro, os membros dizem primeiro o que fizeram, uma após o outro, depois dizem o que pretendem fazer, um atrás do outro, e ao final o que os impede, também da mesma forma.
Com isso o time resolveu de maneira simples um problema que parece não ter solução, sem sacrificar a reunião diária, pois todos saem dela sabendo o que fazer, o que já está pronto e quais são os impedimentos do projeto. Cumprindo exatamente o propósito dela.
O ideal, é claro, é que não houvessem tarefas dependentes entre si em uma história. Mas isso é muito díficil, e segundo minha breve experiência com Scrum, e nesse ponto ela se resume a apenas alguns poucos projetos web, me parece ser impossivel. Como exemplo posso mostrar três tarefas que foram presentes na maioria das histórias dos projetos que participei e que são dependentes entre si:
1- Criar design
2- Criar html e css estático
3- Implementar camada de visualização
A tarefa 2 depende da tarefa 1, e a tarefa 3 depende da tarefa 2. É claro que seria possível paralelizar a tarefa 3 com a 2, fazendo com que a implementação da camada de visualização fosse apenas de um html tosco. Mas mesmo assim seria necessária uma quarta tarefa para fazer o merge do html bonito com a camada de visualização, e esta nova tarefa seria enfim dependente da tarefa 2.
Ou seja, não vejo como paralelizar todas elas. E cabe aqui uma brecha para colaboração dos leitores no caso de terem encontrado alternativas, ficaria feliz de conhecê-las. De qualquer forma, existem outras situações específicas de cada empresa e de cada time que elevam mais ainda o número de dependência entre as tarefas.
Eis então que presenciei em outro time uma boa adaptação da reunião diária. Ao invés de cada membro do time responder as três perguntas, um em seguida do outro, os membros dizem primeiro o que fizeram, uma após o outro, depois dizem o que pretendem fazer, um atrás do outro, e ao final o que os impede, também da mesma forma.
Com isso o time resolveu de maneira simples um problema que parece não ter solução, sem sacrificar a reunião diária, pois todos saem dela sabendo o que fazer, o que já está pronto e quais são os impedimentos do projeto. Cumprindo exatamente o propósito dela.
Assinar:
Postagens (Atom)