Notes Entwicklungsrichtlinien + QS

[Fineas]

Hallo,

hat oder weiss jemand eine Quelle, wo man sowas herbekommt? Kann doch nicht sein, dass sich noch niemand aktiv mit Standards beschäftigt hat ... oder?

Hintergrund ist die Tatsache, dass mit dem Anwachsen der Entwicklertruppe die Probleme bei der Kooperation (trotz oder wahrscheinlich gerade wegen Notes) dramatische Ausmaße annehmen. Das ganze muss deshalb auf eine solide Basis gestellt werden.

Rein persönlich richtet sich mein Interesse dann auch noch auf Qualitätssicherung und Softwaretest mit/für Lotus Notes. Da muss es doch auch Know How geben ...

THX.

[animate]

hat oder weiss jemand eine Quelle, wo man sowas herbekommt?

was meinst du denn mit "sowas"?

(trotz oder wahrscheinlich gerade wegen Notes)

Welche Probleme habt ihr denn?
Die Probleme, die mit dem Wachsen einer Gruppe kommen liegen eher selten an den Werkzeugen, die die Gruppe benutzt, denke ich.

Rein persönlich richtet sich mein Interesse dann auch noch auf Qualitätssicherung und Softwaretest mit/für Lotus Notes. Da muss es doch auch Know How geben ...

Suchst du nach etwas bestimmtem? Es gibt Know-how auf diesem Gebiet, da bin ich mir sicher. Ich vermute aber, du musst konkretere Fragen stellen, um eine gescheite Antwort zu bekommen

[Glombi]

Natürlich gibt es Know-how und fertige Konzepte. Es ist halt die Frage, ob das so einfach mir nichts dir nichts hier preisgegeben wird.

Andreas

[Fineas]

@Thomas:

"sowas" = Entwicklungsrichtlinien + QS-Maßnahmen

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! Aber welcher hofierte und gut bezahlte Individualist läßt sich schon auf die stille Treppe setzen ... Gerade das ist aber ein zentrales Problem. Wie bekommt man Leute dazu, sich an gemeinsame Grundsätze zu halten? Und wie sanktioniert man richtig?

unbestimmte QS = ist mein Hausthema. Ich hatte meine Diplomarbeit dazu und bin schon damals parallel zu den ersten Schritten mit Notes voll gegen die Wand gelaufen. Dass es Know How gibt ist mir klar. Dass dieses Know How oft grottenschlecht ist und auf Notes selten anwendbar auch. Es gibt sehr wenige fundierte Ansätze für RAD, XP oder noch schlimmer die beliebte Quick & Dirty Entwicklung bei Notes. Es läuft immer drauf hinaus, dass einer was entwicklet, das läuft dann voll super und wenn dran manipuliert werden muss, gucken alle in die Röhre (oder inzwischen auf das TFT) und wundern sich, was der da wohl gemacht hat und warum das überhaupt funktioniert.

Die letzten Richtlinien, die ich für meine Arbeit in der Mache hatte standen unter dem matt glänzenden Stern eines Automobilherstellers und waren gestützt auf ein fundamentales Machwerk, dass seiner Zeit anscheinend noch nie voraus war. Ich will den Autor nicht verunglimpfen, aber die Kommentare gereizter Leser bei Amazon sagen alles. Den Spezialfall Notes gab es nicht mal.

Problem preisgeben = natürlich. Richtig. Aber gerade dafür denke ich, ist ein Forum ja die passende Basis. Erfahrungen teilen und von gemeinsamen Ideen profitieren. Wenn dem nicht so ist, dann bleibt es eben dabei, dass ich wie alle anderen auch, mein eigenes Ding mache und mich damit zufrieden gebe. 

[Glombi]

Problem preisgeben = natürlich. Richtig. Aber gerade dafür denke ich, ist ein Forum ja die passende Basis. Erfahrungen teilen und von gemeinsamen Ideen profitieren. Wenn dem nicht so ist, dann bleibt es eben dabei, dass ich wie alle anderen auch, mein eigenes Ding mache und mich damit zufrieden gebe. 

Sowas wäre meiner Meinung nach ein Thema für unsere Best Practices.
Design-Richtlinien für Notes zu erstellen kann ein sehr umfangreiches Unternehmen werden.

Zunächst kann man anfangen, Links oder Artikel zu sammeln, die frei zugänglich sind.

Andreas

[animate]

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!

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. 

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.

[animate]

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

LMAO! Mir gehts da nicht anders.

Es gibt doch bestimmt Gründe, warum sich deine Leute nicht an die Regeln halten. Hast du die schon herausgefunden?

