histórias de sistema para arquitetura ágil [fechado]

Question

Ao tentar aplicar os princípios ágeis para nosso processo de desenvolvimento, em particular os princípios Scrum e XP-como histórias de usuários, nos deparamos com um problema sobre a arquitetura.

Talvez estejamos ainda muito ligada ao desenvolvimento de arquitetura centrada, no entanto, estamos tentando manter um desenvolvimento baseado em componentes forte, misturado com os princípios de modelagem ágil. O nosso objectivo é ter um design pequeno na frente, propenso a evoluções durante o desenvolvimento.

O que eu estou procurando é algo que poderia me colocar em minhas histórias backlog sobre a minha arquitetura e os componentes dentro dela: histórias desenvolvimento, não só histórias de uso. história sistema poderia ser um tipo diferente de história de usuário, que diz algo que não está estritamente relacionada com o valor do negócio, mas que em vez disso é ligada à arquitetura e qualidade preocupações de um sistema.

Editar: Eu encontrei este da Universidade Aalborg sobre a pesquisa " histórias desenvolvedor " .

Você tem alguma experiência, idéia ou oposição?

Agradecemos antecipadamente! (Esta é a minha primeira pergunta: D)

Answer 1

IMO um backlog deve não incluem histórias de desenvolvedores. Não há nenhuma maneira que qualquer Product Owner pode sensatamente priorizar estes juntamente com a funcionalidade de negócios. E o que acontece se o Product Owner considere um deles sem importância e por isso puxa-o para fora do backlog? Se a equipe, então, insiste em manter a história, você está em uma situação onde a propriedade do backlog torna-se clara.

No entanto, eu definitivamente acho que a necessidade da equipe para a arquitetura de construção no início do projeto. Um problema no meu projeto era que nós focado demais em funcionalidade nos primeiros sprints.

Vamos pensar sobre "dívida de arquitectura" (semelhante a dívida técnica) como o tempo que precisa ser gasto infra-estrutura de construção e arquitetura. Ao contrário de dívida técnica (que começa em zero e acumula-se como a equipe produz funcionalidade sem refatoração adequada), uma equipe inicia com a dívida arquitetônico e deve trabalhar para reduzi-la. Tempo gasto reduzindo a dívida de arquitetura que menos tempo é gasto funcionalidade produzir, ou seja, uma velocidade da equipe inferior e reduziram a produção sprint. Desta forma, a dívida arquitetura é semelhante a dívida técnica. Se os requisitos se que não se encaixava a arquitetura atual, em seguida, o nível da dívida arquitetônico aumentaria.

Tenha em mente, que a equipe deve decidir (e ser capaz de justificar o Product Owner) como eles estão indo para gastar seu tempo. E para que eles possam dividir seus esforços entre a funcionalidade, a dívida técnica e dívida arquitetônica como entenderem.

Arquitetura trabalho deve ainda ser conduzido pela funcionalidade embora. Em outras palavras, a equipe deve construir infra-estrutura para suporte e habilitar uma história de usuário particular. Não só porque eles acham que vai ser útil no futuro. O princípio YAGNI se aplica a esse tipo de abordagem.

Answer 2

A minha resposta aqui se aplica .

Há um equilíbrio muito difícil entre fazer trabalho de arquitetura e mais trabalho específico recurso. Tecnicamente ambos são abordagens válidas e trabalho, mas quanto mais tempo você demora alguma quantidade de produto utilizável (resultados de sprint) quanto maior o risco que você toma que você não está construindo o produto certo (as necessidades dos utilizadores, requisitos de desempenho, ect.). Tão cedo quanto possível, chegar a um ponto onde você pode realizar testes de nível de sistema para provar que seus trabalhos produtos e você pode demonstrar o valor eo sentido do produto com suas partes interessadas.

Answer 3

É tão simples como colocar um Verifique se o componente assinatura pode ser testado desconectado de todos os outros componentes história 'user', o seu backlog deve ter sistema / desenvolvimento-histórias, desde que é sync'ed com o desejo do proprietário do produto de tal implementação.

É assim que costumam colocar os requisitos não funcionais em um backlog, como "O modelo de domínio tem de ser executado em um datacenter diferente sob o balanceamento de carga" etc.

Answer 4

Uma lente que eu achar útil para assumir histórias desenvolvedor é pensar que "o usuário" para qualquer história é. Só porque você não está escrevendo um recurso que será visto por pessoas de fora da empresa não significa que não há um usuário para aquele pedaço de trabalho. Você pode escrever código para uma equipe no corredor. Em alguns casos, o usuário é você mesmo. Isso é muitas vezes o caso de histórias de desenvolvedores. Pense "Como um desenvolvedor, eu tenho uma arquitetura escalável para que eu possa facilmente adicionar novas funcionalidades." Ao chamar o usuário em particular, dá o proprietário do produto alguns insights sobre quem vai ver o valor da história. E apontando o "porquê" é também útil para transmitir o que beneficiará as esperanças da história a alcançar. Como já foi mencionado, a gestão do backlog vem para baixo a uma negociação entre o proprietário do produto e da equipe. E como sempre, você precisa descobrir o que funciona melhor para sua equipe, independentemente do dogma processo. Cada equipe tem uma situação diferente, e as idéias que funcionam bem para uma equipe nem sempre se traduzem para outro.

Answer 5

Em nossa equipe chamamos isso de "it-cards", que é cartões da forma: "Como um desenvolvedor eu luto para refatorar o xyz-componente Para reduzir o custo de manutenção e aumentar a flexibilidade..."

Os membros da equipe são livres para escolher qualquer IT-card que considerem importante, em vez de tomar uma "Recurso-card" do backlog priorizado.

Eu acho essa abordagem funcionar razoavelmente bem para manter dívida técnica a um nível aceitável e permitir um ritmo saudável de inovação.

Eu achei um pouco carente como um meio de re-arquitetar o sistema embora. É difícil justificar a longos desvios do fluxo de produção de recurso.

Como eu estou escrevendo isso, eu estou pensando que se pode aproximar arquitetura por theming as histórias. Identificar as metas architectual com épicos que você quebrar em um tema para se concentrar.