Une méthodologie de développement flexible est une excellente idée qui est trop compliquée. Agile Lite est une tentative de simplifier la situation. Vous n'avez pas besoin de livres ou de séminaires pour expliquer Agile Lite. Seul un petit texte avec quelques points est nécessaire. Voici le texte.

Agile Lite est assez simple. Il peut être appliqué à n'importe quel projet, à condition que le travail soit divisé en tâches plus petites (problème). Comme d'autres méthodologies agiles, il utilise des cycles de développement courts - les sprints. Mais contrairement à eux, Agile Lite reconnaît clairement la prévalence du burnout dans l'industrie du développement logiciel et essaie de l'atténuer directement en introduisant un cycle de développement de trois semaines / repos d'une semaine.

Règles de base:

• La première semaine de chaque cycle, les chefs de projet, les développeurs et les autres parties prenantes déterminent le sprint à venir. Bien qu'une semaine ait été réservée, la planification du sprint ne prendra pas plus de deux heures, et avec la bonne organisation, cela prendra environ 45 minutes. C'est une semaine volontairement facile: beaucoup peuvent simplement prendre des vacances pour surfer, peindre ou autre chose.
  
• Le sprint se déroule sur les trois semaines restantes. Pendant cette période, les ingénieurs travaillent sur les tâches qui leur sont attribuées lors de la planification. Étant donné que les employés peuvent être distants et répartis sur plusieurs fuseaux horaires, les réunions en direct ne sont pas fréquentes et la plupart des communications passent par un tracker (qui fonctionne plus rapidement que le courrier électronique). Un tableau de kanban commun comme Trello est très bien, et une feuille de calcul est peu probable. Les planeurs quotidiens ne sont pas encouragés: le pouls global du projet est entièrement suivi par les mises à jour du tracker.
  
• Après le démarrage du sprint, vous ne pouvez pas ajouter de tâches au sprint, mais vous pouvez les supprimer. Cela réduit le changement de contexte, ce qui est bien.
  
• Les tâches non terminées sont prises en compte lors de la prochaine session de planification de sprint - et il est décidé de déplacer la tâche vers le sprint suivant, de la renvoyer à la liste de souhaits ou de la réaffecter à un autre développeur.
  
• Chaque tâche est soit dans la liste de souhaits, soit dans le sprint en cours. Chaque tâche devrait prendre de 4 à 8 heures.
  
• Comme déjà mentionné, les développeurs sont invités à se reposer pendant la semaine de planification afin que le cerveau récupère du sprint précédent. Ce n'est pas une croisade. Les développeurs ne travaillent pas le week-end. Tout cela permet d'éviter l'épuisement professionnel, ce qui est utile pour tout le monde.

Bien que le travail principal du sprint puisse être planifié, quelque chose d'inattendu se produit parfois. Ces problèmes inattendus sont appelés problèmes de support.

Pendant la planification du sprint, nous suggérons d'allouer du temps pour résoudre les tâches de support qui ne se prêtent pas à la planification. Par exemple, "lors du prochain sprint, Dave dispose de 12 heures pour résoudre les tâches de support (dont les détails seront déterminés plus tard)". Il est souvent utile de maintenir la rotation, où le ou les développeurs responsables des problèmes de support changent à chaque sprint.

Pour améliorer la précision des prévisions, à chaque session de planification de sprint, la quantité de travail de support réellement effectuée lors du sprint précédent est analysée et une décision est prise quant à savoir s'il faut plus ou moins de temps pour soutenir le sprint suivant.

En pratique, différents groupes ont des définitions différentes pour les tâches de support. Cela signifie peut-être client / support client. Peut-être le support d'autres développeurs. C'est à vous de décider quels éléments de cette méthodologie générale conviennent le mieux à votre équipe.

En éliminant la complexité inutile, Agile Lite est le meilleur moyen, plus durable, de développer des logiciels. Il aide au développement, tout en assurant un niveau de productivité constamment élevé.

Agile Lite pour les développeurs

Si vous n'êtes pas nouveau dans l'industrie, vous avez peut-être connu un épuisement professionnel. Cela a de nombreuses raisons, mais la façon la plus simple de décrire l'épuisement professionnel est le résultat d'un travail trop dur sous trop de stress pendant trop longtemps.

