Beiträge mit tag "Produktivität

Der Erfolgreiche Programmierer

1

Gestern habe ich auf dem PHP World Kongress 2010 einen Vortrag mit dem Namen „Der Efolgreiche Programmierer” gehalten. In diesem Vortrag ging es weniger um Software-Entwicklung und mehr darum, welche Eigenschaften und Methoden man bei sich selbst fördern sollte, um eine erfolgreiche Laufbahn als Software-Entwickler einzuschlagen. Erfolgreich muss dabei nicht unbedingt bedeuten, dass man die Karriereleiter aufsteigt oder kontinuierlich mehr Geld verdient, sondern kann z.B. auch bedeuten, langfristig einen interessanten Job zu haben.

Doch genug der Worte, hier sind die Slides des Vortrags:

Das war mein erster Vortrag, in dem nun weder Code, noch konkrete Empfehlungen für Tools zu finden sind. Ist eine ganz neue Erfahrung, auch in diesen Bereichen nun mein Wissen weiterzugeben.

Aufwand schätzen, ohne Aufwand zu haben

8

„Haben Sie ein neues Projekt und der Kunde möchte möglichst schnell wissen, was es kosten wird? Wollen Sie agil arbeiten, aber Ihre Entwickler müssen das Geld ranschaffen und haben keine Zeit für langwieriges Planning Poker? Sind sie auch der Meinung, dass aufwändiges Planen überflüssig ist?”

Dann gibt es jetzt die Lösung: Verwenden Sie einfach „Planning Dice”. Mit „Planning Dice” können Sie jede Aufgabe innerhalb kurzer Zeit abschätzen, ohne dass Sie dafür wertvolle Entwickler-Ressourcen von der Software-Entwicklung abziehen.

Wie funktioniert „Planning Dice”?

Drucken Sie sich den „Planning Dice”-Bausatz aus und schneiden die Vorlage aus. Falten Sie den Bausatz an den vorgegebenen Linien und nutzen Sie die Klebeflächen, um den „Planning Dice”-Bausatz zu fixieren. Verwenden Sie dazu handelsüblichen Papierkleber oder bestellen Sie das Original-„Planning Dice”-Klebeset.

Nun sind Sie nur noch Sekunden davon entfernt, langwierigen Planungsmeetings Adieu zu sagen. Um den Aufwand einer Aufgabe zu schätzen, denken Sie einfach fest an die Aufgabe und lassen Sie den „Planning Dice” aus Ihrer Hand auf einen Tisch gleiten. Der „Planning Dice” wird Ihnen den Aufwand auf der zum Himmel gewandten Fläche anzeigen. „Planning Dice” paßt sich automatisch an die Größe Ihrer Aufgaben und das Know-How Ihrer Entwickler an, so dass die Werte als Stunden, Tage, Wochen oder Mannmonate zu interpretieren sind. Sollten Sie streng nach Scrum implementieren, so zeigt Ihnen „Planning Dice” natürlich Story Points an.

Sollte „Planning Dice” ein „?” anzeigen, so hat „Planning Dice” noch nicht all benötigten Informationen für eine verläßliche Schätzung. Fokussieren Sie sich erneut auf die zu schätzende Aufgabe und wenden Sie danach den Planning Dice erneut an.

Der Bausatz

Probieren Sie „Planning Dice” noch heute aus und überzeugen Sie sich von den beeindruckenden Ergebnissen. Laden Sie dazu „Planning Dice” hier herunter.

Planning Dice - Jetzt NEU!„Planning Dice” und große Projekte

Wir erhalten oft Anfragen von Projektmanagern, die die Vorteile von „Planning Dice” auch in großen Projekten einsetzen möchten und Planungen auf Vorstandsniveau in Sekunden erstellen wollen. Auch dies ist natürlich mit „Planning Dice” möglich.

Laden Sie sich dazu einfach einen zweiten „Planning Dice” herunter und befragen Sie gleichzeitig beide „Planning Dice”. Die angezeigten Werte müssen dabei einfach miteinander multipliziert werden und Sie erhalten die korrekte Schätzung für Ihr Projekt.

Natürlich skaliert „Planning Dice” noch weiter und Sie können die komplette Ressourcenplanung für das nächste Jahr mit Hilfe von zehn „Planning Dice” innerhalb weniger Sekunden erledigen. Vorbei ist die Zeit, in der Sie mühsam die Roadmap durcharbeiten mussten, um die Grobschätzung der benötigen Projektpersonentage für das nächste Jahr zu ermitteln.

Vielen Dank an Sebastian Lorenz, der diese nette Idee mit mir gesponnen hat.

