Abo
  1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Mitarbeiterführung: Fünf Faktoren…

nicht nur agile, diese Regeln gelten allgemein

  1. Thema

Neues Thema Ansicht wechseln


  1. nicht nur agile, diese Regeln gelten allgemein

    Autor: ZwoVierNeun 22.08.19 - 12:32

    Und gerade die erste Regel ist symptomatisch für Software. Da wird eine Spec oder ein Lastenheft hingekachelt und ein völlig sachfremder Entwickler setzt 1:1 das um, was da drin steht. Ich habe allerdings noch niemals eine Spec gesehen, die auf Anhieb das exakt umschrieben hat, was der Kunde tatsächlich will. Mal fehlt es an Kleinigkeiten, mal sind elementare Fehler drin. Und der Workflow, mit dem der Nutzer arbeiten soll und mit dem er vielleicht schon arbeitet, bleibt völlig unberücksichtigt. Am Ende bekommt er häufig ein Produkt, das seine Erwartungen nicht erfüllt, mit dem er nicht gerne arbeitet und das im Nachgang umzubauen erheblichen Aufwand verursacht. Insofern sollte der Entwickler nicht nur mit Verantwortlichen des Kunden, sondern ganz konkret mit Nutzern in Kontakt stehen und sich auch mal anschauen, wie die seine Software überhaupt nutzen. Zudem sollte man offen und ehrlich miteinander umgehen. Weder kleingerechnete Angebote noch entsprechend geschönte, aber unrealistische Zeitpläne sind hilfreich.

  2. Re: nicht nur agile, diese Regeln gelten allgemein

    Autor: aLpenbog 22.08.19 - 13:43

    Sehe ich auch so, ist aber oft auch nicht gewollt. Und oft blockt da auch der Kunde. Wir hatten schon einige Projekte die am Ende einen deutlichen Mehraufwand bedeutet haben, da die obere Etage beim Kunden selbst nicht wusste, was im Unternehmen abläuft.

    Das vorher abzuklären, dafür möchte man aber nicht zahlen, sondern entscheidet einfach oben drüber Abläufe, die so nicht möglich sind. Testen möchte man auch nicht oder die Software soll ins Testsystem und man testet intern, dafür streicht man den Punkt und spart wieder ein paar Euro. Das zeigt sich dann hinterher in der Praxis und bedeutet Worst Case zurück auf Anfang mit doppelten Kosten und einer Entlassung.

    Aber Kunde ist König. Hauptprobleme sind eben immer Geld und fehlende Kommunikation. Bei der Kommunikation kann eine agile Arbeitsweise, vor allem aber die Tools die damit kommen hier und da helfen. Oft werden auch Verantwortlichkeiten hin- und hergeschoben und es kommen Workarounds ins System #1, weil man System #2 nicht mehr anfassen möchte, dafür niemanden greifbar hat usw. Man darf quasi bewusst geplant Sche.. umsetzen.

    Das gibt es aber natürlich auch anders herum, wo man selbst eher Sche.. umsetzt, weil man für eine vernünftige Lösung im Gewährleistungsfall keine Freigabe kriegt, auch wieder Geld.. am Ende endet es mit etlichen kleinen Iterationen, die wie Pflaster auf einen Dolch geklebt werden, der im Herzen steckt.

    Mehr Kommunikation und ja auch mit den kleinen Endkunden, sich anschauen wie der arbeitet, wie die Abläufe sind und nach Möglichkeit immer eine gute Lösung, auch wenn sie an irgendeiner Seite erstmal ein paar Mehrkosten verursacht. Gerade bei Sachen die noch geändert und erweitert werden recht sich das im Anschluss sonst eh.

    Mal ab von politischen Sachen, wo Leute Angst haben um Regressansprüche und sich mehre Gewerke die Schuld in die Schuhe schieben und mehr Energie verschwenden Gründe zu finden warum der andere Schuld ist, anstatt an die offensichtlichen Probleme zu gehen.

    Ob nun "agile" oder nicht, habe ich bis dato noch nie groß als Problem gesehen. Kommunikation, kleinere Häppchen und genug Geld auf beiden Seiten, um gute Lösungen umzusetzen sind imo meist die Hauptpfeiler.

  3. Re: nicht nur agile, diese Regeln gelten allgemein

    Autor: Serenity 22.08.19 - 14:49

    ZwoVierNeun schrieb:
    --------------------------------------------------------------------------------
    > Und gerade die erste Regel ist symptomatisch für Software. Da wird eine
    > Spec oder ein Lastenheft hingekachelt und ein völlig sachfremder Entwickler
    > setzt 1:1 das um, was da drin steht. Ich habe allerdings noch niemals eine
    > Spec gesehen, die auf Anhieb das exakt umschrieben hat, was der Kunde
    > tatsächlich will.

    Das liegt aber nicht daran, dass nicht agil gearbeitet wird, sondern dass die Leute entweder nicht wissen, dass es sowas wie einen Requirement Engineer gibt oder einfach nicht wissen, wie man richtig Anforderungen (Ermitteln, Dokumentieren, Prüfen & Abstimmen und Verwalten) erstellt.
    Man denkt, wenn man schnell genug mit dem Programmieren anfängt, kann man schneller fertig werden. Das ist ein weit verbreiteter Irrglaube.

  4. Re: nicht nur agile, diese Regeln gelten allgemein

    Autor: chewbacca0815 22.08.19 - 16:03

    aLpenbog schrieb:
    --------------------------------------------------------------------------------
    > ... Und oft blockt da auch der Kunde. Wir hatten schon einige Projekte die am Ende einen deutlichen Mehraufwand bedeutet haben, da die obere Etage beim Kunden selbst nicht wusste, was im Unternehmen abläuft.

    Klingt nach Regel 5 und passiert leider viel zu häufig. Je größer der Kunde, desto weiter weg vom Geschehen sind natürlich auch dessen Entscheider, egal ob Einkauf oder Exekutive - diese Gruppen wissen doch zumeist als Allerletzte, was wirklich benötigt wird, ziehen aber oftmals die gesamte Entscheidung an sich. Hier einen Ausweg aus diesem Dilemma zu finden dürfte mehr als schwierig werden; wer gesteht sich doch schon gerne gerade gegenüber Außenstehenden ein, von der Materie eigentlich keine Ahnung zu haben?

  5. Re: nicht nur agile, diese Regeln gelten allgemein

    Autor: theonlyone 22.08.19 - 19:57

    Entwickler denken wie Entwickler, nicht wie die User.

    Grundsätzliches unlösbares Problem das Entwickler niemals wie die User denken.
    Können sie auch gar nicht, weil sie die Details kennen, das Wissen das man hat kann man nicht einfach abschalten.


    Genau deshalb muss die Spezifikation jemand schreiben der weiß wie die Arbeit gemacht werden muss.

    Dann muss man sich Gedanken um den Prozess machen und eventuelle Schritte eliminieren die nicht notwendig sind (also genau das was man mit einer guten IT Lösung automatisieren kann und Umwege vermeidet).


    Schlechte Spezifikationen kommen oft von Menschen die ihren Prozess selbst nicht verstehen, oder zumindest nur teilweise.
    Es liegt dann an der Person die so eine Spezifikation "abnehmen" soll zu erkennen das etwas nicht korrekt ist ; genau das ist der Knackpunkt an dem entscheidende Entscheidungen getroffen werden müssen ; noch bevor irgendetwas entwickelt wird, hier sind Änderungen am günstigsten, da man noch nichts produziert hat.

    Bevor man dann direkt loslegt entwickelt man erst mal ein Mockup, einen prototyp.
    Da kann der Kunde dann noch sagen, ja das geht in die Richtung, oder noch frühzeitig Änderungen ankurbeln bevor es an den Beef geht der Entwicklung.

    Wenn sich grundlegend ständig die Spezifikationen ändern, dann sind das schwerwiegende Change Requests die eben auch sehr teuer sind.


    Das gibt es immer mal, sollte aber eben nicht die Regel sein.

    Entwickler sollten sich um die technische Umsetzung kümmern. Zu verlangen das ein Entwickler die Spezifikation schreibt ist eigentlich schlichtweg weltfremd und produziert nur umso mehr Köche die den Brei versalzen ; den was der Entwickler als tolle Verbesserung wahrnimmt ist für den Anwender eventuell kompletter Humbug, oder Features die so ins Detail gehen das sie nicht gebraucht werden vom 0815 User.
    Thema, Feature-Creep ; das können Entwickler hervorragend und da muss man eben gegensteuern anstatt das noch zu befördern.


    In meinen Projekt-Erfahrungen habe ich erkannt das es immer jemanden braucht der den Prozess verstanden hat ; im Detail muss geklärt sein was wirklich gewollt ist.

    Das Feedback der Entwickler, oder eines Implementierungsleiters sollte klar sein um die technische Lösung.

    Ein Projekt-Planer muss technisch nur rudimentär wissen was möglich ist, bei Fragen geht das an den Implementierungs-Leiter mit technischem Know-how.

    Für den Reality-Check ist es immer gut wenn alle zumindest mitdenken, damit logische Fehler erkannt werden können.

    Aber wenn Spezifikationen schon löchrig wie ein Käse sind und zu abstrakt, dann muss der Entwickler beim lesen der Spez eben schon sagen das die nicht genau genug ist ; ergo, nicht drauf los entwickeln nach gut denken, sondern klar direkt abweisen ; da muss nachgearbeitet werden.
    Wer blind entwickelt ist schlichtweg für den Quark verantwortlich, das ist fahrlässig und unprofessionell.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Bayerische Versorgungskammer, München
  2. Bundesamt für Verbraucherschutz und Lebensmittelsicherheit, Berlin, Braunschweig
  3. transmed Transport GmbH, Regensburg
  4. Stadtwerke Heidelberg GmbH, Heidelberg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 51,99€
  2. 3,83€
  3. 2,80€
  4. 4,19€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Acer Predator Thronos im Sit on: Der Nerd-Olymp
