Scrum? Quel SCRUM?
Pour la première fois, l'approche SCRUM (
mêlée anglaise «combat autour du ballon») a été décrite par Hirotaka Takeuchi et Ikujiro Nonaka, qui ont remarqué que de petites équipes (5 à 9 personnes), composées de spécialistes divers, donnent de meilleurs résultats. La description la plus complète de SCRUM a été introduite pour la première fois dans son livre par Jeff Sutherland. Le livre s'appelle SCRUM. Jeff a commencé sa carrière en tant que pilote militaire, pendant la guerre du Vietnam, il a effectué plus d'une centaine de sorties. Ensuite, Jeff s'est engagé dans la science, mais le monde se souviendra de lui comme l'un des fondateurs de SCRUM. Le livre commence par une histoire vraie de la vie du FBI, qui a dépensé des millions de dollars pour développer un système automatisé conçu pour rechercher et traquer les criminels. Le problème était qu'après l'expiration du projet, les entrepreneurs avaient montré au FBI un produit complètement inopérant. Cela ne signifiait qu'une chose: les contribuables américains ont gaspillé des millions. La situation semblait désespérée jusqu'à ce que la direction du FBI se tourne vers la méthode de gestion de projet SCRUM alors naissante. Cette méthode est décrite dans un langage accessible dans le livre susmentionné, qui a d'ailleurs été traduit en russe. De plus, l'article traite des principales idées fausses et mythes qui peuvent effrayer les cadres supérieurs qui ont décidé de mettre en œuvre SCRUM dans leurs projets.
1. Un contrôle total qui tue la créativité
Chez SCRUM, c'est l'équipe de projet, et non la direction, qui décide comment atteindre l'objectif commercial. Une telle méthode motive et stimule une approche créative, contrairement à la gestion classique, où les employés se voient déléguer la mise en œuvre d'actions spécifiques de bas niveau, et ceux-ci, à leur tour, ne comprennent souvent même pas pourquoi cela est et comment cela affectera le projet dans son ensemble. Ainsi, dans SCRUM, la direction ne contrôle pas les actions de l'équipe de projet, et cela, à son tour, ne rend compte que des résultats à la fin de chaque sprint (une période prédéfinie, par exemple, 2 semaines). La transparence n'existe que parmi les membres de l'équipe de projet. Dans quoi se manifeste-t-il? Tout d'abord, des rassemblements de stand-up quotidiens au cours desquels chaque membre de l'équipe du projet raconte ce qu'il a fait hier, ce qu'il fera aujourd'hui, quels problèmes il a rencontrés. Cette pratique n'est pas destinée à contrôler la quantité de travail effectuée par chaque employé. Les rallyes debout sont conçus pour aider chaque membre de l'équipe à lever les obstacles dans leur travail et à consacrer des collègues à leurs plans, afin que chacun comprenne où le projet se déplace aujourd'hui et soit conscient de son rôle dans le développement de produits. Dans le même but, soit dit en passant, une planche SCRUM commune avec des autocollants, que tout le monde peut voir, et un espace ouvert, qui supprime les obstacles à une communication libre entre les membres de l'équipe, sert.
2. SCRUM prive les droits des ingénieurs les plus expérimentés, car ils obéissent à la décision de l'équipe
SCRUM crée un environnement dans lequel l'autorité est acquise non pas par les titres et les postes, mais par les compétences et l'expérience. Un exemple frappant de la situation inverse est la hiérarchie des forces armées, où le pouvoir est basé sur la position et le grade. Un capitaine peut être beaucoup plus talentueux et érudit qu'un colonel. Malgré cela, le capitaine doit obéir strictement. Une telle structure rigide est idéale pour des conditions extrêmes, telles que les hostilités, où les décisions doivent être prises rapidement, et leur discussion entraîne un retard, ce qui entraîne la mort de personnes. SCRUM n'annulera pas les titres. Chaque collaborateur a son propre poste en fonction de son expérience et de sa matrice de compétences. Néanmoins, dans le processus de discussion d'une décision particulière, le facteur dominant est une position claire et raisonnable, soutenue par l'expérience personnelle de l'employé dans le domaine en question, et non par son titre. Contrairement au mythe, SCRUM donne le pouvoir précisément aux membres de l'équipe qui articulent clairement des idées solides. Et comme vous le savez - celui qui pense clairement, il formule clairement.
3. SCRUM vise les valeurs commerciales à court terme et non le développement à long terme du projet
Ce problème est en effet pertinent. Heureusement, la question "Que faire?" il y a des réponses. Cela devrait commencer par le fait que si le projet ne dure pas longtemps, avec une durée ne dépassant pas six mois, ce problème ne se posera probablement pas. Une autre chose est lorsque le logiciel se développe pendant 2-3 ans ou plus. Il existe de nombreux articles dans lesquels les auteurs expriment leur douleur concernant de tels projets. L'armée de juin et du milieu (les synergies, comme vous le savez, sont chères et peu d'entre elles) engage son travail en toute confiance et le sprint client récolte de brillants résultats SCRUM après le sprint. Mais le problème est qu'après 5 à 10 sprints, l'ajout de nouvelles fonctionnalités devient problématique, et plus loin, plus difficile. Par conséquent, SCRUM est bon, mais vous devez penser à la stratégie et à l'architecture. Une situation similaire peut être évitée. Premièrement, au
moins 1 à
2 ingénieurs expérimentés au maximum travailleront sur le projet, qui passeront par eux-mêmes toutes les validations du référentiel lors de la révision du code. Deuxièmement, consacrer beaucoup de temps à la formation (au moins 3 heures par semaine) d'ingénieurs juniors et intermédiaires en architecture logicielle, modèles de conception et comment cela est appliqué à un projet existant. Ces cours devraient être accompagnés de pratique et de devoirs minimaux pour un meilleur apprentissage. Les missions pratiques peuvent être intégrées dans l'arriéré des sprints de projet. Cela n'affectera pas beaucoup la rentabilité du projet, mais cela accélérera le processus de croissance des employés et évitera des problèmes potentiels avec l'architecture logicielle. La tenue de réunions périodiques permettra aux équipes de projet d'apprendre les unes des autres, ce qui ne nuit pas à la qualité du logiciel produit.
4. SCRUM empêche les ingénieurs de développer
SCRUM suppose que toutes les décisions concernant la manière d'atteindre les objectifs commerciaux sont déléguées à l'équipe. Le propriétaire du produit décide de ce qui doit être fait et l'équipe décide comment. Il s'ensuit que l'équipe doit être suffisamment compétente pour prendre des décisions efficaces. Par conséquent, la pierre angulaire de la méthodologie SCRUM est la formation. C'est pourquoi dans toutes les plus grandes banques et sous-traitants informatiques, une grande attention est accordée au développement: formations, séminaires, cours. La croissance professionnelle des employés fait partie intégrante de SCRUM. Étant donné que les équipes SCRUM sont relativement petites, les membres de l'équipe doivent maîtriser l'ensemble de la pile technologique au sein du projet sur lequel ils travaillent. À la fin du projet, l'ingénieur reçoit de nouvelles compétences, ce qui augmente sa valeur sur le marché du travail.
Sous-total
SCRUM, comme toute autre méthode de gestion de projet, a ses propres caractéristiques et rugosités qui doivent être connues et prises en compte. Malgré cela, il donne le meilleur résultat parmi les méthodes connues aujourd'hui.
1. Jeff Sutherland // SCRUM 2017.