Archiv der Kategorie: Buch Review

Gelesene Bücher 2012

Hallo zusammen,

2012 ist extrem lesereich, und da mir einige Bücher wirklich extrem gut gefallen haben würde ich euch gerne daran teilhaben lassen.






War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

Top-10 – Bücher die mich dieses Jahr inspiriert haben

Hi,

das Jahr ist zwar noch nicht vorüber, trotzdem möchte ich euch schonmal meine Top-10 Bücher 2011 vorstellen.

Pragmatic THinking and Learning

Das Buch ist spitze. Das Buch hat es tatsächlich geschafft, mich zu inspirieren. Totale Leseempfehlung.


The Naked Presenter: Delivering Powerful Presentations with or without Slides

Bisher besters Buch von Garr. Und das will was heißen.

Steve Jobs – A Biography

Ob man Steve Jobs mag oder nicht, das Buch ist eine definitive Lesempfehlung. Man erfährt viel über Apple und Steve, aber mindestens eben so viel über Design und worauf es wirklich ankommt. Das Buch hat mich tief beeindruckt.

Confessions of a Public Speaker

Man merkt, dass Scott Berkun weiß, wovon er spricht. Ich habe selten ein so amüsant zu lesendes Buch in der Hand gehabt. Definitive Kaufempfehlung.

Coding

Eines der besten Softwareenticklungsbücher die ich bisher gelesen habe, kurz prägnant auf den Punkt. Ich hab das Buch schon zweimal gelesen und kann nur dringend empfehlen, hier einen Blick rein zu werfen.

Clean Coder

Zu Uncle Bob Martin muss man nichts sagen. Das Buch sollte jeder unter sein Kopfkissen legen. Echt jetzt!!

97 Things every Programmer should know

Sehr amüsant und lehrreich.


Presentation Zen Design: Simple Design Principles and Techniques to Enhance Your Presentations

Garr Reynolds in Hochform. Spitzenbuch!

Your Brain at work

Hochinteressant und amüsant geschrieben. Das Buch ist echt lesenswert.

Founders at work

Hochinteressante Geschichten – lesenswert.


War dieser Blogeintrag für Sie interessant? Evtl. kann ich noch mehr für Sie tun.

Trainings & Know-How aus der Praxis zu

  • Apache Wicket 1.4.x, 1.5.x, 1.6.x
  • GIT – Best Practices, Einsatz, Methoden
  • Spring
  • Java
  • Scrum & Kanban
  • Agiles Arbeiten
Consulting & Softwareentwicklung

  • Requirements Engineering
  • Qualitätssicherung
  • Software-Entwicklung
  • Architektur
  • Scrum & Kanban

„Ein Scrum Team sollte genau so groß sein, dass man es mit zwei Pizzas satt bekommt“ – Buch Rezension Succeeding with Agile

Hallo zusammen,

die in den letzten beiden Einträgen erschienenen Hinweise auf Artikel im Java Magazin sind ja mittlerweile erschienen, auch die Buch-Rezension für das Buch „OSGi für Praktiker“ ist mittlerweile abgegeben und wird wohl demnächst erscheinen.

Heute würde ich gerne eine kleine Rezension für ein Buch schreiben, das ich vor einiger Zeit gelesen habe und das mich tatsächlich begeistert hat.


Succeeding with Agile – Autor Mike Cohn

Diejenigen die bereits Bücher von Mike Cohn gelesen haben, werden mir beipflichten, dass dieser sein Handwerk versteht und DInge oft direkt anspricht und so klarheit in viele Fragestellungen bringt.

Das vorliegende Buch ist mit Sicherheit das beste zum Thema Agiles Projektmanagement aller Bücher, die ich bisher zu diesem Thema gelesen habe (und das sind mittlerweile wirklich schon einige).

Gleich zu Beginn betont Mike, dass Scrum einzuführen und zu leben wirklich schwierig ist, weil

  • Scrum DInge verändert und Veränderungen erfordert
  • Scrum Fehler aufdeckt
  • Scrum nicht nur Bottom-Up (vom Entwickler getrieben) oder Top-Down (Managementgetrieben) funktioniert
  • Scrum-Adoptionen niemals abgeschlossen sind, sondern ein fortlaufender Prozess

