XP vs Kanban: Desenvolvimento de Novos Produtos

Nossa situação

Eu e minha equipe está atualmente trabalhando em uma aplicação web nova linha de
negócios, e tivemos uma discussão hoje sobre o que o melhor processo Agile seria para
nosso esforço atual. Até sexta-feira passada, temos praticado Extreme Programming
(XP). Geralmente temos uma semana de duração iterações, começando nas manhãs de
sexta-feira e terminando nas noites de quinta-feira (para que fim de iteração tempo de
crise para atender o nosso compromisso de iteração não se enquadra em uma noite de
sexta-feira). Manhãs de sexta-feira têm que levantar, então a nossa retrospectiva, e, em
seguida, planejamos nossa próxima iteração. Sexta-feira passada decidimos
experimentar um processo Lean / puxar por uma semana. Esta manhã, no nosso stand-
up, eu estava tentando escolher entre trabalhar em uma história bastante grande que
estava no topo da nossa fila "Ready", que eu provavelmente não poderia ter terminado
até o final do dia, e uma pequena história logo abaixo que é mais viável para hoje Se
tivéssemos de continuar usando Lean / Pull, tendo a história semi-acabados no final do
dia não é um problema, mas se vamos voltar para o XP e de comprimento fixo de
iterações, eu preciso ter certeza de que não há trabalho em andamento pela EOD. Este
post é sobre o processo que decidimos usar e por quê.

Extreme Programming

Uma vantagem do XP sobre o Kanban é a nossa

percepção de que é mais fácil transmitir
estimativas aproximadas de um lote de trabalho
para a alta gerência.

Meu chefe (o CTO) rotineiramente se reúne com

o CEO e COO da nossa empresa pequena e eles vão discutir um produto estratégico
novo, ou um módulo bastante grande para ser adicionado a um produto já existente. Eles
vão escrever colaborativamente um conjunto de histórias, e em seguida, na sexta-feira
seguinte, a equipe de desenvolvimento se reunirão para dar uma estimativa aproximada
para cada uma dessas histórias (ou cada um dos "must haves" se há um monte de
histórias). Uma vez que fizemos isso, meu chefe vai dividir a soma das estimativas por
nossa velocidade semanais (a quantidade média de trabalho que completa por semana),
em seguida, multiplicar por um fator de risco, para produzir uma estimativa de quando
esse pedaço de trabalho ser feito, e que transmite de volta para a alta gerência. A
estimativa e o alcance que ela representa não estão gravados em pedra, e todo mundo
entende isso. Isto ainda tem valor para a alta gerência, porque eles podem optar por
cancelar ou adiar esse pedaço de trabalho se o seu valor esperado não é mais ou menos
proporcional ao esforço exigido. Além disso, ele serve como um sinal para saber se eles
devem ou não ser de brainstorming novos produtos estratégicos / modules, ou se
estamos ocupados o suficiente para que não vale a pena, enquanto para o momento.
Além disso, o compromisso de iteração em XP fornece um pouco de segurança em
saber que o trabalho atualmente em construção será feito até o final da semana, que
podem ser comunicados a outras partes interessadas, se solicitado.

Em um mundo ideal (ex. livro Agile / XP), que seria capaz de entregar os recursos mais
valiosos para a produção em uma iteração, gerar algum valor, e construir a partir daí. No
mundo real (ou no nosso mundo, em qualquer caso), há muitas vezes um conjunto de
recursos mínimo comercializável que devem ser concluídas para que um novo
aplicativo para entregar qualquer valor em seu contexto de negócios. Em nossos
negócios, nossos clientes estão ocupados e seletivos, então se você demonstrar algo para
eles que não faz as funções essenciais, que provocou o seu interesse, na melhor das
hipóteses: eles não vão usá-lo em seu estado atual. Na pior das hipóteses: eles vão
perder o interesse no novo produto e declínio dedicar ainda mais atenção a ele no futuro.
Outro fator que pode resultar em um traço mínimo comercializável set como este é um
esforço de marketing. Dado um orçamento de marketing fixo, você vai gastar os dólares
valiosos em execução que anúncio de página inteira em um jornal de comércio depois
que o produto teve apenas uma semana de desenvolvimento? Eu acho que
provavelmente seria imprudente na maioria das situações. Tudo isso certamente não é
para dizer que devemos voltar à cachoeira e decidir o escopo na frente, então o faça 'até
que é "feito", etc., mas apenas que como a maioria das coisas na vida, a seleção quando
a "lançar" um novo aplicação é um equilíbrio. Que deseja iniciar com o conjunto
mínimo de funcionalidade que realmente chamam a atenção do seu público-alvo, sem
fazer muito na frente que você precisa fazer uma tonelada de re-trabalho após ser
utilizados na produção e os usuários dizer-lhe tudo o que está errado com ele. O truque
é implementar A, B e C (se essas são as características que são absolutamente críticos)
sem tentar entregar D, E e F (a nice-to-haves), ao mesmo tempo. O problema é que o
esforço necessário para construir A, B e C muitas vezes leva mais de uma iteração de
tamanho razoável, no caso de uma nova aplicação.

Em suma, as iterações comprimento fixo usado em XP nos permitem oferecer

estimativas prazo valioso para a alta gerência, e eu não vejo uma maneira de contornar
isso em nosso contexto de negócios.

