Release Planning

Prática originária do Extreme Programming, ela pode ser bastante útil para a implantação de Scrum em sua empresa, principalmente para as empresas que possuem um cultura mais tradicionalista em gerenciamento de projetos.

Release Planning pode ser definido como: (Fonte)

Criação de um Plano de Projeto baseado nas expectativas do cliente juntamente com o histórico de desenvolvimento do produto. Planejamentos iniciais são necessariamente imprecisos: prioridades nem estimativas são sólidas, e até a equipe iniciar o trabalho não há como saber o quão rápido seguirão. Mesmo o planejamento para o primeiro release não será claro, e continuamente este plano será revisado pela equipe/cliente.

Integrando ao Scrum

Criando Roadmap do Projeto

Scrum é basicamente sobre fatos reais, não contos de fada. Assim, o Product Owner, interpretando o valor de negócio das funcionalidades, forças técnicas e restrições de mercado pode transcrever suas expectativas em um roadmap (Mapa de produto), para que possa preparar-se melhor na evolução do projeto.

Este roadmap será simples. Fornecerá deadlines e a priorização (em nível macro) necessária para criar o Plano de Release.

Meça o presente olhando para o futuro

Steve McConnell (9 Pecados Mortais do Gerenciamento de Projetos) fez uma interessante comparação:

Eu imagino um bom planejamento de projetos como dirigir à noite com as lanternas ligadas. Podem existir mapas que dirão como ir da Cidade A para a Cidade B, mas a distância que posso ver em detalhes através de meus faróis é limitada. Em projetos de médio ou grande porte, planejamento deve ser mapeado fim-a-fim cedo no projeto. Detalhamento e micro planejamento deve geralmente ser conduzido apenas algumas semanas por vez, e deve ser guiado na forma "just in time".

Interpete a citação acima da seguinte forma: Mantenha um pequeno plano sobre três Sprints à frente da atual. Revise este plano a cada Sprint Review para manter nítidas as suas intenções de curto e médio prazos. O product backlog, macro e priorizado por valores de negócio e criticidade, continuará existindo, estou apenas propondo um item a mais na sua incursão no Desenvolvimento Ágil.
Utilize os resultados do Sprint, Retrospectivas e o Sprint Planning para manter-se focado no estado real do projeto para determinar qual caminho seguir.


[]s

Technical debt -- Introdução ao Débito Técnico

Conceito

O termo descreve a obrigação que uma empresa adiciona a um projeto de software quando escolhe uma abordagem de desenvolvimento que permita um resultado rápido que aumentará a complexidade do software e que custará muito mais caro a longo prazo.

Inserido acidentalmente

Uma abordagem tecnológica não adequada ou o código inserido por um programador inexperiente. Este é o resultado não estratégico de um trabalho mal desempenhado. Pode ser criado, ironicamente, na tentativa de refatorar algum setor de código problemático sem o auxílio de mecanismos de verificações/validações.

Inserido intencionalmente

Ocorre com a decisão da empresa em favorecer conscientemente o resultado presente em detrimento dos ganhos futuros. Entre os exemplos mais comuns e mais preocupantes: “Se não entregarmos esta release no prazo, não haverá outra entrega”, ou ainda “se não esta features não for implementada, perderemos N clientes”. A escolha em deixar para o futuro a preocupação com a qualidade do código produzido é o principal motivo para a ampliação dos custos de manutenção.

Identificar o Débito Técnico

• Existe um único desenvolvedor capaz de tocar em “certas partes do código”

• Desenvolvedores não possuem confiança em estimar o esforço em realizar atividades

• A falta de validação/testes dificulda a confiabilidade no sistema. Desenvolvedores dificilmente garantem o funcionamento do sistema

• Inserções no sistema são feitas e entregues rapidamente, mas levam muito mais tempo para realmente estarem utilizáveis no sistema (retrabalho)

Aprofunde Conhecimento

• Technical Debt and the Design death - Part 1
• Technical Debt and the Design death - Part 2
• Technical Debt @ Agile Advice
• Technical Debt by Steve MacConnell
  

Cockburn e Use Cases

Lendo o blog do Tyner Blain me deparei com post comentando sobre a posição do Alistar Cockburn sobre Casos de Uso e desenvolvimento Ágil.

Entre as principais motivações para utilização de Casos de Uso:

1. The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users. It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation and timing. It is the first part of the completeness question.
2. The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.
3. The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.
4. The use case extension scenario fragments provide answers to the many detailed, often tricky business questions progammers ask: "What are we supposed to do in this case?" (which is normally answered by, "I don't know, I've never thought about that case.") In other words, it is a thinking / documentation framework that matches the if...then...else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.
5. The full use case set shows that the investigators have throught through every user's needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: "And is that everything?" She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)

Mas o mais importante desta leitura está a apresentação abaixo. Realmente me fez pensar um pouco sobre a forma que tratamos User Stories, e de que maneira, mudando-se o foco, poderíamos utilizar Casos de Uso para ampliar a visibilidade e o conhecimento de todos da equipe sobre o domínio da aplicação, e mais do que isso, de que maneira esta abordagem se encaixa ao Desenvolvjmento Ágil

Leitura Obrigatória número 4300

Download do Arquivo: Agile Use Cases