Comment expliquez-vous à une équipe «agile» qu’elle doit encore planifier le logiciel qu’elle écrit?

Cette semaine au travail, je me suis encore énervé . Après avoir suivi la méthodologie de développement ad hoc standard, agile, TDD, de propriété partagée, de ne jamais rien planifier au-delà de quelques histoires d’utilisateurs sur un morceau de carte, reprochant verbalement les techniques d’une intégration tierce ad nauseam sans jamais rien faire de réel. En réfléchissant ou en faisant preuve de diligence et en reliant architecturalement tout le code de production au premier test qui nous vient à la tête ces derniers mois, nous arrivons à la fin d'un cycle de publication et voici que la principale fonctionnalité visible de l'extérieur que nous avons développée est trop lente pour utilisation, buggy, devenant labyrinthique complexe et complètement inflexible.

Au cours de ce processus, des "pics" ont été réalisés, mais jamais documentés et aucune conception architecturale n'a été produite (il n'y avait pas de système de fichiers, alors quoi, si vous ne savez pas ce que vous développez, comment pouvez-vous planifier ou effectuer des recherches ?) - le projet a été transmis d’une paire à l’autre, chacun ne s’étant concentré que sur une seule histoire d’utilisateur à la fois et le résultat était inévitable.

Pour résoudre ce problème, je suis passé inaperçu, je suis allé à la cascade (redoutée), j'ai planifié, codé et, fondamentalement, je n'ai pas échangé la paire et j'ai essayé autant que possible de travailler seul, en mettant l'accent sur une architecture et des spécifications solides plutôt que sur des tests unitaires. viendra plus tard une fois que tout est bloqué. Le code est maintenant bien meilleur et est en réalité totalement utilisable, flexible et rapide. Certaines personnes semblent avoir vraiment regretté que je fasse cela et aient fait de leur mieux pour saboter mes efforts (peut-être inconsciemment) parce que cela va à l'encontre du processus sacré de l'agilité.

Alors, comment, en tant que développeur, expliquez-vous à l'équipe qu'il n'est pas "agile" de planifier son travail et comment intégrez-vous la planification dans le processus agile? (Je ne parle pas de l'IPM; je parle de résoudre un problème et de dessiner une conception de bout en bout qui explique comment résoudre un problème avec suffisamment de détails pour que quiconque travaille sur le problème sache quoi architecture et modèles qu’ils devraient utiliser et où le nouveau code doit s’intégrer au code existant)

