• Noser.com
facebook
linkedin
twitter
youtube
  • NOSERmobile
    • Android
    • HTML 5
    • Hybrid Apps
    • iOS
    • Windows Phone
  • NOSERembedded
    • Medizintechnik
  • NOSERprojektmanagement
  • NOSERtesting
  • NOSERlifecycle
    • .NET Allgemein
    • Application Lifecylce Management
    • Apps
    • Architektur
    • ASP.NET
    • Azure
    • Cleancode
    • Cloud
    • Silverlight
    • Visual Studio / Team Foundation Server
    • Windows 8
    • Windows Presentation Foundation
  • NOSERinnovation
    • Big Data
    • Cloud
    • IoT
    • Operations Research
    • Augmented Reality
    • RFID, NFC, Bluetooth LE

Was Kanban nicht kann

22. August 2013
Nathalie Kellenberger
0
Agile Softwaremethoden, Kanban, Scrum

Agil, Scrum, Kanban … Schlagworte der Informatik heute. Scrum und Kanban lassen sich erst noch kombinieren, daraus entsteht dann Scrumban.

Scrum ist vermutlich den meisten ein Begriff, Kanban vielleicht weniger. Dazu gibt es ein kostenloses Buch, das eine schnelle Einführung in Kanban gibt: Kanban Scrum Minibook.

Wer schon an einer Scrum Schulung oder Einführung war, weiss, da steht ein begeisterter Trainer vor einem und füttert einen mit Schlagworten darüber, was der Prozess alles kann. Das Ganze ähnelt einem Verkaufsgespräch. Das macht durchaus Sinn, denn bei Scrum wie Kanban ist es wichtig, dass der Prozess gelebt wird, damit er funktioniert und das lässt sich wiederum am besten über Begeisterung bewerkstelligen.

Ich will gar nicht viele Worte über das Prinzip von Kanban verlieren. Kanban stammt ursprünglich aus der Automobilindustrie und wurde bei Toyota fürs Fliessband entwickelt. Was hat jetzt Software mit Fliessband zu tun? Ein Verkäufer hat darauf sicher eine Antwort.

Kanban verwendet analog zu Scrum ein Board, um Transparenz zu schaffen. Die bestehenden Firmenprozesse werden auf das Board in mehrere Phasen bzw. Spalten abgebildet. Bspw. Input-Queue, Analyse, Entwicklung, Abnahme, Live-Schaltung. Der Prozess will Engpunkte in den bestehenden Prozessen aufdecken und diese verbessern. Er arbeitet mit dem, was da ist und zwingt das Team nicht, einen neuen Prozess zu lernen wie bei Scrum. Soweit so gut.

Sprints gibt es nicht, dafür WIP (work in progress), der minimiert werden soll. Der Gedanke dahinter ist, dass sich der Entwickler immer auf eine Aufgabe konzentriert und diese zu Ende bringt, anstatt ständig zwischen unterschiedlichen Aufgaben wechseln zu müssen. Denn dieser Wechsel kostet Zeit! Eine VM muss runter-, die nächste hochgefahren werden, der Kopf muss sich erst in die neue Aufgabe hinein denken. Soweit einleuchtend.

Damit das Team sich auch daran hält, erhält jede Spalte eine Limite als Kontrollgrösse. Wenn die Entwicklungsphase eine Limite von drei besitzt und das Team aus drei Entwicklern besteht, kann sich jeder auf eine Aufgabe konzentrieren. Wenn Pairprogramming erwünscht ist, schraubt man die Limite auf zwei runter. Ändert das Team und wird aufgestockt auf vier, kann die Limite angehoben werden. Für gewöhnlich beginnt das Team mit einer höheren Limite und versucht, diese nach unten zu schrauben, um den Durchfluss der Arbeit zu erhöhen. Soweit sinnvoll.

Wenn ein Entwickler aufgrund der Limite keine neue Arbeit in Angriff nehmen kann (weil bspw. der Tester nicht nachkommt mit der Abnahme), zieht er die rote Leine. Die ganze Produktion stoppt, das Problem wird behoben (wie dass der Entwickler im Testing aus- oder bei einem anderen Entwickler mithilft), damit alle weiterarbeiten können. Soweit die Konsequenz.

