Flow im Unternehmen – Teil 2 – Qualität

Wenn die Softwareentwicklung besser werden soll, dann ist nicht jede Veränderung von gleichem Wert. Das liegt auf der Hand. Doch welche Veränderungen sind anderen vorzuziehen? Sollte ein weiterer Entwickler eingestellt werden? Oder besser auf TFS umstellen? Oder zur WCF-Schulung gehen?

Solche Fragen sollten nicht aus dem Bauch heraus entschieden werden. Es braucht vielmehr ein Rahmenwerk, in dem Sie Scrum, TFS, WCF, CCD als Werkzeuge einordnen können. Und dieses Rahmenwerk sollte mit Werten ausgestattet sein, für die Sie fragen können, ob eine Veränderung sie unterstützt oder behindert. Und darüber braucht es dann noch ein Ziel für das Ganze.

In meinem vorherigen Artikel habe ich angefangen, ein solches Rahmenwerk zu skizzieren. Es basiert auf der Theory of Constraints (TOC). Der grundsätzliche Gedanke dahinter: Sie können die Softwareentwicklung als einen Produktionsprozess ansehen, der aus irgendwelchem “Material” Software herstellt, für die am Ende Kunden Geld bezahlen.

Geld mit Software zu verdienen heute und (!) in der Zukunft, ist mithin das Ziel der Softwareentwicklung bzw. einer größeren Organisation um sie herum. Und nur, wenn eine Veränderung dazu führt, dass heute mehr Geld verdient oder das Geldverdienen in der Zukunft gesichert wird, dann ist sie für diese Organisation lohnend.

Also nochmal die Frage: Lohnt es sich, den WCF-Kurs zu machen? Bringt die Einführung von TFS etwas? Sollten alle Entwickler nach CCD-Prinzipien und Praktiken arbeiten?

Die Antwort gibt nie der Anbieter, sondern immer nur der Softwareproduktionsprozess. Dafür muss der natürlich bewusst sein.

Engpass intern oder extern?

Bisher habe ich nur die offensichtlichen Produktionsschritte einer Softwareentwicklung genannt:

Software wird geschrieben und dann verkauft. Das sieht nicht nach viel aus, doch auch die Formulierung dieses kleinen Prozesses bringt schon etwas. Denn mit der TOC auf ihn geblickt können wir fragen: Wo liegt der Engpass?

In jeder Sequenz von Prozessschritten gibt es einen Engpass, d.h. einen Schritt mit kleinster Kapazität.

Wieviele Einheiten kann ein Prozessschritt pro Zeiteinheit verarbeiten, aufnehmen, “verdauen”? Das ist seine Kapazität K. Gegenüber dem vorgeschalteten Schritt erscheint die Kapazität dann als Bedarf. Bedarf, weil Kapazität natürlich ausgeschöpft sein will.

Optimal ist die Lage, wenn die Kapazitäten aller Prozessschritte gleich sind und jeder Schritt einen Ausstoß A hat, der dem Bedarf des folgenden entspricht: Ai = Ki+1.

So ist es jedoch im Grunde nie. Die Kapazitäten von Prozessschritten sind erstens unterschiedlich und zweitens entspricht der Ausstoß nicht immer dem Bedarf. Wie im vorherigen Artikel erklärt, kann der Ausstoß des Gesamtprozesses dann höchstens so groß sein, wie der maximale Ausstoß des Engpasses, d.h. des Schrittes mit der kleinsten Kapazität in Bezug auf die zu produzierenden “Packerl”.

Überlegen Sie einmal, wo bei Ihnen im Unternehmen der Engpass ist. Bisher sind am Produktionsprozess nur 2 Produzenten und 2 Konsumenten beteiligt:

• Softwareentwicklung: Produzent
• Vertrieb: Produzent + Konsument (Prosument? ;-)
• Markt: Konsument

Welcher hat die geringste Kapazität?

