Freitag, 25. September 2015

Die geltende Geschäftspraxis steht einem guten Requirements Engineering entgegen.

These:Gute Software benötigt gute fachliche Anforderungen.

Im Requirements Engineering sollen Anforderungen an eine Software möglichst genau aufgenommen werden. Auf dieser Grundlage wird dann eine Anwendung erstellt, die zum größtmöglichen Nutzen eingesetzt wird. Soweit der Anspruch. In der Wirklichkeit schlägt dieses Unterfangen oft fehl. Die Welt ist zu oft in Auftraggeber und Auftragnehmer aufgeteilt, die nicht am selben Strang ziehen. Gegensätzliche Interessen verhindern das Ziel zu erreichen. Auf der einen Seite steht das Softwareunternehmen. Es versucht möglichst viel Geld zu verdienen mit möglichst wenig Arbeit. Der Austausch eines Logos für 10.000 € wird so zum Sieg. Der Kunde wurde ausgetrickst und wenn alles gut geht, dann merkt er es auch nicht. Leider kommen immer wieder Geschichten an die Oberfläche, in diesen Tagen auch in anderen Bereichen der Wirtschaft, in denen das Austricksen von Kunden Bestandteil der Geschäftspolitik ist.

Freitag, 11. September 2015

Das Erstellen reproduzierbarer Software Releases.

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.


Im letzten Post haben wir uns darum gekümmert, unserer Software einen Namen zu geben. Für den Kunden wurde ein eingängiger Marketingname erfunden, für die Entwicklung reichte eine interpretierbare Versionsnummer. Diese Versionsnummer beinhaltet Information. Wiederfinden kann man den Versionsnamen im Tagnamen, der auf der Tagline (Baseline) in der Versionsverwaltung sitzt. Dieser Tagname kann weitere, vielfältige Informationen zur Version enthalten.

Freitag, 28. August 2015

Gib Deiner Version einen nachvollziehbaren Namen.

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.


In den letzten Artikeln dieser Reihe haben wir uns mit der Versionierung von Objekten und mit derNachvollziehbarkeit (Traceability) beschäftigt. Heute soll eine Softwarefirma unserer Wahl eine neue Version ihrer brandneuen Software ausliefern. Wir laden sie von der Downloadseite und sehen, sie hat die Versionsnummer 3.9.11. Im Kleingedruckten steht sogar die Nummer 3.9.11.2945. Was hat das zu bedeuten und warum spielt das bei unseren Betrachtungen zur Versionsverwaltung von Artefakten eine Rolle?

Freitag, 14. August 2015

Ein Produkt ist ein Produkt und ein Projekt ist ein Projekt.

Prozessübersicht Softwareentwicklung: Produkte

Es gibt Unternehmen, in denen werden zwar Produkte erstellt, deren Umsetzung erfolgt jedoch ausschließlich auf Projektebene. Es existiert also ein Produkt für eine Vielzahl von Kunden, eine Planungsebene für das Produkt gibt es jedoch nicht. Aus Kostengründen werden nur Projektbeauftragungen einzelner Kunden umgesetzt. Diese werden einzelnen Entwicklern oder kleinen Entwicklergruppen übertragen. Eine organisierte Abstimmung in Bezug auf das Produkt entfällt. Flur- und Zimmergespräche ersetzen notwendige Planungsaufgaben. Das ganze Problem verschlimmert sich, wenn es im Unternehmen nicht nur ein Produkt, sondern mehrere Produkte gibt. Am Ende haben wir eine projektgetriebene, konfuse Einzelentwicklung hin zu seltsamen Produkten.

Freitag, 31. Juli 2015

Die Angst vor dem Kunden.

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

Stellen Sie sich vor, Sie sind Programmierer in einer Softwarefirma und bekommen die Aufgabe, eine Anforderungsspezifikation zu schreiben. Nach der Spezifikation droht dann die Umsetzung. Deshalb möchten Sie die Anforderungen möglichst genau analysieren und beschreiben, und auch, weil Sie wissen, dass das Spezifizieren von Anforderungen der erste Entwicklungsschritt ist und zudem ein sehr bedeutender. 70 Prozent aller Projekte, die scheitern, leiden an fehlenden oder fehlerhaften Anforderungsanalysen.

Freitag, 17. Juli 2015

Das Alte behindert das Neue oder wie bewerte ich eine Firma anhand ihrer Lernkultur.

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

Neues zu lernen ist eines der wichtigsten Dinge im Leben eines Programmierers. Alles ändert sich - Vorgehensmodelle, Techniken und Sprachen. In traditionellen Gesellschaften haben die Jungen von den Alten gelernt. In unserer schnelllebigen Zeit müssen die Alten am Ball bleiben oder sie werden vom Zug der Zeit überholt und im schlimmsten Falle aussortiert. Solche Szenarien erzeugen Angst, und wo Angst herrscht, werden irrationale Verhaltensmuster geboren. In Firmen, wo die Alten auf Entscheidungsposten sitzen, kann es dazu kommen, dass sie sich vor Neuem schützen. Es gibt durchaus Firmen, in denen Techniken angewandt werden, die auch schon vor 20 Jahren modern waren. Dem Geschrei von schneller, weiter, höher entgegen, verkauft sich auch diese Software. Der Kunde dieser Produkte hat allzu oft keine Vorstellung von der Leistung, die er für sein Geld bekommt. Softwarefirmen vermögen es in vielen Fällen selbst nicht, die Leistungszunahme durch neue Techniken zu bewerten. Wie sollen Endkunden es da schaffen, einzuschätzen, wie viel Software man für sein Geld bekommt?

Freitag, 3. Juli 2015

Vom Sprint zum Überblick. Durchblick kommt nicht von allein.

Ordnung ins Chaos

Artikelübersicht
1. Teil Gegenseitige Hilfe ersetzt Chaos.
2. Teil Ein Held, der sich helfen lässt.
3. Teil Teambullshit oder wirkliche Teams. Mit dem Team gegen das Chaos.
4. Teil Vom Sprint zum Überblick. Durchblick kommt nicht von allein.


Im letzten Post habe ich beschrieben, wie sich ein kleines Team selbst organisieren kann. Die Abarbeitung der Aufgaben in Sprints, die eine, zwei oder vier Wochen dauern, gewährleistet eine effektive Arbeitsweise, mit der man auf kurzfristige Änderungen reagieren kann. Außerdem wird die Arbeit so zu einer Kette von Erfolgserlebnissen, die alle zwei Wochen ein neues und erweitertes Produkt präsentieren. Der Arbeitsfortschritt wird transparent. Es ist ein bisschen vergleichbar mit dem Ernten eines 100 Hektar großen Kartoffelackers. Die schiere Größe der abzuerntenden Fläche raubt uns den letzten Nerv oder sie lässt uns verzweifeln. Unterteilen wir die Fläche in kleinere Parzellen, wird jede einzelne Ernteaufgabe in absehbarer Zeit zu bewältigen sein. Wir stecken 10 x 10 m Parzellen ab und ernten eine nach der anderen ab. Unsere Motivation aufgrund der Kette von Erfolgen steigt enorm. Ein ähnliches Prinzip verwenden erfolgreiche Computerspiele, um ihre Spieler süchtig zu machen.