Beiträge mit tag "Teamarbeit

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.

Verbotene Wörter

3

Vor kurzem hat mir Frank von einem Team erzählt, in dem man auf Fragen nur mit drei Antworten reagieren darf: „Ja.”, „Nein.” und „Ich weiß nicht.”. Sätze wie „Das sollte so funktionieren.” oder „Wenn alles glatt geht, müsste das klappen.” sind in diesem Team verboten.

Das wollte ich mal zum Anlass nehmen, eine Liste von Wörtern und Redewendungen aufzustellen, die ich (zumindest im Berufsleben) nicht mehr hören möchte, besonders wenn es um Aufwand, Lösungen oder Termine geht.

sollten”, „müssten”, etc.

Der Konjunktiv ist der Feind einer jeden Projektplanung. Meistens verrät er einem nicht, unter welchen Bedingungen ein Arbeitspaket rechtzeitig fertig wird, oder unter welchen Bedingungen der Code wie erwartet funktioniert. Wenn Sie den Konjunktiv im Berufsleben hören, dann nehmen Sie so schnell wie möglich Reißaus.

sollen

Sollen” ist der kleine Bruder von „sollten” aber fast genau so schlimm. Was machen Sie, wenn Sie in einem Anforderungsdokument einen Satz wie „Die Antwortzeit des Service soll unter 200 Millisekunden liegen.” vorfinden? Ist das eine freundliche Bitte oder eine zwingende Anforderung? Was passiert, wenn diese Anforderung nicht erfüllt wird? Beim Einsatz des Verbs „sollen” bewegen Sie sich in einer Grauzone.

einfach”, „nur”, etc.

In der Software-Entwicklung gilt nicht „Weil einfach einfach einfach ist.”. Zwei Situationen sind fast nie identisch, das heißt, wenn heute etwas funktioniert hat, haben Sie keine Gewißheit, dass es morgen genau so funktioniert. Die Vokabeln „einfach” oder „nur” werden meistens eingesetzt, um einen Sachverhalt zu verharmlosen oder die Komplexität zu verstecken. Wenn Sie diese Wörter hören, dann schauen Sie besser genau so hin. Aber vielleicht sehe ich das einfach nur zu eng.

prinzipiell”, „eigentlich”, „normalerweise

Ist der aktuelle Fall der Normalfall, oder wird jetzt gerade gegen das Prinzip verstoßen? Ich möchte nicht wissen, wann ein Arbeitspaket unter anderen Umständen eigentlich fertig wird, sondern wann genau in diesem konkreten Fall mit der Fertigstellung des Arbeitspaketes zu rechnen ist. Vor Jahren habe ich mit einem guten Freund gearbeitet, dessen Shop-Projekt monatelang „normalerweise nächste Woche fertig werden sollte”.

Was ist daran schlecht?

Warum möchte ich diese Wörter nicht hören? Sie machen es mir schwer, zu reagieren. Wenn das Projekt normalerweise pünktlich fertig gestellt werden sollte, dann sagt mir das das selbe, als würde das Projekt wahrscheinlich nicht rechtzeitig fertig und damit bin ich wieder genau so schlau wie vorher.

Ein „Wir hatten Probleme mit den Unit-Tests und werden nicht zum geplanten Termin fertig. Es dauert eine Woche länger.” zeigt mir klar, woran ich bin und ermöglicht mir (und dem Team) Maßnahmen zu ergreifen. Es geht hier um Verbindlichkeit, die nötig ist, um entsprechend reagieren zu können. Ob dies bedeutet, einfach Funktionalitäten außen vor zu lassen, um den Termin zu halten, oder stattdessen den Termin zu verschieben, hängt vom Projekt ab.

Aber warum hört man diese Wörter trotzdem so oft, wenn es darum geht, einen Termin zu bestätigen oder frühzeitig abzusagen? Meistens möchte man damit schlechte Nachrichten vermeiden und hofft, den Termin doch noch irgendwie zu halten. Damit wird die schlechte Nachricht in den meisten Fällen jedoch nur verschleppt, wenn der Termin nicht doch noch, wie durch ein Wunder, gehalten werden kann.

Wie kann man es verhindern?

Erschießen Sie nicht den Überbringer der schlechten Nachricht und schaffen Sie eine Kultur, in der man eigene Fehler zugeben und schlechte Nachrichten überbringen kann, ohne mit Sanktionen rechnen zu müssen. Belohnen Sie Verbindlichkeit und signalisieren Sie so, dass es Ihnen lieber ist, früh die schmerzhafte Wahrheit zu erfahren, anstatt sich lange in trügerischer Sicherheit zu wiegen.

Probieren Sie einfach, dann sollte das eigentlich auch in Ihrem Team funktionieren.

Jeder ist entbehrlich – außer John Rambo

2

