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?

Fwd:Curso Certified ScrumMaster – CSM (Recife) - Estarei lá! =)

Nos dias 18 e 19 de março no Recife Praia Hotel (www.recifepraiahotel.com.br) vai acontecer o Curso Certified ScrumMaster. O curso será ministrado por Michel Goldenberg.

Neste treinamento de dois dias você não somente conhecerá os fundamentos do Scrum, mas terá experiências hands-on usando Scrum. Este treinamento coloca a teoria em ação através de várias atividades práticas que simulam em sala de aula o funcionamento do Scrum.

Durante o treinamento, os participantes irão entender como um simples – mas eficiente – processo como Scrum pode transformar os resultados de uma empresa. Os participantes deste treinamento irão adquirir experiência com as ferramentas utilizadas no Scrum e em atividades ligadas a Product e Sprint Backlogs, Daily Meetings, Sprint Planning Meeting, Review, Retrospectives e Burndown charts. Irão também aprender como aplicar Scrum em diversos tipos de projetos, do single collocated team ao time distribuído em ambiente off-shore.

Essa formação está sendo organizada pela Goto Serviços Tecnológicos. O valor do curso é R$ 1500,00 no early bird (até 3 semanas antes do curso) ou R$ 1900,00, após as 3 semanas. Esses valores podem ser pagos por boleto bancário em até 3 vezes ou por depósito bancário ou cheque à vista.

Para saber mais sobre o processo de certificação de Scrum, por favor, consulte http://www.scrumalliance.org/scrum_certification

Detalhes

Data: 18 e 19 de março (08h00 – 18h00)

Carga Horária: 16 horas

Local: Recife Praia Hotel – Av. Boa Viagem, N° 9, Pina, Recife – PE

Valor: R$ 1500,00 no early bird

Valor: R$ 1900,00 após o early bird

Oferecemos: Almoço e coffee break

Idioma: Português

Instrutor: Michel Goldenberg

Contato:

Alexsandro Marques – alexoliveira.marques@gmail.com

Fernanda – fernanda.goto@gmail.com

Sobre o Instrutor:

Michel Goldenberg é co-fundador do Grupo de usuário Scrum de Montreal, um dos maiores grupos de usuários Scrum do Canadá. Michel vem divulgando o Framework Scrum na comunidade de Montreal e pelo mundo através de palestras e treinamentos. Além disso, Michel presta consultoria e é Agile Coach em grandes empresas no Canadá.

Com mais de dez anos em TI e cinco anos trabalhando em projetos Scrum, Michel Goldenberg foi percebendo aos poucos os motivos que atrapalhavam a aceitação de Scrum dentro das empresas, e concluiu que o motivo principal era os erros de planejamentos.

O que diferencia os consultores é a paixão verdadeira por suas atividades. Michel tem uma paixão especial pelo Agile Estimating and Planning, em criar times unidos e bem balanceados, e maximizar o ROI (Retorno de Investimento) dos projetos nos quais ele trabalha como Coach e aonde vem ajudando muitos times a reerguerem e retomarem projetos considerados de insucesso até sua atuação.

Para maiores informações, consulte:

http://twitter.com/Michel_Golden
http://ca.linkedin.com/in/mgoldenb
http://www.scrumalliance.org/profiles/38596-michel-goldenberg

--
Atenciosamente,
Alexsandro Marques, CSPO
www.alexsandromarques.wordpress.com