KANBAN prático e eficaz!

Apresentação de Rodrigo Yoshima (blog dele aqui), muito boa sobre práticas de Kanban.

Para quem está vendo Lean e TOC, a identificação com os conceitos é imediata… aliás é tudo farinha da mesma fungada!!rsrrs!!

Mapeando o SCRUM no CMMI

A demanda de documentação requerida pelo modelo CMMI com certeza faz frente a idéia da agilidade adquirida do Scrum quando tratando-se da gestão do desenvolvimento de software.

As críticas feitas entre os dois posicionamentos são normalmente que:

• Abordagens ágeis são criticadas devido ao fato de apresentarem muito pouco design de arquitetura e pouca documentação.
• Abordagens rigorosas são criticadas por serem burocráticas e serem de difícil adaptação à mudança.

Devemos sempre ter em mente que o modelo CMMI descreve “o que fazer”, enquanto a práticas de gestão ágil, como o Scrum, descrevem “o como fazer”.

Deixando de lado as entrelinhas temos os 2 contra-pontos:

Modelo de Maturidade e Excelência (CMMI): enxerga todo e qualquer processo dentro da empresa como sendo capaz de evoluir (amadurecer) de forma que a organização aprenda com seus próprios erros e acertos, para isso é necessário seguir uma série de práticas, normas e regras para alcançar os níveis de excelência estabelecidos através de métricas bem definidas, isto não leva em consideração o tempo nem os recursos gastos para o preenchimento, análise e gerenciamento destes documentos.

Prática de Gestão Ágil (Scrum): viabiliza técnicas e processos de gerenciamento para que seja cumprido o objeto do projeto de maneira mais eficiente possível atingindo o máximo de expectativas do cliente com relação ao atendimento de requisitos. Na maioria das vezes os projetos são tão velozes que não há tempo hábil entre um projeto e outro para que haja o aprendizado da organização.

Isso não quer dizer que seja impossível adotá-las em conjunto. Simplesmente é uma questão de adaptar as necessidades estabelecidas pelo CMMI (ações e documentação) de modo que não interfiram no modo como deveremos executá-las (práticas doScrum).

Não estamos apenas focados no Scrum, outras metodologias ágeis como o TDD, FDD e XP podem ser conectadas aos processos do CMMI. Segue abaixo uma tabela comparativa das áreas de processo do CMMI e quais são satisfeitas por cada uma dessas metodologias.

Artigo original em Inovatividade

Tutorial Instantâneo de SCRUM

Nada melhor do que explicar uma abordagem ágil de gestão de formal ágil… então iremos do vocabulário básico para dinâmica  e logo depois a aplicação. Assim rapidamente você poderá experimentar o uso prático do Scrum em seus projetos.

Vocabulário Básico Scrum

Antes de ser capaz de implementar Scrum, é importante estar familiarizado com algumas palavras-chave no vocabulário do Scrum.

• SPRINT: esforço concentrado de aproximadamente 15~30 dias (a ser ajustado de acordo com o projeto) com a equipe focado na resolução das metas fixadas.

• PRODUCT BACKLOG: lista de tarefas com prioridades constantemente revisadas.

• SPRINT BACKLOG: lista dos itens de mais alta prioridade proveniente do product backlog, a serem realizados durante 1 sprint

• SCRUM MASTER: é o mantenedor da dinâmica scrum na equipe e responsável por garantir a realização dos objetivos do sprint através da remoção de obstáculos que estejam impedindo o avanço da equipe.

• PRODUCT OWNER: é a personificação do cliente e é responsável por priorizar o product backlog.

• SCRUM TEAM: um grupo de 09/05 pessoas que se auto-organizam e têm uma responsabilidade conjunta para as tarefas concluídas.

O Processo Scrum

Esta é a figura típica que representa o processo Scrum:

Agora vamos detalhar o processo básico passo-a-passo.

1. Criar o Product Backlog - O Product Owner forma a visão do produto, gerando uma lista de tarefas macro que juntamento com o Scrum Team são mapeadas e priorizadas de acordo com a importância de cada funcionalidade para o product owner.

2. Sprint Planning Meeting – após a criação do backlog, faz-se a primeira Sprint Planning Meeting, para realizar o planejamento do sprint. Na primeira fase da reunião, o owner descreve os objetivos do projeto e junto com a equipe seleciona do Product Backlog as tarefas macro que irão fazer parte do Sprint e quanto tempo este deverá durar.

3. Criar Sprint Backlog – Uma vez que os itens a serem trabalhados foram selecionadas, uma programação Sprint potencial é construída, tendo em conta a disponibilidade dos membros da equipe para dedicar seu tempo ao projeto. As tarefas macro são decompostas em tarefas técnicas realizáveis e individuais, este é o Sprint Backlog.

4. Início do Sprint – o sprint começa hoje e dura entre 15~30 dias, de acordo com o programado no sprint planning. Durante o Sprint, outras tarefas são adicionados ao backlog do sprint de acordo com a necessidade.

5. Executa-se o Daily Scrum – após o início da corrida, a cada dia teremos o Daily Scrum, é uma reunião de 15 minutos em pé no meio da equipe (stand-up meeting), onde cada membro da equipe dá um breve relatório para todos os outros sobre:

1. O que realizou desde o DailyScrum passado
2. O que eles esperam realizar
3. Problemas encontrados

O Scrum Master fará nota das questões e tentará remover os obstáculos encontrados, após a reunião.

6. Sprint Review – uma vez que a Sprint termina, todos se reunem para compartilhar o que foi realizado durante o sprint.

7. Retornar ao Sprint Planning até o fim – O processo começa novamente com uma nova lista de tarefas priorizadas, ainda não realizadas vinda do Product Backlog, faz-se o novo Sprint Planning Meeting e continua até o fim de todo o product backlog, isto é, retorne ao passo 2.

Este breve resumo do processo de Scrum é suficiente para começar a aplicar Scrum.

São necessários poucos templates de documentos para a execução dos projetos, como Scrum Product Backlog, Sprint Backlog,  Você pode planejar recursos, tempo e as estimativas de itens individuais do Product Backlog com o Microsoft Project ou outro instrumento de planeamento.

Acerte na coleta de Requisitos (com uma idéia vinda do Scrum)

Coleta de requisitos… assunto que sempre vigente nas rodas de samba dos gerentes de projetos e clientes de todo mundo! Saiba que 60 a 80% dos projetos estão diretamente ligados a falhas no levantamento, análise e gerenciamento dos requisitos (Fonte: Meta Group).

Uma boa prática que tenho adotado em meus projetos vem do Scrum, chama-se “User Stories”, mesmo quando não utilizo de técnicas ágeis integralmente, sempre trago esta parte de coleta de requisitos comigo debaixo do braço.

User Stories, traduzindo ao pé da letra já nos da uma boa idéia do que seria: “Estórias do Usuário”. É uma modo de coleta de requisitos onde escreve-se de forma simples e concisa, utilizando o vocabulário do cliente o que ele quer, com o máximo possível de detalhes. O sujeito, foco das estórias são sempre o usuário/cliente, sendo completamente proibido mencionar termos técnicos ou rebuscados neste momento

Duas dicas disfarçam acrônimos interessantes (em inglês) para as user stories:

INVEST in Good Stories

Independent, Negotiable, Valuable, Estimable, Small, Testable

• Cada User Storie deve ser, o máximo possível, independente de outras histórias.
• Aquilo que ela descreve deve ser perfeitamente negociável entre o fornecedor e o cliente (de fato, ela deve poder ser traduzida, posteriormente, em um plano de trabalho ou contrato de serviços).
• O cliente deve perceber o valor da User Story tanto como apoio à compreensão na construção da solução quanto na percepção do resultado de seu investimento na mesma.
• E cada história deve ser pequena e testável.

SMART Tasks

Specific, Measurable, Achievable, Relevant, Time-boxed

• Cada tarefa deve ser específica, contida em si, bem definida e também independente.
• Deve poder ser medida para que seu custo possa ser efetivamente avaliado.
• Obviamente, temos que definir tarefas que possam ser realizadas.
• Deve ser relevante à estória e, se na definição das tarefas, uma delas parecer não estar relacionada com a estória, então ela ou a estória devem ser revistas.
• Deve ter um período de tempo definido.

Algumas dicas de como produzir boas User Stories (extraídas do blog de David Churchville)

1. Make them customer-focused. The easiest way to do this is to have the customer write them. If this isn’t practical, then you’ll have to role-play. An example of a developer-focused story is “Add clustered index to the Orders table.” This doesn’t mean much to most customers, and a real customer (unless they are a DBA), would probably never write this. Instead, something like “Improve Order reporting performance”, captures the same information, but is understandable to everyone on the team.

2. Make them elevator-friendly. A good story should be something you could explain on an elevator in 30 seconds or so to a team member. Don’t write a novel. Remember, this is just a placeholder for more detailed conversations, not a specification or requirements document.

3. Make them the right size. Not too big, and not too small, just like Goldilocks said when she visited a tough bear hangout. For me, the right size is usually under 40 ideal hours (1 ideal week) of estimated effort. Small stories aren’t usually a problem, but if they get to be under an hour or so, you probably want to batch them up. Defects are usually good candidates for batching into a single story, as long as they are small and easy to implement.

4. Make them testable. An untestable story might be something like “Make the order screen easy to use.” It sounds nice, but no one really knows what this means, or how to objectively verify it. A better wording choice might be: “A novice user be able to load, enter information, and submit an order within 5 minutes.” Hmmm…still seems a little questionable, but I can probably write a test like “Given a sample group of 10, 8 of these users should be able to complete an order for a book in 5 minutes.”

Um exemplo bem simples feito pela Universidade Estadual da Carolina do Norte, descreve o projeto de desenvolvimento de uma máquina de café.

Um livro altamente recomendado é o do Mike Cohn: User Stories Applied.

Texto adaptado do blog Scrum – User Stories | Brod Tecnologia.