👩🏿‍💻 🚢 👲🏽 Scrum peut-il être utilisé dans l'externalisation? 🔂 🈚️ 👨🏿‍⚖️

La question est très controversée, et je n'ai personnellement pas trouvé de réponse simple et évidente, bien que je la cherche depuis longtemps et que je la cherche toujours (je crois toujours que je trouverai un moyen d'utiliser l'essence pure de la mêlée et rien d'autre sur le projet d'externalisation). Néanmoins, le cadre lui-même fournit beaucoup de nishtyaks, dont les avantages sont difficiles à nier, voire impossibles. Et pourtant, dans la question à laquelle l'article s'intitule, un vrai problème se lit entre les lignes. Laisser s'exprimer.

Problème

Scrum est un framework agile, il implique un développement agile. Le développement agile nécessite des délais flexibles et un budget similaire. L'externalisation du développement, quant à elle, dans 95% des cas (hors impasse) implique des délais et un budget serrés. Conditionnellement: «fais de moi un portail d'entreprise en 3 mois, le budget est de 3 millions d'euros. Je te paie pour le résultat. " Et le client a raison, il veut voir le résultat. Et le manager doit conduire l'équipe à ce résultat. Mais voici comment faire avec Scrum?

Ce cadre suppose une incertitude dans le calendrier et le budget. Autrement dit, déjà au stade initial du projet, la mêlée elle-même vous dit: "Attendez, je ne peux pas venir ici, il y a des délais clairs et un vrai budget, vous devez chercher un chemin critique, tout planifier à l'avance, chercher quelque chose de cascade."

Solution au problème

Étape 1. Commencez avec quelque chose de cascade pour vendre vos services.

Dès l'enfance, mon père m'a appris: "Il n'y a pas de noir et blanc, cherchez partout le pour et le contre". Oui, la cascade est dépassée, oui elle n'est pas très adaptée au développement agile, mais elle permet de comprendre et de calculer le chemin critique en tenant compte de tous les risques. Très probablement, le chemin critique sera inexact et même une évaluation pessimiste sera très optimiste (si vous comprenez ce que je veux dire), mais cette étape donnera une compréhension approximative de la quantité de travail pour vous et votre client.

Vous devrez passer beaucoup de temps à évaluer le projet avec les développeurs. Pour une discussion sur les fonctionnalités. Et c'est un temps qui est dommage à passer, car les fonctionnalités devront encore être surestimées plus tard, mais jusqu'ici sans lui, nulle part ailleurs; sinon le projet ne se vendra pas et le chien du développement externalisé ne cassera pas la chaîne, à la poursuite du prochain os - il n'y aura pas d'os.

(!) Cette étape ne signifie pas la vente directe, il s'agit uniquement de déterminer le conditionnel «de» et «à» en argent et en termes.

Étape 2. Hourra! Nous avons pris le projet, nous commençons à travailler sur la mêlée (à son image et à sa ressemblance)

Le projet est pris. Il semble que tous les délais soient là. La tâche est claire, eh bien, conduit à faire. Alerte! Ne sois pas si rapide. Beaucoup de choses ont probablement changé depuis le moment où vous avez évalué le projet pour la première fois. Pourrait, par exemple, apparaître design ou voler une nouvelle liste de souhaits du client.

J'ai une suggestion. Essayez la mêlée. Dans le backlog du produit, sélectionnez le backlog de sprint, groom. Planifiez soigneusement votre sprint et voyez comment l'équipe le gère. Faites des scrams quotidiens au format "Ce que le développeur a fait hier / Ce qu'il fait aujourd'hui". Et rétro à la fin du sprint, pour résumer les succès de chacun et les succès de l'équipe dans son ensemble. Vous remarquerez rapidement comment le KPI de chaque développeur croît de sprint en sprint, comment le nombre de retours de QA diminue et comment le backlog de produit diminue.

PS Ne vous précipitez pas pour refuser les nouveaux souhaits des clients. Peut-être qu'elles ont un sens et qu'elles peuvent être entrées en toute sécurité dans le backlog de produit au lieu de certaines autres fonctionnalités qui se sont avérées ne plus être nécessaires aux activités de votre client (et, par conséquent, au client lui-même).

