From Vision Statement to Product Backlog

Foi publicada no SlideShare a apresentação que fiz dia 14/05/2009 no Scrum Gathering Brazil. Faça o download dos templates da Project Story e do Product Scope do http://www.scribd.com/parzianello.

From Vision Statement to Product Backlog

View more presentations from Luiz cláudio Parzianello.

Scrum é um framework?

Segue mais um email para a lista Scrum-Brasil que acredito ter se tornado um post para este blog! Ele inicia com a pergunta do colega Rodrigo Yoshima: Quando dizemos Scrum é um Framework, o quenecessariamente queremos dizer com isso?

Vou tentar dar uma pequena contribuição para esta discussão ... ;-)

1. Scrum é um método de gerenciamento de projetos;
2. Tipicamente, de projetos de desenvolvimento de produto (Product Backlog);
3. Scrum tem como foco principal a entrega de valor para o cliente (Product Owner);
4. Para tanto, explora a auto-gestão da equipe (Scrum Team);
5. A equipe deve manter altos níveis de comunicação e colaboração;
6. Scrum é baseado em muitos princípios e práticas do Lean Thinking;
7. Por essa razão, exige um fluxo de valor do tipo Just-in-Time (JIT);
8. Por ser JIT, trabalha com pequenos intervalos de produção (Sprints);
9. Devido a isso, faz entregas frequentes com estoques reduzidos;
10. Por ter estoques reduzidos, traz os problemas à tona;
11. Uma vez que problemas podem surgir, um líder deve procurar contorná-los (Scrum Master);
12. Os problemas são discutidos diariamente com a equipe (Daily Scrum);
13. Bem como a evolução do produto (Burndown Chart);
14. O produto evolui de forma dinâmica, de acordo com os interesses do cliente (Sprint Backlog);
15. E equipe se compromete com os resultados do projeto (Sprint Planning);
16. Os resultados obtidos são avaliados durante as entregas parciais do produto (Sprint Review);
17. E uma análise crítica dos resultados é feita após cada entrega (Restrospective);
18. E todo o processo reinicia até chegarmos ao produto desejado.

Por que eu escrevi esses 18 pressupostos? Porque muitos deles são diretrizes para o planejamento do meu processo de desenvolvimento. O Scrum não é um método prescritivo ao extremo, como é o RUP, que entrega até os templates de como você deve escrever cada artefato. Tanto um quanto o outro eu posso considerar como frameworks de processo, dado que a instância de cada um será diferente em cada empresa onde eles forem implantados. No entanto, tanto um quanto outro não abrem mão de suas diretrizes "obrigatórias", como no caso do Scrum com: Sprint de prazo fixo (2 a 4 semanas), um único Product Backlog (que muita gente ainda desconhece o poder de uma User Story), Daily Meeting (que muita gente não faz), Sprint Planning e Review (que muita gente não sabe como conduzir), Retrospectives (que muita gente não tem no sangue a melhoria contínua), Burndown Chart (que muita gente ainda tem alergia a métricas e indicadores de desempenho). Nestes itens, não há flexibilidade. A flexibilidade que existe é na exploração do processo criativo para o desenvolvimento do melhor produto, no melhor tempo e no melhor custo, a fim de atender as necessidades de meu cliente.

Ou seja, da mesma forma que um framework MVC tem dentre suas diretrizes obrigatórias a construção das classes GUI na estrutura V do modelo (se você colocar no M vai deturpar o modelo e prejudicar a manutenção e o controle do sistema), o Scrum possui essas características. Se seu sistema foi desenvolvido com base nesse framwork (MVC), mantendo total aderência às suas diretrizes obrigatórias, pode-se dizer que o sistema é uma instância do modelo MVC. Se seu processo de desenvolvimento de software foi planejado com base no framework Scrum, mantendo total aderências às diretrizes obrigatórias, pode-se dizer que o processo é uma instância do modelo Scrum. Conclusão: o Scrum é um framework!

Brazil Scrum Gathering 2009

Pessoal! Estarei na próxima semana apresentando um trabalho inédito no Brazil Scrum Gathering 2009, em São Paulo. Nele, vou apresentar, pela primeira vez, um modelo de "Project Story" que estou concebendo para definir de forma rápida e efetiva o escopo de um projeto de software. É uma idéia que tem dado certo de trabalhar com um template de Project Charter com estruturas semelhantes à User Story.

Espero vê-los por lá!!
--------------------------

RESUMO DO TRABALHO
From Vision Statement to Product Backlog:
An Effective Way to Quickly Develop Project and Product Requirements

Wednesday, 13 May 2009 from 11:15 to 12:30

Product Backlog (PB) is a high-level description about what have to be done in a project performed with Scrum. It is well known that PB has to be written (or specified) by the Product Owner (PO), who knows the business rules and what software requirements have to be developed. The problem in this case is that sometimes neither PO nor team members know how to structure a mind process to develop project and product requirements. A systemic view of the business context and the NLP S.C.O.R.E. Model can help a Scrum team to quickly develop a useful PB based on User Stories. In this talk, we will show how to combine these assumptions to develop in PO and team members new communication skills for better working with software requirements.

TOPIC:

Most Neuro-Linguistic Programming (NLP) is oriented around defining a present state and a desired state, and then identifying and applying a technique that will hopefully help someone get to their desired state. The S.C.O.R.E. Model enriches that description by adding a few more simple distinctions. The letters stand for Symptoms, Causes, Outcomes, Resources and Effects. These elements represent the minimum amount of information that needs to be addressed by any process of change. We will show how to think about software as a “resource” that provides desirable “effects” in a business environment, improving process “outcomes” by eliminating the “causes” of undesirable “symptoms”. The User Story framework showed to be powerful when developing a PB based on these assumptions.

OBJECTIVES:

1. How to use a systemic view (process thinking) to understand the project scope?
2. How to use the S.C.O.R.E. Model to write a simple and powerful business plan for the project?
3. How to challenge software requirements with the User Story framework?