Abo
  1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Agilität: Wenn alle bestimmen, wo…

Der Mensch brauch Struktur

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Der Mensch brauch Struktur

    Autor: PerilOS 29.10.18 - 09:42

    Und all diese "Agilen" Methoden bieten keine vernünftige Struktur.
    Aus meiner Erfahrung die ich bei SCRUM Teams beobachten konnte ist, dass es in mehr Streß für die einzelnen ausartet, mehr Erwartungen entstehen und am Ende trotzdem nicht mehr bei rum kommt. Ob Mittelstand oder Weltkonzern hat da bis jetzt keinen Unterschied gemacht. All diese Methoden haben in der Regel Personal gekostet und Entwicklungen verzögert.

    Ein Projekt bzw. eine Firma steht und fällt mit dem Management. Das ist essenziell zum erreichen des Ziels. Ein gutes Management fällt Entscheidungen auf Basis der Faktenlage und das Feedback von vor und hinter gelagerten Personen. Das einbeziehen des eigenen Teams in die Entscheidungsfindung und die Begründung dieser ist eigentlich die Norm. "Agilität" bietet da keine Vorteile.

    Und wenn im Unternehmen jeder theoretisch alles machen kann, weil er der "fähigste ist", endet das auch ganz schnell darin, dass keiner mehr was macht. Das typische "Ich bin nicht Zuständig" Prinzip das man aus Behörden kennt.
    Work-Life-Balance ist auch so ein Thema, was in mittleren bis hohen Positionen auch Gang und Gäbe ist. Solange die Arbeit gemacht ist und man ggf. auch kurzfristig auf Abruf Entscheidungen treffen kann, ist es egal ob du 4 oder 8 Stunden im Büro sitzt.
    Feste von bis Arbeitszeiten sind nur relevant und unvermeidbar in Positionen wo physische Arbeit involviert ist und man kurze Reaktionszeiten brauch. Beispiel nen Lagerarbeiter. Oder eine Supermarktverkäuferin. Wobei es auch hier ausnahmen gibt. Müllfahrer z.B. haben eine feste Route. Je schneller sie fertig sind, desto früher können die nach Hause. Deswegen ist der gemeine BSR Man in Berlin auch der gefährlichste Straßenteilnehmer.



    3 mal bearbeitet, zuletzt am 29.10.18 09:51 durch PerilOS.

  2. Re: Der Mensch brauch Struktur

    Autor: Zweistein2 29.10.18 - 10:07

    PerilOS schrieb:
    --------------------------------------------------------------------------------
    > Und all diese "Agilen" Methoden bieten keine vernünftige Struktur.
    > Aus meiner Erfahrung die ich bei SCRUM Teams beobachten konnte ist, dass es
    > in mehr Streß für die einzelnen ausartet, mehr Erwartungen entstehen und am
    > Ende trotzdem nicht mehr bei rum kommt. Ob Mittelstand oder Weltkonzern hat
    > da bis jetzt keinen Unterschied gemacht. All diese Methoden haben in der
    > Regel Personal gekostet und Entwicklungen verzögert.
    >
    > Ein Projekt bzw. eine Firma steht und fällt mit dem Management. Das ist
    > essenziell zum erreichen des Ziels. Ein gutes Management fällt
    > Entscheidungen auf Basis der Faktenlage und das Feedback von vor und hinter
    > gelagerten Personen. Das einbeziehen des eigenen Teams in die
    > Entscheidungsfindung und die Begründung dieser ist eigentlich die Norm.
    > "Agilität" bietet da keine Vorteile.

    Ja, beim Einbeziehen von Fakten und Feedback scheiterts oft im Management. Immerhin rollt dann ja der eigene Kopf oder man muss - Gott bewahre! - seine eigenen Fehler eingestehen.

    Ich mach nun seit 3 Jahren agile Entwicklung in großen, namhaften Firmen der Finanz- und Versicherungsbranche. Klar, man kann agil auch falsch machen, aber im Großen und Ganzen funktioniert das ganz gut.
    Wichtig ist, dass alle im Team mit der Agilität konform gehen und sich damit auch auseinandersetzen wollen. Die wenigen Projekte, die nicht agil funktioniert haben, sind meist aufgrund der "Das haben wir schon immer so gemacht!"- oder "Ich bin seit 20 Jahren im Unternehmen, ich lern jetzt nix Neues mehr"-Nörgler und Fortschrittsverweigerer gescheitert.

    Ansonsten muss ich sagen, dass das Konzept gut funktioniert (und mir persönlich auch sehr gefällt). Mal spontan 1-2 Tage Urlaub nehmen? Kein Problem, solange die Features fertig werden und die Code-Qualität nicht leidet. Eine Woche lang jeden Tag nach 5-6 Stunden gehen, um den Feierabend genießen zu können? Auch einfach machbar, macht man halt die Woche drauf ein paar Stunden mehr. Da man die Entwicklung ja schön auf Stories und Unteraufgaben runterbricht und diese schätzt (Was mit einem geübten und eingespielten Team wunderbar funktioniert), kann man auch selber recht gut abschätzen, ob man seine Aufgaben dann noch erledigt bekommt oder nicht - und entsprechend handeln. Agil eben.



    1 mal bearbeitet, zuletzt am 29.10.18 10:11 durch Zweistein2.

  3. Re: Der Mensch brauch Struktur

    Autor: Klausens 29.10.18 - 10:10

    Ich glaub ihr hattet da komische Agilität.

    > Das einbeziehen des eigenen Teams in die Entscheidungsfindung und die Begründung dieser ist eigentlich die Norm. "Agilität" bietet da keine Vorteile.

    In welche Entscheidungsfindung wird ein agiles Team einbezogen? Es gibt einen Product Owner und der sagt was als nächstes gemacht wird. Punkt.

    > Und wenn im Unternehmen jeder theoretisch alles machen kann, weil er der "fähigste ist", endet das auch ganz schnell darin, dass keiner mehr was macht.

    Die User Stories werden von oben nach unten abgearbeitet. Da macht keiner was er will. Und das wird kontrolliert vom Scrum master.

    Ich glaub eher bei dir war das so ein: Wir machen auch Agil - so irgendwie.

  4. Re: Der Mensch brauch Struktur

    Autor: Muhaha 29.10.18 - 10:15

    Zweistein2 schrieb:
    --------------------------------------------------------------------------------

    > Wichtig ist, dass alle im Team mit der Agilität konform gehen und sich
    > damit auch auseinandersetzen wollen.

    Ganz, ganz wichtig! Eine Bekannte von mir besetzt beruflich IT-Projekte mit Freelancern und bei der Personalauswahl achtet sie mittlerweile am meisten auf die persönliche und charakterliche Eignung der Kandidaten für Projekte, in denen Agile Methoden verwendet werden. Da kommt es mehr darauf an, ob die Teammitglieder zusammenpassen, anstatt auf die individuellen Einzelfähigkeiten.

  5. Re: Der Mensch brauch Struktur

    Autor: Zweistein2 29.10.18 - 10:17

    Klausens schrieb:
    --------------------------------------------------------------------------------
    > Ich glaub ihr hattet da komische Agilität.
    >
    > > Das einbeziehen des eigenen Teams in die Entscheidungsfindung und die
    > Begründung dieser ist eigentlich die Norm. "Agilität" bietet da keine
    > Vorteile.
    >
    > In welche Entscheidungsfindung wird ein agiles Team einbezogen? Es gibt
    > einen Product Owner und der sagt was als nächstes gemacht wird. Punkt.
    >

    Naja, wenn das Team sagt, dass die 80 angesetzten Story Points zu viel sind, sollte auch der PO das nicht einfach so durchdrücken. Und wenn doch, muss halt der PO den Kopf dafür hinhalten, dass das Team halt nur die commiteten 30 Points geschafft hat, statt seiner gewünschten 80.

    Klausens schrieb:
    --------------------------------------------------------------------------------
    > > Und wenn im Unternehmen jeder theoretisch alles machen kann, weil er der
    > "fähigste ist", endet das auch ganz schnell darin, dass keiner mehr was
    > macht.
    >
    > Die User Stories werden von oben nach unten abgearbeitet. Da macht keiner
    > was er will. Und das wird kontrolliert vom Scrum master.
    >

    Auch das würde ich nicht so stehen lassen. Klar geht die Prio von oben nach unten und wird auch möglichst danach bearbeitet. Aber 8 Entwickler an einer Story arbeiten zu lassen geht halt auch nicht immer, daher wird auch viel parallel gemacht. Das Ganze muss natürlich organisiert werden (von Team UND Scrum Master). Der SM sollte eigentlich nur schauen, ob das Team dann irgendwo festhängt und ggf. diese Blocker beseitigen oder mit dem PO reden und die Kapazitäten erhöhen.

  6. Re: Der Mensch brauch Struktur

    Autor: PerilOS 29.10.18 - 10:23

    Klausens schrieb:
    --------------------------------------------------------------------------------
    > Ich glaub eher bei dir war das so ein: Wir machen auch Agil - so irgendwie.

    Nah das war da ganz groß mit Beratern und Management commitment und all den Kram.
    Danach hast du die Entwickler nur noch wie Zombies durch die Gegend rennen sehen. Das muss nicht mal an der Fehlerhaften Umsetzung liegen. Sondern einfach weil eine Struktur wegfällt, die einem einen Rahmen gegeben hat. Das weckt Ängste und Leute werden im schlimmsten Fall weniger Teamplayer als mehr. Weil dann ne Competition entsteht. Diese Methodik ist nur für die wenigsten Leute zu empfehlen. Das kann man nicht einfach drüber stülpen. Wenn man aber neue Teams baut, dann kann das sicherlich funktionieren. Weil die Leute das Vorab schon wissen. Ich hab das jetzt in 3 Betrieben gesehen, und es hat mich absolut nicht überzeugt.

    Da finde ich es in meinem jetzigen aber besser. Jeder kommt und geht wann er will, aber jeder weiß was sein Aufgabenbereich ist und ist Verfügbar. Da kannst du auch im Hochsommer auf der Woche nebenbei deinen Sportbootführerschein machen oder mal 3 Tage zu Hause bleiben für die Kinder. Ist kein Ding.



    1 mal bearbeitet, zuletzt am 29.10.18 10:25 durch PerilOS.

  7. Re: Der Mensch brauch Struktur

    Autor: Trockenobst 29.10.18 - 10:25

    PerilOS schrieb:
    --------------------------------------------------------------------------------
    > Aus meiner Erfahrung die ich bei SCRUM Teams beobachten konnte ist, dass es
    > in mehr Streß für die einzelnen ausartet, mehr Erwartungen entstehen und am
    > Ende trotzdem nicht mehr bei rum kommt.

    Wir haben z.T Features wo der Kunde nicht weiß was seine Kunden wirklich wollen.
    Dann machen wir workshops, entwickelt neue Formulare und Felder (hacky) und dann schauen wir in Explorationen ob es das ist was der Kunde will.

    Und dann stellen wir meistens erstaunt fest, dass das was der Kunde-Kunde will eher größer und sinnvoller ist, als das was der Kunde dem Kunden-Kunden verkaufen möchte.

    Wir haben auch bestimmte Features im Gespräch mit dem Kunden ganz anders umgesetzt, weil wir den Formularflow und Sinnhaftigkeit der Rollen im Kopf haben. Es gab dann einmal mit dem Kunden-Kunden etwas knatsch. Wir haben dann eine Live Situation im Workshop nachgestellt (das ging über Skype) und als wir dann zum Kritischen Punkt kamen, sagen wir dem Kunden-Kunden
    "So, jetzt machen sie das was sie hier machen wollen"
    "Ich habe die Rolle nicht"
    "Dann lassen sie sich diese schnell vom Chef geben, der sitzt neben ihm"
    "Äh...das geht rechtlich nicht"
    "Genau deswegen haben wir den Formularfluss anders gemacht"
    "<coindrop>"

    Dem Kunden ist erst beim Live arbeiten mit dem Prototypen aufgefallen, dass seine Sicht der Dinge nicht funktioniert. Bei über 200 Funktionen in der Software nichts ungewöhnliches.

    Agile funktioniert bei uns deswegen gut, weil wir es konkret leben und nicht einfach nur Wasserfall anders verpacken. Wir haben auch schon lange Wutreden im Meeting gehabt, wo jemand ein großes Feature versprochen hat und wir haben gesagt dass die anteiligen Prozesse so schwierig sind, die müssen wir erst durcharbeiten da sind wir nich vollständig durch.

    Die anderen Teams haben es eingehackt und danach sind sie in einer Flut von Bugs versumpft, aber haben ein Versprechen auf dem Papier gehalten. Es gibt immer einen Ort wo du sterben willst, weil es nie genug Zeit, Geld oder Qualität gibt. Etwas scheitert immer. Das liegt aber auch an der hoffnungslosen Planlosigkeit der Kunden, die man kaum loswird.

    Daran ist dann nicht Agile schuld. Wir sprechen auch seit einigen Jahren von Estimations und nicht von Commitments. Commitments kann man nur geben wenn man alle Fakten kennt. Wer seine Entwickler mit unklaren Systemen harte Termine abringt, arbeitet unsauber. Und vor allem Spätkapitalistisch.

  8. Re: Der Mensch brauch Struktur

    Autor: Klausens 29.10.18 - 10:26

    Sie Storypoints errechnen sich grob aus Manntagen * Fokusfaktor.
    Es gibt ja Erfahrungswerte aus den letzten Sprints was geht und was nicht.

    > Klar geht die Prio von oben nach unten und wird auch möglichst danach bearbeitet. Aber 8 Entwickler an einer Story arbeiten zu lassen geht halt auch nicht immer

    Jeder der grad nichts zu tun hat nimmt sich den obersten Zettel, der auf "To do" steht und hängt ihn nach "In Progress".

    Da gibt's Ausnahmen, warum das grad überhaupt nicht sinnvoll ist, aber die müssen abgesegnet sein.

  9. Re: Der Mensch brauch Struktur

    Autor: Klausens 29.10.18 - 10:28

    > Nah das war da ganz groß mit Beratern und Management commitment und all den Kram.

    Ah, dann isses klar. In dem Fall ist Agil wirklich meist Mist. Eigentlich will das von den Entscheidern eh keiner, aber es ist grad Modewort und drum brauchen wir das auch.

  10. Re: Der Mensch brauch Struktur

    Autor: theonlyone 29.10.18 - 10:33

    Klausens schrieb:
    --------------------------------------------------------------------------------
    > Ich glaub ihr hattet da komische Agilität.
    >
    > > Das einbeziehen des eigenen Teams in die Entscheidungsfindung und die
    > Begründung dieser ist eigentlich die Norm. "Agilität" bietet da keine
    > Vorteile.
    >
    > In welche Entscheidungsfindung wird ein agiles Team einbezogen? Es gibt
    > einen Product Owner und der sagt was als nächstes gemacht wird. Punkt.

    Wenn der Product Owner so klare Ansagen macht was entwickelt werden muss und daran nichts aber auch gar nichts zu rütteln ist, dann hat man an sich keine Agilität, sondern nur einen Product Owner der Hierarchisch von oben diktiert was gearbeitet werden soll.

    Am besten noch einer, sobald Aufgaben erledigt sind zieht man einfach noch weitere in den Sprint mit rein. Macht irgendwo Sinn für vermeintlichen "Boss" um die Arbeit schneller zu erledigen, der ganze Sinn einer Selbstorganisation geht dadurch natürlich einfach mal komplett verloren.

    Sinn der Aktion muss sein das es Aufgaben gibt die hohe Priorität haben, aber nicht den ganzen Sprint ausfüllen und Aufgaben aus einem Pool mit niedriger Priorität die sich die Entwickler nach eigenem Gusto picken.
    Sobald der Product Owner alles ohne Optionen vorgibt hat man nichts gewonnen, man nennt seine Hierarchie nur anders.

    > > Und wenn im Unternehmen jeder theoretisch alles machen kann, weil er der
    > "fähigste ist", endet das auch ganz schnell darin, dass keiner mehr was
    > macht.

    Im Prinzip will man ja da hin, das jemand als Dev-Op prinzipiell alles machen kann, auch wenn er kein Profi in jedem Gebiet ist. Sinn der Aktion ist eben das man nicht aufgeschmießen ist wenn jemand mal krank wird, oder sogar die Firma verlässt und auch bei Einarbeitung neuer Mitarbeiter möglichst viel abgedeckt werden kann und dadurch erkennt man auch seine eigenen Stärken besser und versteht das Zusammenspiel auch besser, weil man es selbst mal gemacht hat.
    Am Ende hat natürlich immer noch jeder irgendwo seine Stärken und wenn jemand einfach ein absoluter Profi in einem Gebiet ist, wird die Arbeit auch zwangsläufig von genau dem gemacht ; das ist aber so ein Punkt den man versucht zu vermeiden, da man das Wissen doch viel lieber in die Breite mischt und weitergibt als sie auf einzelnen Personen zu bündeln.
    Umso Kommunikativer die Personen sind umso besser, dann fällt der Austausch leichter als jemand der sein Wissen nicht sinnvoll weitergeben kann (oder das auch gar nicht will).

    > Die User Stories werden von oben nach unten abgearbeitet. Da macht keiner
    > was er will. Und das wird kontrolliert vom Scrum master.
    >
    > Ich glaub eher bei dir war das so ein: Wir machen auch Agil - so irgendwie.

    Eben, das ist letztlich nicht Agil, man benutzt nur die Tools für Agile Entwicklung.

    Altes Sprichwort : "A fool with a tool, is still a fool."


    Wenn für ein Projekt sehr klar ist welche Aufgaben zu erledigen sind und damit praktisch alle Schritte bereits geplant sind, dann kann das nicht einfach so Agil gemacht werden, weil der Zeitplan ja sagt welches Feature zu welchem Zeitpunkt fertig sein muss.
    Und wenn dann ohnehin zu wenig Entwickler da sind hat man überhaupt keinen Spielraum und auch keine Zeit Wissen in die Breite zu bringen, da jeder Spezialist genau seine Aufgaben bekommt, weil vermeintlich nur das im Zeitplan überhaupt machbar ist.

    Da hat man natürlich überhaupt nichts gewonnen und macht auch keine reale Agile Entwicklung, den ein gerader Zeitplan in einer Linie ist genau das Gegenteil von Agil.

    Das Problem fällt entweder gar keinem auf, oder es wird auch gar nicht als Problem angesehen. Spätestens wenn ein "Spezialist" krank wird und es keinen Ersatz für das Wissen gibt gerät so ein Projekt komplett aus dem Ruder und einmal in Verzögerung gekommen wird der Zeitplan nur umso straffer, der Stress umso größer, die Agilität geht umso mehr verloren und die Leute werden umso eher Krank und verlieren eben auch komplett die Motivation, ein Schneeball der zur Lawine wird und das Projekt mit sich reißt.

    Agile Entwicklung bedeutet eben nur das man schneller kleinere Ergebnis-Intervalle bekommt und eine hohe Kommunikation zwischen den Entwicklern, den Projektleitern und dem Kunden.
    Da für die aller meisten immer noch einzig und allein der Zeitplan relevant ist, beißt sich das natürlich schon im Kern der Sache.
    Hat man in einem nicht agilen Projekt im Nachhinein das Problem das viele Änderungen dazu kommen die umso teurer und zeitaufwändiger sind, weil sie eben nicht vorher berücksichtigt werden konnten/durften , Kostet das eben auch mehr Geld.

    Für etwas wie Ausschreibungen ist Agil natürlich auch kein tolles Verkaufsargument, wenn schlichtweg der genommen wird der vermeintlich den kürzesten Zeitplan vorlegt (die praktisch unter Garantie nicht einzuhalten sind und das weiß eigentlich auch jeder, will es aber irgendwo nicht wahr haben).

  11. Re: Der Mensch brauch Struktur

    Autor: Klausens 29.10.18 - 10:37

    > Sinn der Aktion muss sein das es Aufgaben gibt die hohe Priorität haben, aber nicht den ganzen Sprint ausfüllen und Aufgaben aus einem Pool mit niedriger Priorität die sich die Entwickler nach eigenem Gusto picken.

    Steht das auch irgendwo oder ist das deine Interpretation?

    > Am besten noch einer, sobald Aufgaben erledigt sind zieht man einfach noch weitere in den Sprint mit rein

    Eine Änderung während des Sprints bedeutet: Sprint wird beendet, komplett neuer Sprint wird begonnen.


    Den Rest hab ich nicht mehr weitergelesen.

  12. Re: Der Mensch brauch Struktur

    Autor: Trockenobst 29.10.18 - 10:38

    PerilOS schrieb:
    --------------------------------------------------------------------------------
    > Danach hast du die Entwickler nur noch wie Zombies durch die Gegend rennen
    > sehen. Das muss nicht mal an der Fehlerhaften Umsetzung liegen. Sondern
    > einfach weil eine Struktur wegfällt, die einem einen Rahmen gegeben hat.

    Wer ganz simpel Unfähigkeit des Kunden nicht abholen und in entsprechende Kontrollierte Bahnen von Arbeitstasks, Featurewünsche etc. einplanen kann, hat Agile nicht verstanden und deswegen macht er es auch als Designer, Projektleiter etc. FALSCH.

    Agile ist nicht die Ausrede für schlechtes Management. wernn der Kunde keinen Plan hat und die Resourcen nicht vernünftig planen kann, dann muss man das selbst machen. "Ich habe für Mai und Juni 4 Leute, wenn bis zum Freitag keine Betellung erfolgt, dann schiebe ich zwei um".

    Gerade wenn man viele Leute im Projekt hat und viele Projekte/Module parallel macht, hat man Verhandlungsmasse. Wer das nicht hat und die Unsicherheiten auf seine Arbeitsnehmer abwälzt, hat grundsätzliche Projektplanung nicht verstanden.

    Bei den Arbeitsmarktoptionen in der IT muss man als Team dann auch mit der Projektleitung reden das so ein Käse nicht geht und ggf. sich nach einem anderen Job umsehen.

  13. Re: Der Mensch brauch Struktur

    Autor: Trockenobst 29.10.18 - 10:50

    theonlyone schrieb:

    > Wenn der Product Owner so klare Ansagen macht was entwickelt werden muss
    > und daran nichts aber auch gar nichts zu rütteln ist, dann hat man an sich
    > keine Agilität, sondern nur einen Product Owner der Hierarchisch von oben
    > diktiert was gearbeitet werden soll.

    Das klingt nach Wasserfall-Fließband, dass keinerlei Kreativität erlaubt und damit auch keine besseren Produkte. Ich kenne SAP Teams die so arbeiten, pump und dump, die Codebase ist fürchterlich und sie haben mehrere Qualitätstufen für Prio1 Bugs (wie absurd), aber die Sprints sind immer hypergefüllt und viele Entwickler kommen aus den "Urlauben" nicht zurück. D.h. großer Turnover und viel Zeit geht für Onboarding drauf.

    Das sind meiner Meinung nach fehlgemanagede Projekte und deswegen scheitern diese Buden früher oder später am Markt. Jedenfalls ist das meine Hoffnug, damit sowas keine Schule macht.

    Wir ziehen grundsätzlich nur Prio1 Bugs in den laufenden Sprint, der schon vorher estimated wurde. Der ProductOwner kann nicht einfach das Board vollmachen, weil wir 10% Refactoring Anteil im Vertrag haben. Das ist unsere Teamplanung und so ist das festgelegt.

    Der Scrum-Master/Projektleiter ist in einem solche Setup entweder vertraglich bewusst schwach gehalten, will keine Konflikte oder existiert gar nicht. Ich war in einem Bewerbungsgespräch zum Thema Agile, und der Projektleiter war ProductOwner und Scrum-Master in einer Person. Ich habe dann andere Fragen gestellt und habe das Projekt nicht angenommen.

    Der Vermittler hat mir dann gleich gesagt "Das war wegen der doppelten Rolle? Deswegen springen alle ab". Klar, ist auch keine agile Entwicklung, sondern Wasserfall-Fließband in verrotteten Schläuchen.

    Ich habe Industriefirmen kennengelernt, die konnten durch die konrekte Umsetzung von Agile besser Deadlines einhalten; haben ihre Prozesse und Fähigkeitengrenzen ihrer Teams besser ausloten können und bessere Leute eingestellt. Leute die sie vorher wegen dem Chaos in der Entwicklung nicht bekommen konnten.

    Ein neuer Entwicklungschef wollte dann agile wieder abschaffen ("Das ist mir zu Modern") und der Effekt war dann dass er gehen musste und nicht die Entwickler. Die Vorteile waren einfach zu gut.

  14. Re: Der Mensch brauch Struktur

    Autor: Der schwarze Ritter 29.10.18 - 10:57

    Aber mit simple Estimations statt Commitments triggert man bei einigen Kunden einfach keine Purchase Decisions.

    :D

    Sorry, den konnte ich mir nicht verkneifen. Bin selber Entwickler, aber amüsiere mich immer wieder, wenn es vollends in den üblichen Jargon abrutscht ;)

  15. Re: Der Mensch brauch Struktur

    Autor: Trockenobst 29.10.18 - 11:05

    Der schwarze Ritter schrieb:
    --------------------------------------------------------------------------------
    > Aber mit simple Estimations statt Commitments triggert man bei einigen
    > Kunden einfach keine Purchase Decisions.

    Commitments haben nach deutschem Recht juristischen Charakter. Der Kunde könnte durch ein Commitment behaupten, die sollten liefern und wenn der Hauptentwickler beim Snowboarden sein Bein runiert dann schaffst du es nicht für Ersatz zu sorgen. Und schon werden irgendwo in irgendwelchen Rahmenverträgen möglicherweise Schadenersätze fällig.

    Ist alles "da draußen" vorgekommen, dann wenn man es für gar nicht erwartet hat. Gleichzeitig muss ich auch sagen, dass der Entwickler am Ende der Kette einfach nicht der richtige Ort ist, damit eine Firma mit 1000,1000,100000 Entwicklern ihr "Risiko" managed.

    Das diese Leute früher oder später abspringen, ist verständlich. Das ist kein Fließbandjob mit der Kamera über dem Kopf.

  16. Re: Der Mensch brauch Struktur

    Autor: Anonymer Nutzer 29.10.18 - 11:22

    braucht man soviele worte um zu bemerken, dass die party im bestenfall schräg abdriftet wenn gastgeber und ausrichter mit abwesenheit und unvermögen glänzen?

  17. Re: Der Mensch brauch Struktur

    Autor: Trockenobst 29.10.18 - 11:37

    ML82 schrieb:
    --------------------------------------------------------------------------------
    > braucht man soviele worte um zu bemerken, dass die party im bestenfall
    > schräg abdriftet wenn gastgeber und ausrichter mit abwesenheit und
    > unvermögen glänzen?

    Nunja, setze dich mal in einen Gerichtsaal über zu 3cm zu breite Hecken zwischen zwei Nachbarn und stelle erstaunt fest, was da alles an juristischem und menschlichen Hickhack ist. Da ist die Hecken eben nicht nur 3cm "zu breit" , sondern dann wird es schwierig. Ist der Flächenplan korrekt fotokopiert, hat man damals das richtig auf 3 Stellen hinter dem Komma korrekt gezeichnet etc.

    So ist es in der Projektplanung eben auch. Es ist nicht immer der eine Schuld, noch sind die Leute so blöd sich selbst als Störer und/oder Schuldigen zu präsentieren. Das wird dann sehr gut auf viele Leute verteilt und dann ist es nicht mehr so einfach.

  18. Re: Der Mensch brauch Struktur

    Autor: debattierer 29.10.18 - 11:49

    So und das ganze hört sich so an wie bis jetzt. chef sagt "A" und verteilt die Aufgaben. Kontrolliert immer wieder ob das läuft und fertig.
    Ob man das jetzt SCRUM nennt oder einfach nur Projektführung mit Hirn ist komplett egal. Gute Vorgesetzte haben schon vor 50 Jahren so geführt.

  19. Re: Der Mensch brauch Struktur

    Autor: mark.wolf 29.10.18 - 13:09

    Was es auf keinen Fall braucht, ist das von Dir beschriebene Management. Das Team ist in der Lage selbst die verantwortung zu übernehmen. Nur so wird ein Schuh draus. Agil und kalssisches Amnagement sind Gegensätze. Ich kann aus eigener Erfahrung sagen, dass ein Scheitern eines Projektes zu 99% zu Lasten des sog. Managementes ging.

  20. Re: Der Mensch brauch Struktur

    Autor: Zweistein2 29.10.18 - 13:11

    debattierer schrieb:
    --------------------------------------------------------------------------------
    > So und das ganze hört sich so an wie bis jetzt. chef sagt "A" und verteilt
    > die Aufgaben. Kontrolliert immer wieder ob das läuft und fertig.
    > Ob man das jetzt SCRUM nennt oder einfach nur Projektführung mit Hirn ist
    > komplett egal. Gute Vorgesetzte haben schon vor 50 Jahren so geführt.

    Gerade das ist ja eben nicht agil, bzw. Scrum. Agil wäre, wenn Chef sagt: "Ich will die Features X, Y und Z in zwei Wochen fertig haben" und das Team antwortet: "Wir schaffen nur Feature X und Y oder X und Z, alle drei sind zu viel" und der Chef dann halt eben nurnoch auf X und Z besteht. Gleichzeitig kann das Team dann kleinere Aufgaben, die nicht so hohe Prio wie X/Y/Z haben nachziehen, wenn noch irgendwo ein halber Tag Luft entsteht, ohne ein Feature anzufangen und es nicht zu beenden oder Däumchen zu drehen.

    Wie ich weiter oben schon schrieb, im Agilen gibt es keine Anweisung von oben. Im Idealfall hocken sich Team, PO und Kunde zusammenhin und arbeiten aus, was in dem Sprint gemacht wird. Gemeinsam. Da darf man dann auch sagen "Das schaffen wir nicht in der Zeit" oder "Das ist ne doofe Idee, wäre die Lösung auch gut?". Danach wird geguckt, ob das so passt und falls der Kunde merkt "Ah, der Button war vlt. doch ne blöde Idee", dann wird das halt im nächsten Sprint wieder ausgebaut. So verhindert man, dass die Software, die Manager A beim Kunden vor drei Jahren beauftragt hat, hinterher dem Manager B (weil A gegangen ist) beim Kunden nicht gefällt. Und vor allem kann der Kunde flexibel sagen, was er möchte. Gibt es inzwischen Änderungen am Markt, einen neuen Großauftrag, whatever, so kann der Kunde die Tasks dazu mal eben in die nächsten Sprints mit einplanen lassen, statt nach 3 Jahren zu sagen: "Das war Mist damals" oder während der Entwicklung lustig die Anforderungen zu ändern.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Schaeffler Technologies AG & Co. KG, Herzogenaurach
  2. SEW-EURODRIVE GmbH & Co KG, Bruchsal
  3. operational services GmbH & Co. KG, Nürnberg, Dresden, Berlin, Frankfurt am Main, München, Braunschweig, Wolfsburg, Zwickau
  4. Hays AG, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-60%) 23,99€
  2. 32,99€
  3. (-53%) 6,99€
  4. 3,40€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Alexa: Das allgegenwärtige Ohr Amazons