In Rambo II – Der Auftrag wird John Rambo von seinem ehemaligen Vorgesetzten aus dem Gefängnis (in das man in nach Rambo – First Blood gesteckt hat) geholt und nach Vietnam geschickt. Dort soll er Photos von Kriegsgefangenen machen, die auch viele Jahre nach dem Vietnamkrieg dort festgehalten und gefoltert werden.

Unterstützt wird John Rambo dabei von der Vietnamesin Co Bao, in die er sich während seines Einsatzes verliebt und von Captain Vinh getötet wird. Rambo schwört Rache und befreit die Kriegsgefangenen unter Einsatz seines eigenen Lebens aus den Klauen des Vietcong.

Vor ihrem Tod führen Rambo und Co Bao die folgende Unterhaltung.

Rambo: „Ach weißt Du, ich bin entbehrlich.”
Co Bao: „Was bedeutet entbehrlich?”
Rambo: „Das ist so, als wenn man zu einer Party eingeladen wird, und dann nicht hingeht. Es spielt einfach keine Rolle.”
Co Bao: „Rambo, Du bist nicht entbehrlich.”

John Rambo ist also nicht entbehrlich. Doch was hat er davon? Immer wieder, wenn es Probleme gibt, muss Rambo sein Leben einsetzen, um diese Probleme zu lösen. Was das aus ihm gemacht hat, sieht man sehr gut im ersten Film der Rambo Reihe: In First Blood kommt Rambo aus dem Krieg zurück in eine Kleinstadt und ist so traumatisiert, dass er sich vom Sheriff provozieren läßt und einen Kleinkrieg anfängt. Am Ende des Films wird er von der Armee eingesperrt und erst wieder auf freien Fuß gesetzt, als man ihn bei einem Todeskommando braucht. Ähnlich ergeht es Rambo in den Jahren danach, statt Vietnam muss er in Rambo III nach Afghanistan. Selbst als er sich in „John Rambo” einen Altersruhesitz in Thailand aufbauen möchte, und wirklich keinen Ärger mehr sucht, kommt er nicht zur Ruhe. Stattdessen muss er eine Gruppe Missionare aus Burma retten, die nicht auf ihn hören wollten. Sein Leben wiederholt sich immer wieder.

Viele Software-Entwickler wollen so sein, wie John Rambo: unentbehrlich. Sie sind glücklich, wenn sie die einzigen sind, die wissen, wie man mit einer bestimmten Datenbank oder einer Legacy-Applikation umgeht. Wenn es Probleme mit dieser Datenbank oder dieser Anwendung gibt, dann muss man beim einzigen Entwickler vorsprechen, der sich damit auskennt und ihn bitten, diese Probleme zu lösen. Wenn man so manchen „unentbehrlichen” Entwickler reden hört, dann lassen sich diese Probleme auch nur, wie von John Rambo, unter „Einsatz des eigenen Lebens” lösen.

Auch wenn es anfänglich schmeichelt, immer dann gerufen zu werden, wenn es Probleme gibt, bringt diese Unentbehrlichkeit auch negative Seiten mit sich. Einem solchen Entwickler wird die Möglichkeit genommen, sich weiter zu entwickeln. Er bleibt auf der aktuellen Position sitzen, weil er ab und zu an dieser Stelle dringend gebraucht wird. So wie Rambo in Friedenseiten langsam zu einem Relikt aus alten Zeiten wird, geht es auch diesen Entwicklern. Und wenn die Systeme des Entwicklers sterben, so stirbt auch der Entwickler mit ihnen. Und wie John Rambo in Thailand, möchte ein Entwickler sich später einmal neu orientieren. So lange er in seinem alten Job nicht entbehrlich geworden ist, wird er dort immer zu jeder Tages- und Nachtzeit gerufen werden.

Falls Sie also ein „unentbehrlicher” Entwickler sind, lauet mein Rat an Sie: „Seien Sie nicht John Rambo, machen Sie sich entbehrlich.

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.

23 Dinge #0: Menschen

0

Bevor ich über 23 Dinge blogge, möchte ich noch einen Artikel voran stellen, der die folgenden Artikel meiner Serie in einen entsprechenden Kontext setzt. Sie bekommen hier sozusagen einen Tipp, wie Sie die folgenden Tipps anwenden sollten.

Beginnen möchte ich mit einem Yogiism von Dale „Yogi” Berra, einem der erfolgreichsten Baseball-Spieler der US-Major League:

„In theory, there is no difference between theory and practice. In practice, there is.”

Frei übersetzt bedeutet dies so viel wie:

„In der Theorie sind Theorie und Praxis das selbe, in der Praxis sind sie es nicht.”

Meine 23 Dinge, die Sie über Software-Entwicklung ins Teams wissen sollten, entspringen zwar meiner praktischen Erfahrung, aber in diesem Blog werden sie auf Theorien reduziert. Die Tipps haben mir in den Teams, in denen ich bereits gearbeitet habe (sowohl in geschäftlichen, als auch im Open Source Umfeld), wertvolle Dienste geleistet. Das bedeutet jedoch nicht zwangsläufig, dass diese Tipps sklavisch bei Ihnen angewendet werden sollten. Manche Tipps müssen vielleicht an ihr Umfeld angepasst werden, andere funktionieren in Ihrem Umfeld überhaupt nicht.

Sobald Sie von Teamarbeit sprechen, sollten Sie nicht vergessen, dass es dabei auch immer um Menschen geht. Die Menschen sollten immer im Mittelpunkt Ihrer Bemühungen stehen, denn sie sind es, die Ihr Team formen und am Ende die Software produzieren.

Und Menschen sind nun mal verschieden. Also sind auch Teams verschieden und werden nicht genau gleich auf die Tipps in dieser Artikelserie reagieren. Achten Sie also beim Umsetzen der Tipps darauf, dass Ihnen nicht der Fehler auf diesem Poster passiert:

Conformity - It's the one who is different, that get's left out in the cold.

Schätzen Sie die Unterschiedlichkeit Ihres Teams und wenn ein Tipp nicht zu Ihnen oder Ihrem Team passt, dann passen Sie ihn an. Dieses Poster hängt im Büro übrigens auch in DIN A1 an meiner Wand, um mich und andere jeden Tag daran zu erinnern.

Don’t assume!

1

Manche Weisheiten sind so einfach, dass man sie immer wieder vergisst. Aus diesem Grund hänge ich mir solche gerne bei mir im Büro an die Wand, damit ich regelmäßig mit der Nase drauf gestoßen werden.

In regelmäßigen (oder wahrscheinlich eher unregelmäßgen) Abständen werde ich diese jetzt auch in meinem Blog posten. Ihr findet diese Artikel dann alle unter dem Tag „An meiner Wand”. Den Anfang macht heute die folgende Weisheit von Oscar Wilde:

Don’t assume – it makes an «ass» of «u» and «me».

Auf den ersten Blick klingt das in der Software-Entwicklung etwas seltsam, da wir alle wissen, dass in kaum einem Software-Entwicklungsprojekt immer alle Anforderungen klar auf dem Tisch liegen. Dabei bleibt uns als Entwicklern oft nichts anderes übrig, als Annahmen zu treffen.

Wichtig ist aber, dass man sich in solchen Moment bewusst sein muss, wo man nur Annahmen trifft. Sonst macht man ganz plötzlich Annahmen, von denen man annimmt, dass es Fakten sind. Und nichts ist schlimmer, als Annahmen über Annahmen zu treffen.

Und genau da beginnt das Problem. Sie treffen Entscheidungen auf Basis von Fakten, die nur in Ihrer Vorstellung existieren. Typische Annahmen, die zu Problemen führen sind:

  • „Ich denke nicht, dass der Kunde diese Anforderung nochmal ändern wird. Die ist in Stein gemeißelt.”
  • „Unsere Applikation ist so langsam, weil wir Datenbank XXX verwenden, wir müssen stattdessen die Datenbank YYY einsetzen.”

Während die erste Annahme dazu führt, dass Sie dem Kunden Flexibilität nehmen, investieren Sie bei der zweiten Annahme Zeit und Aufwand in eine Optimierung, die unter Umständen unnötig ist. Damit landen Sie nämlich bei Premature Optimization, und darüber hat Donald Knuth mal gesagt:

Premature optimization is the root of all evil.

Bevor Sie also annehmen, dass ein Kunde eine Anforderung in Stein gemeißelt hat und darauf hin eine Architektur-Entscheidung treffen, sprechen Sie doch lieber mit dem Kunden darüber. Erklären Sie ihm zur Not auch, welche Vor- und Nachteile hat, wenn er genau diese Anforderung unumstößlich festlegt und Ihnen damit eine bestimmte Architekturentscheidung ermöglicht.

Und bevor Sie annehmen zu wissen, wo das Performance-Problem Ihrer Anwendung liegt, fragen Sie doch einfach einen Profiler und stützen Ihre Entscheidungen auf Fakten.

23 Dinge über Software-Entwicklung in Teams

1

Auf der PHP World 2009 in München habe ich einen Vortrag mit dem Titel „23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten” gehalten.

Der Vortrag war gut besucht und ein voller Erfolg. Um die Inhalte einer breiteren Öffentlichkeit zugänglich zu machen, werde ich in den nächsten Wochen jedes der 23 Dinge heraus greifen und in einem Eintrag in meinem Blog genauer betrachten. Eine feste Timeline gibt es dafür nicht, genau so könnte es sein, dass ich die Reihenfolge vom Vortrag abweichen wird.

nach oben