Zitat der Woche zur Aufwandsabschätzung – Gilt besonders für Softwareentwicklung

Standard

Dieselbe Arbeit unter denselben Bedingungen wird von 10 Schätzern unterschiedlich geschätzt werden oder von einem Schätzer unterschiedlich zu 10 verschiedenen Zeitpunkten.

(unbekannter Autor)

 

Nichts ist schwieriger wie den Aufwand einer Softwareentwicklung abzuschätzen. Man stützt sich auf die beschriebenen Anforderungen und versucht dann ein Konzept und dafür eine sinnvolle Zeitabschätzung zu finden.

Als erstes werden dann die Erfahrungswerte für ähnliches, schon entwickeltes, zu Rate gezogen.

Dann, wer schätzt ab? Wenn man einen Softwareentwickler diese Aufgabe überträgt, wird man zu keiner Aussage gelangen, oder zu so einer „sicheren“ Aussage, so, dass man das nicht mehr verkaufen kann.

Schätzt der Projektleiter mit Entwicklungserfahrung ab, wird er zu bewerten versuchen, welcher Entwickler für was zur Verfügung steht und wie lange der erfahrungsgemäß für seine Arbeit benötigt und wieviel Unterstützung er von anderer Seite braucht. Er liegt meistens schon in der richtigen Richtung, aber sein Schätzwert ist immer noch zu gering.

Schätzt der Vertriebler ab, wird die Schätzung zu 98% zu niedrig sein. Das ist sicher. Das gleiche gilt für den Chef, der ja seine Visionen verkaufen will und selten weiß was realistisch erreichbar ist.

Dann ist natürlich noch die Gemütslage am Tag der Abschätzung nicht zu vernachlässigen. Bei einem Hoch wird zu wenig Aufwand geschätzt, bei einem Tief wird der Aufwand höher, da die Herausforderungen plötzlich viel größer erscheinen, manchmal gar unerreichbar.

Aber dann kommt die Realität: Allen Abschätzungen und nach bestem Wissen und Gewissen durchgeführten Analysen und den von den zukünftigen Projektbeteiligten eingeholten Meinungen zum Trotz, wieder mal daneben gelegen und zu wenig geschätzt!

Advertisements

Zitat der Woche – Konzepte im Team zum Leben erweckt oder auch net

Standard

Alles erscheint klar, das Bild steht vor Augen, sogar Beschreibungen gibt’s. Doch wie bring ich’s meinen Entwicklerkollegen bei, dieses Bild im Kopf, am Whiteboard und in Powerpoint. Nimmer net, solange des Kollegen Herz nicht brennt.

Rüdiger Jung

Zitat – die beiden Wege zum Softwaredesign

Standard

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

Sir Charles Antony Richard (C. A. R.) Hoare

Zitat – Digitale Transformation, wer transformiert?

Standard

„Wir arbeiten in Strukturen von gestern mit Methoden von heute an Problemen von morgen vorwiegend mit Menschen, die die Strukturen von gestern gebaut haben und das Morgen innerhalb der Organisation nicht mehr erleben werden.“

Knut Bleicher, Ehrenpräsident der Gesellschaft für integriertes Management

Schlaues zur Softwarequalität

Standard

Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don’t buy a new scale; change your diet. If you want to improve your software, don’t test more; develop better.

auch wieder von Steve McConell aus Code Complete

Clean Code Zitat

Standard

Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‚How can I improve the code so that this comment isn’t needed?‘ Improve the code and then document it to make it even clearer.

Steve McConell

aus Code Complete (ein wirklich empfehlenswertes Werk für Softwareentwickler)