Projektmanagement Softwareentwicklung

Softwareentwicklung für Projektleiter, Manager und Entwickler

IT-Projektmanagement RSS
  • Herzlich Willkommen beim IT-Projektmanagement Blog

    Jörg Hinrichs

    Hallo und herzlich Willkommen!

    Jörg HinrichsIch heiße Jörg Hinrichs und bin selbständig in der IT-Branche.

    Seit nunmehr fast zwanzig Jahren beschäftige ich mich mit Softwareentwicklung, hauptsächlich als Entwickler und Dozent. Während dieser Zeit habe ich in vielen unterschiedlichen Softwareprojekten mitgewirkt. Was ich dabei erlebt habe und welche Erkenntnisse sich daraus für mich entwickelt haben, möchte ich in diesem Blog mit Ihnen teilen.

    Hier geht es um Softwareentwicklung, wobei das Projektmanagement von Softwareprojekten im Mittelpunkt steht. Der Blog richtet sich deshalb hauptsächlich an Projektleiter. Es wird aber auch interessante Beiträge für Entwickler, Softwarearchitekten oder auch Manager und Auftraggeber (Fachabteilung oder Kunde) geben, denn diese gehören zu einem Softwareprojekt zwangsläufig dazu.

    Um Ihnen die Suche möglichst leicht zu machen, gibt es in diesem Blog Kategorien für die thematische Zuordnung sowie solche für die Rolle, die eine Person in einem Softwareprojekt einnimmt. So finden Sie schnell genau die Themen, die für Sie am interessantesten sind.

    Also, ich hoffe, dass Sie hier neue und interessante Beiträge finden. Dieser Blog soll außerdem eine Plattform für die gemeinsame Diskussion sein. Wenn Sie also anderer Meinung sind oder etwas Wesentliches ergänzen möchten, machen Sie gerne Gebrauch von der Kommentarfunktion.

    Und jetzt wünsche ich Ihnen viel Spaß beim Lesen!

    Jörg Hinrichs

     

    Published on Juli 5, 2011 · Filed under: Allgemein; Tagged as: , , ,
    5 Comments

