Je démarre une entreprise de logiciels financiers et, dans le cadre de ce processus, j'ai étudié les principes et méthodes agiles et l'un des aspects du développement que je n'ai pas encore vu est de savoir où répondre au besoin continu des développeurs d'acquérir de nouvelles compétences et technologies dans le développement. processus.

Avant de travailler sur des logiciels financiers au cours des dernières années, j'ai passé la majeure partie de ma carrière à travailler sur des jeux vidéo ainsi que des logiciels de SIG et de biométrie. J'ai toujours dû plonger dans une falaise et comprendre comment voler. Bien que j'aie toujours réussi, je suis sûr de ne pas vivre aussi longtemps que je l'aurais si je ne m'étais pas tué en travaillant autant de semaines et de mois à 100 heures.

Maintenant que je démarre une société de logiciels qui n’a pas encore les exigences innovantes des graphismes 3D, je souhaite mettre en place une approche plus globale du développement.

Peut-être que l'agile ne résout pas le problème, mais si c'est le cas, je n'ai pas trouvé où et j'apprécierais toute connaissance, expertise ou expérience que quiconque possède dans ce domaine.

Cela n’a pas grand-chose à voir avec Agile, ni même avec le génie logiciel. C’est tout simplement vrai de toute entreprise dans toute 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 que ce qu'elle pourrait supporter pendant une durée indéterminée. Ie pas de "temps de crise". Cela doit également être respecté par la formation. Ainsi, le rythme de votre équipe est durable: "Pas plus de 5 heures d'affilée sans pause, pas plus de 9 heures par jour, pas plus de 40 heures par semaine", et vous souhaitez consacrer 10% de temps à la formation, puis 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 laisser 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 blocs de connaissances de tailles différentes rapidement et à un rythme soutenu.