Dringlich vs Wichtig

4

Wenn Sie ein Team oder eine Abteilung von Software-Entwicklern leiten, dann landen jeden Tag eine unglaubliche Menge an Todos auf Ihrem Tisch. Das Tagesgeschäft wird erdrückend und Sie sind nicht mehr in der Lage, die strategische Planung zu machen, die eigentlich eine Ihrer Hauptaufgaben sein sollte. Sie müssen also das Tagesgeschäft reduzieren, aber wie entscheiden Sie, welche Aufgaben Sie selbst erledigen und welche Sie delegieren?
Machen Sie doch dazu das, was vor Ihnen schon Dwight D. Eisenhower (Präsident der Vereinigten Staaten von Amerika von 1953 bis 1961) gemacht hat und wenden Sie das Eisenhower-Prinzip an.

Bei diesem Prinzip prüfen Sie für jede Aufgabe, die es zu erledigen gilt, wie wichtig und wie dringlich diese ist. Doch bedeutet dringlich und wichtig nicht das selbe? Sehen Sie sich dazu die folgenden Definitionen der Begriffe an.

Dringlichkeit: die Notwendigkeit, eine wichtige Handlung kurzfristig zu erledigen, also die (zeitliche) Priorität.

Wichtigkeit: die schwerwiegende (wichtige) Bedeutung eines Gegenstandes.

Die Dringlichkeit einer Aufgabe bezieht sich also auf die Zeit, die zur Verfügung steht, um die Aufgabe zu erledigen, während sich die Wichtigkeit der Aufgabe immer auf den Inhalt der Aufgabe bezieht. Wenn Sie auf die Toilette müssen, so ist das meistens eine dringliche Angelegenheit, es kann hier schnell zu spät sein und dann noch auf die Toilette zu gehen, bringt Ihnen keinen Nutzen mehr. Einen guten Schulabschluss zu schaffen ist eine wichtige Aufgabe, die auch noch Nutzen bringt, wenn Sie sie ein oder zwei Jahre später abschließen, als dies geplant war.

Das Eisenhower-Prinzip

Wenn Sie nun Ihre Aufgaben nach deren Dringlichkeit und Wichtigkeit bewertet haben, dann nehmen Sie sich das folgende Koordinatensystem vor und platzieren Ihre Aufgaben auf den Achsen wichtig und dringlich.

Jede Ihrer Aufgaben sollte nun einem der Bereiche A-D zugerdnet worden sein. Manche Aufgaben sind wichtig aber nicht dringlich, manche sind dringlich jedoch nicht wichtig, manche sind beides und so einige sind wahrscheinlich weder wichtig noch dringlich. Mit dieser Einteilung ist die Entscheidung leicht, wie mit den einzelnen Aufgaben verfahren werden soll.

A-Aufgaben: Diese Aufgaben sind wichtig und sie müssen schnell erledigt werden. Das bedeutet, Sie erledigen die Aufgaben sofort und selbst. Die Delegation und die Kontrolle der Aufgabe würden zu viel Zeit beanspruchen.

B-Aufgaben: Diese Aufgaben sind wichtig, jedoch nicht dringlich. Definieren Sie schon jetzt, wann Sie diese Aufgaben erledigen werden und tragen Sie sich einen Blocker in Ihren Kalender ein. Stellen Sie auch sicher, dass Sie die Aufgaben zum geplanten Termin erledigen.

C-Aufgaben: Diese Aufgaben müssen schnell erledigt werden, es sind aber keine wichtigen Aufgaben. Delegieren Sie sie! Das sind genau die Aufgaben, die Sie von den wichtigen B-Aufgaben abhalten, wodurch diese plötzlich neben wichtig auch noch dringlich sind. Also sorgen Sie dafür, dass die C-Aufgaben von jemand anderem erledigt werden.

D-Aufgaben: Diese Aufgaben sind weder wichtig, noch dringlich. Das bedeutet also, sie bringen keinen Nutzen. Diese Aufgaben werden also weder sofort noch später erledigt, sondern gehören einfach nur in den Papierkorb.

Wenn Sie Ihre Aufgaben regelmäßig mit dem Eisenhower-Prinzip priorisieren, dann können Sie sicher sein, dass Sie Ihre Zeit und die Zeit Ihrer Mitarbeiter sinnvoll einsetzen. Besonders hervorheben möchte ich hierbei das regelmäßige Priorisieren: Wichtige Aufgaben, die letzte Woche nicht dringlich waren, werden es wahrscheinlich werden, wenn Sie nicht bearbeitet werden.

