JavaSpektrum März 2004 [antikvár]

Editorial ^Erfolgreiche Softwareprojekte sind so seilten wie altruistische Staubsaugervertreter, und das hat eine schlichte Ursache. Wer redet denn schon von erfolgreichen Projekten? Es ist müßig über sie zu berichten, denn gerade schadenfrohe Naturen ergötzen sich primär an den kleinen Martyrien und mittleren Katastrophen, von denen hauptsächlich andere Entwickler heimgesucht werden. Sind wir doch einmal ehrlich: Das häufige Argument „Von problematischen Projekten hören, um aus deren Fehlern zu lernen" ist nur vorgeschoben. Warum sonst sind an den Stammtischen so häufig jene Geschichten zu vernehmen, die berühmte „Mißgeschicke" zum Thema haben? Denken Sie zum Beispiel an den explosiven Ariane-Start, den Ingenieure durch die Wiederverwendung alter Code-Teile geschickt eingefädelt haben. Dieser Schwank erhält auch heute noch Höchstnoten auf der nach oben offenen Murphy-Skala. Oder denken Sie an Toll Collect! Stehen Ihnen nicht schon beim Gedanken daran Freundentränen in den Augen? Da es freilich langweilig ist, ständig über dieselben Stories zu schmunzeln, stellt sich die Frage, ob die geneigte Entwicklerin oder Managerin nicht aktiv Einfluß auf die Häufigkeit solcher Fehlschläge nehmen kann, statt alles stets dem Zufall zu überlassen. Nur durch einen durchschlagenden Mißerfolg können Sie mit Ihrem Namen einen Platz in der Geschichte einnehmen. Die gute Nachricht lautet: Selbstredend existiert ein Satz von Maßnahmen, um eigene Softwareprojekte mit mehr oder minder schmerzhaften Dornen zu verzieren. Lassen Sie mich aus dem Nähkästchen plaudern. Ein paar der Dienstanweisungen für einen Softwareteufel könnten folgendermaßen aussehen: Mission Impossible 1. Schon beim Zusammensetzen eines Teams ist darauf zu achten, dass es keine klar definierten und abgegrenzten Verantwortlichkeiten gibt. Den daraus unweigerlich resultierenden Konflikten läßt sich durch geschickt eingefädeltes Mobbing eine höhere Durchschlagskraft verleihen. 2. Anforderungen sollten weder vollständig noch widerspruchsfrei sein. Zudem sollte der Satz von Anforderungen einer gewissen temporalen Variabilität, Interpretier-barkeit und Extensibilität unterliegen. Von Vorteil erweist sich, wenn darüber hinaus die Quelle der Anforderungen im Verborgenen bleibt. 3. Die Kommunikation im Team sollte auf einer Gauß'schen Verteilungskurve immer an den äußersten Rändern liegen. Förderlich sind sowohl übertrieben hohe als auch fehlende Kommunikation. Monieren Störenfriede dieses Problem, empfiehlt es sich, von einem ins andere Extrem zu wechseln. 4. Der gewählte Softwareprozess ist im Idealfall Undefiniert oder inadäquat. Für Kleinstteams erweist sich ein aufwändiges Wasserfallmodell und für sehr große Teams eXtreme Programming als geeignetes Vorgehen. Riskante Projekte sollten stets mit der Einführung eines neuen Softwareprozesses einhergehen. 5. Die Aufwandsabschätzung von Arbeitspaketen zählt auch heute noch zu den unverstandenen schwarzen Künsten, weshalb zu gering geschätzte Aufwände nicht weiter auffallen. Beim Nichterreichen von Meilensteinen können Sie mit den Fehlleistungen der Teammitarbeiter argumentieren (siehe auch 7). 6. Zu den Katalysatoren erfolgreichen Projektmißmanagements zählt der Einsatz unreifer Technologien oder solcher Technologien, an die sich nur noch pensionierte Mitarbeiter erinnern können. Die kontinuierliche Änderung der eingesetzten Technologien zur Projektlaufzeit dient als weiterer Hebel. 7. Den besonders risikobehafteten Projekten sollten Sie Personal mit geringst möglicher Erfahrung und Kompetenz zuweisen. Stellen andere diese Strategie in Frage, argumentieren Sie, dass sich gerade für unternehmenskritische Entwicklungen unvoreingenommene Mitarbeiter am besten eignen. 8. Als den beiden letzten Punkten orthogonal gilt die Nutzung inadäquater V Werkzeuge. Argumentieren Sie mit den Kostenargumenten gegen gute kommerzi- L eile Werkzeuge und mit Risikoargumenten gegen freie Software. Durch Wahl falscher Werkzeuge lassen sich die Negativeffekte geschickt potenzieren. 9. Behandeln Sie Prinzipien moderner Softwarearchitektur stets als Hirngespinste theoriehöriger Akademiker ohne die geringste Praxisrelevanz. Stellen Sie daher alle anderen Phasen in den Vordergrund und spendieren Sie für architektonische Aktivitäten nicht mehr als 1 Personenwoche. 10. Betrachten Sie Dokumentationstätigkeit stets als unproduktiven, bürokratischen Akt! Dokumentationsaufwände sind daher zu minimieren oder mit so hohem Aufwand zu betreiben, dass sich eine geringe Aussagekraft sicherstellen läßt. Hier kommt Ihnen zudem die Trägheit von Softwareentwicklern entgegen. 11. Machen Sie sich stets die Effekte der „semantischen Entropie" zu Nutze: Vermeiden Sie ein Glossar mit eindeutig definierten Fachbegriffen und sorgen Sie dafür, dass verschiedene Teammitglieder immer über verschiedene Inhalte sinnieren, wenn sie dieselben Begriffe benutzen. 12. Maßnahmen zur Qualitätssicherung setzen voraus, dass es Probleme mit der Qualität des entwickelten Produktes geben könnte. Weisen Sie daher solche Anliegen stets vehement von sich! Fordert das Management trotzdem Maßnahmen zur Qualitätssicherung, nutzen Sie Regeln 4, 7, 8 und 10. Die genannten Verhaltensregeln stellen natürlich nur einen Ausschnitt dessen dar, was Ihnen an potentiellen Möglichkeiten zur Verfügung steht. Wir hoffen, Ihnen damit wenigstens den Einstieg in die komplizierte Materie zu erleichtern. Sollten Sie an dieser Stelle noch weitere Empfehlungen in petto haben, scheuen Sie sich nicht, die Redaktion zu kontaktieren, damit auch andere von Ihren Erfahrungen profitieren können. In diesem Sinne wünsche ich Ihnen auch im Namen des gesamten Teams ein glückliches, gesundes und erfolgreiches Jahr 2004, wie auch immer Sie „erfolgreich" definieren mögen. Ihr Michael Stal