• Kann der Vertrieb pro Zeiteinheit den Markt mit “Packerln” befriedigen? Oder dreht der Vertrieb Däumchen? Mein Gefühl ist, dass es kaum einen Vertrieb gibt, der sagt, der Markt wolle seine Software nicht. Wenn es eine Klage gibt, dann die, dass man nicht genug verkaufe, weil es der Software noch an etwas fehle. Es gibt also Bedarf, der nicht befriedigt werden kann. Das bedeutet, der Markt ist nicht der Engpass.
• Wie ist es aber mit dem Vertrieb selbst? Er könnte selbst der Engpass sein. Dann gäbe es Bedarf und die Software wäre dem auch angemessen, alle vom Markt nachgefragten Features sind enthalten. Dennoch sind die Verkäufe schleppend. Das kann leicht bei einem Startups der Fall sein: Da haben existiert schon eine von Enthusiasten geschriebene Software, es gibt einen Markt – nur ist die Software noch unbekannt.
• Bei etablierten Firmen scheint es jedoch am häufigsten, dass weder Markt, noch Vertrieb der Engpass sind – sondern die Softwareentwicklung. Der Markt hat Bedarf, der Vertrieb würde gern verkaufen, er sitzt auf einer Liste von Interessenten. Der Software fehlen aber immer wieder entscheidende Features, die Softwareentwicklung zu langsam für den Vertrieb produziert.
  Beispiel: Die Softwareentwicklung stellt alle 3 Monate ein neues Release her. Daraus kann der Vertrieb jeden Monat 10 “Packerl” schnüren und verkaufen. Wenn allerdings noch Feature A und B enthalten wären, dann könnten 12 “Packerl” geschnürt und verkauft werden. Das ist aber frühestens in weiteren 3 Monaten der Fall. Also ist die Softwareentwicklung der Engpass. Und das so lange, bis sie Release mit einer Frequenz ausstößt, dass es für den Vertrieb keinen Unterschied mehr macht. (Eine solche Softwareabteilung habe ich aber in 13 Jahren Beratungspraxis noch nicht gesehen.)

Sie sehen: Schon mit einem solch einfachen Diagramm lassen sich interessante Erkenntnisse gewinnen. Liegt der notwendig existierende Engpass in Ihrem Unternehmen oder außerhalb im Markt? Müssen Sie intern etwas tun, damit mehr Geld verdient wird – oder ist es Ihnen quasi aus der Hand genommen, weil die Gründe für schlechten Verdienst extern sind?

Hm… gibt es überhaupt einen externen Engpass? Kann der Markt der Engpass sein? Oder ist dann nicht auch intern etwas im Argen und man produziert die falsche Software? Ja, ich denke, so ist es wohl. So wie es kein schlechtes Wetter, sondern nur unangemessene Bekleidung gibt, so gibt es auch keinen Engpass im Markt, sondern nur Produkte, die am Bedarf vorbeigehen.

Aber darauf will ich an dieser Stelle nicht näher eingehen. Als Softwareentwickler vertrauen wir mal darauf, dass unsere Auftraggeber wissen, warum sie wollen, was sie wollen, und dass das auch bedarfsgerecht ist.

Der Gedanke, dass es eigentlich keinen externen Engpass gibt, ist jedoch insofern nützlich, als dass er die Unterscheidung zweier Arten von Engpässen motiviert. Denn offensichtlich können Grundsatzentscheidungen (“Wir produzieren eine Software mit diesen und jenen Features.” (die den Markt leider nicht interessieren) oder “Wir hauen lieber schnell neue Releases raus, als dass wir auf Evolvierbarkeit achten.”) Einfluss auf den “Pakerl”-Absatz haben – die dann als Engpass im Markt wahrgenommen werden.

In der Literatur gibt es daher nicht nur den Begriff Produktionsengpass (production constraint), sondern auch Grundsatzengpass (policy constraint). Bei ersterem geht es um die Ressource mit ihrer Kapazität, bei letzterem um die Steuerung der Ressource. Wenn eine Ressource eigentlich mehr könnte, aber durch einen Grundsatz behindert wird, die Kapazität auszuschöpfen, dann liegt ein Grundsatzengpass vor.

Prozessverfeinerung

