Comment mettre en œuvre le développement Agile dans une équipe de travail?

Question

Nous avons une équipe de travail de 3 développeurs PHP, 1 scripteur (Javascript) et 1 architecte. Aucun d'entre nous n'a d'expériences réelles avec le développement Agile de l'une de nos équipes précédentes. Ma question est de savoir comment implémenter efficacement le développement Agile dans notre équipe? Qu'est-ce qu'on devrait faire en premier? Quelles sont les prérequis? Devrions-nous mettre en œuvre tout à la fois ou petit à petit? Quels principes devrions-nous mettre en œuvre plus tôt et lesquels plus tard?

Un autre problème est que nous manquons actuellement un membre supplémentaire et que nous ne pouvons tout simplement pas faire notre travail à temps. Devrions-nous nous pousser et travailler par exemple 30 minutes de plus chaque jour ou tout simplement passer par une règle Agile pas plus de 8 heures par jour? Quelles sont vos expériences avec "combattre avec la direction" dans de tels cas? Ils ont l'impression que nous n'avons pas besoin d'un membre supplémentaire, mais je refuse tout simplement de travailler le week-end ou de ne plus travailler.

Answer 1

« Agile » et « longues heures de travail » sont des concepts orthogonaux. Travailler sur une équipe Agile ne signifie pas que vous commencez à 9 et terminez à 5, peu importe quoi. S'attaquer à une culture d'équipes surchargées et sous-financées est un défi différent de l'introduction de l'Agile, et dans un tel environnement, il peut être difficile d'effectuer des changements.

Je commencerais par examiner pourquoi vous êtes surmené. Est-ce parce que vous avez des échéances critiques qui ne peuvent pas changer, et votre équipe (gestion incluse) n'est pas bonne à la planification, alors vous finissez avec des tirets fous à la fin? Ou est-ce parce que la direction ne respecte pas le travail que vous faites?

Si votre équipe ne sait pas planifier alors Agile peut avoir une certaine valeur. Agile peut vous aider à identifier que vous êtes en retard précédemment, de sorte que vous avez plus de temps pour réagir. Cela peut aussi vous aider à rester concentré: selon mon expérience, il est facile pour les développeurs d'être inefficaces ou improductifs au début de longs cycles de publication car il n'y a pas de sens de l'urgence. De courtes itérations, comme une semaine ou deux, gardent le sentiment d'urgence dans son coin: il y a assez de pression pour vous empêcher de vous relâcher, mais pas tellement que c'est négatif.

Si la direction ne respecte pas l'équipe technique, Agile sera difficile. Scrum, par exemple, exige que le propriétaire du produit et l'équipe technique se respectent mutuellement suffisamment pour suivre des règles simples. Si votre direction est susceptible de simplement dire "on s'en fout, travailler plus longtemps de toute façon", alors ils ne sont pas susceptibles de se conformer à l'esprit d'une équipe Agile. Cela ne veut pas dire que vous ne pouvez pas passer à l'Agilité ... ne vous attendez pas à ce que la direction y adhère.

Comme pour COMMENT pour aller Agile? Il y a des tonnes de questions à ce sujet, et ils s'appliqueront à vous une fois que vous aurez résolu vos problèmes de culture.

Answer 2

Il ya beaucoup de littérature sur la façon d'introduire agile à une équipe au agilealliance.com. Mon conseil est d'aller lentement et de choisir une ou deux pratiques à ajouter. Commencez peut-être par de petites itérations et TDD. Travailler à partir de là. D'après mon expérience, vous serez plus productif et n'auriez pas à vous battre pour obtenir des ressources supplémentaires. Notez que pendant que vous apprenez, vous serez probablement moins productif pendant un certain temps - en fait plus productif, mais une partie du temps et de l'énergie ira dans l'apprentissage au lieu de coder, donc moins de code sortira. Cela devrait être de courte durée.

Je pense qu'il est important d'avoir un certain niveau de participation de la part de la direction avant de commencer, car il peut y avoir une baisse initiale de la productivité. Vous devrez avoir assez de buy-in pour vous faire passer la phase initiale d'apprentissage si vous voulez éviter d'avoir à faire des heures supplémentaires. Il y a un très bon livre, Fearless Change, qui décrit le processus de plaidoyer pour le changement au sein de votre organisation.

Vous pourriez également être intéressé par les réponses aux https://stackoverflow.com/questions/53318/effective-ways-to-introduce-agile-into-the-workplace