Agile - Spikes e a linha do tempo geral

A equipe está começando em seu primeiro projeto A-Agile de capital, e o projeto parece estar alinhado com a metodologia (ou seja, provavelmente podemos apenas pegar um livro ágil e segui-lo como uma receita), com um pouco de confusão:

O projeto envolve três aspectos com os quais ninguém da equipe tem experiência: Integrar-se ao Foo Payroll System, poder lidar com o tipo de arquivo XYZ89 (onde "XYZ89" = algum tipo de arquivo que você nunca ouviu falar) e converter alguns outros arquivos para que possam ser manipulados pelo Frobnobdicator.

Pelo que entendi, a prática padrão do Agile seria agendar picos para cada um deles, após o qual podemos determinar quanto tempo eles levarão (não tenho certeza de que há muita chance de o cliente decidir não fazer eles, já que são requisitos bastante sólidos do projeto)

Então, minhas perguntas são:

1. Fazemos todos os picos na frente na primeira iteração para obter uma estimativa melhor do tempo que levará para fazê-los e / ou obter um "esqueleto ambulante" em funcionamento?

2. Caso contrário, o cronograma total do projeto não ficaria à mercê de um desses picos voltando com dados de que essa história em particular levará muito mais tempo do que nós estacionamos?

Qual é a melhor maneira de lidar com vários picos quando eles são basicamente requisitos não negociáveis ​​de um projeto?

A maneira como lidei com essas incógnitas obscuras no meu plano de projeto antes é tentar e configurar o tempo para a equipe de desenvolvimento fazer protótipos da funcionalidade desconhecida antes. Isso oferece o benefício de tornar claro o que será necessário para executar as tarefas especializadas, provar que elas são tecnicamente viáveis ​​e educar o restante da equipe sobre as possíveis armadilhas a serem evitadas quando o desenvolvimento ativo começar.

É por isso que muitos projetos Agile geralmente começam com um, o que eu gosto de chamar, Sprint 0 .

Pense nisso como amarrar seus tênis de corrida, alongar e colocar bandaids nos mamilos antes de começar uma maratona. Esse tempo pode ser usado para fazer o planejamento inicial do projeto e a criação da história do usuário, o lançamento da arquitetura e do design, a criação da estrutura de software e os desenvolvedores podem trabalhar em quaisquer protótipos e provas de conceitos para qualquer nova tecnologia ou desafios técnicos desconhecidos que farão o ponto da história do usuário estimativa muito mais fácil.

Você deve fazer as coisas na ordem da prioridade definida pelo proprietário do produto (ou cliente). Não faz sentido se matar por algo que é realmente bom de se ter. A idéia é que, se você ficar sem tempo e algo não for feito, deve ser o item de menor prioridade.

Se eles não priorizarem o que querem, você estará lutando.

Se as coisas forem relativamente iguais, não comece com o item mais difícil - comece com uma vitória fácil, que dará à equipe a chance de se acostumar a trabalhar juntos usando a nova metodologia e ao cliente certa confiança de que eles podem entregar as coisas dessa maneira. Uma vez estabelecido, lide com algo difícil. Avalie a complexidade do item difícil com a complexidade das coisas mais fáceis que você acabou de fazer e você começará a ter uma idéia de quanto tempo pode demorar para passar por isso.

Itens complexos não são realmente "picos". São simplesmente coisas que exigem mais esforço para descobrir. Divida-os em tarefas mais simples, tanto quanto possível.

Uma solução possível é criar uma tarefa para fazer uma prova de conceito para descobrir como resolver o problema e cronometrá-lo, e depois adicionar essa história a um sprint com outras histórias.

Você ainda está entregando valor e um produto no final do sprint, mesmo que seja um aplicativo de console de hackers. A idéia é que você não está afundando a produtividade de toda a equipe; se ficar sem tempo, você adiciona outra tarefa semelhante ao próximo sprint.