Dienstag, 27. Oktober 2009
Der nächste Schritt - Personas
Mein erster Schritt sollte es sein, Personas zu erarbeiten. Für mich ein unerlässliches Arbeitsmittel über den gesamten Zeitraum der Entwicklung habe ich ihm dieses Arbeitsmittel clever verkauft. Quasi als Anbieter der Software habe ich nicht vorgeben, dass wir mit Personas arbeiten, dass wir damit arbeiten, warum bla bla bla...
Mir war es wichtig, auch ein bischen reiner Selbstschutz, dass mein Schulfreund eine Vorstellung hat, wer an die Software verwenden wird, warum er dies tut und was für Aufgaben eine Person über die Software erledigen würde. Bis hierher hatte ich oft das Gefühl, dass wir recht visionär unterwegs waren. Mein Ziel war es, die Dinge mal auf den Boden zu holen. Wir haben gemeinsam den Blickwinkel stark verändert, von der Sicht des Produktherstellers mit starkem Vertriebsinteresse hin zur Sicht der Benutzer.
Wir entwickelten also Personas.
Bis hierher wurde Emails ausgetauscht. Über kurz oder lang verlor sowohl er als auch ich den Überblick. Kurzerhand habe ich alles auf Google Documents verschoben, unser erstes Arbeitsmittel mit Unterstützung verteilten Arbeitens.
Donnerstag, 22. Oktober 2009
In 3 Tagen lauffähige Software entwickeln - geht das, wie funktioniert das?
Beim letzten Scrum Breakfast Zürich konnte ich der agilen Community ein interessantes Projekt vorstellen.
3-2-1 Live! Rapid Development.
Namics hat im August 2009 gemeinsam mit der Adhoco GmbH, Winterthur ein Projekt der besonderen Art abwickelt. Ein interdisziplinäres Team, dass sich nicht kannte und so noch nie zusammengearbeitet, hat sich das ambitionierte Ziel gesteckt, lauffähige Software in 3 Tagen zu realisieren, wobei zu Beginn nur ein Idee im Raum stand!
Das Team, bestehend aus dem CEO/Adhoco als Product Owner, 1 Entwicker/Adhoco, 2 Entwicklern/Namics, einem ScrumMaster/Namics und einer UI Designerin/Meyer-Hayoz Design Engineering, führe in der gegebenen Zeit Interviews durch, erarbeite Personas und User Stories, entwarf UI Prototypen, Wireframes und realisierte letztendlich ein Web Applikation, die für das iPhone optimiert wurde.
Im Vortrag wurden fünf Fragen beantwortet:
- Wie kommt man von einer Idee zur Vision?
- Wie sammelt man benutzerorientierte Anforderungen?
- Wie stellt man den ersten Release zusammen?
- Wie geht man bei der Umsetzung vor?
- Wie geht man erfolgreich live?
... und natürlich wurde das Ergebnis gezeigt. Eine spannende Diskussion folgte auf den Fuss.
Klingt spannend? Dann studieren Sie die Unterlagen zum Vortrag ...
NAM-3-2-1-Live-RapidDevelopment-20091006-v1-1.pdfMontag, 19. Oktober 2009
Pay Per Use
Quasi mit leeren Taschen stand mein Schulfreund dann vor mir und fragte mich:
Was kostet dass, wenn man so eine Anwendung baut?Bis zu diesem Zeitpunkt war ich meiner Wahrnehmung nach nicht als Software Entwickler angesprochen, sondern eher als guter Zuhörer, als Partei zum challangen der Idee und Vision, als Berater - wie auch immer. Es war recht abstrakt, wenig greifbar und hatte irgend wie auch nichts mit mir zu tun. Als er danach fragte, ob ich ihm helfen könnte und wie ich mir eine Bezahlung vorstellte, änderte sich alles.
Wie einen Schalter, den man umlegt - ich wusste wie es geht, wie man vorgeht, welche Schritte man macht, in welcher Reihenfolge, wie es funktionieren wird und wann es nicht funktioniert. Ich hatte für jede Frage eine Antwort, ausser was es kostet und wie lange ich brauchen werde.
Mein Schulfreund, leicht irritiert, meinte, dass kann doch nicht so viel Arbeit sei, er stelle sich das recht einfach vor. Mein Gedanke war, und ich erinnere mich recht gut daran: Kein fixer Scope und keine fixe Zeitvorgaben - Aufwandschätzung unmöglich.
Wie im Vaakuum kam ich mir vor, als ich meinem Schulfreund versuchte zu erklären, dass Software Entwicklung nicht auf ein paar netten Gesprächen basieren kann. Man müsse schon etwas mehr in der Hand haben. Ausserdem kann das schnell recht teuer werden, den Standartsoftware kommt wohl nicht in Frage ;-)
Nach einer Weile und etwas mehr Verständnis für meine Situation kam er mit einem recht attraktiven Model. Letztendlich ist die Investitionssumme für die Software nicht wichtig. Wichtig ist, dass sie ein integraler Bestandteil der Pay Per Use Philosophie ist das man auch über Beteiligungen regeln kann. Pssst .....
Viel mehr möchte ich hierzu nicht erörtern -nur soviel: Wir haben ein Agreement gefunden. Eine Dimension des magischen Dreieck ist damit fixiert, oder relativiert: Budget.
Bleiben Scope und Time.
Freitag, 2. Oktober 2009
Ein neues Projekt - ProjekDE
"Du kennst doch Prepaid Handies?"
"Und Leasing-Modell bei Autos ist Dir auch bekannt?"