Projektmanagement

0

10mal täglich deployen – am Beispiel von Flickr

Veröffentlicht am von danny quick

Ich habe auf Slideshare eine interessante Präsentation zum Thema Deployment gefunden. Interessant aus zwei Aspekten. Zum einen, da wir uns derzeit auch mit dem Thema “Releasemanagement” auseinandersetzen und zum anderen, weil Flickr laut der Präsentation zehn Mal pro Tag deployed! Das halte ich persönlich für eine starke Leistung, die sicherlich gut vorbereitet wurde.

In der Präsentation geht Flickr auf die technischen Aspekte ein, die ich interessant finde. Hier kann man sich sicherlich noch die ein oder andere Anregung holen. Das wirklich Spannende liegt aber wieder mal in der Zwischenmenschlichen Kommunikation der Beteiligten – nämlich der Entwickler und der Administratoren. Die zentrale Botschaft lautet hier:

Schaffe eine Kultur, die von Respekt, Vertrauen und einer gesunden Einstellung zu Fehlern geprägt ist und in der das Thema “Schuldzuweisung” ein Fremdwort ist. Nur so können die Entwickler und Administratoren an einem guten Geschäftsergebnis mitwirken.

Dann sind die restlichen technischen Spielereien nur Administrivialitäten:

  1. Vorbereiten der Infrastruktur mittels einer großen Anzahl von Tools wie beispielsweise CFengine,  Bcfg2,  System Imager, Cobbler etc.
  2. Geteiltes Wissen zum Versionsstand.
  3. Automatisierung von Build und Deployment.
  4. Einsatz von Feature flags und private Betas, arbeiten im Trunk.
  5. Visualisierung des Systemzustandes und der Einsatz von Metriken.
  6. Informationsaustausch der Entwickler und der Administratoren.

Die Präsentation ist auch optisch ein echter Hingucker – also viel Spaß damit.

8

Agile Softwareentwicklung – eine weitere Lanze gebrochen

Veröffentlicht am von danny quick

lanzeAgile Softwareentwicklung scheint nun endlich aus den Kinderschuhen zu sein. Wenn selbst eine Firme wie Microsoft sich bei der Entwicklung von Windows 7 auf dieses Vorgehen festlegt. So ist es derzeit bei Spiegel-Online nachzulesen. Die Redmonder setzten vor drei Jahren auf das Thema Extreme Programming und versuchten dadurch die Fehler der Vergangenheit zu vermeiden.

So ist Microsoft neben Google und ebay ein weiteres großes Unternehmen, das auf Agilität in der Softwareentwicklung setzt.  Dass ich ein großer Freund von Agilen Methoden bin, hat der ein oder andere vielleicht bereits bemerkt. Für mich der Schlüssel zu guter Software, da wir uns in kleinen Schritten dem Ziel nähern. Leider kenne ich aber immer noch Unternehmen, die strikt nach den Phasen der Softwareentwicklung (Analyse, Design, Realisierung und Test) eine SAP-Einführung planen.

Das große Problem dabei entsteht, durch die Aussicht alles Technische umsetzen zu können  und die Softwareentwicklung wie den Bau eines Hauses zu sehen.  Zumindest hat Microsoft damit eine weitere Lanze für agile Softwareentwicklung gebrochen. Ich hoffe andere Unternehmen folgen dem Beispiel und lassen die Phasenmodelle dort wo sie hingehören – in die 70er und 80er.

0

Von Risiko- und Krisenmanagern

Veröffentlicht am von danny quick

Ich habe eben im Guerilla Projektmanagement Blog einen Beitrag zum Thema „Fehler die Showstopper sind“ gelesen, der mich dazu bringt, dieses Problem in der Firmenkultur nochmal zu thematisieren.

Wie Sven Rimbach in seinem Beitrag erwähnte, gibt es eben Fehler die vor Projektende das gesamte Projekt aus dem Zeitplan werfen.  Hätte man sich also vorher damit auseinander gesetzt, welche Fehler den Projekttermin gefährden, wären sie vermutlich auch nicht in der Ausprägung aufgetreten. Ein einfaches Ursache-Wirkung-Prinzip.

Warum verzichten dennoch so viele Projekte auf eine Top-10 Risikoliste? Ganz einfach, schon in der Antike wurde der Überbringer schlechter Nachrichten geköpft. Also werden die Risiken zwar wahrgenommen, aber ignoriert. Stattdessen werden Pläne ausgearbeitet, wie die aufgetretenen Probleme beseitigt werden können. Die Beteiligten glauben vermutlich sogar sie würden ihre Risiken managen.

So ist es vielleicht an der Zeit den Unterschied einmal deutlich zu machen. Tom DeMarco beschreibt im Buch Bärentango die Begriffe wie folgt:

“Ein Risiko ist ein Problem, das erst noch auftreten muss, und ein Problem ist ein Risiko, das bereits aufgetreten ist.”

Tatsächlich ist da viel Wahrheit dran. Denn jemand er in einem Projekt die ganze Zeit den Teufel an die Wand malt und die “tolle Stimmung” zerstört, der ist nicht gut angesehen. Aber jemand der die fertigen Pläne in der Schublade hat, wenn das „Kind erst in den Brunnen gefallen ist“, wird als Krisenmanager gefeiert.

Jedenfalls ist das der bequemere Weg – solange niemand die Ursachen hinterfragt.

0

Scrum-Anti-Patterns

Veröffentlicht am von danny quick

rugby

Eben erst hatte ich Zeit mir die neue  iX anzusehen und mir spring sofort der Artikel auf Seite 110 in die Augen. Ein Beitrag über agile Softwareentwicklung speziell mit Scrum – insgesamt lesenswert. Was mir aber besonders gefallen hat, ist die Liste der Scrum-Anti-Patterns:

  1. Der Scrum Master weist Aufgaben zu und zerstört so das sich selbst steuernde und organisierende Team.
  2. Der Sprint wird von außen gestört. Es werden neue Aufgaben eingefügt oder Änderungen an den gewählten User Stories vorgenommen.
  3. Es finden keine Review Meetings statt.
  4. Es findet keine Retrospektive statt.
  5. Es gibt keine regelmäßigen Daily Standup Meetings.
  6. Der Product Owner hat keine ausreichende Kompetenz und nimmt seine Rolle nicht wahr.
  7. Es gibt kein „1 to 1 Agreement“, also keine persönliche Vereinbarung zwischen dem Product Owner und dem Team.
  8. Die Beteiligten sind nicht ausreichend geschult.
  9. Meetings sind nicht Timeboxed.
  10. Anstatt Features werden Aktivitäten erfasst.
  11. Man schickt ein paar Scrum Master zum Training und denkt, nun werde alles gut.

Diese Liste ist bei weitem noch nicht vollständig. Mir fallen da spontan noch ein paar Ding wie „Bug-fix Sprints“ oder die aktive Beteiligung des Management am Daily Scrum ein.

Fallen Ihnen vielleicht noch ein paar schöne Scrum-Anti-Patterns ein? Ich bin gespannt.

(Bildquelle: Stock Exchange, johnmckeag)