Freitag, 25. Juli 2014

Hochsensible sind nichts Besonderes.

HSM und Softwareentwicklung

Artikelübersicht
1. Teil Sind alle Menschen gleich?
2. Teil Hochsensible sind nichts Besonderes.


Im letzten Post schrieb ich, dass Hochsensible (HSM) oft als Sensibelchen diskreditiert werden. In einem Kommentar wurde das persönliche Empfinden diesen Menschen gegenüber als überempfindlich und unter Dauermigräne leidend beschrieben. Es scheint eine besonders positive Eigenschaft zu sein, Härte gegen Andere und gegen sich selbst zu zeigen. Sensibilität wird kaum als positive Eigenschaft im Arbeitsleben wahrgenommen. In vielen Fällen wären Desaster jedoch zu vermeiden, wenn die Kontrollleuchten sensibler Menschen gesehen werden würden. An anderer Stelle wurde geäußert, dass HSM besser nicht als Programmierer einzusetzen wären. Falls sich diese Ansicht durchsetzt, würden 15 bis 20 % der Menschheit ausgeschlossen, nur weil sie so sind, wie sie sind. Viele Talente würden einfach verloren gehen, befinden sich doch in dieser Gruppe viele kreative Menschen, die in Bezug auf die Programmierung sehr begabt sind.

Freitag, 18. Juli 2014

Ohne Abnahmekriterien läuft nichts.

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.


Im folgenden Post möchte ich ein sehr wichtiges Thema im Requirements Engineering behandeln, die Kriterien für die Akzeptanz bzw. die Abnahme von Software. Immer wieder habe ich erlebt, wie der Kunde sich auf den Standpunkt stellte, das wollte ich aber ganz anders. Zu diesem Zeitpunkt war das entsprechende Feature die gesamte Produktionskette durchlaufen. Es waren Tage, manchmal auch Wochen investiert. Nun musste der bestehende Zustand analysiert werden und die gewünschten Änderungen aufwendig in das schon Bestehende eingebaut werden. Manchmal hat man zu einem späteren Zeitpunkt immer noch nicht begriffen, wie wichtig eine sorgsame Analyse ist. Mehrere dieser Arbeitsgänge werden ausgeführt, bevor der Kunde sein Feature bekommt und richtig glücklich ist er dann zu diesem Zeitpunkt verständlicherweise auch nicht mehr.

Freitag, 11. Juli 2014

Managementaufgaben zwischen Fremd- und Selbstverwaltung.

Managementaufgaben

Artikelübersicht
1. Teil Managementaufgaben zwischen Fremd- und Selbstverwaltung.
2. Teil Was soll ich zuerst tun? Die Qual der Wahl.
3. Teil Prioritäten verteilen ist eine Kunst.
4. Teil Nur ein Fool wählt gleich ein Tool und ein Plädoyer gegen Monsterprogramme.
5. Teil Wer weiß schon, was alles dazu gehört? Von der Lust oder Unlust zur Versionsverwaltung.
6. Teil Im Dschungel der Nachvollziehbarkeit.
7. Teil Gib Deiner Version einen nachvollziehbaren Namen.
8. Teil Das Erstellen reproduzierbarer Software Releases.


Bisher haben wir uns mit dem Dokumentieren von Anforderungen beschäftigt. Dabei sind auf der Grundlage des Objekt-Aufgaben-Modells eine Fülle verschiedener Artefakte erzeugt worden. Das geschah durch beauftragte Tätigkeiten. Diese Artefakte (Objekte) und Tätigkeiten (Aufgaben) müssen geplant und verwaltet werden. Neben der reinen Dokumentation muss es demzufolge ein Management geben, welches die notwendige Planung, Steuerung und Kontrolle im Auge behält. Das Management muss die Aktivitätsausführung kontrollieren und steuern. [POH08] spricht im Requirements Engineering allgemein von den Phasen Gewinnung, Dokumentation, Übereinstimmung und Validierung. In meiner Prozessreihe setzte ich mich mit der Abfolge notwendiger Arbeitsschritte innerhalb der Softwareentwicklung auseinander. Deshalb werde ich in dieser Managementreihe zugunsten dieser Reihe auf prozessuale Beschreibungen verzichten.

Freitag, 4. Juli 2014

Warum ist unsere virtuelle Firma nur ein Torso?

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Das Gedankenexperiment einer virtuellen Firma hat im letzten Post dieser Reihe ein Entwicklerteam geschaffen. Damit besteht die Möglichkeit Dinge herzustellen. Das ist innerhalb einer Marktwirtschaft jedoch nicht ausreichend. Das Anstellen des Produktionsmotors, der Produkte ausspuckt und auf den Markt wirft, reicht bei weitem nicht aus. Am Anfang und am Ende dieses Vorgangs fehlen wesentliche Schritte zum Erfolg. Vor- und nachbereitende Schritte sowie organisatorische Leistungen werden in unserem Denken oft unterschätzt.