Das Meetings nicht unnötig sind, ist den meisten Teamplayern bewusst, der Austausch an Informationen ist wichtig für den Projekterfolg, auch die gemeinsamen Diskussionen beeinflussen die Qualität der Produkte, die es zu erstellen gibt. Trotzdem werden schätzungsweise 50 Prozent aller Gruppentermine als nicht erfolgreich wahrgenommen. Da zu einem erfolgreichen Projekt auch erfolgreiche und nicht weitverbrennende Termine gehören, gilt es zu analysieren, warum das teure Beisammensein häufig erfolglos scheint. Im Normalfall sind es immer wieder die gleichen Probleme die auftreten:

• Durcheinanderreden und Monologe der Teilnehmer – Viele dominante Kollegen nutzen solche Augenblicke, um sich zur Schau zu stellen und all ihr Wissen in minutenlangen Monologen wiederzugeben. Zusätzlich passiert es bei hitzigen Debatten, dass alle Teilnehmer gleichzeitig reden wollen. Ist die Stimmung eines solchen Termins erst mal vergiftet, ist es schwer wieder auf eine sachliche Ebene zu gelangen.
• Abschweifen vom eigentlichen Thema – Häufig passiert es, dass die Teilnehmer weit vom eigentlichen Thema abkommen, da kommt von vom eigentlichen Fokus schnell zu Problem B und von dort zu Problem C. Diese Punkte sind sicherlich auch für den Projekterfolg wichtig, trotzdem helfen sie einem nicht beim eigentlichen Grund des Meetings.
• Überziehen der Termine – Eine Stunde rum, diverse hitzige Diskussionen hinter sich gebracht, aber ein Konsens wurde nicht gefunden. So oder so ähnlich enden viele schlecht laufende Besprechungen. Durch die harten Anschläge weiterer Termine bleibt in einem solchen Fall auch keine Zeit mehr noch schnell ein Ergebnis zu formulieren und wenn es dann doch gelingt, wurde es übers Knie gebrochen und wird sicherlich nach kurzer Zeit wieder auf dem Tisch landen.
• Unsicherheit beim Ergebnis – Termin abgeschlossen. Die Teilnehmer gehen mit einem guten Gefühl raus, im Nachgang wird aber klar, dass gar nicht alle Teilnehmer das Ergebnis des Termins identisch in Erinnerung haben. Nach einer Woche werden es immer mehr, die sicher sind, dass genau das Ergebnis in ihrem Köpfen das richtige war und man sich wundert, dass andere nicht genau das gleiche denken.

Meetings werden häufig als nervend wahrgenommen und der Grund dahinter nicht analysiert. Häufig sind es aber genau die vier aufgeführten Punkte, die einen eigentlich nützlichen Termin als Strapaze enden lassen. Dabei hilft die Erstellung und die Einhaltung einfacher Meetingregeln bereits das gröbste aus der Welt zu schaffen.

• Es existiert eine Agenda - In der Einladung der Besprechung wird bereits genau beschrieben, wie der Termin ablaufen soll. Dieser Ablaufplan wird am Anfang einmal durchgesprochen, damit alle Teilnehmer wissen, was sie erwartet. Das Abschweifen wird somit bereits unterbunden, da eine klare Struktur des Themas behilflich ist sich selbst klarer zu strukturieren.
  Zusätzlich können sich Teilnehmer auf Grund der Agenda gezielt vorbereiten. Bemerkungen werden wertvoller und die eingebrachten Informationen hochwertiger. Oft sind Lösungen, die auch den gemeinsamen Tenor treffen, im Vorfeld in den Köpfen ausgearbeitet – vielleicht auch unterbewusst – und müssen nur erläutert werden. Gur vorbereitete Termine finden häufig schneller zu einem Konsens als spontane Treffen.
