Monthly Archives: January 2012

Why IT Contracts should address Questions of Agility


What exactly is Agility in Software Development?

One definition is: To get a nice (software) solution is more important than to sit on a no longer useful contract.

There is no need to make Agile Software Development a complicated concept: We only have to realize which kind of agility will help in modern IT projects.

But never forget: There is one important consequence you and your client should be aware of: Agile and Fixed Price are like Fire and Waterif not tamed they simply annihilate each other (and do so in many unexpected ways).

The case De Beers vs Atos Origin is ample proof of this fact.

To avoid similar desasters, there is only one possible solution:

Before starting a software development project, suppliers and customers, in their contract, should agree not only on the scope of work and a project plan — the basis for a possible fixed price — but also on how to deal with any changes that might become necessary. This is the part specifying a specific degree of agility the project partners promise, or should promise, each other.

The accusations brought forward in the lawsuit De Beers vs Atos Origin clearly show that agility could become necessary on both sides (not only on supplier’s side).

To summerize:

  • Agility is nothing more than to acknowledge that changes to the contract itself may become unavoidable.
     
  • The contract should forsee this possibility.
     
  • Contracts not addressing this issue can become a problem: The supplier may even end up being accused of fraudulent misrepresentation (as EDS was as a supplier of BSkyB).

 
To learn more you may want to read:

 

Advertisements

Wirklich Trauriges zu Agilität im Software Engineering


Obgleich die Diskussion um sog. Agile Software-Entwicklung heute heftiger wird denn je, hat man den Eindruck, dass vor allem die Entwickler und Programmierer selbst nicht wirklich verstehen, über was sie da im Detail nachzudenken haben: Jeder glaubt, den Begriff zu verstehen, aber kaum noch jemand geht ihm wirklich auf den Grund.

Wer nachliest, was Gartner uns sagt, wird sofort erkennen, was ich meine und dass es an der Zeit ist, zu handeln: Wir, die Software-Ingenieure, müssen lernen, wieder mehr wissenschaftlich zu denken: eben wie Architekten und Ingenieure und über den gesamten Lebenszyklus dessen hinweg, was wir bauen.

Stattdessen scheinen wir inzwischen zu denken wie Handwerker oder angehende Programmierer in der High School (!).

Versuchen wir’s mal richtig:

Ja, es sollte heute selbstverständlich sein, dass im Zuge der Entwicklung neuer Software alle Beteiligten gewillt und in der Lage sind, höchst agil zu reagieren — weit flexibler jedenfalls, als das noch bis vor etwa 15 Jahren notwendig war oder auch nur denkbar erschien.

Richtig ist aber auch, dass der agile Ansatz noch häufig zu wenig verstanden wird:

Wer angehenden Software-Entwicklern eine SCRUM-Schulung bezahlt und glaubt, sie könnten dann schon in sinnvoller Weise agil sein, der irrt gewaltig:

Im positiven Sinne agil zu handeln erfordert Können und viel Erfahrungmit dem Agile Manifesto allein gelassene Lehrlinge werden stets nur Schaden anrichten (Schaden, der nicht sofort jedem sichtbar wird, der aber durchaus gravierend sein kann, siehe z.B. Agile is ignoring CIO’s Interest).

Das zu wissen lohnt sich vor allem für die Betreiber, Nutzer und Eigentümer von Software, weniger für die Entwickler (denn die haben, wenn der Schaden offen­kundig wird, die Verantwortung längst abgegeben und ihr Geld schon kassiert).

