Je suis tout à fait nouveau dans le maigre / kanban, mais je me suis répandu sur des ressources en ligne au cours des dernières semaines et j'ai eu une question à laquelle je n'ai pas trouvé de bonne réponse. Lean / kanban semble autrement si bon ajustement pour notre société, qui utilise déjà Scrum, mais a atteint certaines limitations à l'intérieur de cette méthodologie. J'espère que quelqu'un ici peut me donner une bonne idée.
Comme je le vois, l'un des plus gros avantages de Scrum sur la cascade est l'utilisation de sprints. En ayant tout prêt tous les 14 jours, vous obtenez des cycles de commentaires courts et que vous pouvez libérer souvent. Cependant, comme je l'ai compris de lire sur lean, il y a des coûts associés à cela (par exemple, le temps passé dans les réunions de planification de sprint, les réunions d'engagement d'équipe et certains problèmes de trouver quelque chose d'utile pour tout le monde à la fin des sprints). < / p>
Lean / kanban supprime ces déchets, mais seulement au coût de ne pas pouvoir libérer tous les 14 jours. Ou ai-je manqué un point important? Pour, à Kanban, comment pouvez-vous travailler sur de nouvelles tâches de développement et libérer en même temps? Comment vous assurez-vous de ne pas expédier quelque chose qui ne fait que mi-chemin? Et comment pouvez-vous le tester correctement?
Mes meilleures "solutions / idées" jusqu'à présent sont:
En résumé, Ma question est : lorsque vous utilisez le maigre / kanban, pouvez-vous libérer souvent sans introduire de déchets? Ou est libérer souvent ne faisant pas partie de Lean / kanban?
Info supplémentaire spécifique à ma société : Nous utilisons le système de fondation de l'équipe et le contrôle des sources et avons déjà eu de mauvaises expériences en matière de branchement et de fusion. Pourrait-il être résolu simplement en apportant une expertise dans cette zone?
7 Réponses :
Le problème que vous décrivez semble plus un programme de contrôle source - Comment séparer les fonctionnalités faites des fonctionnalités en cours que sur Kanban. Vous semblez mettre une forte pénalité sur la gestion de nombreuses branches - ce qui est le cas pour les systèmes de contrôle de source non basés sur l'idée de plusieurs branches. Sur les systèmes de contrôle des sources distribuées, tels que Git et Mercury, tout est une branche et les avoir et travaillant avec eux est léger.
Je suppose que vous avez lu Ce blog sur Kanban vs Scrum et le guide pratique associé?
Et, en réponse à votre question, oui, vous pouvez libérer souvent avec Kanban.
Oui, bien noté! Je fais une pénalité sur la gestion de nombreuses branches. J'aurais peut-être peut-être déclaré que nous utilisions le système de base de la Fondation de l'équipe et le contrôle des sources et avoir eu des coûts liés aux succursales précédemment.
J'ai lu le guide avant, mais je n'ai rien trouvé concret sur la façon de libérer souvent. Au moment où je réalise après avoir lu votre réponse et que je pensais à cela, je me suis restreint dans ma pensée sur des problèmes concrets liés à ma société et que vous êtes bien sûr correct pour dire que vous pouvez libérer souvent avec Kanban.
L'équipe que je gère utilise Kanban et nous relâchons toutes les deux semaines. Si vous êtes strict sur ce qui est intégré à votre branche de code principal (tests passant, approuvé par le client, etc.), Kanban vous permet de libérer quand vous le souhaitez. Vous devez vous assurer que les histoires qui se déplaçant dans votre système ne sont pas co-dépendantes afin de le faire, mais sur mon équipe, ce n'est généralement pas un problème - une grande partie de notre travail implique la maintenance, qui consiste en plusieurs corrections de bogues non liées. / Caractéristiques par libération.
Merci pour les commentaires! À la suite de note: nous avons décidé d'essayer Kanban d'octobre sur, pour une période d'essai, de voir si nous l'aimons.
pour le contrôle source Je recommanderais vivement Perforce . Il rend la ramification et l'intégration des changements d'autres branches relativement simples et fournit la meilleure interface pour le contrôle source que j'ai vu jusqu'à présent.
L'intégration continue aide aussi bien - c'est-à-dire beaucoup de petits engagements quotidiens, au lieu de fantasmes énormes et potentiellement difficiles. Outils tels que Cruisecontrol peut vous aider à mettre en évidence lorsque la source reçoit brisé par un mauvais commit. En outre, si tout le monde apporte de nombreux petits changements, les changements contradictoires seront rares.
Je conseillerais également de ne pas essayer de suivre des choses comme Lean, Scrum, Kanban et Co. trop étroitement. Il suffit de résoudre vous-même les problèmes, en regardant ces idées de conseils plutôt que d'instruction. Les spécificités de vos problèmes nécessiteront probablement une certaine flexibilité pour la meilleure gestion.
La façon dont nous avons manipulé des versions hebdomadaires sur un projet d'ingénierie soutenu qui a utilisé Kanban était de mettre en œuvre une stratégie de ramification. Les Devs travaillaient dans une branche de sable de la sable et ont fait une vérification par article. Nos testeurs testeraient l'élément de travail dans le bac à sable; S'il est passé les tests de régression, la vérification serait migrée vers notre branche de version. Nous avons enfermé la succursale de la libération de midi lundi que lorsque la sortie ait disparu (généralement de mercredi, de temps en temps de jeudi, la date morte de la goutte était vendredi) et réaffirmer les tests de régression pour tous les contrôles migrateurs ainsi que des tests d'intégration pour le produit, laisser tomber une libération une fois que tous les tests ont passé.
Cette stratégie permettra à Devs de travailler continuellement sur des problèmes sans être gelés de leur succursale pendant le processus de libération. Il leur permet également de travailler sur des problèmes qui ont pris plus d'une semaine pour résoudre; Si ce n'était pas enregistré et testé / approuvé, il n'a pas été migré.
Si j'écoutais Kanban pour une nouvelle version d'un projet, j'utiliserais une stratégie similaire, mais le groupe Tous les Checkins associés en tant que «fonctionnalité», la migration d'une fonctionnalité en masse à la branche de version Une fois la fonctionnalité terminée, puis effectuant des tests supplémentaires d'unité / d'intégration / d'acceptation / de régression dans la branche de déverrouillage avant de supprimer une libération avec cette fonctionnalité. Notez qu'un concept clé de Kanban est limitant les travaux en cours, donc je pourrais limiter mon équipe à travailler sur une caractéristique à la fois (ce serait probablement plusieurs articles de travail / histoires d'utilisateurs).
Il y a plus à cela que le contrôle de la source, mais votre choix de TFS va vous limiter. Lorsque le projet Burton a été conçu en 2004, Microsoft ne faisait pas attention à Agile, beaucoup moins maigre. Ce sera votre lien mécanique le plus faible pendant un certain temps. Vos packles auraient dû être soulevés par la propre adoption de Mercurial de Codeplex après avoir été offerte à la communauté Microsoft en tant qu'affiale de la mise en œuvre de TFS.
Un problème plus saillant ici est la conception de travail. Il englobe l'ordre que vous choisissez de mettre en œuvre des fonctionnalités (calendrier de travail), ainsi que la hiérarchisation et le coût du délai, ainsi que la forme et la taille des éléments de travail.
Scrum est généralement interprété pour dire que les "propriétaires de produits" non techniques peuvent déterminer le calendrier de travail basé uniquement sur leurs propres préoccupations. Si vous suivez ce chemin, vous allez engager beaucoup de déchets en ne prenant pas les possibilités de travailler ensemble qui appartient ensemble. Le travail qui appartient ensemble ne peut pas être déterminé par les souhaits du propriétaire du produit. Les opportunités techniques et de main-d'œuvre) doivent également être prises en compte.
Pour que le travail soit fait de la manière la plus productive, le travail lui-même doit être conçu de cette façon. Cela signifie que dans une équipe de développement de produits LAN, des décisions ne sont pas prises par un travailleur non technique, mais par ce que Toyota appelle une personne de «compétence technique dominante» qui est proche du produit, proche des clients et à proximité de l'équipe. .
Ce rôle est un contraste distant avec la proposition de Scrum. Un ingénieur en chef sur une équipe maigre est lui-même (ou elle-même) la voix du client et le rôle du propriétaire du produit est inutile.
"Le propriétaire du produit" de Scrum est une reconnaissance d'un rôle sous-développé dans les organisations de développement de logiciels, mais il est loin d'une solution durable qui évite systématiquement les déchets. Le rôle de «architecte logiciel» est souvent insuffisant également, comme dans certaines sous-cultures de développeurs, l'architecte est devenu beaucoup trop retiré du travail.
Vos problèmes de déploiement continu ne sont que partiellement traités avec la technologie et les outils. Regardez également les problèmes organisationnels, et peut-être donner une idée de certaines personnes à l'intention de Scrum comme une approche transitoire de la cascade plutôt que celle qui peut servir votre organisation indéfiniment.
Vous devez comprendre les systèmes de tirage, ce que Kanban est conçu pour gérer.
Un client (ou propriétaire de produit ou similaire) Demande d'une fonctionnalité dans le système d'exécution est ce qui déclenche le processus.
La demande est un signal qui va au déploiement. Déploiement Recherchez un élément testé avec des propriétés correspondant à la demande. Si aucun n'est là, vous écrivez les tests et regardez le développement s'il existe une fente de développement pouvant être utilisée pour mettre en œuvre quelque chose qui remplit le test. Lorsque le développement a effectué son développement (peut-être à la recherche d'une analyse appropriée d'abord), le test fait son test et le déploiement déployé.
Les demandes à l'envers à l'aide du système sont des autorisations pour commencer à travailler. Dès que la demande est arrivée, cela déclenche beaucoup d'activité, où chaque activité devrait être complétée le plus rapidement possible. Là, vous avez votre déploiement turbo.
Tout comme si la demande d'une voiture va chez le revendeur qui regarde dans le navire qui signale à l'usine de la voiture, qui signale les fournisseurs.
Kanban ne consiste pas à pousser des demandes via un système. Il s'agit de tirer la fonctionnalité du système en échange d'une demande qui entre dans la dernière étape.
Comment nous le faisons:
Nous avons un pipeline avec les étapes suivantes
Chaque histoire est développée comme succursale basée sur la dernière version pour quitter la scène de déploiement. Ils sont ensuite intégrés dans le cadre de la préparation du test d'intégration.
QA tire de la phase de révision du code et peut préparer des versions à n'importe quel rythme souhaité. Je pense que nous avons un rythme d'environ une sortie chaque semaine.
En supprimant la branche "Master" de Git et de ne pas faire de fusion avant la phase d'examen du code que nous nous sommes assurée qu'il n'existait aucune possibilité de "faufiler" du code dans les versions. Ce qui, comme un sous-produit intéressant, nous a forcé à visualiser beaucoup de travail qui était caché.