Wenn schon eine einfache Vorstellung einem Softwareproduktionsprozess hilft, dann hilft eine differenziertere bestimmt noch mehr. Wie könnte also eine Verfeinerung des bisherigen Bildes aussehen, ohne an Allgemeingültigkeit zu verlieren? Ich denke, die Softwareentwicklung sollte nicht mehr so autonom produzieren; denn woher bekommt sie bisher den Anstoß für die Herstellung ihrer Releases?

Ich denke, es geht los bei einer Marktanalyse. Irgendwer sammelt am Markt die unerfüllten Wünsche der Zielgruppe. Die werden gesichtet, gefiltert, verdichtet und zu Vorschlägen für Features gebündelt. Typische Marktanalysten sind Vertriebler, Supporter oder auch der Geschäftsführer.

Mir geht es nicht darum, wer konkret als Person nin einem Unternehmen die und anderes tut. Ich spreche hier über Produktionsschritte oder Rollen. Irgendwer muss halt den Markt analysieren oder die Software entwickeln. Ob das verschiedene Personen oder dieselben tun, ist zunächst einmal egal.

Diese Vorschläge sind für die Softwareentwicklung meist zu schwammig. Deshalb nimmt sich ihrer eine Anforderungsdefinition an, die sie filtert, formalisiert und priorisiert. Scrum weist diese Aufgabe dem ProductOwner zu. Oft spielen Vertrieb oder Marketing oder Geschäftsführung auch diese Rolle.

Die Softwareentwicklung transformiert die Anforderungen dann in Releases, die der Vertrieb an den Markt bringt. Der Markt steht mithin am Anfang und am Ende der Softwareproduktion. Er äußert Wünsche, die das Softwareunternehmen mit “Packerln” befriedigt. Nur wenn der “Packerl”-Inhalt den Wünschen entspricht, ist auf Verkauf zu rechnen.

Hört sich das plausibel an? Ich hoffe. Diese Prozessschritte scheinen mir minimal und konsensfähig. Auch wenn sie in einem Unternehmen nicht explizit besetzt sein sollten, gibt es sie doch immer in mehr oder weniger sichtbarer Form. Und nur das ist hier wichtig. Selbst in einem 1-Personen-Unternehmen, wo alles von einem getan wird, geht es nicht ohne. Da mögen Marktanalyse und Anforderungsdefinition zusammenfalle – stattfinden tun jedoch beide.

Und wo ist die Geschäftsführung, das Management? Was ist mit der Buchhaltung? Mir geht es nur um den Softwareproduktionsprozess. Die Buchhaltung ist dafür irrelevant; sie spielt eine parasitäre Rolle im Unternehmen, da in ihr keine Wertschöpfung erfolgt. Sie hat höchstens eine Relevanz durch ihren Einfluss auf das Management. Denn das hat qua Grundsatzentscheidungen Einfluss auf alle Rollen; das ist schließlich ihr tradioneller Job. Im Diagramm würde ich das durch eine Abhängigkeitsbeziehung kennzeichnen:

Wo Abhängigkeiten existieren, da droht natürlich die Gefahr von Grundsatzengpässen. Sie können wie Einschnürungen auf den abhängigen Produktionsschritt wirken. Organigramme, die darstellen, wer wem welche Ansagen machen kann, haben also ihren Wert. Sie können helfen, Grundsatzengpässe aufzudecken.

Wie sieht es nun mit den Engpässen im verfeinerten Diagramm aus?

• Jetzt ist klarer, warum die Softwareentwicklung ein Engpass sein kann: Sie setzt Anforderungen, die in die hineinfließen einfach nicht schnell genug in Releases um, die der Vertrieb dann absetzen kann. Kommt Ihnen das bekannt vor? Symptom ist ein langes Backlog, für dessen Einträge nicht klar ist, ob und wann sie jemals umgesetzt werden – obwohl sie ja verdichtete und formalisierte Wünsche des Marktes darstellen, d.h. greifbares Potenzial für Umsatz.
• Dass die Anforderungsdefinition ein Engpass ist, habe ich noch nicht gesehen. Ich kenne nur Softwareunternehmungen, die schnelle Anforderungen produzieren, als die Softwareentwicklung in Code transformieren kann.
• Dasselbe gilt für die Marktanalyse; auch hier habe ich noch kein Projekt gesehen, dass darunter gelitten hätte, dass der Markt nicht mehr Wünsche pro Zeiteinheit gehabt hätte, als umgesetzt werden konnten.