Meine Meinung ist, dass wenn du am Montag jedem Entwickler nen Packen Regeln gibst und ihm sagst, dass es sich daran halten soll - ab sofort - dann ist das schwierig für den Entwickler. Er versteht ihren Zweck/Sinn nicht. Er hält dich nicht für fähig genug, ihm Regeln vorzuschreiben weil du keine Ahnung hast. Er mag dich einfach so nicht, weil du ihm kürzlich erst vor die Nase gesetzt worden bist. Er befolgt die Regeln nicht, weil ohne sie bis jetzt auch alles wunderbar funktioniert hat. Er hasst Regeln und Vorschriften einfach. Da gibts noch 1000 andere Gründe. Und um einen Mitarbeiter dazu zu bringen, dir zu folgen, gibts bestimmt genauso viele Möglichkeiten.

Eine Empfehlung, die ich geben kann ist, dass du solche Richtlinien am besten in Zusammenarbeit mit den Betroffenen entwickelst.
Also mit ihnen das Problem der schlechten Kooperation erörtern. es ihnen bewusst und verständlich machen. Und dann gemeinsam mit ihnen eine Lösung für das Problem erarbeiten. Die meisten werden sich daran halten (zumindest eine Zeit lang), denn sie ist ja schließlich auch ihrem Kopf entsprungen.

[animate]

ach so nochwas, auch wenn das von meiner Warte aus unmöglich zu beurteilen ist: in meinen Augen ist nicht Notes die Ursache deiner Probleme. Ich bin mir sicher wenn du statt Notes XYZ einsetztest, wärs das gleiche.

[koehlerbv]

ach so nochwas, auch wenn das von meiner Warte aus unmöglich zu beurteilen ist: in meinen Augen ist nicht Notes die Ursache deiner Probleme. Ich bin mir sicher wenn du statt Notes XYZ einsetztest, wärs das gleiche.

Dieser Gedanke kam mir als allererstes, als ich diesen Thread erstmals sah. Es ist kein Notes-Problem.
Vor vielen Jahren hatte ich das Glück, an eine begnadete Programmiererin und Projektleiterin zu geraten, die mich von grundlegenden Regeln der Programmierung im Team überzeugt hat. Ich habe die "innere Umstellung" durchgestanden, ich habe die Erfolge genossen und dann selber eine Ader dafür gefunden, diese Überzeugung auch an andere weiterzugeben. Ich sehe das genauso wie Thomas: Es ist ein menschliches Problem, das man im Team lösen muss. Meine Erfahrung ist aber auch: Wenn in diesem Teamwork jemand partout nicht mitspielen will (oder - warum auch immer - kann), dann muss er zumindest das Team verlassen. Der Erfolg kommt nur, wenn wirklich alle mitmachen.

Bernhard

[Marinero Atlántico]

Ich halte Generalisierungen generell für gefährlich.
Beispiel: ich beschäftige mich zwar mit Unit-Testing, finde aber 100% Test-Coverage für die meisten Projekte Unsinn.
Ein gesundes Team ist für mich auch ein dynamischer Prozess, wo es eben auch schon mal Konflikte gibt. Es sollte aber bei manchmal bleiben.

- Hacks werden oft mit Kreativität verwechselt. Das ist Unsinn. Hacks lösen zwar oft ein *anscheinend* existierendes Problem, schaffen aber dafür ein paar weitere in der Zukunft. Es gibt eine Menge Hacks, die eigentlich mehr ein Anzeichen für fehlende Imaginationskraft für Probleme in der Zukunft sind. Also eher das Gegenteil von Kreativität.

- Das größte Problem von unerfahrenen Projektmanagern und Entwicklern ist, dass sie sich überschätzen. Sie glauben sich im Besitz von *Wahrheiten*, die keine sind. Arbeitest du basierend auf Allgemeinplätzen, verlierst du jede Flexibilität und gerade das benötigst du für den Erfolg von Projekten. Das ist eigentlich genau wie GO (das Brettspiel). Du hast immer einen gewissen Spielraum, agierst zwischen den Steinen des Gegners. Damit muß man leben. Zu glauben, nur wenn man irgendwelche Regeln befolgt, dass es dann Manna vom Himmel regnet, ist eine Illusion. In dieser Hinsicht sollte man zwar die stark amerikanisch geprägte Projektmanagementliteratur lesen, aber mit Skepsis. Das sind die Amis nämlich auch.

Produktiver werden, ist ein längerer Prozess, der Energie kostet. Dabei gibt es auch Rückschläge (diese Woche bei mir z.B.). Die z.Zt in diesem Land vielerorts herschende leicht panische Stimmung, befördert nicht, dass Leute produktiver werden. Du mußt da ziemlich stark sein und ehrlich gegenüber dir selber.

Gruß Axel