Kleine Schritte sind besser als keine Schritte

1

Eigentlich hatte unter diesem Titel geplant, einen Eintrag über die Pfadfinder-Regel zu schreiben, die Robert C. „Uncle Bob” Martin in seinem Buch Clean Code vorstellt:

Leave the campground cleaner than you found it.

Genau an dem Tag, als ich den Eintrag schreiben wollte, kamen mir jedoch Nils und Holger zuvor. Mein erster Impuls war, meinen Eintrag einfach zu löschen und das Thema zu den Akten zu legen. Doch Schritt für Schritt (wer findet hier den Wortwitz?) bin ich wieder zu der Idee zurück gekehrt.

Die Überschrift „Kleine Schritte sind besser als keine Schritte” war das Motto von Willy Brandt (dt. Bundeskanzler von 1969 bis 1974), der damit seine Ostpolitik der langsamen Annäherung beschrieben hat.

Willy Brandt hat bei diesem Zitat sicher nicht an Uncle Bob, Coding Standards und kleine Refactorings gedacht. Sehr viele Entwickler, die sich die Pfadfinder Regel auf die Fahne schreiben, beschränken diese jedoch zu stark auf den Quellcode und wenden diese nicht ganzheitlich auf die eigene Arbeit und das Umfeld an. Richtig aufgefallen ist mir das auch erst in den letzten Wochen, in denen ich ausführlich mit Holger über Clean Code und die Einührung der Prinzipien in unseren Teams gesprochen habe.

Wenn Willy Brandt diese Regel auf eine Ostpolitik angewandt hat und damit eine Annäherung an Polen und die damalige Sowjetunion damit geschafft hat, dann sollten wir diese Regel auch in unserem täglichen Arbeitsumfeld anwenden können.

Ein gutes Beispiel ist, dass ich auf Konferenzen, auf denen ich über Clean Code, Testgetriebene Entwicklung und eine Menge andere „gute Dinge” geredet habe, am Ende immer gefragt werde, wie man diese in Teams einführt. Für die Teilnehmer sieht das immer nach einem großen Schritt aus, ein Team, das kein Verständnis für eine geminesame Code-Basis, Qualität und Entwicklungsmethodik hat, in ein Team zu transformieren, das bei der Entwicklung und der Pflege des Codes harmonisiert. Meine Antwort ist auch hier immer die selbe: Man muss es in kleinen Schritten angehen. Sie werden es nicht schaffen, das Bewußtsein für neue Entwicklungsmethodiken bei allen Teammitgliedern sofort zu wecken, also wecken Sie es bei einem und schauen Sie, wie es sich danach entwickelt.

Ähnlich verhält es sich bei der klassischen Beförderung vom Entwickler zum Leiter eines Entwicklungsteam. Sie können planen, wie Sie als perfekter Teamleiter sein könnten und diesen Plan dann in einem Jahr umsetzen. Oder Sie fangen morgen an und erledigen eine Teilaufgabe Ihres neuen Jobs mit Bravour und gehen dann die nächste an.

Sei es also ein neues Projekt oder ein neuer Job, der eine große Veränderung bedeutet, so ist der erfolgsversprechende Weg der, der mit vielen kleinen Schritten auf ein Ziel führt, das sich vielleicht sogar während des Wegs verändert.

Und wäre das nicht zu dramatisch für das Ende eines Blog-Artikels, würde ich jetzt schreiben:

Danke Willy Brandt. Danke Uncle Bob. Danke Holger.

Meeting Manieren

0

Meetings – Man kann nicht ohne sie arbeiten, aber auch nicht mit ihnen.

Leider sind Meetings unter Entwicklern oft verpöhnt und haben den Ruf, dass dort nicht gearbeitet, sondern nur heiße Luft produziert wird. Das muss aber nicht so sein. Dass Meetings oft unproduktiv sind, liegt nicht in der Natur der Meetings, sondern daran, wie diese durchgeführt werden. Dabei gibt es ein paar einfache und logische Regeln, deren Befolgung die Ergebnisqualität von Meetings positiv beeinflussen.

Keine ad-hoc Meetings.

Wenn Sie wollen, dass die Teilnehmer Ihres Meetings sich vorbereiten können (und ich ich hoffe, dass Sie das wollen), dann müssen Sie Ihnen Zeit dafür geben. Also kündigen Sie Ihr Meeting nicht erst 30 Minuten vor geplantem Beginn an, sondern besser eine Woche. Das ermöglicht allen Teilnehmern, sich in das Thema einzuarbeiten, und somit auch, im Meeting etwas beizutragen.

