Pourquoi ai-je besoin de SCRUM par rapport à un processus moins formel et plus léger pour mon équipe?

J'aimerais commencer ma question en disant que je comprends que SCRUM ou un dérivé de celui-ci est probablement un bon chemin à parcourir pour gérer le développement de logiciels. Il semble que toutes les grandes entreprises et mes managers l'utilisent ou l'aient utilisé, et je ne peux pas vraiment contester toute cette expérience. Cependant, j'ai du mal à comprendre les "pourquoi" et toute la lecture et même ma formation officielle SCRUM au travail ne fait pas le travail pour moi. C'est juste de la rhétorique. Je viens donc ici chercher des réponses.

Jusqu'à présent, je me suis développé en équipes de 4 à 5 membres de manière très efficace, complètement auto-organisée et sans besoin de formation, de méthodologie ou de logiciel spécial. Juste des discussions en cubes, des réunions ad hoc et des révisions de code individuelles. Je suis maintenant dans une position de travail où l'on nous dit que SCRUM est la voie à suivre et tout ce qui va avec. Quand ils me décrivent SCRUM, je lis des trucs comme ça:

• 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épondre au changement au sujet d'un plan

C'est super, mais tout cela me semble être du bon sens. Pourquoi ce besoin a-t-il été codifié? On me dit ensuite que la méthodologie nous aide à réagir au changement. Quel spécifiqueles aspects de SCRUM me permettent d'être si flexible que je ne le faisais pas auparavant avec mes réunions ad hoc, mes discussions de cube et mes réunions de planification de développeur? Ils expliquent la nécessité d'avoir un livrable fonctionnel toutes les deux semaines, ou sprint. Dans mon projet particulier, il n'y a pas de "client", le logiciel ne sera pas terminé avant un an ou plus, et en attendant, je ne ferai probablement des démonstrations à la haute direction que tous les mois ou moins. Alors pourquoi le besoin explicite d'un livrable toutes les deux semaines? Ils soulignent l'importance de la réunion de planification du sprint où toute l'équipe présente les histoires et les tâches pour le prochain sprint. Ce n'est pas différent des réunions de planification impromptues que j'ai eues dans le passé. Pourquoi cela doit-il se produire un lundi sur deux, et pourquoi toute l'équipe doit-elle être impliquée? Je comprends le concept de chaque membre "propriétaire" du produit, mais le fait est que seules quelques personnes peuvent réellement contribuer à diviser chaque histoire en tâches, tandis que les autres ne font que regarder les bras croisés.

Encore une fois, je comprends que la majorité des gens sont derrière ce processus, et donc il doit fonctionner, et je dois m'engager. Je voudrais juste comprendre pourquoi. Est-ce mon problème que je pratique déjà ces choses et que je n'aime pas les codifier inutilement? Ou peut-être que je n'ai pas encore vu les avantages de ces techniques parce qu'elles sont mal faites? Tout renseignement ou conseil réel et personnel à ce sujet, par opposition au spiel auquel je suis habitué, serait extrêmement apprécié.

Je pense qu'il y a deux aspects pour répondre à votre question, mais permettez-moi de commencer par vous féliciter d'avoir travaillé avec des gens qui semblent suffisamment intelligents et compétents pour pouvoir travailler à peu près sans processus fortement défini et toujours livrer un produit. Malheureusement, ce n'est pas le cas dans toutes les équipes logicielles, alors peut-être qu'un de vos problèmes avec Scrum pourrait être que vous et vos collègues n'avez en fait pas besoin d'un processus qui vous soit transféré pour vous rendre plus efficace. Vous pourriez déjà être efficace.

D'autres équipes ne le sont pas et ont besoin d'un processus plus strictement défini et de quelques directives pour les amener à faire avancer les choses. Cela ne signifie pas que ces équipes sont plus stupides ou moins capables, cela signifie simplement qu'elles ont peut-être des problèmes d'auto-organisation ou de travail avec la discipline en équipe. Cela peut également être une expérience d'apprentissage simple en venant d'un endroit où les gens travaillent principalement seuls pour travailler ensemble en équipe. Scrum peut vous aider à y arriver, car il propose quelques lignes directrices qui sont à la fois assez faciles à comprendre et à suivre, mais suffisamment efficaces pour exercer une pression sur l'équipe pour commencer à se ressaisir.

Étant donné que Scrum ne dit rien sur la façon dont le développement logiciel doit être fait, cela laisse également à l'équipe la liberté de décider pour elle-même (par exemple, vous pouvez toujours faire un sprint en appliquant une méthode de cascade plutôt conservatrice tant que vous avez terminé à la fin du sprint).

Donc, l'équipe est un problème. L'autre problème est la gestion et la confiance de la direction. Ici, Scrum peut être bon car il est transparent et permet à toutes les parties prenantes de voir les progrès de l'équipe dans des cycles définis. Ce n'est donc pas "nous progressons, malheureusement nous ne pouvons rien vous montrer pour l'instant, mais croyez-nous, nous aurons terminé à temps". Cela peut même être vrai, mais il peut être rassurant pour n'importe quel manager d'avoir en fait une démo régulière où ils peuvent voir que des progrès ont effectivement été réalisés.

Scrum n'est pas une solution miracle. Cela peut ne pas fonctionner pour certaines équipes pour diverses raisons, peut-être que pour certaines équipes, l'auto-organisation ne fonctionne pas. Peut-être pour vous, c'est l'inverse et cela semble être un processus jeté sur une équipe déjà productive et organisée.

En cas de doute, je vous suggère de l'essayer et de voir. Si cela ne fonctionne pas et que la majeure partie de l'équipe n'aime pas travailler de cette façon, ne le faites pas. Cependant, vérifiez-le pendant quelques mois (je dis quelques mois, car les premiers sprints seront maladroits de toute façon et vous aurez besoin de temps pour ajuster les détails), puis réévaluez.

Cela peut être controversé, mais Scrum est préférable de réduire les peurs de gestion d'Agile ou d'utiliser avec une équipe déjà sous-performante. Si votre équipe fonctionne bien, atteint des objectifs, gagne de l'argent et est heureuse, Scrum ne vous achètera rien, car tout ce qu'elle fera sera de perturber le bon équilibre des activités que vous faites (et de faire de votre équipe un succès). Scrum n'est pas une solution miracle. D'après mon expérience, cela n'aide que les équipes qui avaient une mauvaise estimation et une mauvaise communication au départ. Une équipe travaillant avec des estimations réalistes dans un environnement de communication efficace n'est entravée que par les frais généraux du processus de Scrum.

Croyez-le ou non, de bonnes équipes de logiciels existaient avant l'arrivée de Scrum. Scrum aide les mauvais à s'améliorer.

La plupart des réponses ici ont déjà énuméré la raison, bien qu'un peu indirecte. La réponse d'Anne est particulièrement éclairante lorsqu'elle touche à la transparence. Autrement dit, permettre aux gestionnaires de voir ce qui se passe. Et la réponse de Schultz touche également à cela quand il parle de personnes qui ne peuvent pas cacher le fait qu'elles se relâchent.

Je voudrais donc dire ce que les autres disent déjà mais dans un langage plus direct: l'objectif principal de SCRUM n'est pas de gérer le développement logiciel, l'objectif principal de SCRUM est de mesurer le développement logiciel.

D'autres systèmes ont déjà essayé et les gens ont proposé d'innombrables mesures pour essayer de mesurer le développement logiciel, mais ils ont échoué. SCRUM renverse le problème et déplace le fardeau de la mesure des gestionnaires et des développeurs eux-mêmes. La logique est simple: qui mieux estimer le temps qu'il faut pour faire quelque chose que ceux qui font le travail eux-mêmes?

Maintenant, le problème avec cela est que les programmeurs sont bien connus pour être trop optimistes. Demandez à un programmeur combien de temps il faut pour faire quelque chose et il sous-estimera généralement la difficulté de la tâche. SCRUM fournit les outils pour contrôler cela:

• des réunions quotidiennes pour évaluer les progrès et obtenir une vue d'ensemble du projet
• les estimations sont faites en "points" au lieu d'heures / jours pour résumer le temps d'absence
• graphiques de brûlage et graphiques de torture / lièvre pour visualiser la vitesse des points
• histoires et tâches sur un tableau pour obtenir une vue d'ensemble de la charge de travail
• sprints et itérations pour agir comme des délais afin que nous puissions mesurer les progrès
• Rôles spécifiques pour Scrum Master, propriétaire et membre de l'équipe pour éviter la tentation de tricher

etc.

Vous remarquerez peut-être que tout ce qui précède fait principalement deux choses:

1. Ils mesurent le travail. Soit du travail à faire, soit du travail en cours, soit du travail terminé.
2. Ils essaient très fort d'éviter le problème du programmeur trop optimiste pour obtenir une estimation meilleure et plus réaliste.

Plus vous implémenterez SCRUM, plus votre estimation sera précise. En fait, je pense personnellement que l'exécution de sprints + un backlog + un graphique de gravure suffit à lui seul à dissuader la plupart des programmeurs de faire de mauvaises estimations du temps qu'il faut pour faire quelque chose.

Personnellement, je pense que le but de SCRUM est de satisfaire les organisations plus anciennes où la haute direction ne peut pas ou ne veut pas se mettre derrière un processus plus léger. Je travaille en tant qu'architecte (poulet) depuis environ un an dans un département qui utilise fortement SCRUM. Mon expérience antérieure est celle des startups de la Silicon Valley, dont la plupart utilisaient un processus axé sur les fonctionnalités beaucoup plus maigre, ad hoc et très itératif (parfois hebdomadaire ou même quotidien). Je trouve que SCRUM, au moins la façon dont nous le mettons en œuvre, est excessif en termes de processus (et à certains égards plus lourd que la cascade (du moins du point de vue du développeur). Pour être juste, je dirai qu'un aspect de notre processus qui s'écarte est que nos propriétaires de produits sont en fait plus proches des analystes des exigences dans l'organisation informatique. En conséquence, ils tendent à émousser les informations provenant de l'entreprise et, pire encore, laissent l'entreprise non responsable à l'équipe de développement (ce qui nécessite des infusions successives régulières d'histoires utilisateur). Néanmoins, dans ma future startup, je n'utiliserais pas de SCRUM. Je ne l'utiliserais probablement que dans la situation où la direction a besoin de la surcharge supplémentaire.

Je ne parlerai pas du point de vue d'un puriste. Je pense que vous pouvez l'exécuter de manière quelque peu similaire à ce que Scrum dit. Cependant, le point principal est que c'est votre capacité à diriger le spectacle. Que se passera-t-il si vous êtes en vacances pendant un mois?

Je vois la mêlée comme un mécanisme pour rationaliser tout ce que vous avez fait et y mettre certains aspects définis. De sorte qu'en votre absence, quelqu'un d'autre peut également le répliquer et le répliquer sur d'autres projets également. Mais la mêlée n'est pas une solution miracle. J'ai vu beaucoup de gens qui ont juste commencé à utiliser Scrum (parce que c'est à la mode) et ont été violemment battus parce qu'ils n'en comprenaient pas l'essence.

PS: Scrum n'exige pas que votre sprint dure deux semaines. Cela peut durer un mois (votre cas).

Veuillez d'abord voir mes commentaires sur la question.

SCRUM est un paradigme de développement logiciel agile. En tant que tel, il est agile lui-même. Il ne suppose pas que vous devez suivre son modèle classique. Et je doute que quelqu'un le fasse. J'ai travaillé dans plusieurs organisations et chaque équipe l'a adapté à leurs besoins. Il n'est pas rare qu'il n'y ait pas de client / consommateur lorsqu'il s'agit de publier un produit / bibliothèque / API public. Je n'en ai jamais eu. Dans mon cas, notre GM a agi comme un, ce que l'OMI était comme n'en avoir aucun.

Avoir 2 semaines de sprints est difficile. Tres difficile. 3 semaines c'est mieux mais c'est vraiment pour les expérimentés et familiers avec l'équipe process. Nous avions 4 semaines ou un mois. Cela nous a donné suffisamment de temps pour "régler" pour ainsi dire au début et avoir plus de confiance à la fin en raison de plus de tests. J'ai aimé ça et je m'en tiendrai à 3 semaines au moins.

L'autre équipe avec laquelle je collaborais n'avait rien d'autre qu'un carnet de commandes. Ils se réuniraient, rendraient compte de l'état d'avancement et de la suite, et c'est tout. Une fois que tout serait fait, ils arriveraient avec un autre arriéré. Ils savaient que ce n'était pas SCRUM mais cela a fonctionné pour eux et c'est ce qui est important.

Est-il plus léger? C'est définitivement le cas. Mais ce n'est pas SCRUM. Ce que j'aime chez SCRUM, c'est qu'il favorise la discipline. Les gens ressentent la pression de livrer quelque chose tous les jours. Tout le monde sait ce que font les autres et il échoue, tout le monde le saura. Même si l'on essaie de couvrir cela (lire le mensonge), cela devient évident beaucoup plus tôt qu'avec d'autres processus. Donc, lorsque vous divergez et simplifiez comme avec cette équipe, vous devez être sûr de le faire avec les bonnes personnes. Sinon, cela risque de se désagréger très rapidement et de dégénérer en réunions de statut sans signification où tout le monde resterait et penserait "qu'est-ce que je fais ici? Je sais ce que je dois faire alors quoi diable?"

C'est mes deux cents. Je fais mon propre SCRUM comme le développement: planifier le travail, répartir les tâches, les estimer, observer les progrès. Cela m'aide vraiment à être au top des choses. J'ai appliqué certaines choses de SCRUM à des projets que j'ai externalisés et cela a très bien fonctionné pour moi.

Restez simplement agile ;-)

Je vous recommande d'ignorer la mêlée. Dans quelques années, une nouvelle mode apparaîtra, et vous serez moins cynique et pourrez toujours l'embrasser sans réserve. En fait, vous pourriez rapidement devenir un expert. Ensuite, vous pouvez gagner beaucoup d'argent en écrivant un livre et en prenant la parole lors de conférences.

Étant donné que beaucoup de choses sont cycliques, cette nouvelle mode sera probablement un processus lourd similaire à RUP. Ce qui se passera, vous voyez, c'est que tout le monde aura suivi des processus agiles légers, et ceux-ci seront blâmés pour leurs échecs de projet. Bien sûr, la solution logique est qu'une planification et une conception plus approfondies sont nécessaires!

Sérieusement, je ne pense pas que vous ayez besoin de Scrum. Il n'y a rien dans Scrum qui soit meilleur que d'autres processus agiles concurrents. De plus, il a beaucoup de noms stupides pour des choses.

C'est super, mais tout cela me semble être du bon sens. Pourquoi ce besoin a-t-il été codifié?

Scrum est généralement comparé à des méthodologies plus anciennes et plus lourdes. Les méthodologies ont essayé de faire fonctionner la cascade sans rétroaction en imposant plus de documents, plus d'approbation et plus de planification à l'avance. Le manifeste Agile (que vous citez) était un renversement de ces idées.

On me dit ensuite que la méthodologie nous aide à réagir au changement. Quels aspects spécifiques de SCRUM me permettent d'être si flexible que je ne le faisais pas auparavant avec mes réunions ad hoc, mes discussions de cube et mes réunions de planification de développeur?

Il semble que vous ayez déjà une structure agile. Si vous réagissez déjà bien au changement, vous n'avez évidemment pas besoin d'aide. Certains processus deviennent si limités avec la procédure que la correction d'un bogue nécessite une analyse complète et une phase de conception fonctionnelle, et ne peut entrer dans le projet que l'année prochaine, au plus tôt.

Ils expliquent la nécessité d'avoir un livrable fonctionnel toutes les deux semaines, ou sprint. Dans mon projet particulier, il n'y a pas de "client", le logiciel ne sera pas terminé avant un an ou plus, et en attendant, je ne ferai probablement des démonstrations à la haute direction que tous les mois ou moins. Alors pourquoi le besoin explicite d'un livrable toutes les deux semaines?

Original Scrum prescrit des sprints d'un mois. Il y a une tendance désagréable vers le machisme agile dans le raccourcissement des sprints. ( « Ouais, eh bien nos sprints ne sont que l' un jour ... ») Le Client / Client est celui qui a le pouvoir de dire que le projet est bon d'aller, ou a besoin de plus de travail. Si vous faites des démonstrations à la haute direction tous les mois, ils sont probablement votre client et vous êtes probablement déjà très proche de Scrum.

D'après votre description de ce que fait votre équipe, Scrum n'est probablement pas très différent. La normalisation peut vous apporter un certain intérêt, car il sera plus facile d'expliquer aux étrangers ce qui se passe si vous utilisez les termes Scrum. De plus, Scrum peut être utilisé comme bouclier; par exemple, Scrum prescrit que les décisions techniques doivent être prises par l'équipe - soulignant que ce principe peut être un bon moyen d'obtenir une valeur technique qui est autrement difficile à vendre (programmation par paires, par exemple.)

Scrum est fondamentalement une interface que votre équipe peut implémenter. Si vous le faites, alors vous avez une bonne idée sur la façon de communiquer avec les personnes extérieures à l'équipe, et ils ont une bonne idée sur la façon de communiquer avec vous. Vous seul pouvez savoir si votre équipe en a besoin.

Nous n'utilisons pas Scrum au travail. Nous utilisons une méthodologie fondée sur Agile et Lean qui est similaire à bien des égards. J'ai utilisé ce processus dans des équipes dont la taille varie entre 3 à 5 personnes, y compris le responsable. Bien qu'il existe des différences, je pense que vous pourrez peut-être vous aider à déterminer si Scrum est utile pour votre situation.

Rendre la méthodologie explicite

Nous rendons notre processus explicite parce que nous passons en revue notre processus à chaque conclusion / révision de sprint. Une partie du résumé / examen consiste à identifier les pratiques qui ne fonctionnent pas pour nous. Nous discutons également des pratiques qui, selon nous, fonctionneront pour nous et s'il y a suffisamment d'accord, nous les essayerons. Nous ne pourrions pas le faire sans codifier notre méthodologie.

Approuver

C'est le cheval de bataille de notre processus. Cela garantit que ce que nous écrivons est ce qui est nécessaire. Lorsque nous obtenons une fonctionnalité particulière, nous nous adressons à notre client. Le client est celui qui va utiliser ce que vous écrivez. Dans certains cas, vous devez mandater le client avec quelqu'un qui représente le client (comme la gestion des produits). Ce sont nos étapes, et jusqu'à ce que la dernière étape soit terminée, la fonctionnalité n'est pas terminée.

• Obtenez la fonctionnalité de la carte, du tracker, etc.
• Allez parler au client et comprenez ce qu'il recherche avant d'écrire quoi que ce soit.
• Implémentez la fonctionnalité.
• Montrez au client la fonctionnalité de travail dans sa forme finale Demandez au client d'approuver la fonctionnalité en cours.

Tranches verticales

Nous faisons tout notre développement en tranches verticales. Cela prend en charge la possibilité de se déconnecter avec une fonctionnalité terminée ainsi que ces autres raisons.

• Amortit les problèmes d'intégration en les intégrant à chaque fonctionnalité. Aide à éliminer le temps de crise à la fin d'un projet.
• Nous permet de couper facilement les fonctionnalités car nous éliminons beaucoup de dépendances croisées.
• Permet de couper le développement si nous devons changer de direction.
• Nous pouvons faire des versions itératives , fournissant au client des fonctionnalités au plus tôt.

Acceptation TDD

Nous tirons parti des cadres de tests unitaires pour l'acceptation tdd. Cela nous donne de nombreux avantages.

• Une grande restructuration ne coûte pas beaucoup de temps de reprise de test.
• Nous assurons la fonctionnalité client.
• Nous couvrons l'intégration de code.
• Prend en charge la pratique de développement de tranche verticale.

La version est toujours libérable

Après chaque poussée, le code devrait être libérable. Même si la fonctionnalité est incomplète, rien ne doit être cassé. Tous les tests doivent s'exécuter et toutes les fonctionnalités précédentes doivent être présentes. C'est vraiment une extension de notre développement de tranche verticale. En tant que tel, il partage bon nombre des mêmes avantages.

• Nous permet de couper facilement les fonctionnalités car nous éliminons beaucoup de dépendances croisées.
• Permet de couper le développement si nous devons changer de direction.
• Nous pouvons faire des versions itératives , fournissant au client des fonctionnalités au plus tôt.

Intégration continue

Chaque push génère une build via notre serveur de build CI. Le serveur de génération extrait le code, parcourt toute la suite de tests, marque le code et le conditionne pour le déploiement. Renforce notre politique selon laquelle la version est toujours libérable.

Estimation ponctuelle pour les cartes

Chaque bug, fonctionnalité et tâche devient une "carte". Une carte est la plus petite unité de travail logique qui présente certains avantages pour le client. Nous les signalons en fonction de notre échelle. Tout ce qui dépasse notre valeur maximale ou décomposé davantage. Nous avons constaté que plus la valeur en points est élevée, plus il peut y avoir d'écart dans le temps jusqu'à l'achèvement, ce qui décompose davantage les grandes cartes. Si la carte a suffisamment d'ambiguïté, elle est arrondie à la valeur en points suivante de l'échelle. Chaque carte doit être approuvée avant de pouvoir être considérée comme complète. Une estimation correcte soutient notre capacité à calculer la vitesse.

Rapidité

Nous avons des sprints d'une semaine. Chaque vendredi, nous planifions le travail et priorisons le travail pour la semaine prochaine. Sur la base de notre vitesse, nous avons une bonne idée de la quantité de «travail» que nous pouvons accomplir au cours de la semaine. Notre vitesse est la moyenne et la médiane du nombre total de points réalisés au cours de la semaine. Les augmentations de l'écart-type sont analysées pour les mauvaises estimations (qui essaient toujours de s'améliorer) ou les interruptions accrues (dont je parle au gestionnaire). La vitesse peut également être utilisée pour estimer une date d'achèvement précise pour un projet, mais uniquement s'il s'agit du seul projet en cours d'élaboration.

Amélioration et conception incrémentales

Nous avons également pour politique de laisser le code dans un état au moins un peu meilleur que celui que vous avez trouvé. Refonte / refonte du code au début d'une carte. L'objectif est de tenir compte de la croissance organique qui peut prévaloir avec un développement progressif. Nous refactorisons également à la fin par normal.

Pour la plupart, ce sont les règles que nous suivons et pourquoi nous les suivons.

Il me semble que vous faites partie d'une équipe très expérimentée et très fonctionnelle. Félicitations, Scrum / Agile formalise fondamentalement ce que votre équipe a toujours compris.

Je pense que ce qui peut être à l'avantage de votre entreprise (entière) est d'adopter Scrum comme un «terrain d'entente», non pas entre les membres de votre équipe de développement, mais entre votre équipe de développement et le département des affaires en général .

Alors que Scrum Sprints sont timeboxed, les équipes peuvent choisir entre la recommandation allant de deux semaines à 1 mois. Moins et il y aurait trop d'examens et de rétrospectives, et d'autres pourraient entraver la capacité de l'entreprise à changer de direction dans un délai d'un an. Il semble que vous ayez trouvé votre sweet spot de 1 mois, alors poussez pour cela.

Il y a beaucoup de latitude pour ajuster les paramètres Scrum et je suis sûr que vous pouvez expliquer à votre entreprise que vous faites toujours Scrum dans le bon sens. Un avantage est que si vous rencontrez l'entreprise à mi-chemin, leur implication peut apporter un soutien positif.