Il existe également des pratiques agiles qui facilitent le transfert des connaissances, par exemple pour 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 (permutation du pilote et du navigateur après chaque étape du cycle rouge-vert-refactor)
• appariement promiscuité (pas de paires fixes, les paires sont assignées au hasard et changées tous les matins et à l'heure du déjeuner)
• nombre impair de membres de l'équipe (si vous programmez en binôme, laissez un membre de l'équipe libre d'apprendre)
• Programmation sur mob (une variante sur la programmation par paire où toute l'équipe utilise un seul ordinateur et un seul écran, un membre de l'équipe désigné est simplement un "dactylographe" et les autres lui disent quoi écrire)
• équipes peu engageantes (les développeurs sont assignés au hasard aux équipes chaque jour / chaque sprint)

La programmation en binôme et en mob permet non seulement une révision continue du code, mais également un partage continu des connaissances. Le couplage ping-pong empêche une personne de "monopoliser le clavier". Le couplage promiscuité permet de diffuser les connaissances dans l’ensemble de l’équipe et les équipes de proximité tout autour, et de veiller à ce que chaque développeur connaisse chaque projet et chaque base de code; cela conduira également à un haut degré de standardisation dans la (les) base (s) de code. Bien que l'objectif principal des rétrospectives soit de fournir des informations en retour sur le processus de développement et de s'adapter en conséquence, il peut également être utilisé pour communiquer un problème inhabituel et la manière de 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 des salles plus grandes pour y enseigner. Les projecteurs du monde entier sont bien sûr sensés en général, pas seulement pour la formation.

Je suis d'accord avec la plupart des propos de Jörg W Mittag , mais pas avec l'affirmation selon laquelle "cela n'a pas vraiment grand-chose à voir avec Agile". Un certain nombre de techniques agiles 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 commandé 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 à la mise en œuvre et, si le manque de connaissances pose problème, planifier l’acquisition de ces connaissances juste à temps. La visibilité et la transparence tendent également à être des aspects clés de diverses méthodes Agiles, afin que les parties prenantes puissent voir sur quoi l’équipe travaille et comment elles s’emploient à améliorer leur capacité à générer de la valeur. Lorsqu'un apprentissage approfondi est nécessaire, il peut être planifié dans un avenir proche ou dans l'itération actuelle.

Une fois que les membres d'une équipe ont acquis des connaissances, il existe des techniques de couplage et de mobbing. La programmation en binôme est une pratique clé de la programmation extrême qui a également été appliquée à d'autres méthodes et est conçue pour, entre autres, 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 silos et que les 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 compétents de l'équipe. Le fait de disposer de personnes possédant un certain niveau de connaissance des outils, de la technologie et du domaine leur permettra d’être mieux informés lorsqu’ils assument des tâches d’apprentissage et d’être plus efficaces lors de la diffusion des connaissances aux autres membres de l’équipe.

Planifiez une tâche de preuve de concept pour le sprint dans lequel vous souhaitez prévoir du temps pour apprendre une compétence. Concentrez-vous sur quelque chose de très spécifique, comme apprendre à créer un tableau HTML accessible. Conservez la planification des tâches de validation de principe jusqu'à ce que vous ayez acquis les compétences nécessaires à l'histoire. Attribuez à chaque tâche POC des points d’histoire et une date d’échéance afin de pouvoir la chronométrer correctement et afficher les progrès accomplis à la fin du sprint.

Alors que se passe-t-il si une histoire ne doit représenter que 5 points pour un développeur expérimenté? Peut-être que cela prend 3-4 tâches à 8 points chacune. Après ces tâches POC, l’histoire n’est toujours que de 5 points, mais au moins vous prenez le temps d’apprendre les nouvelles compétences de sorte que l’histoire en 5 points ne soit pas de 40 points - même si l’histoire et les tâches POC totalisent 40 points.

Scrum a l'idée d'un "pic". Si l'équipe utilise une nouvelle technologie ou de nouvelles capacités, une pointe est une histoire qui résume ce travail. Ainsi, même si une histoire agile est une fonctionnalité centrée sur l'utilisateur, le résultat d'une pointe est la documentation de ce qui a été appris et une panne de travail pour sa mise 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, ce qui est suffisant pour permettre aux développeurs de se familiariser avec un nouveau système ou un nouveau cadre tout en rendant compte 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 tels que la technologie ou de thèmes spécifiques tels que React Native Development. Tout dépend si l'intérêt de participer existe dans votre entreprise.

Quoi qu'il en soit, ces groupes ont souvent pour tâche d'aider les membres du groupe à se développer de manière professionnelle. Cela crée un espace séparé en dehors du travail pour renforcer et développer les compétences des personnes qui l'utilisent quotidiennement et même des personnes extérieures à cette discipline qui sont intéressées par la formation croisée. Ce n'est pas la seule solution à ce problème, mais il semble que cela devienne de plus en plus courant.

Certains autres ont déjà mentionné des aspects, mais je voulais simplement partager mon adaptation au développement personnel dans un environnement agile.

1. Développement en cours

C’est la solution la plus simple: réduisez votre capacité à chaque sprint jusqu’à ce que vous ayez suffisamment de temps pour poursuivre le développement en cours. La partie la plus difficile est généralement de respecter votre plan et de faire le développement si d’autres tâches doivent être prises en charge. Si vous avez des urgences, vous pouvez sacrifier ce temps de temps en temps, mais ne le faites pas autrement.

Parce que vous avez réduit votre capacité, tout ce que vous faites dans cette catégorie est un peu en dehors de la préoccupation directe des autres membres de l'équipe et ceux-ci n'ont probablement pas de raison de s'en inquiéter ou de mettre à jour la planification spécifiquement pour chaque sprint.

2. Des efforts plus importants lors d'un sprint

Ce que j’ai trouvé, c’est que si vous avez planifié quelque chose qui a un impact plus important (par exemple deux jours d’entraînement pendant un sprint), vous devez mettre à jour le sprint en conséquence. Je ne suis pas sûr de la solution théorique, mais j’ai souvent vu que les gens inscrivaient 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 d'un sprint spécifique, mais à moins que les gens ne regardent très attentivement votre performance / efficacité mesurée, je resterais à l'écart de cela. Surtout dans une nouvelle équipe, la stabilité est probablement plus importante que la précision.

Agile est un ensemble de philosophies, jetez un coup d'œil au manifeste, c'est TOUT le Agile, alors quand vous dites comment Agile peut résoudre mes problèmes, je recommande d'en apprendre plus (beaucoup) sur Agile. Prenons une implémentation concrète de 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 d’apprentissage.

Si vous considérez un sprint comme un diagramme à secteurs, vous pouvez diviser les priorités en fonction des sujets. Un de ces sujets peut être… l’acquisition de nouvelles compétences!

Un pic est une tâche de recherche sur un sprint qui consiste à évaluer la faisabilité de quelque chose généralement par apprentissage.

Enfin, ce que vous avez fait est toujours sur la table et vous pouvez apprendre à FAIRE tout ce que vous faites, vous pouvez alors essayer d’augmenter les points d’histoire / la capacité de faire face au 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 négociation de contrat
Réponse au changement suite à un plan

Je mets l'accent sur les parties qui vous conviennent le mieux.

Fondamentalement, les développeurs agiles bien formés peuvent mieux s'adapter aux environnements en mutation 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é repose sur l'idée d'agilité: si le client (ou l'environnement) change radicalement, dans quelle mesure vous y prenez-vous? Si vous favorisez un environnement de collaboration client, ils auront tout intérêt à ce que votre équipe sache ce qu’elle fait.