Domino 9 und frühere Versionen > Entwicklung

Notes Entwicklungsrichtlinien + QS

<< < (2/3) > >>

animate:

--- Zitat von: Fineas am 07.06.05 - 10:51:28 ---Probleme = Programmierer/Entwickler sind kreative Indivdualisten. Wie kleine Kinder halt. Und wenn Programmierer A seine Suppe kocht und Programmierer B die dann weiterkochen soll, dann leidet hinterher der Geschmack. Hauptproblem ist damit die Koordination der Kooperation. Es ist eigentlich wie bei der Supernanny: einfache Regeln für jeden (Deklaration, Kommentierung, Dokumentation, Standards, ...) und dann vor allem auch Sanktionen!

--- Ende Zitat ---

Ich denke, die ganz einfachen Regeln zu Deklaration + Kommentierung, sind das einfachste. In meiner alten Firma haben wir uns dazu der ungarischen Notation für VB bedient und die für Notes angepasst/erweitert.
Was in meinen Augen wichtiger ist, ist der SW-Entwicklungsprozess.
Wie sieht der denn bei euch aus? Ist er dokumentiert? Welche Schritte gibt es? Welche Artefakte werden in diesen Schritten erstellt?
Wie sollte er deiner Meinung nach idealerweise aussehen?

Das Aber-wer-hält-sich-daran-Problem kann ich auch nicht pauschal beantworten (du sprichst ja selbst von Individualisten). Das liegt in der Verantwortung des Teamleaders. Er muss aus den Individualisten ein Team bilden. Außerdem hilft ein dokumentierter Entwicklungsprozess natürlcih dabei.

Fineas:
Das "Aber-wer-hält-sich-daran-Problem" ist gerade des Pudels Kern. Wenn der Teamgeist so weit nicht reicht, dann sind wir wieder bei den Sanktionen. Und da muss es doch mehr geben als mit Abmahnung und Kündigung die Keule zu schwingen. Mir fehlt die kleine Handtaschenkeule.

Die grundsätzlichen Dinge sind ja noch machbar und umgesetzt. Entwicklerdoku und Prozess sind andere große Probleme - nach meiner Erfahrung durchaus allgemeiner Natur. Aber da möchte ich unter der Damokles Keule der Probezeit sitzend nicht wirklich näher drauf eingehen. Gibt auch nicht viel zu zu sagen.

Marinero Atlántico:
Fineas, deine Ausführungen strotzen vor Verallgemeinerungen und wenn du das wirklich so meinst wie du es gesagt hast...
Ich möchte jedenfalls nicht mit Leuten zusammenarbeiten, die pauschal ganze Berufszweige als "kreative Chaoten" diffamieren.

Kamen nicht wirklich bedeutende Bemühungen um QM gerade aus der Basis?
Um jetzt von Java zu sprechen:
Die Benutzung von fremden Codes/Frameworks ist ja wohl ohne Frage sehr weit verbreitet.
Unit-Testing kann zwar nicht alle Probleme lösen, ist aber sehr weit verbreitet.
Logging hat sich stark durchgesetzt.
Gute OO-Praktiken und Pattern helfen auch, den ganzen Prozess vorausschaubarer zu machen.
UML und Domain Modelling wird auf sehr unterschiedliche Weise genutzt:
-> Die schlechten Menschen sehen UML als eine neue Programmiersprache an und machen MDA (oder wie der Unsinn heisst)
-> Die guten Menschen benutzen dass zur Vorplanung und für den Überblick zwischendurch. Zum programmieren benutzen sie aber Programmiersprachen (oder XDoclet).
 
Für RAD und XP gibt es deshalb so wenig "fundierte" Ansätze, weil eben auch Softwareprojekte sehr unterschiedlich sind:
- Team Größe
- Lernkurve für Team
- Mentalität des Teams.

Sämtliche Prozesselemente von RUP sind optional. Bei XP ist aus meiner Sicht inzwischen auch schon eine Menge relativiert werden.

Wenn du auf der Suche nach der *perfekten Methode* bist und diese großartigen Ideen dann mit der Keule gegen den "individualistischen Durchschnittsentwickler" durchsetzen willst, dann wirst du im Nix landen.
Vielleicht fehlt es dir einfach an Erfahrung im Umgang mit Menschen.

Und ich habe nun wirklich überhaupt nix gegen XP oder RUP. Ich habe noch nicht einmal etwas gegen das Wasserfallmodell. Nur eben nicht für jede Art von Projekt.

... und glaub mir, ich hab immer das Gefühl, dass nicht ich sondern Teile meiner Kundschaft kreative Individualisten sind.  ;D

Was erwartest du?
Als weißer Ritter in eine Gruppe von kreativen Individualisten zu reiten und ihnen die Wahrheit über effizientes Arbeiten zu offenbahren?

Gruß Axel

thoge:
Hallo Fineas,

ungeachtet meiner Skepsis gegenüber "Projektmanagement by Sanktionen", habe ich mal ein paar Quellen aufgestöbert, die sich mit dem Scheitern von IT-Projekten, Richtlinien, Prozessmodellen und Qualitätssicherung beschäftigen.

Ich hoffe, diese Quellen liefern Dir ein paar Anhaltspunkte.

Hier eine Artikelsammlung mit dem Schwerpunkt Agile Development:
http://www.agilealliance.org/articles/index

Dieser Artikel aus der C't verweist auf o.a Vorgehensmodell:
http://www.heise.de/ct/05/05/048/default.shtml

Diese Diplomarbeit hat sich mit den o.a. Modellen für kleinere IT-Projekte (u.a. Entwicklung unter LotusNotes) befasst:
http://www.kbst.bund.de/Anlage307433/Diplomarbeit-von-Tobia-Riegg.pdf

Ich denke, da gibt es noch eine Menge mehr Stoff.

HTH

Thomas

[edit]
Ich arbeite in einem Planungsbüro mit ca. 100 Mitarbeitern (Entwurfsarchitekten, Ausführungsplaner, Haustechniker, Maschinenbauer, Verfahrenstechniker, Betriebswirtschaftler, etc. pp), die in Teamarbeit Fabriken planen und erstellen. Glaub mir, auch das sind höchst kreative Individualisten und die Aufgabenstellungen sind ähnlich komplex. Dennoch kommen am Ende des Projektes funktionierende, effiziente und ästhetisch wertvolle Produktionsstätten heraus, was m.E. eine Folge des geeigneten Projektmanagements und der Teambildung ist.
[/edit]

Marinero Atlántico:
Ausserdem ist es sehr einfach alles immer auf genetische Schwächen der Menschenrasse Entwickler zu schieben.
Entwickler (und Administratoren) sind nämlich die, die letztlich die Befehle in die Maschine eingeben. Und wenn die Maschine das nicht richtig kapiert, gibt es ein eindeutiges Ergebnis: Nicht funktionierende Anwendungen. Über Planungsartefakte kann man dagegen immer diskutieren.

Und gerade bezüglich der Qualität der nicht-selber-programmierenden-IT-Spitzenkräfte dieses brillianten Automobilkonzerns hab ich schon sehr, sehr geteilte Meinungen gehört - um es vorsichtig auszudrücken.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete