Como você lida com o design no Scrum?

Como você lida com o design no Scrum? Você ainda possui documentos de design bem escritos para cada iteração de scrum? Você acabou de criar notas de projeto com diagramas UML? Ou você apenas tem um código bem comentado?

Cada iteração pode envolver alterações no design, então eu só queria saber como as pessoas capturam isso, para que os novos desenvolvedores tenham um trabalho fácil de entender o domínio e se integrarem o mais rápido possível.

só porque é scrum não significa que tudo muda a cada sprint!

Scrum é fazer o que é necessário (mas não mais) . Você ainda precisa fazer o design e ainda precisa documentar. É apenas a quantidade não é fixa nem como fazê-lo.

Parte do planejamento de cada sprint é decidir o que precisa ser feito. Se algo no backlog precisar ser projetado porque afeta outras coisas, você precisará adicionar uma tarefa específica para os processos de design e fazer isso antes da tarefa de implementação.

Eu tenho muito a dizer sobre esse assunto. Eu já vi muitos casos em que empresas / equipes / pessoas dizem que estão usando uma abordagem ágil para software, mas, na realidade, querem colher as recompensas que os métodos ágeis prometem sem aderir aos princípios.

Para que a iteração rápida funcione, você deve fazer o desenvolvimento orientado a testes (eu parei de dizer que você deve fazer o TDD com relutância). No TDD, seus testes expressam o design e a intenção do código (quando dizem "o código é a documentação", o que eles deveriam dizer é "os testes são a documentação"). Ao escrever testes de unidade que expressam sua compreensão do recurso em questão, você está declarando explicitamente o que acredita que o código precisa fazer. Então você escreve o código que faz isso. Em seguida, refatorar esse código para que cumpra os princípios principais de arquitetura "Red-Green-Refactor".

A execução dos testes de unidade com cada check-in (ou mesmo antes de cada check-in) verifica se o novo código que você escreveu não quebra a funcionalidade esperada em outra área do aplicativo. Isso fornece uma rede de segurança que permite alterar o código com abandono sem destruição. À medida que sua compreensão dos requisitos em questão aumenta, você pode modificar o teste para refletir esse novo conhecimento. O design real está nos testes de unidade. Tudo o resto (incluindo o código que não é coberto) é uma mentira.

Aqui estão algumas leituras recomendadas

• Código Limpo
• Princípios, padrões e práticas de desenvolvimento de software ágil
• O programador pragmático

Estes são bons lugares para começar a procurar aprender como realmente abordar o desenvolvimento ágil.

Scrum é uma metodologia de gerenciamento de projetos, não uma metodologia de desenvolvimento de software. Scrum é normalmente usado em conjunto com uma metodologia Agile. Aí reside a sua resposta.

Não existe um design inicial tão amplo quanto os requisitos frequentemente mudam. Portanto, projetar até o nível da classe geralmente é uma perda de tempo. No entanto, pode valer a pena esboçar decisões arquitetônicas de nível superior.

O problema com a criação de documentos de design para serviços pesados ​​é que eles ficam obsoletos quase assim que são criados. Portanto, o que funcionou melhor é geralmente uma documentação de alto nível que dificilmente mudará completamente em um curto período de tempo.

Scrum é um modelo iterativo e incremental baseado em valores ágeis . Isso significa que você não tem uma fase de design separada. A idéia é que você esteja constantemente lidando com o design, assim como você está constantemente lidando com a análise, implementação, teste e integração ao longo do projeto.

Você precisa de um pouco de planejamento para que isso funcione. Entre na reunião de planejamento do sprint , em que a equipe estima tarefas para o sprint adiante. A maioria das pessoas não percebe que isso não é apenas uma reunião de estimativa, mas também um esforço de design. Por exemplo, uma tarefa pode ser "Adicionar código para o novo modelo de carro". Você ainda não pode estimar isso, precisa saber um pouco mais. Portanto, a equipe discute o design e apresenta uma solução ampla ("subclasse Car?") E acrescenta isso como um lembrete para a tarefa. Você raramente precisa de mais formalidade do que isso. Agora você tem uma idéia de como resolver o problema. Você ainda não tem todos os detalhes e está tudo bem, você conhece o design o suficiente para poder fazer uma estimativa confortável. Sem precisar criar diagramas (neste momento).

Para documentação física real , recomendo criar um diagrama de visão geral dos sistemas em uma parede para que todos possam ver. A visão geral precisa apenas incluir as classes e módulos mais importantes e raramente deve ser atualizada. Além disso, a criação de alguns diagramas de estado para as classes mais importantes do sistema é muito útil. Polvilhe com alguns diagramas de sequência selecionados de casos de uso típicos para facilitar que as pessoas vejam rapidamente como as coisas estão conectadas. Suponho que você possa gerar diagramas de hierarquia de classes a partir do seu código, para que o problema seja facilmente resolvido.

Observe que todos os diagramas são criados após a implementação real. Isso está de acordo com o "software de trabalho sobre documentação abrangente" e o design just-in-time.

E sim, o código legível é definitivamente documentação.

A arquitetura geral do projeto e o design de alto nível seriam feitos fora das equipes de scrum quando os proprietários do projeto estivessem criando as histórias.

É necessário que haja um design geral suficiente, escrito de qualquer forma, para ajudar a ver o relacionamento entre as histórias e as expectativas do cliente.

Parte do design necessário para cada história seria feito no planejamento e negociação com o proprietário do produto durante o planejamento.

A maior parte do esforço de design de uma história seria feita no sprint.

Se a história não estiver definida o suficiente para ser estimada, uma caixa de tempo poderá ser reservada no sprint atual para fazer o trabalho de design suficiente para que uma história apropriada possa ser criada para um sprint posterior.

Meu entendimento é que você faz um design de nível superior com os requisitos iniciais que você reúne no início do projeto. Você documenta bem esse design.

Então, quando você realmente implementa o requisito, altera o design de nível inferior conforme necessário, mas evita alterar o design de nível superior.

Bem, foi assim que me foi explicado há cinco minutos ...

Hoje existe uma divisão dentro da comunidade Eclipse entre ferramentas UML tradicionais focadas no MDD, nas quais o modelo direciona o código / desenvolvimento e Omondo, que considera que as iterações devem conduzir o processo de desenvolvimento e, certamente, não apenas o modelo.

Eu concordo com eles porque o MDD é uma porcaria, enquanto a UML é realmente uma excelente maneira, porque padroniza para se comunicar com outros membros da equipe.