Devenir Agile
Je suggérerais ce qui suit:
Éditer les mêmes fichiers
Tout d’abord, utilisez Git (ou un système de gestion de versions simultané similaire). Tant que vous éditez différentes parties des mêmes fichiers, vous ne rencontrerez pas de conflits. Si vous obtenez des conflits, ils seront clairement identifiés comme tels.
Essayer de gérer un projet multi-développeurs sans Git, c'est comme essayer de faire un pudding sans bol de pudding. C'est possible, mais ça va devenir assez compliqué.
Comme il a été souligné dans les commentaires, Git n’est pas une panacée, mais combiné à des tests automatisés, il est certainement très utile.
Lister toutes les fonctionnalités
Deuxièmement, divisez le projet en fonctionnalités visibles par l'utilisateur. Par exemple, "lorsque l'utilisateur s'inscrit, il devrait recevoir un courrier électronique" ou "L'utilisateur peut ajouter un élément". Impliquez toutes les parties prenantes ici. Rassemblez tout le monde dans une pièce et invitez tout le monde à crier ses traits.
Celles-ci doivent être des fonctionnalités visibles par l'utilisateur, vous pouvez parler de la stratégie de mise en œuvre plus tard.
Ecrivez toutes les suggestions sur des fiches, même les plus stupides. Rationalisez rapidement la liste pour supprimer les doublons et disposez toutes les cartes sur une grande table, voire au sol.
Ajoutez toutes les cartes supplémentaires nécessaires. Supposons que votre application envoie des alertes par SMS. Vous ne savez peut-être pas comment faire cela, alors vous avez une question. Ecrivez "Enquêter sur les portails SMS" sur une carte. De même pour toutes les autres grandes inconnues. Vous devrez les décompresser plus tard. Ces fonctionnalités ne feront probablement pas partie de votre premier sprint.
Maintenant, triez vos cartes en groupes, mélangez-les, essayez -les. Ceci est la portée de votre projet.
Planification du poker
Essayez de planifier le poker. Toujours avec tout le monde, donnez à tous les développeurs des cartes indiquant "1 point", "2 points", etc., jusqu'à "4 points". Aussi une carte "plus". Un point équivaut à peu près à une heure.
Parcourez la liste des fonctionnalités une à une. Lorsque vous lisez une fonctionnalité, tout le monde doit jouer une carte. Si une personne joue à 1 et une autre personne à 4, il y a un problème de communication. Une personne comprend que la fonctionnalité signifie quelque chose de différent de l'autre personne. Ayez une discussion, déterminez ce que vous voulez réellement dire et notez-le sur la carte.
Si vous convenez qu'une fonctionnalité est un "plus", cette fonctionnalité est trop grande. Vous devez décomposer cette fonctionnalité. Faites cela de la même manière que précédemment.
Avec votre accord, écrivez les numéros sur les cartes dans un stylo de couleur différente.
Les points valent mieux que les heures
Utiliser des points au lieu de plusieurs heures enlève au macho ce que nous, les développeurs, faisons souvent dans le code. C'est une différence subtile, mais j'ai trouvé que cela fonctionnait plutôt bien.
Maintenant, composez un sprint
Un sprint est un coup d'éclat rapide vers un but. Décidez de la durée du sprint, peut-être 5 ou 10 jours. Multipliez le nombre de jours par le nombre de développeurs par le nombre de points par jour.
Supposons initialement 6 points par jour et par développeur. C'est un nombre réalisable. Si vous avez 5 personnes, cela fait 5 * 5 * 6 = 150 points. En collaboration avec tous les développeurs et la direction, sélectionnez des fonctionnalités dans la liste, jusqu'à 150 points. C'est ton sprint.
Ne soyez jamais tenté de faire plus que ce qui convient. Une promesse excessive nuit à tout le monde, y compris à vous.
Vous devrez tenir compte des dépendances ici. Par exemple, la configuration de l'environnement doit évidemment être incluse dans le premier sprint. C'est en fait relativement facile à faire quand tout le monde est présent. Vous avez 6 cerveaux dans la pièce, tous disant "ça dépend de ça", etc. Vous pouvez ensuite mélanger les cartes pour démontrer les dépendances.
Une fois que vous avez votre sprint, rien ne peut y être ajouté, il est verrouillé pour les 5 jours. Le glissement de fonctionnalités va stresser l’équipe, nuire au moral et ralentir tout le monde. Finalement, le fluage va bloquer un projet. En tant que chef d'équipe, vous devez protéger votre équipe contre le glissement des fonctionnalités. Si une nouvelle demande de fonctionnalité arrive, elle doit être ajoutée au prochain sprint. Si le prochain sprint est déjà complet, quelque chose d'autre doit être retiré.
Ne jamais être tenté de serrer dans les extras. Une promesse trop longue vous donne environ 1 jour de client heureux, suivi de 4 jours de stress pour l’équipe et, éventuellement, de plusieurs clients mécontents lorsque l’équipe ne peut pas livrer à temps.
Maintenant, allez-y.
Distribuez des cartes, demandez qui veut faire quoi. Vous avez une visibilité totale sur ce qui se fait et vous pouvez compter les points à zéro. Ayez un stand up au début de chaque journée pour que tout le monde sache qui travaille sur quoi et ce qui a été fait.
Cinq ou six développeurs motivés qui travaillent ensemble pour former des objectifs gérables clairement définis peuvent réaliser une quantité assez importante de choses en un sprint de cinq jours.
Maintenir la visibilité
Assurez-vous que tout le monde peut voir quel est le statut du projet. Bluetack toutes les cartes au mur. Sur la gauche sont des cartes qui ne sont pas encore travaillées. A droite sont faites les cartes.
Lorsqu'un développeur travaille sur une carte, il la décolle et la pose sur son bureau. Cela préserve la visibilité et empêche les gens de marcher trop lourdement sur les pieds.
Il existe des alternatives technologiques aux fiches, mais rien ne vaut un affichage papier massif de l'état du projet sur le mur.
Si possible, placez tout le monde dans la même pièce pendant toute la durée du projet. Avoir les parties prenantes autour autant que possible, idéalement tous les jours.
Incendier
Vous pouvez représenter graphiquement vos points progressant vers zéro sur un graphique de burndown. Si votre ligne de meilleur ajustement dépasse zéro avant de respecter votre limite de temps, vous êtes probablement sur la bonne voie. Sinon, vous devrez peut-être informer votre client maintenant avant de vous approcher trop près de la date limite.
Si vous échouez, échouez tôt.
Vous pouvez créer un burndown à l'aide d'un logiciel, mais je préfère un gros morceau de papier au mur. Dessine et écris partout.
Test automatisé
Lorsque plusieurs développeurs travaillent simultanément sur le même matériel, ils vont probablement se casser le code les uns des autres de temps à autre. La communication et la visibilité aident à cela, mais vous allez probablement vouloir introduire une technologie pour vous aider à trouver des problèmes.
Le test unitaire est le processus d'écriture de tests pour chaque partie individuelle de votre base de code (idéalement pour chaque méthode). Vos tests unitaires doivent être exécutés souvent, avec chaque sauvegarde si possible. Il existe de nombreux outils qui peuvent aider à cela, par exemple Karma ou Rspec.
Les tests de bout en bout consistent à tester votre projet dans son ensemble, en traitant les éléments internes comme une boîte noire. Basez ces tests sur vos exigences professionnelles de haut niveau, par exemple: "L'utilisateur peut s'inscrire" ou "L'utilisateur peut voir une liste d'éléments". Protractor est un bel exemple de framework de test basé sur le Web.
Il existe des livres entiers sur les tests, mais la mise en place d'au moins quelques tests d'acceptation peut vous aider à vous assurer que rien ne se brise pendant que vous travaillez sur votre projet.
Éviter la dette technique et se faire fini
La dette technique est un concept qui décrit des choses qui devront être nettoyées plus tard. Une source commune d’endettement est constituée de caractéristiques qui ont été marquées comme étant terminées, mais qui n’ont jamais été "réalisées". Une fonctionnalité terminée est vérifiée dans Git, approuvée par la partie prenante et soumise à un test.
Ne cochez pas vos fonctions jusqu'à ce qu'elles soient terminées. Ne jamais masser le graphique. Encore une fois, cela fait mal à tout le monde à long terme, y compris à vous.
C'est l'une des raisons pour lesquelles nous ne citons initialement que 6 points par développeur et par jour. Done-done demande un travail supplémentaire, mais se sent bien et donne un coup de pouce à l'équipe.