Alexa
Das allgegenwärtige Ohr Amazons

Die kürzlich angekündigten Echo-Produkte bringen Amazons Sprachassistentin Alexa auf die Straße und damit Datenschutzprobleme in die U-Bahn oder in bisher Alexa-freie Wohnzimmer. Mehrere Landesdatenschutzbeauftragte haben Golem.de erklärt, ob und wie die Geräte eingesetzt werden dürfen.
Von Moritz Tremmel

  1. Digitaler Assistent Amazon bringt neue Funktionen für Alexa
  2. Echo Frames und Echo Loop Amazon zeigt eine Brille und einen Ring mit Alexa
  3. Alexa Answers Nutzer smarter Lautsprecher sollen Alexa Wissen beibringen

Akku-FAQ: Vergesst den Memory-Effekt - vorerst!
Akku-FAQ
Vergesst den Memory-Effekt - vorerst!

Soll man Akkus ganz entladen oder nie unter 20 Prozent fallen lassen - oder garantiert ein ganz anderes Verhalten eine möglichst lange Lebensdauer? Und was ist mit dem Memory-Effekt? Wir geben Antworten.
Von Frank Wunderlich-Pfeiffer

  1. Müll Pfand auf Fahrrad-Akkus gefordert
  2. Akku-FAQ Wo bleiben billige E-Autos?
  3. Echion Technologies Neuer Akku soll sich in sechs Minuten laden lassen

