Comment libérer souvent avec Lean / Kanban? [fermé]

Question

Je suis tout à fait nouveau Lean / Kanban, mais ont versé plus de ressources en ligne au cours des dernières semaines et je suis venu avec une question que je ne l'ai pas trouvé une bonne réponse pour. Lean / Kanban semble par ailleurs un bon moyen pour notre entreprise, qui utilise déjà Scrum, mais ont atteint certaines limites à 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 grands avantages de Scrum sur Cascade est l'utilisation des sprints. En ayant tout prêt tous les 14 jours, vous obtenez des cycles courts de rétroaction et peut libérer souvent. Cependant, comme je l'ai compris à la lecture à propos de Lean, il y a des coûts associés à ce (par exemple, le temps passé à des réunions de planification de sprint, des réunions d'engagement de l'équipe et quelques difficultés à trouver quelque chose d'utile pour tout le monde à la fin des sprints).

Lean / Kanban supprimera ces déchets, mais seulement au prix de ne pas être en mesure de libérer tous les 14 jours. Ou ai-je manqué un point important? Car, Kanban, comment pouvez-vous travailler sur les nouvelles tâches de développement et de libérer en même temps? Comment vous assurez-vous que vous ne livrez pas quelque chose qui est seulement à mi-chemin fait? Et comment pouvez-vous tester correctement?

Mes meilleures "solutions / idées" à ce jour sont:

• Ne pas relâcher souvent et laisser les déchets associés à l'exécution de nouvelles tâches de développement. Pas vraiment une solution à la question posée bien.
• Développer dans les branches, puis se fondre dans le tronc principal. Fait vous devez prendre en charge au moins deux branches en continu à l'intérieur.
• Utilisez un système intelligent d'étiquetage automatique pour construire automatiquement que certaines tâches terminées et pas d'autres.

En résumé, ma question est : Lorsque vous utilisez Lean / Kanban, vous pouvez libérer souvent sans introduire des déchets? Ou est version souvent ne fait pas partie du Lean / Kanban?

Informations complémentaires spécifiques à mon entreprise : Nous utilisons System Team & Source Foundation contrôle et avons déjà eu quelques mauvaises expériences en ce qui concerne la fusion et de branchement. Cela pourrait-il être résolu simplement en apportant une certaine expertise dans ce domaine?

Answer 1

Le problème que vous décrivez semble plus un programme de contrôle de source - comment séparer caractéristiques fait de caractéristiques en cours, d'environ Kanban. Vous semblez mettre une lourde peine sur l'exécution de nombreuses branches - qui est le cas pour les systèmes de contrôle de source ne sont pas fondées sur l'idée de branches multiples. Sur les systèmes de contrôle de source distribué, comme GIT et Mercure, tout est une branche, et de les faire et de travailler avec eux est léger.

Je suppose que vous lisez 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.

Answer 2

Vous devez comprendre les systèmes de traction, ce qui est ce que Kanban est conçu pour gérer.

Un client (ou le propriétaire du produit ou similaire) demande de fonction dans le système de fonctionnement est ce qui déclenche le processus.

La demande est un signal qui va au déploiement. regard du déploiement d'un élément testé avec des propriétés qui correspondent à la demande. Si aucune est là, vous écrivez des tests et regardez le développement s'il y a une fente de développement qui peut être utilisé pour mettre en œuvre quelque chose qui répond à l'épreuve. Lorsque le développement a fait de son développement (peut-être à la recherche d'une analyse appropriée la première et ainsi de suite), le test fait son test et le déploiement se déploie.

Les demandes reculez par le système sont des autorisations pour commencer à travailler. Dès que la demande est arrivée, ce qui déclenche beaucoup d'activité, où chaque activité doit être réalisée le plus rapidement possible. Là, vous avez votre déploiement turbo.

Tout comme la demande d'une voiture va chez le concessionnaire qui regarde dans le navire qui signale à l'usine automobile, qui signale aux fournisseurs.

Kanban est pas pousser la demande par le biais d'un système. Il est de tirer des fonctionnalités du système en échange d'une demande qui entre par la dernière étape.

Answer 3

L'équipe je gère utilise Kanban et nous libérer environ toutes les deux semaines. Si vous êtes strict sur ce qui sera intégré dans votre branche de code ligne principale (passer des tests, client approuvé, etc.), Kanban vous permet de libérer chaque fois que vous voulez. Vous devez vous assurer que les histoires se déplaçant à travers votre système ne sont pas co-dépendants pour ce faire, mais mon équipe qui est généralement pas un problème - une grande partie de notre travail consiste à l'entretien, qui se compose de plusieurs corrections de bugs non liés / caractéristiques par version.

Answer 4

La façon dont nous avons traité de presse hebdomadaire sur un projet d'ingénierie soutenu qui a utilisé Kanban était de mettre en œuvre une stratégie de branchement. Les développeurs ont travaillé dans une branche de bac à sable, et fait un checkin par poste de travail. Nos testeurs vérifieraient l'élément de travail dans le bac à sable; si elle a passé les tests de régression serait migré checkin à notre branche de sortie. Nous avons verrouillé la branche de sortie de midi lundi jusqu'à la sortie est sorti (en général le mercredi, à l'occasion de jeudi, la date morte de baisse a été vendredi), et re-couru les tests de régression pour tous et checkins migrés en tant que tests d'intégration du produit, la suppression d'une version, une fois tous les tests passés.