Natürlich wird es Situationen geben, in denen Sie nicht die Möglicheit haben, eine Woche zu warten (Ihr Projekt  fährt gegen die Wand, Sie müssen ein Vorstandsreporting abgeben, etc.), aber das sollten Ausnahmefälle sein und nicht die Regel.

Setzen Sie sich ein Ziel.

Natürlich sind Sie schon selbst darauf gekommen, dass ein Meeting ohne Ziel keinen Sinn macht. Das ist nicht das Problem. Das Problem ist, dass viele Meetings nicht ein Ziel haben, sondern gleich drei oder vier oder zwölf. Das führt dazu, dass Sie sich im Meeting an zu vielen Zielen orientieren müssen und meist keines der Ziele erreichen oder zumindest nicht das Wichtigste.

Setzen Sie sich also ein Hauptziel, wie zum Beispiel „Nach dem Kick-Off sollen alle Teammitglieder die Vision unseres Projektes verstanden haben.” oder „In diesem Meeting klären wir, in wessen Verwantwortung der Datenbank-Import gehört.

Verschicken Sie eine Agenda.

Eigentlich sollte man meinen, dass eine Agenda zu jedem Meeting gehört. Nur leider bin ich persönlich in mehr Meetings gewesen, zu denen es keine Agenda gab, als in Meetings, zu denen ich vorab eine Agenda erhalten habe. Mittlerweile verweigere ich die Teilnahme an agendalosen Meetings. Wenn jemand nicht in der Lage ist, zusammenzufassen, wozu er meine Zeit benötigt, kann es aus meiner Sicht auch nicht wichtig sein, dass ich am Meeting teilnehme. Das Erstellen und Versenden einer Agenda hat noch weitere Vorteile:

  • Der Organisator des Meetings muss sich Gedanken machen, was im Meeting alles besprochen werden soll.
  • Jeder geplante Teilnehmer kann entscheiden, ob seine Teilnahme wichtig und sinnvoll ist, oder ob es besser wäre, einen Vertreter zu entsenden.
  • Bei langen Meetings hat jeder Teilnehmer die Möglichkeit, partiell nur zu seinen Themen teilzunehmen.
  • Jeder Teilnehmer kann sich entsprechend auf die Themen vorbereiten.
  • Die Agenda kann bereits im Vorfeld zu einer Diskussion führen, sie muss nicht in Stein gemeißelt sein, sondern kann nach dem Feedback der Teilnehmer angepasst werden.

Es versteht sich von selbst, dass die Agenda das zuvor definierte Ziel Ihres Meetings stützen sollte.

Eröffnen Sie das Meeting.

Auch die Eröffnung eines Meetings gehört zu den Selbtverständlichkeiten, die leider viel zu oft ignoriert werden. Wenn Sie zu einem Meeting einladen, dann sagen Sie auch zumindest den ersten Satz im Meeting. Punkt. Sie können das Wort gerne an einen Experten weitergeben, der dann detailliert in das Thema einführt, aber zumindest die Begrüßung muss der Organisator übernehmen. Bei der Eröffnung des Meetings sollten Sie auch folgende Regeln berücksichtigen:

  1. Beginnen Sie mit einer Vorstellungsrunde. Gehen Sie nicht davon aus, dass sich alle Teilnehmer bereits kennen. Auch wenn dies der Fall sein sollte, so sind die Teilnehmer in anderen Rollen und anderen Aufgaben anwesend, als die vielleicht in anderen Projekten der Fall war. Bieten Sie also allen Teilnehmern die Möglichkeit zu erklären, warum sie ein „Eisen im Feuer” dieses Meetings haben.
  2. Bringen Sie alle Teilnehmer auf den selben Stand. Als Organisator haben Sie sich am bestmöglichsten mit dem Thema des Meetings vertraut gemacht. Treffen Sie nicht die Annahme, dass auch alle anderen Teilnehmer genau wissen, wie der aktuelle Stand des Projektes ist. Das die Agenda den Teilnehmern die Möglichkeit gibt, sich vorzubereiten, bedeutet nicht, dass alle vorbereitet sind.
  3. Beginnen Sie das Meeting mit einem lockeren Gespräch und ermöglichen Sie allen Teilnehmern anzukommen, bevor Sie hart ins Thema einsteigen. Der Wechsel von einem Thema in ein anderes benötigt ein paar Minuten.

Die Eröffnung des Meetings kann sehr kurz gehalten werden und muss nicht mehr als zwei bis drei Minuten in Anspruch nehmen.

Verfolgen Sie das Ziel.

