Nach welchem Vorgehensmodell entwickelt ihr bei der Arbeit?



  • Nach welchem Vorgehensmodell (Wasserfallmodell, Spiralmodell,...) entwickelt ihr eure Software bei der Arbeit? Und wenn ihr es noch sagen wollt/dürft, in welcher Branche (Auto, Games, Bank,...) arbeitet ihr?



  • arbeiter schrieb:

    Nach welchem Vorgehensmodell (Wasserfallmodell, Spiralmodell,...) entwickelt ihr eure Software bei der Arbeit? Und wenn ihr es noch sagen wollt/dürft, in welcher Branche (Auto, Games, Bank,...) arbeitet ihr?

    Ich habe in genau einer von 4 Firmen überhaupt so etwas wie ein Vorgehensmodell erlebt, und dort war es auch eher ein grobes Modell an dem man sich nicht allzu stringent gehalten hat. Branchen umfassen hierbei unter anderem CRM- und ERP-Software (meist für mehr als eine Branche, tendenziell Dienstleistung).



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



  • Noch ein Nachtrag:

    Vorgehensmodelle wird man tendenziell dort finden wo Kosten eine geringere Rolle spielen (sprich: Staatsaufträge, Banken, Sicherheitskritische Systeme).

    Die meisten Softwarebuden... ähh ich meine natürlich "Dienstleistungsfirmen" arbeiten aber eher nach dem Prinzip möglichst schnell, schnell, schnell. Dumm nur wenn aus kurzzeitig geplanten Projekten dann eine langfristige Produktlinie wird (so habe ich das z.B. schon in einer Firma erlebt; 90% der Zeit war man eigentlich rein an der Fehlerkorrektur für Altcode).

    Wobei auch ohne festes Vorgehensmodell durchaus auch gute Software entstehen kann. Ich würde sagen die Tendenz für gute Software ist aber auch abhängig von der Planungszeit und der Umsetzung, sprich es erhöht sich durchaus mit solchen Modellen (wobei auch solche Software fehlschlagen kann).



  • Vorgehensmodell?! Hä, wie jetzt?? Unser Vorgehensmodell heißt: Zurufen und dann schnell einbauen:-D

    Ne im Ernst, wir haben zwar Projektziele aber die sind selten genau definiert. Wir entwickeln erstmal grundsätzlich für intern. Das macht das Ganze sehr einfach. Aber wir haben mindestens alle zwei Tage jemanden im Büro der fragt: Und, wie weit seid ihr? Und dann geht mal die Neuerungen durch und dann wird da mal was umgebaut und hier was hinzugefügt usw.

    Ich finde es ist eh eine Kunst für sich bei großen Softwareprojekten einen Termin anzugeben. Sind wir mal ehrlich und realistisch...Bei großen Projekten ist das eh kaum machbar weil irgendwie immer was dazwischen kommt. Ich habe gestern noch einen Bericht im Handelsblatt gelesen, was die größten Projekte angeht die vor die Wand gefahren wurden(aus welchen Gründen auch immer). Es ging dabei hauptsächlich um Projekte, dessen Träger öffentliche Institutionen wären. Thema ELENA usw.



  • asc schrieb:

    Ich würde sagen die Tendenz für gute Software ist aber auch abhängig von der Planungszeit und der Umsetzung, sprich es erhöht sich durchaus mit solchen Modellen (wobei auch solche Software fehlschlagen kann).

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

    Andrerseits kommen dann aber noch die Schlippsträger dazu.
    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.



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


Anmelden zum Antworten