Medienkompetenz: Was, Ihr Kind kann nicht programmieren?
Medienkompetenz
Was, Ihr Kind kann nicht programmieren?

Lesen, schreiben, rechnen und coden: Müssen Kinder programmieren lernen? Vielleicht nicht. Aber sie sollen verstehen, wie Computer funktionieren. Wie das am besten geht.
Von Jakob von Lindern

  1. 5G Milliardenlücke beim Digitalpakt Schule droht
  2. Digitalpakt Schuldigitalisierung kann starten
  3. Whatsapp bei Lehrern Kultusministerkonferenz pocht auf Datenschutz

  1. China: Internetanschluss oder Telefonnummer nur gegen Gesichtsscan
    China
    Internetanschluss oder Telefonnummer nur gegen Gesichtsscan

    In China soll es ab Dezember Telefonnummern oder Internet-Anschlüsse nur noch mit Identitätsfeststellung per Gesichtserkennung geben. Eine entsprechende Regelung wurde kürzlich erlassen und soll auch für bereits registrierte Anschlüsse gelten.

  2. Nach Attentat in Halle: Seehofer möchte "Gamerszene" stärker kontrollieren
    Nach Attentat in Halle
    Seehofer möchte "Gamerszene" stärker kontrollieren

    Nach dem rechtsextremistisch motivierten Attentat in Halle gibt Bundesinnenminister Horst Seehofer in einem Interview der "Gamerszene" eine Mitschuld und kündigte mehr Überwachung an. Kritiker werfen ihm eine Verharmlosung des Rechtsextremismus und Inkompetenz vor.

  3. Siri: Apple will Sprachbefehle wieder auswerten
    Siri
    Apple will Sprachbefehle wieder auswerten

    Nach einem weltweiten Stopp möchte Apple die Sprachbefehle der Siri-Nutzer wieder auswerten - diesmal jedoch mit expliziter Zustimmung durch den Nutzer. Das gilt allerdings nur für Audioaufnahmen, die in Text umgewandelten Mitschnitte möchte Apple weiter ungefragt auswerten.


  1. 15:37

  2. 15:15

  3. 12:56

  4. 15:15

  5. 13:51

  6. 12:41

  7. 22:35

  8. 16:49