• Ein Moderator wurde bestimmt – Die Kunst der Moderation ist sicherlich keine einfache. Die Ernennung eines Moderators erhöht die Struktur aber auf mehreren Ebenen. Zum einen versucht ein guter Moderator fachlich neutral zu agieren, was bedeutet, er kann unterschiedliche Meinungen an einen Tisch bringen und bei der Konsensfindung behilflich sein. Zusätzlich hat er die Aufgabe den Prozess zu verteidigen.
• Nähert sich der Termin dem Ende, so muss den Teilnehmern frühzeitig dies mitgeteilt werden, so dass sich auf ein Ergebnis oder weiteres Vorgehen geeinigt werden kann.
• Unnötig lange Monologe können, mit Verweis auf die zur Verfügung stehenden Zeit, abgebrochen werden.
• Abschweifende Kommentare und Nebendiskussionen müssen unterbunden werden. Je früher hier gestoppt wird, desto einfacher ist der Weg zurück zum Hauptthema.
  • Bestimmung der Ziele – Damit der Erfolg eines Termins eintreten kann, muss klar definiert werden, was eigentlich das Ziel ist. Dieses Ziel gilt es bereits in der Einladung neben der Agenda festzuhalten. Das Ziel ist zusätzlich ein wichtiges Werkzeug des Moderators. Nur so kann bestimmt werden, ob Monologe, Abschweifungen oder sonstige vermeintliche Störungen zielführend sind.
  • Ergebnisprotokoll – Nach Durchführung des Termins müssen die Ergebnisse schriftlich festgehalten werden. Damit dies nicht zur Qual wird – wir wissen wie Informatiker auf die Erstellung von Protokollen reagieren – gilt es das Protokoll bei einem Standardtermin möglichst kurz zu halten. Ein guter Moderator lässt noch im Termin die Teilnehmer selbst die Ergebnissätze formulieren und beharrt darauf, dass kurz und prägnant sind. Wenn man ein Ergebnis nicht auf den Punkt bringen kann, dann ist es noch zu schwammig und muss noch einmal in die Runde gehen.

Wie bei allen Regeln sollte mit einer kleinen Anzahl begonnen werden. Reichen sie, dann sollte man mit dem gleichen Verfahren durch alle Termine kommen. Reichen sie nicht, gilt es wieder in die Analysephase zu gehen und Punkte zu entfernen oder hinzuzunehmen.

Standards scheinen auch in der Softwareentwicklung ein gerne angenommenes Geschenk zu sein, doch leider gibt es immer wieder den Trend zu sagen, dass Standards toll sind, sie aber leider nicht auf die aktuelle Situation passen. Dies ist ein wiederkehrendes Muster bei Bibliotheken [Die Bibliothek], aber noch häufiger sträuben sich Softwareprofis, wenn es um Prozesse geht.

In traditionellen Unternehmen sind es nicht die Entwickler, die die Prozesse machen, sondern das Management oder die Projektverantwortlichen. Wenn die Personen an der organisatorischen Spitze gut und erfahren sind, ist dies auch von Vorteil, da sie sich stärker mit der Materie befasst haben. Leider besteht häufig eine anscheinend natürliche Spannung zwischen Projektmanagement und Softwareentwicklung.

Programmierer neigen dazu Prozessfragen erst einmal sehr kritisch zu sehen. Jede Vorgabe, die einen daran hindert genau so zu arbeiten, wie es für einen als Individuum am besten ist, wird primär als Behinderung wahrgenommen.  Jeder Mensch ist einzigartig, warum sollte es eine funktionierende Methode geben alle möglichst produktiv zu steuern. In dieser Aussage stecken gleich zwei „Fehler“. Sind wir wirklich so unterschiedlich? Als Person betrachtet mag dies natürlich stimmen, wenn man aber die Person in ein Unternehmensumfeld steckt, so achtet man darauf, dass ein Team homogen zusammengestellt wird. Man ähnelt seinen Kollegen mit der Zeit immer mehr – so wie es bei Ehepaaren auch zu beobachten ist. Auch ein Teamleiter ist gut damit beraten sein Team so zusammenzustellen, dass ein ähnliches Gedankengut vorhanden ist. Die zweite falsche Annahme ist, dass es wichtig ist, dass man als einzelner maximal Produktiv sein muss. Natürlich arbeitet man gerne so optimiert wie möglich, das steht außer Frage. Einem Projektverantwortlichen ist es nicht wichtig, dass ein bestimmter  Mitarbeiter produktiv ist, sondern das Team muss maximale Leistung bringen. Wenn dies bedeutet, dass einer der Kollegen nicht sein ganzes Potential ausschöpfen kann, dann muss man damit umgehen können. Einfach ist dieses Umdenken sicher nicht, denn man muss sein egozentrisches Weltbild liegen lassen und das Gesamte sehen. Hat man dies geschafft, kann es einfacher sein, das Projektmanagement und seine Methoden zu verstehen.

Ein Paradebeispiel und gerade derzeit sehr aktuell ist die Einführung von agilen Prozessen, wie zum Beispiel Scrum. Obwohl es eine enorme Erleichterung für den Softwareentwickler bedeutet, ist er häufig sehr kritisch dem gegenübergestellt. Zu viele Unbekannte gilt es zu verstehen. Gewiss sollte man in einer solchen Situation nicht beginnen die neue Methodik zu bekämpfen. Den Gedanken, dass das eigene Projekt so individuell und das Team so besonders ist, dass dieses Vorgehen bei anderen klappen kann, aber leider bei einem selbst nicht, sollte man fürs erste unterdrücken.

Standards entstehen nicht einfach. Die meisten wurden von Experten erstellt, die sich mit der Thematik auskennen und die jahrelange Erfahrungen haben. Standards befinden sich bei anderen auch im täglichen Einsatz und dort funktionieren sie. Wenn man die Personen anspricht, die vor der Einführung kritisch waren, so werden die meisten sicher zurückrudern und sich eingestehen, dass es vielleicht doch eine gute Idee war.

Wichtig bei der Einführung neuer Standards ist, dass die Betroffenen offen mit dem Thema umgehen. Bedenken dürfen ausgesprochen werden, dürfen einen aber nicht dabei behindern es auszuprobieren. Wenn nur genügend Leute versuchen unterbewusst ein System zu sabotieren, dann werden sie es auch schaffen – egal wie gut das System ist. Klar ist auch, dass der Aspekt des Ausprobierens ein wichtiger ist.

Wir leben in einer agilen Welt. Entscheidungen, die getroffen wurden können revidiert werden. Wenn nach ein paar Wochen klar ist, dass der Standard wirklich nicht zu einem passt, dann hat man kaum etwas verloren. In den meisten Fällen wird man aber überrascht sein, dass es sich bei einem doch gut in das Gesamtsystem einbetten lässt.

„Leute, die sagen es kann nicht klappen, sollen denen nicht im Wege stehen, die es gerade machen.“

Mögliche Beweise kann man viele finden. So wurde zur Unterlegung der Theorie ein vollkommen intakter Jaguar in die südliche Bronx gestellt. Vier Tage vergingen und das Auto konnte ohne Kratzer wieder abgeholt werden. Keiner kam auf die Idee den Wagen anzufassen oder schlimmeres damit zu machen. Das gleiche Experiment wurde kurz darauf wieder mit diesem Jaguar ausgeführt. Die einzige kleine Schraube an der gedreht wurde, war das Einschlagen eines der kleinen Fenster. Innerhalb von vier Stunden lag das Auto auf dem Rücken, wurde angezündet und ausgenommen. Die Lehre aus diesem Test lautet „Beschädige etwas und kümmere dich nicht darum, andere werden es somit genauso behandeln“. Man muss aber nicht unbedingt ein Auto opfern, um einen Beweis für eine solche Theorie zu gewinnen. Die Beobachtung seines eigenen Mikrokosmos reicht häufig aus. Da wäre die aufgeräumte Wohnung, in der man sich am wohlsten fühlt und die erste Zeit wird man den Teufel tun und irgendwo etwas liegen lassen, sobald aber die ersten Teile nicht mehr auf ihrem Platz liegen findet das Chaos seinen Weg.

Wir als Softwareentwickler kennen dieses Vorgehen nur zu gut. Ist der erste Verstoß gegen die geltenden Regeln erst mal geschehen, so lassen der zweite und dritte nicht lange auf sich warten. Ist das System aber sauber, so tut es uns Entwicklern in der Seele weh, den ersten Fehler zu begehen, denn die meisten erkennen die Eleganz eines reinen Systems.

Es darf nicht vergessen werden, dass es viele Junior-Entwickler in Projekten gibt. Häufig passen sie sich an die Qualität des Codes an, den sie vorfinden. Sollten also keine Kommentare vorhanden sein, so wird er auch keine schreiben. Fehlt die Testabdeckung, so wird sich ein Junior nicht hinsetzen und Unit Tests schreiben. Dafür fehlen meist einfach die Erfahrungswerte und das Wissen, dass diese Eigenschaften von gutem Code einem zum späteren Zeitpunkt weiterhelfen.

Um ein System auf die Dauer sauber zu halten, gilt es möglichst viele Regeln, die man sich gesetzt hat automatisiert zu überprüfen. Es darf nicht passieren, dass sich der Verfall heimlich einschleicht. Ist ein Verstoß erst mal eine Weile im System wird sich niemand mehr verantwortlich fühlen, passiert das Auffinden jedoch zeitnah, so existiert auch noch eine Bindung zum Code.

Regeln die heutzutage einfach automatisiert geprüft werden können sind beispielsweise:

• Formatierungsregeln
• Validierung des Output-Formats
• Einhaltung minimaler Testabdeckung
• Fehlerfreier Testdurchlauf
• Softwaremetriken

Alles was einfach überprüft werden kann, sollte auch gemacht werden.

Bei der Einführung solcher Prüfungen, kann auch sehr viel falsch gemacht werden. Leicht kann der verantwortliche Qualitätsmanager über sein Ziel herausschießen. Sollte zum Beispiel jemand auf die Idee kommen nach dem Lesen dieses Abschnitts die aufgestellten Formatierungsregeln automatisiert zu testen, so ist dies fürs erste eine gute Idee. Wenn der Mechanismus dann das erste Mal durchgelaufen ist, wird man feststellen, dass bereits hunderte von Fenstern eingeschlagen wurden, also viele falsche Formatierungen gefunden wurden. Die Entwickler werden auf diese Art nicht mitgenommen werden. Ob man jetzt 50 oder 51 Probleme hat, ist einem herzlich egal.

Um neue Regeln sauber einzuführen müssen wir das Problem in kleine Häppchen zerlegen und diese dann peu à peu bereinigen. Wir haben neue Formatierungsregeln? Diese müssen vielleicht nur für neuen Code gelten oder wir schalten jeden Monat ein neues Verzeichnis zur Überprüfung hinzu. Wichtig dabei ist, dass der Schmutz, welcher sich über die Jahre gesammelt hat überschaubar bleibt, die Entwickler müssen das Gefühl haben es in einer humanen Zeit hinzubekommen. Wer räumt schon gerne den Müll von anderen auf?

Man sollte diese Phasen und den Ablauf der Teamentwicklung kennen. Wenn man diese ignoriert, stellt sich ein beliebig gutes oder schlechtes Ergebnis ein (was Motivation des Teams / Abwanderung und Zulauf, Zusammenarbeitsformen, Arbeitsergebnisse angeht).

Wenn man diese Prozesse kennt, kann man steuernd und bewusst eingreifen, um insgesamt bessere Ergebnisse zu erzeugen. Der Vortrag reflektiert sowohl berufliche Teams als auch Open Source Projekte und beantwortet Fragen zur Zielsetzung und -erreichung, Motivation und Beständigkeit.

Bei Scrum ist es anders. Es wird vom Product Owner verlangt alle Features in eine Reihenfolge zu setzen. Es ist eine einfache Liste mit Wünschen und wie bei allen Listen gibt es keine Einträge, die auf derselben Position verharren. Das Team, welches das Projekt technisch betreut weiß also immer genau, was als nächstes ansteht und was zum jetzigen Zeitpunkt das Potential hat bald umgesetzt zu werden.

Wo war aber das eigentliche Problem? Im ersten Beispiel war es der Produktverantwortliche, der sich nicht entscheiden konnte, was denn momentan das wichtigste ist und wie die verschiedenen Features untereinander gewichtet werden sollen. Hilft uns Scrum dabei dieses Problem zu lösen? Ein klares Nein. Das gute an Scrum ist aber, dass es uns als Rahmenwerk dazu zwingt unser Projekt besser zu verstehen. Es zwingt uns eine klare Reihenfolge zu definieren. Der Product Owner muss sich hinsetzen und Gedanken darüber machen in welcher Reihenfolge die Punkte abgearbeitet werden sollen. Er reflektiert sein Produkt immer und immer wieder, redet mit anderen Stakeholdern und stimmt sich mit ihnen ab.

