Comment obtenir une bonne conception lors de l'utilisation de méthodes agiles?

J'utilise une méthodologie agile (SCRUM) depuis environ trois ans maintenant et je vois certains avantages, en particulier dans le retour d'information à court terme à de nombreux niveaux (des clients ayant un accès précoce aux fonctionnalités implémentées, des testeurs qui peuvent tester des fonctionnalités comme dès leur mise en œuvre, par d'autres développeurs qui peuvent fournir très tôt des commentaires sur le nouveau code par le biais d'une révision, etc.).

D'un autre côté, j'ai deux problèmes ouverts, le premier que je vais essayer d'expliquer dans cette question.

Problème: difficulté à obtenir un bon design

J'essaie de refactoriser dès que le code devient désordonné, j'écris des tests unitaires autant que possible (ce qui aide à prévenir les bugs en général et lors du refactoring en particulier). D'un autre côté, développer une fonctionnalité complexe par petits incréments, avec des commits quotidiens et repenser continuellement le code lorsqu'il n'est pas structuré ne me permet pas de produire un très bon design.

Le seul module bien conçu que j'ai pu produire récemment que j'ai obtenu en adoptant une approche différente: j'ai analysé le problème pendant quelques jours (j'avais en fait eu le problème en tête pendant quelques mois avant de commencer à y travailler sérieusement). ), a esquissé une conception assez détaillée de toutes les classes impliquées et de leurs relations pendant quelques jours, puis s'est enfermé dans mon bureau et a écrit tout le code en travaillant sans interruption pendant environ trois semaines. Le résultat a été la meilleure chose que j'ai produite depuis un certain temps, avec très peu de bugs qui étaient plutôt faciles à localiser et à corriger, et avec une conception très claire, qui n'a pas nécessité de modifications pertinentes depuis lors.

Donc, jusqu'à présent, j'ai trouvé beaucoup plus efficace d'obtenir une image globale de ce que je veux faire à l'avance que de commencer à écrire du code par petits incréments dans l'espoir que la grande image émerge comme par magie dans le processus. Avec mes meilleurs efforts, l'approche de développement par petits incréments m'a toujours conduit à une pire conception.

Question : Quelqu'un a-t-il eu une expérience similaire? Suis-je en train d'appliquer SCRUM dans le mauvais sens ou à quoi dois-je faire attention si je veux développer par petits incréments et me retrouver avec un logiciel bien conçu? Ou dois-je planifier une user story de conception avant de commencer le codage proprement dit? Est-ce considéré comme une bonne pratique, du moins pour les fonctionnalités plus complexes que la moyenne?

NOTE ÉDITÉE

Je suis conscient du fait qu'un bon design n'est pas quelque chose d'absolu et n'a pas de valeur en soi, mais cela dépend du contexte, et que l'on devrait viser un design qui soit assez bon pour le problème en question.

Par exemple, je ne me soucie pas (trop) d'une bonne conception si je dois implémenter un composant simple qui (1) doit être prêt dès que possible, (2) ne sera utilisé qu'une seule fois, (3) ne sera pas utilisé par d'autres parties du système (YAGNI).

Je me soucie d'une bonne conception lorsqu'un composant (1) sera utilisé plusieurs fois et dans plusieurs versions différentes d'un produit, (2) doit être maintenu et étendu dans le temps, (3) a beaucoup d'autres composants en fonction .

D'un autre côté, développer une fonctionnalité complexe par petits incréments, avec des validations quotidiennes et repenser continuellement le code lorsqu'il n'est pas structuré ne me permet pas de produire un très bon design.

Alors ne fais pas ça.

Tout ne rentre pas dans la belle boîte agile. Souvent, un produit comporte quelques éléments complexes qui ne peuvent pas être distribués à des particuliers et ne peuvent pas être complétés de manière saine dans un sprint. Les forcer dans cette boîte ne causera que des ennuis. Mais ceux-ci devraient être rares. Si vous trouvez que beaucoup de vos composants sont comme ça, votre propriétaire de produit doit travailler à mieux répartir les choses (avec votre équipe). Je vais bien comme ce que vous avez fait: prenez l'histoire, concevez-la, puis martelez-la dès que possible avec l'espoir que cela prendra quelques semaines.

Dans le cas plus général, il y a 3 choses que j'ai vues faire pour obtenir une bonne conception dans Agile:

• En fait, je fais du design - Beaucoup d'endroits que j'ai vus commencent leur sprint et commencent juste à faire du cowboy avec du code. Vous obtiendrez un mauvais design de cette façon. Agile ne change pas le processus de développement de plan - code - test - release, il le raccourcit simplement en morceaux plus granulaires. Au début du sprint, asseyez-vous au besoin et concevez réellement votre solution.

• Avoir un architecte / lead - Une fois que votre projet est assez grand, vous vous retrouverez avec plusieurs équipes Scrum travaillant sur différentes parties de l'application. Il est très utile d'avoir quelqu'un (ou plusieurs personnes selon la taille de l'application) dont le travail principal est de savoir ce que font toutes les équipes du point de vue de la conception. Ils peuvent répondre aux questions et guider les équipes vers une conception globale plus harmonieuse. Faire en sorte que chaque équipe de mêlée ait une avance qui sait la plupart de ce que font les autres équipes, j'ai également vu et a été très efficace.

• Soyez pragmatique - j'ai couvert celui-ci ci-dessus. Agile est un outil, et comme tout outil; cela ne s'applique pas à tous les problèmes. Si cela n'a pas de sens de s'appliquer à un composant, ne l'appliquez pas là. Votre objectif est de livrer de bons logiciels; ne l'oubliez pas.

