Qu'est-ce que SAFe?
Qu'est-ce que l'Agile, beaucoup le savent. Un nombre encore plus important de personnes impliquées dans l'informatique utilisent la terminologie. En savoir plus sur Agile.
Pas tous ceux qui utilisent avec confiance le terme Agile pour la communication, la critique, pour cela; Pour mieux présenter leur équipe ou leur entreprise, ils comprennent, par exemple, quelle est la différence entre SCRUM et Agile; et mettent souvent un signe égal entre ces deux concepts différents. Mais il n'y a pas si longtemps, en 2015, SAFe est également apparu. Qu'est-ce que c'est et pourquoi est-il nécessaire?
L'un des avantages et inconvénients importants de SCRUM, je considère que la taille prescrite des commandes est 7 + -2 (ou 3-9 données plus récentes du Guide Scrum ), y compris le Product Owner.
Bien sûr, 9 professionnels de haut niveau et bien motivés sont capables de beaucoup, mais il est parfois nécessaire de construire quelque chose avec un grand nombre de mains, de têtes, d'yeux et de cerveaux au final. Gonfler des équipes est mauvais, donc leur nombre doit être augmenté, et ici le problème de la communication entre les équipes se pose, la synchronisation du travail et SCRUM lui-même n'offre aucune solution pour ces tâches. Il y a des tentatives d'utilisation de SCRUM au niveau de la gestion des commandes SCRUM (comme Jeff Sutherland, l'un des auteurs du manifeste Agile le conseille), il y a Scrum à grande échelle, il y a la livraison agile disciplinée, il y a beaucoup plus, mais il y a aussi SAFe - Scaled Agile Framework.
SAFe est un cadre de gestion d'entreprise qui nécessite la coordination des travaux sur un certain projet ou des projets connexes pour 5 équipes SCRUM ou plus. C'est-à-dire c'est une superstructure sur SCRUM qui vous permet de gérer des équipes de 100 personnes ou plus
Avantage?
Tout d'abord, bien sûr, la méthodologie est nécessaire à ceux qui la vendent et s'engagent dans la formation. Dave Thomas (l'un des auteurs du manifeste Agile) a très bien parlé à ce sujet lors de GOTO 2015 dans sa présentation Agile is Dead
Deuxièmement, les départements de gestion des programmes. Ceux qui étaient auparavant impliqués dans la gestion de projet ont reçu la certification PMP, dessiné des diagrammes de Gantt et mis en œuvre le concept de gestion hard-soft (avec un côté doux pour la direction et un côté dur pour les interprètes). Le fait est que dans un SCRUM typique, il n'y a pas de fonction pour eux, dans SAFe c'est le cas. Il en va de même pour toutes sortes d'architectes. Dans SCRUM, il n'y a pas de fonction pour eux dans SAFe - il y a un cheminement de carrière.
En outre, cela peut être bénéfique pour les propriétaires d'entreprise où les gestionnaires travaillent sur de grands projets dévorant un grand nombre d'heures de travail et ne peuvent pas (parfois pour des raisons objectives) rendre ces projets indépendants.
De nombreux développeurs avec des qualifications inférieures à la moyenne souvent pour faire quelque chose, ils doivent être exponentiellement plus nombreux que les professionnels les plus expérimentés et les plus motivés.
Toute l'industrie. Parce que le nombre de développeurs double tous les 5 ans (voir l'avenir de la programmation de l' oncle bob ), ce qui a pour conséquence qu'à tout moment au moins la moitié des développeurs ont moins de 5 ans d'expérience professionnelle. Si la tendance ne change pas, mais ne change apparemment pas, alors des processus sont nécessaires pour prescrire et formaliser leurs fonctions de travail, les mécanismes d'interaction entre les participants et l'ensemble du processus.
Essence
SAFe est un gâteau de couches issu de diverses techniques Agiles. Au niveau inférieur se trouve le SCRUM presque traditionnel, avec des sprints typiques de deux à trois semaines, des équipes de 3-9 personnes, y compris le Product Owner. Tous les rituels typiques, allant de la planification quotidienne - standup et se terminant par un débriefing à la rétrospective. Bien qu'il y ait une différence clé. La commande cesse d'être un module indépendant entièrement fonctionnel. Et le sprint cesse d'être une période de temps indépendante avec un cycle de vie complet. Les sprints sont combinés en incréments de programme composés généralement de 5 sprints. C'est-à-dire si dans SCRUM classique nous n'avons pas construit ce que le client aime, alors nous faisons la correction de cap au prochain sprint, puis dans SAFe nous continuons à aller vers le bord jusqu'à la fin de l'incrémentation du programme, dans le pire des cas, les 4 prochains sprints (bien sûr, j'exagérerai).
Au niveau suivant, nous avons des trains - le soi-disant train de libération agile. Il existe de nouvelles fonctions pour gérer 5 segments de sprint: un architecte système (celui qui possède l'architecture - c'est-à-dire qu'il n'est plus une équipe), le chef de produit (celui qui contrôle le produit, pas le Product Owner, ce dernier va à PM pour des conseils) et RTE - le même PMP du monde lointain de la cascade. Ici, certains développements de Kanban sont appliqués, en particulier, un tableau, une méthode pour attribuer des priorités et, dans l'ensemble, le principe de mesurer la performance historique des équipes (vitesse) et de projeter ce qui sera construit à la fin de l'intervalle de temps par opposition à l'approche avec des estimations et assigner des délais pour une fonction déjà fixe ( portée). L'une des innovations est que le dernier sprint de 5 est déclaré organisationnel et au cours duquel se tiennent d'énormes réunions (toutes les équipes ensemble - et c'est 100 personnes ou plus), une analyse de la dette technique est réalisée, des plans de développement de l'architecture sont réalisés et le travail de toutes les équipes est synchronisé.
Au-dessus du niveau du train, nous avons une coordination entre les départements, les directeurs et le client. Il y a plus d'emprunts auprès de Lean Agile, mais les mêmes outils de Kanban sont préservés. Il s'agit d'une analyse de la faisabilité économique du changement. Idéalement, tout changement passe par une analyse préliminaire où une hypothèse mesurable sur le changement à venir est avancée (par exemple, si nous faisons une boutique en ligne d'un centre de données vers le cloud, puis en augmentant rapidement les capacités au pic des ventes saisonnières, nous pouvons augmenter le nombre de transactions de 10%), puis cette hypothèse est confirmée soit non. Pour les entreprises de moins d'un milliard de dollars, ce sera peut-être le dernier étage. Des plans de travail de 12 à 36 mois sont créés ici (plans quinquennaux de qualité, quantité, etc.)
Au-dessus du niveau des grands systèmes se trouve la gestion de portefeuille. Les fonds sont alloués à divers domaines d'activité. La gestion de portefeuille Lean est utilisée, en utilisant la stratégie de développement de l'entreprise, les domaines à partir desquels vous pouvez obtenir un rendement sont sélectionnés. Ici, les décisions sont prises concernant l'achat ou la fusion avec d'autres sociétés. Création de nouveaux métiers, fermeture des anciens. Le budget est régulièrement ajusté et réaffecté (par opposition aux plans trimestriels ou annuels). Pour chaque composante du portefeuille, un ensemble de métriques plus ou moins standardisées est établi puis toutes sont évaluées en fonction d'elles. En plus des 3 niveaux précédents, il y a des rituels spéciaux de synchronisation toutes les deux semaines (généralement) - il y a un échange de statuts et d'indicateurs clés.
Mené par toute la stratégie. La façon dont il est défini n'est pas décrite par le cadre.
Avantages
- Un nombre important de très bons outils (WSJF, Kanban, Gemba, etc.)
- Formalise et prescrit les étapes pour SDLC de l'écriture de code (prescrit par TDD) à l'exécution de scans statiques et CI / CD et basculement de fonction. Que chacune des pratiques soit bonne ou non est une autre question, mais au moins il y a un plan et tout le monde le suit.
- Le processus peut être compris, expliqué et mis en œuvre.
- Chaque personne dans le cadre de ce processus reçoit une fonction assez strictement définie.
- Augmente la transparence de l'entreprise pour ceux qui y travaillent.
Inconvénients
- Assez de temps pour répondre à une inadéquation de la réalité avec les attentes
- Une énorme somme d'argent et d'argent est dépensée pour la communication et les réunions
- Les solutions souvent recommandées dans le cadre sont obsolètes
Introduire ou non? Je crois que s'il y a un choix, alors non, il vaut mieux réduire la dépendance entre les départements et les projets. Et s'il n'y a pas de choix et que vous devez gérer un énorme projet, c'est tout à fait possible.