Der Kern und zugleich Knackpunkt von Kanban ist die Schaffung einer angstfreien Kultur. Der Prozess fusst darauf, dass Teammitglieder Probleme melden, um den Prozess zu optimieren. Der Prozess muss nicht nur im Team, sondern auch beim Auftraggeber, ja beim ganzen Umfeld verankert sein und gelebt werden. Damit der Entwickler sich auf eine Aufgabe fokussieren kann, müssen die Anforderungen klar sein, müssen die Zulieferer mitziehen. Dahinter versteckt sich, östliches Gedankengut im Westen zu leben. Genau da steckt meiner persönlichen Meinung nach der Wurm drin. So sehr wir uns für alles Östliche begeistern (auch ich mache Yoga), muss das Gedankengut meist auf uns zugeschnitten werden.

Eine rote Leine zu ziehen wirkt abschreckend (allein schon die Farbe, rot!). Bei uns im Team ist die rote Leine eine Hupe, dh. dass tatsächlich das ganze Umfeld mitbekommt, wenn die Produktion stoppt. Wenn gehupt wird, werden alle in ihrer Arbeit gestört. Denn die anderen müssen alles stehen und liegen lassen und ans Board hechten, um das Problem des einen zu beheben. Wir haben im Team festgestellt, dass wir uns alle über das Hupen genervt haben. Dabei wurde nicht wie vom Prozess vorgesehen vier Mal die Woche sondern gerade einmal alle zwei Wochen gehupt!

Der Durchfluss der Arbeit sollte durch Kanban automatisch erhöht werden, was in der Praxis nicht unbedingt der Fall ist. Denn dazu muss der Einzelne daran interessiert sein, seine Arbeit so schnell wie möglich zu erledigen. Die Stimmung im Team war eher entspannt. Endlich hatte jeder Zeit, seine Arbeit gründlich zu tun. Sich erst einzulesen, eine VM ganz neu aufzusetzen. Keine Termine, kein Abgabedruck, kein Sprint, kein Stress. Damit will ich keinesfalls sagen, dass irgendein Teammitglied schlechte Arbeit abgeliefert hat oder das vorsätzlich wollte. Das ist nie der Fall. Wir wollen alle gute Arbeit leisten. Aber den einen oder anderen Entwickler muss man manchmal bremsen, sonst vergoldet er bis zum Sanktnimmerleinstag.

Wenigstens der Auftraggeber ist daran interessiert, dass seine gestellte Aufgabe schnell erledigt wird? Weit gefehlt! Das ist er natürlich schon. Aber bei der Abnahme fällt dies und jenes auf. Das hätte er doch lieber anders, beim nächsten Abnahmezyklus fällt ihm noch eine Verbesserung ein und so dreht die Aufgabe ihre Kreise auf dem Board und wird nicht fertig.

Transparenz über das Board ist nur gegeben, wenn der Prozess und das Board vom Umfeld auch verstanden wurde. Der subjektive Eindruck, dass die Arbeit nicht vorangeht, entsteht immer noch. Das Board ist lediglich ein Abdruck der aktuellen Arbeitssituation. Wenn die geleistete Arbeit aus der letzten Spalte herausrutscht, weil sie produktiv ist, ist sie am Board nicht mehr zu sehen, jedoch über Auswertungsgrafiken (bspw. über ein kumulatives Flächendiagramm) ersichtlich. Diese hängen bei uns neben dem Board, müssen aber auch erst Beachtung finden.

Ich bin der Meinung, dass der Sprint einer der Gründe ist, warum Scrum für den Westen besser geeignet ist als Kanban. Abgabetermine sind für uns verbindlich und wir sind stets bemüht, diese einzuhalten. Ein Abgabetermin baut den nötigen Druck auf, die Arbeit schnell zu erledigen und falls nötig Abstriche zu machen. Beim Entwickler wie beim Auftraggeber. Für Support- und Wartungsarbeiten sind Sprints allerdings weniger geeignet. Bei einem Notfall kann nicht erst der nächste Sprint abgewartet werden.

Die Idee das Team zu entlasten und zu schützen, die hinter Kanban steht, ist auf jeden Fall schützenswert! Wenn wir Entwickler uns auf unsere Arbeit fokussieren können, arbeiten wir am besten. Ich wäre jedoch für eine westliche Variante von Kanban zu begeistern. Vielleicht finden wir die noch. Ganz im Sinne von Kanban: Der Prozess verbessert sich selbst durch diejenigen, die ihn leben!

Entwickler entwickeln sich

25. Februar 2013
Nathalie Kellenberger
0
Agile Softwaremethoden, Entwickler, Kommunikation, Scrum

Achtung, ich sage es gleich zu Beginn: Das hier ist kein technischer Post, heute widme ich mich dem Entwickler selbst. Denn es gilt dringend, mit einigen Klischees aufzuräumen! Entwickler, das sind die, mit denen keiner am Pausen- oder Mittagstisch sitzen will, weil die entweder gar nicht oder so seltsames technisches Zeug reden, das kein Aussenstehender versteht. Das mag immer noch so sein, wobei auch Nicht-Informatiker stundenlang über ihr Smartphone zu referieren vermögen.