Je pense (et j'y vais peut-être un peu ici) que TOUS les projets devraient comporter un peu de cascade classique: la phase initiale d'analyse et de spécification est essentielle. Vous devez savoir ce que vous faites et vous devez l'avoir par écrit. Obtenir les exigences par écrit est difficile et prend du temps, et il est facile de mal faire. C'est pourquoi tant de gens l'ignorent - n'importe quelle excuse fera l'affaire: "Oh, nous faisons de manière agile, nous n'avons donc pas besoin de le faire." Il était une fois, avant l'agile, c'était "oh, je suis vraiment intelligent et je sais comment résoudre ça, alors on n'a pas besoin de faire ça." Les mots ont un peu changé mais la chanson est essentiellement la même.

C’est bien sûr tout ce que vous voulez: vous devez savoir ce que vous devez faire - et une spécification est le moyen par lequel le développeur et le client peuvent communiquer le but recherché.

Une fois que vous savez ce que vous devez faire - esquisser une architecture. C'est la partie "Obtenez la bonne image". Il n'y a pas de solution magique ici, pas de solution unique, ni de méthodologie qui puisse vous aider. Les architectures sont la SYNTHESE d'une solution et elles proviennent d'un génie en partie inspiré et d'une connaissance en partie durement acquise.

Il y aura itération à chacune de ces étapes: vous trouverez des choses fausses ou manquantes, et allez les réparer. C'est le débogage. C'est juste fait avant que tout code soit écrit.

Certains voient ces étapes comme ennuyeuses ou inutiles. En fait, ces deux étapes sont les plus importantes pour la résolution de tout problème: résolvez-les et tout ce qui suit sera faux. Ces étapes ressemblent aux fondations d'un bâtiment: ne vous y trompez pas et vous avez une tour penchée de Pise.

Une fois que vous avez le WHAT (c'est votre spécification) et le HOW (c'est l'architecture - qui est une conception de haut niveau), alors vous avez des tâches. Habituellement beaucoup d'entre eux.

Décompressez les tâches comme vous le souhaitez, attribuez-les comme vous le souhaitez. Utilisez la méthode de la semaine que vous aimez ou qui vous convient. Et effectuez ces tâches en sachant où vous allez et ce que vous devez accomplir.

En chemin, il y aura de fausses pistes, des erreurs, des problèmes rencontrés avec les spécifications et l'architecture. Cela provoque des choses comme: "Eh bien, toute cette planification était alors une perte de temps." Qui est aussi taureau. Cela signifiait simplement que vous avez MOINS de problèmes à traiter plus tard. Lorsque vous rencontrez des problèmes avec les problèmes de débuts de haut niveau, corrigez-les.

(Et sur une question de côté: il ya une grande tentation que j’ai vue à maintes reprises d’essayer de répondre à une spécification coûteuse, difficile, voire impossible. La réponse correcte est de demander: "Ma mise en œuvre est-elle en panne, ou "Parce que si un problème peut être réglé rapidement et à moindre coût en le modifiant, c’est ce que vous devez faire. Parfois, cela fonctionne avec un client, parfois non. Mais vous ne saurez pas si vous ne demande pas.)

Enfin - vous devez tester. Vous pouvez utiliser TDD ou tout ce que vous préférez, mais rien ne garantit qu’à la fin, vous avez fait ce que vous aviez dit que vous feriez. Cela aide, mais cela ne garantit pas. Donc, vous devez faire le test final. C’est la raison pour laquelle des éléments tels que la vérification et la validation demeurent des éléments importants dans la plupart des approches de la gestion de projet - qu’il s’agisse du développement de logiciels ou de la fabrication de bulldozers.

Résumé: Vous avez besoin de tout ce qui est ennuyeux au début. Utilisez des éléments tels que Agile comme moyen de livraison, mais vous ne pouvez pas éliminer la pensée, la spécification et la conception architecturale démodées.

[Vous attendez-vous sérieusement à construire un bâtiment de 25 étages en affectant 1 000 ouvriers sur le site et en leur demandant de former des équipes pour effectuer quelques travaux? Sans plans. Sans calculs structurels. Sans conception ni vision de ce à quoi le bâtiment devrait ressembler. Et avec seulement savoir que c'est un hôtel. Non, je ne le pensais pas.]

Je suis toujours étonné que beaucoup de gens pensent que TDD signifie d'abord écrire des tests unitaires. Non, cela signifie que vous devez passer des tests avant d’écrire le code. Le test peut en réalité être un test unitaire, un test d’intégration, un test de bout en bout et bien sûr un test de performance (vous n’écrirez probablement pas de test de performance avant le code testé, mais cela ne signifie pas que vous ne devez pas l’écrire du tout). Le type de test requis doit être visible dans la définition de done pour la user story. Si l'un des critères d'acceptation de la user story indique que cette fonctionnalité doit fournir le résultat dans un délai de 500 ms avec 50 utilisateurs simultanés, elle ne peut pas être considérée comme terminée tant que vous n'avez pas passé un test de performance prouvant que ce critère d'acceptation est satisfait. Une fois que vous avez le test automatique, vous pouvez vérifier chaque jour que le test passe, au fur et à mesure que vous ajoutez d'autres fonctionnalités.

Il semble plus que vos critères d'acceptation n'aient pas été définis correctement et que, de ce fait, vous ne puissiez pas tester vos performances. Néanmoins, il peut arriver que l’application fonctionne mal une fois que vous l’aurez déployée dans l’environnement réel et que vous l’utilisez sous une charge importante, mais cela peut toujours être considéré comme un échec des exigences (si l’exigence n’est pas définie, le développeur ne la prend pas à l’esprit lorsqu’il travaille sur code) ou de l'équipe de développement (tests insuffisants par rapport aux exigences définies).

Une autre chose intéressante est que les développeurs de votre équipe se concentrent sur une seule expérience utilisateur. Agile concerne la communication. Les développeurs doivent donc communiquer les exigences des user stories et leur incidence sur le reste de l'application. La collaboration est essentielle. Le test doit couvrir cela également. Ainsi, si un développeur casse la fonctionnalité nécessaire pour une autre user story, celle-ci doit être visible dans les tests automatisés. Si vous pensez toujours que cela ne suffit pas ou que cela ne fonctionne pas, vous pouvez introduire une réunion d'architecture où toute l'équipe coopère et discute de l'architecture de l'application. Il suffit généralement de se réunir une fois par semaine.

Une grande partie du processus en cascade est remplacée par des tests de communication et automatiques. Personne ne dit que vous ne pouvez écrire aucune documentation ou conception de haut niveau! Vous pouvez et de nombreuses équipes utilisent par exemple Wiki pour cela.

[notre produit était] trop lent à utiliser, buggy, devenant complexe et complètement inflexible.

Cela n’a rien à voir avec l’agilité, c’est le signe que les programmeurs ne font pas leur travail correctement.

Une idée de base de l'agilité est que l'équipe contrôle totalement le processus. Cela signifie qu'ils doivent s'entendre sur le montant de planification, de documentation, de test et sur la manière dont ils traitent le refactoring. Tout ce pouvoir est formidable, mais cela implique aussi des responsabilités et c'est probablement là que votre équipe a échoué. Ils ont accepté leur liberté, mais ont négligé leurs responsabilités.

En fin de compte, il suffit d'expliquer la qualité du code et d'essayer de s'entendre sur un moyen de l'augmenter et de le conserver de cette manière. Les pratiques de programmation normales s'appliquent, vraiment.

Conseil pro: utilisez votre "Définition de Terminé" pour appliquer ceci. Assurez-vous que tout le monde est d'accord et placez-le visible pour tout le monde. Utilisez-le comme un gardien de porte strict pour décider si une histoire est terminée ou non. Il est même possible d'ajouter des exigences non fonctionnelles (comme des performances) à cette liste.

Ouais. Vos coéquipiers sont des idiots. Votre projet a échoué à cause de Agile. Se sentir mieux? Ok, passons à autre chose. : P

Je pense que vous et votre équipe serez en mesure de communiquer plus efficacement sur ce qui ne va pas si vous vous concentrez moins sur les noms de vos méthodologies Capital-M et davantage sur les raisons pour lesquelles le logiciel que vous avez écrit était si lent et si bogué. Ne pas utiliser les termes Agile ou cascade du tout. Ils sont clairement chargés d'émotion dans votre bureau.

Agile fonctionne parfois. Cela n'a pas fonctionné pour votre équipe cette fois. Certaines personnes diront que c'est parce que vous avez mal agile. Après tout, Agile fonctionne. Si vous l’aviez bien fait, cela aurait fonctionné, non? Peu importe.

Il ne semble pas que quiconque soit en désaccord avec l'échec, mais vous n'allez pas gagner d'amis, influencer les gens ou faire mieux la prochaine fois si vous blâmez une méthodologie. Cela a probablement peu à voir avec ce qui a mal tourné.

Concentrez-vous plutôt sur les causes les plus directes de l’échec et collaborez avec l’équipe pour faire en sorte qu’elles ne se reproduisent plus. Cela nécessitera des compétences de personnes.

En parlant de compétences relationnelles, vous ne devriez pas être surpris que votre équipe n’ait pas apprécié que vous leur donniez une mauvaise image en faisant tout leur travail et en le faisant mieux qu’elles ne l’avaient fait. En faisant cela "sous le radar", vous aurez peut-être endommagé certaines relations que vous devrez maintenant reconstruire pour devenir un membre efficace de l'équipe.

Je pense que la meilleure façon de regarder une situation comme celle-ci est de considérer le rendement total à long terme de l'équipe dans son ensemble. Vous avez peut-être économisé la semaine cette fois-ci, mais vous avez peut-être fait mieux pour votre entreprise à long terme en constituant une meilleure équipe .

Je vous raconte toutes ces choses, mais je pense que vous connaissez probablement déjà la plupart d'entre elles et que vous pourriez les expliquer à quelqu'un d'autre si vous n'étiez pas si près de cette situation.

Si vous souhaitez ajouter une citation pithy à vos discussions, Eisenhower en avait une bonne:

"Les plans ne sont rien; la planification est tout."

http://www.brainyquote.com/quotes/quotes/d/dwightdei149111.html

Il voulait dire que vous devriez vous attendre à changer vos plans et à ne pas donner trop de valeur au plan tel qu'il existe, mais en même temps, le processus de planification concentrera vos énergies de manière cruciale. Vous devez faire des plans avant de pouvoir les tester et les affiner.

+1 C'est la meilleure description de l'entreprise agile que j'ai lue récemment.

Tous ceux qui s'entendent avec agilité soulignent que cela n'a jamais été supposé vouloir dire cela, mais une fois que tout le monde est pris dans les mesures, c'est exactement ce que vous obtenez d'une équipe qui n'a aucune passion pour la qualité du produit et qui est obsédée par testez la couverture par-dessus tout ou respectez les délais de livraison hebdomadaires, quel que soit le coin où ils ont décrit tout le monde, car c’est tout ce qui se rend au niveau de la direction sur une base hebdomadaire.

Je n'ai jamais vu cela réglé avec rien de moins qu'une réorganisation. Si vous êtes une entreprise de taille moyenne avec rien de spécial pour attirer des gens vraiment passionnés, cela ne réglera rien à moins que la prochaine direction modifie parfois les méthodologies.

Agile ne semble bien fonctionner que dans les organisations où l'équipe de développement se préoccupe suffisamment de créer un bon produit malgré le travail supplémentaire non crédité requis. Effectivement, ils doivent prendre suffisamment soin de leur temps, se battre pour s'améliorer (et être prêts à passer beaucoup de temps supplémentaire à refaire les tests dans certains cas de TDD).

De toute évidence, vous vous souciez de l’expédition d’un bon produit. Ils tiennent également à passer en revue un ensemble de motions et à recevoir un chèque de règlement pour nettoyer en permanence les dégâts causés.

Je chercherais un emploi moins irritant ailleurs, que ce soit agile ou non.

Si vous êtes complètement fatigué en agile, de nombreux endroits utilisent encore d'autres méthodologies. Presque tout sur l'offre ou le contrat par exemple.

J'ai tendance à utiliser une sorte d'hybride. Le plan général est une chute d'eau, mais l'exécution est agile.

Je suppose que si la situation est aussi difficile que vous le dites, votre équipe n’utilise pas vraiment l’agilité, elle est simplement paresseuse ou indisciplinée. Agile ne consiste pas à ne pas planifier, mais à être flexible et, bien, agile.

Nous avons les mêmes problèmes avec certains membres du personnel.

Fondamentalement, "je ne sais pas jusqu'à ce que je l'écrive" est une déclaration favorite. Nous avons donc inversé la tendance, nous avons travaillé avec le client pour définir les produits à livrer avec des points d'approbation. Le dernier étant "maintenant écris le code pour faire X".

Si nous avons "écrire conception / test / plan etc." dans le même sprint livrable que "faire du code amusant et intéressant", la première partie ne se produit jamais ...

MAIS si je place "vous ne pourrez pas faire de code amusant et intéressant tant que vous n’aurez pas dit ce que vous allez construire et que le client l’a approuvé", puis

• vous obtenez d’abord une acceptation grincheuse et quelques larmes et je devais faire beaucoup de travail pour combler les blancs et un effort supplémentaire…
• alors vous obtenez une reconnaissance naissante lorsque vous leur demandez "alors comment était le processus" qu'il vaut mieux avoir essayé la première version sur papier
• vous avez ensuite les cas de test que les développeurs peuvent voir, et vous pouvez indiquer exactement ce que vous attendez de "ce que fait fait signifie".
• alors les clients signent que le développement a un taux de rejet inférieur de 80% ...
• De plus, vous regardez tous les développeurs se promener avec les documents de conception et discuter entre eux des conceptions ... ils commencent vraiment à comprendre.
• Ensuite, vous déterminez comment décomposer le plan de projet en petits morceaux et en faire un processus.

La partie agile vient lorsque le client change de plan et que vous pouvez vous adapter en un cycle de 2 semaines NE PAS voler par le siège de votre pantalon et le maquiller en chemin.

Dans notre cas, le «gros projet initial» a été divisé en 9 étapes (versions de production réelles) avec une moyenne de 5 sous-étapes. Les concepteurs et les développeurs suivent le rythme, les concepteurs ayant une avance de 1 à 3 étapes sur les développeurs ... trop loin et les découvertes en matière de développement pèsent trop lourd dans la conception, trop proches et ajustant leurs coûts de manière à en réduire les coûts. déjà mis en œuvre "immuable" dans le développement. Chaque sous-étape correspond à 2 à 4 sprints valables pour 1 développeur.

Dans les projets plus petits, nous avons simplement le même développeur qui crée d'abord> signer> facture> développer> signer> facture ... en cycles.

Le problème de nommage des tests

Les tests ont de nombreuses facettes. Il existe formellement environ 7 catégories de tests, chacune avec des sous-sections ... L’une de ces dernières est "écrire des tests unitaires automatisés".

C'est une mauvaise réputation d'avoir "test d'abord le développement" uniquement parce que les développeurs comprennent ce que "tests" signifie dans ce contexte, ils voient les tests comme écrivant le code réel pour le test contre l'interface pour l'implémentation. Quand ce n’est pas vraiment du tout… vous pouvez le faire quand il s’agit d’écrire le code, mais c’est vraiment "valider la conception contre les cas d’utilisation et les user stories AVANT de commencer à écrire le code" ... fait correctement, cela enlève beaucoup des problèmes normalement découverts lors du développement alors que sa version encore moins chère du "papier qui peut être jeté".

L'un des éléments clés d'Agile est l'idée d'amélioration continue et l'idée que toute l'équipe est propriétaire du projet. La bonne approche aurait donc été d’examiner les problèmes avec l’équipe et de demander à l’équipe de décider comment la corriger.

Un membre de l'équipe qui s'éloigne de lui-même, abandonne tous les principes de l'Agile et fait les choses à sa manière peut faire en sorte qu'une petite quantité de code fonctionne bien, mais ne fait pas avancer le projet dans son ensemble de manière positive.

Une façon de les faire fonctionner est de créer un T-Map couvrant l’ensemble de votre historique de sprint.

Chaque équipe a un fil, chaque sprint est une période. Tout cela est lié (c'est là que votre équipe semble tomber). Épinglez-le quelque part et demandez à des aimants de représenter les paires / sous-équipes. Ils peuvent même «faire la course». Mais tout le monde sait où ils se trouvent, ainsi que les autres équipes. Mettez les dépendances ici s'il y en a.

Le point ici est que vous transmettez le processus total mais que vous le divisez également en sprints. Même si seul le premier sprint est enregistré, et que les autres périodes sont vierges, cela devrait être une excellente feuille de route pour terminer le projet.

Vous avez deux problèmes: pas assez de forme sur les exigences et une architecture médiocre.

Exigences

Vous avez besoin d'un objectif final et d'une feuille de route détaillée pour y parvenir.

Dans le monde des cascades, l'objectif final est la spécification fonctionnelle, et la feuille de route indiquant comment s'y rendre est le plan du projet.

Dans le monde agile, une solution consiste à capturer cette information dans une histoire d'utilisateur épique. Ensuite, la feuille de route est constituée des histoires d'utilisateurs détaillées qui étoffent les détails de l'épopée.

Je n'ai jamais été complètement heureux avec cette histoire, parce que l'histoire épique ne capture jamais assez de viande pour faire passer toute l'idée. J'ai donc eu tendance à utiliser un document de configuration système de haut niveau associé à une ou plusieurs histoires d'utilisateur épiques. Après cela, la feuille de route est constituée des histoires d'utilisateurs détaillées.

L'avantage d'un document sur les exigences des systèmes est que les critères d'acceptation de la plupart des user stories peuvent être définis.

Considérez le document d'exigences système de haut niveau comme une "feuille de calcul" que le marketing pourrait utiliser pour vendre le produit à un client techniquement averti.

Architecture

Une des choses que vous donne la "feuille de coupe" est qu’elle définit des limites sur le système que vous concevez. Cela vous permet de prendre rapidement des décisions éclairées sur l'architecture à utiliser.

Si votre équipe avait reçu un tel document à un stade précoce, vous n’auriez pas à refaire la tâche de réorganiser le système plus tard.

En fait, un troisième problème que vous avez est une mauvaise communication. La communication est une voie à double sens (ou à plusieurs sens entre plusieurs personnes). Cependant, il ne s'agit que d'un échec humain et nécessite (parfois) des efforts surhumains pour bien faire les choses.