Como alocar preocupações transversais no planejamento ágil de desenvolvimento de software?

5

Meu empregador passou de projetos tradicionais em cascata para uma versão modificada do ágil. O trabalho é dividido em histórias, que são estimadas e sequenciadas em iterações de duas semanas. Cada iteração inclui pontos para criar, testar e aceitar recursos.

As histórias são focadas em recursos de negócios testáveis. Não há como planejar e contabilizar preocupações transversais como design, arquitetura, infraestrutura ou (ironicamente) gerenciamento de projetos.

As equipes ágeis devem incluir explicitamente histórias ou tarefas para essas questões transversais? Como sua equipe lida com tarefas que nunca desaparecem? Eles são "off book"?

    
por duffymo 15.08.2014 / 14:42
fonte

3 respostas

3

Eu já vi duas abordagens básicas:

  1. Adicione tarefas recorrentes e temporizadas a cada sprint para esses tipos de problemas. Isso aumenta a visibilidade das tarefas e permite verificar se uma etapa ou tarefa específica é Concluída. A desvantagem é mais clonagem de overhead ou recriar essas tarefas de sprint para sprint.

  2. Apenas reserve um timebox coletivo para essas tarefas a cada sprint, reduzindo o tempo disponível para a implementação de histórias no sprint de acordo. Isso é mais simples de gerenciar, mas dificulta o gerenciamento das tarefas individuais incluídas na caixa.

por 15.08.2014 / 15:39
fonte
1

Sim, crie histórias para design, arquitetura, infraestrutura e gerenciamento de projetos.

Você pode querer criar uma placa adicional para eles, pelo menos inicialmente.

Em última análise, eles envolvem pessoas fazendo trabalho, de modo que, ao se desenvolverem, você deve ser capaz de designar pessoas para elas ou transferi-las para a diretoria do projeto de uma equipe.

Uma coisa que fazemos para histórias mais intangíveis, às vezes, é a criação de spikjes que são vinculados ao tempo, por ex. "2 dias" para fazer essas tarefas.

    
por 15.08.2014 / 16:39
fonte
1

TL: DR; Histórias para arquitetura de sistemas, design emergente por meio de refatoração e desduplicação de código.

Isso é o que fazemos no meu trabalho:

  • A arquitetura e a infraestrutura de sistemas são tratadas como uma história (ou várias histórias), em nosso jargão seria um cartão de pesquisa. A pesquisa, quando feita, responde a uma pergunta e geralmente leva a histórias ou cartões mais bem definidos.
  • O design do código é tratado de maneira diferente. Praticamos design emergente por meio de refatoração constante e deduplicação de código que é sempre uma parte de todas as tarefas de programação que fazemos.

Uma exceção:

Como você deve saber, o design de refatoração pode ser muito difícil, especialmente com uma base de código estabelecida. Um dos maiores fatores atenuantes para nós, que torna possível o design interativo, é fazer o Desenvolvimento Orientado a Testes de Aceitação. Criamos um conjunto de testes que define e testa o comportamento de nossos sistemas. Isso nos permitiu ocasionalmente extrair completamente subsistemas, reimplementá-los e ainda ter certeza de que tudo funciona. Geralmente, tentamos fazer isso iterativamente e como parte do fornecimento de valor ao cliente. No entanto, existem exceções à regra e, quando elas surgem (raramente), gastamos alguns dias apenas na reformulação de parte do design. MAS, tudo bem, porque são ocorrências raras e nosso processo permite exceções.

    
por 15.08.2014 / 18:52
fonte