Acer Predator Thronos im Sit on
Der Nerd-Olymp

Ifa 2019 Ob wir es nun den eisernen Thron oder den Sitz der Götter nennen: Der Predator Thronos von Acer fällt auf dem Messestand des Herstellers schon auf. Golem.de konnte den skurrilen Stuhl ausprobieren. Er ist eines Gaming-Kellers würdig.
Ein Hands on von Oliver Nickel

  1. Nitro XV273X Acer baut ersten Monitor mit IPS-Panel und 240 Hz
  2. Acer Beim Predator-Notebook fährt die Tastatur wie eine Rampe aus
  3. Geräte für Mediengestalter Acer gibt Verfügbarkeit der Concept-D-Laptops bekannt

5G-Antenne in Berlin ausprobiert: Zu schnell, um nützlich zu sein
5G-Antenne in Berlin ausprobiert
Zu schnell, um nützlich zu sein

Neben einem unwirtlichen Parkplatz in Berlin-Adlershof befindet sich ein Knotenpunkt für den frühen 5G-Ausbau von Vodafone und Telekom. Wir sind hingefahren, um 5G selbst auszuprobieren, und kamen dabei ins Schwitzen.
Von Achim Sawall und Martin Wolf

  1. Tausende neue Nutzer Vodafone schafft Zuschlag für 5G ab
  2. Vodafone Callya Digital Prepaid-Tarif mit 10 GByte Datenvolumen kostet 20 Euro
  3. Kabelnetz Vodafone bekommt Netzüberlastung nicht in den Griff

Garmin Fenix 6 im Test: Laufzeitmonster mit Sonne im Herzen
Garmin Fenix 6 im Test
Laufzeitmonster mit Sonne im Herzen

Bis zu 24 Tage Akkulaufzeit, im Spezialmodus sogar bis zu 120 Tage: Garmin setzt bei seiner Sport- und Smartwatchserie Fenix 6 konsequent auf Akku-Ausdauer. Beim Ausprobieren haben uns neben einem System zur Stromgewinnung auch neue Energiesparoptionen interessiert.
Ein Test von Peter Steinlechner

  1. Fenix 6 Garmins Premium-Wearable hat ein Pairing-Problem
  2. Wearable Garmin Fenix 6 bekommt Solarstrom

  1. Lufttaxi: Volocopter hebt in Stuttgart ab
    Lufttaxi
    Volocopter hebt in Stuttgart ab

    In Stuttgart ist der Volocopter erstmals in einer europäischen Innenstadt abgehoben. Rund vier Minuten befand sich das Flugtaxi in der Luft. Für kommerzielle Flüge fehlt jedoch noch die Genehmigung.

  2. Pixel: Googles neue Kamera-App vom Pixel 4 geleakt
    Pixel
    Googles neue Kamera-App vom Pixel 4 geleakt

    Programmierer haben sich die geleakte neue Version von Googles Kamera-App genauer angeschaut und einige Verbesserungen in der Benutzerführung entdeckt. Zudem sollen Nutzer die automatischen Hinweise während der Aufnahme abschalten können.

  3. Wikileaks: Assange kommt nicht frei
    Wikileaks
    Assange kommt nicht frei

    Eigentlich endet Julian Assanges Freiheitsstrafe am 22. September. Eine Richterin entschied jedoch, dass er auch nach dem Verbüßen seiner Haftstrafe im Gefängnis bleiben muss.


  1. 15:47

  2. 15:11

  3. 14:49

  4. 13:52

  5. 13:25

  6. 12:52

  7. 08:30

  8. 18:01