5 Responses to “Herzlich Willkommen beim IT-Projektmanagement Blog”

  1. Very interesting post. Thank You.

  2. Vielen Dank für diesen informativen Artikel. Alles sehr schön eingerichtet! Eins würde ich aber gerne mal Fragen: Wo ist der “gefällt mir” Button Von Facebook? Freue mich auf Rückmeldung

  3. Direkt am Ende des Artikels ;)

  4. Uwe Zipprich said on

    Sehr geehrter Herr Hinrichs,

    ich weiss nicht ob Sie mir weiterhelfen koennen, aber einen Versuch unternehme ich mal.

    Ich soll eine Software fuer einen ‘Bootloader’ des ds33f Mikrokontrollers con Microchip schreiben (siehe pdf-Dokument).

    http://ww1.microchip.com/downloads/en/AppNotes/01094a.pdf

    Gegeben ist ein C++-SourceCode, der die Applikation unter DOS laufen laesst. Ich soll nun das ganze mit einer graphischen Benutzeroberflaeche versehen, sprich in VISUAL C++ schreiben.

    Sourcecode: http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en530200

    Das Projekt ist im .zip file enthalten.

    Koennten Sie mir vielleicht verrate, wie ich den Wert dieses Projektes einschaetzen kann?

    Er hat mir gesagt, dass ein Profi das ganze in 40 Std. erledigen wuerde, aber ich glaube das nicht so ganz, denn ich muss mich erst mit dem Demoboard vertraut machen, den Sourcecode analysieren, Proben machen und danach den Code schreiben. Fuer mich ist das mindestens 2 Wochen wert (80 Std.).

    Aber offen gesagt, weder er noch ich haben eine Ahnung, wie man das Ganze richtig einschaetzen kann.

    Koennten Sie mir da vielleicht einen Tip geben?

    Vielen Dank

    Uwe Zipprich

  5. Jörg Hinrichs said on

    Hallo Herr Zipprich,

    bitte seien Sie mir nicht böse, dass ich nicht tiefer in die von Ihnen angeführten Dokumente eingestiegen bin. Ich kann Ihnen aber ein paar allgemeine Ratschläge geben:

    1.
    Schätzungen werden grundsätzlich vom ausführenden Entwickler durchgeführt. Immer. Der Grund ist ganz einfach: Die Produktivitätsunterschiede bei Entwicklern sind riesig. Ein guter Entwickler kann 10-20 mal schneller arbeiten als ein unerfahrener. Es spielt also für Ihre Schätzung keine Rolle, wie schnell ein “Profi” wäre (allenfalls für die Bezahlung, aber das ist ein ganz anderes Thema).

    2.
    Prüfen Sie, ob die Anforderung genau genug ist. Das geht ganz einfach indem Sie Testfälle für jede Funktionalität erstellen. Wenn Sie nicht genau wissen, wie etwas zu testen ist (inklusive Sollwerte), dann haben Sie noch nicht genügend Informationen.

    3.
    Als nächstes machen Sie Ihre eigene Schätzung. Teilen Sie dazu die Aufgabe in Häppchen auf. Ich würde maximal 2-3 Tage pro Task empfehlen, wenn es mehr ist sollte er weiter aufgeteilt werden. Halbe Tage sind auch Ok. Viel tiefer würde ich aber nicht gehen (meine eigenen Schätzungen halte ich zwischen 0.25 und 5 Tagen, vorzugsweise in der Mitte). Gehen Sie davon aus, dass die Aufgabe sich erledigen lässt, ohne dass Sie auf größere Hindernisse stoßen.

    4.
    Dann versehen Sie die einzelnen Tasks mit Risikofaktoren, mit denen der Aufwand multipliziert wird. Tasks die Sie sicher einschätzen können (z.B. Dokumentation) bekommen einen Risikofaktor von 1. Tasks, bei denen Sie mit Hindernissen rechnen, erhalten einen höheren Risikofaktor, z.B. 1.5 oder 2. Wenn Sie neue Technologie einsetzen, mit der Sie noch nicht gearbeitet haben, würde ich mindestens einen Faktor von 3 ansetzen. Unter neue Technologie verstehe ich eine neue Entwicklungsumgebung, Drittanbieter-Komponenten oder Frameworks, mit denen Sie noch nicht gearbeitet haben oder Techniken innerhalb einer Programmiersprache, die Sie noch nicht benutzt haben (z.B. Datenbankzugriff).

    5.
    Jetzt zählen Sie alle Aufwände zusammen – und kriegen wahrscheinlich einen kleinen Schock! Die Zahl ist groß – geradezu riesig. Keine Angst, das ist normal ;). Trotzdem, ich gehe jede Wette ein, dass diese Zahl besser ist als die vorgeschlagenen 40 Stunden.

    Jetzt kommt es darauf an, was Ihre Zielsetzung ist. Geht es um Geld? Oder nur um eine verlässliche Schätzung? Was passiert, wenn Sie 105 Stunden statt 40 Stunden schätzen?
    Wenn es Ihre “eigene” Zeit ist (also z.B. wenn Sie selbständig sind), können Sie auch einen Ansatz nach dem folgenden Muster fahren: Nehmen wir einmal an, Sie haben 105 Stunden geschätzt. Sie möchten das dem Auftraggeber aber so nicht sagen, aus welchen Gründen auch immer. Dann bieten Sie ihm beispielsweise 55 Stunden an (weil Sie ja vermutlich noch kein Profi sind) und betrachten den Rest als Investition in Ihre Ausbildung.

    So oder so sollten Sie aber beim Zeitaufwand auf jeden Fall von Ihrer eigenen Schätzung ausgehen. Und auch die Termine entsprechend gestalten.

    Ich hoffe, das hilft Ihnen erst einmal weiter.

    Viele Grüße
    Jörg Hinrichs

Leave a Reply