projekte - Einträge für Juli 2008

  • Juli, 2008
  • Welche Prozesse müssen wirklich umgesetzt werden? ::: Managementprozesse

    Wir haben vor kurzem wieder mal ein Projekt gestartet und wie immer kam die Frage auf, ob wir wirklich alle Prozesse durchführen müssen. Die Fragen waren:
    • Müssen wir ein proaktives Risikomanagement aufbauen?
    • Braucht es ein Changemanagement?
    • Ist ein Costtracking wirklich notwendig?
    • Wieso brauchen wir ein Stakeholder-Management?
    • Wer macht denn heute noch Support-Prozesse oder Incident-Management um Projekte an den Betrieb zu übergeben?
    Wie immer gab es im Team mehrere Bestrebungen. Die Einen wollten am liebsten alle Prozesse aufsetzen und im Papierstapel ertrinken. Die Anderen wollten am liebsten gar nichts machen und einfach schnell mal das Projekt fertig stellen. Tja, da war also unser Dilemma. Entweder wahnsinnig viel schreiben, viele Protokolle erstellen, viele Dokumente unterschreiben und weiter leiten, oder schnell und schlank durchs Projekt schreiten und beim ersten politischen Rülpser unter die Räder kommen. Wir saßen also zusammen und stellten unsere Anforderungen zusammen. Wir wussten, dass dieses Projekt politisch nicht leicht werden wird. Es ist ziemlich dick und wir müssen viele Mitarbeiter an verschiedenen Standorten koordinieren. Das schreit nach viel Prozess, Planung und Koordination. Aber wie immer haben wir nicht viele Mitarbeiter, die uns beim Planen und Koordinieren helfen können. Das kostet Geld und ist für die Auftraggeber ziemlich nervig. Stellt euch vor ihr zahlt für den Umbau eurer Wohnung 10.000€ und davon für die Projektleitung 7.000€. Das würde euch sicher gefallen oder? Wie etwa nicht? ;-) Und da hat einer von unseren altgedienten Projektleitern eine super Aussage gemacht:
    • Du kannst jeden Prozess weglassen.
    • Du kannst in deinem Projekt auf alles verzichten.
    • Mit jedem Prozess den du weglässt erhöht sich lediglich dass Risiko.
    Und so haben wir uns auf ein hoffentlich vernünftiges Maß der eingesetzten Prozesse geeinigt. Wir lassen diverse Prozesse weg, oder behandeln sie etwas stiefmütterlich. Andere Prozesse, die wir wegen der Eigenheiten des Projektes als wichtig ansehen, setzen wir komplett um. Den Rest machen wir mit unserem Bauchgefühl. Denn wie schon Tom DeMarco sagte, das wichtigste Organ des Projektleiters ist der Bauch. Also dann auf ins Projekt und vertraut hier und da eurem Bauch! Ich für meinen Teil kann da auf einen relativ dicken Teil meines Körpers vertrauen :-( Viel Spaß beim Leiten!
  • Anhalten und sich umschauen ::: Kommen noch alle mit? ::: Anfänger und Profis

    In den letzten Jahren bin ich von einem Projekt zum nächsten gesprungen und arbeitete mit Architekten, Projektmanagern, Systemspezialisten und Experten aus unterschiedlichsten Disziplinen zusammen. Ich eignete mir BPM, Design Patterns, UML, J2EE, PHP, EAI, SOA, Webservices, Web2.0 und vieles mehr an. Vor lauter dazulernen habe ich völlig vergessen, dass es auch Anfänger gibt, denen das Programmieren nicht in die Wiege gelegt wurde. Unser Azubi bei miradlo hat mir da die Augen geöffnet. Unsere Welt dreht sich extrem schnell und wir dürfen nicht stehen bleiben. Dummerweise müssen die "Neuen" auch irgendwie hinterher kommen. Da stellt sich nun die Frage, was sie alles lernen müssen und was wirklich nicht mehr benötigt wird.

    Dinge die garantiert noch benötigt werden

    Ich glaube beim Einstieg in die Programmierung sind die folgenden Themengebiete immer noch unumgänglich:

    Boolesche Algebra

    Das ist DIE Grundlage. Zum Einstieg sollten wirklich die grundlegenden Elemente erlernt werden. Im Internet findet sich genügend Dokumentation darüber; (siehe wikipedia oder IT-Wissen). In den Schulen sollte das auch unterrichtet werden. Leider sollte das nur unterrichtet werden. Bei manchen Schulen wird im ersten Lehrjahr alles mögliche unterrichtet, die benötigten mathematischen Grundlagen sind jedoch eher nicht gern gesehen...

    Datentypen

    Hier geht es weiter. Wenn man sich in die Programmierung einlernen will, sollte man sich mit den Standarddatentypen auskennen. (Siehe wikipedia) Es ist wichtig zu wissen, was folgende Datentypen bedeuten:
    • bool
    • int
    • long
    • double
    • float
    • String
    Egal in welcher Programmiersprache. Irgendwie findet man diese elementaren Datentypen immer wieder.

    Syntax der Programmierung

    Wie in at-mix.de schön beschrieben, handelt es sich bei der Syntax um die Festlegung welche Zeichen miteinander kombiniert werden dürfen. Im letzten Jahr habe ich mehrmals Anfänger erlebt, die ihre Programme nach Form, anstatt nach Syntax erstellten. Wenn man das zuvor noch nicht gesehen hat, ist es schwer zu erklären. Vielleicht gelingt mir das mit einem Beispiel: Die Aufgabe war eine Überprüfung von Eingabewerten durchzuführen:
    // Some other codeif(a > 10){
    
    // do something which looks like a very long string
    
    }else{
    
    // do something else which didn't fit in this line. So you have to look what to do...
    
    }
    Der zu lange Text sah nicht gut aus und so wurde er umgebrochen:
    // Some other codeif(a > 10){
    
    // do something which looks like a very long string
    
    }else{
    
    // do something else which didn't fit in this line.
    
    So you have to look what to do...
    
    }
    Wenn ihr euch ein bisschen mit programmieren auskennt, wisst ihr warum das keine gute Idee ist ;-) Der Code sieht zwar schöner aus, kann aber nicht mehr ausgeführt werden. Ein weiteres Beispiel, bei dem die Syntax nicht verstanden wurde, zeigt diese Zeile hier:
    if(count($argv > 2)){}
    Anstatt:
    if(count($argv)  > 2){}
    Na erkennt jeder den Unterschied?

    Fazit

    Im ersten Moment ist es irritierend, wenn man selbst diese Fehler lange nicht mehr macht. Doch es hat mir gezeigt, dass man vor lauter bunten Oberflächen, schnelleren Modellen und einem blinden Glauben an die Technik immernoch auf die Menschen achten muss, die diese Maschinen bedienen. Egal wie perfekt unsere Computer und Methoden werden, schlussendlich müssen wir sie bedienen und verstehen können, um wirklich nutzbringende Systeme erstellen zu können. Schaut euch mal ein bisschen um und überprüft ob alle in eurem Umfeld noch mitkommen...
  • Episode 14: Warum ein Detailkonzept erstellen?

    In den letzten Episoden habe ich ein bisschen die Möglichkeiten der Anforderungsanalyse beschrieben. Was machen wir mit den Anforderungen, wenn sie in schriftlicher Form vorliegen? Wir müssen die Informationen bündeln und in eine Form bringen, die wir für die Umsetzung verwenden können.

    Warum müssen wir so vorgehen?

    Egal ob wir mit Extreme Programming oder mit dem Wasserfallmodell arbeiten, wir können die Anforderungen nicht einfach nur heruntertippen. Das heißt, können kann man schon. Aber dann kommt eine Software dabei heraus, die garantiert nicht erweiterbar und wartbar ist. Ich mußte einmal ein PHP-Projekt übernehmen, das direkt von den Anforderungen in Code geschrieben wurde. Das war eine tolle Erfahrung! In einer .php-Datei war Javascript, CSS, HTML, SQL und PHP-Code vereint. Für einen Prototypen, um schnell mal dem Kunden zu zeigen, wo die Reise hingehen soll, mag das so passen. Wenn wir später nur eine Änderung an der Datei vornehmen wollen geht es schief. Die Aufwände für die Weiterentwicklung steigen ins Unermessliche und am Ende muss alles neu geschrieben werden.

    Was muss gemacht werden?

    Um wirklich stabile Software erstellen zu können, muss die Software einer Systemarchitektur genügen. Die Architektur muss so ausgewählt werden, dass sie die Anforderungen abdecken kann. So muss eine Applikation, die für die Verarbeitung von Formulardaten erstellt wird, viele parallele Eingaben verarbeiten können. In einer Software für die Fahrtsteuerung eines  Autos muss vor allem die Realzeitanforderung abgedeckt werden. Es wäre ziemlich unangenehm, wenn das Auto erst die Wand durchschlägt und dann der Computer nachträglich das Lenkmanöver einleitet ;-) Die Kundenanforderungen beschreiben das System von der Kundenseite aus. Das Detailkonzept beschreibt, wie das zu erstellende System die Kundenanforderungen abdecken wird. Eine 1:1 Abbildung wird es nicht geben. Der Zwischenschritt über das Detailkonzept ist notwendig. Über den Umfang des Detailkonzepts kann man streiten. Soll wirklich alles zuerst beschrieben und dann umgesetzt werden? Manchmal ist das nicht zielführend. Jedoch muss so viel beschrieben sein, dass eine abschließend definierte Softwarearchitektur vorhanden ist.
  • Episode 13: Anforderungen mit XP Vorgehen aufnehmen ::: Softwareprojekte

    Bei nicht allzu komplexen Projekten, oder bei Teilprojekten, kann man mit Extreme Programming (XP) sehr gute Ergebnisse erzielen.
    • Im ganz Groben kann man sagen, dass man iterativ vorgeht und zuerst ein paar Basiskomponenten erstellt.
    • Der jeweilige Stakeholder kann nach relativ kurzer Zeit das Ergebnis ansehen und seine Anforderungen näher beschreiben.
    • Auf diese Weise ist man stets im Kontakt mit seinen Stakeholder und wird die Bedürfnisse eher verstehen.
    • Bei allen Arten der Anforderungsanalyse ist es vor allem wichtig zu wissen, dass die verschiedenen Stakeholder die Welt unterschiedlich sehen und beschreiben.
    • Wenn vier Personen etwas sagen, können dabei mindestens vier unterschiedliche Ansichten entstehen.
    • Die echte Wahrheit gibt es nicht.
    Weitere Hinweise zu Extreme Programming gibts z.B. in den Quellen zu Requirements Engineering.

Seite 1 von 1, insgesamt 4 Einträge