Kanban
Kanban é japonês para "placa" ou "outdoor". "Kanban é um sistema de sinalização para
acionar a ação. Como o próprio nome sugere, kanban historicamente utiliza cartões para
sinalizar a necessidade de um item. "( Wikipedia ) Temos na verdade, vindo a utilizar
uma placa de Kanban virtuais para um pouco de tempo agora, como no que é mais
simples de uso, é efetivamente semelhante ao XP estilo story-board (cartões de índice
preso em um quadro de ferro com imãs coloridos) que estávamos usando antes. O
processo de mudança a que me referi anteriormente é que nós brevemente
experimentado um sistema de tração, onde os nossos stakeholders e acrescentou
histórias priorizadas na fila de "pronto" à vontade, teoricamente, sinalizado por nossa
conclusão do trabalho. Nós tentamos isso em vez de ter uma iteração de comprimento
fixo, esta semana, motivados em parte por ela ser uma semana curta devido ao feriado
04 de julho reconheceu na segunda-feira.

O que nos atraiu para um pull-sistema é a flexibilidade que oferece as partes

interessadas para introduzir novos cartões ou priorizar cartas no meio de uma iteração.
(Ambos são proibidos no XP: Escopo é fixado para a iteração atual e a ordem de
implementação história é marcada por membros da equipe com base no fluxo lógico de
trabalho que ocorrem durante a iteração) A outra coisa agradável sobre ele é que ele
aproveita-nos a abordagens interessantes (como o Mapeamento do Fluxo de Valor ) para
maximizar a taxa de transferência de novos recursos (Em outras palavras, minimizando
a quantidade de tempo que normalmente leva uma história para ir desde a concepção à
produção.) É definitivamente soa agradável no principal, e parece ter funcionado bem
para a Toyota.

O lado negativo de usar Kanban ao desenvolver uma nova aplicação é que não há
maneira aparente de fazer a estimativa ampla que atualmente comunicar à gerência
superior. Embora você possa usar o seu tempo de ciclo calculado (a quantidade média
de tempo que leva um recurso a ir desde a concepção à produção) para estimar quando
uma característica particular será entregue à produção, que sobre o tempo necessário
para entregar o conjunto mínimo de recursos comercializável? Não parece possível a
utilização de tempo de ciclo para calcular isso, e você não pode usar a velocidade, se
você não tem iterações comprimento fixo. Além disso, os pedaços de trabalho
representado pelo conjunto mínimo de recursos comercializável não parece muito
compatível com um sistema de tração. As partes interessadas não estão adicionando um
recurso para a fila como nós começar o trabalho feito, eles estão nos dizendo o conjunto
mínimo de recursos que são necessários antes que eles estão dispostos a convocar uma
reunião com um cliente-chave para demonstrar uma nova aplicação, e parece lógico que
dadas as circunstâncias. Por último, o cálculo do tempo de ciclo e identificar gargalos se
torna muito mais difícil se as histórias que se deslocam através do fluxo de valor não
são do mesmo tamanho, e eles geralmente não são para o início de uma vida aplicações,
uma vez que há pouca ou nenhuma infra-estrutura no local no início.

Decisão

Uma vez que o valor de ser capaz de produzir estimativas para novas aplicações para a
gestão superior excede o valor delas é capaz de adicionar e priorizar histórias no meio
de uma iteração, decidimos voltar a usar XP para a nossa próxima iteração
Continuaremos a usar o XP sobre este pedido (e todas as novas funcionalidades que não
podem ser totalmente lançada após uma iteração) até que ele está realmente sendo
utilizados na produção. Vamos entregá-lo para um ambiente de produção em intervalos
regulares, antes disso, e demonstrar-lo lá para a alta gerência. Uma vez que os usuários
pretendidos são realmente usá-lo na produção e recebendo o valor a partir dele, temos
provisoriamente decidiu experimentar um sistema puxado de novo, uma vez que fará
mais sentido ter novas funcionalidades ser puxado através do sistema em resposta ao
trabalho que está sendo concluída uma vez estamos recebendo feedback do público-alvo
e estimativas não precisam ser comunicadas de volta para a alta gerência para essa
aplicação. Significa "XP para novo apps, Kanban para melhorias" parece ser um bom
módulo de operação? Uma coisa que me ocorre que eu estou lendo para trás sobre o
meu post é que se tinha decidido ir com um sistema de tração desde o começo, nós
poderíamos usar alguma metodologia de estimativa que não tem relação com nosso
processo (por exemplo, algum sabor de COCOMO, ou SWAG , ou o nome dele), apesar
de eu recolher que a velocidade com base em estimativas que temos vindo a utilizar
desde que adotamos XP ter sido muito mais precisas do que as estimativas dadas antes
de a empresa utilizou um processo ágil (embora eu acho que poderia ter a fazer com a
adoção de outras práticas ágeis nos manter focados). Se alguém ler este implementou
uma nova aplicação usando um sistema de puxar sob restrições semelhantes, como você
lidou com a estimativa (que foi em qualquer lugar perto precisa?), E foi a sua fila de
trabalho muito maior no início do projeto, ou era pequena toda?

Technorati Tags: Agile , Extreme Programming , XP , magra , Lean Software

Development , Kanban