Início > Scrum > Organizing a Scrum Team

Organizing a Scrum Team

O segundo capítulo do livro “Professional Scrum with Team Foundation 2010” trata de como organizar e qual o papel de cada profissional dentro de a equipe.  São eles:

    • Product owner – responsável por determinar as características / módulos do sistema e como deve funcionar
    • ScrumMaster – gerente de projeto, coordenador, responsável pela produtividade, entregas, comunicação.
      As duas principais tarefas dele é certificar-se da produtividade da equipe e dar feedback através dos release.
      Tarefas: fazer as reuniões diárias, envolver as pessoas necessárias, forçar a comunicação, determinar o tamanho do time.
    • TeamMembers – responsáveis por desenvolver/testar o sistema

    O capítulo comenta bastante sobre com coordenar o “Daily Scrum” todos os dias. A reunião diária deve ser para aquecer a equipe e forçar todos a lembrar o que está sendo desenvolvido, porque, e para que. Nesse momento cada profissional do time deve falar. Isso força o próprio desenvolvedor a se concentrar no que está fazendo e quais as suas atividades para aquele dia. O ScrumMaster deve organizar qualquer trabalho que esteja travando o desenvolvimento de alguma tarefa. Questões técnicas podem ser resolvidas na própria reunião ou durante o dia em conversar com os desenvolvedores. Questões de escopo, dúvidas de regras de negócio devem ser tratadas pelo ScrumMaster. Não que ele tenha que saber responder todas as questões, mas é responsável por correr atrás da solução, procurar o Product owner para discussões, etc.

Especificar e priorizar características a serem desenvolvidas são um trabalho do product owner. Ele escreve o que é chamado de “User Stories”, que são pequenas descrições das funcionalidades que o produto precisa ter. Internamente a equipe cria os products backlog itens (PBIs) que são pequenas tarefas a serem desenvolvidas.
Fala-se sobre a “Prioridade das tarefas” vs “Valor de negócio (Business Value) vs Esforço”. A prioridade das tarefas é diferente do valor de negócio. Uma tarefa pode ser imprescindível, mas só pode ser desenvolvida nos últimos sprints pois depende de outras tarefas. E também é diferente da dificuldade e esforço necessário para entregar cada uma das tarefas.

Uma coisa que achei bem interessante e que gera bastante discussão é como é organizada uma equipe com Scrum. Normalmente são equipes pequenas, com poucos desenvolvedores, 1 ScrumMaster e 1 Product Owner. Mas isso não é uma regra. Podem existir mais de 1 Product Owner na equipe, cada um com uma responsabilidade. Por exemplo, um responsável pela área de Marketing e outro na área Comercial.
Em grandes projetos, pode-se criar várias pequenas equipes (que contém 1 ScrumMaster, 1 Prodcut Owner e os membros da equipe). A melhor forma de separar em várias equipes segue a seguintes prioridades:

    • Separar por característica
      • Vantagem: Reduz a dependência entre outros times, foca em desenvolver as características do projeto, promove aceitação de testes.
      • Desvantagens: Solução da arquitetura e design podem se perder durante o processo, aumentando o custo de suporte e cada time precisa “reinventar a roda”
    • Separar por preocupações transversais(Ex: um time cuida do desenvolvimento do cache de objetos, outro da segurança do sistema):
      • Vantagens: Reduz o custo e aumenta a qualidade técnica do projeto, promove arquitetura consistente das features.
      • Desvantagens: Não é uma divisão boa para o cliente, time não consegue visualizar o escopo geral do projeto, necessita definir a interface primeiro, mudanças são custosas.
    • Separar por tecnologia
      • Vantagens: Maximiza habilidade do especialista/desenvolvedor, promove testes unitários dentro de cada tecnologia.
      • Desvantagens: Aumenta a dependência entre as equipes, ninguém é responsável pelas entregas de funcionalidades, cada equipe está focada em entregar a sua parte, mas não presta atenção na complexidade técnica do produto.

Depois de toda essa separação em várias equipes, é necessário organizar a comunicação entre elas na “Scrum of Scrum Meeting”. É uma reunião aonde podem participar um membro de cada equipe que tenha capacidade de dar o feedback sobre o andamento das atividades. Não necessariamente precisa ser o ScrumMaster.

Quando existem várias equipes, cada uma delas tem seus próprios sprints. Mas lembrando que normalmente ela depende de trabalhos e entregas de outras equipes, então o trabalho precisa ser muito bem coordenado. Uma coisa que o capítulo não comentou é como organizar para que isso ocorra sem maiores problemas. E o mais importante… como gerar Releases entregáveis para o Product Owner??? Essa é uma boa discussão, não!?

Então existe uma grande comparação entre os papéis/responsabilidades entre SCRUM e MSF. Em resumo, como é possível perceber, o SCRUM tem equipes menores e existe mais responsabilidade. Ou seja, é necessária uma equipe com mais conhecimento. O MSF tem responsabilidades bem definidas e separadas, aonde existe uma equipe de testes/QA, o papel do Gerente de Projeto se compara ao PMI. Não vou entrar em detalhes, mas as comparações no livro são muito bem organizadas.

Trechos do livro que grifei:

“The ScrumMaster has two primary responsibilities: ensure team productivity and tracking  Project status through release. These are not easy task, but when treated as top-line job  responsibilities, they are quite achievable.”

“The product owner is responsible for ensuring that product features meet customer expectations. The product owner can be a leader in the user community, someone from marketing, a business analyst with the IT arena, or any other individual who can effectively communicated business needs.”

“The primary responsibility of the team members is to build the product. They determines the architecture, component design, and user experience. They work within boundaries of time and coast and are empowered to make trade-offs to build the best possible product within those limits. Both development and testing occur within the team. Because is no separate QA group, the team members are both empowered and responsible for their own testing.”

“Four resources are required to ship great software: time, money, people an technology.”

“The architect role, regardless of project management methodology , is to manage the complexity of component parts of the system. Developers write the code, but the architect must be able to see the forest for the trees. ”

 Abaixo achei uma charge sobre equipes de SCRUM… hehehe..

Anúncios
Categorias:Scrum
  1. Nenhum comentário ainda.
  1. No trackbacks yet.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: