Posts mit dem Label resourcen werden angezeigt. Alle Posts anzeigen
Posts mit dem Label resourcen werden angezeigt. Alle Posts anzeigen

Montag, 14. Januar 2008

*SHIFT_resources - das Spiel mit den offenen Karten

*SHIFT_resources - so oder so ähnlich würde der Claim auf den Werbeplakat von Nissan aussehen, wenn ...

Erfahrungsgemäss ist mit der Einführung von agilem Vergehen á la Scrum das Offenlegen der Resourcen am Projekt ein zweiseitiges Schwert, weil ...

Der Product Owner trifft pro Iteration bei der Planung und Vorführung, wahlweise auch bei der Retrospective, auf das gesamte Team. Damit ist eines sofort ersichtlich - Resource-Shifting beim Software Anbieter - Pluspunkt!

Den Minuspunkt gibts beim Software Anbieter - der muss sich sehr wohl überlegen, ob und wie oft er Resourcen auf dem Projekt wechselt. Auch ein Resource-Sharing wird schnell ersichtlich, denn bei der Planung wird das Team dem Rechnung tragen, wenn 1, 2 oder 3 Entwickler nur 80% am Projekt arbeiten.

Zusammenfassend kann man sagen: wer ein Projekt nach SCRUM abwickelt, spielt bezüglich Resourcen mit offenen Karten - man muss!

Dienstag, 4. Dezember 2007

Ajax in Action IV

Im vorherigen Post in der Serie Ajax in Action habe ich beschrieben, wie man mit AJAX in GUI Komponenten nachladen kann.

In diesem Beitrag geht es darum, locale spezifische Messages im Client auszugeben. In vielen Büchern, z.B. Ajax in Action, findet man immer wieder ein Kapitel Exception Handling, was aber nur das Handling ansich aufzeigt, nicht aber, wie man lokalisierte Messages realisert.

Beispiel: Ajax in Action, Seite 464, Listing 1:

handleError: function(request) {
 if (this.options.messageSpanId) {
  document.getElementById(this.options.messageSpanId).innerHTML=
   "Opps! Server error. Please try again later.";

Soweit - so gut. Aber wie realisert man jetzt, dass die Message in DE/FR/IT/EN lokalisiert wird?

Ich persönlich schau immer gern was Microsoft so macht, denn die Lösungen sind meistens sehr gut durchdacht und funktionieren auch!

Gesagt - getan - gegoogled: Adding Localized Resources to a JavaScript File.

Ich hab die Idee ein bischen verändert und komme zu folgendem Lösungsansatz:

Die Seiten, die eine JavaScript Message lokalisieren müssen bekommen einen script include, z.B:

<script type='text/javascript' src='/myapp/js/resources.js'></script>

Im JavaScript wird folgendes definiert:

Error={
"InputNotValid":"Sie haben ein ungültigen Wert eingegeben.",
"ServerError": "Der Service ist momentan nicht verfügbar."
};
Message={
"Loading":"Bitte warten…"
};

Dieses resources.js steht die Default Locale bereit. Zusätzlich wird im HMTL Code weiter unten noch das sprachspezifische resource.js geladen. Da JavaScript überladen unterstützt, können im sprachspezifischen File die Werte neu definiert werden. Werden sie nicht definiert, greift die Default Language:

<script type='text/javascript' src='/myapp/js/resources.en-GB.js'></script>

Das JavaScript sieht dann so aus:

Error={
"InputNotValid":"Your entered value is not valid."
};

Message={
"Loading":"Loading…"
};

In diesem Fall würde das englische Resource File den Error.ServerError nicht definieren und somit den Default aus resources.js verwendet.

Wie wird das nun verwendet? Am Beispiel vom "Loading" wird die Message.Loading im div loadingMsg so verwendet:

<script type="text/javascript">
function addItemToCart() {
 document.getElementById('loadingMsg').style.display = 'block';
 document.getElementById('loadingMsg').innerHTML = Message.Loading;
 var id = dwr.util.getValue("id");
 var q = dwr.util.getValue("quantity");
 cartManager.addItemToCart(id,q);
 return;
}
</script>


Lokalisierte Messages im JavaScript - gelöst!

Mittwoch, 23. Mai 2007

Release 2.0 erfolgreich ausgeliefert

Gestern, 22.05.07 haben wir den Release 2.0 (Anneboda) erfolgreich ausgeliefert. Wir haben daran zwei Sprints a eine Woche gearbeitet. Geplant war pro Sprint eine Velocity von 10 SP's. Es hat sich jedoch gezeigt, dass einwöchige Sprints nicht wirklich gut sind, denn es ist das Ziel am Sprint Ende alle User Stories auf DONE zu bringen. Wir konnten das nicht einhalten. Im ersten Sprint wurde lediglich eine User Story mit 1 SP abgeschlossen, im zweiten Sprint dann 5 weitere mit insgesamt 25 SP's. Damit wurden total 26 SP's für diesen Release realisiert. Wir werden zukünftig wieder Sprints a zwei Wochen planen - Velocity 20.

Ein alt bekanntes Problem gab es auch während dieses Releases - Resourcenlage. Es gab erneut wieder, sagen wir mal "flüchtige Resourcen". Teammitglieder wurden mal stunden-, mal tagweise abgezogen und es ist viel Arbeit liegengeblieben. Der Rest des Teams hat diese dann übernommen und fertiggestellt - immerhin fördert das den Teamzusammenhalt, auch wenn man beim Einen oder Anderen Säbelrasseln hört...

Was haben wir daraus gelernt? Nun ja, die Scrum Rituale sind wichtig! Bisher haben wir Estimation, Planning Meeting und Daily Scrum nicht nach Scrum durchgeführt. Hier war es eher so, dass ein kleiner Teil des Teams diese Meetings durchlaufen hat, nicht aber alle. Damit haben die Daily Scrum Meetings eher den Stil von "Du machst heute das!" (Weil ich es Dir sage!). Was passiert? Niemand übernimmt Verantwortung und klemmt sich hinter die Arbeit. Man bekommt auch keine Hindernisse oder Verzug gemeldet. Am Ende wird es eng und die Gemüter sind erhitzt!

Wir machen jetzt Planning Meeting mit allen Teammitgliedern und jeder wählt selbst, welche Arbeit er übernehmen möchte. "Scheissarbeiten" werden demokratisch verteilt, so kommt jeder mal in den Genuss. Jedem ist klar, dass er allein für die Fertigstellung der Aufgabe verantwortlich ist. Wenn Hindernisse auftauchen müssen diese in erster Linie selbst gelöst werden.

Wir arbeiten jetzt konzentrierter und fokussierter an den Aufgabe - ein guter Schritt nach vorn, wie ich finde.

Mittwoch, 9. Mai 2007

Release 1.0 erfolgreich ausgeliefert

Am Montag 07.Mai 07 haben wir den ersten Release (Ecktorp) im neuen Scrum Projekt planmässig ausgeliefert. Alle Features, die geplant waren, wurden firstgerecht fertigestellt und in Produktion genommen. Der Kunde ist sehr zufrieden und hat mit dem Team die weiteren Schritte definiert.

Trotzdem der Release erfolgreich war, hatten wir einige Problem, die ich hier kurz erläutern möchte.

  1. Sprint-Planung
    Von Begin an war klar, dass wir einen ersten Release nach ca. 3 Wochen in Betrieb nehmen werden. Das Produktbacklog bot genug Arbeit für ca. 3 Releases. Der Kunde hat ein Priorisierung der Features vorgegeben und das Team hat die Arbeit zunächst auf einen Sprint mit 3 Wochen mit 25 Story Points geplant. Ein weiterer Release steht in 2 Wochen an, was uns zur Frage bringt, wie man dass in eine Sprint Planung einbezieht. Wir haben für den 2. Release (Anneboda) zwei Sprints a eine Woche geplant. Die Problematik besteht nun darin, eine realistische Planung aufzustellen, denn man hat keinen Vergleich für die Sprint Geschwindigkeit (Velocity). Unsere Annahme ist, dass wir pro Woche 12 Story Points realisieren können. Wir werden sehen ...
  2. Resourcenplanung
    Sprint 1 wurde mit einem Team von 4 Entwicklern geplant. Wir haben die User Stories aufgeteilt und parallel an Features gearbeitet. Nach ca. 1 1/2 Wochen hat sich die Resourcenlage leider verschlechtert - es wurden 2 Teammitglieder abgezogen. Nun, was ist passiert? Ein Scrum Teammitglied arbeitet weitestgehend eigenverantwortlich. Wenn jemand das Team während des Sprints verlässt, hinterlässt man begonnen Arbeit in einem mehr oder weniger unklarem Zustand. Wir haben also in der Hälfte des Sprints die Strategie zur Abarbeitung der User Stories verändert und auf Stabilität statt Menge gesetzt - sprich den Umfang reduziert. Der Rest vom Team hat die liegengebliebene Arbeit (grossteils durch Überstunden) auf DONE bringen können. So haben wir es trotz nicht geplanter Lage geschafft, alle gewünschten Features fertigzustellen. Das hat nur funktioniert, weil das Team bereits mit dem Scrum Vorgehensmodell vertraut ist und technologisch sattelfest ist. Wenn das Know-How nicht homogen verteilt ist, ist eine solche Lage durchaus als riskant einzustufen.
  3. Prototype
    In der Offerte wurden bereits Screen/Design Vorschläge offeriert. Unmittelbar zum Projektbeginn hat der Kunde das Design abgenommen. Daraufhin wurde ausserhalb des Scrum Teams ein HTML Prototype realisiert. Als das Scrum Team die Arbeit aufgenommen hatte, ergaben sich die ersten Probleme. Das Design war für eine Website, nicht aber für eine Webapplikation ausgelegt. Klassiker, wie Links, die einen Form Submit auslösen, Breadcrumb Trail in einer Applikation, Dialoge, die keine Dialoge sind, etc. wurde falsch gemacht. Somit konnte das Team nur verzögert mit der Arbeit beginnen. Dazu kam, dass der Kunde das Design abgenommen hatte und nunmehr bereits nach wenigen Tagen schon ein Re-Design besprochen werden musste, bevor überhaupt Features realisiert werden konnten. Der Kunde war sichtlich irritiert - verständlich! Daher die Empfehlung einen Applikationsdesigner von Beginn an einzusetzen. Es ist sicher auch hilfreich ein Developer über das Design schauen zu lassen - das hat sich in der Vergangenheit immer bewährt.
Was vielleicht noch erwähnenswert ist: wir haben die Scrum Rituale auf eine Minimum beschränkt. Wir machen täglich ein 15-minütiges Stand-up Meeting, Sprint und Release Planung und eine Retrospective bei einem Bier am Abend. Wir setzten Target Process ein, beschränken uns aber nur auf die Funktionen für Release und Sprint Planung, sowie User Stories und Bugs. Sonst kommen keine weiteren Tools zum Einsatz.