No ágil, como as tarefas básicas de infraestrutura no início de um projeto são planejadas e alocadas usando estritas estruturas de gerenciamento como o TFS online?

9

Aqui estou, no processo de definição de escopo e estimativa de um projeto de desenvolvimento de software relativamente pequeno. Passei pelas histórias de usuários sugeridas pelo cliente e coloquei tarefas em cada uma delas, com uma estimativa e algumas breves notas sobre como a tarefa será realizada. Existem critérios de aceitação. Tudo deve ser bom com o mundo.

insira a descrição da imagem aqui

Ao olhar para o trabalho que planejei, percebi que havia algo faltando. Haverá um esforço inicial na simples configuração de coisas nas quais podemos aparafusar a funcionalidade. Coisas que pertencem a todas as histórias de usuário, não uma história de usuário específica.

Por exemplo, parte desse aplicativo é um serviço que analisa XML. Do ponto de vista do usuário, existem histórias específicas em que coisas diferentes precisam ser feitas, dependendo do conteúdo do XML. Na verdade, escrever um analisador XML - os bits que procuram um arquivo, o leem e extraem os dados relevantes antes de decidir o que fazer com o conteúdo - faz parte de todas essas histórias. Como é envolvê-lo em um serviço do Windows com um instalador, etc. É uma tarefa centrada no desenvolvedor, sem relevância direta para o usuário.

Outro exemplo relevante desse aplicativo em particular é pegar e reescrever um bloco de código legado ruim que é útil para as funções desse aplicativo. Novamente, isso não tem resultados imediatos para o usuário, mas é um trabalho necessário. Onde o planejamento e a execução deste trabalho "vivem" em um plano de projeto focado em histórias de usuários?

Vi pessoas resolverem isso escrevendo histórias de usuários "Como desenvolvedor, eu quero ...", mas como já foi discutido em outro lugar, essa não é uma história de usuário . É um desenvolvedor.

Estou procurando uma resposta concreta para isso, para me ajudar (e a outros) a planejar projetos usando estritas estruturas de gerenciamento como o TFS online. Elas não costumam ter a função de criar "histórias de partes interessadas" ou outras meta-soluções vagas mencionadas nas respostas a Como uma equipe do Scrum explica as tarefas de infraestrutura na reunião de planejamento?

Bob Tway
fonte
2
Se eu lhe disser que um computador ou serviço também pode ser tratado como um "usuário", isso altera sua análise?
Robert Harvey
11
@mmathis eu vi essa pergunta, e é semelhante e relevante. No entanto, nenhuma das respostas realmente responde a essa pergunta. Especialmente quando você se concentra em como fazê-lo nas estruturas existentes, como o TFS.
perfil completo de Bob Tway
@RobertHarvey parcialmente, sim. Isso cobriria o serviço nesse caso, mas não o código legado. Posso pensar em outras situações em que essa abordagem pode não cobrir os requisitos. Eu também estaria interessado em saber o quão amplamente aceito é: parece uma mudança semântica para contornar o problema "como desenvolvedor".
perfil completo de Bob Tway
2
Você pode trapacear em ter usuários do sistema e iteration0 ou cortar o bolo de maneira diferente. O primeiro recurso fornece algumas funcionalidades ao usuário e a infraestrutura necessária para fazê-lo funcionar. Em seguida, o recurso 2, que traz consequentemente mais infraestrutura, dessa forma você não perde tempo configurando a infraestrutura que não precisa. Se você está gritando agora, mas isso significa que preciso planejar novamente, então você não está agilizando.
CTRL-ALT-DELOR

Respostas:

12

Gosto das outras respostas que dizem para colocar o máximo de código de "ferramentas" na Iteração 0. No entanto, às vezes, esses tipos de ferramentas surgem após o início do projeto. Talvez na Iteração 3 você perceba que precisa de um widget de analisador XML generalizado para ser usado em várias histórias daqui para frente.

Nesse caso, a primeira história do usuário que depende dessas peças arquitetônicas internas é a qual elas pertencem . Se você estiver prestes a trabalhar na História 345, e ela dependerá do seu analisador XML antes que possa ser contada como 'concluída', seu analisador reutilizável será anexado como trabalho para que a história seja concluída.

Minha equipe usou a abordagem acima e pareceu funcionar bem para nós.

Graham
fonte
Eu ia responder de forma semelhante a esta. Se uma história precisa de algo, é parte dela. Algumas histórias podem apenas ter o benefício de buscar outra história que construiu a infraestrutura. No entanto, você precisa manter todas as histórias que precisam, exigindo-a apenas no caso de as histórias serem priorizadas novamente. Você não pode ter certeza de qual será o primeiro.
Jay S
11
+1 Isso toca em um ótimo ponto. Se é chamado iteração 0, 1 ou o que quer que seja uma bagatela. Todos, exceto os mais irracionais ou desinformados, entendem que é necessário algum trabalho de base. Se você pinta, prepara as paredes, se cozinha, pica, se é músico, pratica.
Robbie Dee
6

Se a infraestrutura é tipicamente colocada na Iteração Zero. O que é a Iteração Zero? Normalmente, é o tempo entre o início e o planejamento antes do início das iterações reais.

Um exemplo, digamos que precisamos de um novo serviço da web. Portanto, preciso criar o projeto, configurar a integração contínua, configurar um repositório de controle de origem, configurar o script de compilação e implantação automatizada etc. Os usuários realmente não se importam com eles, mas precisamos deles independentemente.

Portanto, esse trabalho seria feito na iteração 0. Quando a iteração 1 começou, já havia um novo shell de projeto que seria compilado, teria um script de construção automatizado e seria implantado. Agora, nenhuma das funcionalidades do usuário estaria lá, mas está pronta para ser usada.

Eu ainda controlaria e planejaria esse trabalho como parte do trabalho da iteração 0.

A refatoração parece uma história técnica que pode ocorrer em qualquer iteração.

Jon Raynor
fonte
4
+1 porque usamos isso também, mas, na realidade, a Interação Zero é a nova Iteração Um. É apenas uma iteração que a parte interessada do negócio realmente não se importa, mas é necessária para entender as coisas com as quais a parte interessada se importa.
precisa saber é o seguinte
Você pode ter uma iteração de boa fé 0, mas isso não quer dizer que você não possa começar a fornecer valor a partir do dia 1. Você não precisa de um servidor de compilação, implantação automatizada e repositório de código-fonte para começar a cortar o código - isso pode acontecer mais tarde (ou mesmo em paralelo).
Robbie Dee
3

Depende da infraestrutura.

Se a infraestrutura for muito significativa ou precisar seguir regulamentos complicados de conformidade, você poderá ter uma equipe de infraestrutura separada, que poderá ter um cronograma próprio. Pode ser Ágil, pode ser cascata. Nesse caso, a construção da infraestrutura seria gerenciada no seu projeto como uma dependência externa .

Se a infraestrutura for gerenciada por sua equipe e configurada apenas uma vez, você poderá usar a técnica de iteração 0 descrita por Jon.

Se a configuração da infraestrutura precisar de várias iterações (por exemplo, talvez você configure seu servidor de compilação agora, mas os servidores de controle de qualidade e pré-produção serão construídos um pouco mais tarde), o buildout poderá ser gerenciado como PBIs não funcionais. Os PBIs funcionais podem ter certas dependências, que você pode codificar no TFS usando o link "predecessor".

E é claro que você pode misturar e combinar todas as opções acima. Por exemplo, você não pode fazer muito sem um servidor de construção contínuo; portanto, você pode colocá-lo na iteração 0. Enquanto isso, seus servidores de pré-produção podem ser definidos como tarefas para as iterações 2 e 3 e podem ter dependências externas na equipe do DBA ( quem não é ágil) que alocará suas instâncias de banco de dados no seu datacenter. Ou talvez você precise aguardar a emissão de certificados SSL para determinados recursos; eles podem ir na iteração 4 e quaisquer itens funcionais que dependem desses certificados devem ser vinculados a eles com um relacionamento predecessor / sucessor.

Em todos os casos, lembre-se:

  1. Sempre defina critérios de aceitação claros. Os profissionais de hardware têm uma tendência irritante de suportar um servidor e concluí-lo quando ele ainda não foi validado.
  2. Durante o início da iteração de sua equipe, a equipe precisará examinar as dependências e sua disponibilidade antes de confirmar qualquer PBI ou item de trabalho.
John Wu
fonte
Os profissionais de hardware têm uma tendência irritante de resistir a um servidor e concluí-lo quando ele ainda não foi validado. Bom - daí a prevalência recente de DevOps.
Robbie Dee