Étape 2.1 Présentez le propriétaire du produit au projet

Le plus souvent, les sociétés d'impartition n'ont qu'un seul chef de projet. Sans se diviser en maîtres de mêlée et propriétaires de produits, mais ce n'est pas un si gros problème qu'il n'y paraît à première vue.

Par exemple, j'ai un testeur sympa sur le projet, à qui j'ai délégué 90% des responsabilités du Product Owner (les 10% restants sont ceux du client, et je les transmets déjà à mon collègue). Outre le fait qu'il est engagé dans des tests (et il le fait parfaitement), il gère et reconstitue également le backlog, écrit un dock, construit des tables de flux et d'entités: il fait un excellent travail (pas au détriment de son cœur), pour lequel je n'ai tout simplement pas le temps, en raison de l'emploi sur d'autres projets.

Dans cette approche, il y a un autre énorme avantage. Pour un testeur expérimenté (et seul cela peut être confié à la propriété du produit), c'est une excellente occasion de ne pas vous ennuyer et de vous amuser avec de nouvelles tâches + de ressentir votre valeur. N'oubliez pas de faire confiance aux membres de votre équipe, du moins parce que c'est ainsi que vous augmentez votre autorité.

PS Maintenant je travaille sur un tel modèle pas sur tous mes projets. Quelque part, une mêlée n'est tout simplement pas nécessaire, car elle complique. Il s'agit principalement de petits projets d'une durée d'un mois ou moins.

Étape 2.2 Convertir la note d'horloge en points d'histoire

Pas l'étape la plus importante, vous pouvez travailler sans elle, mais plus difficile. Le fait est que lorsque vous évaluez la tâche dans la montre, l'horloge est différente pour tout le monde, il faut 6 heures pour que quelqu'un crée une entité de domaine (tâche conditionnelle), quelqu'un en a 7, quelqu'un en a 8. Dans les points d'histoire tout le monde aura la même chose = 8.

Selon les histoires, il sera plus pratique de calculer le KPI de chaque développeur, d'établir une revue de performance et de suivre le succès du projet dans son ensemble.

Arrangez-vous avec les développeurs pour 8 points d'histoire (5 Mo pour juin) par jour, planifiez en fonction de cela et regardez comment les tâches sont fermées et le projet est mis en œuvre.

Si un développeur ferme soudainement 8 points d'histoire en 4 heures (5 points d'histoire, selon les chiffres de Fibonacci), ne le chargez pas avec de nouvelles poignées. Appréciez votre accord, respectez son travail. Une partie de son temps «libre» restant sera toujours consacrée à l'étude du prochain long métrage, à la préparation de demain, et une partie au développement personnel, voire aux loisirs. Les bons loisirs motivent également à bien travailler.

Étape 3. Cool Work

Ne faites pas tout comme écrit dans les guides Scrum ou dans tout autre standardiseur pm. Prenez des décisions avec souplesse et tirez parti de la situation. Sélectionnez avec soin les outils proposés par les différents frameworks et n'hésitez pas à en essayer un nouveau.

Pas besoin de travailler en cascade ou en mêlée pour gérer les projets avec succès. Besoin de travailler cool. C'est tout.

Conclusion

Scrum peut être utilisé et il sera très utile: un excellent cadre qui offre un tas d'outils sympas pour être constamment au courant, pour se développer et fournir la base de la croissance de l'équipe, suivre l'avancement du projet et considérer les KPI des membres de votre équipe.

Néanmoins, Scrum n'est pas une panacée, et dire, par exemple, au client que nous ne savons pas initialement combien le projet vous apportera et combien de temps cela prendra en termes de développement externalisé, très probablement ne fonctionnera pas. C’est tout de même sans éléments en cascade.

N'hésitez pas à combiner les frameworks et à utiliser les outils que vous et votre équipe aimez, même s'ils ne sont pas censés être de la mêlée. Faites-le fonctionner facilement, car c'est le principal objectif de chaque cadre. Et comment l'appeler dépend de vous.

PS Je l'ai HMS - mêlée génétiquement modifiée.

Scrum peut-il être utilisé dans l'externalisation?