Ken Schwaber: Não conheço estudos específicos. Contudo, a questão do gerente de projetos tem sido vastamente comentada. O gerente de projetos pode se tornar um scrum master, um product owner, ou dentro de uma equipe Scrum. O papel de gerente de projetos não é parte do Scrum. O PMO normalmente se transforma para organizar o backlog do produto, tanto para os product owners quanto para as equipes de desenvolvimento. Apesar de não criar itens no backlog do produto (nem priorizá-los ou estimá-los), o backlog de produto tem várias facetas. Estas incluem o software de sistema, fluxos de trabalho, funcionalidades, decomposições e estruturas de negócio. Estas devem ser desenvolvidas e gerenciadas de forma que os product owners possam tomar as melhores decisões sobre qual o próximo item a ser feito.
Raazi Konkader (CSM): Os pontos de função (Cosmic por exemplo) são uma medida de tamanho/esforço valida no Scrum?
Ken Schwaber: Os pontos de função são uma medida de funcionalidade de software tão válidas no Scrum quanto em qualquer outro lugar.
Leonardo Campos: Onde trabalho, cada equipe é responsável por uma série de produtos diferentes. O PO normalmente prioriza histórias de cada um destes produtos em cada Sprint, tornando difícil criar uma meta decente de sprint. O PO simplesmente argumenta que as histórias são a meta (sem um propósito é difícil motivar). O que você pensa sobre este problema e qual você considera ser a melhor abordagem para tratá-lo?
Ken Schwaber: Eu trabalharia com o product owner para agrupar os backlogs dos produtos de forma que eles tratassem um objetivo de negócio ou estivessem na mesma área do software. Mostre para ele quanto seu trabalho seria facilitado, portanto a produtividade é maior, tornando o trabalho mais barato.
Leonardo Campos: O Kanban é projetado para ser muito pouco intrusivo e poder ser aplicado sobre outros frameworks, metodologias etc. Quão compatível você considera ser o Kanban em relação a sua aplicação com Scrum? Você consideraria viável ter uma "meta de sprint" em uma implementação de "Scrum-ban"?
Ken Schwaber: Não implemento Kanban por si só, de forma que não sei a respeito de metas de sprint.
O que eu realmente aprecio é usar o Kanban para ajudar equipes de desenvolvimento a aprender novas práticas, com raias como:
1. Desenvolver testes de aceitação
2. Desenvolver o design de projeto
3. Desenvolver testes automatizados, codificar e documentar
4. Testar de forma integrada para verificar se todos funcionam juntos
5. Corrigir a falhas
e por aí vai
Raazi Konkader (CSM): Quais são alguns indícios de que uma equipe seguindo as práticas, mas sem entender a teoria por trás de métodos ágeis com Scrum, XP ou Kanban? Como tratar isso de forma geral
?
Ken Schwaber: A equipe tem um problema e não sabe como melhor tratá-lo. Se você entende a transparência, ajuda as pessoas a atingir o melhor delas, e entende a arte do possível (todas atitudes que vêm do empirismo e Lean), você consegue tomar decisões muito boas. Caso você não as conheça, suas decisões não tem base e são frequentemente contra-produtivas.
Leonardo Campos: Você tem planos para vir ao Brasil nos próximos 12 meses?
Ken Schwaber: Não, não nos próximos 12 meses. Ainda estou me recuperando de toda comida que comi da última vez.
As raias mencionadas pelo Ken tem o mesmo objetivo de criar tarefas que deixem claro a criação de testes, documentação, criar design, etc. para cada estória, certo?
ResponderExcluirQuanto a meta do Sprint, para o cenário, quanto menor o Sprint mais fácil contornar o problema. Mas convencer o PO a agrupar os backlogs dos produtos, eventualmente priorzando uma história que entrega menos valor que outras "apenas" para permitir uma meta, precisa de muito argumento. O ganho de produtividade compensaria mesmo?
Abraço
As raias mencionadas tem apenas fundo didático, mas entendo que elas devam ser abandonadas assim que o time adote as práticas introduzidas.
ExcluirJá em relação à meta, sim um Sprint menor facilitaria, mas em compensação gera um overhead na quebra de histórias para que elas sejam pequenas o suficiente para ocupar o sprint e ao mesmo tempo serem todas terminadas DENTRO do sprint.
Quanto ao ganho, eu realmente não sei. Penso que não há de fato um estudo por parte dos POs em relação ao Business Value de cada história de forma a possibilidar a avaliar o custo/benefício de se agrupar as histórias.