Morgen halte ich einen kleinen halbstündigen Einführungsvortrag zu dem MapReduce-Programmiermodell und dem Apache Hadoop-Framework. Die Folien werde ich anschließend über SlideShare online stellen.
Wenn wir mit anderen zusammenarbeiten besteht immer die Gefahr sich gegenseitig zu stören. Wir arbeiten im gleichen Projekt, bearbeiten die selben Klassen, schreiben in die selbe Datenbank, gegen die der Kollege seine Tests fährt, machen Änderungen, die sich gegenseitig ausschließen. Oft stellt das kein Problem dar, wenn es koordiniert oder zumindest mit dem Wissen der Kollegen geschieht. Was ist aber, wenn wir genau das nicht wollen? Wenn wir in Ruhe die nächsten zwei Wochen an einem ganz besonderen Feature arbeiten wollen oder ein größeres experimentelles Refactoring vornehmen wollen? Es geht aber nicht nur um die großen Aufgaben. Auch in unserer alltäglichen Arbeit, sollte die Gefahr mit der Arbeit Anderer zu kollidieren möglichst gering sein.
Wir müssen uns also isolieren können und unsere Entwicklungslandschaft muß das unterstützten, uns dafür die technischen Möglichkeiten geben. Solange es für ein gesamtes Team nur eine Datenbank, auf der alle arbeiten, oder nur einen Application Server gibt, gelingt das nicht. Solche Systeme nenne ich immer scherzhaft Synchronisationssingularitäten, also Punkte, an denen alle Arbeiten zusammenlaufen laufen. Aber was bedeutet jetzt Isolation für eine Entwicklungslandschaft?
Hier meine Definition:
Isolation ist die Fähigkeit einer Entwicklungslandschaft an dem SUD (System Under Development) Änderungen vorzunehmen, ohne dabei von Anderen ungewollt beeinflußt zu werden oder Andere ungewollt zu beeinflußen.
Ein sehr gutes praktisches Beispiel für Isolation unterstützende Werkzeuge in einer Entwicklungslandschaft sind Versionsverwaltungssysteme wie Subversion oder Git, das die Isolation durch seinen dezentralen Ansatz noch weiter vorantreibt als früher CVS oder jetzt Subversion. Aber der Einsatz eines Versionskontrollsystems kann nur ein erster Schritt sein. Abgesehen davon: zeitgemäße Softwareentwicklung ohne Versionskontrollsystem ist ein Widerspruch in sich.
Heute lassen sich die meisten Systeme, die wir für Entwicklung und Test benötigen ohne Probleme für jeden Entwickler bereitstellen. Eine eigene Datenbank auf dem Laptop, ein lokaler FTP- oder Mailserver oder auch Applikation-Server sind immer möglich. Manche dieser Systeme müssen sogar nicht festinstalliert werden, sondern können im Rahmen eines Builds installiert und konfiguriert werden. JBoss, GlassFish und Apache Tomcat können aus ZIP-Archiven vollständig installiert und angepaßte Konfigurationsdateien anschließend generiert werden. Wird eine saubere Installation gebraucht, wird die alte gelöscht und eine neue automatisch installiert. Mit etwas Ehrgeiz ist das durchaus möglich.
Aber Isolation bringt noch weitere Vorteile für die Software-Entwicklung:
Wenn wir beim Aufbau unserer Entwicklungslandschaft Isolation konsequent von Anfang an verfolgen und beachten, erhalten wir die Chance besser im Team zusammenarbeiten zu können, weil wir es dann geschafft haben gegenseitige Abhängigkeiten weiter aufzulösen. Gerade für agil arbeitende Teams sollte Isolation immer ein zu erreichendes Ziel sein, den deren Fehlen stört den Arbeitsfluß.
Das Software Engineering Blog läuft auf einer inzwischen angestaubten Version von WordPress und es wird langsam Zeit mit der Zeit zugehen. Daher werde ich zwischen den Feiertagen die Zeit für ein Update nutzen. Daher kann es zwischenzeitlich zu Problemen kommen. Aber ein schon angelegtes Vollbackup sollte das Schlimmste verhindern helfen. 
Am Montag war der letzte Berliner Scrumtisch in diesem Jahr und Andrea Tomasini sprach über Kanban. Seine Vorstellung von Kanban sorgte unter den wenigen vorweihnachtlichen Teilnehmern für intensive Diskussionen. Vielleicht schaffe ich es ja noch ein paar Zeilen zu meinen natürlich rein subjektiven Ansichten dazu zu schreiben. Ehrlich gesagt, ich habe mich mit Kanban dabei nicht anfreunden können, auch wenn mir einzelne Ideen gut gefallen haben.
Nach dem Vortrag hat mich Tomasini auf das Buch The Fifth Disciplin von Peter M. Senge aufmerksam gemacht. Schon beim ersten Blätter wußte ich, das dieses Buch etwas für mich ist und habe es flugs bei A..... bestellt.
Nach Senger ist die fünfte Disziplin Systemdenken und faßt Personal Mastery, Mental models, Building shared vision und Team Learning zusammen. Das sind die ersten vier Disziplinen. Es geht also darum übergreifend zu denken und zu handeln, um Dinge zu vernetzen und so in Bewegung zu bringen.
Was mir an der Wikipedia-Zusammenfassung zum Buch besonders gut gefallen hat, sind The 11 Laws of the Fifth Discipline, die ich hier einfach einmal reinkopiere...
Ich kann hier nur elf Mal nicken, aber meine Lieblinge sind 1, 6, 7 und last-but-not-least 8.
Statusmails sind ein beliebtes Kommunikationsmittel, um Meilensteine oder wichtige Änderungen an alle Beteiligten zu kommunizieren. Richtig formuliert vermitteln sie schnell die wesentlichen Fakten und helfen uns besser den Stand an auch einen größeren oder nicht immer direkt beteiligten Personenkreis zu vermitteln.
Eigentlich ist das sehr gut, denn wir alle wissen, daß Kommunikation wesentlich über Erfolg oder Mißerfolg, Sieg oder Niederlage entscheidet.
Daher sollte ich eigentlich auch kein Problem mit ihnen haben. Habe ich aber. Das Problem ist, das es Mails sind. Widersprüchlich? Auf den ersten Blick sicherlich, aber ich habe auch mindestens ein gutes Argument dafür: Mails gehen in den Mailboxen ihrer Empfänger verloren.
Zum einen bin ich mir sicher, daß die meisten Statusmails ungelesen in vielen Mailboxen versauern, da die Empfänger gerade mit subjektiv wichtigerem beschäftigt sind. Das in der Mail behandelte Problem betrifft mich jetzt gerade nicht, das kann ich auch später lesen. Irgendwann ist diese Mail kann in der Inbox soweit hinten, daß wir uns gar nicht mehr an sie erinnern.
Was aber noch schlimmer ist, diese Statusmails sind immer nur für die verfügbar, die genau in diesem Augenblick an dem Projekt beteiligt sind. Wer später hinzukommt, hat keine Chance mehr an diese Informationen zu kommen. Und oft sind es aber genau diese Informationen, die Projektneulingen helfen zu verstehen, warum das Projekt jetzt da ist wo es ist und warum dies so und jenes so ist.
Ein Blog bietet hierfür eine wunderbaren Alternative. Chronologisch aufgebaut kann man sich in die Geschichte des Projektes einlesen, da die wichtigen Informationen zentral an einer Stelle gesammelt werden.
Ein berechtigter Einwand ist, daß nicht sichergestellt ist, daß das Blog auch gelesen wird, da man es ja explizit aufrufen muß (Pull-Prinzip), man bei Mails aber relativ sicher sein kann, daß jede Mitteilung auch beim Empfänger ankommt. Das stimmt, aber erhalten bedeutet noch nicht gelesen. Ich will damit nicht das Argument entkräften, denn ich teile die Ansicht auch. Doch wie wäre es mit einer Mailschnittstelle, die neue Blogeinträge einzeln oder aggregiert an einen Verteiler schickt? So könnten sinnvoll E-Mail und Blog als Kommunikationsmittel eingesetzt werden, ohne die bestehenden Vorteile zu verlieren.
Abschließend möchte ich aber noch einmal den wichtigsten Punkt hervorheben: Wie in einer Firma oder in einem Projekt kommuniziert wird ist ein Teil der Kultur der Organisation. Und ein Blog bleibt daher stehts nur ein Mittel zu Zweck.
Also, viel Erfolg und auch Spaß am eigenen Projektblog!
P.S.: Da ich nun nicht der erste bin, der sich zum Einsatz von Blogs in Projekten Gedanken gemacht hat, hier ein paar Links zum Thema:
Im PM Blog habe ich einen interessanten Verweis auf einen Vortrag von Jurgen Apello auf der Agile Eastern Europe conference in Kiew gefunden, der nach meiner Ansicht wunderbar die wesentlichen Prinzipien zusammenfaßt, mit der Software-Entwicklungs-Teams geführt werden sollten.
Jurgen Appelo, "So Now You’re an Agilist. What’s Next?", Agileee conference, 2009 from Alexey Krivitsky on Vimeo.
Aus gegebenen Anlaß mal wieder ein Verweis auf einen Spiegel-Artikel. In "Google will die Weltherrschaft" widmet sich Spiegel online den sich immer weiter ausweitenden Aktivitäten von Google. Wie meinte heute ein Freund: "Die Staatssicherheit mußte die Daten noch selber sammeln, heute geben wir sie selber jedem weiter." Tja, leider stimmt das wohl.
Für alle aus dem Raum Berlin und an Scrum-Interessierte dürfte interessant sein, daß die OOSE im nächsten Jahr auch ein Scrum-Master-Seminar mit der Möglichkeit zur Zertifizierung in Berlin durchführt. Für mich auf jeden Fall die Gelegenheit, mich als Scrum Master zertifizieren zu lassen, ohne nach Hamburg zu fahren. Eigentlich aber auch schade.
Alle zwei Jahre steht auch bei mir eine Verlängerung des Handyvertrags an und die je nach Anbieter unterschiedlichen Angebote sorgen dafür, daß wohl viele Handys in Deutschland nach zwei Jahren den Besitzer wechseln. Der Erstbesitzer macht einen Technologiesprung und es findet sich doch immer jemand im Bekanntenkreis, der ein (neueres) Handy gebrauchen könnte.
So auch bei mir und daher besitze ich jetzt seit zwei Wochen ein Nokia E71. Sicherlich, nicht das aktuellste Modell auf dem Markt, aber genau das was ich brauche. Zumindest glaube zu brauchen. Es ist klein, handlich und leichter als mein altes E61. Und es hat unerwartete Nebenwirkungen: ich höre jetzt auch Podcasts. Auf dem Laptop war mir das immer nicht bequem genug. Schlimmstenfalls muß man da auch noch zuhören, sich also konzentrieren. Das klappt zwar neben der Arbeit, aber geht auch zu deren Lasten. Jetzt ist das anders. Die Podcasts aktualisieren sich automatisch über mein WLAN und da das Handy praktisch überall dabei ist, findet sich immer irgendwo etwas Zeit für ein wenig Edutainment. Aber nun zur Sache...
So komme ich endlich auch einmal dazu mir Podcasts des Software Engineering Radios anzuhören. So zum Bespiel die Episode 148 mit Dave Thomas zum Thema Software-Archäologie.
Thomas führt in diesem Podcasts ein paar interessante Dinge aus. Zum Beispiel, daß er am Code sehen kann, unter welchen Umständen die Software geschrieben wurde. Für mich ist das nachvollziehbar, denn unsere Arbeitsumstände haben einen maßgeblichen Einfluß darauf wie wir arbeiten und was wir erreichen können. Das erinnert mich aber auch an Conways Gesetz… Suchen sie einmal danach im weltweiten Gewebe.
Während des Podcasts wird auch das Thema Lesen von Code behandelt und daß dies eine viel zu stark vernachlässigte Disziplin ist. Das findet absolut meine Zustimmung. Und jeder der in Teams arbeitete weiß wie schwer ist manchmal schon sein kann, zu verstehen, was der Kollege da geschrieben hat und seine Gedankengänge nachzuvollziehen. Wie schwer ist es also erst sich in ein ganz fremdes System einzuarbeiten, eventuell noch auf einer anderen technischen Basis? Neulich habe ich mich mit der Implementierung von Hadoop beschäftigt. Und dabei mußte ich selber wieder erstaut feststellen, daß selbst wenn man im Grunde weiß wie etwas funktioniert, es doch eine Weile dauert ehe man die entsprechenden Teile im Code gefunden hat und zu verstehen beginnt, wie diese zusammenspielen. Am Ende ist es aber auch ein gutes Gefühl nicht nur zu wissen wie etwas ungefähr funktioniert, sondern es genau zu verstehen.
Thomas bemängelt in dem Podcast, daß in der Ausbildung an den Universitäten diese Disziplin nicht gelehrt wird. In anderen Fächern, wie den Geisteswissenschaften etwa, sei es gang und gäbe sich mit der Arbeit von anderen zu beschäftigen, indem deren Bücher und andere Veröffentlichungen von relevanten Autoren gelesen, analysiert und kritisiert werden.
Auch Mediziner lernen die menschliche Anatomie nicht beim ersten Kontakt mit den Patienten kennen, sondern schon bei der Sektion. Stellen sie sich einmal vor, sie kommen zu einem Arzt und hören: „Ah, so sieht das aus. Noch nie gesehen... Darf ich da einmal anfassen?“ Sie würden kopfschüttelnd den Raum verlassen und diesen Arzt für immer meiden.
Also warum nicht, wie Thomas es vorschlägt, Seminare an Universitäten anbieten, die sich nur mit der Analyse von bestehender Software beschäftigen? Nicht nur mit den abstrakten Konzepten, sondern mit deren konkreter Umsetzung durch exisitierende Systeme.
Das ist nicht schwer. Java ist eine leichte Sprache und die Unterstützung durch Entwicklungsumgebungen ist sehr gut. Große quell-offene Softwareprojekte sind im Java-Umfeld frei verfügbar. Ich nenne hier nur einmal die üblichen Verdächtigen: Hibernate, Tomcat, JBoss, …
Jedes dieser Systeme setzt freiverfügbare Standards wie JPA, Servlet, JSP und EJB um. Warum nicht die Umsetzung dieser Standards untersuchen am Beispiel von konkreten Implementierungen. Welche Algorithmen lassen sich finden? Wie sieht die Architektur aus und wird diese auch konsequent umgesetzt?
Davon würde jeder profitieren können. Also, vielleicht gibt es ja einen Leser dieses Blocks, der sich dieser Idee annehmen möchte…
Eine normale Arbeitswoche hat fünf Arbeitstage und zwei Pole. Montag ist der eine Pol und Freitag der andere. Anfang und Ende, Alpha und Omega. Jeder Wochentag hat seine Eigenheiten und von Wochenendarbeiten wollen wir einmal nicht ausgehen.
Montag ist der Tag nach dem Wochenende und das ist wichtig. Wir betreten das Büro ausgeruht und mit neuer Kraft. Probleme die am Freitag unlösbar waren sind über das Wochenende nebenbei gelöst worden. Manchmal einfach nach dem Aufstehen am Samstag und wir fragen uns, warum wir das nicht gleich so gesehen haben. Abstand und Ruhe sind oft die besten Problemlöser.
Am anderen Ende der Woche steht der Freitag. Freitag ist der Tag vor Samstag und Sonntag, also dem Wochenende und das ist wichtig für den nächsten Montag. Siehe oben. Freitags sollten keine harten Nüsse geknackt oder immens wichtige Termine angesetzt werden.
Den Montag sollten wir uns für die Dinge vorbehalten, die wir mit ausgeruht angehen wollen, die uns vielleicht schon seit einiger Zeit unter den Nägeln brennen oder letzte Woche liegen geblieben sind. Oft wird der Montag aber gleich mit Meetings vollgekleistert, die sich damit beschäftigen, war in dieser Woche zu erledigen ist. War das nicht schon letzte Woche klar, was ansteht? Die Woche hat doch schon begonnen und über das Wochenende hat sich meistens wenig geändert.
Dafür wird am Freitag oft versucht noch das zu schaffen, was noch vor Montag umgesetzt sein muß. Das beste Beispiel hierfür sind Deployments, die noch „schnell“ am Freitag live gehen müssen. Schauen Sie an solchen Tagen mal in das Gesicht Ihrer Kollegen, die sich gerade überlegen, was alles schief gehen könnte und überlegen, wie wahrscheinlich es ist, spätestes um 18:00 Uhr das Büro verlassen zu können.
Aber wie können wir es besser machen? Hier sind meine Tipps:
So, Sie müssen ja nicht einverstanden sein mit meinen Ansichten zur Einteilung der Woche, aber vielleicht habe ich Ihnen ja einen Anstoß zum Nachdenken über Ihre Woche gegeben.
Certified ScrumMaster