Was sind gängige Klischees über Entwickler? Sie sitzen gern im dunklen, stillen Kämmerlein, arbeiten also vorzugsweise allein und kommunizieren lieber mit Maschinen als mit Menschen. Deswegen sind sie doch überhaupt Entwickler geworden, ist doch logisch.

Aber halt, so einfach verkriechen können sich Entwickler heute nicht mehr!

Bei der agilen Softwareentwicklung werden Entwickler gerade in der Kommunikation stark gefordert. Am besten lässt sich das über Scrum zeigen. Bei Scrum regiert der Teamgedanke. Kommunikation ist dabei das A und O:

  • Beim Daily erzählt jeder Entwickler etwas zu den drei Fragen:
    • Was habe ich gestern gemacht?
    • Was mache ich heute?
    • Was blockiert mich?
  • Beim Review präsentiert ein Entwickler die Arbeit des Teams.
  • Bei der Retrospektive diskutiert jeder Entwickler über den vergangenen Sprint und arbeitet aktiv an der Verbesserung des Prozesses mit.
  • Bei der Planung besprechen die Entwickler im Team, wie die kommenden Aufgaben zu lösen sind.
  • Bei der täglichen Arbeit tauschen sich alle Entwickler im Team über technische Details, den Fortschritt der Arbeit, Probleme, etc. aus.

 

Einzelkämpfer ade? Zumindest haben es Einzelkämpfer in Scrum eher schwer.

Das Gute ist, dass Entwickler hauptsächlich mit Entwicklern kommunizieren (und dem Product Owner) und sich allein dadurch schon verstehen. Dennoch gilt es in dieser agilen Zeit, die Kommunikationsfähigkeiten des einen oder anderen zu fördern.

Entsteht jetzt so auch bei Entwicklern Zickenkrieg?

Ja, das kann schon mal vorkommen. Wir Entwickler sind tatsächlich auch Menschen und keine Roboter.

Ich persönlich nehme die kommunikative Entwicklung dank agiler Softwaremethoden äusserst positiv wahr. Entwickler reden nämlich gern über ihr Fachgebiet und der Austausch der Entwickler dient auch dem Knowhow Transfer. In meinem persönlichen Umfeld bleiben Entwickler meist auf der fachlichen und faktischen Ebene und fühlen sich nicht gleich betroffen, wenn sie kritisiert werden.

Also danke agil, danke Scrum. Eine Quasselstrippe freut sich!

buy сialis online
1234

Tag Cloud

.NET android Angular AngularJs Arduino ASP.Net automated testing Azure Big Data C# C++ Cloud continuous integration Elm Embedded Führung gRPC Internet of Things IoT Java Javascript M2M OWASP Projektmanagement protobuf Python Raspberry Pi Reactive Programming REST Scrum Security Softwarequalität SPA Testen testing Testmanagement Teststrategie UX Visual Studio WebAPI windows WPF Xamarin Xamarin.Android Xamarin.Forms

Archive

Current Posts

  • Akzente setzen mit der Android Splash Screen API unter .NET MAUI
  • Do You have Your Personal Space?
  • Automated provisioning with ARM Templates
  • Asynchrone Beobachtungen und Versprechungen in Angular
  • Simplify Your Automated Tests With Fluent Syntax

Last Comments

  • Hans Reinsch bei Der Safety-Plan: Die wichtigsten Antworten mit Checkliste
  • George H. Barbehenn bei Modeling Optocouplers with Spice
  • Noser Blog Touch-Actions in Xamarin.Forms - Noser Blog bei Mach mehr aus Animationen in Xamarin.Forms mit SkiaSharp
  • Noser Blog Focus on the Secure Storage service of Trusted Firmware (TFM) - Noser Blog bei First run of the Trusted Firmware (TFM) application
  • Noser Blog First run of the Trusted Firmware (TFM) application - Noser Blog bei Focus on the Secure Storage service of Trusted Firmware (TFM)

Popular Posts

Xamarin.Android Code Obfuscation

6 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 1 - Aufbruch

5 Comments

ManuScripts: Wenn jemand eine Reise tut... Funktionale Programmierung mit Elm - Teil 2 - Kein Picknick

4 Comments

Contact us

  1. Name *
    * Please enter your name
  2. Email *
    * Please enter a valid email address
  3. Message *
    * Please enter message
© 2013 NOSER ENGINEERING AG. All rights reserved. Datenschutz | Cookie-Richtlinie