Vom Traum durch präzise Arbeitsplanung keine Ressourcen zu vergeuden

Wir nutzen TFS und die Projektvorlage ScrumForTeamSystem. Unser Taskboard für die Daily Scrums ist also digital. Wir treffen uns täglich rund um einen 24" Monitor und schieben unsere digitalen Aufgabenzettel übers Taskboard. Die Burndown Charts des Sprints wird daraus automatich ermittelt.
Neulich hatte ich mit einem Kollegen, der Scrum nicht kennt, eine interessante Diskussion. Der Anstoß der Diskussion war ein Blick auf unser aktuelles und vergangene Burndown Charts.
Die Fragestellung: "Warum weicht den Euer Fortschritt in den Burndown Charts so stark vom Plan ab?" und "Warum plant ihr die Sprints nicht so, dass die Ist-Kurve auf der Plan-Kurve liegt?"

Oben sind drei Beispiele von Burndown Charts aufgezeigt. Stellt die rote Kurve eine falsche Planung dar? "Vertrödelt" das Team gar die Zeit und bringt nichts fertig?
Was würde es denn bedeuten ein Team exakt auf die grüne Kurve hin zu trimmen? Wir Entwickler würden in in unseren Aufwandsabschätzungen dazu einfach genügend Puffer einbauen. Wir wollen dann ja auch ganz sicher gehen, dass wir im Zeitraster der Plankurve bleiben. Nun kann sein, dass sie diesen Puffer benötigen. Wahrscheinlicher ist es aber, dass sie ihn nicht benötigen. Dies bedeutet, dass in einer grünen Kurve eine Menge Zeitreserven stecken. In einer Roten aber keine.
Fazit: Allzu glatte Burndown Charts können nur mit genügend Zeitreserven erreicht werden.

Kombinationen und Maskierungen mit Enums und Flags

Das Beispiel unten zeigt, wie Flags eingesetzt werden können um bitweise mit Kombinationen arbeiten zu können. Mehrere Flags können mit einem OR-Operator verknüpft werden (Siehe Zeile 14). Eine Kombination kann über einen AND-Operator aufgelöst werden (Siehe z. B. Zeile 19).

1 [Flags()]

2 public enum Usage

3 {

4 Private = 1,

5 Commercial = 2,

6 Education = 4,

7 Training = 8

8 }

9

10 class Program

11 {

12 static void Main(string[] args)

13 {

14 TheUsage(Usage.Commercial | Usage.Education);

15 }

16

17 static void TheUsage(Usage usage)

18 {

19 bool isPrivate = (Usage.Private & usage) == Usage.Private; // false

20 bool isCommercial = (Usage.Commercial & usage) == Usage.Commercial; // true

21 bool isEducation = (Usage.Education & usage) == Usage.Education; // true

22 bool isTraining = (Usage.Training & usage) == Usage.Training; // false

23 }

24 }

Ich liebe es.

Schlankes ASPX: ASHX!

Aspx Seiten sind unschlagbar beim Entwerfen von Web Formularen. Möchte man aber z. B. nur ein dynamisches Image erzeugen oder eine Datei zum Download anbieten, benötigt man aber den "Overhead" den die Web Formulare mitbringen (Page Events, Server Side Tags, etc. ) nicht.
Hierfür gibt es Generic Handlers.
Diese haben die Dateiendung ASHX:

Dieses Beispiel schreibt einen vertikal verlaufenden Text als jpeg, was beispielsweise für Tabellenüberschriften verwendet werden könnte.

1 <%@ WebHandler Language="C#" Class="SampleHandler" %>

2 using System;

3 using System.Web;

4 using System.Drawing;

5 using System.Drawing.Imaging;

6 using System.Drawing.Drawing2D;

7

8 public class Handler : IHttpHandler

9 {

10

11 public void ProcessRequest(HttpContext context)

12 {

13

14 string text = context.Request.QueryString["text"];

15

16 System.IO.MemoryStream memStream = new System.IO.MemoryStream();

17 Bitmap bitmap = new Bitmap(100, 20, PixelFormat.Format32bppRgb);

18

19 Graphics graphic = Graphics.FromImage(bitmap);

20

21 graphic.SmoothingMode = SmoothingMode.HighSpeed;

22 graphic.Clear(Color.White);

23 graphic.DrawString(text, new Font("Arial", 12), Brushes.Black, 0, 0);

24

25 bitmap.RotateFlip(RotateFlipType.Rotate270FlipNone);

26 bitmap.Save(memStream, ImageFormat.Jpeg);

27

28 context.Response.ContentType = "image/jpeg";

29 context.Response.BinaryWrite(memStream.ToArray());

30 context.Response.End();

31

32 }

33

34 public bool IsReusable

35 {

36 get

37 {

38 return false;

39 }

40 }

41}

Das Resultat des Beispiels ist ein Image. Und all das ohne die Page Events und den Page LifeCycle von ASPX.

