Comment gérez-vous le design dans Scrum?
Comment gérez-vous le design dans Scrum? Avez-vous encore des documents de conception bien écrits pour chaque itération de mêlée? Faites-vous juste des notes de conception comportant des diagrammes UML? Ou avez-vous juste du code bien commenté?
Chaque itération peut impliquer un changement de conception, donc je voulais juste savoir comment les gens capturaient cela afin que les nouveaux développeurs puissent facilement comprendre le domaine et intégrer le plus rapidement possible.
ce n'est pas parce que c'est de la mêlée que tout change à chaque sprint!
Scrum concerne faire ce qui est nécessaire (mais pas plus). Vous devez toujours faire la conception et vous devez toujours documenter. Son juste le montant n'est pas fixe ni comment le faire.
Une partie de la planification de chaque sprint consiste à décider de ce qui doit être fait. Si quelque chose dans le backlog doit être conçu car il a un impact sur d'autres choses, vous devez ajouter une tâche spécifique pour les processus de conception et le faire avant la tâche d'implémentation.
J'ai beaucoup à dire sur ce sujet. J'ai vu de nombreux cas où des entreprises/équipes/personnes disent utiliser une approche Agile des logiciels, mais en réalité, ils veulent récolter les fruits que les méthodes Agiles promettent sans adhérer aux principes.
Pour que l'itération rapide fonctionne, vous devez faire un développement piloté par les tests (je me suis arrêté de dire que vous devez faire TDD à contrecœur). Dans TDD, vos tests expriment la conception et l'intention du code (quand ils disent "le code est la documentation", ce qu'ils devraient dire, c'est "les tests sont la documentation"). En écrivant des tests unitaires qui expriment votre compréhension de la fonctionnalité à portée de main, vous déclarez explicitement ce que vous pensez que le code doit faire. Ensuite, vous écrivez le code qui le fait. Ensuite, vous refactorisez ce code afin qu'il adhère aux bons principes architecturaux "Red-Green-Refactor".
L'exécution de vos tests unitaires à chaque archivage (ou même avant chaque archivage) vérifie que le nouveau code que vous avez écrit ne rompt pas les fonctionnalités attendues dans un autre domaine de l'application. Cela fournit un filet de sécurité qui vous permet de modifier le code avec un abandon sans faille. À mesure que votre compréhension des exigences augmente, vous pouvez modifier le test pour refléter ces nouvelles connaissances. La vraie conception réside dans les tests unitaires. Tout le reste (y compris le code non couvert) est un mensonge.
Voici quelques lectures recommandées
- Code propre
- Principes, modèles et pratiques de développement logiciel agile
- Le programmeur pragmatique
Ce sont de bons endroits pour commencer à chercher à vraiment aborder le développement agile.
Scrum est une méthodologie de gestion de projet, pas une méthodologie de développement logiciel. Scrum est généralement utilisé en conjonction avec une méthodologie Agile. C'est là que réside votre réponse.
L'architecture globale du projet et la conception de haut niveau se feraient en dehors des équipes Scrum lorsque les propriétaires du projet créeraient les histoires.
Il doit y avoir suffisamment de conception globale écrite sous quelque forme que ce soit pour aider à voir la relation entre les histoires et les attentes du client.
Une partie de la conception nécessaire pour chaque histoire serait effectuée lors de la planification et de la négociation avec le propriétaire du produit pendant la planification.
La majeure partie de l'effort de conception d'une histoire se ferait au cours du sprint.
Si l'histoire n'est pas suffisamment définie pour être estimée, alors une zone de temps peut être mise de côté dans le sprint actuel pour effectuer suffisamment de travail de conception pour qu'une histoire appropriée puisse être créée pour un sprint ultérieur.
Scrum est un modèle itératif et incrémentiel basé sur valeurs agiles . Cela signifie que vous n'avez pas de phase de conception distincte. L'idée est que vous devez constamment vous occuper de la conception, tout comme vous vous occupez constamment de l'analyse, de la mise en œuvre, des tests et de l'intégration tout au long du projet.
Vous avez besoin d'un peu de planification pour que cela fonctionne. Entrez dans la réunion de planification du sprint, où l'équipe estime les tâches pour le sprint à venir. La plupart des gens ne réalisent pas que ce n'est pas seulement une réunion d'estimation, mais aussi un effort de conception. Par exemple, une tâche peut être "Ajouter du code pour un nouveau modèle de voiture". Vous ne pouvez pas encore estimer cela, vous devez en savoir un peu plus. L'équipe discute donc de la conception et propose une solution large ("Sous-classe Voiture?") Et ajoute cela en rappel à la tâche. Vous avez rarement besoin de plus de formalité que cela. Vous avez maintenant une idée de la façon de résoudre le problème. Vous n'avez pas encore tous les détails et c'est bien, vous connaissez assez du design pour pouvoir faire une estimation confortable. Sans avoir à créer de diagrammes (à ce stade).
Pour la documentation physique réelle , je recommande créer un schéma de vue d'ensemble des systèmes sur un mur pour que tout le monde puisse le voir. L'aperçu n'a besoin que des classes et modules les plus importants inclus et devrait rarement être mis à jour. De plus, la création de quelques diagrammes d'état pour les classes les plus importantes du système est très utile. Saupoudrez de quelques diagrammes de séquence sélectionnés de cas d'utilisation typiques pour permettre aux utilisateurs de voir rapidement comment les choses sont connectées. Je suppose que vous pouvez générer des diagrammes de hiérarchie de classes à partir de votre code, afin que ce problème soit facilement résolu.
Notez que tous les diagrammes sont créés après l'implémentation réelle. Cela est conforme au "logiciel de travail sur une documentation complète" et à une conception juste à temps.
Et oui, le code lisible est définitivement de la documentation.
Il n'y a pas autant de conception initiale que les exigences changent fréquemment. Donc, la conception au niveau de la classe est généralement une perte de temps. Cependant, il peut être utile d'esquisser des décisions architecturales de niveau supérieur.
Le problème avec les documents de conception lourds est qu'ils sont obsolètes presque dès leur création. Donc, ce qui fonctionne le mieux, c'est généralement une documentation de haut niveau qui ne changera probablement pas complètement en peu de temps.
Il existe aujourd'hui une division au sein de la communauté Eclipse entre les outils UML traditionnels axés sur MDD dans lesquels le modèle pilote le code/développement et Omondo qui considère que les itérations devraient conduire le processus de développement et certainement pas seulement le modèle.
Je suis d'accord avec eux car MDD est de la merde alors que UML est vraiment un excellent moyen car standardiser pour communiquer avec les autres membres de l'équipe. 
Ma compréhension est que vous effectuez une conception de niveau supérieur avec les exigences initiales que vous réunissez au début du projet. Vous documentez bien cette conception.
Ensuite, lorsque vous allez réellement implémenter l'exigence, vous modifiez la conception de niveau inférieur selon vos besoins, mais vous évitez de modifier la conception de niveau supérieur.
Eh bien, c'est comme ça qu'on m'a expliqué il y a cinq minutes de toute façon ...