Natürlich betont er in gleicher Weise, dass sich die Mühe dennoch lohnt, und zwar u.a. deswegen weil:

  • Man mit Scrum schneller Produkte für den Markt liefert.
  • Qualität und Motivation der Arbeit und aller Beteiligten steigt

Was mir sehr gut an dem Buch gefällt sind die auf diversein Seiten eingestreuten Hinweise á la „Things to do now“, hier empfiehlt der Autor Dinge, die man direkt anpacken kann, um die Scrum-Adoption zu verbessern. Dies sind beispielsweise Hinweise wie „Hänge noch heute ein Improvement Backlog“ in euerm Team-Büro auf.

Im Kapitel 2 geht Mike auf das ADAPT-Prinzip ein (Awareness, Desire, Ability, Promotion, Transport).

Was bedeuten aber jetzt die einzelnen Punkte?

Awareness?

Man muss sich, wenn man versucht agil zu arbeiten (und ganz besonders, wenn man versucht mit Scrum zu arbeiten) sehr früh bewusst sein, dass es überhaupt ein Problem in der Organisation oder im Vorgehensmodell gibt. Ist man sich dessen nicht bewusst, würde man wahrscheinlich erst gar nicht versuchen, Scrum zu adaptieren.

Buzzword hier ist „Selling the Problem, not the Solution“. Das heisst, um einen Lösungsansatz erfolgreich vermarkten zu können, muss zunächst mal „Werbung“ für das Problem gemacht werden, Bewusstsein geschaffen werden. Ist dies möglich, werden viele Unternehen gerne bereit sein, zumindest den Versuch zu wagen, Agile Vorgehensweisen auszuprobieren.

Desire?

Um erfolgreich agil arbeiten zu können, muss man den unbedingten Willen haben, erfolgreich zu sein und hierfür auch etwas zu tun. Der Autor nennt hier eine sehr schöne Analogie: Er meint, er sollte mehr Gemüse essen, ist sich auch der Notwendigkeit bewusst, aber ihm fehlt einfach der Wille, das auch wirklich durchzusetzen“. Gefällt mir.

Ability?

Um Agile Techniken etablieren zu können, muss man die entsprechenden Möglichkeiten hierzu schaffen.

Zum Einen muß man sich persönlich fähig fühlen, diese Herausforderung anzunehmen und zu meistern, zum Anderen müssen natürlich auch die Rahmenbedingungen stimmen, das heißt, das Umfeld muß eine Adaption von Agilen Techniken zulassen.

Transer?

Was bedeutet Transfer von Scrum? Transfer bedeutet, dass Scrum weit genug in alle Teilbereiche eines Unternehmens transportiert werden muss. Es ist enorm schwierig, Scrum nur in Teilbereichen eines Unternehmens zu etablieren (das kenne ich zur Genüge). Am besten funktioniert eine Adaption, wenn alle mitziehen.

Wieder schafft es der Autor, mit einer sehr schönen Analogie das Konzept zu erläutern:

Transfer von Scrum kann mit einer Rakete verglichen werden. Deren Antrieb muss die Rakete weit genug bis in den Orbit transportieren, damit eine Weltraummission erfolgreich sein kann. Funktioniert dies nicht, wird die Mission scheitern. (Cohn nennt dies Organizational Gravity, sehr schön)

Weiter geht es bei Cohn mit den sogenannten Scrum Adoption Patterns:

Es gibt verschiedene Patterns um Scrum zu adaptieren, Cohn nennt hier u.a. den Start-Small Pattern, das bedeutet, man startet mit 1-2 Teams und vergrößert die Anzahl agiler Arbeiter immer weiter, bis irgendwann hoffentlich das ganze Unternehmen agil ist.

Ein weiteres Pattern ist das ALL-IN-Pattern, dies ist das genaue Gegenteil von Start-Small – hierbei wird in einem Big-Bang eine Voll-Adoption von Scrum mit allen verfügbaren Entwicklerteams vollzogen.