Wer als Methodiker die Diskussion um agile Prozesse verfolgt, der sieht, dass sich jeder Diskussionsteilnehmer schnell erkennbar einer der folgenden drei Gruppen zuordnet:

  • Gruppe 1: Das sind alle, die um jeden Preis "agil" sein wollen — den Ansatz in seiner ganzen Tiefe aber noch lange nicht wirklich verstanden haben.
     
  • Gruppe 2: Jene, die schon nachdenklich wurden (da ihnen auffällt, dass die Diskussion um wünschenswerte Agilität immer lauter wird, aber doch nun schon gut 10 Jahre lang nur gebetsmühlenartig die immer gleichen Halb­wahrheiten aus dem Manifest zitiert.
     
  • Gruppe 3: Dazu zählt, wem längst klar ist, dass Entwickler und Berater aus Gruppe 1 eine Zeitbombe nach der anderen produzieren.

Eine Schande für unseren ganzen Berufsstand ist, dass auch viele gut bezahlte Berater und Trainer sich in Gruppe 1 tummeln. Diese Gruppe ist allzu groß und scheint kaum zu schrumpfen.

Dass Leute aus Gruppe 3 sich selten oder nur allzu vorsichtig zu Wort melden, ist schade (und eigentlich unverantwortlich). Einer der wenigen, den diese Kritik nicht
trifft, ist Mike Gualtieri, der in Forrester’s Blog, schonungslos Kritik übt und dann zum Schluß kommt: " … we need a new software development methodology. Agile is not it."

Was er uns damit sagen will ist wohl: « Die — ja nun wirklich — zu wenig flexible klassische Vorgehensweise muss fortentwickelt werden zu einer neuen, besseren. Die aber darf nichts zu tun haben mit dem, was in den Köpfen zu wenig umsichtig denkender Agilisten an unausgegorener Vorstellung so alles existiert. »

Ich sehe die Situation ebenso, bin aber der Meinung, dass wir da erst vorankommen werden, wenn wir Agilität über ihren Zweck definieren, nicht aber, wie bisher, über das zu kurz gedachte und mißverständlich formulierte Manifest aus dem Jahr 2001.

Sich Tom de Marcos resignierender Feststellung anzuschließen I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone scheint mir (noch) zu früh — hoffen wir, dass es nicht so kommt.

 

Effective Assessment of Test Coverage is possible


Everything software developers and test managers should know about how to monitor test coverage quite effectively — and which metrics not to use — is explained in a two pages document What you need to know about old and new Metrics for Test Coverage Assessment.

There is also a very illuminating example.

 

Against misunderstandig Agile


Most people — Agile evangelists are no exception — tend to define Agility via a specific way of working (e.g. via SCRUM) or via the Agile Manifesto (which is a set of too easily – and by far too often – misunderstood principles totally ignoring the CIO as one of the most important stakeholders).

But to really understand what it means to become agile as a software developer (or a developer’s client) in some positive manner

If you don’t believe me, there are others who also say:

 

Software-Test wäre effektiver, wenn …


Die hohen Summen, die große Firmen (Banken und Versicherungen etwa) für Software-Test ausgeben, wären mit Sicherheit deutlich besser angelegt, wenn man sämtliche Tester zwingen würde, weit detaillierter als bisher zu belegen,

  • welche Details im einzelnen denn nun wirklich getestet wurden,
  • gegen welche Spezifikationspapiere man geprüft hat,
  • und — vor allem — welche Testabdeckung die jeweils letzte Test­wiederholung erzielt hat.

Derzeit werden Tester viel zu sehr sich selbst überlassen — ihre Effektivität zu messen und gezielt zu steigern wird nicht wirklich versucht (!).

Lese auch:

 

Wie fehlerbehaftet ist typische Software?


Wissenschaftliche Untersuchungen (z.B. eine der Carnegie Mellon University aus 2003) belegen, dass moderne Software, wenn sie in Betrieb genommen wird, i.A. immer noch bis zu fünf Fehler pro 1000 Lines of Code enthält; sprich: etwa 1 Fehler auf je 3 DIN A4 Seiten manuell erstellten Source Codes.

Selbst in den besten aller je untersuchten (größeren) Programme fand sich immer noch 1 Fehler in je 7500 Zeilen Code.

Wären mathematische Publikationen auch nur annähernd so fehlerhaft, wäre die Mathematik als Wissenschaft sicher längst in sich zusammen gebrochen (denn dort bauen neue Ergebnisse ja stets auf älteren auf).

Wir sehen: Die Informatik — wenigstens aber ihre Technik zur Qualitätssicherung — steckt heute wohl noch in Kinderschuhen, die vergleichbar sind mit denen, die die Mathematik zu Zeiten von Aristoteles, Pythagoras und Euklid trug.

Haben wir da ein Problem?

Und wird man sich leisten können, damit noch lange zu leben?

 

Lücken der Software-Qualitätssicherung


Wissenschaftler aus München berichten (siehe Demystifying Maintainability):

"In 2003 we conducted a study on software maintenance practices in German software organizations. Interestingly, of the 47 respondents only 20% did specific checking for maintainability during quality assurance".

Frage: Liegt das daran, dass es Unternehmen, die Software für Kunden produ­zieren, völlig gleichgültig sein kann, wie teuer den Kunden später die Wartung dieser Software kommt?

Wenn ja: Kann dem Auftraggeber solche Haltung wirklich gleichgültig sein? Warum unternimmt er i.A. gar nichts, um sicherzustellen, dass er gut wartbare Software bekommt (solche also, bei der die Total Cost of Ownership gering ist)?

 

Best Practice Software Engineering


Als jemand der 30 Jahre Erfahrung mit Entwicklung und Test von Software hat, habe ich — für Berufsanfänger (aber auch für Hochschullehrer und für Manager mit wenig praktischer Erfahrung) — in Form von etwa 25 sehr kurzen Aufsätzen zusammen­getragen, was ich unter

Best Practice Software Engineering

verstehe.

Einstiegsseite in dieses kleine Handbuch ist Software Engineering: Fakten, Best Practices (und allzu Naives).

Wer mir widersprechen möchte ist eingeladen, hier entsprechende Kommentare zu hinterlassen.