Ist jemand mit Kanban? [geschlossen]

Question

Ist jemand Kanban (oder scrumban) für die agilen Management-Praktiken? Was ist Ihre Erfahrung mit Kanban? Wie sieht es mit Abhängigkeiten von Wasserfall-Projekten in großen, komplexen Umgebungen arbeiten?

Answer 1

weiß, dass ich die BBC es ziemlich ausgiebig nutzen. Siehe David Joyce Blog für weitere Details http://leanandkanban.wordpress.com/

Er hat ein ziemlich kräftige Rutsche Deck dort. Zu sichten

Ich denke, die Sache über Lean Denken zu erinnern ist, dass Sie den Wert Strom als Ganzes betrachten müssen. Während Sie Super des Entwicklungsteam mit Hilfe von Techniken wie Kanban optimieren, ist es wichtiger, sowohl zu übernehmen bis Strom (Management / Analyse) und nachgelagerten (QA / deployment / Support) in vollem Umfang die Früchte zu ernten.

Daher zu fragen, wie paßt das in einen Wasserfall oder komplexen Prozess (über Ihre persönliche Wirkung), ist nicht ganz die richtige Frage. Was ist eine weitere wichtige Frage ist, zu fragen, wie kann ich den gesamten Wertstrom zu bewirken beginnen. Ich weiß, das klingt wie der Anfang des religiösen Lean zealotry, aber es ist, wie Sie den wahren Wert eines schlanken Prozess zu realisieren.

Zum Beispiel das folgende Szenario für ein typisches Projekt:

• Analysezeit: 18 Monate
• Dev Zeit: 9 Monate
• QA & Release-Zeit: 4 Monate
• Kunden Annahme und Nacharbeit: 12 Monate

Insgesamt: 43 Monate

Wenn durch Lean den Entwicklungsprozess bewerben Sie sich um 100% verbessern, eine Entwicklungszeit von 4,5 Monaten, dh, einen neue insgesamt 38,5 Monate zu bringen. Sie haben dann erhöht nur den Gesamtwertstrom von knapp über 10% ... unbedeutend !!

Sie müssen beginnen, um den Kampf zu kämpfen und die Lean Denkt oberes Management übernehmen und zeigen, wo echter Erfolg liegt ..., die in der Neugestaltung des gesamten Prozesses ist.

Denken Sie daran, Lean ist kein Entwicklungsprozess, kann es auf jeden Aspekt des Geschäfts angewendet werden.

Einige interessante Bücher darüber, wie diese Diskussion nehmen über die das Entwicklungsteam gehören;

• Lean Thinking
• Beyond Budge
• Throughput Accounting
• Der Toyota Way
• Implementierung von Lean Software Development: Vom Konzept einzulösen

Answer 2

Zunächst einmal ist es wichtig, die Probleme zu erkennen, dass Kanban in der Softwareentwicklung zu lösen versucht:

• Multi-Tasking / Überlastung der Arbeit . Kanban befasst sich mit diesen durch seine Just-in-time und Queue-Systeme. Dort ist in der Warteschlange zu halten, ausreicht, jeder damit beschäftigt, aber nicht überlastet (Das kommt mit der Praxis mit Schätzung und effiziente Geschwindigkeit Überwachung). Und JIT stellt sicher, dass Menschen haben nicht zu Multi-Task und daher lose Produktivität.
• Unpredictable Downstream-Releases . Wenn Sie in einem großen Software-Unternehmen arbeiten, könnte entwickelt das Stück, das Sie nur ein von Software in einem großen Nebeneinander sein. Daher könnte es Downstream-Team sein, die für Ihre Funktion warten könnten. Kanban Warteschlange System zusammen mit seiner zeit boxed Lieferzeiten sicherzustellen, dass es ein gewisses Maß an Vorhersehbarkeit in den Versionen.

Meist andere agile Praktiken versuchen, auch ähnliche Probleme mit verschiedenen Techniken zu lösen.

  

große, komplexe Umgebungen mit Abhängigkeiten von Wasserfall-Projekten

Das macht es schwer, wenn Sie eine Abhängigkeit von einem Projekt, das nicht agil wie dann Ihre Eingabe-Warteschlange nicht vorhersehbar folgt. Wenn ein nicht-agiles Projekt von Ihnen abhängt, könnte das Problem geringer sein - aber Sie könnten mehr produzieren am Ende als verbraucht werden kann ( ‚Muda‘ in Lean-Terminologie). Also, im Idealfall würden Sie alle abhängigen Projekte wollen zumindest folgenden einige agilen Praktiken, wenn nicht selbst Kanban.

Ein schöner Artikel über Kanban, Strömungs- und Cadence können hier .

Answer 3

  

Ist jemand Kanban (oder scrumban) für die agilen Managementpraktiken mit?

Ja, ich bin mit: -)

  

Wie es in großen, komplexen Umgebungen mit Abhängigkeiten von Wasserfall-Projekten funktioniert?

In unserer Umgebung haben wir> 500 Entwickler, so ist es recht groß. Mein Team war die erste, die Kanban verwendet, vor allem für Wartungsarbeiten und jetzt für die Entwicklung. Unsere tägliche Arbeit war sehr schwer, weil die anderen je Teams folgenden klassischen Entwicklung und Management-Techniken waren, und sie wollten (sie tun noch) zu Push die Arbeit und Kanban etwa ist ziehen .

Unser Ansatz war, so viel wie möglich machen unsere Arbeit transparent, aber aufgrund der Zurückhaltung der Umwelt kommunizieren wir auf unserer internen Arbeit wurden konzentriert. Die WIP-Grenze half uns konzentriert bleiben, und mit dem visualize Workflow wussten wir, wer was im Moment tut.

Unser Durchsatz vor Kanban betrug 90% (in anderen Worten, wenn 10 Teile kommen, lieferten wir nur 9), und nach dem Kanban hatten wir 100,4% und es wurde erhöht. Als zusätzliches Ergebnis gestartet anderen Teams kamen nach und fragen Sie nach Kanban, weil sie unsere Ergebnisse gefallen hat, und wollten ihre eigene Kanban-System implementieren. Im Moment weiß ich über 5 Teams, die Kanban in unserer Organisation gestartet.

HTH,

Zsolt