Cette stratégie laisse devs continuellement travailler sur des questions sans être gelé de leur branche au cours du processus de libération. Il laisse également à travailler sur des questions qui ont plus d'une semaine pour résoudre; si elle n'a pas été vérifié et testé / approuvé n'a pas migré se.

Si je dirigeais Kanban pour une nouvelle version d'un projet, j'utiliser une stratégie similaire, mais le groupe tous les checkins liés comme une « caractéristique », la migration d'une fonction en masse à la branche de sortie une fois que la fonction a été fait et en effectuant ensuite unité supplémentaire / intégration / acceptation / tests de régression dans la branche de libération avant de laisser tomber une version avec cette fonctionnalité. Notez qu'un concept clé de Kanban limite les travaux en cours, donc je pourrais restreindre mon équipe à travailler sur une fonction à la fois (ce serait probablement plusieurs éléments de travail / user stories).

Answer 5

Il y a plus à ce que tout contrôle de code 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, Lean beaucoup moins. Ça va être votre maillon le plus faible mécanique pendant un certain temps. Vos hérisser auraient dû être soulevées par le propre adoption de CodePlex de Mercurial après avoir été offert à la communauté Microsoft comme l'enfant d'affiche de la mise en œuvre TFS.

Une question plus saillant ici est la conception du travail. Il comprend l'ordre que vous choisissez de mettre en œuvre les fonctions (horaires de travail), ainsi que la hiérarchisation et le coût du retard, et la forme et la taille des éléments de travail.

Scrum est généralement interprété en disant 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 subir une perte de beaucoup en ne prenant pas les occasions de travailler ensemble qui appartient ensemble. Un travail qui appartient ensemble ne peut pas être simplement déterminée par souhaits produit propriétaire. Technique et la main-d'œuvre (compétences) doivent également être des opportunités pris en considération.

Pour les travaux à faire de la manière la plus productive, l'œuvre doit être conçue de cette façon. Cela signifie que dans une équipe de développement de produits Lan, les décisions sont prises non pas par un travailleur non technique, mais par ce que Toyota appelle quelqu'un de « Towering Compétence technique » qui est proche du produit, à proximité des clients, et proche de l'équipe .

Ce rôle est un contraste frappant avec la proposition de Scrum. Un ingénieur en chef d'une équipe Lean est lui-même (ou elle-même) la voix du client, et le rôle du propriétaire du produit est inutile.

« 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'être une solution durable qui évite systématiquement les déchets. Le rôle de « Software Architect » est souvent insuffisante et, comme dans certaines sous-cultures de développement, l'architecte est devenu beaucoup trop enlevé du travail.

Vos problèmes de déploiement continu ne sont que partiellement traitées avec la technologie et les outils. Regardez aussi les questions d'organisation, et peut-être réfléchir à l'objectif de Scrum comme une approche de transition de chute d'eau plutôt que celui qui peut servir votre organisation indéfiniment.

Answer 6

Pour le contrôle de la source, je recommande vivement Perforce . Il fait de branchement et l'intégration des changements dans d'autres branches relativement simples, et fournit la meilleure interface pour le contrôle des sources que j'ai vu jusqu'à présent.

L'intégration continue permet ainsi - à savoir beaucoup de petits, plus que tous les jours commits, au lieu de se confond énormes et potentiellement difficiles. Des outils tels que CruiseControl peuvent contribuer à souligner lorsque la source obtient cassé par un mauvais engagement. En outre, si tout le monde fait beaucoup de petits changements alors des changements contradictoires seront rares.

Je conseille également de ne pas essayer de suivre les choses comme maigre, Scrum, Kanban & co. trop près. Il suffit de résoudre les problèmes vous-même, à la recherche de ces idées d'orientation plutôt que l'instruction. Les spécificités de vos problèmes seront plus que probablement besoin d'une certaine flexibilité pour la meilleure gestion.

Answer 7

Comment nous le faisons:

Nous avons un pipeline avec les étapes suivantes

1. Carnet de commandes
2. TODO
3. En cours (Développer et tester rapidement)
4. Revue de code
5. Test (test Rigoureuse)
6. tests de test d'intégration et d'acceptation générale
7. Déployer

Chaque histoire est développée comme une branche basée sur la dernière version de quitter la scène Déployer. Ils sont ensuite intégrés dans le cadre de la préparation du test d'intégration.

QA tire de l'étape de l'examen du code et peut préparer les rejets à tout rythme le besoin. Je pense que nous avons un rythme d'environ une sortie chaque semaine.

En supprimant la branche « maître » de git et ne pas faire de fusion avant l'étape de la révision du code que nous avons fait en sorte qu'il n'y a pas possibilité de code « sournoise » dans les versions. Ce qui, comme sous-produit intéressant, nous a forcé de visualiser une grande partie du travail qui sert à cacher.