Natürlich muss bei beiden Pattern genau abgewogen werden, welche Art und Weise am besten zum jeweiligen Unternehmen passt. Das Start-Small Pattern eignet sich natürlich am besten für Unternehmen, die sich selbst noch gar nicht 100% sicher sind, ob sie Scrum überhaupt adaptieren möchten. So kann man auf sehr einfache Art und Weise die Produktivität, Qualität der Arbeit und Motivation der gescrummten Teams mit denjenigen Vergleichen, die noch auf die althergebrachte Art und Weise arbeiten.

Die Big-Bang-Lösung hilft natülich bei einer schnelleren Adaption von Scrum, aber natürlich mit allen Problemen, die dadurch entstehen – Schwierigkeiten bei der Umsetzung, viel Veränderung in kurzer Zeit, mögliche Entwickler, die nicht mitziehen möchten. Trotzdem wäre das Big-Bang-Pattern mein Pattern der Wahl, da es meiner Ansicht nach essentiell wichtig ist, den Prozess mit möglichst allen Entwicklern, Abteilungen, Projektmanagern zu etablieren.

Cohn beschreibt noch weitere Patterns, und zwar wie man mit frischen Teams umgehen kann und so Scrum besser verbreitet:

Split and Seed –  Hierbei beschreibt Cohn die Möglichkeit, Erfahrene Scrum-Entwickler aus einem Scrum-Team herauszunehmen und als „Grundstein“ für neue Scrum-Teams mit unerfahrenen Entwicklern zu benutzen. Auf diese Art und Weise können neue Teams etabliert werden. Natürlich geht dies mit einem Performanceverlust einher, da neue Teams sich erst zusammenfinden müssen und auch unerfahrene Entwickler erst an das Thema herangeführt werden müssen.

Grow and Split – Dieses Pattern beschreibt die Vorgehensweise, Teams immer mehr wachsen zu lassen, bis sie schließlich zu groß für ein einziges Scrum-Team sind, und diese großen Teams anschließend zu splitten und zwei Teams daraus zu machen, usw. usw.

Ich persönlich bin mir da nicht so sicher, ob ich mit Herrn Cohn übereinstimme. Aus meiner praktischen Erfahrung kann ich sagen, dass Scrum Teams ungefähr 2-3 Sprints brauchen, bis sie wirklich performant zusammenarbeiten. Das Gefühl für ein Team muss sich wirklich erst entwickeln, die Teammitglieder müssen lernen, sich aufeinander einzustellen.

Cohn vertritt die Einstellung, dass es durchaus möglich und manchmal sogar erwünscht ist, funktionierende Teams zu splitten. Darüber würde sich vortrefflich diskutieren lassen.

Cohn betont ausserdem, dass es enorm wichtig ist, sich niemals auf seinen Lorbeeren auszuruhen, d.h. man sollte niemals darauf verzichten, neue Techniken (XP, Pairprogramming, TDD oder auch Techniken auf der Projektmanagementebene) auszuprobieren. Teams lernen sonst durch Scrum lediglich das inkrementelle Arbeiten. Inkrementelles Arbeiten ist aber nicht agiles Arbeiten.

Cohn führt hier das sehr interessante Beispiel von Shamrock Foods an, hier wurde tatsächlich auf der Ebene des Projektmanagements versucht, zumindest eine Art Scrum einzuführen, und zwar ganz ohne Softwareentwicklung (hier sieht man, dass Scrum zwar oft mit Softwareentwicklung in Verbindung gebracht wird, aber nicht zwingend darauf beschränkt werden muß).

Shamrock Foods hat einen 5-Jahres Plan aufgestellt, um ihr Management und ihr Produkt in Viertel-Jahres-Sprints zu verbessern. Die zuständigen Manager haben sich hier am Ende des Sprints off-site in einem Hotel getroffen und quasi eine Retrospektive des vergangenen Sprints durchgeführt. Der Titel eines Artikels hierzu lautet „Should you build Strategy like you build Software“, leider habe ich diesen nirgendwo gefunden, aber dieser ist bestimmt sehr lesenswert.

Das erste Projekt

Cohn stellt hier eine interessante Tabelle bereit, und zwar geht es um die Ängste verschiedener „Schichten“ in einem Projekt, wenn es um die Einführung von Scrum geht. Entwickler haben beispielsweise folgende Ängste in sortierter Reihenfolge:

  1. Mangelndes Bewusstsein
  2. Angst vor Unbekanntem
  3. Angst um den Job
  4. Angst vor Aufwand

Ängste des Managements sind folgende in sortierter Reihenfolge:

  1. Kontrollverlust (DAS ist meiner Ansicht nach einer der größten Probleme)
  2. Zeitverlust
  3. Bequemlichkeit
  4. Scrum bietet keine Antwort auf die Frage „Was ist für mich drin“

Weiterhin teilt Cohn alle Projektbeteiligten in verschiedene Gruppen ein:

  • Pragmatiker – Pragmatiker akzeptieren und praktizieren changes, hören sich Argumente an
  • Konservative – Konservative möchten gerne aktuelle Strukturen behalten, Bestpractices und Vorhersagbarkeit
  • Vorstösser – Rütteln an bestehenden Strukturen, Wollen Veränderung

Cohn bietet natürlich auch eine Definition verschiedener Rollen, die ich hier nicht wiederhole, da diese sich mit der bekannten Definition deckt. Was ich hier erwähne sind eine markante Sätze aus dem Buch zu den jeweiligen Rollen:

Scrum-Master: „Scrum-Master hat Verantwortung ohne Macht“, „Scrum-Master sagen nicht, schau was ich erreicht habe, sondern schau was ich geholfen habe zu erreichen“,“Scrum-Master comitten sich genauso wie jedes andere Teammitglied“.

Techleads: Techleads können laut Cohn durchaus Scrummaster sein, aber nur wenn sie die persönlichen Skills mitbringen.

ProductOwner: Jedes Team sollte laut Cohn einen eigenen haben, da der PO die Vision des Produktes vorantreibt, ein PO sollte folgende Attribute mitbringen:

  • A(vailable) – Er sollte für das Team erreichbar sein
  • B(usiness Savy) – Ein PO kennt sein Business
  • C(ommunicable) – Er muß kommunikationsfreudig sein
  • D(ecisive) – Er muß fähig sein, Entscheidungen zu treffen
  • E(mpowered) – Er muß die Kraft haben, für sein Produkt einzustehen.

 

Technical Challenges – hier sind einige Perlen aus dem Buch

„Jedes Stück Code das man produziert sollte qualitativ so hochwertig sein, dass man es sich ausdrucken und zu Hause an den Kühlschrank hängen möchte“ – Ein sehr schöner Satz, der viel über Code-Quality aussagt.;)

Ein weiterer schöner Spruch kommt von den BoyScouts of America : „Leave every Place a little bit cleaner than you found it“ – bezogen auf Code eine Perle;).

Collective-Code-Ownership ist wichtig – denn Code den jeder sieht tendiert dazu, sauberer zu sein – Analogie „Was hält man sauberer, das Bad das jeder sehen kann oder das Bad im Keller, das alle paar Monate mal benutzt wird?“

Fazit:

Das Buch ist eine Perle und hat sich einen festen Platz auf meinem Schreibtisch verdient. Selten habe ich so treffende Worte zum Thema Scrum gelesen. Meine Empfehlung lautet unbedingt kaufen und lesen!

 

Buchreview – Making it Big in Software

Ich habe soeben das Buch „Making it Big in Software“ fertig gelesen, und möchte an dieser Stelle eine einfache Zusammenfassung geben.

Das Buch versucht, eine allgemeine Beschreibung zu geben, was ein Software-Entwickler in der heutigen Zeit für Fertigkeiten mitbringen sollte, um im Daily-Business zu bestehen. Der Ansatz der im Buch verfolgt wird ist durchaus interessant, da viele Interviews mit Größen der Branche zu finden sind (Linu(x)s Torvalds, James Gossling, Steve Wozniak), in denen interssante Fragen zur Sprache kommen (Wie bist du zur Softwareentwicklung gekommen, was machst Du um Dich nach der Arbeit zu entspannen…), die tatsächlich hochinteressant zu lesen sind.

Natürlich wird man als gestandener Softwareentwickler keine wirklichen Neuigkeiten erfahren, man hat alles irgendwie schon mal gehört, jedoch ist das Buch weiterhin mit amüsanten Geschichten gespickt (die von der stumpfen Säge und dem Baumfäller).

Das zweite Kapitel dreht sich um das Thema „Worum es bei guter Software wirklich geht“

Hier dreht es sich hauptsächlich darum, was gute (im Sinn von erfolgreicher) Software wirklich ausmacht, und welche Kriterien eine Software kommerziell erfolgreich machen. Interessant hierbei ist eine Statistik die die erfolgsraten von Softwareprojekten zwischen den Jahren 1994 und 2004 betrachtet. Im Schnitt sind demnach ein Drittel aller Entwicklungsprojekte Fehlschläge, ein Drittel wird mit Verzug fertiggestellt und nur ein Drittel ist tatsächlch erfolgreich. Ganz schön harter Tobak.

Weiterhin wird erläutert, dass nicht immer das, was ein Kunde will, auch das ist, was er wirklich braucht. Ein sehr schöner Satz von Henry Ford, der hier erwähnt wird ist „If I had listened to customers, I had given them faster horses„. Sehr schön!

Ein weiterer interessanter Aspekt des Autors sind die Dinge, die man am Beginn seiner Software-Karriere lernen sollte:

  • 4 verschiedene Programmiersprachen (ich kann u.a. Java, PHP, Javascript, Scala… reicht das schon?)
  • 4 verschiedene Formate (ups, XML, das Git Packfile Format, XSL, XSLT.. naja)
  • Entwickle Software die mindestens von 1000 Leuten verwendet werden kann / verwendet wird (hab ich schon)
  • Software die mindestens 1 TB an Daten verarbeiten kann (hm, müss
  • te ich mal überlegen)
  • Arbeite in einem Projekt mit mehr als 10 ENtwicklern (hab ich bzw. tu ich gerade)
  • Arbeite an Legacy Code (ich mach nichts anderes)
  • Fixe 40 Bugs (mach ich an einem Tag;))
  • etc…

Ein weiterer interessanter Aspekt der im Buch beschrieben wird sind die verschiedenen Bereiche, in denen ein Entwickler aktiv werden sollte:

  • Wichtig und Zeitkritisch
  • Zeitkritisch aber nicht wichtig
  • Weder Zeitkritisch noch wichtig
  • Wichtig aber nicht zeitkritisch

Laut dem Autor ist Wichtig aber nicht zeitkritisch der BEreich, in dem ein Entwickler so viel Zeit wie möglich verbringen sollte.

Ein für mich sehr interessantes Kapitel war das Kapitel über Zeitmanagement. Der Autor unterscheidet hier zwischen Zielorientiertem Zeitmanagement und Taskorientiertem Zeitmanagement.

  • Zielorientiertes Zeitmanagement beschäftigt sich mit einer langfristigen Planung (man setzt sich Ziele und legt die entsprechenden Schritte fest, um diese Ziele zu erreichen)
  • Taskorientiertes Zeitmanagement ist unser aller täglich Brot, man bekommt täglich irgendwelche Tasks zugewiesen und bearbeitet diese typischerweise zeitnah.

Fazit:

Ein für mich durchaus lesenswertes Buch, teilweise sogar richtig amüsant. Ich kann das Buch sehr empfehlen, allerdings muss man mit der richtigen Eintsellung an das Buch herangehen, man darf sich hiervon nicht ungeahnte Karriereschübe oder ähnliches erwarten, viel mehr ist es eine recht interessante Ansammlung von Anekdoten, Zitaten und Weisheiten.