Nach welchem Vorgehensmodell entwickelt ihr bei der Arbeit?



  • hustbaer schrieb:

    Einerseits kann man bei der Software-Entwicklung natürlich Dinge übersehen.

    Ersetze mal das kann durch ein wird - ich habe noch kein nicht-triviales Programm erlebt bei der bereits alles bis zur Auslieferung Bestand hatte. Dennoch kann ich auch aus eigener Erfahrung sage, das die Projekte wo noch am meisten geplant wurde und zumindest grundlegende Abläufe eingehalten wurden, qualitativ im Ergebnis besser waren.

    Ich rede hier nicht Zwangsweise nur von Vorgehensmodellen (wobei in Projekten mit einem solchen, meist auch die restlichen Abläufe besser sind). Daran ändern auch nicht Anforderungen die kurz vor der Auslieferung eingegangen sind.

    hustbaer schrieb:

    Bei uns in der Firma ist das ein ziemliches Problem. Da wird z.T. geplant, und dann kommt Herr Schlippsträger mit irgendwelchen komplett sinnfreien Anforderungen, die natürlich "muss" sind, und wirft alles um. Auch gerne nachdem das Projekt schon fast fertig ist.

    Ich bin bei solchen Aussagen inzwischen etwas vorsichtig, auch wenn ich ähnliches kenne: Du kennst die Kunden vermutlich nicht so gut, das du jede "sinnfreie" Anforderung bewerten kannst. Es sei den dies sind Leute die gar nicht mit den Kunden gesprochen haben (Kenne ich durchaus auch) und an diesen vorbei entwickeln weil sie meinen alles besser zu wissen.



  • asc schrieb:

    Ich bin bei solchen Aussagen inzwischen etwas vorsichtig, auch wenn ich ähnliches kenne

    Ich grundsätzlich auch, aber im Moment ist es mal wieder ganz schlimm.



  • qweasdyxc schrieb:

    Vorgehensmodel auf der Arbeit.
    lol ... der war gut.

    👍

    Richtig planen und richtig umsetzen ist oft auch sehr schwierig und bei uns auch nicht wirklich ein Ziel. Wir arbeiten im CAD/Maschinenbaubereich und unsere Software wird von verschiedenen großen Firmen eingesetzt. Die setzen schon andere Software ein und haben viele definierte Workflows. Da müssen wir dann z.B. mit verschiedenen CAD- und PDM-Systemen und z.B. SAP interagieren, oft auch mit zig anderen Sachen. Solche Projekte laufen jahrelang und es kommt ständig was dazu. Da können wir unmöglich von vornherein alle möglichen Anforderungen in dem Bereich überblicken und richtig einplanen.
    Und selbst wenn uns viele mögliche Anforderungen von einem neuen Unterprojekt (sind jetzt nicht direkt Dienstleistungen, es ist schon unsere eigene Software, nur eben nicht für Endkunden und wir orientieren uns natürlich sehr stark an unseren Kunden) im Voraus bekannt sind, würde es oft heißen, dass man mehrere Mannjahre bräuchte, um das komplett richtig umzusetzen. Ist bei unserer Firmengröße nicht drin. Deswegen werden oft Teillösungen implementiert, für die wir erstmal vielleicht ein halbes Jahr Arbeit einplanen. Das wird dann bei den Kunden eingeführt und die können schon mal anfangen zu arbeiten. Dann kommen dazu ständig Service Packs, um Probleme zu beheben (ich rede explizit nicht von Bugs) oder dringend benötigte Funktionen nachzuliefern. Nach paar Jahren wird das ganze dann auch komplett umgesetzt, aber bis dahin haben sich die Anforderungen wahrscheinlich eh schon stark verändert und die Kunden konnte damit schon arbeiten und wir haben dann auch viel Feedback bekommen und Reallife UseCases gesehen.



  • Nach dem Chaos-Modell



  • Scrum



  • @Tyrdal: Macht ihr so wirklich SCRUM? Also so, dass zum Beispiel der SCRUM Master nicht gleichzeitig noch Product Owner und am besten noch Team Member ist? Mit Sprint Kickoff, Retrospektive und Daily Scrums? Mich würde interessieren, ob das tatsächlich irgendwo so durchgezogen wird wie es mal angedacht war. Bei uns ist es nämlich nicht so und wir sagen auch, dass wir nach SCRUM arbeiten 😉



  • Der Srummaster ist zwar Temamember kommt aber vor lauter Scrum kaum zum arbeiten. Ansonsten, ja nach Lehrbuch. Das kann recht nervig sein.



  • Naja SCRUM hat mit Software-Design nicht viel zu tun.
    Wobei ich mir nicht sicher bin worum es dem OP geht.
    Um den Administrativen Teil, Zeit- und Resourcenplanung etc. - da wäre SCRUM ein Thema.
    Wenns ums Software-Design geht wären vielleicht RUP, XP etc. relevant, SCRUM aber sicher nicht.



  • Würde mich auch mal interessieren, wir man mit Scrum vernünftig Software entwickeln kann.
    Geht ihr da wirklich so vor, dass man nach jedem Sprint eine "fertige" Software hat? Wie bekommt man da eine vernünftige Softwarearchitektur hin, wenn man immer nur Teile entwickelt? Woher weiß man, ob der nächste Teil noch zum vorigen passt? Macht ihr ständig Refactorings? Muss man da nicht ständig sein Datenbankmodel/Fileformat/Klassendesign wegwerfen bzw. umbauen?



  • Ich habe das Gefühl, die Modelle sollten besser zur Analyse dienen, statt als Leitfaden: als Hilfe um zu verstehen, wie es gelaufen ist und läuft, um Fehler auf den Punkt zu bringen und beheben zu können. Sie sollten, so man die üblichen Modelle kennt, der Universalschlüssel sein, um sein Feedback zu entschlüsseln und einbringen zu können im Sinne des Unternehmens.

    Aber wer analysiert schon, wenn man stattdessen planen kann. Man male sich mal ein Schreckgespenst aus, einen BWL-er, der keine Ahnung davon hat, was er verkauft.

    Oft werden die Modelle vorausgeworfen ohne jede Absicht der Rückkoppung, sogar als Methode, sich vor Rückkopplung abzuschirmen. Dann sind sie natürlich sehr gut.



  • arbeiter schrieb:

    Würde mich auch mal interessieren, wir man mit Scrum vernünftig Software entwickeln kann.
    Geht ihr da wirklich so vor, dass man nach jedem Sprint eine "fertige" Software hat? Wie bekommt man da eine vernünftige Softwarearchitektur hin, wenn man immer nur Teile entwickelt? Woher weiß man, ob der nächste Teil noch zum vorigen passt? Macht ihr ständig Refactorings? Muss man da nicht ständig sein Datenbankmodel/Fileformat/Klassendesign wegwerfen bzw. umbauen?

    So allgemein wie du fragst kann man nur antworten: Informier dich über Scrum.



  • hustbaer schrieb:

    Naja SCRUM hat mit Software-Design nicht viel zu tun.

    Nach Design war doch gar nicht gefragt.



  • @Tyrdal
    Ich meine nicht unbedingt Modelle die genau beschreiben wie man designt. Sondern z.B. wann welche Teile entworfen werden.

    Und darum geht es sehr wohl in der Frage. Es wurden explizit Wasserfallmodell und Spiralmodell angesprochen. Beide haben viel mit Design zu tun.
    Das Wasserfallmodell schreibt vor dass die gesamte Software erstmal entworfen wird, bevor angefangen wird sie zu implementieren.
    Das Spiralmodell dagegen schreibt hier einen zyklischen Prozess vor.

    Und...
    So allgemein wie du antwortest: hast du auch was konkretes zu sagen? Oder solltest du dein "Informier dich über Scrum" vielleicht an dich selbst richten?



  • Naja sicher ist Scrum in gewisser Weise othogonal zu sowas wie Wasserfallmodell, aber in der Praxis neigen Entwicklungen doch bei allen Modellen Spiralen zu werden (auch bei Wasserfall). Von daher ...



  • Von daher was?

    Ich glaube schon dass es zu dem Thema etwas mehr zu sagen gibt als "werden eh immer Spiralen".



  • Dann sags.



  • http://www.heise.de/developer/meldung/Studie-Continuous-Delivery-ist-De-facto-Standard-fuer-Software-Entwicklung-2100842.html

    Wassermodel und Spiralmodel sind übrigens Vorgehensmodelle aus der Steinzeit, an den Hochschulen wird so etwas altes gar nicht mehr gelehrt.


Anmelden zum Antworten