MSDN Veranstaltungsübersicht

Eine Liste aller Veranstaltungen, Developer Communities, TechNet Events, usw... findet man hier:

LINK

DotNet OpenSpace Süd 2009 in Ulm

Zum ersten Mal habe ich an einem Open Space teilgenommen.
Höchst beeindruckend mit welche Energie und Kompetenz die Diskussionen stattfanden.
Ich bin das nächste mal wieder dabei!
Ein Dank an Andreas und Thomas für die prima Organisation!

Scrum - Unser Kick-Off

Seit dieser Woche arbeiten wir nun mit Scrum. Wir entschließen uns die Tasks (also eigentlich die Sprint Backlog Items) in unserem TFSs aufzubauen. Dort verwenden wir noch das MSFA Projekt Template. Den eigentlichen Scrum Workflow werden wir aber an einem Whiteboard für jedermann ersichtlich durchzuspielen. Wir wollen erst mal den Prozess etablieren, ehe wir das komplette Visual Studio Projekt in ein neues Scrum-TFS-Projekt umziehen.
Was gab es für Erkenntnisse beim ersten Planungsmeeting?

• Die Forderung "alle kritischen Punkte zuerst angehen" behindert eine gleichmäßige Auslastung im Team
  Scrum fordert, dass die kritischen Aspekte bei Iterationen/Sprints immer zuerst angegangen werden. Wir erstellten also eine Liste mit allen Punkten die ein hohes Risiko haben oder kritisch sind. Diese wollten wir zuerst angehen. Beim durchsehen der Punkte fiel uns gleich auf, das nur ganz bestimmte Personen diese Aufgaben durchführen konnten. Eine gleichmäßige Auslastung im Team war nun nicht mehr gegeben. Wir haben Experten ("Kopfmonopole") und das Know-How ist sehr ungleichmäßig verteilt. Wir schafften es trotzdem die Aufgaben einigermaßen gleichmäßig zu verteilen.
  
• Entwickler tun sich schwer den Aufwand ihrer Arbeitspakete abzuschätzen.
  Diese ernüchternde Feststellung hat mich nicht verwundert. Die Abschätzung der Dauer einzelner Arbeitspakete benötigt man für die die Planung eines Sprints. Oft wird empfohlen mit Story Points die Aufwände und die Kapazität des Teams zu ermitteln. Wir versuchen es erst mal mit Stunden. Das ist uns vertrauter. Mal sehen, ob Story Points später nicht doch besser geeignet sind.
  
• Die Erste Sprint-Planung dauert (und dauert und dauert…)
  Wir haben sehr lange für die erste Sprint-Planung gebraucht. Mehr als drei Tage haben wir damit verbracht bis die Planung stand. Die Planung sollte an einem Tag durchführbar sein. Man hört und liest aber, dass es beim ersten Mal immer sehr lange dauert…

Was waren die Ergebnisse?

• Unser Sprint Ziel:

"Complete SQL Interfaces & Finish GUI Basis-Funktion für…"

• Die Aufgaben (Sprint Backlog Items bzw. Tasks)

Gelbe Zettel auf dem White-Board sind die Tasks im Sprint. Wir bauen die Tasks parallel in TFS auf.

Fazit
Fürs erste sieht's schon mal nicht schlecht aus!

• Die Planung steht.
• Alle haben mitgearbeitet.
• Jeder kennt das Ziel für die nächsten 3 Wochen

Impressum

Verantwortlich für die Inhalte dieses Blogs:

Dies ist ein privater Blog.

Als Anschrift ist zu verwenden:

Bernhard Renner
Postfach 1203
86830 Schwabmünchen

Infos dazu auch:
§ 10 Abs. 2 S. 1 Nr. 1 MdStV bzw. § 6 S. 1 Nr. 1 TDG

Da es sich hierbei um Pflichtangaben handelt,
sind diese nach oben stehendem Gesetz ausreichend.

Kontakt:
bernhard.renner@gmail.com

Datenschutz und Erklärung zum Telemediengesetz.
Sehr geehrter Besucher dieser Webseite, mittels des Services von Google-Analytics werden Daten erhoben zur statistischen Auswertung dieser Webseite.

Dabei wird Ihre IP Adresse gespeichert und entsprechend ausgewertet welchen Weg Sie durch die Homepage nehmen.
Es wird ebenfalls ausgewertet, welche Downloads Sie von dieser Seite tätigen. Es ist jedoch nicht eindeutig auf Ihre Person zu beziehen, sondern lediglich auf die von Ihnen verwendete IP Adresse Ihrese Internet-Providers.

Im Falle einer strafrechtlichen Verfolgung wird der Provider die IP Adresse natürlich Ihnen zuordnen können und an die Ermittlungsbehörden weiter geben.

Was genau dabei geschieht, wird in einer Privacy Policy erklärt: http://www.google.com/intl/de/privacy.html.