Essa leitura que recomendo, é um negocio sem tamanho, uma historia sem fim! E pior que faz parte do meu universo...
Li empolgada, Dooooooooooida pra mostrar pra minha chefa e gerar uma reunião com todo mundo.
Mas... procrastination. Eles nao me querem pra nada desse tipo por aqui :P
http://www.infoq.com/br/news/2011/05/agile-setor-publico
enjoy!
Showing posts with label scrum. Show all posts
Showing posts with label scrum. Show all posts
Monday, October 22, 2012
Wednesday, December 01, 2010
Aumento de produtividade por ponto de complexidade
Ótimo post (sorry o copy-paste, mas gostaria muito te ter isto guardado aqui!): http://programandosemcafeina.blogspot.com/2010/08/aumento-de-produtividade-por-ponto-de.html
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?
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?
Friday, October 30, 2009
uma dia qualquer de QA no scrum...
Ok, vamos lá analisar a situação de um projeto que auditei:
Cheguei no ambiente do projeto, perguntei em que sprint estavam, e o time não soube responder (vai terminar a #2? Já terminou a #3?).
Teve retrospectiva recentemente de que sprint? Não souberam, responderam que foi da #2. Era da #3!
Oficialmente, pelo wiki e registros feitos pelo gerente, estão com a sprint #3 finalizada (de 21/09 á 02/10)
Ainda tem post-it da sprint #2 no taskboard.
Não tem apontamento de horas.
Gráfico burn-up? Ninguém tocou nele. Sò tá o 'esqueleto'.
Acompanhei um review da equipe, onde problemas muito bobos foram levantados como bugs (internos no caso).
Hoje vi apenas um área do ‘rip’...além de relatos que o projeto não sofre atualização no ambiente de produção a mais de 3 sprints,por ‘medo de bugs’ mais pesados... Equipe relaxada, desenvolvendo sem motivação, perdendo tempo com retrabalho em bugs bobos internos.
E quantos pontos entregues nessa finalizada sprint #3? Ninguém presente sabe responder. "Vê na ata" me falaram;
O time não acompanhou seu próprio desempenho, apontando sempre ‘pergunte ao gerente’... Cadê aquela equipe auto-gerenciável? Que faz as atividades (reuniões, gerar baseline, atas, arruma eventum) mesmo sem scrum-master por perto?
Isso me é preocupante. O Scrum parece que não tá rolando direito...
Resultado: NC´s de tudo que é tipo!
Mas esta bagunça, que se repete em mais de um projeto, tem uma explicação.
Ou vocês acham que só SCRUM salva?
Neste caso, a bronca vem 'lá de cima'.Depois falo mais sobre isso.
Cheguei no ambiente do projeto, perguntei em que sprint estavam, e o time não soube responder (vai terminar a #2? Já terminou a #3?).
Teve retrospectiva recentemente de que sprint? Não souberam, responderam que foi da #2. Era da #3!
Oficialmente, pelo wiki e registros feitos pelo gerente, estão com a sprint #3 finalizada (de 21/09 á 02/10)
Ainda tem post-it da sprint #2 no taskboard.
Não tem apontamento de horas.
Gráfico burn-up? Ninguém tocou nele. Sò tá o 'esqueleto'.
Acompanhei um review da equipe, onde problemas muito bobos foram levantados como bugs (internos no caso).
Hoje vi apenas um área do ‘rip’...além de relatos que o projeto não sofre atualização no ambiente de produção a mais de 3 sprints,por ‘medo de bugs’ mais pesados... Equipe relaxada, desenvolvendo sem motivação, perdendo tempo com retrabalho em bugs bobos internos.
E quantos pontos entregues nessa finalizada sprint #3? Ninguém presente sabe responder. "Vê na ata" me falaram;
O time não acompanhou seu próprio desempenho, apontando sempre ‘pergunte ao gerente’... Cadê aquela equipe auto-gerenciável? Que faz as atividades (reuniões, gerar baseline, atas, arruma eventum) mesmo sem scrum-master por perto?
Isso me é preocupante. O Scrum parece que não tá rolando direito...
Resultado: NC´s de tudo que é tipo!
Mas esta bagunça, que se repete em mais de um projeto, tem uma explicação.
Ou vocês acham que só SCRUM salva?
Neste caso, a bronca vem 'lá de cima'.Depois falo mais sobre isso.
Subscribe to:
Posts (Atom)