Oft ist einem gar nicht klar, was dies eigentlich bedeutet und wird als pure Schikane empfunden. Dem ist aber nicht so. Die Entwickler haben auf einmal nicht mehr den riesen unsortierten Berg an Arbeit vor sich liegen und können uns strukturierter beginnen anzufangen. Wünsche, die ganz hinten auf der Liste stehen müssen erst mal gar nicht mehr in Betracht gezogen werden und es wird nur das entwickelt, was gerade relevant ist. Auch wird den Verantwortlichen klar, was es vielleicht nicht in das nächste Release schaffen wird und man kann sich frühzeitig darauf einstellen. Es handelt sich also keinesfalls um Schikane.

Nehmen wir ein zweites Beispiel. Bei Scrum gibt es täglich ein aktuelles Sprint-Burndown-Chart, das dazu verwendet wird den Fortschritt im aktuellen Sprint zu visualisieren.

Die optische Aufbereitung hilft den Entwicklern zu erkennen, wann sie mit ihrer Arbeit hintendran sind und wann sie nahe an der erhofften Geschwindigkeit liegen. Man könnte jetzt meinen, das Burndown-Chart löst das Problem des faulen Entwicklers und es ist dazu da ihn immer wieder drauf hinzuweisen, dass er härter arbeiten soll. Viele Arbeitgeber sehen dies genauso. Zum Glück ist dies aber falsch.

Das Burndown-Chart ist ein Werkzeug um Probleme aufzuzeigen. Sobald etwas Unerwartetes im Diagramm zu sehen ist, heißt es, dass man nachforschen muss, um herauszubekommen, was der Grund dafür ist. In den allermeisten Fällen ist es nicht das faule Team, sondern Rahmenbedingungen, die nicht stimmen. Häufig sind es Rahmenbedingungen wie unaufgelöste Abhängigkeiten, ungenaue Schätzung durch zu viele unbekannte technische Voraussetzungen oder zu ungenaue Beschreibung der eigentlichen Features.

Scrum gibt auch in diesen Fällen nicht vor, wie die Probleme zu lösen sind, es hilft einem aber zeitnah festzustellen, dass dort Probleme existieren. Wie diese zu lösen sind, muss das Team entscheiden.

Probleme in Unternehmen sind zwar häufig ähnlich, aber doch immer wieder ein wenig anders. Ein Projektmanagement-Framework zu schaffen, welches alle möglichen Probleme löst ist also fast unmöglich zu konzipieren, ohne dass das Regelwerk die Umfang einer Enzyklopädie annimmt. Scrum geht also den richtigen Weg indem es einem die Werkzeuge an die Hand gibt Probleme aufzudecken und sich bei der Lösung im groben erst einmal  heraushält.

Wird die Untersuchung gewissenhaft durchgeführt, startet man häufig mit einer Matrix, die mit relevanten Qualitätskriterien gefüllt werden. Häufig ist einer der ersten Punkte, die dort auftreten Geschwindigkeit, da es für ein System wichtig ist schnell zu reagieren und dem Benutzer ein angenehmes Nutzungsgefühl zu gewährleisten. Ein großer Fehler, der bei einer solchen Evaluierung häufig gemacht wird ist das Denken in Vergleichen. Technologie 1 ist schneller als Technologie 2. Aus diesem Grund ist Technologie 1 besser als Technologie 2. Richtig. Zumindest wenn es rein um die Performance geht. Nehmen wir mal ein konkretes Beispiel. Wir betrachten zwei Webserver, der eine kann 6.000 statische Anfragen pro Sekunde abarbeiten, der andere bis zu 10.000. Ist die zweite Technologie besser als die erste? Ja, auf die Performance bezogen sicherlich. Betrachtet man das Szenario ein wenig genauer, muss man noch mal einen Schritt zurückrudern.

Genau wie in sehr vielen anderen Problemen der Softwareentwicklung  spielt hier das Anforderungsmanagement eine wichtige Rolle. Der Projektverantwortliche hat die Aufgabe die nicht-funktionalen Anforderungen zu definieren. In den meisten Fällen wird die Forderung an die statischen Anfragen pro Sekunde unter 6.000 liegen. In unserem fiktiven Projekt nehmen wir 1.000 als Richtwert.

Vergleicht man jetzt die beiden Webserver, so wird klar, dass sie mit ihrer Geschwindigkeit beide in Frage kommen. In der aufgestellten Evaluierungsmatrix darf also nicht der Punkte der Geschwindigkeit aufgeführt sein, sondern die Frage „Schnell genug?“ mit ja oder nein muss beantwortet werden. Die tatsächliche Geschwindigkeit darf als Fußnote natürlich notiert sein. Wichtig hierbei ist, dass einem klar wird, dass somit andere Qualitätskriterien wie Wartbarkeit, Erlernbarkeit oder Erweiterbarkeit nun einen höheren Stellenwert gewinnen. Wahrscheinlich sollte man jedem Informatiker nach dem Studium oder der Ausbildung einen Zettel mit „Habt ihr an die Anforderungen gedacht?“ in die Hand drücken, um ihm sein Leben zu erleichtern.

Diese Art zu Vergleichen ist nahe verwandt mit dem „You ain’t gonna need it“-Paradigma, da man Optimierungen, die derzeit nicht notwendig sind auch nicht mit in die Messung einbezieht.

Solche Entscheidungen gilt es aber nicht zu treffen, wenn es um den Einkauf von Software geht, sondern auch wenn man die Eigenimplementierung vorzieht. Einen großen Wert auf Geschwindigkeit zu legen ist sicherlich keine schlechte Eigenschaft eines Softwareentwicklers, doch muss einem klar sein, dass Optimierung oft nicht ohne einen gewissen Preis zu erhalten ist. Wie überall im Leben ist es so, dass wenn man sich sehr stark auf eine Thema konzentriert andere hinten über fallen. In den Performance-Fällen ist es häufig die Wartbarkeit oder Erlernbarkeit, die zuerst in Vergessenheit gerät.

Warum ist dies schlimm? Jeder Programmierer hat sicherlich seine eigene Prioritätenliste, was Anforderungen an den eigenen Code angehen. Bei vielen steht Geschwindigkeit an erster Stelle, diese Entwickler vergessen aber sehr häufig, dass Hardware um einiges günstiger ist, als das Gehalt eines Mitarbeiters. Die Rechnung, die einen nach einer solchen Performanceoptimierung serviert wird ist einfach. Die Anzahl der Server, die eingespart werden muss in Verhältnis stehen zu dem Mehraufwand, den ein Entwickler benötigt um das System zu warten oder weiterzuentwickeln. Meist ist es nämlich doch günstiger einen zusätzlichen Server aufzubauen, um damit Performance zu gewinnen, als das vorhandene System zu beschleunigen.

Diese Regeln gelten solange man in einem eigenen Projekt arbeitet, man also Herr seiner Anforderungen ist und die Skalierung des Systems selber übernehmen kann. Findet man sich im Produktkontext wieder, sieht die Welt anders aus. Hier geht es um Alleinstellungsmerkmale der Software, die man verkaufen will und schneller zu sein als die Konkurrenz ist sicherlich ein wichtiges Kaufkriterium. Ich gehe aber davon aus, dass die meisten Webentwickler in Projekten und nicht an Produkten arbeiten.

Hier noch die offizielle Ankündigung:

Die Mobile Developer Conference (MDC), die Konferenz für Mobile-Entwickler, findet vom 13. – 14. Februar 2012 zum vierten Mal im Radisson Blu Hotel in Hamburg statt. Nach dem Start 2011 in den deutschen Großstädten München, Köln und Hamburg wird die Konferenz um einen weiteren Tag und einen Thementrack in Hamburg erweitert.

Ein breites Wissen der mobilen Plattformen ist heutzutage erforderlich – auch Themen wie Marketing der App sind relevant. Die Verzahnung mit der IT-Infrastruktur im Unternehmen erfordert ein hohes Maß an Prozessen in mobilen Projekten. Die Mobile Developer Conference widmet sich diesen Themen ausführlich. Aktuelle Trends und Lösungen werden Ihnen präsentiert, damit Sie für Ihre Projekte gerüstet sind.
 

So wie es aussieht werde ich beim abendlichen Feiern/Essen dabei sein. Wer mich also sieht, am besten ansprechen und ein Bier zischen.