Freitag, 28. Februar 2014

Arbeitsumgebung kann Kreativität töten.

These: Menschen die sich wohl fühlen, Menschen die geachtet werden schaffen beachtliche Software.

Im Post Teambildung als bewusster Prozess habe ich dafür plädiert, die Bedeutung von sich selbst erschaffenden und langfristig existierenden Teams anzuerkennen. Die Leistungsfähigkeit eingespielter Teams scheint mir um ein Vielfaches höher als von Menschen, die wie Dinge aus einem Pool geholt und je nach Laune in neue Teams gesteckt werden. Für diese Zusammenschlüsse von Arbeitsgemeinschaften würde ich das Wort Team nicht benutzen. Jedesmal beginnt der Teambildungsprozess von vorn. Die Phasen Forming, Storming und Norming reduzieren die Leistung, bei Scrum muss die velocity immer wieder neu bestimmt werden und Leute, bei denen die Chemie nicht stimmt, haben keine Chance, langfristig ein zu Hause in anderen Teams zu suchen. Die Liste ließe sich um einiges verlängern. Doch wo das Management diese Prozesse beherrscht, baut sich ein gewaltiger Konkurrenzvorteil auf.

Freitag, 21. Februar 2014

Die Attributierung der Objekte in der Umsetzung.

Ein System zur Anforderungsentwicklung in der Umsetzung.

Artikelübersicht
1. Teil Mit dem Zustandsmuster beginnt die Umsetzung eines Requirements Engineering.
2. Teil Die Attributierung der Objekte in der Umsetzung.


Im zweiten Umsetzungspost zum Requirements Engineering möchte ich auf spezifische Ableitungen des RequirementsObject zu sprechen kommen. Bisher sind uns einige spezifische Objekte des Objekt-Aufgaben-Modells in den theoretischen Posts über den Weg gelaufen. Zuerst ist uns das Ideenobjekt (Idea) begegnet. Die unterschiedlichen Stakeholder haben die Möglichkeit Ideen zu sammeln. Später werden diese in Themen (Issue) zusammengefasst. Für Themen werden Systemkontextuntersuchungen veranlasst, in denen Kontextobjekte (Context) geschaffen werden. Um planbare Systeme zu schaffen, habe ich an dieser Stelle User Stories (UserStory) eingeführt. Natürlich wird es im weiteren Verlauf des Requirements Engineering weitere Objekte geben.

Freitag, 14. Februar 2014

Praktisches Beispiel zu User Stories.

Beispiel zum System der Anforderungsermittlung

Artikelübersicht
1. Teil Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.
2. Teil Praktisches Beispiel zur Kontextuntersuchung.
3. Teil Praktisches Beispiel zu User Stories.
4. Teil Drei Basismodelle guter Software im praktischen Beispiel.
5. Teil Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.
6. Teil Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.


Der erste Post zu den praktischen Beispielen erläutert, wie Stakeholder ihre Ideen notieren, die Ideen sich zu Themen gruppieren und die Themen eine natürliche Roadmap erzeugen. Im zweiten Post zu den praktischen Beispielen wurde auf die Systemkontextanalyse eingegangen, die notwendig ist, für ein tiefes Verständnis des Umfeldes des künftigen Softwaresystems und Voraussetzung zum Verstehen des zu lösenden Problems. Das Verstehen der Domäne öffnet uns auch den Blick für die Schwierigkeiten der IST-Prozesse. Die Optimierung der Prozesse und das Herausfiltern der zu automatisierenden Prozessschritte und der künftigen Features einer zu schaffenden Software ist ein Arbeitsschritt, der im ganzen Team erfolgen sollte. In einem Post zu Explorationen zeige ich auf, wie wichtig die Explorationen in dieser Phase sind. Die gemeinsame Anstrengung führt zu optimalen Systemen, die für den Kunden von hohen Nutzen sind. Die ersten Entdeckerarbeiten finden bei der Optimierung der Prozesse statt. Weitere Entdeckungen können beim Bedenken der zukünftigen Features der Software gemacht werden, die dann für die Umsetzung in User Stories notiert werden, genau wie die umzusetzenden optimierten Prozesse.

Freitag, 7. Februar 2014

Die Analyse des Problemraums führt zum Zielmodell.

These: Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.

Eine Software wird oft entwickelt, weil ein Problem gelöst werden soll. Prozesse werden automatisiert, menschliche Tätigkeiten werden durch den Prozessor ersetzt und Aktenschränke verschwinden auf Festplatten. Damit die Entwicklung weiß, was von diesen Dingen wirklich umgesetzt werden soll, muss zuerst eine Problemanalyse durchgeführt werden. Erste Schritte einer Problemanalyse wurden bereits in der Systemkontextanalyse durchgeführt. Dort wurde der Schwerpunkt auf das Verstehen des Systemumfeldes gelegt, aber es wurden auch Prozesse analysiert und vor allem optimiert. Das Optimieren eines Prozesses ist jedoch nur möglich, wenn man eine IST-Analyse durchgeführt hat und nachfolgend eine Schwachstellenanalyse. Die Schwachstellenanalyse hat Probleme aufgedeckt, die in der Optimierung des Prozesses abgestellt wurden.