![\"Join](\"https:\/\/i0.wp.com\/berlin3.davidweb.pro\/wp-content\/uploads\/2021\/12\/0-HoA-Join-Hands-on-Agile-Meetup-Community.jpg?resize=1290%2C251&ssl=1\")
<\/a><\/p>\r\n\r\nDie Aufmerksamkeits\u00f6konomie von Hacker News und DZone<\/h2>\r\n\r\n
Haben Sie als Autor schon einmal davon getr\u00e4umt, bei Hacker News oder DZone gro\u00df rauszukommen?<\/p>\r\n\r\n
Das ist einfach; lassen Sie mich Ihnen helfen: Schreiben Sie etwas dar\u00fcber, wie schrecklich \"Agile\" und das Wesen von Scrum sind. Diese starren Methodologien verwandeln Softwareentwickler unweigerlich in hirnlose R\u00e4dchen in einer Unternehmensmaschine, die immer mehr Code produziert, und ignorieren dabei das wahre Potenzial dieser Wissensarbeiter. Finden Sie dann eine eing\u00e4ngige \u00dcberschrift wie \"Warum ich [Agile, Scrum, ...] [hasse, verachte\u2026],\" und die Zuspruch der Entwicklergemeinde ist Ihnen sicher.<\/p>\r\n\r\n
In einem k\u00fcrzlich erschienenen Artikel \u00fcber das Wesen von Scrum<\/a> beschreibt der Autor seine Erfahrungen mit \"Scrum\" im Detail. Werfen wir einen Blick auf einige der Aussagen des Autors: <\/p>\r\n\r\n\r\n\t- Definition of Done<\/strong>: \u201cI entirely agree that every task should have a definition of done. But the definition should be task related [\u2026] Figuring out \u2018Done\u2019 is also difficult because the client may not have a good idea of what done looks like.\u201d Die \"Definition of Done\" in Scrum dient nicht nur der Qualit\u00e4tskontrolle. Die Definition of Done ist der Qualit\u00e4tsstandard, der f\u00fcr alle Produktinkremente gilt. Sie wird von allen, die Inkremente inspizieren, gut verstanden und bildet so die Grundlage, dass Scrums empirischer Prozess funktioniert. Sie umfasst alles, was notwendig ist, um die Produktinkremente an unsere Kunden auszuliefern, einschlie\u00dflich, aber nicht beschr\u00e4nkt auf die Einhaltung technischer Standards, Governance-Regeln und rechtlicher Anforderungen. In Anbetracht dieser Eigenschaften erwartet niemand, dass die Kunden ein vollst\u00e4ndiges Verst\u00e4ndnis davon haben, was \"Done\" bedeutet. Aus diesem Grund bezahlen wir auch das Entwicklungsteam daf\u00fcr, dass es die Verantwortung \u00fcbernimmt, ein \"Done\" Produktinkrement zu entwickeln. <\/li>\r\n\r\n\t
- Time-Boxing und Releases<\/strong>: \u201cWhen things are done, they are done. And you should be able to ship with the done feature at any time. Waiting for the end of a sprint and a sprint review means waiting to ship a done project.\u201d Die Aussage ist schlichtweg falsch. Die Entscheidung, ob ein Produktinkrement ausgeliefert wird, obliegt dem Product Owner. Ein Inkrement kann am Ende des Sprints geliefert werden, oder seine Lieferung erfolgt zu einem sp\u00e4teren Zeitpunkt. Oder das Entwicklungsteam liefert w\u00e4hrend des Sprints kontinuierlich Inkremente aus. Zu keinem Zeitpunkt h\u00e4ngt die Lieferung eines Produktinkrements vom Sprint Review ab, da es sich bei diesem Ereignis nicht um eine Stage-Gate\u00ae-\u00e4hnliche Genehmigungsinstanz handelt.<\/li>\r\n\r\n\t
- Scrum Master<\/strong>: \u201cWhat the Scrum Master really is is the project manager stripped of the ability to manage the project. [\u2026] But there are times when something needs to be done and a project manager can make the changes and get it done.\u201d Scrum st\u00fctzt sich auf selbstorganisierende und funktions\u00fcbergreifende Teams, die dar\u00fcber entscheiden, wie wertvolle Produktinkremente erstellt werden k\u00f6nnen. Die Aufgabe des Scrum-Masters ist es daher, das Scrum-Team bei der Beseitigung von Hindernissen \u2014 Probleme, die die Teammitglieder nicht selbst l\u00f6sen k\u00f6nnen \u2014 zu unterst\u00fctzen und damit diesen dezentralen F\u00fchrungsansatz zu f\u00f6rdern. Dar\u00fcber hinaus sind diese Hindernisse meist innerhalb der Organisation angesiedelt. Hier geschieht Ver\u00e4nderung nicht einfach dadurch, dass man \"die Dinge zum Laufen bringt\", sondern durch die Zusammenarbeit mit anderen Beteiligten und ihren Pl\u00e4nen, Agenden, Zielen usw. Diese Notwendigkeit ist auch der Grund daf\u00fcr, dass ein Scrum Master eine Vollzeitbesch\u00e4ftigung ist. Scrum-Master werden nicht daf\u00fcr bezahlt, ein paar Scrum-Events zu moderieren, Stickies zu bestellen und Besprechungsr\u00e4ume zu buchen. Ihre prim\u00e4re Rolle ist die eines Change Agents innerhalb der Organisation.<\/li>\r\n\r\n\t
- Scrum-Events<\/strong>: \u201cWhile I like the basic concepts, I don\u2019t like the huge time sync associated with these events. I don\u2019t like meetings and I like non-productive meeting even less.\u201d Wenn Sie nicht wissen, wohin Sie gehen wollen, wird Sie jeder Weg dorthin f\u00fchren. Da wir an neuen Produkten in komplexen Umgebungen arbeiten, ist es sinnvoll, regelm\u00e4\u00dfig etwas Zeit einzuplanen, um herauszufinden, ob wir in die richtige Richtung laufen. Alle Scrum-Events haben zudem Zeit-Boxen, um das Risiko zu verringern, dass wir die Zeit aller Beteiligten vergeuden, ohne einen Mehrwert f\u00fcr unsere Kunden zu schaffen. Niemand erwartet, dass Ihre Scrum-Ereignisse vom ersten Sprint an effektiv verlaufen. Es wird einige Zeit dauern, sie richtig zu gestalten. Gl\u00fccklicherweise haben wir auch eine formelle Veranstaltung, um das Streben des Scrum Teams nach kontinuierlicher Verbesserung zu unterst\u00fctzen, die Retrospektive. Dies bedeutet ebenfalls, dass wir nicht darauf warten m\u00fcssen, dass die Sprint-Retrospektive beginnt, um die Dinge zum Besseren zu ver\u00e4ndern. Mein Tipp: einfach machen.<\/li>\r\n\r\n\t
- Das Scrum Team<\/strong>: \u201cI believe in individual effort and that individuals should get credit for their efforts. [\u2026] I also reject the concept that every team member should have an equal vote on everything.\u201d Spoileralarm: Scrum ist nicht f\u00fcr jedermann; Helden und Rockstars \u2014 ob selbst ernannt oder nicht \u2014 werden wahrscheinlich entt\u00e4uscht sein. Das Wesen von Scrum betont die Bedeutung \"echter\" Teams, da das Team die Verantwortung f\u00fcr die Schaffung eines wertvollen Produktinkrements mit der Regelm\u00e4\u00dfigkeit eines Schweizer Uhrwerks \u00fcbernehmen muss. Eine Vielfalt von Erfahrungen, Hintergr\u00fcnden und Meinungen wird die erforderliche Selbstorganisation unterst\u00fctzen und in dieser Hinsicht \u00fcberlegene Ergebnisse liefern. Denken Sie schlie\u00dflich an das Sprichwort: Wenn Sie Feuerwehrleute belohnen, schaffen Sie eine Kultur der Brandstifter. Raten Sie mal, woher das toxische Miteinander in manchen Entwicklungsabteilungen kommt?<\/li>\r\n\r\n\t
- Scrum ist kein Team-Player<\/strong>: \u201cIn the Scaled Agile Framework (SAFe), you get to the time boxed scrum teams by having an \u2018Architectural Runway\u2019 filled with \u2018enablers.\u2019 Scrum ist Scrum; SAFe\u00ae ist SAFe\u00ae. Bitte verwechseln Sie die beiden nicht, denn Scrum hat nichts mit SAFe\u00ae zu tun. F\u00fcr eine erfolgreiche Zusammenarbeit mehrerer Scrum-Teams bieten sowohl NEXUS als auch LeSS die entsprechenden Framework-Erweiterungen zum Scrum-Guide an. Nat\u00fcrlich ist es m\u00f6glich, neue Produkte zu entwickeln, an denen mehr als ein Scrum-Team arbeitet, es sei denn, Sie entfernen kritische Komponenten der Zusammenarbeit und Selbstorganisation. Wie Ron Jeffries es so wortgewandt formuliert: \u201cWe Tried Baseball and It Didn\u2019t Work.<\/a>\u201d <\/li>\r\n\r\n\t
- User Stories<\/strong>: \u201cI\u2019m not even going there. Here is a smattering of why user stories aren\u2019t the be-all and end-all.\u201d Wenn nichts mehr hilft, einfach mal das Handbuch lesen. Bitte weisen Sie mich darauf hin, wo im Scrum-Guide User Stories erw\u00e4hnt werden. Wenn Sie diese gerne anwenden m\u00f6chten, und es funktioniert, gut f\u00fcr Sie. Es gibt jedoch auch andere M\u00f6glichkeiten, mit Product Backlog Items zu organisieren, zum Beispiel Job Stories<\/a>. Setzen Sie alles ein, was zu einem umsetzbaren, wertvollen Product Backlog f\u00fchrt, um Werte f\u00fcr die Kunden zu schaffen.<\/li> \r\n\r\n\t
- Working Software<\/strong>: \u201cScrum is based around dropping working software every two weeks. [\u2026] But the real problem I have with the working software model is that it gives short-shrift to planning and documentation. [\u2026] o you have two weeks to do planning then you can forget about that drudgery. And after that two weeks, don\u2019t plan or document, just code, code, code.\u201d Der Autor argumentiert, dass die Konzentration von Scrum auf funktionierende Software zu schlechten Design-Entscheidungen, minderwertiger Code-Qualit\u00e4t und mangelnder Dokumentation f\u00fchrt. Meiner Erfahrung nach geschieht dies nur in Umgebungen mit schlechten technischen Standards und w\u00fcrde wahrscheinlich so oder so passieren, unabh\u00e4ngig vom verwendeten Entwicklungsframework oder dem Wesen von Scrum. Der Erfolg von Scrum h\u00e4ngt von einer starken Softwareentwicklungskultur und von Teams ab, die nach handwerklichem K\u00f6nnen streben, was der Grund daf\u00fcr ist, dass z. B. Scrum und Extreme Programming so gut zusammenarbeiten. Wenn TDD, Refactoring und emergent Architecture auf einen kontinuierlichen Verfeinerungsprozess des Product Backlog treffen, wird keines der zuvor erw\u00e4hnten Probleme auftreten.<\/li>\r\n<\/ul>\r\n\r\n
![\"Das](\"https:\/\/i0.wp.com\/berlin3.davidweb.pro\/wp-content\/uploads\/2020\/07\/Scrums-Nature-Tool-Not-Love-Hate.jpg?resize=1290%2C645&ssl=1\")
<\/p>\r\n\r\n\r\n\r\n\r\n