Table des matières:
Être une équipe de développement logiciel agile signifie certainement des choses différentes pour différentes personnes. Il y a des degrés d'adoption sur un très large spectre, avec apparemment très peu d'organisations qui pensent bien le faire. Selon l'enquête State of Agile de VersionOne (publiée en avril 2017), 80% de leurs répondants déclarent être «à un niveau encore en cours de maturation ou en dessous». Malheureusement, les équipes de développement ne mettent souvent pas beaucoup d'efforts dans la partie «apprendre» de l'itération. Nous voulons nous dépêcher et terminer les cérémonies Scrum afin de pouvoir recommencer à écrire du code. Après tout, il y a tellement de travail à faire! Mais le temps de codage insuffisant est-il vraiment le problème?
Pour beaucoup d'entre nous, la lutte contre les incendies pourrait tout aussi bien être mentionnée spécifiquement dans notre description de poste. Nous allons travailler tous les jours en sachant que nous devons être prêts à glisser le long du poteau à tout moment, à attraper nos chapeaux et à sauter dans le camion. Nous acceptons les choses telles qu'elles sont, et nous supposons que nous ne pouvons rien y faire. Mais que se passe-t-il si la cause profonde de nos luttes est un grave manque d'efficacité? Tout le monde sait combien il est important de faire mieux que cette autre entreprise là-bas. Nous n'arrivons tout simplement pas à y arriver - nous ne semblons pas avoir la bande passante. Les gestionnaires ajoutent plus de personnes et augmentent la taille de leur organisation et ont toujours les mêmes difficultés. Vous n'arrivez pas à vous en remettre parce que vos équipes ne développent pas de logiciels efficacement (et vous n'êtes pas seul).
Principes d'un développement efficace
Pixabay
Alors, qu'est-ce qui nous rend inefficaces? Pour la plupart d'entre nous, la première chose qui vient à l'esprit est le manque d'automatisation (builds automatisés, déploiements, tests). «Une fois que nous aurons suffisamment d'automatisation, la vie s'améliorera.» Malheureusement, ce n'est qu'une partie de la solution. Considérez l'effet des retouches sur votre projet. Le moyen le plus efficace de créer une fonctionnalité est de la créer une fois correctement et de ne jamais revenir en arrière et de la toucher à nouveau. Les bugs, la refactorisation et d'autres activités similaires rouvrent essentiellement le patient après qu'il a quitté la salle d'opération et il y a un risque inhérent associé à cela. Nous ne pouvons pas éliminer les retouches, mais nous devons certainement nous efforcer de les minimiser.
"Mais est-ce que Agile n'admet pas le retravail (ex. Refactoring)? C'est en fait le cas, car les créateurs d'agile ont compris que les deux principales causes de retouche sont des circonstances imprévues et des exigences commerciales changeantes. Il s'avère que les humains sont terribles pour prédire l'avenir. Les créateurs agiles ont également compris qu'un énorme contributeur à l'inefficacité est ce que les développeurs appellent le «plaquage or» - contenant des fonctionnalités que nous pensons que quelqu'un utilisera même si les utilisateurs finaux ne l'ont jamais demandé. C'est comme du porc pour votre logiciel - une perte de temps totale. "Ne construisez pas de station spatiale alors qu'ils ne demandent qu'une Volvo." Ainsi, les entreprises ont judicieusement commencé à laisser de côté le porc et à adopter la refactorisation à la place, ajoutant uniquement des fonctionnalités lorsque le besoin était clair. Mais l'imprévisibilité de la vie n'est pas le seul facteur de reprise, n'est-ce pas?
Les détails manqués à n'importe quelle étape du développement des fonctionnalités feront perdre du temps et de l'argent. Collaborer efficacement dès le départ vous évitera au fil du temps une tonne de retouches (gestion des exigences manquées, conception à courte vue, etc.). Nous avons tous des angles morts et nous avons tous besoin de paires d'yeux supplémentaires. De nombreuses équipes de développement adoptent cela en arrière-plan lors de la révision du code, mais consacrent beaucoup moins d'énergie à collaborer dès le début lorsque les problèmes peuvent être résolus à moindre coût et après un investissement minimal.
Combien de fois avez-vous implémenté une fonctionnalité et trouvé des failles importantes vers la fin qui auraient dû être détectées lors des discussions sur les exigences / la conception? C'est comme essayer de conduire d'Atlanta à Montgomery et réaliser plusieurs heures après le voyage que vous vous êtes rendu accidentellement à Birmingham. Combien de temps a été passé à essayer d'obtenir le code juste pour rouvrir le patient plus tard parce que des exigences importantes ont été manquées? Tirer parti de l'intelligence collective permettrait de gagner du temps et de l'argent, mais au lieu de cela, les développeurs travaillent souvent sur des fonctionnalités de manière isolée.
Essaimage traditionnel
Pixabay
L'essaimage traditionnel signifie que l'équipe travaille en collaboration sur des histoires avec plusieurs personnes travaillant sur une petite fonctionnalité en même temps, raccourcissant la boucle de rétroaction et réduisant le temps d'achèvement global de la fonctionnalité (c.-à-d. Diviser pour conquérir). Cela grouille essentiellement au sein de chaque discipline (développeurs backend, développeurs UI, etc.). Avant le début du développement, les développeurs de l'interface utilisateur s'emploient à identifier les tâches indépendantes pouvant être effectuées simultanément. Ils discutent des points d'interface afin que chacun sache comment sa pièce s'intègre dans l'ensemble. Les membres de l'équipe peuvent alors procéder à l'achèvement des tâches qui leur ont été assignées et tout rassembler à la fin lors de l'intégration. Des commits fréquents et des révisions périodiques du code permettent de s'assurer que tout reste sur les rails. Cette approche nécessite une collaboration entre les développeurs,ce qui aide à produire un meilleur résultat final de toute façon. Nous accordons souvent la priorité au temps passé à écrire du code (n'importe quel code) par rapport au temps passé à nous assurer de ne pas écrire le mauvais code. Lorsque vous considérez le temps potentiellement économisé, la valeur devient claire.
Se débloquer
Pixabay
Une autre approche intéressante de l'essaimage consiste à concentrer l'équipe dès le début sur l'atténuation des dépendances afin de faciliter le développement simultané entre les disciplines. Considérez le flux de développement naturel d'une fonctionnalité d'interface utilisateur. Les testeurs d'automatisation (SDET) dépendent d'une interface utilisateur fonctionnelle pour tester, les développeurs d'interface utilisateur dépendent d'une API backend fonctionnelle et les développeurs backend dépendent de la configuration, des mises à jour de base de données et des builds / déploiements automatisés. Ainsi, les développeurs d'interface utilisateur peuvent ne pas commencer leur travail tant que les API ne sont pas terminées et les SDET peuvent ne pas commencer leur travail tant que la fonctionnalité n'est pas terminée. Chaque discipline travaille de manière isolée, ce qui entrave la collaboration car les personnes avec lesquelles vous devez interagir sont occupées à travailler sur d'autres choses.Mais que se passerait-il si vous pouviez atténuer les dépendances plus tôt et permettre aux disciplines de travailler toutes simultanément sur la même fonctionnalité?
Voici quelques exemples:
1. Interface utilisateur fonctionnelle déployée avec stubs
Afin de débloquer les SDET, les développeurs d'interface utilisateur peuvent leur donner une interface utilisateur fonctionnelle qui fonctionne juste assez pour leur permettre d'écrire des tests. L'intégration de l'API backend et les styles CSS peuvent toujours être en attente, car les frameworks de test automatisés comme Selenium ne se soucieront pas si ces choses ne sont pas terminées. Tout cela peut être de la fumée et des miroirs. Bien que des changements puissent survenir et entraîner des retouches, l'avantage de commencer les tests tôt l'emporte sur ce risque.
2. API backend déployées (données stubbed, codées en dur)
Fournir des API backend que les développeurs d'interface utilisateur peuvent tester permet une détection précoce des problèmes d'intégration entre le frontend et les API. Parfois, vous découvrez que l'API fournie ne répond pas aux besoins des développeurs frontaux. Des appels entiers peuvent manquer, la signature peut être erronée ou la structure des données peut avoir des problèmes. S'il y a une déconnexion, autant le découvrir tôt avant que quoi que ce soit ne se soit durci.
3. Créez une version HelloWorld des nouvelles applications et services.
Si un nouveau service est nécessaire (ex. Un microservice), créez le référentiel et construisez une version «hello world» du service. Cela permet aux ressources dev-ops de démarrer sur les travaux Jenkins et les scripts de déploiement avant que le service ne soit réellement développé.
Ces optimisations facilitent une boucle de rétroaction précoce où quelqu'un peut dire «j'ai besoin de quelque chose de différent» avant que le développement ne soit terminé sur le composant qui nécessite le changement.
Emballer
Il est extrêmement important que nous trouvions comment raccourcir les délais de mise sur le marché des fonctionnalités sur lesquelles nous travaillons. L'entreprise n'a aucune valeur à avoir un tas de fonctionnalités en cours de développement, et les développeurs ont désespérément besoin de fonctionnalités à implémenter rapidement afin que les défauts puissent être résolus aussi près que possible du point d'injection. Les développeurs ont aussi désespérément besoin d'interagir les uns avec les autres, même s'ils veulent vraiment écrire du code. C'est mieux pour toutes les personnes impliquées, y compris l'utilisateur final qui veut juste un meilleur produit. Si vous ne leur donnez pas, ils iront ailleurs pour le trouver.
L'essaimage est un outil extrêmement précieux dans la boîte à outils de votre organisation, si les gens prennent le temps d'apprendre à le faire. Ce n'est pas un cadre ni même une activité - c'est un état d'esprit. Pour chaque user story, les membres de l'équipe se posent deux questions:
- Comment organiser les tâches de cette histoire pour que plusieurs personnes contribuent à la fois?
- Quel est le minimum que je dois faire pour débloquer quelqu'un qui m'attend?
Et si votre équipe construisait rapidement des fonctionnalités ensemble plutôt que de construire lentement un ensemble de fonctionnalités indépendamment? Ils pourraient en fait répondre aux besoins changeants de l'entreprise et répondre aux besoins de l'entreprise lorsque l'entreprise en a besoin. Les concurrents auraient peur de vous - les clients vous aimeraient. C'est la recette d'une entreprise prospère.
© 2017 Mike Shoemake