O que você entrega nas duas primeiras iterações no Agile?


22

Pelo que entendi, a idéia com metodologias ágeis é que você entrega algo funcional e o entrega com frequência. O aplicativo entra em seu incremento de forma final após incremento.

Mas nas iterações iniciais, você pode criar a estrutura ou os fundamentos sobre os quais o aplicativo permanecerá, para que seja algo importante, mas não visível para os usuários.

O que é entregue ao cliente nessas primeiras iterações? Como você mostra o progresso na direção certa quando cria código de andaimes?


2
Construir uma estrutura ou fundação inteira deve ser uma decisão tomada o mais tarde possível no projeto.
JeffO 07/01

@ JeffO: o que você quer dizer o mais tarde possível? Você pode expandir isso em uma resposta?
JohnDoDo

5
Idealmente, não deveria ser uma decisão. Uma estrutura não deve ser criada, deve emergir organicamente como resultado da refatoração. Nenhuma estrutura "boa" (para minha própria definição subjetiva de "boa") foi projetada do zero; elas foram extraídas após o fato de aplicativos existentes ou baseadas em outras estruturas existentes.
Jörg W Mittag

7
A @JohnDoDo construindo uma fundação antecipadamente pressupõe que você saiba quais serão os requisitos do seu aplicativo antes mesmo de ele existir. Toda vez que vejo pessoas fazendo isso, acabam com algo rígido e muito difícil de trabalhar. Frequentemente, os usuários dessa "estrutura" acabam lutando mais do que abraçando-a.
Stefan Billiet

Respostas:


15

É típico ter 2 semanas de corrida.

Para mim, o primeiro sprint ou o 2 provavelmente terão menos recursos "visíveis" do que os sprints posteriores por esse motivo exato (por alguma descrição tênue de "less").

Dito isto, certamente não deve demorar duas semanas para criar todo o seu andaime e não há nada visível na interface do usuário para mostrar isso.

Talvez você não elimine todos os itens do andaime no primeiro sprint ou 2. Talvez as peças possam esperar e serem adicionadas mais tarde.

Talvez seu primeiro sprint tenha "Criar página da Web X com dados fictícios" para que você possa obter algo brilhante para mostrar ao seu cliente. E o próximo sprint tem "Alterar página da web X para usar dados do banco de dados".


6
+1 no último parágrafo - é uma boa ideia iniciar o desenvolvimento com um protótipo destinado à validação do usuário.
21978 Konamiman

4
"Talvez seu primeiro sprint tenha" Criar página da Web X com dados fictícios "para que você possa obter algo brilhante para mostrar ao seu cliente.": OMI depende do cliente e da escala de tempo do projeto: para um projeto de 2 meses, um cliente pode deseja ver algo em 1 ou 2 semanas. Para um projeto de 18 meses, pode ser bom obter uma primeira demonstração em 1 ou 2 meses. De qualquer forma, enquanto alguns clientes gostam de ver uma página falsa, outros podem querer ver algo mais significativo e ter a sensação de que estão perdendo tempo. Eu acho que você não pode generalizar.
Giorgio

4
+1, mas sempre, lembre-se sempre do segredo do iceberg ao mostrar as peças da interface do usuário ao seu cliente joelonsoftware.com/articles/fog0000000356.html
Doc Brown

1
@MatthewFlynn - Scrum pode não ter uma verdadeira fase de "requisitos", mas isso não significa que existem requisitos ou documentação ZERO disponíveis. Eu nunca estive envolvido em um projeto em que um cliente disse: "vá em frente e comece a construir e descobriremos isso ao longo do caminho". Eu acho que há um termo para isso. Normalmente, deve haver algum tipo de fase de elicitação de um projeto que inclua alguma discussão e acordo sobre o que será entregue. Eu apresentei protótipos durante o discurso de vendas
hanzolo

1
@hanzolo - Um projeto de muito sucesso em que trabalhei recentemente envolveu a implementação de uma solução para lidar com um novo requisito legal que fazia parte da Affordable Care Act. Os requisitos básicos eram conhecidos, sim, mas não havia nada no caminho de um protótipo ou projeto sobre qual seria a solução. A equipe do projeto (que incluía analistas de negócios) descobriu isso dentro do contexto dos sprints. Na melhor das hipóteses, os BAs conversariam com o pessoal de negócios sobre histórias um ou dois sprints à frente do resto da equipe, mas era com isso que tínhamos que trabalhar. Funcionou bem.
Matthew Flynn

13

O Manifesto Agile sugere que o Software de Trabalho é mais valioso do que a documentação abrangente, e a estrutura do Scrum adota essa noção para sugerir que o fornecimento de software de trabalho testado e com valor comercial seja um requisito a cada sprint.

Por quê? Bem, entre outras coisas, designers e desenvolvedores frequentemente são vítimas de gastar muito tempo com itens YNNI (você nunca precisará dele). Infelizmente, essas estruturas de que você está falando geralmente são uma grande responsabilidade nessa área. Os desenvolvedores começam a desenvolver todas as coisas que a estrutura PODE ter para oferecer suporte e, de repente, você tem três meses e não tem nada de valor comercial para mostrar. Acontece que a estrutura nem suporta realmente o que eles acabam precisando.

Portanto, a abordagem sugerida é criar apenas o que é realmente necessário agora e entregá-lo agora.

Isso NÃO significa que você não pode construir peças reutilizáveis ​​e similares, mas sempre o faz para apoiar a construção de uma necessidade atual. Além disso, isso não significa que você precise usar completamente antolhos para o que está por vir - não construa coisas para que seja impossível alterá-las / melhorá-las mais tarde. Mas a chave é sempre oferecer valor comercial.

Geralmente, existem algumas coisas importantes que precisam ser estabelecidas antes que qualquer coisa possa ser entregue, como a configuração de ambientes e similares. Para isso, muitas equipes acham útil ter um "Sprint 0" no qual as bases são estabelecidas. O Sprint 0 pode demorar um pouco mais do que os outros sprints, pois não é aplicado ao backlog ou queima do seu produto, mas ainda deve ter um prazo de duração razoável.


8

O que é entregue ao cliente nessas primeiras iterações?

O que tem maior valor comercial para o usuário. Por exemplo, se os aplicativos tiverem regras de negócios complexas, a (s) primeira (s) iteração (ões) conterão apenas aquelas regras de negócios codificadas na forma de código. O cliente deve estar satisfeito desde que você tenha um código para essas regras de negócios. (O problema de convencer o cliente a aceitar uma coisa dessas é uma questão completamente diferente.) Por exemplo, você pode mostrar aos especialistas em negócios do cliente seus testes de unidade / aceitação que expressam o que o domínio deve fazer e que o código passa com um resultado verde. Ou melhor ainda, faça com que os especialistas em negócios ajudem a criar esses testes.

Há também a questão de

você pode construir a estrutura ou fundações

O que acredito ser muito mais importante do que realmente é entregue. O Design Evolucionário tem algo importante , que diz que você deve criar a arquitetura ao longo do tempo, em vez de tentar criá-la no começo. Quanto à fundação, isso geralmente significa algum tipo de banco de dados ou estrutura da interface do usuário. Nesse caso, existe a idéia de " boa arquitetura é aquela que permite adiar decisões importantes ". E escolher banco de dados ou interface do usuário é uma decisão importante. Por exemplo, você pode se dar bem apenas com armazenamento na memória de dados, em vez de tentar usar o DB desde a primeira iteração.


3

O que tentamos fazer é entregar nas primeiras iterações o aplicativo mais simples possível (uma versão hello world do que estamos entregando). Vemos três benefícios importantes nisso:

  • Configure o procedimento de entrega (sempre uma das partes mais difíceis): instale ambientes, servidores, atualize a segurança desse ambiente. Como entregaremos com frequência, é importante acertar o mais rápido possível.
  • Dê aos usuários um primeiro vislumbre de como o aplicativo será. Isso ajuda os usuários e os desenvolvedores a entender o que eles realmente querem e precisam.
  • Tenha uma idéia básica sobre como será a arquitetura do aplicativo (o aplicativo deve cobrir as 'camadas' ou componentes básicos do aplicativo).

"Configurar o processo de entrega" é muito mais difícil do que as pessoas pensam.
precisa saber é o seguinte

Sim. É por isso que você deve fazer isso o mais cedo possível.
precisa saber é o seguinte

2

Mas nas iterações iniciais, você pode criar a estrutura ou os fundamentos sobre os quais o aplicativo permanecerá, para que seja algo importante, mas não visível para os usuários.

Isso está errado, já que você não precisa criar uma estrutura que possa usar no futuro. A idéia é construir apenas o necessário (veja também YAGNI ).

No sprint zero, você precisa se preparar para o trabalho real. Muitas pessoas discutem o que deve ser feito neste sprint, mas, na minha opinião, está concluído quando você pode começar a trabalhar nos itens do backlog. Esta etapa inclui configurar PCs, definir o processo de criação, escolher estruturas etc.

Quando você terminar o sprint zero (ou a iteração zero), poderá começar a trabalhar no seu aplicativo. Pegue os itens da lista de pendências e termine-os um por um. Depois de concluir a iteração 1, você terá algo útil. A primeira iteração geralmente inclui alguns dos recursos mais importantes.

O que é entregue ao cliente nessas primeiras iterações? Como você mostra o progresso na direção certa quando cria código de andaimes?

Após a iteração zero, obviamente você não tem mais nada para entregar. A entrega ocorre após a iteração 1. Ele contém recursos que você definiu para a iteração.

Se sua pergunta for "como escolher o que entra na iteração X?", Dê uma olhada nesses videocasts (vídeos para a iteração 0 A e parte de B).


+1 por ser o único a mencionar a iteração zero
crad

Não considero definir processo de compilação e escolher tarefas de estruturas para o sprint zero. Como você pode saber qual estrutura precisa se não sabe o que construir? Eu sempre limitei o sprint 0 a um mínimo. Obtenha PCs para as pessoas e encontre um espaço onde elas possam se sentar. Descubra com quem você precisa falar da empresa. Configure uma primeira reunião de planejamento. Aplico YAGNI ao resto.
precisa saber é o seguinte

@ user99561 As estruturas são grandes decisões e geralmente difíceis de mudar. Por exemplo, você deve saber se vai usar gtest ou cppunit para testes de unidade antes de começar a escrever o código. Mudá-lo mais tarde será uma enorme dor na bunda e muito tempo perdido.
BЈовић

@ Bћовић: Sim, estruturas são grandes decisões, é por isso que você deve adiar a decisão. Não faz sentido decidir sobre uma estrutura se você não sabe o que precisa ser desenvolvido e como o aplicativo e a arquitetura serão exibidos. Você deve decidir sobre qual estrutura usar no último momento possível. Caso contrário, você definitivamente corre o risco de precisar alterá-lo.
precisa saber é o seguinte

@ user99561 Se você não sabe o que precisa ser desenvolvido, não pode nem mesmo começar :) Os requisitos e as histórias do usuário devem ser anotados; caso contrário, a iteração 1 nem poderá ser iniciada.
BЈовић

2

Você pode entregar praticamente o que quiser. A construção da ideia de infraestrutura é simplesmente errada / não é ágil / insustentável.

Por exemplo: a criação de um aplicativo Hello World totalmente funcional pode ser criada em horas. A criação de um servidor (mesmo que temporariamente) na nuvem ou como uma VM pode ser feita em horas.

Estes são suficientes para começar a se desenvolver . Então, se você precisar de IC, poderá adicionar uma história de IC; se você precisar de um servidor físico, com certeza, adicione uma história para isso.

Mas comece a entregar no primeiro dia e nunca pare!


1

As iterações iniciais, especialmente a 1ª, conterão ou devem pelo menos planejar picos de arquitetura, que incluem uma certa quantidade de tempo de descoberta e talvez alguma prototipagem de arquitetura.

Como você disse, geralmente, existem requisitos estruturais que podem não significar muito para a parte interessada / cliente, mas são necessários para formar uma forte plataforma ou orientação de padrão. Você não pode contornar isso, pois não pode começar a construir B até que A esteja completo.

Parte da abordagem do Agile é fechar o cliente para que a documentação não seja necessária, pois tudo o que você precisa fazer é pegar o telefone / enviar e-mail, e isso é esperado. As expectativas dos clientes devem ser definidas adequadamente e qualquer trabalho concluído deve ser muito conciso e NECESSÁRIO . Sem revestimento de ouro, sem "Você pode precisar", etc. Construa o que você precisa em A para passar para B.

Dependendo de como você está atacando o projeto, você só pode criar a base necessária para concluir um determinado módulo; portanto, durante a reunião de planejamento do sprint, você deve definir os planos para o sprint atual com base nas prioridades definidas pelo cliente, dependendo do que for necessário para esse sprint, pode haver alguns requisitos básicos, e é isso que entra no sprint 1. Depois que o 1º sprint estiver concluído e A tiver sido construído, planeje concluir B.

Se você concordou com uma linha do tempo com o cliente, desde que cumpra esse contrato, o cliente provavelmente não se importará com o que você faz primeiro ou segundo. Você sempre pode mostrar a eles os resultados do teste de unidade, mas se você disser que teremos algo para você ver após o sprint 2 (ou 3) e entregar, ele estabelecerá uma forte precedência. Espera-se que os clientes sejam razoáveis ​​tanto quanto os desenvolvedores e ambos estão trabalhando para o mesmo objetivo. Um projeto concluído que atenda às necessidades do cliente e funcione conforme o esperado. Tão preocupante que não haja nada para ver após o sprint 1 é um ponto discutível, porque o cliente só quer ter certeza de que, após o sprint 20, o projeto será concluído (-ish).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.