Niemandem hilft ein Ziel, das nicht erreicht, oder zumindest aktiv verfolgt wird. Wenn Sie sich ein Ziel gesetzt haben, dann prüfen Sie auch im Meeting regelmäßig, ob Sie noch in der Richtung des Ziels unterwegs sind. Wenn nicht, so greifen Sie korrigierend ein.

Die Überschrift dieser Regel lautet mit Absicht nicht „Halten Sie die Agenda ein”. Die Agenda ist ein Hilfsmittel zur Erreichung des Ziels, sie ist nicht das Ziel. Auch das mittlerweile beliebte Timeboxing, bei dem Sie zwar alle Agendapunkte ansprechen, hilft Ihnen nicht per se Ihr Ziel zu erreichen.

Erstellen Sie ein Protokoll.

Wenn Sie wollen, dass die Ergebnisse des Meetings dauerhaft bestehen, dann halten Sie sie fest. Schreiben Sie ein kurzes Protokoll, machen Sie Photos der erstellten Flipcharts oder nehmen Sie die Flipcharts mit und hängen Sie in Ihr Büro. Wichtig ist, dass Sie die Ergebnisse auf irgendeine Weise dokumentieren. Wichtig ist dabei nicht, in welcher Form Sie das machen. Es muss kein Protokoll sein, in dem genau festgehalten wird, dass RG zusammen JR die E Muss im Detail besprochen werden” getroffen haben und daraus für EW das TTermin suchen” entstanden ist. Leider sind die meisten Protokolle hauptsächlich eine Sammlung von Abkürzungen und unwichtigen Informationen und genau deshalb so unbeliebt. Protokollieren Sie nicht, wer in welcher Reihenfolge mit wem gesprochen hat, sondern halten Sie die Ergebnisse fest.

Nur wenn Sie ein Meeting mit einer Agenda und einem Ziel, das Sie verfolgen, früh genug ankündigen und entsprechend nachbereiten, wird aus einem Treffen mehrerer Personen in einem Raum auch ein echtes Meeting, das einen Mehrwert bietet.

Frisch im RSS-Reader

0

Seit ich mich entschlossen habe, selbst aktiv zu bloggen, habe ich auch wieder angefangen, regelmäßig andere Blogs zu lesen. Neu in meinem RSS-Reader sind jetzt:

Frank Westphal

Mit seinem Buch „Testgetriebene Entwicklung mit JUnit und FIT” verfolge ich in unregelmäßigen Abständen, was Frank Westphal veröffentlicht. Auf seiner Website veröffentlich er interessante Artikel zum Extreme Programming, Agiler Entwicklung und Qualitätssicherung. Seinen Podcast „Tonabnehmer” habe ich mir bislang noch nicht angehört, wären aber sicher ein guter Grund, Podcasts endlich mal auszuprobieren.

Neal Ford

Neal Ford ist Meme Wrangler bei Thoughtworks. Auf ihn bin ich bei einer Keynote auf der Dynamic Languages World aufmerksam geworden. Am meisten beeindruckt hat mich damals (und auch heute noch) sein Satz

Simplify essential complexity; diminish accidental complexity.

Diesem Satz hatten Holger Rüprich und ich auch eine unserer neun Regeln in unserem Workshop „Die Kunst des Software Design” auf der PHP World 2009 gewidmet.

Ludwig Ostrowski

Auf das Blog von Ludwig Ostrowski bin ich nur per Zufall (aka Twitter) gestolpert. In meinen Reader hat er es aus zwei Gründen geschafft:

  1. Seine neusten Einträge befassen sich mit Dependency Injection (und sogar PHP und Google Guice, meine Lieblingsthemen bei DI), Continuous Integration und Sonar. Alles Themen, die mich auch schon seit einiger Zeit fesseln.
  2. In seinem Blog zitiert er Martin Fowler mit einem meiner Lieblingszitate.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Ich werde das Blog auf jeden Fall mal im Auge behalten.

David Seah

Zum Abschluss noch ein Blog, das nichts mit Software-Entwicklung zu tun hat. David Seah schreibt über Design und Produktivität und kombiniert beides, in dem er wunderschöne Vordrucke für Tasklisten oder auch Ressourcenplanung zum kostenlosen Download anbietet. Zusammengefasst werden diese unter dem Namen „The Prinable CEO”, den David Seah wie folgt erklärt:

The Printable CEO name comes from the idea that a good CEO should focus primarily on those things that move the company forward; since I can’t afford to hire my own CEO, being able to print one out seemed like the next best thing!

Die Feeds

nach oben