Il est très possible de l'implémenter par petits incréments et de se retrouver avec un code maintenable bien structuré. En théorie, c'est très simple: si vous vous assurez que le code est bien structuré après chaque changement, il sera toujours bien structuré. Votre code devient mal structuré car vous continuez à ajouter du code alors que vous devriez refactoriser.

Peu importe le temps que vous passez sur la conception, les exigences changeront éventuellement de manière imprévue et vous devrez écrire du code qui ne correspond pas à la conception d'origine. Ensuite, vous devrez effectuer une modification incrémentielle. Si vous disposez d'un bon ensemble de tests unitaires et que vous êtes habile à refactoriser, vous pourrez garder le code bien structuré au fur et à mesure que vous répondez aux nouvelles exigences.

"Bien conçu" est subjectif

Que signifie "bien conçu" pour vous? au propriétaire du produit? au client?

Est « bien conçu » un objectif du propriétaire du produit? un objectif du client? ou juste toi?

Ce que vous considérez comme «pas bien conçu» répond-il toujours aux attentes des propriétaires de produits et satisfait-il le client? Alors c'est plutôt "bien conçu" .

Bon assez et YAGNI

Rien dans la plupart des méthodologies Agile ne parle de "bien conçu", car tout système que le Product Owner accepte les histoires comme complètes et les clients croient qu'il répond à leurs exigences est "bien conçu" .

Il est prévu que les développeurs soient des professionnels et qu'ils utilisent de manière pragmatique les meilleures pratiques, les conceptions et les idiomes appropriés pour implémenter les fonctionnalités et les histoires.

Si vous ne prenez pas en compte le temps de faire les choses correctement, c'est un problème de développeur, si le propriétaire du produit exige des choses en moins de temps que cela puisse être fait, c'est leur prérogative de le faire, et votre responsabilité de les éduquer sur le conséquences sous forme d' histoires techniques de dette .

SCRUM

_{La méthodologie Agile qui peut être écrite, n'est pas la méthodologie Agile. "- Jarrod Roberson}

SCRUM est censé être un cadre d'outils pour gérer le cycle de vie total d'un produit logiciel. Ce n'est pas censé être un ensemble rigide de choses, juste un bon endroit pour commencer et, espérons-le, s'améliorer.

La plupart des magasins dans lesquels j'ai travaillé ont ce qu'on appelle Sprint ZERO, des sprints pour les membres seniors de l'équipe pour esquisser une architecture globale ou un thème du produit.

Les histoires qui dépassent 20 disons sont généralement décomposées jusqu'à ce qu'elles ne soient en réalité que quelques histoires de 3 à 5 points. L'une de ces histoires est la suivante: «En tant qu'équipe, nous devons nous réunir pour discuter de la façon dont nous allons concevoir cette fonctionnalité, afin que nous ayons le moins de dettes techniques possible compte tenu du temps imparti.

Généralement

En général, un système "bien conçu" est assez bon et suit YAGNI.

Agile, et SCRUM en particulier en tant qu'implémentation d'Agile sont plus sur la façon de produire un produit de la manière la plus transparente possible pour le Product Owner / Sponsors.

Il ne s'agit pas de conception technique / architecture sage. Il s'agit plutôt d'une philosophie sur la façon d'aborder la livraison de logiciels qui répondent aux besoins et aux attentes des clients. S'il n'y a pas ce que vous appelez des pièces "bien conçues" , ce n'est pas un défaut en soi, car ce n'est pas un élément fondamental de la philosophie.

Nous travaillons avec Scrum depuis plusieurs mois et je souhaite partager mon expérience concernant votre problème.

Il y a quelques mois, on m'a donné un gros morceau à mettre en œuvre. J'avais toutes les spécifications prêtes, j'ai donc dû implémenter de nouvelles fonctionnalités en conséquence. La tâche devait prendre environ 5-6 semaines (comme je l'ai estimé). J'ai passé la première semaine à travailler uniquement sur le design. La tâche était un peu compliquée: il y avait un objet principal qui, comme je l'ai conclu à partir de la spécification, avait 15 états différents, et l'interface utilisateur devait avoir des comportements différents pour chaque état.

J'ai conçu l'ensemble du flux de travail et la structure et les classes de base de données par la suite.

Je ne vois aucune autre approche dans mon cas. Si j'avais plongé dans le codage à la fois, j'aurais eu un gros gâchis à la fin - presque impossible à maintenir et extrêmement difficile à apporter d'autres changements. Mais les changements sont survenus dans les 2 semaines suivantes, j'ai donc dû retravailler le code. C'était facile maintenant, avec la conception originale. Cela nous a fait gagner du temps, de l'argent et des nerfs.

Après cette expérience, je suis absolument sûr que cela vaut la peine de faire un design acceptable au début, alors j'espère qu'avec un miracle, vous l'aurez à la fin.

Le recul est de 20-20. Si vous aviez les informations à votre disposition au début du projet pour comprendre le tout puis écrire le code en quelques semaines, je vous suggère de le faire.

Vous n'accordez pas suffisamment de crédit à toutes les informations que vous avez acquises, aux approches qui ont été essayées et qui ont échoué / ont dû être modifiées, et à la capacité accrue du client / des utilisateurs à fournir suffisamment de crédit aux exigences.

Pourquoi une personne ayant des antécédents de projets de chute d'eau réussis passerait-elle à une méthodologie agile?

Vous avez toujours besoin d'une vue d'ensemble de ce que devrait être l'objectif final, et des fonctionnalités qui doivent être mises en œuvre et quand, avant de démarrer un projet. Travailler sur des histoires en tant que tâches atomiques demande des ennuis. Vous devez tenir compte autant que possible des besoins futurs.