Laden...

UML, Pflichtenheft, Feinspezifikationen vs. agile Methoden

Erstellt von Abt vor 6 Jahren Letzter Beitrag vor 6 Jahren 15.360 Views
Hinweis von gfoidl vor 6 Jahren

Abgeteilt von Modellierungs-Tools um aus UML C# Klassen zu generieren

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Allgemein wird in der gesamten Software-Entwicklung quasi heute (natürlich eher dann bei neueren Projekten) auf UML verzichtet.
Daher fliegt es nicht nur aus Visual Studio raus.

Das Problem bei UML ist, dass es spätestens mit dem Speichern der Ansicht veraltet ist.
Dafür entwickelt sich Software einfach viel zu schnell. Die heutige Vorgehenweise ist einfach Code-First.
Und anhand von Code wird dann dokumentiert. Das wird dann mit groben Architekturplänen abgeglichen.
Es gibt dafür auch Tools, dass kein Code eingecheckt werden kann, der einem Architekturplan entspricht. Das ist viel effizienter als UML Diagramme.

Viel wichtiger als das Zeichnen von UML Ansichten ist das Abbilden von Workflows, denn damit kann man wirklich was anfangen.
Viele nutzen dafür Visio oder ViFlow (ein Visio Addon); auch ich.
Der Business Value von 100% UML=Code ist einfach nicht gegeben.

Warum brauchst Du denn noch UML Diagramme?
Historische Anforderung?

3.003 Beiträge seit 2006
vor 6 Jahren

Da muss ich ein bisschen widersprechen. Große Spezifikationen[1] beinhalten sehr gerne noch UML, insbesonders activity, use cases, interaction und state diagrams. Was selten geworden ist, ist das, worauf du hinauswillst: Versuche, Code direkt aus einem Klassendiagramm zu generieren. Es hat sich gezeigt, dass das meistens nicht so zielführend ist - Begründung liefert Abt ja.

UML ist aber mehr als nur das, und wie gesagt, für Dokumentation, Spezifikation, Architekturbeschreibung und dergleichen sind die entsprechenden Diagrammtypen sehr gut geeignet und werden auch benutzt.

LaTino
[1] Beispiele:
SAP (diverse Specs)
VDV KA (e-Ticketing, VDV-Kernapplikation)
etliche Specs aus dem Gesundheitsbereich
Logistikspezifikationen
...

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

.. aber gerade große Spezifikationen versucht man heutzutage zu vermeiden, weil das die Gefahr eines riesigen Monolithen birgt.
Wenn ich beim Kunde bin und hör "ja, wir wollen agil sein(...)wir machen dann mal ein Lastenheft und Feinspezifikation" dann rollen sich mir die Zehennägel auf.

3.003 Beiträge seit 2006
vor 6 Jahren

Geht bisschen vom Thema weg, aber ohne große Spezifikationen sind große Standards nicht definierbar (Kernapplikation ist das beste Beispiel, was mir dazu einfällt...das MUSS bis ins Kleinste spezifiziert/standardisiert sein, weil sonst jeder Akteur seine Suppe kocht und das Gesamtprojekt scheitern würde. Wenn man mal 5 Minuten Zeit hat: Die VDV-Kernapplikation herunterladen, beliebiges Dokument nehmen und reinschauen. Soweit ich mich erinnere, fand ich den Umgang mit UML gerade in der Spec ziemlich gelungen[1]).

Da kann man prima drüber streiten, schon klar. An den TE bleibt die Aussage: UML für Codegenerierung ist eine Idee, die sich nicht bewährt hat. Die Beschäftigung damit lohnt eher nicht.

LaTino
[1] heisst nicht, dass auf jeder zweiten Seite ein activity diagram ist. Bisschen stöbern lohnt.

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

B
66 Beiträge seit 2013
vor 6 Jahren

Als jemand der viele, leitende Funktionen in Großprojekten u.a. der SW Entwixcklung hatte, sage ich ich dass dort
Modellgetriebene Softwareentwicklung
immer noch Standard ist.
Agile Methoden - wie SCRUM, Criystal Clear oder XP - sind Anfängerkramm.
Testgetriebene Entwicklung
ist auch obligarorisch in stark prozessgesteuerte SW E/D.

UML ist ein domainspezifisches Standard-Tool bzw. Spache für die OO SW Entwicklung und dort sollte die Illustration der Übersicht für die Entwickler und Architekten sinnvoll sein. Im Management hat UML eigenlich nichts zu suchen, besser ist dort Powerpoint.
Dort würde ich maximal eine Aktivtätsdigramm oder UC-Diagramm verwenden.

@TE:

Um mit UML
Round-Trip-Engineering
zu betreieben, empfehle ich
Enterprise Architect

Das Preis-/Leitungsverhältnis ist bis heute unschlagbar.

Um Round Trip Engineering mit anderen Domains oder Domainmodellen zu betreiben, die nicht mit formallen Sprachen betrieben werden, enpfehle ich eine Mehodentechnik die Requirements Enginnering (RE) genannt wird.

Es existieren aber nur sehr Wenige, die sie wirklich beherrschen - insb. f. Großprojkte.
Man muss bereits sehr viele, interdisziplinäre Erfahrungen haben, um gute Consultants im RE überhaupt erkennen zu können.

Kostengünstiger ist
z.B. http://staruml.io/
Free:
http://whitestaruml.sourceforge.net/

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Agile Methoden - wie SCRUM, Cristal Clear oder XP sind Anfängerkramm.

Wow. Dazu fällt mir nichts mehr ein.

3.003 Beiträge seit 2006
vor 6 Jahren

Agile Methoden - wie SCRUM, Cristal Clear oder XP sind Anfängerkramm.

Wow. Dazu fällt mir nichts mehr ein.

Vielleicht, weil du dich um überwiegenden Teil in der agilen Szene bewegst?

diese Meinung ist in Projekten durchaus nicht selten. Nach dem Motto "agile ist eine nette Idee, funktioniert nur leider nicht, sobald man eine gewisse Projektgröße erreicht." Das liegt mMn nicht am Konzept an sich, sondern an der gefühlt riesigen Masse gescheiterter agiler Projekte. Ich glaub nur, dass es ein Trugschluss ist, dass dieses Scheitern am Konzept liegt.

Wasserfall, V-Modell und Konsorten für "echte" Projekte, scrum für überfinanzierte, kurzlebige Webfrickel-Startups. Die Aussage würden vermutlich mehr als die Hälfte der Projektleiter aus meinem Bekanntenkreis sofort unterschreiben. Ich selber nur mit einem "kommt darauf an"-Vorbehalt.

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

F
10.010 Beiträge seit 2004
vor 6 Jahren

Komisch, ich habe es in den letzten 30 Jahren eher andersrum erlebt.

Die meisten Großprojekte in denen ich involviert war, waren alle "schön" geplant,
aber nach 2 Jahren Laufzeit hatten die wenigsten etwas mit den dann tatsächlich vorhandenen
Anforderungen zu tun.

Die wurden dann entweder trotzdem zu Ende entwickelt ( meist öffentlicher Dienst ),
oder eingestellt.
Natürlich wurden die zu Ende entwickelten als Erfolg gewertet, auch wenn sie dann in die Schublade kamen.

Bei ein paar wurde dann auf biegen und brechen versucht es mit etwas Agilität noch hinzubiegen,
aber das ging dann meist schief.
Und die arroganten Ex Projektleiter haben das dann natürlich den agilen Methoden und
nicht ihrem eigenen Versagen zugeordnet.

Die erfolgreichen Großprojekte, an denen ich etwas mit getan habe, hatten alle eine Solide Basis,
wurden aber danach eher agil entwickelt, also sehr viele Meilensteine, kurze Entscheidungswege usw.
Die Projektleiter meinten dann aber leider auch immer das sie kein Agil machen würden, was nicht wirklich stimmt.
Nur weil man keinen täglichen Scrum macht, heißt nicht das man nicht trotzdem agil arbeitet.

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Wegen mir: Leute, macht mehr Monolithen! Macht mehr Feinspezifikationen! Aber bitte gebt euch mehr Mühe mit eurer Doku. Denn wahrscheinlich muss diese eine Person lesen, die das Projekt retten soll.
Warum: das sichert meinen Job, denn mein Tagesgeschäft als Architekt ist es, solche, gegen die Wand gefahrene Projekte wieder auf korrekte Bahnen zu lenken: mit agilen Methoden. Selten, dass ein Projekt - und ich mache entgegen der Anmaßung keine Web-Frickel-Projekte - dass diese nur im 6-stelligen Bereich sind, um mal eine Größenordnung zu geben.
100/100 Feinspezifika haben nichts mit dem zutun, was gemacht wurde. Weil sich bis zu dessen Fertigstellung, die meist Monate in Anspruch nehmen, die meisten Anforderungen geändert haben.
Und selbst nach der Fertigstellung einer Definition kommen 100 Dinge hinzu, weil sich was geändert hat oder es vergessen wurde.

"agile ist eine nette Idee, funktioniert nur leider nicht, sobald man eine gewisse Projektgröße erreicht."

Dann scheint die Azure Plattform, die AWS Plattform, die ganzen Google Produkte, Windows, Visual Studio, SAP, Oracle Database, MySQL und all diese Welttechnologien einfach viel zu klein zu sein.
Denn das sind alles Produkte, die mit agilen Methoden umgesetzt werden. Nicht alle mit SCRUM - es gib zig andere - aber agile Methoden. SCRUM zb funktioniert nicht, wenn das Team ein Support-Anteil leisten muss. Dann ist oft KANBAN die bessere agile Methode.
Du wirst bei Google nicht ein fein-spezifiziertes Projekt finden.

