Où se situe l'apprentissage de nouvelles compétences dans Agile?
Je démarre une société de logiciels financiers et dans le processus, j'étudie les principes et méthodes agiles et le seul aspect du développement que je n'ai pas encore vu abordé est de savoir où répondre au besoin continu des développeurs d'apprendre de nouvelles compétences et technologies dans le développement processus.
Avant de travailler sur des logiciels financiers au cours des deux dernières années, j'ai passé la majeure partie de ma carrière en tant que programmeur graphique 3D à travailler sur des jeux vidéo et des logiciels SIG et biométriques et j'ai toujours dû simplement plonger d'une falaise dans les choses et comprendre comment voler. Bien que j'ai toujours réussi, je suis sûr que je ne vivrai pas aussi longtemps que je l'aurais fait si je ne m'étais pas tué en travaillant autant de semaines et de mois de 100 heures à la fois.
Maintenant que je démarre une société de logiciels qui n'a pas tout à fait les exigences innovantes intenses des graphiques 3D, je veux établir une approche plus holistique du développement.
Peut-être que l'agilité ne résout pas cela, mais si c'est le cas, je n'ai pas trouvé où et j'apprécierais toute connaissance ou expertise ou expérience que quiconque a avec cela.
Cela n'a pas grand-chose à voir avec Agile, ni même avec le génie logiciel. C'est tout simplement vrai pour n'importe quelle entreprise dans n'importe quelle entreprise: vous devez réserver du temps pour la formation. Période.
Agile a cette idée de "rythme durable", ce qui signifie qu'à aucun moment l'équipe ne devrait travailler plus dur que ce qu'elle pourrait soutenir pendant une durée indéterminée. C'est à dire. pas de "temps de crise". Cela doit également être respecté par la formation. Ainsi, un rythme soutenable pour votre équipe est "pas plus de 5 heures d'affilée sans interruption, pas plus de 9 heures par jour, pas plus de 40 heures par semaine", et vous voulez donner 10% de temps pour la formation, alors vous besoin de planifier vos projets pour des semaines de 36 heures.
Mais encore une fois, cela n'a rien à voir avec Agile, c'est juste du bon sens et des mathématiques à l'école primaire.
Personnellement, je pense que quelque chose comme permettre une demi-heure par jour, une demi-journée par semaine et une semaine complète par trimestre permettrait à l'équipe d'acquérir des connaissances de différentes tailles rapidement et à un rythme régulier.
Il existe également des pratiques Agiles qui aident au transfert de connaissances, c'est-à-dire à aplanir les différences de niveau de connaissances entre les équipes:
- rétrospectives quotidiennes
- rétrospectives par sprint
- rétrospectives par projet
- programmation en binôme
- couplage ping-pong (échange du pilote et du navigateur après chaque étape du cycle de refactorisation rouge-vert)
- appariement promiscuité (pas de paires fixes, les paires sont attribuées au hasard et changées chaque matin et déjeuner)
- nombre impair de membres de l'équipe (si vous faites de la programmation en binôme, laissez un membre de l'équipe libre d'apprendre)
- programmation mob (une variante de la programmation par paires où toute l'équipe utilise un seul ordinateur et écran, un membre désigné de l'équipe est simplement un "dactylographe" et les autres lui disent quoi écrire)
- équipes promiscuous (les développeurs sont assignés au hasard aux équipes chaque jour/chaque sprint)
La programmation en binôme et la programmation en masse offrent non seulement un examen continu du code mais également un partage continu des connaissances. L'appariement ping-pong empêche une personne de "s'emparer du clavier". Le jumelage promiscuous diffuse les connaissances à travers toute l'équipe, les équipes promiscuous diffusent les connaissances à travers toute l'entreprise et s'assurent que chaque développeur connaît chaque projet et chaque base de code; cela conduira également à un degré élevé de standardisation dans la ou les bases de code. Bien que l'objectif principal des rétrospectives soit de fournir un retour d'informations sur le processus de développement et de l'adapter en conséquence, il peut également être utilisé pour communiquer un problème inhabituel et comment le résoudre.
Il va sans dire que l'employeur devrait fournir une vaste bibliothèque, des abonnements payants à ACM, Springer, IEEE, etc., ainsi que des salles calmes pour étudier et de plus grandes salles pour enseigner. Beaucoup de tableaux blancs et de tableaux à feuilles mobiles, ainsi que les projecteurs partout sont bien sûr sensés en général, pas seulement pour la formation.
Je vais être d'accord avec la plupart de ce que Jörg W Mittag a dit , mais pas avec l'affirmation selon laquelle "cela n'a pas vraiment grand-chose à voir avec Agile". Un certain nombre de techniques Agile soutiennent l'apprentissage et le développement des individus et des équipes.
Les méthodes Agiles ont tendance à être basées sur des incréments ou un flux continu. Dans les deux cas, le travail est ordonné en fonction de facteurs tels que la priorité, la valeur et les dépendances. Étant donné que l'accent est mis sur le travail à court terme, l'équipe peut identifier les connaissances nécessaires pour fournir et, si le manque de connaissances pose problème, planifier pour acquérir ces connaissances juste à temps. La visibilité et la transparence ont également tendance à être des aspects clés des différentes méthodes Agile, afin que les parties prenantes puissent voir sur quoi l'équipe travaille et comment elles travaillent pour améliorer leurs capacités à offrir de la valeur. Lorsqu'un apprentissage approfondi est nécessaire, il peut être planifié dans un avenir proche ou l'itération actuelle.
Une fois que les individus d'une équipe ont acquis des connaissances, il existe des techniques autour du jumelage et du mobbing. La programmation par paires est une pratique clé de la programmation extrême qui a également été appliquée à d'autres méthodes et qui est conçue, entre autres, pour faciliter l'apprentissage. Mobbing applique cela à plus de deux personnes. La collaboration étroite et la fonctionnalité croisée des équipes signifient qu'il n'y a pas de cloisonnement et que ces informations sont diffusées.
Même avec la capacité de planifier et d'exécuter l'apprentissage de ce qui est nécessaire pour le travail immédiat, il est très important d'avoir des membres de l'équipe bien informés. Le fait d'avoir des personnes ayant un certain niveau de connaissances existantes des outils, de la technologie et du domaine leur permettra d'être plus informés lors de l'exécution de tâches d'apprentissage et d'être plus efficace lors de la diffusion des connaissances aux autres membres de l'équipe.
Planifiez une tâche de validation de principe pour le sprint au cours duquel vous souhaitez prévoir du temps pour acquérir une compétence. Restez concentré sur quelque chose de très spécifique, comme apprendre à créer un tableau HTML accessible. Continuez à planifier des tâches de preuve de concept jusqu'à ce que vous ayez acquis les compétences nécessaires pour l'histoire. Donnez à chaque tâche POC quelques points d'histoire et une date d'échéance afin que vous puissiez correctement la chronométrer et montrer les progrès à la fin du sprint.
Et si une histoire ne devait représenter que 5 points pour un développeur expérimenté? Peut-être qu'il faut 3-4 tâches à 8 points chacune. Après ces tâches POC, l'histoire ne peut toujours être que de 5 points, mais au moins vous réservez du temps pour apprendre les nouvelles compétences afin que l'histoire de 5 points ne soit pas 40 points - même si l'histoire et les tâches POC totalisent jusqu'à 40 points.
Scrum a l'idée d'un "pic". Si l'équipe adopte une nouvelle technologie ou capacité, un pic est une histoire pour résumer ce travail. Ainsi, alors qu'une histoire en agile est un élément de fonctionnalité axé sur l'utilisateur, la sortie d'un pic est la documentation de ce qui a été appris et une répartition du travail pour le mettre en pratique dans l'application réelle.
Dans la pratique, j'ai trouvé que c'était un bon moyen de gérer au moins une formation à petite échelle - suffisamment pour mettre les développeurs au courant d'un nouveau système ou cadre tout en restant responsable du calendrier.
Je n'ai pas vu cela dans les autres réponses, donc je voulais ajouter que de nombreuses organisations créent des guildes, des chapitres ou des centres d'excellence autour de domaines de compétences. Il peut s'agir de sujets généraux comme la technologie ou de sujets spécifiques comme React Développement natif. Tout dépend si l'intérêt de participer existe dans votre entreprise.
Quoi qu'il en soit, ces groupes ont souvent la tâche d'aider les membres du groupe à se développer professionnellement. Cela crée un espace séparé en dehors du travail pour renforcer et développer les compétences à la fois pour les personnes qui utilisent ces compétences tous les jours et même pour les personnes en dehors de cette discipline qui sont intéressées par la formation polyvalente. Ce n'est pas la seule solution à ce problème, mais il semble devenir de plus en plus courant.
Certains autres ont déjà mentionné des aspects, mais je voulais juste partager comment j'intègre le développement personnel dans un environnement agile.
1. Développement en cours
C'est le plus simple, réduisez votre capacité à chaque sprint jusqu'à ce que vous ayez suffisamment de temps pour effectuer un développement continu. La partie difficile est généralement de s'en tenir à votre plan et de faire le développement s'il y a plus d'autres tâches à ramasser. Si vous avez des urgences, vous pouvez sacrifier cette fois de temps en temps, mais sinon, ne le faites pas.
Parce que vous avez réduit votre capacité, tout ce que vous faites dans cette catégorie est quelque peu en dehors des préoccupations directes des autres membres de l'équipe, et ils n'ont probablement pas beaucoup de raisons de s'en inquiéter ou de mettre à jour la planification spécifiquement dans chaque sprint individuel.
2. Des efforts plus importants pendant un sprint
Ce que j'ai trouvé, c'est que si vous avez prévu quelque chose avec un impact plus important (par exemple une formation de 2 jours pendant un sprint), vous devez mettre à jour le sprint pour refléter cela. Je ne sais pas quelle est la solution théorique pour cela, mais j'ai souvent vu que les gens mettent simplement la tâche de formation au tableau pour s'assurer qu'il est visible que quelqu'un est occupé avec cela.
Alternativement, vous pouvez corriger la capacité de sprint du sprint spécifique, mais à moins que les gens ne regardent très attentivement vos performances/efficacité mesurées, je resterais à l'écart de cela. Surtout dans une nouvelle équipe, la stabilité est probablement plus précieuse que la précision.
Agile est un ensemble de philosophies, jetez un œil au manifeste, c'est TOUT Agile, alors quand vous dites comment Agile peut résoudre mes problèmes, je recommande d'en apprendre (beaucoup) plus sur Agile. Prenons une implémentation concrète d'Agile: SCRUM. Dans SCRUM, nous avons les concepts de Sprint et de pointes. Grâce à ces deux artefacts, il est possible de créer un budget pour l'apprentissage.
Si vous regardez un sprint sous forme de graphique à secteurs, vous pouvez diviser les priorités en fonction du sujet, un de ces sujets peut être ... l'apprentissage de nouvelles compétences!
Un pic est une tâche de recherche sur un sprint qui consiste à évaluer la faisabilité de quelque chose habituellement par l'apprentissage.
Enfin, la chose que vous avez faite est toujours sur la table et vous pouvez apprendre EN FAISANT ce que vous travaillez, à quel point vous pouvez essayer d'augmenter les points d'histoire/la capacité à relever le défi technique.
Pour citer le Manifeste Agile lui-même:
Individus et interactions sur les processus et les outils
Logiciel de travail sur une documentation complète
Collaboration client sur la négociation du contrat
Répondre au changement suite à un plan
L'accent est à moi, mettant en évidence les parties qui vous sont probablement les plus applicables.
Fondamentalement, les développeurs agiles bien formés peuvent mieux répondre aux environnements changeants que ceux qui laissent leurs compétences pétrifier.
Si je peux ajouter ma propre définition de l'agilité, nous pouvons également intégrer la "collaboration client". Je trouve que la meilleure définition de l'agilité est celle basée sur l'idée d'agilité - si le client (ou l'environnement) change radicalement, comment gérez-vous bien? Si vous favorisez un environnement de collaboration client, ils auront tout intérêt à ce que votre équipe sache ce qu'ils font.