Einträge für projekte

  • Juni, 2008
  • Episode 9: Wann muss der Betrieb mit ins Boot? ::: Softwareprojekte

    Immer wieder stellt sich bei Projekten die Frage, ab wann der Betrieb involviert werden soll. Der Betrieb hat im Normalfall nicht genügend Mitarbeiter, um in jedem anstehenden Projekt mitzuarbeiten. Auf der anderen Seite muss gewährleistet werden, dass das erstellte Produkt auch vom jeweiligen Betrieb verwaltet werden kann.

    Thomas hatte sich die beiden Familien angeschaut...

    ...und sich den Betrieb genauer betrachtet. Im Fall von Hans, Karl und Orlando kann man nicht von einem klassischen Betrieb sprechen. Die drei sind Entwickler und Betreiber in Personalunion. Bei der zweiten Familie ist die Entwicklung und der Betrieb voneinander getrennt. Die Entwicklung erstellt ein Programm und übergibt es an den Betrieb. Eine vernünftige Dokumentation, wie das jeweilige Programm zu bedienen und warten ist, gibt es nicht. Wenn ein Fehler auftritt, handelt der Betrieb intuitiv. Wenn das nicht klappt, wird der Incident an die Entwickler übergeben. Thomas will bei der Neugestaltung der gemeinsamen IT die beiden Betriebe zusammenlegen und einen möglichst stabilen Betrieb aufbauen. Seine Überlegungen: „Wenn ich den Betrieb permanent mit in das Projekt einbinde wird die Stakeholderliste unnötig groß. Jeder will mitreden und an eine Weiterentwicklung der Software ist kaum zu denken.“ „Wenn ich den Betrieb erst kurz vor der Abnahme einbinde, ist die Gefahr extrem hoch, dass die erstellte Software nicht betreibbar ist.“ Was für ein Dilemma! Nach einigem hin- und her entschied sich Thomas für folgendes Vorgehen: „Ich lass den Betrieb bei der Anforderungsanalyse all seine Anforderungen, die zu diesem Zeitpunkt bekannt sind, formulieren.“ Bekannte Anforderungen können sein:
    • Bekannte Betriebssysteme, die von den Mitarbeitern verwaltet werden können
    • Monitor-Elemente, die gesetzt sind und die eingebunden werden müssen
    • Angaben, wie Projekte dokumentiert und Betriebshandbücher aufgebaut sein müssen
    • Angaben, wie Artefakte an den Betrieb übergeben werden müssen
    • ...
    „Zusammen mit den Anforderungen der Kunden erstelle ich die Architektur und das Detailkonzept. Das Detailkonzept wird vom Betrieb überprüft und anhand der detaillierten Informationen kann der Betrieb genauer angeben, was er wirklich braucht.“ „Danach lasse ich den Betrieb erst einmal wieder in Ruhe.“ Zu diesem Zeitpunkt werden im...

    Projekt vor allem die neuen Komponenten

    erstellt. „Wenn ein testbares System vorhanden ist, muss der Betrieb wieder ran und kontrollieren ob alles für ihn in Ordnung ist.“ Zu testen sind hier
    • Stabilität
    • Auswirkungen auf andere Komponenten
    • Installierbarkeit
    • Konfigurierbarkeit
    • Performance
    • ...
    „Weiterhin werde ich die Betriebsmitarbeiter während dieser Tests schulen.“ Hier ist die Gefahr hoch, dass die Zeit für die Schulung nicht ausreicht, um die Mitarbeiter wirklich für den Betrieb fit zu machen. Und da haben wir auch wieder das Dilemma. Entweder hat man über eine lange Zeit viele Mitarbeiter blockiert und dafür aber später gut ausgebildete Kollegen oder man kommt im Projekt schneller vorwärts und fährt das Risiko, dass sich die Betriebsübergabe verschiebt. Ich selbst glaube, dass es hier keine ideale Lösung gibt. Man muss sich für einen Mittelweg entscheiden. Wichtig ist jedoch, dass der Betrieb von Anfang an ausreichend informiert wird.
  • Mai, 2008
  • Projektleiter der Welt vereinigt euch! ::: Blogparade

    Vor dem letzten 1. Mai bin ich an einem Schild vorbei gekommen, auf dem stand „Proletarier der Welt vereinigt euch!“ Dummerweise habe ich das nicht richtig gelesen und dachte dann; es heißt „Projektleiter der Welt vereinigt euch!“ Im Prinzip ist es das Gleiche :-) In Firmen ist der gemeine Projektleiter ein Einzelkämpfer. Firmen haben im Normalfall mehr Projekte als Mitarbeiter. Also muss darum gestritten werden, wer die wertvollen Mitarbeiter bekommt. Und oft gilt dabei, dass der lauteste Brüllaffe die Ressourcen zugeteilt bekommt. Ok, bisher hatte ich Glück und war der beste Brüllaffe. Aber eigentlich müsste das auch anders möglich sein, oder? Also warum vereinigen sich die Einzelkämpfer nicht und bringen die Projekte „gemeinsam“ durch? Häufig ist das so, weil die Projektleiter so erzogen worden sind und glauben nur dann ihre Projekte zum Ziel führen können, wenn sie die anderen Projekte aus dem Weg räumen. Ich habe es schon ein paarmal probiert und es klappt auch ohne gegeneinander zu kämpfen. Wie es überall im Leben so ist, oft geht es auch einfach besser, wenn man die Mitarbeiter gemeinsam einplant und managed. Das ist zumindest meine Meinung. Man muss zwar aufpassen, dass die Projekte fair mit Mitarbeitern ausgestattet werden und die einzelnen Projektleiter ihren Job durchführen können, jedoch das Einzelkämpferdasein halte ich für ziemlich idiotisch.

    Blogparade zu folgenden Fragen

    • Was sind eure Erfahrungen?
    • Arbeitet ihr mit euren Projektleiterkollegen zusammen oder führt ihr ein Einzelleben?
    Eine kleine Diskussion zu diesem Thema fände ich toll... Teilnehmen könnt ihr an der Blogparade bis einschließlich 16. Juni, sowohl in den Kommentaren, als auch mit Beiträgen auf eurem Blog. Ich bin gespannt auf eure Berichte.

    Verlängerung bis  24. Juni

    Wer noch mitdiskutieren möchte, kann bis noch bis einschließlich zum 24. Juni, teilnehmen.
  • Bücherliste zu Webdesign, Projektmanagement, Informatik usw.

    Hier im Blog gibts ja bereits die Quellenliste zu Requirements Engineering. Inzwischen ist auch unsere Bücherliste, mit den bei miradlo genutzten, Büchern online. Ganz vollständig ist sie noch nicht, aber wir arbeiten dran. Da es einfacher ist, diese Liste als eigenständige Seite, laufend zu aktualisieren, habe ich mich entschlossen, sie außerhalb des Blogs im allgemeinen Bereich unterzubringen. Die Bücherliste enthält die Titel, die in unseren Bücherregalen zu finden sind. Angefangen haben wir bereits mit Kurzkommentaren zu den Büchern, so dass ihr nachschauen könnt, welche Bücher wir für besonders empfehlenswert halten. Die Kommentare werden wir im Lauf der Zeit noch ergänzen, die Liste als solche natürlich ebenfalls. Wir haben Bücher aus folgenden Bereichen aufgeführt:
    • CSS
    • Webdesign
    • Linux
    • Projektmanagement
    • Informatik
    • Programmieren (PHP, Java...)
    • Usability, Barrierefreiheit usw.
    • Design
    Darüber hinaus haben wir eine kleine Serie der diversen Versionen des Dudens. Das Kochbuch für Geeks ist ebenfalls dabei, eine gute Freundin hat mir das geschenkt. Sicherlich nicht in der Hoffnung, dass ich deshalb koche, sondern eher als Anregung, was ich mir von den kochenenden Menschen in meiner Umgebung wünschen könnte und einfach so zum Amüsieren. Ja, es stimmt, was ihr daraus schließt: ich koche nicht, auch nicht ein bisschen, auch nicht ab und zu. Zumindest dann nicht, wenn es nicht zählt, Tiefkühlgemüse in der Mikrowelle zu erhitzen und wenn die Definition ist, dass Salat nicht gekocht wird. ;-)
  • Episode 8: Vorstudie strukturieren ::: Softwareprojekte

    Ein Projekt ist einmalig. Es ist mit gewissen Risiken verbunden und ist, da es einmalig ist, nicht mit einem anderen Projekt direkt vergleichbar. Das ist eine in allen Lehrbüchern beschriebene Tatsache. Wenn Projekte einmalig sind, wieso geht man dann immer mehr oder weniger gleich an Projekte heran? Ganz einfach: Projekte können anhand bestimmter Eigenschaften klassifiziert werden. Und so ist die Herangehensweise natürlich pro Projekttyp sehr ähnlich. Wenn ich hier jetzt beschreibe, wie die Vorstudie zu strukturieren ist, kann das keine allgemeingültige Beschreibung sein. Es ist eine mögliche Art die Vorstudie zu strukturieren. Wenn man nichts hat, kann man sich hier ein paar Ideen herausfischen. Andere Themengebiete sind nicht relevant oder durch diese Vorstudie nicht abgedeckt. Also: Selber kreativ sein und Hirn einschalten! Nicht alles was Roland sagt stimmt. Normalerweise laber ich sogar ziemlich viel Mist. Das kommt daher, dass es keine einzige Wahrheit gibt. Die Projektmanagementwelt ist bunt und nicht schwarz- weiß. Thomas befragte in der ersten Woche die Entwickler, Giuseppe, den Familienvater der anderen Firma und einige schwere Jungs. Thomas ist (so wie ich) ein bisschen schwer von Begriff. Aber nach der Woche war ihm klar, dass er sich mit einer kriminellen Vereinigung eingelassen hatte und so schnell da nicht mehr herauskommen wird. Welchen Zweck die Betonschuhe und der Familienteich haben wurde ihm auch klar. „Was solls, wenn man schon Mist baut, dann wenigstens Spaß dabei!“, sagte er sich. Da an kündigen nicht zu denken war, entschied Thomas sich das Projekt durchzuführen. Er erstellte eine Vorlage für eine Vorstudie mit folgenden Kapiteln (zu den Begriffen siehe Glossar Informatik):

    Einleitung / Management Summary

    Hier wird auf maximal einer Seite beschrieben was mit dem zu erstellenden System erreicht werden soll. Es soll den Auftraggebern eine Zusammenfassung geben, was sie erhalten und die wichtigsten Eckpunkte auflisten.

    Systemübersicht

    Falls möglich, sollte gleich eine sehr grobe Systemübersicht dargestellt werden.

    Anforderungen

    Auflistung der Eigenschaften die dieses System haben soll. Die Anforderungen werden in funktionale und nicht-funktionale Anforderungen aufgegliedert. Hier kann schon mit Usecases gearbeitet werden. Wie die Anforderungen zusammen gesammelt werden ist im Prinzip nicht wichtig. Hauptsache sie sind eindeutig identifizierbar und so vollständig wie möglich. Beispielsweise kann man jeder Anforderung eine Nummer geben. Diese Nummer kann man später wieder verwenden.

    Funktionale Anforderungen

    Hier wird beschrieben was man mit dem System später machen kann. Zum Beispiel „Anf#82: Verwalten der schweren Jungs“ oder „Anf#98 Auflistung wie viel Schmuggelware abgegeben wurde“ Weiterhin sind funktionale Anforderungen die Beschreibung der Schnittstellen und anzubindenden Systeme.

    nicht-funktionale Anforderungen

    Wie der Name schon sagt- handelt es sich hier um Anforderungen, die nichts direkt mit der Funktion zu tun haben. Im Prinzip ist es egal ob eine Berechnung 100 Tage benötigt. Wenn nach 100 Tagen das Ergebnis der Berechnung vorliegt, hat die Funktion funktionert. Eventuell sind 100 Tage aber ein bisschen lange um 20+30 zu rechnen ;-)

    Sicherheitsanforderungen

    Welche Personen dürfen auf welche Daten zugreifen? Wie schützen wir uns vor anderen Familien oder der Steuerbehörde?

    Geschwindigkeit

    Wie lange darf eine Bearbeitung dauern?

    Mengengerüste

    Wie viele Mitarbeiter, Daten und Zugriffe sind zu erwarten?

    Betreibbarkeit

    Welche Service Levels müssen vereinbart werden? Vor allem bei einem System, indem Personen direkt betroffen sind, muss man sich hier besonders viel Gedanken machen. Wie viel Wartungsfenster sind zu erwarten? Welche weiteren Kriterien sind hier zu beachten? (Rechenzentrumeigenschaften usw.)

    Rechtliche Fragen

    Was erlaubt das Gesetz? Im Fall der Familie: was ist erlaubt und was wird geahndet?

    Desaster Recovery

    Wie schnell müssen welche Funktionen nach einer Katastrophe wieder verfügbar sein? Welche Vorgaben sind in der Firma vorhanden?

    Business Continuity

    Wie wird gewährleistet das im Katastrophenfall die Geschäfte weiter getätigt werden können? Von welchen IT-Systemen ist die Firma abhängig?

    Wartbarkeit

    Gibt es spezielle Anforderungen an die Wartbarkeit der Systeme? Beispielsweise sind die Legacy Systeme weiterhin zu warten. Wie soll das gewährleistet werden?

    Erweiterbarkeit

    Jedes System muss erweiterbar sein. Wo sind die Grenzen? Woran kann erkannt werden, dass diese Grenzen erreicht werden?

    Dokumentation

    Welche Dokumentation (Betriebsdokumente, Sourcecode Beschreibung usw.) muss erstellt werden?

    Stakeholder

    Welche Personengruppen sind im späteren Projekt zu beachten? Je politischer ein Projekt ist, desto wichtiger ist es zu wissen, wen man alles informieren muss. Dieser Punkt kommt zwar später wieder in der Projektbeschreibung, doch schadet es nichts, sich schon sehr bald darüber klar zu werden, wer alles betroffen ist.

    Abgrenzungen

    Was ist nicht Aufgabe dieses Systems? Diese Frage ist sehr wichtig. Ansonsten wird man mit ungeplanten Anforderungen zugeschüttet. Beispielsweise ist das bestehende System deshalb so komplex, da während des Erstellens immer neue Anforderungen hinzugefügt wurden. Hier kann erkannt werden, dass die Vorstudie unter Umständen schon ein eigenes Projekt ist. Bei großen Systemen wird daher die Vorstudie schon als Evaluationsprojekt durchgeführt. Egal wie groß ein Projekt ist, ich kann nur empfehlen eine gewissenhafte Vorstudie durchzuführen. Jede Überlegung in diesem Bereich spart euch hinterher das Vielfache an Ärger, Fehlern und Aufwänden!
  • Episode 7: Requirements für die Vorstudie ::: Softwareprojekte

    An einem verregneten Morgen kam Giuseppe mit einem Fremden zur Türe herein. Hans, Karl und Orlando waren sofort ziemlich nervös. Nie kam Giuseppe persönlich zu ihnen in die Häckerecke. „Ich möchte euch über unsere neuesten Familienaktivitäten unterrichten“, begann Giuseppe. „Wir haben mit einer Familie in einer anderen Stadt funssioniert. Unsere Geschäftsfelder passen optimal zusammen. Die neue Familie hat sich auf die Verteilung von bewusstseinserweiternden Mitteln spezialisiert. Wir sind gut im Geld waschen und zusammen können wir sehr viel Profit für die Familien erwirtschaften. Die andere Familie hat ebenfalls ein Verwaltungssystem und wir müssen unsere Systeme miteinander verschmelzen.“

    Orlando war begeistert

    „Das ist ja toll! Da können wir sicher voneinander profitieren und neue Integrationsmethoden lernen.“ Hans und Karl standen etwas abseits und ihre Gesichtsfarbe glich der Wand. Sie waren schneeweiß. Hans stotterte: „Das bedeutet nicht nur neue Funktionalität sondern eine Erweiterung der Basisfunktionalität. Wir haben kein System erstellt das mandantenfähig oder auf Austausch mit anderen Systemen ausgelegt ist.“ Giuseppe grinste: „Bevor wir weiter reden möchte ich euch Thomas vorstellen. Thomas ist ein Softwarearchitekt und Projektleiter der im Bereich der Fusionierung von Firmen schon mehrmals wahre Wunder vollbracht hat. Wir haben ihn eingestellt um die beiden Firmen sicher miteinander verbinden zu können. Weiterhin haben wir diverse Expansionspläne erarbeitet. Dem Familienrat ist klar, dass unsere heutigen Verwaltungssysteme uns nicht weiter optimal unterstützen können. Das bedeutet wir werden investieren und ihr braucht euch vorerst keine Sorgen um Betonschuhe und Tauchgänge machen.“ Giuseppe verabschiedete sich und Thomas ließ sich von den Dreien in die bestehende Umgebung einführen.

    Eintrag in das Projekttagebuch von Thomas

    Wie immer endete der erste Tag mit „das schaff ich nie“ Gedanken. Davon lass ich mich natürlich nicht abschrecken. Die drei Kollegen sind ziemlich eingeschüchtert und haben Angst. Ich bin neu in der Firma und werde das Problem hoffentlich bald erkennen. Was Giuseppe mit den Betonschuhen und Tauchgängen gemeint hat, verstehe ich noch nicht. Folgende Punkte habe ich bereits erkannt:
    • Giuseppe scheint ein ziemlich unstrukturierter Auftraggeber zu sein. Seine Ziele sind unklar und müssen genauer analysiert werden.
    • Die Firma befindet sich in einer Fusionierungsphase und das bedeutet einen enormen Change, sowohl bei der Infrastruktur wie auch bei den Mitarbeitern.
    • Die Fähigkeiten der drei Entwickler schätze ich als ausreichend ein. Sie sind Bastler und müssen zuerst an eine vernünftige Vorgehensweise gewöhnt werden.
    • Das Verwaltungssystem ist monolitisch aufgebaut.
    • Es besteht aus Eigenentwicklung ohne offenen Standards
    • Die Strategie und die Pläne der Firma sind nicht klar beschrieben. Hier muss eine umfassende Anforderungsanalyse durchgeführt werden.
    • Projektmanagement-Prozesse und -Vorlagen sind nicht vorhanden

    Was hat Thomas an seinem ersten Tag gemacht?

    Er hat begonnen sich ein allgemeines Bild der Lage zu machen. Er hat die vorhandenen Rahmenbedingungen abgesteckt. Am ersten Tag ist es unmöglich schon alles zu überblicken. Er muss sich an das Thema herantasten. Mit seiner Aufzählung hat er weiterhin begonnen eine Schwachstellenanalyse durchzuführen. Die Eckpunkte werden ihm helfen die Vorstudie erstellen zu können. Das bedeutet, dass man eine Vorstudie erst erstellen kann, wenn man hierfür schon diverse Anforderungen zusammengestellt hat. Diese Aussage klingt logisch, doch einige Kollegen erstellen Vorstudien ohne das tatsächliche Problem zu beschreiben. Vor allem bei Projekten die ähnlich aussehen wie bereits erstellte, verfällt der Projektleiter gerne in den Modus „Hey das kenne ich, das mach ich gleich nochmal!“ Ich kann davon nur abraten. Ein paar Stunden, oder gar Tage, Anforderungen zusammen tragen, spart im Projektverlauf das vielfache an Ärger und Kosten. Einen Nachteil hat diese Vorgehensweise: Niemand bekommt hinterher mit, dass sinnvolle Vorarbeit geleistet wurde. Das kann manchmal ziemlich frustrierend sein. Aber so ist das Projektleben. Wenn es gut läuft wird niemand etwas vom Projekt mitbekommen. Dann ist es einfach fertig gestellt worden.
  • April, 2008
  • Fish & Chips Incident-Process

    Ein anderer Titel für diesen Blog ist: „How to get a cup of coffee for free, learn about Incident management and understand the need for a security concept.“ Doch dieser Titel ist etwas lange... Ich war mal wieder „dienstlich“ in England unterwegs. Eigentlich sollte ich für meine Firma herausfinden, was man dort alles besser machen kann. Nun zumindest für das Leben habe ich etwas gelernt. Trotz, oder wegen, meines Übergewichts kann ich nicht darauf verzichten Fish & Chips zu kaufen. Natürlich mit Salt and Vinegar. Also, ich gehe in den nächsten Futterladen und finde vier Frauen und einen Mann vor. Die Personen möchte ich mit Fischfrau 1, Fischfrau 2, Fischfrau 3, Cheffischfrau und John den Fischgriller bezeichnen. Mich selbst nenne ich Kunde 1. Fischfrau 1: "Hello" Kunde 1: "Hello, one fish and chips please." Fischfrau 1: "John, one fish and chips please!" John stürzt sich an die Fritiermaschine und der Fisch wird generiert. Fischfrau 1: "3,50 please." Kunde reicht eine zwanzig-Pfund-Note. Fischfrau 1 benutzt die Registrierkasse und liefert 6,50 Pfund zurück. Außerdem schließt sie die Kasse. Kunde 1 wundert sich und erwähnt, dass er gerne noch zehn Pfund change mehr hätte. Immerhin bedeuten zehn Pfund später ungefähr drei Biere, die Kunde 1 benötigt um diesen Blog formulieren zu können.

    Juchu! Wir haben einen Incident!

    Fischfrau 1 erkennt, dass sie einen Fehler gemacht hat. Sie ruft nach der Cheffischfrau. Das klappt aber nicht, da Fischfrau 2 besorgt heranstürmt und sich die Sachlage erklären lässt. Das Problem lässt sich schnell und einfach eingrenzen. Kunde hat zwanzig Pfund gegeben und nur für zehn Pfund Ware und Geld erhalten. Die beiden haben eine erste Lösung erarbeitet. Fischfrau 2 fragt den Kunden 1, ob er wirklich zwanzig Pfund gegeben hat. Dieser beantwortet die Frage mit „yes“. Beide Fischfrauen rufen nach der Cheffischfrau und erklären dem Kunden „I am sorry“. Ein weiterer Kunde kommt vorbei und fragt wie lange der Fischladen heute offen hat. Fischfrau 2 sagt ihm, dass bis um halb zehn offen ist. Es wird ein weiteres „I am sorry“ dem Kunden 1 entgegen geschmettert. Dieser denkt sich noch nichts dabei, da John den Fisch fertig gebraten hat und in den Fischzwischenspeicher überführt hat. Die gesamte Aufmerksamkeit des Jägers (Kunden 1) ist nun auf den Fisch gerichtet. Eventuell kann via Telepathie der Fisch herüberwachsen? Cheffischfrau erscheint und erkennt, dass die Kasse geöffnet werden muss. Cheffischfrau: „John, I need the key!“ John liefert den Schlüssel an Fischfrau 3, die sich an Fischfrau 1, Fischfrau 2 und Cheffischfrau vorbeizwängt um die Kasse zu öffnen. Cheffischfrau generiert eine Abrechnung der Kasse. Hierzu wird der Saldo über alle vorhandenen Tagestransaktionen ausgedruckt. Fischfrau 1 steht nebenan und ist vollkommen von Scham und Schande eingewickelt. Sie kann außer '„I am sorry“ sagen' nichts mehr tun. Cheffischfrau fängt an, vor allen Gästen die Münzen, die sich in der Kasse befinden, zu zählen. Die weiteren Kunden bezahlen ohne change zu benötigen. Dreimal klappt das auch und Fischfrau 2 und 3 können die Lage unter Kontrolle halten. Beim Kunden 4 geht das schief. Er benötigt Wechselgeld. Der Betrieb muss eingestellt werden. Eine Schlange williger Fischkäufer bildet sich. Fischfrau 1 kann kaum noch atmen, generiert jedoch in regelmäßigen Abständen ein „I am sorry“. Kunde 1 beteuert, dass so etwas ja mal passieren kann. Die weiteren Kunden sehen das vermutlich anders und beginnen den Kunden 1 als alleinigen Schuldigen zu deklarieren. Cheffischrau ist mit dem Zählen der Münzen durch und macht sich an die Scheine. Kunde 1 beginnt Strategien zu erarbeiten.
    • Geld zurück geben lassen?
    • 10 Pfund abgeben und auf drei Biere verzichten? (kaum vorstellbar)
    • Weiter lächeln oder doch den deutschen Proll auspacken?
    • Einfach gehen und zwanzig Pfund abschreiben? (sicher nicht, bin Schwabe)
    • Kontrolle, ob er tatsächlich 20 Pfund übergeben hat oder ob der Fehler doch bei ihm liegt. (klingt verlockend und wird als Zwischenlösung angesehen.)
    Cheffischfrau hat fertig gezählt. Alle vier Frauen und John ziehen sich nach hinten zurück und beraten die Lage. Kunde 1 hört ein paar sehr beunruhigende Worte: „I can't pay him 10 pound back!“ Nach weiterer Kontrolle kommt Cheffischfrau wieder nach vorne. „You gave us 20 pound?“ Kunde 1 bejaht. Sie zeigt die Kassenabrechnung und ihr Zählergebnis. Die Zählung ergab, dass sich 978,50 Pfund in der Kasse befinden. Die Abrechnung behauptet, dass nur 968,50 Pfund vorhanden sein sollen. Es könnte also durchaus sein, dass der Kunde 1, zehn Pfund zu wenig Wechselgeld erhalten hat. Die Entscheidung ist getroffen worden, der Kunde 1 erhält zehn weitere Pfund zurück. Fischfrau 3 fragt Kunden ob er ein "Coffee" aufs Haus haben will. Dieser bejaht. Fischfrau 2 verpackt den Fisch und fragt nach salt & vinegar. Fischfrau 1 japst ein letztes „I am sorry“. Kunde 1 wird mit seinem Fisch, Geld und Kaffee entlassen und verschwindet. Der Incident-Fall wird abgeschlossen.

    Ergebnis des Incidents:

    Mindestens vier Gäste sind verschwunden und entschieden sich für Diät oder einen anderen Fischladen. Der Incident verursachte 15 Minuten Stillstand im Laden. Weiterhin mussten Löhne für 5*15 Minuten bezahlt werden was somit 75 Minuten Arbeitszeit ausmacht. Ein Kaffee (Kosten ca. 50 Pence) musste mitgegeben werden. Für die 15 Minuten musste die Arbeit eingestellt werden und dennoch Raummiete, Strom usw. bezahlt werden.

    Folgende Behauptung wird aufgestellt:

    Wenn die 10 Pfund sofort zurückgegeben worden wären, wären die Kosten geringer gewesen. Faszinierend finde ich allerdings, dass sich Cheffischfrau nicht verzählt hat. :-) Jetzt kommt aber der Hammer! Stellt euch vor ich wäre ein Krimineller.
    • Ich weiß, wann der Fischladen zugemacht wird (halb zehn)
    • Ich weiß, dass mindestens 968,50.- Pfund in der Kasse vorhanden sind.
    • Ich komme um halb zehn mit meinem Freund Revolver vorbei und erhalte nicht nur einen Kaffee umsonst sondern auch noch 968,50 Pfund.
    Daraus folgt, dass der Verlust sich um mindestens 968,50 Pfund erhöht. Der Incident Prozess führt zu sehr hohen Verlusten. Es wird den Verbrechern direkt mitgeteilt was an einem Freitag ungefähr in der Kasse ist. => Die Gefahr dass die Räuber am Freitag öfters vorbei kommen wird erhöht. Gegenmaßnahmen:
    • Zählen von Geld immer ohne direkten Blickkontakt der Kunden
    • Security Konzept ist notwendig und führt zu einem sichereren Betrieb.
    • Keine 1000 Pfund in der Kasse deponieren. Ab- und zu mal Geld entfernen und an einem sicheren Ort lagern.
    • Fünf Personen sind für den Fischladen gleichzeitig zu viel. Man kann z.B. mit drei Personen den Laden laufen lassen und die Ladenöffnungszeiten mit gleichem Personal verlängern. Die treten sich dann nicht auf den Füßen herum und haben alle ein bisschen was zu tun.
    • Die Mehreinnahmen können zu mehr Lohn für die Mitarbeiter führen.
    • Mehr Spaß an der Arbeit, da sie nicht mehr so langweilig ist.
    Ich werde jetzt auf alle Fälle meinen Job kündigen und mich als Fischladen-Optimierer durchschlagen. ;-)
  • Episode 6: Grenzen des Refactorings ::: Softwareprojekte

    Zu Episode 1 wurde ein Kommentar geschrieben der mir zeigte das auch noch andere Mitstreiter das Problem des Refactorings aktiv angehen. Die Aussage „Andererseits weiß ich, dass wenn ich die Firma verlasse, dann werden die Projekte andere nach mir übernehmen und wieder alles reverseengeneeren müssen. ...wenn ich das Unternehmen verlasse, muss von vorne begonnen werden“ fand ich sehr passend. Mit Refactoring kann man nicht die Welt retten. Ein Softwaresystem ist für mich wie ein lebender Organismus. Unsere Haut wird beispielsweise alle sieben Jahre erneuert. Bei Software verhält sich das im Prinzip genauso.

    Orlando war mal wieder auf einer Schulung

    Ok, da war er schon in Episode 3 und das hat auch seinen Grund. Orlando ist Single und liebt es in Hotelzimmern herumzuhängen. Da das Familienunternehmen zur Zeit noch nicht in mehreren Ländern vertreten ist, ist es für ihn die einzige Möglichkeit das Jet-Set-Gefühl zu erleben. Bei der Schulung wurde der Model Driven Architecture-Ansatz besprochen. Wieder kam er freudestrahlend zurück und wollte das Erlernte sofort ausprobieren. Das ist auch eine typische Orlando Eigenschaft. Er nimmt gerne Neues an und versucht so viel wie möglich gleich zu implementieren. Da es sich bei dem, von Hans, Karl und Orlando, betreuten System um ein hochriskantes, produktives System handelt, ist diese Freude an Neuem für Hans und Karl nicht unbedingt nachvollziehbar. Zuweilen sind Orlandos Kollegen sonderbar altmodisch und wollen vor allem ein überlebensfähiges, stabiles System haben. Vielleicht liegt das an den Betonschuhen die am Ausgang von den schweren Jungs abgestellt wurden... Wie dem auch sei. Hin- und wieder werden Hans und Karl von Orlando überredet etwas Neues zu implementieren. Die Drei wollten erreichen, dass die Entwicklung auf Dauer gesehen immer stabiler und sicherer wird. Deshalb schauten sie sich ihr System genauer an und überlegten ob Model Driven Architecture eventuell eingeführt werden kann.

    Keine Architektur?

    Karl schaute sich die bisherigen Architekturkonzepte an. „Also im Moment sind wir mit einem Mischmasch zwischen prozeduraler Programmierung und objektorientierter Programmierung konfrontiert. Wenn wir das ändern wollen, müssen wir das ganze System am Besten wegwerfen und neu bauen.“ Die drei waren sich hier sehr einig. Ein Neubau würde jedoch einem langanhaltenden Tauchgang im Familienteich nahe kommen. „Vielleicht können wir uns wenigstens eine Architektur überlegen wie es aussehen sollte und das als unsere Strategie definieren. Dann könnten wir beim Review darauf achten in die Richtung der Strategie zu arbeiten“, bemerkte der geschulte Orlando. Hans nickte zustimmend. „Das klingt schon eher machbar. Wir werden also mit dem Refactoring keine endgültige Lösung finden. Wir werden die, zur Zeit erkannten Fehler und Missstände, aufdecken und korrigieren können. Das System wird also nie fertig werden.“ Orlando überlegte: „Ich glaube, dass ist eine normale Eigenschaft in komplexen Systemen. Jede neue Idee führt zu einer Änderung und diese Änderung erfordert neue Vorgehensweisen. Ich glaube das Geheimrezept liegt im Changemanagement und in der Umsetzung der Strategievorgaben. Lasst uns zuerst einmal eine Strategie für die nächsten drei- bis fünf Jahre definieren. Wir sollten dringend mit Giuseppe reden um zu erfahren was er alles vor hat. Dann können wir unsere IT-Bemühungen entsprechend auslegen.“ Vielleicht habt ihr euch schon hin- und wieder gefragt warum Firmen viel Geld für Enterprise Architektur ausgeben. Ich habe im Moment das Vergnügen mit den Architekten eng in einer Gruppe zusammen arbeiten zu können. Die Kollegen produzieren im Prinzip (außer Papier und endlosen Telefongesprächen ;-) ) nichts. Doch der Gewinn für die Firma ist, dass sie sich über die weiteren Jahre Gedanken machen. Es ist wichtig die IT-Landschaft, wie jede andere Prozesslandschaft, über die Jahre hin proaktiv zu bewirtschaften. Unsere drei Freunde haben aus Angst vor Betonschuhen bisher nur reagiert. Mit dem Handwerkzeug Reverse Engineering, haben sie erreicht sich über Wasser zu halten und nicht zusammen mit ihrem alten System zu sterben. Doch um wirklich eine gute Zukunft zu haben, kommen sie um eine Strategie und eine sinnvolle Planung nicht herum. Es wird Zeit das wir eine Koordination in die Geschichte bringen! Um ehrlich zu sein, ich bin gespannt wo dieses Blog noch hinführt...

Seite 2 von 4, insgesamt 28 Einträge