Was passiert mit Monolithen, mit Projekten, dessen Heads einfach Sturköpfe sind?
Ganz, viel zu oft das: Bundesagentur für Arbeit stoppt millionenschweres IT-Projekt
Das ist das Paradebeispiel, was mit einer uralt Herangehensweise von Großprojekten passieren kann. Oft kann man es aber für viel Geld retten. Leider aber auch viel zu oft nicht.

Aber ok. Windows ist einfach ein kurzlebiges Frickelstartup 😉

Und ja: bitte macht mehr Feinspezifika und Monolithen, dann mach ich mir bis zur Rente keine Sorgen um meine Auslastung 😃

Agil muss man leben, nicht einfach nur machen.
Und das ist das Problem vieler. Nicht die Methode.

Ich enthalte mich wieder der Diskussion 😃

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo zusammen,

mMn gilt Folgendes für den Großteil der Software.

Wenn Software nicht für das Archiv entwickelt werden soll, so kann kein Weg an agilen Methoden vorbeiführen -- egal wie diese heißen und wie diese konkrete ausgeprägt sind.
Warum? Das wurde in diesem Thread schon genannt: bis die Spezifikation gründlich genug geschrieben ist, haben sich die Anforderungen geändert und es wird SW entwickelt die nicht den aktuellen Anforderungen genügt. Diese zeitliche Latenz lässt sich nur durch agile Methoden verkürzen. (Ganz eliminieren lässt sich diese Latenz wohl kaum, denn es muss ja mindestens auch Zeit für die Umsetzung aufgewandt werden.

Ausnahmen davon können Projekte wie mathematische Bibliotheken sein, aber selbst hier ändern sich die Anforderungen (Multicore, GPU, ...) so dass nicht einmal in diesem Themen-Bereich ein nicht-agiles Vorgehen wirklich sinnvoll ist.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

B
66 Beiträge seit 2013
vor 6 Jahren

Also wenn ich den Titel und die Beiträge lesen, muss ich für mich Schlusslolgern, dass keiner von Euch jemals unter einen wirklich starken Projektleiter gedient hat! 8o

  1. Auch unter Agile Methoden und Entwicklung werden Lastenheft, Pflichtenheft und UML eingesetzt!
    Ist vergleichbar Topic - Geschäftsverträge in der Versorgungskette, Tablet PC vs. Geschäftsstrategie und - philosphie.

  2. Agiles M/D ist in der Prozess- und Methodenlandschaft der SW-Entwicklung, dass was die Bildzeitung in der Presselandschaft darstellt. Zielgruppe Entwickler-Teams, mit geringen, aber noch wichtiger, einseitigen fachlichen Bildungs- und Erfahrungshintergrund, bloß nichts hoch funktional darstellen, weil die gesamte Umgebung nicht ausreichend qualifiziert ist mit den Constraints klar zu kommen und deshalb schon ewig nicht ausreichend ausgerüstet sind, diese umzusetzen - Prozesse, Methoden und IT Umgebung.

  3. Deswegen wird dies im Thread mein letzter Post sein. Denn das ist so, als versuche ich als Fachzeitschriftsauthor für Mathe mit logischen und vernunftbegabten Argumenten gegen die Bildzeitung anzustinken. Den Kampf kann ich nicht gewinnen. 🙁

  4. Da ich 180 PLs bereits geschult habe, mal ein kurzes C&P aus meinen Schulungsunterlagen - Die Grafiken kann ich leider nicht kopieren:

===========================================
Agile Management And Development

Starting short term without extended project planning.

  • Use lot of person-orienting oral communications, but just few quoted in writing. => Often in tons of meetings.
  • Small and short iterations in development. Priority is finish executable and tested iterations before satisfy all goals and requirements.
  • Practiced normally in small teams who join and disassemble quick and dynamic (agile).
  • Much courage dropping entire iterations and starting from scratch again.
    -Budget is mostly fixed due to human resource costs by rates, tools, licenses etc. and not by external influences like offices cost, distribution.
  • Dependencies between different teams and departments, Stakeholder, Subject Matter Experts (SME) and Solution Providers are managed like project itself - Agile!
  • Typical methods are XP and SCRUM etc.
    ================================================
    Agile Management And Development – Consequences And (Dis-)advantages

„Agile Project Management is failure of Project Management; especially project planning!“
Already over 150 Project Managers had learned this lesson in my coaching and training seminars.

  • (Project) Leader, who has authority and responsibility, is not automatically a (Project) Manager! (Project) Manager is not just (Project) Administrator.
  • (Project) Management has five main features – Responsibility & Authority, (Project) Planning, Risk Management, (Project) Monitoring & Controlling and Vision & Strategy.
    -To claim title (Project) Manager you have to implement some progressive strategic aspects not just in project itself, but also in entire project environment – departments, customers, company, colleagues, own life during working etc as well. If one of these features are missing I do deny rank Manager.
  • As a (Project) Manager you have to think
    +for and about others.
  • about the improvement and advancement of all domain models and institutions.
  • about the big picture and entire system.
  • about current situation (tactic) and future situation (strategic).

=================================================

Comparism Agile vs. Progressive Management & Development

Entropy (Chaos)Mark Coordination Between 2 Projects 5 Years Later to Efforts

Hier sind nur leider nur Diagramme.

=================================================
What Progressive Management & Development Has Achieved Meanwhile

Hier sind leider nur Diagramme

  • 3 Years Later
  • 5 Years Later
  • Coordination Between 2 Projects 5 Years Later
    ==================================================

Agile Management And Development – Consequences And (Dis-)advantages
(2)

Symptoms in big organizations with strong agile management & development.

  • A strict planning about HRs, schedules, material demands, delivery time, manufacturing units etc. is not possible, because all participants just toss spontaneously and uncoordinatedly their requests, tasks and requirements over fence onto neighbours ground every time.
  • Domain Models and Institutions are developed very opportunistically to satisfy heuristics. And almost every organizations cannot resist to extend these in new projects for re-use. Use these extension in following project and so forth. And after many years IT, process, regulation and institution landscape looks like a well known phenomenon in procedural programming languages like in 80- 90s called Spaghetti nodes. Although these are conceptualized as prototypes or one-way development, 20 years later they will have already 30 levels with hundreds of supporting beams, be operated and maintained by a „dwarf army" to defend the non-transparent „holy cow" to the last and who try to hide many „bodies in cellar" by doing so (see WikiLeaks). Doesn't left any budget for refurbishment or new investments behind as well as any employee with courage start Mikado game, because no one can tell any longer which part of company might be crunched if we switch off some parts. – And suddenly a crisis, merger, new management, extension, law, regulation or standard appears and forces do it anyway …– Greetings to banks, EU Euro stability and economy task forces, country austerity measurements and world ecology conferences.
  • Produces many local heroes with exclusive knowledge who either cannot take extensive vacations ever, is enabled black mailing company or strongly constrains capability for expansions of organization.

======================================

Agile Management And Development – Consequences And (Dis-)advantages (3)

  • Most Project Leaders are all-in-one heroes – PM, Systems Engineer, Customer Manager, QA etc - who need domain knowledge of their environments. For instance, a PL in investment banking needs knowledge in investment markets.
    -Number of experts decreases in organizations.
  • More and more all-in-one heroes appear for special task areas, whose domain knowledge could assigned to a single office or department.
  • Cost/efficiency ratio is hard to measure.
  • Solid effort estimation is not possible in agile high level perspective.
  • Coordination or parallelism of work tasks are made very inefficient (explained later).
  • Needs plenty of time phase employees into new tasks areas.
  • Entropy in project environment increases as well in opposite to progressive M&D where e.g. customers or colleagues realizing it's actually a good idea doing so as well.
  • §Only way out is rigorous Release Management, but more then ITIL V3.
  • Agile M&D works fine in:
  • unique crisis situations. But if crisis situations are day-to-day business maybe Agile M&D is main cause!
  • environments where normally no projects initialized at all – almost 100% operative business – and don't effect other environments.
    -Agile M&D is like a drug addict, which infects project environment as well.

===================================================
**
Spaghetti Nodes Of Domain Models And Institutions By Agile Procedures Over Time.**

Grafik kann man sich wohl vorstellen !

=====================================================

Agile Management And Development – Consequences And (Dis)advantages (4)

This means stress and personal consequences in conservative and less self-confident environments or organizations in crisis situations.
-That's why we independent contractors are often hired. We have nothing to lose when we challenge concepts, procedures, responsibilities and authorities even by superiors to clean up mess very professional and efficient in organizations – no internal career, no personal own agenda in organization, no made long term enemies etc. We do our job and move on to next contract in next company and leave a company behind made progress by a decade where some people are pleased don't need see us any longer, but rest celebrate us as heroes two years later.

  • Many employees don't understand the reason why we can and must dare disturb harmony for change. We seem to be arrogant, harsh and loud by people who are trained to follow strict chain of command and protocols, not to interfere with competences and authorities by others, risk woes of personal relationship by that and who don't understand rigorous progressive perspective in crisis situations - not to fight just symptoms, but also roots. Therefore we are actually ultimate team players.
  • Don„t use progressive aspects as excuse to act like a jerk! Use your authority in crisis and stress situations short term, but explain or justify yourself always post mortem to everyone middle term. Start with your children for practice.
  • It's a good sign for high profession and self confidence constantly join your political or conceptual enemies for a drink, go back to meeting room, take morning star out of cloakroom and battle for your convincement to the last and vice versa.
  • You must always be prepared that there some people who are not interested in project success and follow own agenda (personal career, being right about own forecast, internal intrigues, imply own concepts etc). Try first Win-Win approach and consider their objections. If not possible, accept some collateral damage and force showdown as soon as possible in crisis situations. Sometimes they are right and project is nonsense. Then try redefine your role or resign after informing clients or superiors.

=======================================================

Soviel aus etwa 200 Folien zu artverwandten Themen.

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo Blaster,

für mich Schlusslolgern, dass keiner von Euch jemals unter einen wirklich starken Projektleiter gedient hat!

Naja, gut dass du das für dich schlussgefolgert hast 😉
Außerdem wenn schon unter einem Projektleiter gedient wird, so läuft mMn einiges falsch, denn es sollte eine Zusammenarbeit sein und keine strikte Befehlskette von oben nach unten wie beim Bundesheer.

Dass auch bei agilen Methoden Lasten-, Pflichtenheft eingesetzt werden, sofern DIN 69901-5 od. IEEE Std 830 gemeint ist, kann ich nicht zustimmen.
Klar muss es bei jedem (professionellen) Projekt eine Vorgabe geben, aber diese erfolgt -- eben aufgrund der sich ändernden Anforderungen od. erst sich während der Entwicklung ergebenden (neuen, geänderten) Anforderungen -- eher durch eine Roadmap, einen Kosten- und Laufzeitrahmen. Hier ist dann Aufgabe des Projekt-Leiters dafür zu sorgen, dass die "must-haves" auch (z.B. iterativ) umgesetzt werden und während der Entwicklung zusammen mit dem Auftraggeber immer neu abgestimmt und priorisiert werden.
UML kann dabei auch eingesetzt werden, aber eher in Form von Use-Case-Diagrammen, Ablaufdiagrammen. Ein big-picture od. hoher Flugmodus über das Projekt, die Teil-Aufgabe (~User Story) eben.
Sequenz- und Klassen-Diagramme sind meist schon beim Erstellen wieder schal, daher sind diese eher zur Dokumentation geeignet, als zur Vorgabe einer Entwicklung.

Deinen zweiten Punkt lass ich (fast) unkommentiert stehen.
Hier ist es äußerst hochgegriffen, was du vielen Entwicklern, die zweifelsohne erfolgreiche Produkte zusammenbringen wie auch genug Beispiele in diesem Thread zeigen, unterstellst.

Punkt drei kann ich auf mehrere Arten betrachten:*Ironisch: wenn du vom Zeitungsverkauf lebst, so bringt die Bildzeitung mehr als eine Fachzeitschrift die kaum einer liest 😉

*Um beim Vergleich mit der Fachzeitschrift zu bleiben: dein Artikel bzw. Beitrag würde dort gar nicht veröffentlicht werden, denn die logischen und vernuftbegabten Argumente sind weder angeführt noch belegt. Das C&P aus deinen Schulungsunterlagen lass ich dabei nicht gelten, denn hier fehlt ein Diskurs, etc.

*außerdem und v.a. hinkt der Vergleich Bildzeitung (~agil) mit Mathe-Fachzeitschrift (~Lastenheft, etc.) schon gewaltig und falls du doch entgegen deiner Ankündigung weiter diskutieren willst, so bitte ich dich auf der sachlichen Ebene zu bleiben -- zumindest solltest du überlegen ob du mit deiner Argumentation nicht auf Bild-Niveau bist.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

3.003 Beiträge seit 2006
vor 6 Jahren

gfoidl:

Klar muss es bei jedem (professionellen) Projekt eine Vorgabe geben, aber diese erfolgt -- eben aufgrund der sich ändernden Anforderungen od. erst sich während der Entwicklung ergebenden (neuen, geänderten) Anforderungen -- eher durch eine Roadmap, einen Kosten- und Laufzeitrahmen. Hier ist dann Aufgabe des Projekt-Leiters dafür zu sorgen, dass die "must-haves" auch (z.B. iterativ) umgesetzt werden und während der Entwicklung zusammen mit dem Auftraggeber immer neu abgestimmt und priorisiert werden.

Und da ist schon der (ein) Knackpunkt bei agilen Methoden. Es gibt keine Grundlagen für ein Angebot. Wie soll man sich an einem Ausschreibungsverfahren beteiligen, wenn schon in der Natur der Sache liegt, dass man den Aufwand gar nicht abschätzen kann? Und woran macht man eine Vertragserfüllung fest? Wie schaut's mit Regress und Mängeln aus, woran macht man die am fertigen Werk juristisch sicher fest? Die agilen Konzepte haben darauf keine überzeugenden Antworten, finde ich. Ich will mich nicht unbedingt auf blaster's Seite schlagen - seine starken Meinungen werden mMn nur ungenügend mit Argumenten gestützt. Aber: man muss zur Kenntnis nehmen, dass in der Projektwelt sehr reichlich Vorurteile ggü agiler Softwareentwicklung bestehen[1], und dass nicht alle dieser Vorurteile unbegründet sind.

Ich selber nutze sehr gern einige Methoden und Konzepte, wenn es passt, aber ich würde deshalb nicht behaupten wollen, dass wir agile Softwareentwicklung betreiben.

LaTino
Anekdote am Rande: voriges Jahr, Ausschreibung eines Projektes mit einem enormen Budget (eher acht als sieben Stellen) und der Aussicht auf einen Fuß in der Tür. Bevor wir dort in Delegation auftauchen und unser Konzept vorstellen dürfen, muss ich von jedem Beteiligten ein Resümee abgeben. Und was passiert: alle mit Schwerpunkt auf Agile werden schlichtweg abgelehnt. Weder durften die mit zur Präsentation, noch weiter am Projekt beteiligt werden. Hat für die eine oder andere hochgezogene Augenbraue gesorgt, dem Projekt aber absolut nicht geschadet, soviel muss ich zugeben.

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo LaTino,

beim Punkt Angebot / Ausschreibung mag ich dir recht geben. Da spießt sich ein agiles Vorgehen mit einem konkreten Angebot.
Aber seien wir ehrlich: wie real wird ein Angebot eingehalten? Ich hab dazu keine konkrete Zahlen parat, aber vorstellen und aus Erfahrung weiß ich, dass sich immer große Abweichungen davon ergeben (entweder zu Gunsten vom Kunden od. zum Auftraggeber). Das geht schon beim Dilemma mit der Schätzung des Aufwands einher, aber das wäre ein eigener Themenpunkt.
Es gibt mehr als genügend Beispiele die mit Ausschreibung, Angebot, genauer Planung mehr als die Ziele verfehlt haben, auch abseits von der SW-Branche -- Stichwort: etliche Flughafen-Bauten im deutsprachigen Raum. Mir ist aber auch klar, dass mehr als genug Beispiele abseits der SW-Branche existieren die genau nach diesem Schema erfolgreich durchgeführt werden. Nur wie erfolgreich das Angebot an der Realität liegt erfährt man nicht, denn es will ja keine Seite zugeben, dass sie zuviel od. zuwenig bezahlt haben.

Die SW ist mehr ein kreativer Prozess und daher nicht von vornherein (bis ins Detail) planbar. Dass sich die Anforderungen i.d.R. während der Projekts ändern hatten wir mehrfach erwähnt.

Für den Punkt Vertragserfüllung sollte beim agilen Vorgehen der Auftraggeber mit an Bord sein, damit dieser die einzelnen Meilensteine (od. wie auch immer das Projekt zerlegt worden sein mag) absegnen kann. Und auch um die weiteren Schritte in der Priorisierung mitbestimmen kann.
In diesem Sinne ist auch die Dokumentation, Mangelansprüche, etc. ein lebendes Dokument bis das Projekt den Status "fertig" erhält. All dies muss sich mit dem Projekt mitentwickeln dann passt das.

Agiles Vorgehen fordert für Auftraggeber und -nehmer mehr Disziplin und sie müssen wissen, worauf sie sich einlassen. Dies kann oft der Knackpunkt sein.
Für die GF mag es leichter sein ein konkretes Angebot zu erhalten und dies zu behandeln, aber real ist das alles nicht. Hinterher gibt es dann Meetings um Erklärungen für den Verzug, zu hohe Kosten, etc. zu finden. Beim agilen ist der Kunde "live dabei" und kann die Richtung ändern, usw.

Ich kann schon verstehen, warum -- wie du auch in der Anekdote genannt hast -- diese Denkweise so drinnen steckt und lösen kann ich das Problem sicher auch nicht. Aber ich bin mir sicher, dass durch agiles, iteratives Vorgehen in Zusammenarbeit mit dem Kunden bessere Produkte, die näher am Wunsch vom Kunden hinsichtlich Anforderung, Kosten, Termine sind entstehen.
Wenn der Kunde dieses Feature noch haben will, dafür verschiebt sich aber der Termin nach hinten od. die Kosten steigen, so kann er ja selbst abwägen ob er dieses Feature dennoch haben will.
Bei starrem Vorgehen hat er dieses Feature und es ist zu teuer und zu spät fertig.

Anmerken will ich noch, dass "agil" schon ein sehr grober Begriff ist und der Erfolg von agilen Projekten auch sehr von der konkrekten Ausprägung im Team und der Mentalität dazu abhängt.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

F
10.010 Beiträge seit 2004
vor 6 Jahren

Ich finde es schade das von beiden Seiten immer ein "entweder oder " beschrieben wird.

Wir haben unsere letzten Projekte ganz "normal" geplant, also vom Kunden (PM) das Lastenheft erhalten, dabei dann Meilensteine "vorgegeben" bekommen und Version 1.0 bis x.y geplant und dann an das Pflichtenheft gesetzt.
Dieses dann auch durchgeplant, mit allem was dazu gehört.

Die Diskrepanzen der Termine dann mit Kunde ( also PM ) in der nächsten Runde besprochen, und das "Spielchen" solange gemacht bis beide Seiten zufrieden waren.

Wir haben explizit kurze Meilensteine ( ausser dem ersten, denn die Client/Server Architektur ist schon aufwändiger ) vereinbart und alle 2 Wochen kurz ( wirklich kurz ) mit Kunde ( PM )
die Fortschritte besprochen.
Hier hatte der PM auch die Chance Änderungswünsche anzusprechen.
Die wurden dann ggf gleich schriftlich niedergelegt ( das feature brauchen wir doch nicht mehr... ) oder ein Zeitabschätzung beantragt.

Wir selber haben unseren täglichen Scrum, und arbeiten uns am Pflichtenheft entlang.

Sind tatsächlich Änderungen an den Meilensteinen, oder an den Features der verschiedenen Versionen gewünscht, muss das schriftlich vom Kunden bestätigt werden.

So haben alle was davon, der Kunde hat recht häufig updates was passiert, er hat Eingriffsmöglichkeiten, die GF hat das Gefühl das alles geregelt abläuft und alle sind mehr oder weniger happy.

Und ein externer AG braucht nicht mal wissen das wir intern Scrum machen, denn das ist ja nur unsere Herangehensweise das Ziel zu erreichen.

3.003 Beiträge seit 2006
vor 6 Jahren

@FZelle, was du beschreibst, ist auch ziemlich genau die übliche Vorgehensweise hier im Haus (auch bei vorherigen AG wurde so oder ähnlich vorgegangen[1]). Ich muss zu meiner Schande gestehen, dass ich die entsprechende Stelle nicht parat habe, aber ich meine, mich zu erinnern, dass im agile manifest etwas in der Art "ganz oder gar nicht" erwähnt wird. Und das lässt sich auch gut begründen. (Vermutlich scheitern auch Projekte daran, dass die agilen Methoden nicht konsequent durchgezogen werden, oder wie Abt sagt, "gelebt" werden.) Insofern betrachte ich diese Art der Softwareentwicklung nicht als agil.

LaTino
[1] die einzelnen Teams - 3-6 Entwickler - entscheiden selbst, wie sie vorgehen. Wir haben welche, die machen scrum nach Lehrbuch, und welche, die eher starr vorgehen, und welche, die sich gar nicht groß organisieren. Kommt auf den Teamleiter an. Solang die Ergebnisse korrekt und rechtzeitig vorliegen, quatscht da auch keiner rein. Gab auch mal so Sachen wie "pair programming friday", fällt mir da ein...das könnte man mal aufleben lassen.

EDIT: mal spasseshalber geschaut: Extreme Programming
Von den Punkten bis "Evolutionäre Praktiken" benutzt mein Team 10 bis 11 (von 12). Dennoch arbeiten wir nicht agil, nur weil wir dieselben Methoden benutzen.

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

E
180 Beiträge seit 2010
vor 6 Jahren

Das Kernproblem was hier im Grunde ausgeklammert wird, ist die Qualität der Anforderungen, die die Basis jeder hier genannter Methodiken bildet. Doch nur selten wird sich drüber Gedanken gemacht. Jede Methodik wird scheitern, egal wie gut sie ist, wenn die Anforderungen nicht durchdacht, zu kurzsichtig oder gar inhaltlich nicht zutreffend sind.

Zudem hat jede Methodik ihre eigene Glaubensgemeinschaft (wie man hier wunderbar erkennen kann), jedoch gibt es keine, die den ultimativen Fall für alles abbildet. Es geht immer nur um die Frage, welche Methodik ist für diesen konkreten Fall die beste, effektivste oder einfach die, die den Anforderungen genügt. Denn in der Realwelt hat man nicht die Zeit, alles immer 150%ig fein auszuarbeiten, da geht es um Zeit und damit Geld - also Wirtschaftlichkeit.

Auch das UML aus der Welt sein soll ist weit weg von der Realität. Im Webbereich mag UML nicht stark vertreten sein, aber überall da, wo es z. B ums Engineering geht, ist sie einfach relevant. Zumal UML nicht automatisch ausschließt das auch Agil gearbeitet werden kann. Es ist nur die Frage wie intensiv man bestimmte Sachen nutzt, was aber wiederum eine Frage von Zeit und Geld ist.

Ich denke nicht das dieser Glaubenskrieg mal wieder zu irgendetwas führt, eher sollte man wirklich sachlich bleiben, was auch für die Mods gilt, und andere Ansichten einfach mal anerkennen und nicht absolut dagegen wettern, nur weils nicht die eigene ist.

Das schöne an der Programmierung ist doch eigentlich das, dass es unendlich viele Möglichkeiten gibt, ein Ziel zu erreichen. Der Unterschied liegt nur in der Art wie man es tut, mit welchen Mitteln und vor allem in welcher Zeitvorgabe. Das sollte doch eigentlich ein guter Ansporn sein für ein wenig mehr Toleranz auch in diesem Sektor. Man muss nicht jede Methodik lieben, aber man sollte wenigstens sie nicht untergraben als wäre es eine heilige Religion.

Meine Meinung.

C
2.121 Beiträge seit 2010
vor 6 Jahren

Ein Denkanstoß.

Aus meiner Sicht wird um die ganzen Benennungen ein viel zu großer Hype gemacht. Es kommt immer drauf an wie sehr man etwas nicht tut oder zuviel davon tut. Sich verzetteln oder auch erfolgreich sein kann man auf verschiedene Arten.

Seitenweise nicht mehr wartbare Dokumente verfassen die später keiner mehr lesen wird, die alles mehrfach evtl. noch in verschiedenen Fassungen und Ständen enthalten, sind ebenso sinnlos wie ein Projekt in dem gar nichts festgehalten wird. Die wenigsten Kunden möchten einem planlosen Entwicklungsprozess zusehen, um dann Stopp zu rufen wenn gerade zufällig das herauskommt was herauskommen sollte.
UML mit all seinen Details die nur Insider verstehen ist genauso wenig hilfreich wie gar kein Bild oder keine Skizze.

Wissen was man macht und warum man es macht, das ist der Schlüssel zum Erfolg. Ist es nicht Nebensache wie es heißt und wie es im Detail aussieht?

742 Beiträge seit 2005
vor 6 Jahren

Mich würde mal interessieren, wie ihr ein Projekt als "erfolgreich" bewertet. Aus IT Sicht mag es ja ausreichen, wenn der Auftraggeber zufrieden ist, aber das heißt ja erstmal gar nichts.

Ich sehe nämlich nicht, dass irgendeine Expertenkommission in der Lage wäre Anforderungen richtig abzuschätzen. Wie soll man als Abteilungsleiter beim Arbeitsamt wissen, wie Daten am besten einzupflegen sind, wenn man das selbst kaum noch selber machen muss? Man kann auch nicht von sich auf andere Benutzer schließen, obwohl dass viele Manager leider versuchen. Das heißt ohne ein Prozess mit kontinuierlichen Experimenten ist die Gefahr einfach extrem groß, dass man in die falsche Richtung rennt (oder das neue Produkt einfach nicht so gut wird wie erwartet).

ich verstehe einfach nicht, wie man NICHT Agile/Lean arbeiten will.

Ich schließe jetzt mal Software für den Eurofighter oder technische Integrationsprojekte hier aus, da mag vll. Agile wirklich nicht so gut funktionieren, habe aber auch noch keine SW für den Eurofighter geschrieben (ist wahrscheinlich besser so).

3.003 Beiträge seit 2006
vor 6 Jahren

Moment, du sagst quasi, agile ist in Ordnung, aber wenn es kritisch wird, würdest du dann doch lieber drauf verzichten? (Davon abgesehen: haltet doch bitte die "Expertenkommissionen" nicht für dämlich. Da sitzen meist richtige Füchse mit drin, und schlaue Leute wissen, wenn sie etwas nicht wissen, und wie sie diese Lücken füllen. Darüber hinaus gibt es normierte, standardisierte, erprobte Vorgehensweisen, um Anforderungen korrekt erfassen zu können. Die Entwicklung dort ist ja nicht in den Achtzigern stehengeblieben.)

Und, äh, wenn der Auftraggeber zufrieden ist, heisst das nichts? Kann ich bitte ein Beispiel haben, wo ein Projekt gescheitert ist, obwohl der Kunde mit dem Ergebnis zufrieden war?

(Vermutlich verstehe ich nicht das, was du ausdrücken wolltest, also bitte kurz erläutern 😃 )

LaTino

"Furlow, is it always about money?"
"Is there anything else? I mean, how much sex can you have?"
"Don't know. I haven't maxed out yet."
(Furlow & Crichton, Farscape)

E
180 Beiträge seit 2010
vor 6 Jahren

Wenn du also einen Kundenauftrag kriegst, der eine Website haben möchte, die rein repräsentativen Charakter hat, möchtest du beginnen mit einem agilen Prozess? Wird der Kunde nicht mitmachen, der möchte erst einmal einen Preis wissen und entscheidet sich dann, ob er den Vertrag macht oder nicht. Und selbst dann möchte der Kunde festgeschrieben haben, was in dem Auftrag enthalten ist oder nicht. Es gibt genügend Fälle, wo der agile Ansatz mit Kanonen auf Spatzen geschossen ist, wie man so schön sagt.

Das Kernproblem sind nicht die Methodiken, sondern die Anforderungen. Und eine Expertenkommission, die die Anforderungen nicht definieren kann, ist einfach keine. Zumal man hier trennen muss, zwischen den einzelnen Holdern, von denen die Fachlichen nur ein Teil sind. Nur die Gesamtmenge schafft ein möglichst klares RE-Dokument.

Ein erfolgreiches Projekt, ist dann erfolgreich, wenn der Kunde das erhält was vereinbart wurde und optimalerweise mit der Nutzung zufrieden ist. Mein Prof sagt immer damals, eine Win-Win Situation. Kunde hat was er wollte, Auftragnehmer erhält die Bezahlung und eine Reputation. Nur das hängt sehr stark davon ab, wie die Differenz zwischen beiden ist, also von dem was der AG wollte / gedacht hatte zu kriegen, und was tatsächlich dabei rauskam. Agil kann dabei helfen, aber nur auf Basis von gutem RE. Geht aber genauso mit herkömmlichen Methoden, auch ohne Agil.

742 Beiträge seit 2005
vor 6 Jahren

@LaTino: Nein ich meinte, dass ich Agile/Lean wenn möglich immer verwenden würde.

Ich grenze das Folgende mal auf Software ein, die von Menschen bedient wird.

Der Kunde ist nicht unbedingt der Nutzer,. Das heißt irgendein Manager oder Projektleiter trifft Entscheidungen und ein Sachbearbeiter nutzt das Ding dann. Oder ein Endkunde für eine SaaS Projekt oder auch nur einfach ein Besucher einer Webseite. Und hier gibt es eine riesige Lücke, weil der Projektleiter einfach nicht wissen kann, was die beste Alternative ist. Soll der Button jetzt grün oder blau sein? Hat uU. einen großen Effekt auf die Conversion. Da hilft Erfahrung auch nicht viel weiter.

Diese Wissenslücke kann der Projektleiter zum Beispiel schließen indem er vor dem eigentlichen Projekt Prototypen baut und sie an Nutzer testet. Aber die besten Tests sind am richtigen Produkt. Agile Entwicklung sorgt für kontinuierliches Feedback durch den Kunden und Lean Development schließt die Feedback Lücke zum Endnutzer. Um die langfristige Zufriedenheit des Kunden zu garantieren, sehe ich keine Alternative.

67 Beiträge seit 2011
vor 6 Jahren

Ich bin da eigentlich auch eher pragmatisch unterwegs. Für mich sind alle Methoden eher Werkzeugkoffer, aus denen man sich bedienen kann und im konkreten Projekt anwendet. Es hängt aber auch sehr stark von den Teams ab. Agil heißt ja auch, dass der einzelne Entwickler "enriched" wird und mehr Eigenverantwortung trägt. Viele wollen das gar nicht und einfach nur ihre Spezifikation runterklimpern. Solche Leute frustriert man mit agilenen Vorgehen eher.

Ich bin bisher immer in Großprojekten im mehrstelligen Millionenbreich unterwegs gewesen. Aktuell arbeite ich als Fachlicher und Technischer Spezifikateur mit ca. 200 Entwicklern, zig Architekten, Designern und was es sonst noch gibt. Das Ganze läuft auch noch Near/Offshore. Ein 100% agiles Vorgehen funktioniert da nicht. Klar, Dinge wie kurze Sprints, enge Zusammenarbeit von Fachbereichen, Desginern, Architekten und Entickwlern, Reviews, Restrospektiven, Stand Ups etc. kommen auch bei uns vor; ist aber kein agiles Vorgehen im eigentlichen Sinne, sondern ein Anwenden bestimmter Praktiken.

Vor allem auf der Planungs- und Steuerungsebene brauche ich andere Methoden bei so einer Projektgröße. Wenn ich meine Issues grob mit Story Points bewerte etc., kann ich kein vernünftiges Reporting oder Budgetplanung machen.

Zum Thema UML: Nutzen wir auch. Man muss da aber imho wissen, wo man den Cut macht. Von tiefgehenden Sequenzdiagrammen, Klassenmodellen halte ich auch eher wenig. Hilfreicher sind Dinge wie Use Cases, Komponentendiagramme, Schnittstellen usw. Letztlich brauche ich sowas auch bei der Projektgröße - einfach, um alles zusammenhalten. Jedes Team würde sonst seine eigene Suppe kochen.

Ich habe auch in solchen Kontexten schon Hardcore Agilisten erlebt. Es gab im aktuellen Projekt ein Entwicklungsteam samit Teamleiter dass sich komplett losgelöst haben: keine Dokumentation mehr, Code First, keine Schätzungen, ihre eigenen Programmier/Architekteurregeln aufgestellt, sich vom Rest des Projekts entkoppelt, ihre Komponente in eigenen Sprints geliefert, nur noch User Stories definiert und mit Story Points bewertet. Auch haben sie an den Spezifikateuren vorbei direkt mit den Fachbereichen gesprochen etc. Führte letztlich zu nem riesen Overhead, der Code war Murks, es konnte keine Schätzungen, Kapazitäts-/Budgetplaungen mehr an die Projektleitung reported werden. Ebenso gab es kein vernüntiges Monitoring mehr.

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

(...) mit ca. 200 Entwicklern, zig Architekten, Designern und was es sonst noch gibt. Das Ganze läuft auch noch Near/Offshore. Ein 100% agiles Vorgehen funktioniert da nicht.

Könntest Du etwas ausführen, warum das denn (bei euch) nicht funktioniert? So hört sich das sehr pauschal an.
Einfach, weil es mehr als 10 Leute sind? Wegen Kultur bei Offshore? Wegen der üblichen Rollen "Architekt", "Designer" statt alle als gleichwertige Teammitglieder zu sehen?

Ist es in den aller meisten Fällen nicht so, dass einfach der alte, seit Jahren verwendete "Hammer" - um beim Werkzeugkasten zu bleiben - sich einfach nicht besser anfühlt, als der neue und es ganz oft eher ein organisatorisches statt ein methodischer Grund ist, wieso agil nicht mehr adaptiert wird?

Ich kenne Software deutlich größer als 200 beteiligte Personen, die Agile sehr weit fortgeschritten haben - nicht nur im Cloud-Umfeld.
Aber ich kenne auch die Sache, dass je größer eine Software ist, desto mehr Köpfe gibt es, die vieles nicht umstellen _wollen _und dadurch Agile nur zum Teil adaptiert wird; weswegen gerade Startups auf ihren grünen Wiesen sehr viel agiler sein können und sind; auch wenn sie sehr stark anwachsen (Uber, Facebook, Snapchat, Instagram, Microsoft, Google, Amazon...).

67 Beiträge seit 2011
vor 6 Jahren

Ich hatte ein anderes Projekt mit 160 Entwicklern und einem Hardcore Agilisten, der das auch nach Scrum Lehrbuch aufziehen wollte. Aber das fängt dann schon mit sehr banalen Fragen an: wie organisier ich ein Daily Stand up? Mit 160 Personen? Spalte ich das in Teams auf? Wer trägt die Informationen aus den Einzelteams weiter und kommuniziert diese? Wer ist Scrum Master? Brauche ich mehrere? Dann brauche ich wieder einen "Super" Scrum Master. Ab dem Punkt bin ich schon wieder bei Hierarchien. Wer steuert die Teams etc. Ab dem Punkt ist man von Lehrbuch Scrum schon wieder weg...

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Sehr gut, darauf wollte ich hinaus 😉
Weder in SCRUM, noch im Wasserfall, hast Du ein unoranisiertes 160 Personen Team.

Schau Dir mal Scrum wirklich an. Der SCRUM Guide sieht eine maximale Teamgröße von 9 Personen vor; da eben ansonsten ein Daily gar nicht strukturiert durchführbar ist geschweige denn, dass ein Team größer 9 noch effizient führbar ist.
Einige Dax Unternehmen haben heute schon die Regel, dass keine Führungskraft zB. mehr als 8 Personen im Team haben darf.

Ergo hast Du eine "Abteilung" von 160 Personen und "Gruppen" von je 9 Personen.
Die Grundstruktur von Abteilungen und Gruppen gibt es in 99% aller Firmen ja schon heute. Nur das Paradigma und die Größen sind halt anders (keine 20 Personen in einem Team, wovon 5 wahrscheinlich nur mit schwimmen).

Und nein, dabei bist Du nicht vom SCRUM Guide weg, sondern genau dieser führt diese Situation wie sehr große Teams.
Ich sage nicht, dass SCRUM auf alles passt (vor allem Kopfsache) aber es ist einfach unwahr, dass SCRUM diese Größen nicht abdeckt.
Und ja, Rollen wie Chief Scrum Master und Chief Product Owner gibt es. Übrigens gibts die in "alten" Strukturen auch schon: Abteilungsleiter, Gruppenleiter, Projektleiter.
Nur sehen die Verantwortlichkeiten etwas anders aus.
Es liegt hier viel eher am Können und an der Erfahrung der Overhead-Personen (SM, PO..).

Ein Scrum Master hat die Verantwortung EINES Teams. Eines. Und zwar auf der Ebene des Projekts und des Teams.
(Gute Scrum Master führen zwei Teams. Sehr gute Scrum Master führen ein Team).
Ein Chief Scrum Master verantwortet das strategische Ziel. Davon hebt er sich deutlich vom normalen Scrum Master ab.
Ein Super Scrum Master gibt es nicht. Die Rollenbezeichnungen sind im Scrum Guide klar definiert.

PS: Auch Scrum hat definierte Hierachien. Scrum ist nicht anarchisch.
PPS: Modelle wie Microservices sind nicht nur Architekturen, sondern haben auch einen Business Impact und Hierarchy Impact.
Technisch gesehen ist ein Micorservice nichts anderes als ein simpler, gut designter zB WebService.
Der Sinn des Microservice hat aber auch den Gedanken der Teamzugehörigkeit: so ist immer ein Team für ein Microservice verantwortlich, ein Microservice wird von einem Team verantwortet. Die sogenannten Cross Functional Teams.
So ein Team ist zB. ein gut geführtes Scrum Team.

Hierzu sei auch Conway's Law erwähnt.

67 Beiträge seit 2011
vor 6 Jahren

Letztlich kommst du dann aber immer auch mehr oder weniger in den Zwang, gewisse Rollen mit gewissen Verantwortlichkeiten zu definieren - wie eben Architekt. In kleinen Teams kann das einzelner Entwickler oder mehere gleichberechtigt machen. Wenn ich aber eine Architektur und Architekturentscheidungen aufstelle für ein Team mit 160 Leuten, kann das mit gleichberechtigt und eigenverantwortlich gemacht werden. Das ist chaotisch.

Letztlich sind wir dann mit einem von dir beschriebenen Mix-Modell gefahren. Keiner hat das Scrum genannt und auch der Hardcore Agilist hat sich mit Händen und Füßen geweigert, das Scrum zu nennen und wollte damit auch nichts mehr zu tun haben.

Aus meiner Sicht ist das auch kein Scrum, sondern der Werkzeugkoffer. Ich nehme einige Rollen, Methoden und Strukturen und versuche in mein bestehendes Organisitionsmodell zu integrieren bzw. passe ich die bestehende Struktur auch an.

Echtes Lehrbuch Scrum kenne ich nur aus Kleinst- und Kleinprojekten.

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Ich selbst bin in den meisten Projekten so ein "Springer" als Architekt und ich finde diese Rolle eigentlich ganz bequem; aber sie entspricht - so wie Du beschrieben, Entscheidung der Architekturen, nicht Scrum.

Das Team sollte die Architektur bestimmen, nicht ein Außenstehender.
Dahingehend sehe ich mich eher als technologischen Berater für die Scrum Teams: das ist völlig legitim.

Wenn ihr 2 Architekten habt, die eine Architektur für 160 Personen vorschreibt, dann seid ihr vermutlich sehr sehr nahe an einem riesigen Monolithen, richtig?

Echtes Lehrbuch Scrum kenne ich nur aus Kleinst- und Kleinprojekten.

Dann schau Dir wie gesagt mal die Großen an: Microsoft, Google, Facebook, Uber.
Aber: die alle haben sehr wahrscheinlich auch ein anderes Organisationsmodell als ihr.

Genauso wie Quellcode bzw. dessen Architektur skalieren soll, muss das ein Unternehmen und eine Struktur auch können.
In Deutschland sind die Standard-Organisationsmodelle leider aber völlig ungeeignet (eben die Kopfsache).
Einige Unternehmen haben das erkannt und kaufen wie wild Agile Coaches ein (kann man sich aktuell eine goldene Nase verdienen), wovon ich aber auch nichts halte.
Man muss es nicht nur erkennen, sondern auch wollen - und an letzterem hapert es leider sehr.

Im einem meiner letzten Unternehmen als Externer - Energieunternehmen - ist sehr viel daran gescheitert, dass es eben Personen gab, die Angst um ihren Arbeitsplatz hatten und ihr Baby (ihre Verantwortung eines Softwareprodukts im Unternehmen) mit Biegen und Brechen nicht hergeben wollten.
Sie wollten ihre Verantwortung, die sie bequem als "unersetzbare Einzelperson" hatten, nicht auf ein Team übertragen.
Daran scheitert Scrum.

190 Beiträge seit 2012
vor 6 Jahren
  • Wer lesen kann, ist klar im Vorteil
  • Meistens sitzt der Fehler vorm Monitor
  • "Geht nicht" ist keine Fehlermeldung!
  • "Ich kann programmieren" != "Ich habe den Code bei Google gefunden"

GidF

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Ziemlich guter Artikel, vor allem der Inhalt der 6 Punkte, wann man es lassen sollte.
Kern: wenn Du kein Bock hast, lass es sein.

Kein einziger Punkt betrifft die Größe, die Branche oder alte Strukturen. 👍

Wer agiler werden möchte, muss zunächst seine Haltung, sein Mindset ändern.

Top Aussage!

463 Beiträge seit 2009
vor 6 Jahren

Gerade den Beitrag in Was haltet ihr von agilen Methoden in der Softwareentwicklung? gelesen - und muss sagen, dass ich schon etwas schockiert bin. Wer heutzutage agile Entwicklung in Frage stellt, sollte doch mal überdenken ob er in der richtigen Branche arbeitet.

Vor allem das Argument/Bemerkung mit den Dailys gab mir sehr zu denken. Also wenn einer von meinen Entwicklern solche Äußerungen machen würde, würde ich ihm nahelegen seinen Job zu überdenken.

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo,

agil lässt sich auch ohne "daily standups" entwickeln. Die sehe ich nicht als notwendig, wenn in der Gruppe / Abteilung / etc. sonst ein offenes und gutes (Gesprächs-) Klima herrscht. Eine Kaffeepause ist oft produktiver als ein daily standup 😉

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Es gibt ja auch keine Vorschrift, wie und wo so ein Daily abgehandelt werden muss.
Ob das nun 15 oder 20 Minuten dauert, spielt auch keine größere Rolle, solang die Kommunikation stimmt und man beim Thema bleibt.

Ich hatte auch schon ein Projekt, wo man jeden Morgen gemeinsam gefrühstückt hat und während dessen das Daily abgehalten hat.
Kam super an und wurde auch fix (Gesamtzeit des Frühstücks 45Min) eingehalten.

Meine Erfahrung ist aber: erst wenn sich das Team gut kennt udn quasi eingespielt ist, empfiehlt es sich, etwas von der "strenge des Dailys" abzuweichen.

C
2.121 Beiträge seit 2010
vor 6 Jahren

Wer heutzutage agile Entwicklung in Frage stellt, sollte doch mal überdenken ob er in der richtigen Branche arbeitet.

Auch auf die Gefahr hin dass du dich persönlich angegriffen fühlst...

Gerade diese Art mit einer Kritik umzugehen dürfte den Fragesteller darin bestärken dass agiles entwickeln tatsächlich nicht mehr bedeutet als fleißiges Häkchen setzen in den Verwaltungsbüros.
Warum kommen da keine Argumente die vom Gegenteil überzeugen?

Wenn ein daily Unsinn ist weil jeder nur das selber erzählt und alle der Meinung sind es reicht auch alle 2 oder 3 Tage, dann wird man nicht nochmal aus allem rausgerissen und hat nach dieser Zeit wenigstens etwas neues zu sagen, dann macht man es eben seltener und dafür produktiver. Problem? Außer für den Häkchensetzer, der soll dann eben drei Häkchen auf einmal machen.

Also wenn einer von meinen Entwicklern solche Äußerungen machen würde, würde ich ihm nahelegen seinen Job zu überdenken.

Sorry nochmal aber auch das muss raus. Lies dir mal den Artikel durch. Beachte Dinge wie Augenhöhe, unangenehme Fragen stellen, Experiment, etwas in Frage stellen (dürfen), an sich arbeiten und eigentlich alles sonstige was da steht. Dann hast du das nämlich schon mal nicht verstanden!
Von daher ganz großes Buuuh für diese Aussage! Wie war das gleich, wer sollte seinen Job überdenken?

Übrigens habe ich nichts gegen agile Methoden. Ich finde nur man sollte sie nicht mit der Peitsche rüberbringen wollen, sondern mit Argumenten.

463 Beiträge seit 2009
vor 6 Jahren

Auch auf die Gefahr hin dass du dich persönlich angegriffen fühlst...

Ich? Niemals!

Gerade diese Art mit einer Kritik umzugehen dürfte den Fragesteller darin bestärken dass agiles entwickeln tatsächlich nicht mehr bedeutet als fleißiges Häkchen setzen in den Verwaltungsbüros.

Agile Entwicklung ist Häkchen setzen? Das Problem ist doch, dass die meisten erst mal alles Neue ablehnen. Auf einmal hat man als Entwickler tägliche Termine, welche man einhalten muss... Geht ja gar nicht, oder? Die Vorteile, der Dailys - regelmäßiger Austausch, sprechen über Probleme - merken/sehen die meisten erst nach 3-6 Wochen.

Wenn ein daily Unsinn ist weil jeder nur das selber erzählt und alle der Meinung sind es reicht auch alle 2 oder 3 Tage, dann wird man nicht nochmal aus allem rausgerissen und hat nach dieser Zeit wenigstens etwas neues zu sagen, dann macht man es eben seltener und dafür produktiver.

Eben nicht - das tägliche Sprechen (= Daily) ist wichtig für das Team und die Entwicklung. Wie dieses Daily stattfindet ist Sache des Teams. Wichtig ist nur - fokusiert auf den Sprint bleiben. Private Geschichten/Erlebnisse oder Diskussionen über Tickets haben im Daily nicht verloren. Dies kann man gerne im Anschluss machen.

Problem? Außer für den Häkchensetzer, der soll dann eben drei Häkchen auf einmal machen.

Nochmals - welche Häkchen? Die Tickets werden während des Dailys aktualisiert....

Übrigens habe ich nichts gegen agile Methoden. Ich finde nur man sollte sie nicht mit der Peitsche rüberbringen wollen, sondern mit Argumenten.

Standardantwort - ich habe nichts dagegen, aber....
Agile Entwicklung führt man nicht an einem WE ein - dieser Prozess dauert je nach Team gerne mal 3-9 Monate... Damit meine ich nicht nur die Einführung, sondern auch das Leben der agilen Entwicklung.

S
80 Beiträge seit 2012
vor 6 Jahren

Gerade den Beitrag in
>
gelesen - und muss sagen, dass ich schon etwas schockiert bin. Wer heutzutage agile Entwicklung in Frage stellt, sollte doch mal überdenken ob er in der richtigen Branche arbeitet.

Vor allem das Argument/Bemerkung mit den Dailys gab mir sehr zu denken. Also wenn einer von meinen Entwicklern solche Äußerungen machen würde, würde ich ihm nahelegen seinen Job zu überdenken.

Eigentlich sollte man sich selber in erster Linie die Fragen stellen: *Bin ich dafür geeignet, mit anderen Menschen zusammen zu arbeiten? *Bin ich fähig Kritik und Verbesserungen entgegen zu nehmen? *Kann ich über mich selber drüber wachsen, damit ich mein Ego begraben kann?

Alles andere, ob man jetzt Agil oder NON-Agil entwickelt, ist zweitrangig. Da muss man auch nicht fanatisch darüber streiten oder fest und entschlossen dafür einstehen.

Das Funktionieren eines Projektes hängt in vielen Dingen von einem Projektmanager/in ab, die/der immer Zeit hat, um Fragen zu klären. Richtige Informationen zur Verfügung stellt und davon reichlich (Richt Place, Right Time, Right Person).

Persönlich sah ich einige Projekte fast scheitern im Agilen und in einem NON-Agilen Umfeld, weil diese Arbeit durch den Vorarbeiter (Projektmanager) nicht erledigt wurden. Man hat sich auf kurze Zusammenfassungen beschränkt, in der Annahme, dass der Programmierer schon wissen würde, was damit gemeint wäre. Was dazu führt, dass viel Zeit in der Kommunikation verbraten wird, weil der Projektleiter keine Zeit findet, um anschließende Details zu klären, und überhaupt die nötigen Informationen an den Programmierer auszuliefern.

Was oben einer schon erwähnt hat "Starker Projektleiter", kann nur dann funktionieren, wenn es ein ordentlicher Projektleiter ist, der seine Grenzen und Einschränkungen wahr nimmt und nicht als Workaholic sich verfeuert.

P.S.: Egal ob Agil (wo ich davor nicht überzeugt war) oder auch nicht, beides kann nur funktionieren, wenn man sich komplett auf das eine oder andere einlässt und sein GROßES Ego abschaltet, auch wenn man sich momentan als Golden Boy der Softwareentwicklung in seiner Firma fühlt. Viele Entwickler neigen leider dazu sich zu hervor zu heben.

----ehm............

C
2.121 Beiträge seit 2010
vor 6 Jahren

Moment! Wir sollten vom selben sprechen.

Standardantwort - ich habe nichts dagegen, aber....

Ja ist Standard. Zum Glück hab ich es nicht auch noch gesagt 😉 Mir gings nicht um das Modell sondern die Art es durchzusetzen. Ich finde den agilen Ansatz nämlich interessant. Daher würde ich ihn lieber mit Interesse statt Druck vermittelt bekommen. Wissen warum man etwas tut, motiviert bleiben statt Resignation. Kritik äußern dürfen was zugegebenermaßen sanfter passieren könnte als im verlinkten Beitrag, dadurch Abläufe verbessern statt immer wieder denselben Overhead zu machen. Jedenfalls nicht zu hören bekommen "tu was man sagt oder verschwinde".

Warum wehren sich viele gegen neues? Weil im beruflichen Alltag so vieles gemacht wird ohne den Grund zu kennen. Entweder wird keiner erklärt, oder niemand will einsehen müssen dass es keinen gibt. Überall ist das so, auch in der IT. Der Vorgesetzte schreit danach und wenns nichts bringt sind die Programmierer schuld. Davor scheut man sich.
Da MUSS man hinterfragen und filtern. Kritik und Fragen sind ein gutes Mittel um überflüssiges von sinnvollem zu unterscheiden. Gerade für den der die Dinge die er vorgibt nicht selbst anwendet. Das bringt Qualität in die Position.

Und was passiert: alle mit Schwerpunkt auf Agile werden schlichtweg abgelehnt.

Womöglich nur weil agil das neue Killwort ist das alle nur um sich werfen und vor lauter neu neu neu nicht mehr wissen wo vorne und hinten ist?

Ich selber nutze sehr gern einige Methoden und Konzepte, wenn es passt, aber ich würde deshalb nicht behaupten wollen, dass wir agile Softwareentwicklung betreiben.

Wert legen auf das was man macht, statt welchem Hype man folgt. Diese Einstellung gefällt mir! Das klingt nach Denkprozessen. Besser als hey Kunde wir machen jetzt agil, nein ich kann nicht erklären warum.

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Das Funktionieren eines Projektes hängt in vielen Dingen von einem Projektmanager/in ab

Ein guter Projektmanager ist eine Hilfe, aber kein Garant.

Ein super eingespieltes Team kann einen schlechten Projektmanager locker abfangen.
Ein guter Projektleiter kann aber kein schlechtes, nicht zusammen passendes Team ersetzen.

M.E. kommt es auch sehr darauf an, wie sich das Team organisiert (DoR, DoD, Diszplin bei Tasks, Planing etc).
Wenn darauf das Team (Mindset) kein Bock hat, hilft der beste Projektmanager nicht.

P
1.090 Beiträge seit 2011
vor 6 Jahren

Daher würde ich ihn lieber mit Interesse statt Druck vermittelt bekommen. Wissen warum man etwas tut, motiviert bleiben statt Resignation. Kritik äußern dürfen was zugegebenermaßen sanfter passieren könnte als im verlinkten Beitrag, dadurch Abläufe verbessern statt immer wieder denselben Overhead zu machen. Jedenfalls nicht zu hören bekommen "tu was man sagt oder verschwinde".

Damit dass „tu was man sagt oder verschwinde“, ein schlechtes Argument ist, hast du natürlich recht. Das ist aber ja grundlegend eine Tür, die in beide Richtungen schwenkt.

Wenn ich hier Argumente lese wie, „Agile Methoden - wie SCRUM, Cristal Clear oder XP sind Anfängerkramm. „ und „"agile ist eine nette Idee, funktioniert nur leider nicht, sobald man eine gewisse Projektgröße erreicht." „, frag ich mich ob die Leute sich wirklich mit Agilen Methoden auseinander gesetzt haben.

Wie Abt schon erwähnt hat, Microsoft , Google usw. entwickeln Agile. Ich denke mal, jedem sollte klar sein das das keine Anfänger sind und die wirklich große Projekte umsetzen. Das entkräftet meines erachten, die erwähnten Argumente.

Und ich denke man sollte hier vielleicht auch anfangen umzudenken. Und sich Fragen wenn es bei Microsoft klappt, kann es dann nicht auch eine Lösung für mich sein?

Ich denke eines der Probleme die „Gegner“ haben, ist oft dass sie sich konkrete Agile Prozesse (z.B. Scrum) anschauen, einen oder mehrere Punkte, sie an dem Prozess stören (Daylies) und deshalb alles Agiles verwerfen.

Ich denke hier lohnt sich einfach mal ein Blick auf die Werte die hinter den Agilen Methoden Stecken. Die sind sehr schön im Agilen Manifest zusammen gefasst. Um es mit anderen Worten auszudrücken.
Der Mensch (ob Entwickler, Kunde usw.) und funktionierende Software, wurden zentraler in den Mittelpunkt gestellt. Wobei es vorher mehr Planung, Dokumentation usw. waren.

Der Ansatz ist vor allem bei Entwicklern gut angekommen. Hier hat sich dann aber häufig die Frage gestellt, wie setzen wir das den jetzt konkret um. Dafür wurden bestehende Ansätze wie z.B. Kanaban/Scrum verwendet. Um den Leute Beispiele für ein Agiles Prozessmodell zu liefern.

Und meines Erachtens, ist z.B. Scrum nicht Agile wenn der Chef von oben kommt und es gegen die Wünsche der Entwickler und Kunden durchsetzt. Nur um zu behaupten, wir arbeiten nach Scrum.
Da gegen ist es meines Erachtens Agiler z.B. CMMI zu verwenden wenn alle Prozessbeteiligten, damit einverstanden sind.

Ich denke hier hat es Microsoft (ca. 2010) gut vorgemacht. Den Entwickler Teams blieb selber überlassen ob sie nach CMMI, Scrum usw. entwickeln wollten. (Ich hatte mich damals mal mit einen Mitarbeiter drüber unterhalten).

Meines Wissens hat sich aber mit der Zeit Scrum und andere Agile Prozessmodell gegenüber CMMI durchgesetzt. Weil Agile Prozessmodelle einige Vorteile gegenüber CMMI haben. (Bei Bedarf kann man auch gerne beide mal Vergleichen).

Damit möchte ich eigentlich zum noch mal den Letzten Punkt des Agilen Maifests ansprechen: „Reagieren auf Veränderungen“. Wenn ihr einen gut funktionierenden Prozess mit CMMI und V-Model hab. Geht ja nicht hin und schmeißt alles von heute auf Morgen um. Was man aber meines Erachtens machen kann, ist mal über den Tellerrand schauen. Was gibt es noch so, wie machen es andere, was kann man verbessern. Um dann vielleicht nach und nach, im zusammen Arbeit mit den Prozessbeteiligen, Verbesserungen herbei zu führen.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Ich denke hier hat es Microsoft (ca. 2010) gut vorgemacht.

Also Microsoft ist mindestens seit Mitte den 90ern mit verschiedenen Methoden agil unterwegs, wenn nicht sogar noch früher.
Das agile Wissen von Microsoft floss ja bereits in die Produkte TFS 2005 und Co ein.

P
1.090 Beiträge seit 2011
vor 6 Jahren

@Abt
Ich hatte 2010 im rahmen des Release vom TFS2010 mit einen Mitarbeiter von Microsoft gesprochen und gefragt welches Prozessmodel MS verwendet (die Frage hatte er wohl schon öfter gehört). Seiner Aussage nach (bezogen auf die Entwickler des TFS), kamen beide Ansätze noch vor. Also CMMI und Agile Methoden und die Teams konnten selber entscheiden was sie Verwenden wollten. CMMI wurde demnach meist von „älteren“ Teams verwendet, die einen sehr gut Funktionierenden CMMI Prozess hatten. „Jüngere“ Teams würden meist Agile Methoden bevorzugen.

Hier noch ein Link, der wohl ganz gut zum Thema passt.
heise:Softwareentwicklung: Agile Methoden sind angesagt

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Das ist sehr schön; Deine Aussage im anderen Beitrag hatte sich dennoch so angehört, dass Microsoft ab 2010 agil ist.
Und das sind sie eben schon deutlich länger.

Ganz viele Firmen sagen, sie wollen nun agil sein, ohne das Mindset zu übernehmen; da hilft auch so eine News nicht.
Es reicht einfach nicht ein Buch über Agilität zu lesen, und dann zu sagen: so, jetzt agil!
So funktioniert das nicht; stellen sich aber viele vor.

Erst gestern wieder ein Kunden-Gespräch gehabt: "wir wollen nun Agil sein, aber weiterhin Lastenhefte verwenden".
Das ist halt einfach ein Widerspruch und das verstehen viele leider einfach nicht (oder wollen es nicht verstehen, oder bekommen es "von oben" durchgedrückt).
Aber mit so einer Haltung oder einem Vorgehen kracht jeder Versuch, agil zu werden.

Das liegt dann aber nicht an der Methodik, sondern ganz einfach am Mindset.

96 Beiträge seit 2012
vor 6 Jahren

gfoidl:

Und da ist schon der (ein) Knackpunkt bei agilen Methoden. Es gibt keine Grundlagen für ein Angebot. Wie soll man sich an einem Ausschreibungsverfahren beteiligen, wenn schon in der Natur der Sache liegt, dass man den Aufwand gar nicht abschätzen kann?

Wenn der Kunde in einem Lastenheft beschreiben kann, was er haben will, kann man auch den Aufwand abschätzen.
Ein Pflichtenheft für ein Angebot beinhaltet doch keine Spezifikation bis in jede Funktion hinein, sondern eine mehr oder weniger grobe Beantwortung der Lasten á la "lösen wir mit unserem Standardmodul xyz" oder "kundenspezifisches Modul".
Wenn das nicht geht, ist das Lastenheft nicht genau genug.

Der Knackpunkt, der m.E. häufiger anzutreffen ist, ist, dass der Kunde nicht genau weiß, was er will. Ein "schaut ja ganz gut aus, aber eigentlich will ich das ganz anders..." sprengt das Projekt häufiger (zumindest ist das meine Erfahrung). Und in diesem Fall ist man mit agilen Methoden viel wendiger.
Oder man bekommt Erfahrung im Change Management. 😉


Gruß
Carlo

"Palabras que no coinciden con hechos no valen nada."

P
1.090 Beiträge seit 2011
vor 6 Jahren

Erst gestern wieder ein Kunden-Gespräch gehabt: "wir wollen nun Agil sein, aber weiterhin Lastenhefte verwenden".
Das ist halt einfach ein Widerspruch und das verstehen viele leider einfach nicht (oder wollen es nicht verstehen, oder bekommen es "von oben" durchgedrückt).
Aber mit so einer Haltung oder einem Vorgehen kracht jeder Versuch, agil zu werden.

Ein Lastenheft ist zwar nicht ganz so, schön geht aber auch. (Ok ich hab da jetzt auch eine andere Rolle und bin da nicht als Berater tätig.)

Aktuell ist es bei einem „neu“ Kunden so, das sie mit dem Vertrieb abgesprochen hatten, unsere Software zu kaufen (brauchen sie auch auf jeden Fall) und das wir noch ca. 50 Schnittstellen implementieren, so das der Kunde die Software mit ihrer Software ansprechen kann. Das wollten sie dann als Komplett Paket kaufen.
Ich bin dann nach Absprache mit meinem Chef, an deren Projektmanager herangetreten, der hat mich dann an den Verantwortlichen in seiner IT weitergeleitet.
Wir haben dann zusammen abgesprochen, das Projekt herunter zu berechne.
Die Software ist ja schon da, die installieren wir jetzt erst mal, dann können sie sie schon benutzen und vielleicht brauchen sie ja dann nicht mehr alle 50 Schnittstellen.
Und wir setzen dann nicht direkt alle 50 Schnittstellen um, sondern haben uns erst mal auf 3 Schnittstellen geeinigt. Das kam auch der IT des Kunden entgegen, die haben da jetzt nicht auf einmal 50 Schnittstellen, die ASAP implementiert werden sollen. Sondern erst mal 3 das kann man im Tagesgeschäft unterbringen. Man sieht direkt wo es Probleme gibt und für den Kunden besteht schon mal ein mehr Wehrt, da es die am häufigsten benötigten Schnittstellen sind.
Für die 3 Schnittstellen möchte der Kunde (und in Zukunft auch für die Weiteren) aber ein Lastenheft haben. Das ist aber jetzt nicht wirklich ein Problem. In der Word Vorlage für das Lastenheft muss ich eigentlich immer nur die Schnittstellen beschreiben, die Umgesetzt werden.

Ich hab es jetzt mal ein wenig ausführlicher Beschrieben, weil ich denke das das Beispiel ganz gut ist, wie man eher Statische Projekte aufbrechen kann und in dem Rahmen zu einer gewissen Agilität kommen kann (Ja ein Lastenheft ist jetzt nicht wirklich Agil, aber wenn stört es?). Und ich denke es spiegelt ganz gut den Agilen Grundgedanken wieder, gemeinsam mit den Kunden zusammen Arbeiten um funktionierende Software zu entwickeln. (Ja ob das mit der funktionierenden Software klappt müssen wir nach mal schauen. 😉 Da bin ich aber sehr zuversichtlich.)

Ein Punkt der mir beim Schreiben aufgefallen ist und der hier meines Wissens nicht wirklich angesprochen würde, ist das „Tooling“ in der Entwicklung. Was sich deutlich verbessert hat und ich denke an vielen Prunkten für ein Agiles Vorgehen wirklich nötig ist.

Wenn ich an meine Anfänge zurückdenke (Modulare Software mit VB6 und .NET Komponenten), wurde da ein maximal zweimal ein Release im einem Jahr gemacht. Das lag auch einfach an dem Aufwand. Alle Entwickler mussten, da irgendwie schauen, das die Passende Version ihrer Software eingecheckt war und die Kollegen auch ihre Passenden „Module“ eingecheckt hatten. Der Build war reine Hexerei, den nur die „alten“ Meister beherrschten. Denn nur sie wussten genau in welcher Reihenfolge welches „Modul“ erstellt werden musste. Und im Anschluss kam dann die QS, die „alles“ Testete, da noch kein Automatischen Test Vorhanden waren. Ein Release hat so mehrere Monate gedauert und war für alle Beteiligten Stress pur.

Unter den Bedingungen hätte ich wohl auch die 50 Schnittstellen in einem Release gepackt.

Gott sei dank haben wir heute Continuous Delivery, ich kann auf Knopfdruck einen Release Build anstoßen. Der ist dann nach ca. 40 Minuten fertig ist, wobei dann schon ein Komplettest Testsystem erzeugt wurde mit Beispieldaten usw. Und grob 1000 Automatisierte Tests (Codet UI , Integrations- und UnitTests) durchgeführt wurden. Mir macht das deutlich mehr Spaß und ich bin auch viel Entspannter wenn eine neue Version zum Kunden ausgeliefert wird.

Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern