Samstag, 27. Juli 2013

Demokratische Teamstrukturen

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

Der Satz, "eine Unternehmen ist keine Demokratie", habe ich schon von mehreren Seiten zu Gehör bekommen. Besonders leitende Persönlichkeiten scheinen demokratische Strukturen als Bedrohung zu empfinden. Dabei wird die ganze Kiste der Ressentiments gegen die Demokratie aufgefahren. Denkt man darüber nach, beschleicht einen die Empfindung, dass diktatorische, zentralistische Systeme als effektiver empfunden werden. Meine Geschichtswahrnehmung hat jedoch Anderes gesehen. Mit der Freisetzung von Demokratie kam es zur Explosion von Kreativität und Produktivität. Die Explosionen autokratischer Denkmuster sind zumeist menschenverachtender, wenn nicht gar noch schlimmerer Art. Deswegen denke ich, es ist an der Zeit Demokratie im Team zu wagen.

Montag, 22. Juli 2013

Ordnung für Use Cases und User Stories durch Funktionsgruppen

These: Gut kommunizierte Software ist ein Segen für die Zukunft.

Artikelübersicht
1. Teil Ordnung für Use Cases und User Stories durch Funktionsgruppen.
2. Teil Von den Funktionsgruppen zu logischen Komponenten.
3. Teil Von der logischen Komponente zur technischen Komponente.


Das Ergebnis des Requirements Engineering ist eine systematische Dokumentation der Anforderungen eines zu erstellenden Softwaresystems. Je nachdem, wie die Anforderungen erhoben und mit welchen Mitteln sie dokumentiert wurden, liegen eine Menge von User Stories oder Use Cases vor. Im weiteren Verlauf werden User Stories oder Use Cases für den Entwurf einer Architektur verwendet.

Am Anfang bilden wir Bereiche gleicher oder ähnlicher Funktionalitäten und ordnen die passenden User Stories oder Use Cases in diese Bereiche ein. "Die Funktionsbereiche können sich gegenseitig verwenden, zwischen ihnen fließen Daten, und sie können sich hierarchisch enthalten." [S.347, REUS09]

Mittwoch, 17. Juli 2013

Nutzerrollen, Personas und extreme Charaktere

These: Systemkontextanalyse öffnet die Augen für optimale Software

Artikelübersicht
1. Teil Kontextaspekt Stakeholder.
2. Teil Nutzerrollen, Personas und extreme Charaktere.
3. Teil Organisationsstrukturen.


Im Post Kontextaspekt Stakeholder habe ich ein Modell zur Erfassung von Stakeholdern beschrieben. Dieses Modell möchte ich für die Aspekte der agilen Softwareentwicklung erweitern. Dort werden durch User User Stories formuliert. Ein mögliches Template für eine User Story ist

"Ich als (Rolle) möchte (Funktion), damit (Geschäftswert)." [S.100, COHN10]

Ein User tritt in einer bestimmten Rolle auf. Damit eine umfangreiche Sammlung von User Stories erstellt werden kann, müssen die User in verschiedene Nutzerrollen segmentiert werden.

Freitag, 12. Juli 2013

Systemanalyse – vielleicht doch erst mal eine Architektur

Praktisches Beispiel 1.3

Artikelübersicht
1. Teil Reengineering - Die Analyse des Altcodes.
2. Teil Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil Schon Vorhandenes nutzen wäre schneller gewesen
6. Teil Reengineering – Am Ende gab es nur noch eine Schnittstelle.


Ein weiteres Architekturmeeting diskutiert grundlegende Probleme der Architektur. Auch hier ist die Anwesenheit mehrerer Teammitglieder Garant für mehr Qualität. Jeder hat seine eignen Ideen, sieht Fehler und kann somit zu besserem Code beitragen.

Software wird nicht nur durch ein vergessenes Requiremens Engineering belastet, sondern auch durch einen fehlenden Architekturentwurf. Über die Jahre der "Codepflege" kann dieser aber auch im Chaos der "Verbesserungen" verschwunden sein. Es gibt keine Architektur, die den Code in kleine beherrschbare Strukturen unterteilt, die Verantwortlichkeiten benennt, so dass man schon weiß, wohin der entsprechende Code gehört.

Sonntag, 7. Juli 2013

Kontextaspekt Stakeholder

These: Systemkontextanalyse öffnet die Augen für optimale Software

Artikelübersicht
1. Teil Kontextaspekt Stakeholder.
2. Teil Nutzerrollen, Personas und extreme Charaktere.
3. Teil Organisationsstrukturen.


Im Folgenden werde ich ein Modell und eine Schablone zur Erfassung von Stakeholdern entwickeln. Im Post Welche Arten von Kontextobjekten gibt es? ist der Begriff des Stakeholders bereits definiert worden. Man kann ihn im Deutschen auch Interessenhalter nennen, also eine Person, die ein direktes oder indirektes Interesse an dem betrachteten Projekt besitzt.

Dienstag, 2. Juli 2013

Gedanken zu Reaktionen

Allgemeines

Es ist ein weiterer Monat ins Land gegangen. Trotzdem stehe ich noch ganz am Anfang. Die Frage, die mich umtreibt, ist, wie kann ich eine Diskussion entfachen, in der ich ganz viel lernen kann. Gespannt bin ich vor allem auf Ideen und Reflektionen, wie man sie eigentlich in der Breite nur im Internet erfahren kann. Viele verschiedene Menschen ganz unterschiedlicher Begabungen, ganz unterschiedlichen Könnens haben die Möglichkeit, sich in freier Diskussion auszutauschen. Man kann dabei Menschen entdecken, mit denen man gerne Kontakt aufnehmen möchte und wo eine einfache Kritik zu einem Austausch von Gedanken führt.