Marktanalyse und Anforderungsdefinition scheinen also kein Problem zu sein. Die Softwareentwicklung ist und bleibt der Engpass. Als hätten Sie das nicht irgendwie schon vorher gewusst ;-)

Dennoch finde ich es wichtig, diese beiden Schritte eingeführt zu haben. Denn wie Sie dem vorherigen Artikel entnehmen können, kann ein System nur optimal funktionieren, wenn man die Optimierung auf dem Ganzen ausführt und nicht nur auf Teilen. Grundsatz #3 ist zu beachten: Downstream Bedarf bestimmt upstream Produktion in allen Teilen eines Prozesses.

Die Softwareentwicklung folgt Anforderungsdefinition und Marktanalyse, liegt also downstream. Das heißt, sie hat nach Grundsatz #3 Einfluss auf beide. Nur wie?

Ausbeutung mit Qualität

Bevor der Einfluss der Softwareentwicklung auf vorgelagerte Prozessschritte klar wird und der Produktionsprozess noch weiter verfeinert werden kann, wieder ein Ausflug ins Grundsätzliche der Theory of Constraints.

Am Ende meines vorherigen Artikels habe ich die Schritte zur Optimierung eines Systems auf sein Ziel hin genannt:

1. Engpass identifizieren
2. Engpass ausreizen (Grundsatz #5)
3. Nicht-Engpass Prozessschritte am Engpass ausrichten (Grundsatz #3)
4. Enpass erweitern (Grundsatz #5)
5. Zurück zu 1.

Schritt 3 ist darin sozusagen der sichtbar “systemische” Schritt. Er widerspricht dem landläufigen Gedanken lokaler Optimierung. Denn hier kann es zum Abbau lokaler Optima führen, um ein Gesamtoptimum zu erzielen. Prozesschritte dürfen sich also nicht autistisch in sich kehren, sondern sollen das Ganze im Blick behalten – insbesondere ihr Verhältnis zum Engpass.

Vorher geht es jedoch darum, den Engpass bestmöglich auszunutzen. Das bedeutet, dass man ihn auf das fokussiert, was er leisten soll im Sinne des Ziels. Alles, womit sich der Engpass beschäftigen muss, das nicht der Produktion hochwertigen Ausstoßes dient, ist zu vermeiden. Engpässe sollten also von jeder Ablenkung freigehalten werden.

Eine häufige und ganz allgemeine Ablenkung ist nun Wiederbearbeitung (rework). Wenn ein Engpass schlechte Qualität ausstößt, kommt die irgendwann zu ihm zurück. Der Engpass muss seinen früheren Ausstoß dann nachbearbeiten. Das kostet Zeit, die ihm für die Produktion neuen Ausstoßes fehlt.

Ob mangelnde Qualität der Engpass-Ausstoßes direkt zu ihm zurückkommt oder dazu führt, dass vorgelagerte Prozessschritte auch kompensieren müssen, ist egal. Am Ende muss insbesondere der Engpass Zeit aufwenden für etwas eigentlich Erledigtes, statt etwas Neues zu produzieren.

Sie kennen das sicher: Sie haben viel zu tun, takten Ihre Aufgaben eng, um rechtzeitig mit allem fertig zu werden – Sie haben keine Zeit zu verschwenden! – und dann bekommen Sie das Feedback, dass Sie das Dokument, das Sie gestern abgegeben haben, nochmal überarbeiten müssen, weil es Qualitätsmängel enthält. Das passt Ihnen natürlich gar nicht in den Kram, weil sie keinen Spielraum haben; Sie können es sich nicht erlauben, etwas, das schon fertig war, nochmal anzufassen. Genauso ist es mit dem Engpass in einem Prozess. Der hat keinen Spielraum, der muss an der Kapazitätsgrenze performen, weil er alle anderen ja schon aufhält. Der kann sich also nicht erlauben, einen Fehler zu machen, um dadurch selbstverschuldet früher oder später nachbessern zu müssen. Nachbesserungen verdienen einfach kein Geld.

Selbst wenn der Engpass jedoch an sich fehlerfrei Input in Output transformiert, kann er mit Nachbesserungen belastet werden. Es gilt ja: Garbage in, garbage out. Wenn also der Input in den Engpass schon mangelhaft ist, kann der Engpass es nicht besser machen. Wenn die Qualität des Ausstoßes des vorgeschalteten Prozessschrittes suboptimal ist, dann wird der Engpass sogar womöglich doppelt unnütz belastet. Er befasst sich mit dem mangelhaften Input, bemerkt das aber nicht selbst, sondern transformiert ihn nach bestem Wissen und Gewissen – und dann verweigert ein nachgeschalteter Schritt die Weiterverarbeitung. Das führt dann zu einem erneuten Anlauf bei einem vorgeschalteten Schritt, so dass der Engpass erneut mit der Sache befasst ist.

Es ist also darauf zu achten, dass der Engpass nur mit Topqualität beliefert wird und selbst nur Topqualität ausstößt. Alles andere führt zu Wiederbearbeitungen, die den Engpass vom Wesentlichen ablenken.

Wenn Nicht-Engpass Prozessschritte mit solchem “Wiederkäuen” belastet werden, mag das nicht so schlimm sein. Sie haben wegen des Engpasses wahrscheinlich Überkapazitäten und können sich (gelegentliche) Nachbesserungen leisten. Der Engpass hat diesen Luxus nicht.

Und schließlich kann der Engpass zu Wiederbearbeitungen gezwungen werden, wenn seine Topqualität von downstream Prozessschritten zerstört wird. Als Pizzabäcker mögen Sie perfekt sein – wenn dann aber der Kellner die Pizza fallen lässt, war Ihre Arbeit umsonst. Sie müssen die Pizza nochmal backen, was andere Gäste auf Ihre Bestellungen ungeplant warten lässt.

Es ist also darauf zu achten, dass der Engpass nur mit Topqualität beliefert wird, selbst nur Topqualität ausstößt und downstream diese Topqualität nicht verlorengeht, so dass Nachbesserungen durch den Engpass fließen.

Den Engpass ausreizen bedeutet natürlich, dass er selbst wie geschmiert funktioniert. Darüber hinaus zwingt ein Engpass aber auch zum Blick auf Qualität. Sobald mangelnde Qualität upstream, downstream oder durch ihn selbst produziert zu Nachbesserungen führt, die durch den Engpass laufen, ist das im Widerspruch zur Forderung von Schritt 2 der Systemoptimierung.

Qualität ist kein Selbstzweck. Irgendwie haben Entscheider also doch Recht, wenn sie Entwickler skeptisch beäugen, die mit einem absoluten Qualitätsbewusstsein an der Entwicklung “rumschrauben” wollen.

Mit der Theory of Constraints bekommen Entscheider wie Entwickler allerdings ein Denkmodell an die Hand, das sie beurteilen lässt, wo qualitätssteigernde Maßnahmen Sinn ergeben. Eine simple Frage reicht aus: “Führt die Qualitätssteigerung zu einer Entlastung des Engpasses?” oder “Kann der Engpass sich anschließend mehr auf die Produktion von Neuem konzentrieren?”

Wenn diese Frage mit Ja beantwortet werden kann, dann sollte die Maßnahme ernsthaft in Betracht gezogen werden.

Umgekehrt kann natürlich auch nach lohnenden Veränderungsansatzpunkten gesucht werden. Ist ein Engpass bekannt, dann kann man fragen, wie die Qualität seines Ausstoßes erhöht werden kann, wie der Ausstoß des vorgelagerten Schrittes verbessert werden kann oder wie nachgelagerte Schritte die Qualität halten können.

Die Systemoptimierung fragt also zuerst nach dem Engpass, dann danach, wie der überhaupt zu voller Kapazität gebracht werden kann – und anschließend kommt die Qualität in den Blick. Im Kern der TOC schlägt ein Herz für hohe Qualität – weil Qualität sich im wahrsten Sinne des Wortes auszahlt. Und damit ist das hohe Qualitätsempfinden der meisten Entwickler an den Sinn fürs Geld ihrer Entscheider angebunden. Entwickeridealismus und Entscheiderpragmatismus stehen nicht so im Widerspruch, wie es oberflächlich den Anschein hat. Mit einem passenden und gemeinsamen Referenzsystem kommen Geld und Qualität überein.

Qualität im Softwareproduktionsprozess

Nach diesem Ausflug in die TOC-Grundlagen stellt sich natürlich umso mehr die Frage, wo Qualität im Softwareproduktionsprozess eine Rolle spielt. Bisher ist sie noch nicht explizit sichtbar. Ich schlage vor, zwei weitere Produktionsschritte ins Bild einzuführen, die mit Qualität zu tun haben:

Da ist zum einen der Support. Der befasst sich mit schlechter Qualität. Die Kundschaft meldet sich beim Support mit Problemen, die vom Support entweder selbst aufgeklärt werden können – oder als Issues weitergeleitet werden an die Softwareentwicklung. Solche Issues sind Abweichungen von der Anwendererwartung jeder Art, Bugs natürlich eingeschlossen.

Dadurch steht die Softwareentwicklung von zwei Seiten unter Produktionsdruck. Die Anforderungsdefinition schiebt ihr zu, was umgesetzt werden muss, um am Markt “Packerl” abzusetzen. Und der Support schiebt ihr Nachbesserungen zu. Der Support im Bild ist somit ein deutlich sichtbarer Ausdruck dessen, dass die Softwareentwicklung ganz verlässlich immer wieder Engpass ist. Solange Support nötig ist, der mit der Softwareentwicklung verbunden ist, stimmt also mit der Qualität der “Packerl” irgendetwas nicht.

Der Support ist in vielen Unternehmen wie eine Notbremse, die die Entwicklung jederzeit anhalten kann, um ein kundenlebenswichtiges Problem zu lösen. Das behindert die Softwareentwicklung dann doppelt, weil sie nicht nur eine Nachbesserung vornehmen muss, sondern auch aus ihrem Arbeitsfluss gerissen wird. Ein ruhiger, konzentrierter Arbeitsfluss ist aber wichtig, wenn die Softwareentwicklung als hochkreative Tätigkeit ihre Kapazität ausreizen können soll.

Support-Issues kommen aber natürlich nicht von ungefähr. Sie sind nur das Symptom für Qualitätsmängel in der Produktion von “Packerln”. Deshalb ist eine explizite Qualitätssicherung gerade im Engpass als Gegenmaßnahme selbstverständlich. Sie entspricht der Erkenntnis der TOC, dass der Engpass von sich aus höchste Qualität liefern sollte, um Nachbesserungen zu vermeiden.

Damit aber nicht genug! Qualität spielt lt. TOC auch noch an anderen Stellen eine Rolle. Auf hoher Abstraktionsebene ist die Softwareentwicklung der Engpass, d.h. Input und Output müssen hohe Qualität haben. Bei näherer Betrachtung ist dann jedoch die Programmierung innerhalb der Softwareentwicklung der wahre Engpass. Auch dort muss also schon die explizit Qualität in den Blick genommen werden.

Die Qualitätshebelpunkte im Einzelnen:

• Anforderungsdefinition: Können Anforderungen überhaupt von mangelhafter Qualität sein? Natürlich. Denn “mangelhafte Qualität” bedeutet, dass am Engpass Nachbesserungen nötig sind bzw. es kein Geld einbringt, sie umzusetzen. Der Engpass hat dann weniger Zeit für neue, lukrative Anforderunge. Mangelhafte Anforderungen sind mithin solche…
  • …die unnötig sind (Stichwort YAGNI). Vorschläge sind nicht einfach in Anforderungen zu transformieren, sondern auf ihre Relevanz zu prüfen. Die Anforderungsdefinition muss ein Gespür dafür haben, was wichtig, was nötig, was nice-to-have ist. Priorisierung ist das Zauberwort. Und auch ablehnen darf die Anforderungsdefinition. Nicht jeder Räusper des Marktes muss umgesetzt werden.
  • …die unklar sind. Anforderungen müssen in Form und Granularität so formuliert sein, dass bei der Softwareentwicklung möglichst wenige Zweifel existieren, was gemeint ist. Anforderungen sollten schon gar nicht Formulierungen wie “irgendwie” oder “Das sollen die Entwickler entscheiden, die haben doch Erfahrung” enthalten.
    Markstein für Klarheit sind in jedem Fall Akzeptanzkriterien, d.h. Paare von Eingaben mit erwartetem Verhalten. Ohne eine Liste solcher Paare sollte die Softwareentwicklung nicht mit der Implementierung beginnen. Sie kann dann nämlich nicht für sich feststellen, ob die Qualität ihrer Arbeit hoch ist. Das aber ist die Voraussetzung dafür, als Prozessschritt mit anderen zusammenzuarbeiten. Qualität ist ja nicht subjektiv von jedem Prozessschritt selbst zu bestimmen, sondern hat auch etwas mit den Folgeschritten zu tun.
• Support: Was vom Support kommt, ist immer eine Störung für die Softwareentwicklung. Deshalb sollte der Support besonders sensibel sein, Issues mit geringer Frequenz und hoher Qualität zu produzieren. Mangelhaft sind Issues, wenn…
  • …sie unklar sind und der Entwickler nicht genau weiß, was zu tun ist. Wie kann er das Problem reproduzieren? Wer hat es gemeldet (für Nachfragen)? Alles was die Bearbeitung eines Issue verlängert, ist zu vermeiden.
  • …im Grunde vom Support selbst geklärt werden könnten. Das sollte für alle Issues gelten, die keine Bugs sind. Was ein Anwender für einen Fehler hält, mag nur eine falsch verstandene Anforderung sein. Deshalb sollte der Support auch eigentlich gar nicht mit dem Engpass Softwareentwicklung direkt verbunden sein. Das obige Bild stellt also nur die häufige de facto Prozesskette dar, nicht eine wünschenswerte. Wünschenswert ist vielmehr, dass die Softwareentwicklung von der Außenwelt abgeschirmt ist. Nur dann kann ein ruhiger Fluss zur maximalen Ausnutzung des Engpasses entstehen. Hier der angepasste Produktionsfluss:

Die Verbindung des Support mit der Anforderungsdefinition macht nicht nur zur Entkopplung der Entwicklung Sinn, sondern passt auch dazu, dass über den Support immer wieder (potenzielle) Verbesserungsvorschläge hereinkommen. Die landen nach der obigen Prozessstruktur nun ebenfalls bei der Anforderungsdefinition, also da, wo sie hingehören.

• Programmierung: Die Programmierung ist die zentrale Transformationsstelle. Sie ist das Herz des Unternehmens. Hier werden Anforderungen in Code gegossen; hier entstehen Softwarelösungen. Und leider ist die Programmierung auch der ewige Engpass. Das hat unabhängig von suboptimaler Anforderungsqualität mit vielen Faktoren zu tun, z.B. Komplexität der Materie Softwareentwicklung an sich, heterogene Ausbildung, mangelnde Plattformkenntnis, suboptimale Teamkommunikation oder schließlich auch Grundsatzengpässe aller Art.
  Den Engpass Programmierung maximal produktiv zu halten, ist also oberstes Gebot eines Softwareunternehmens. Alles andere ist Geldverschwendung. Das bedeutet aber auch, dass Produktivität unter Verzicht auf Qualität immer ein Phyrrussieg ist. Immer. Schlechte Qualität kommt immer zurück in Form von Nachbesserungen und verstopft den Engpass Programmierung. Das gilt für Bugs wie für fehlende Usability. Die Programmierung muss deshalb sehr sensibel sein für die Qualität ihrer eigenen Arbeit. Weniger als top Qualität (nach bestem Wissen und Gewissen der Programmierer) ist also zuwenig.
  • Automatisierte Tests (insb. zur Vermeidung von Regressionsfehlern) sind also ein Muss für den Engpass Programmierung. Nur so kann die Kapazität mittel- bis langfristig für Neues eingesetzt werden, statt für Nachbesserungen.
  • Reviews am Ende der Programmierung sind ebenfalls ein unverzichtbares Mittel, um vor Übergabe des Codes nochmal die Qualität zu checken. Alles was die Programmierung verlässt und später wiederkommt bereitet ungeplanten Mehraufwand, der von der eigentlichen Arbeit ablenkt.
  • Ähnlich verhält es sich mit der Usability. Wird auf die kein Wert gelegt, fällt Zusatzaufwand für die Anwenderdokumentation an und Issues vom Support tauchen früher oder später als Sand im Getriebe auf.
  • Sensibilität ist aber auch gegenüber den Anforderungen angebracht. Was klar ist, sollte pünktlich erfüllt werden. Was unklar ist, sollte vor Arbeitsaufnahme geklärt oder abgelehnt werden. Hier ist das größte Risiko, dass die Programmierung sich überschätzt. “Das kriegen wie schon irgendwie hin…” oder “Unsere Erfahrung sagt, dass der Kunde es bestimmt so und so haben will…” sind Symptome dafür.
• Qualitätssicherung: Hohe Qualität als Output der Softwareentwicklung ist so wichtig, dass der Programmierung ihre Prüfung nicht allein überlassen werden kann. Grundsatzengpässe, die auf die Programmierung wirken und simple psychologische Mechanismen machen es wahrscheinlich, dass selbst sorgfältig testenden Programmierern Qualitätsmängel durch die Lappen gehen. Also ist eine explizite nachgeschaltete Qualitätssicherung wichtig, die ausdrücklich die Kunden-/Anwenderbrille auf hat. Spätestens hier sind die Akzeptanzkriterien aus den Anforderungen zu überprüfen. Sie macht aus dem, was die Programmierung für ein Release hält (Release Candidate) wirklich ein Release, das der Vertrieb zu einem “Packerl” schnüren kann.

Zwischenfazit

Die Grundstuktur eines Softwareproduktionsprozesses ist nicht kompliziert. Dennoch ist sie wertvoll im Verein mit der Theory of Constraints. Denn selbst an der simplen Struktur lässt sich schon ablesen, wo Investitionen lohnen und wichtig sind.

Testautomatisierung ist keine spinnerte Idee, sondern eine Maßnahme, um den Engpass Programmierung auszureizen. Dasselbe gilt für Versionskontrolle, automatisierten Buildprozess und andere Bausteine von Clean Code Developer. Sie alle zielen darauf ab, Programmierer zu entlasten, um den Kopf frei für das Wesentliche zu bekommen.

Ob ein Release von Hand oder mit einem Werkzeug hergestellt wird, interessiert den Kunden nicht. Da hat der Entscheider recht. Unrecht hat er aber, wenn er meint, deshalb sollte auf solch neumodischen Kram verzichtet werden. Denn was den Kunden interessiert, das ist die Zeit, die der Engpass Programmierung in die Herstellung neuer (!) Features steckt. Und die sinkt, wann immer Nachbesserungen oder manuelle Tätigkeiten nötig sind.

Insofern liegt der Wert in automatisierten Tests (Unit Tests, Integrationstests) nicht darin, dass sie bei der Erstentwicklung eines Feature laufen. Bei der Erstentwicklung sind manuelle Tests womöglich schneller. Automatisierte Tests entfalten Ihren Wert vor allem als Regressionstests. Sie werden nämlich immer vor Release ausgeführt. Das ist mit manuellen Tests nicht möglich. Automatisierte Tests sind ewige Sicherungsseile für die Qualität. Die beschränkt sich mit ihnen nicht darauf, was für ein Release an manuellen Tests möglich ist – denn das wird im Verhältnis zur Gesamtfunktionalität immer weniger –, sondern deckt die Gesamtfunktionalität ab. Ob ein Programmierer nun überblickt, das er durch eine Veränderung “alte” Funktionalität nicht beeinflusst hat oder nicht, ist mit automatisierten Regressionstests unerheblich. Das ist ultimativ entlastend für die Programmierung.

Eine Begründung von CCD durch die Theory of Constraints? Das ist ein schönes Zwischenergebnis, finde ich.

Beim nächsten Mal geht es weiter mit einer Detaillierung der Programmierung.