Tout commence par un projet. Chaque projet a une spécification et un délai détaillés. Lorsque la spécification change, le délai n'est pas. En fin de compte, l'échéance arrive et la spécification est devenue quelque chose de différent de l'endroit où elle avait commencé. Bien sûr, cela est considéré comme votre faute, et on vous demande de rester tard jusqu'à tard ou de «tendre la cible». En conséquence, vous travaillez tous les week-ends, mais quels que soient vos efforts, le manager est toujours insatisfait et le projet est constamment «en retard».

Voulant partir en vacances ou en vacances, vous aurez l'air d'un flâneur qui ne soutient pas l'équipe. Vous travaillez peut-être dans un bureau ouvert; tout le monde sait quand quelqu'un vient et part et tout le monde signe un contrat tacite de ne pas travailler moins que les autres. Par conséquent, les gens savent paraître occupés. Lorsque quelqu'un vous demande comment vous allez, vous répondez simplement: «Occupé! Je suis tellement occupé! "

Mais au final, quelque chose se passe. Vous pouvez changer d'emploi, mais ce sont généralement d'autres entreprises de l'industrie du logiciel. Peut-être que vous donnez toutes vos forces pour terminer la dévastation, puis l'entreprise vous laisse partir, car vous "ne correspondez pas à la culture". Peut-être que vous quittez et commencez à échanger des voitures, car la programmation est trop frustrante. Comme dit le proverbe, si vous voulez perdre le plaisir d'un passe-temps, essayez de gagner de l'argent avec.

J'offre une solution. Il s'agit d'un formulaire Agile clairement conçu pour éviter l'épuisement professionnel: Agile Lite. Il n'y a pas d'heures supplémentaires. Les travaux d'ingénierie sont en cours et les développeurs ont suffisamment de temps pour se ressourcer. Les frais généraux de gestion sont minimes.

Presque tout le système est décrit dans les six points ci-dessus. Il peut être modifié en fonction de vos objectifs. Mais je voudrais souligner une fonctionnalité d'Agile Lite. Ici, nous disons explicitement: «Hé, les équipes flexibles s'épuisent de la même manière que dans d'autres méthodologies de développement. Il peut être utile d'écrire des règles explicites pour éviter la surchauffe du moteur, qui est l'équipe d'ingénierie. »

Arrêtons de surchauffer les moteurs. Nous avons beaucoup de travail. En fait, c'est une fosse sans fond. Mais la vie est trop courte pour la consacrer entièrement au travail, au stress et finalement à l'épuisement professionnel.

Agile Lite pour les gestionnaires

Votre entreprise a-t-elle eu des problèmes avec les développeurs? Les projets ont-ils souvent manqué les délais? Avez-vous travaillé avec des développeurs qui démarrent parfaitement, se dégradent lentement, puis disparaissent? C'est peut-être un programmeur talentueux qui a connu l'épuisement professionnel.

L'épuisement professionnel est extrêmement courant dans l'industrie du logiciel et est une des principales raisons de l'échec de nombreux projets logiciels. L'épuisement professionnel peut être décrit comme les symptômes du trouble de stress post-traumatique associé à un projet ou une organisation donnés. Par exemple, le cerveau semble s'éteindre et vous ressentez une anxiété extrême à la simple mention d'un certain projet. C'est l'épuisement professionnel. Un développeur dans cet état, très probablement, ne pourra pas continuer à travailler sur ce projet, et dans les projets ultérieurs ne pourra pas travailler à pleine puissance. L'épuisement professionnel peut paralyser une carrière.

Cela revient à faire tourner un moteur de voiture à des vitesses élevées pendant très longtemps sans ajouter d'huile ou de carburant. Au final, ce moteur tombera en panne et il sera difficile de le remonter.

Les principes de base d'Agile Lite sont décrits ci-dessus et sont susceptibles de changer en fonction de vos objectifs.

FAQ + déclarations typiques

La seule règle générale dans le monde du développement agile est que tout le monde le fait mal. @fwip

Ainsi, les ingénieurs bénéficient de 12 semaines de congé par an pour le surf et la peinture? Comment cela fonctionnera-t-il dans un monde où le travail du 9h00 au 21h00 six jours par semaine deviendra la norme?

Je pense que vos développeurs devraient se reposer autant qu'ils en ont besoin.

Je note que la semaine de travail de 40 heures était autrefois considérée comme une idée radicale. Google a commencé avec 80% du temps de travail pour les grands projets, maintenant nous en avons 75%, je voudrais le réduire à 10% (méthode Ferris) d'ici la fin des années 2020.

Le système 996 (de 9 h à 21 h 6 jours par semaine) est l'approche inverse, qui vise à étendre la semaine de travail de 40 heures à une semaine de 72 heures. Je vois cela comme une régression et je pense que nous devrions arrêter de fétichiser les heures supplémentaires. En fait, cela n'augmente pas la productivité.

De plus, vous décidez quoi faire pendant la "semaine de repos": partir en vacances, assigner une charge de travail plus légère ou autre. La réponse peut dépendre de la semaine en particulier.

Peut-être que la «semaine facile» est plus facile pour les gens que la «semaine de repos». Utilisez ce qui vous convient le mieux.

Le surf et la peinture ne sont en aucun cas obligatoires, ils sont donnés simplement à titre d'exemples. Moi-même je ne surfe pas et je ne peins même pas.

Les gens se voient -ils assigner des tâches ou prévoient -ils eux-mêmes ce qu'ils obtiendront?

Ils prédisent. Ce n'est pas grave si vos estimations sont fausses. Cela fait partie du processus et fait partie d'une même équipe.

Pourrait-il être appelé itérations au lieu de sprints?

Bien sûr! Sprint me convient.

Est-il possible de faire une itération glissante dans le style kanban, où les dates de début et de fin varient et dépendent des circonstances?

J'apprécie vraiment le concept d'un cycle de travail avec certaines dates de début et de fin, et défini par un bloc de tâches. Les itérations glissantes qui ne sont pas synchronisées avec une boucle particulière la ruineront.

Pourquoi exactement trois semaines de sprints?

Parce que le développement et la récupération sont placés dans 13 emplacements par an. Une fois le cycle terminé, un nouveau commence. Une semaine de "repos" vous permet de redémarrer avant le début d'un nouveau sprint. Il s'agit d'obtenir une cadence et des intervalles clairs et cohérents.

Est-ce à dire que les dates de début et de fin des sprints tombent souvent au milieu du mois civil?

Oui

Les développeurs sont-ils impliqués dans la planification du sprint?

Oui Il ne leur est pas interdit d'assister à la réunion. Ce n'est tout simplement pas nécessaire, surtout si le tracker de tâches fonctionne bien, et l'équipe a discuté de certains des points pour le prochain sprint lors du précédent.

Je suis pour moins de réunions. Peu de gens les aiment. Si vous en faites partie, ne comptez pas sur moi.

La planification d'un sprint prend-elle une semaine?

Non, c'est ça le point. C'est une semaine facile.

Les stand-ups sont-ils vraiment un problème?

D'après mon expérience, oui. Habituellement, tout le monde se tient en cercle, écoutant une personne pendant 20 minutes. Bien sûr, c'est la «mauvaise» approche, mais je n'ai jamais vu personne le faire correctement, et je préférerais abandonner complètement les planeurs quotidiens. Encore plus difficile (ou du moins gênant) de le faire lorsque votre équipe est géographiquement répartie. Mais s'ils vous sont très précieux, ne me laissez pas vous arrêter.

Faut-il le faire de cette façon?

Non. Personne ne vous oblige à rien. Ce sont des recommandations, pas des règles.

Ce n'est pas une religion.

Ces règles ne sont politiques que dans le sens où la propagande de la semaine de travail de 40 heures était politique.

Ce qui fonctionne pour vous peut ne pas fonctionner pour les autres. Le savez-vous?

J'en suis sûr!

Réclamations fréquentes

Vous n'avez pas besoin de faire de prévisions sur le calendrier, car les estimations sont impossibles.

Les prévisions sont considérées comme des prévisions et non comme des contrats signés de sang. Par conséquent, s'ils ne sont pas respectés, c'est normal. Faites tous les efforts possibles et essayez de faire une prévision par incréments de 4 heures.

Les développeurs ne peuvent pas faire confiance, et vous devez garder une trace de tout leur temps, car c'est ainsi que le travail est effectué.

Je suis vraiment en désaccord, mais je ne peux pas expliquer rapidement pourquoi. Nous avons des différences fondamentales dans la vision du monde.

Ce n'est pas Agile.

Bien sûr Agile, il a raison dans le titre.

C'est irréaliste.

Et pourtant ça marche.

Vous faites mal agile.

Malheureusement, le problème avec Agile est qu'il ne peut pas être fait correctement.