sábado, 12 de novembro de 2011

Perguntas e Respostas sobre Scrum




1.Scrum funciona somente para projetos pequenos?
O Scrum funciona para projetos de qualquer porte, desde que se dividam as entregas em sprints. Em projetos com sprints paralelos é importante aplicar o Scrum of Scrums.

2.O Scrum é aplicável somente ao gerenciamento de software?
Não, como qualquer outra metodologia é aplicável a outros tipos de projetos.

3.Como gerenciar um projeto com o escopo aberto?
O escopo não é aberto, é alterável. Os métodos de gerenciamento de projetos permitem alterações de escopo, desde que haja análise de impacto, replanejamento e aceite do cliente. Todo projeto está sujeito a alterações de escopo, isto depende tanto de fatores técnicos quanto externos ao projeto, como: mudanças de regras de negócio, leis ou a própria opinião do cliente.
No caso do Scrum, as alterações são feitas no planejamento do product backlog e refletidas nos sprints, a análise de impacto é realizada nas duas etapas e o replanejamento é visualizado através das “time boxes”.

4.Um método que permite alterações de escopo não tende a retardar indefinidamente o projeto?
É questão de realismo: É sabido que os clientes normalmente refinam seus requisitos ao longo do tempo, por isso é melhor ter um prazo alterável que um prazo irreal. Independente do método, não existe planejamento que não seja alterado ao longo da execução.

5.O Scrum permite definir uma data final para o projeto?
Ele permite que se tenha uma visão de data final através do “burndown graph”, o prazo vai sendo modificado ao longo da execução do projeto (diariamente) e cabe ao Scrum Master garantir o cumprimento do prazo de cada sprint.
Uma estratégia para alcançar um prazo específico é o dimensionamento dos sprints (mais curtos, mais longos, com maior ou menor quantidade de entregas ou de sprints).

6.Como gerenciar o prazo no Scrum?
A partir de uma lista de requisitos priorizados, geram-se sprints, que são blocos de tempo (time boxes) que os implementam. Desse modo pode-se planejar e acompanhar o prazo do projeto. Ex: Se existem 10 sprints de 1 mês, o projeto levará em torno de 10 meses para ser completado. Se houver alterações de requisitos que impliquem em aumento ou redução dos sprints basta projetar o impacto até o final do projeto.

7.Então, como estimar o custo de um projeto Scrum?
O custo de um projeto geralmente é uma composição de horas e aquisições. Estimam-se os custos das aquisições através de orçamentos, estima-se o total de horas e multiplica-se por um fator de custo da empresa.
No caso da estimativa de horas, existem métodos bastante utilizados no mercado, como: Opinião de especialistas, Pert, Estimativa análoga, paramétrica e planning poker. Além dos métodos especificos para a área de software como: linhas de código, pontos de função e pontos por casos de uso.


8.Que forma usar para fazer um contrato no Scrum?

As mesmas formas tradicionais são aplicáveis, com suas vantagens e desvantagens normais, são elas: Preço fixo, tempo e material e reembolso de custo.

9.É obrigatório ter uma equipe máxima de 12 pessoas?
É o que a teoria prega, pois facilita a integração da equipe e permite a agilidade. Também pela premissa de que um projeto grande demais deve ser quebrado em projetos menores, menos complexos e portanto mais fáceis de gerenciar. Se ainda assim a equipe for maior, é recomendável que se aplique o Scrum of Scrums.

10.É obrigatório que as pessoas estejam no mesmo local físico?
Segundo o Scrum sim. Se for impossível, é importante que ao menos na daily meeting estejam todos juntos.

11.Como lidar com terceirizados em uma equipe scrum, dado o problema de autoridade e diferenças de processo?
Os terceirizados precisam se adequar ao modelo da organização em relação a processos e permitir que o Scrum Master coordene a equipe sobre a equipe, já que são auto-gerenciáveis.

12.Se a equipe é auto-gerenciável, qual a importância do Scrum Master?
O Scrum Master faz o controle do escopo, da alocação da equipe, puxa o ritmo de trabalho e arbitra conflitos, se necessário. Ele também a porta de comunicação com Product Owner e alta gerência.

13.É realmente viável que a equipe escolha suas atribuições, dadas as diferenças de skill, ou é apenas idealismo?
É muito viável e o trabalho flui melhor, as pessoas se sentem importantes, pois podem tomar decisões e acabam ficando mais
motivadas e comprometidas.

14.O que é o Scrum of Scrums?
Em linhas gerais é uma organização que permite que um grande projeto seja executado utilizando-se o Scrum. Aloca-se um Scrum Master para o projeto todo e várias equipes abaixo, cada uma com seu Scrum Master definido.

15.Sprint: O que fazer se as atividades do sprint não terminarem dentro do mês?
Ao final do “time box”, entregam-se as funcionalidades que estiverem prontas, as demais voltam para o product backlog para serem repriorizadas.

16.Sprint: As alterações de escopo obrigatoriamente devem acontecer no planejamento do sprint?
Não, a alteração pode vir a qualquer momento, mas é replanejada no product backlog e não no planejamento do sprint, pois pode ser priorizada somente para um próximo sprint. Deve-se atualizar o product backlog sempre para manter a rastreabilidade.

17.Daily meeting: Qual o impacto de não se fazer daily meetings todos os dias?
Qual o impacto das pessoas estarem em
locais e horários diferentes? existe alternativa?
A daily meeting deve ser realizada diariamente. Os possíveis impactos são: perda do controle do trabalho e redução do comprometimento da equipe, pois não estarão explicando o que estão fazendo na daily meeting. A alternativa para problemas de horários e locais é a participação via tele-conferência.

18.Daily meeting: Quem pode levantar um impedimento? o scrum master? qualquer pessoa?
Qualquer pessoa envolvida no projeto a qualquer momento.

19.Daily meeting: O que fazer se não for possível resolver um impedimento?
Pausa o sprint até que seja resolvido?
Quando não for possível resolver um impedimento, deve-se partir para a próxima user story. Se impactar todo o sprint, o que é bem improvável, toda a equipe deve se mobilizar para resolvê-lo.

20.Retrospective: Quem faz e como funciona (na prática) a retrospective meeting?É o Scrum Master com a equipe inteira, para fazer um balaço dos prós e contras. O que for bom deve ser mantido (e ampliado) nos próximos sprints, o que for ruim, deve-se procurar as causas e evitar que aconteçam no futuro.

21.User stories: Como saber quantas horas vale cada user story, se o esforço depende da senioridade dos recursos que vou usar?
As user stories devem ser estimadas em story points através do planning poker, que mede a proporcionalidade entre os requisitos. Ao planejar cada sprint, a equipe pode oferecer suas estimativas em horas, cada um na sua senioridade.

22.User stories: Como comparar diferentes projetos se as user stories usam proporcionalidade entre requisitos?
Não se deve comparar projetos diretamente através das user stories, pode-se sim comparar pontos positivos, negativos e lições aprendidas.

23.Quais as principais diferenças entre o SCRUM e o PMBOK?
As diferenças são muitas!
O SCRUM utiliza um conjunto de princípios que o leva a controlar escopo, prazo e qualidade de forma “ágil”. Para que isso aconteça ele estabelece regras, cerimônias, artefatos e papéis, de modo que, sendo seguidos, levam as equipes a um melhor desempenho. O conceito de prazo é baseado em timeboxes, a comunicação é constante e a motivação da equipe é incentivada e monitorada.
O PMBOK tem uma proposta diferente, pois busca coletar boas práticas e associá-las a grupos de processo e áreas de conhecimento. É um arcabouço vasto de informações, técnicas e processos, que pode ser aplicado a projetos de qualquer tamanho, tipo e em qualquer cenário. Requer um monitoramento constante de vários parâmetros e não define “cerimônias”.

24.Daria para usar Scrum e PMBOK ao mesmo tempo?
Pela perpectiva do PMBOK seria possível, desde que fiquem claros alguns pontos:
- A documentação como Termo de Abertura não será utilizada;
- Um documento substituto a Declaração de Escopo será o Product Backlog;
- O gerenciamento do tempo será feito em timeboxes e não com técnicas de PERT/CPM, utilizará o Sprint Backlog e não um cronograma;
- Os custos poderão ser gerenciados apenas pelas horas de alocação da equipe, já que não se coletam horas gastas;
- etc
Já pelo lado do Scrum, não haveria o menor sentido adotar dentro de um sprint documentações do PMBOK, pois iria de encontro aos princípios da agilidade. Uma solução intermediária seria o PO “gerenciar o projeto” enquanto o SM gerenciaria o andamento de acordo com o Scrum.

25.Qual a diferença entre o Scrum Master e o Gerente de Projetos?
As perspectivas são um pouco diferentes, no SCRUM as atividades de gerenciamento são distribuídas entre PO, SM e ST (scrum team). No Scrum não existem certos controles como custos, riscos e nem definições sobre práticas, ex:
- O SM tem foco maior no gerenciamento da execução
- O PO gerencia escopo
- A qualidade é garantida e controlada por todos, em especial o PO
- Custos não são gerenciados
Já o Gerente de Projetos precisa planejar, gerenciar, monitorar e controlar as 9 disciplinas ao longo de todo o ciclo de vida do projeto.
Contribuição da professora Janice Firmo (@janicefirmo), gerente de projetos de software na IBM/SP.

Nenhum comentário:

Postar um comentário