Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung | Nächste Überarbeitung Beide Seiten der Revision | ||
se:nofrills [2008-12-30 20:22] stefan |
se:nofrills [2008-12-30 20:44] stefan |
||
---|---|---|---|
Zeile 9: | Zeile 9: | ||
==== Problemverständnis ==== | ==== Problemverständnis ==== | ||
- | |||
* Verstehe das ganze Problem in voller Breite | * Verstehe das ganze Problem in voller Breite | ||
* Entwicklern fehlt häufig das Domänenwissen -> Fehler aufgrund mangelnden Domänenwissens sind teuer (da sie meist spät erkannt werden) | * Entwicklern fehlt häufig das Domänenwissen -> Fehler aufgrund mangelnden Domänenwissens sind teuer (da sie meist spät erkannt werden) | ||
Zeile 31: | Zeile 30: | ||
* die Entwickler sollen nicht einfach die Lösungen der Fachbereiche implementieren, sondern vielmehr die Probleme verstehen und Lösungen anbieten | * die Entwickler sollen nicht einfach die Lösungen der Fachbereiche implementieren, sondern vielmehr die Probleme verstehen und Lösungen anbieten | ||
* die Hinterfragung der Aspekte hinsichtlich Lösung (Design) oder Problem (Anforderung) führt zu einem tieferen Verständnisses des Problems und somit zu einer besseren Abwägung der verschiedenen möglichen Lösungen | * die Hinterfragung der Aspekte hinsichtlich Lösung (Design) oder Problem (Anforderung) führt zu einem tieferen Verständnisses des Problems und somit zu einer besseren Abwägung der verschiedenen möglichen Lösungen | ||
+ | |||
+ | ==== Wertorientierung ==== | ||
+ | * Teste, validiere und überprüfe das Wesentliche | ||
+ | * nach Möglichkeit sollten nur die Programmteile erneut qualitätsgesichert werden, die geändert wurden | ||
+ | * kritische Programmteile (die der Anwender zu Gesicht bekommt) sollten intensiver getestet werden -> subjektiv höhere Qualität der Software | ||
+ | * Fordere schlanke Lösungen | ||
+ | * zu jedem Zeitpunkt der Entwicklung sollte versucht werden, weniger Software zu erstellen | ||
+ | * Pareto-Prinzip: wenn mit 20% Entwicklungsaufwand 80% des Tagesgeschäfts behandelt werden kann, müssen die verbleibenden 20% die Weiterentwicklung rechtfertigen | ||
+ | * Möglichkeiten zur Automatisierung sollten ausgeschöpft werden | ||
+ | * kann die Anforderung auf eine andere Art erfüllt werden? | ||
+ | * was passiert, wenn wir die Anforderung weglassen? -> häufig nichts | ||
+ | * Produktivität = Nutzen / Aufwand | ||
+ | * die Produktivität ist besonders hoch, wenn mit wenig Aufwand schlanke Lösungen gefunden werden, die viele Anforderungen abdecken | ||
+ | |||
+ | ==== Technik ==== | ||
+ | * Design von außen nach innen | ||
+ | * Informationssysteme müssen meistens in eine bestehende Systemlandschaft integriert werden (keine "grüne Wiese") | ||
+ | * Integration-Engineering dominiert -> nicht erst das neue System planen und dann über die Integration zum Altsystem nachdenken | ||
+ | * Prüfe Sourcing-Möglichkeiten | ||
+ | * meist werden Aufgaben im Team anhand von Interessen oder aktueller Auslastung der Mitarbeiter verteilt -> unglückliche Aufgabenverteilung (z.B. Implementierung unternehmenskritischer Anforderungen durch externe Partner) | ||
+ | * die Frage der Aufgabenverteilung sollte strategisch entschieden werden | ||
+ | * Vermeide technologische Debatten | ||
+ | * Technologiediskussionen verlieren sich schnell im Detail und arten in Glaubenskriege aus | ||
+ | |||
+ | ==== Team und Qualität ==== | ||
+ | * Professionelle und fokussierte Kommunikation | ||
+ | * Stakeholder müssen immer auf dem Laufenden sein -> die Informationen sind jedoch meist überfrachtet und nicht priorisiert, sodass das wichtige unter den Tisch fällt | ||
+ | * die richtigen Informationen müssen zur richtigen Zeit in der richtigen Form vermittelt werden | ||
+ | * Beispiel Anwender: sie dürfen keine überzogenen Vorstellungen an das System haben, sondern die Fähigkeiten realistisch einschätzen können | ||
+ | * Wähle die passenden Sprachen und Werkzeuge für die Stakeholder | ||
+ | * Fließtext des Fachbereichs hilft den Entwicklern nicht (zu schwierig), UML der Entwickler hilft dem Fachbereich nicht -> Lösung: vereinfachte Form der UML oder nur intuitiv verstehbare Modelltypen verwenden | ||
+ | * Überprüfe auf No-Frills-Prinzipien | ||
+ | * viele Unternehmen kennen ihre eigenen Entwicklungsprozesse nicht oder sie werde mit der Zeit immer fetter | ||
+ | * regelmäßige Retrospektiven sind erforderlich um den Prozess zu optimieren | ||
+ | |||
+ | ===== Hauptaktivitäten ===== | ||
+ |