myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
   » Plugin für Firefox
   » Plugin für IE
   » Gadget für Windows
» Regeln
» Wie poste ich richtig?
» Datenschutzerklärung
» wbb-FAQ

Mitglieder
» Liste / Suche
» Stadt / Anleitung dazu
» Wer ist wo online?

Angebote
» ASP.NET Webspace
» Bücher
» Zeitschriften
   » dot.net magazin

Ressourcen
» guide to C#
» openbook: Visual C#
» openbook: OO
» MSDN Webcasts
» Search.Net

Team
» Kontakt
» Übersicht
» Wir über uns
» Impressum

» Unsere MiniCity
MiniCity
» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Gemeinschaft » Smalltalk » UML, Pflichtenheft, Feinspezifikationen vs. agile Methoden
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

UML, Pflichtenheft, Feinspezifikationen vs. agile Methoden

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
myCSharp.de
Moderationshinweis von gfoidl (19.04.2017 23:05):

Abgeteilt von  Modellierungs-Tools um aus UML C# Klassen zu generieren
 
Abt
myCSharp.de-Team

images/avatars/avatar-2981.png


Dabei seit: 20.07.2008
Beiträge: 9.869
Herkunft: Süddeutschland


Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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?
19.04.2017 13:38 Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

images/avatars/avatar-1871.jpg


Dabei seit: 03.04.2006
Beiträge: 2.602
Entwicklungsumgebung: VS 2008 / VS 2017 / VS Code
Herkunft: Thüringen


LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
...
19.04.2017 14:01 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

images/avatars/avatar-2981.png


Dabei seit: 20.07.2008
Beiträge: 9.869
Herkunft: Süddeutschland

Themenstarter Thema begonnen von Abt

Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

.. 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.
19.04.2017 14:07 Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

images/avatars/avatar-1871.jpg


Dabei seit: 03.04.2006
Beiträge: 2.602
Entwicklungsumgebung: VS 2008 / VS 2017 / VS Code
Herkunft: Thüringen


LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
19.04.2017 14:21 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Blaster
myCSharp.de-Mitglied

Dabei seit: 30.10.2013
Beiträge: 54


Blaster ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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/

Dieser Beitrag wurde 8 mal editiert, zum letzten Mal von Blaster am 19.04.2017 18:16.

19.04.2017 15:33 Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

images/avatars/avatar-2981.png


Dabei seit: 20.07.2008
Beiträge: 9.869
Herkunft: Süddeutschland

Themenstarter Thema begonnen von Abt

Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von Blaster:
Agile Methoden - wie SCRUM, Cristal Clear oder XP sind Anfängerkramm.

Wow. Dazu fällt mir nichts mehr ein.
19.04.2017 16:02 Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

images/avatars/avatar-1871.jpg


Dabei seit: 03.04.2006
Beiträge: 2.602
Entwicklungsumgebung: VS 2008 / VS 2017 / VS Code
Herkunft: Thüringen


LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat von Abt:
Zitat von Blaster:
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
19.04.2017 19:10 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
FZelle
myCSharp.de-Poweruser/ Experte

Dabei seit: 23.04.2004
Beiträge: 9.675


FZelle ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
19.04.2017 20:27 Beiträge des Benutzers | zu Buddylist hinzufügen
Abt
myCSharp.de-Team

images/avatars/avatar-2981.png


Dabei seit: 20.07.2008
Beiträge: 9.869
Herkunft: Süddeutschland

Themenstarter Thema begonnen von Abt

Abt ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.

Zitat:
"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 :-)
19.04.2017 22:02 Beiträge des Benutzers | zu Buddylist hinzufügen
gfoidl gfoidl ist männlich
myCSharp.de-Team

images/avatars/avatar-2894.jpg


Dabei seit: 07.06.2009
Beiträge: 6.211
Entwicklungsumgebung: VS 201[25]
Herkunft: Waidring


gfoidl ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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ü
19.04.2017 23:17 Beiträge des Benutzers | zu Buddylist hinzufügen
Blaster
myCSharp.de-Mitglied

Dabei seit: 30.10.2013
Beiträge: 54


Blaster ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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! geschockt

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. unglücklich

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

Zitat:
===========================================
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.

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Blaster am 20.04.2017 11:51.

20.04.2017 11:49 Beiträge des Benutzers | zu Buddylist hinzufügen
gfoidl gfoidl ist männlich
myCSharp.de-Team

images/avatars/avatar-2894.jpg


Dabei seit: 07.06.2009
Beiträge: 6.211
Entwicklungsumgebung: VS 201[25]
Herkunft: Waidring


gfoidl ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo Blaster,

Zitat:
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ü
20.04.2017 13:09 Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

images/avatars/avatar-1871.jpg


Dabei seit: 03.04.2006
Beiträge: 2.602
Entwicklungsumgebung: VS 2008 / VS 2017 / VS Code
Herkunft: Thüringen


LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

gfoidl:

Zitat von 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.
20.04.2017 14:20 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
gfoidl gfoidl ist männlich
myCSharp.de-Team

images/avatars/avatar-2894.jpg


Dabei seit: 07.06.2009
Beiträge: 6.211
Entwicklungsumgebung: VS 201[25]
Herkunft: Waidring


gfoidl ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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ü
20.04.2017 16:38 Beiträge des Benutzers | zu Buddylist hinzufügen
FZelle
myCSharp.de-Poweruser/ Experte

Dabei seit: 23.04.2004
Beiträge: 9.675


FZelle ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
20.04.2017 16:45 Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

images/avatars/avatar-1871.jpg


Dabei seit: 03.04.2006
Beiträge: 2.602
Entwicklungsumgebung: VS 2008 / VS 2017 / VS Code
Herkunft: Thüringen


LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

@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.

Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von LaTino am 21.04.2017 05:57.

21.04.2017 05:48 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Equilibrium
myCSharp.de-Mitglied

Dabei seit: 11.05.2010
Beiträge: 179


Equilibrium ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
21.04.2017 08:02 Beiträge des Benutzers | zu Buddylist hinzufügen
chilic
myCSharp.de-Poweruser/ Experte

Dabei seit: 12.02.2010
Beiträge: 1.841


chilic ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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?
21.04.2017 13:35 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
malignate
myCSharp.de-Mitglied

images/avatars/avatar-3206.png


Dabei seit: 18.02.2005
Beiträge: 741


malignate ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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).
24.04.2017 11:54 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
LaTino LaTino ist männlich
myCSharp.de-Poweruser/ Experte

images/avatars/avatar-1871.jpg


Dabei seit: 03.04.2006
Beiträge: 2.602
Entwicklungsumgebung: VS 2008 / VS 2017 / VS Code
Herkunft: Thüringen


LaTino ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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
24.04.2017 12:04 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Equilibrium
myCSharp.de-Mitglied

Dabei seit: 11.05.2010
Beiträge: 179


Equilibrium ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

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.
24.04.2017 12:09 Beiträge des Benutzers | zu Buddylist hinzufügen
malignate
myCSharp.de-Mitglied

images/avatars/avatar-3206.png


Dabei seit: 18.02.2005
Beiträge: 741


malignate ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

@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.
24.04.2017 12:36 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum
Antwort erstellen


© Copyright 2003-2017 myCSharp.de-Team. Alle Rechte vorbehalten. 28.04.2017 12:08