Dienstag, September 23, 2008

Ivar Jacobson über die Zukunft der Softwareentwicklung

The future of software development practices.

Post bewerten

Dienstag, September 09, 2008

Hossa: Acrobat Reader

Ich komme gerade an meinen Rechner zurück und unten rechts blinkt ein kleines Popup, in dem steht: "Acrobat Reader wurde durch den Datenausführungsverhinderer geschlossen. [..]"

Da musste ich eine Weile drüber nachdenken, was das bedeuten soll. Und ganz sicher bin ich mir immer noch nicht.

Post bewerten

Montag, September 08, 2008

WerKannWann mit Uhrzeiten

it-agile hat ein neues Release von WerKannWann veröffentlicht. Mit WerKannWann kann man Terminumfragen über das Internet durchführen und Termine auch dann abstimmen, wenn nicht alle Beteiligten an eine gemeinsame Infrastruktur wie MS-Outlook angeschlossen sind.
WerKannWann ist nicht die erste Anwendung dieser Art. Von der Konkurrenz unterscheidet sich WerKannWann aus meiner Sicht durch:
  1. Uhrzeiten werden direkt zu jedem Termin hinterlegt und nicht im Block, wenn man alle möglichen Termine beisammen hat. Das macht die Arbeit flüssiger. Schließlich beginne ich das Eintragen der Termine normalerweise während ich in meinen Kalender gucke. Wenn ich erst alle Termine auswähle und dann die Uhrzeiten, muss ich für die Uhrzeiten wieder im Kalender zurück und dort die Tage suchen, die ich eingegeben habe.
  2. Man muss die Uhrzeiten nicht umständlich eintippen, sondern kann sie mit coolen Slidern definieren.
  3. Der Service ist nicht werbefinanziert und sendet daher möglicherweise intime Infos aus der Terminumfrage nicht an Google und blendet auch keine Werbung ein. Bei einem der Konkurrenten kann es schon mal passieren, dass man mit einem Kunden einen Termin für eine Scrum-Schulung aushandeln will und die Teilnehmer an der Terminabstimmung die Scrum-Schulungen der Konkurrenz angezeigt bekommen.
  4. Die Teilnehmer an der Terminumfrage können nicht nur "ja" oder "nein" anwählen, sondern auch "wenn es sein muss". Das ist nützlicher als es erscheint, weil viele Teilnehmer "nein" anwählen, wenn der Termin nicht so gut passt. Möglich wäre er aber trotzdem gewesen.
  5. Nach meinem subjektiven Empfinden liegt WerKannWann besser in der Hand als die konkurrierenden Services, die ich so kenne.
Also: Einfach mal ausprobieren. Wir freuen uns über Nutzer und über Feedback.

Post bewerten

Freitag, September 05, 2008

Software-Putzer?

Nico Josuttis schreibt in seinem Blog über Software-Putzmänner und die nächste IT-Revolution. Er schlägt darin vor, schlechte Softwarequalität einfach als Fakt hinzunehmen und nicht immer zu versuchen, die Qualität zu verbessern. Vielmehr ginge es darum, mit dieser schlechten Qualität umzugehen. Als eine mögliche Alternative schlägt er Software-Putzkolonnen vor, die hin und wieder kommen und dann im Code aufräumen.

Dazu fallen mir gleich ein paar Sachen ein.

Zuerst zum Akzeptieren schlechter Qualität: Wenn die Qualität wirklich schlecht ist, wirkt sich das mannigfaltig unangenehm aus. Selbst der Product Owner bemerkt es. Nicht nur durch die langsame Entwicklungsgeschwindigkeit sondern auch dadurch, dass er aus technischen Gründen seine Priorisierungen ändern und seine Stories anders aufschreiben muss.

Und ich habe auch gerade ein aktuelles Projektbeispiel zur Hand, dass sich das Aufräumen lohnt. Beim Kunden dümpelte ein Team bei 30 Story Points je Sprint rum. Irgendwann hat das Team festgestellt, dass umfangreichere Refactorings im Bereich CSS notwendig sind, um schneller zu werden. Sie haben die Refactorings in Angriff genommen und die haben viel länger gedauert als zunächst gedacht - das ist nach meiner Erfahrung fast immer so bei größeren Refactorings. Aber sie haben es durchgestanden, obwohl es sogar soweit ging, dass nicht mehr alle Entwickler während des Sprints beschäftigt werden konnten. Nach dem Refactoring hat die Geschwindigkeit des Teams deutlich zugelegt. Heute liegt die Geschwindigkeit bei 80 Story Points je Sprint.
Mindestens in diesem Fall hat sich das Aufräumen schnell gelohnt und es wäre finanzieller Irrsinn gewesen, das Refactoring nicht durchzuführen.

Und zu den Putz-Kolonnen kann ich gleich zwei Erfahrungen beisteuern.
Erstens: Wir hatten bei it-agile mal so ein Dienstleistungsprodukt im Angebot. Das war ein Ladenhüter. Daher gibt es das jetzt nicht mehr als explizites Produkt bei uns. Wenn jemand sich dafür interessiert, beleben wir es aber jederzeit gerne wieder :-)
Zweitens: Wir hatten in einem Projekt mal sowas wie eine Putz-Kolonne in ganz zarten Ansätzen. Das hat in meinen Augen nicht funktioniert. Zum einen liefern die Projekte dann noch schlechtere Qualität - die Putz-Kolonne wird es schon richten. Zum anderen musste die Putz-Kolonne ständig bei den Entwicklern nachfragen, was bestimmter Code bedeutet. Und damit wurde das Team dann doch wieder mit Putzarbeiten belastet.

Langer Rede kurzer Sinn: Ich vertrete genau den konträren Ansatz. Wir als Entwickler sind für die technische Qualität des Systems verantwortlich. Wer schlechte technische Qualität abliefert, verstößt aus meiner Sicht gegen den Code of Ethics unserer Zunft und sollte sich was schämen. Niemand wird uns die Zeit und das Geld zum Aufräumen geben und die Putz-Kolonne wird auch nicht kommen. Wir als Entwickler müssen die Sache selbst in die Hand nehmen und zu unserer Verantwortung stehen!

P.S.: Zum Code of Ethics: Punkt 3 lautet: "PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible." Das bedeutet meiner Meinung nach auch, hohe Qualität abzuliefern.

P.P.S.: Wer mehr darüber erfahren möchte, wie guter Code für agile Entwicklung aussieht und wie man den schreibt: ich werde auf der OOP darüber einen Vortrag halten.

Post bewerten

Mittwoch, September 03, 2008

Priorisierung von Features

mal eine neue nette Idee zum Thema von David Anderson

Post bewerten