Wie kann man einer Sekte entkommen?

Unsere Welt ist sehr seltsam. Und je weiter Sie gehen, desto seltsamer wird es. Und du wirst verstehen, was zum Teufel.

Es gibt Ingenieure und Programmierer auf der Welt. Manchmal rollten alle in einem. Menschen, die verstehen, was ein Algorithmus ist. Darüber hinaus Menschen, die diese Algorithmen erstellen. Sie sind sich bewusst, dass der erstellte Algorithmus zur Lösung eines Problems geeignet ist, für ein anderes jedoch nicht. Wenn der Algorithmus geringfügig geändert wird, kann er damit verbundene Probleme lösen. Zögern Sie nicht, die Hälfte des Algorithmus eines anderen wegzuwerfen, damit das aktuelle Problem besser gelöst wird.
Programmierer erstellen eine Lösung für eine Aufgabe oder für eine Klasse von Aufgaben. Dies ist die Essenz des Berufs. Verwenden Sie nach Möglichkeit vorgefertigte Teile des eigenen Codes oder des Codes einer anderen Person. Und alles ist gut.

Sobald es jedoch darum geht, Algorithmen außerhalb des Computers zu erstellen, verlieren Programmierer plötzlich den Kopf. Ich spreche nicht davon, Algorithmusdiagramme auf Papier zu zeichnen, wie es bei der Universitätsprüfung der Fall war - hier kann jeder von uns damit umgehen.

Ich spreche von "Implementierung von Techniken", "Arbeit am Framework", "obligatorische Verwendung aller Artefakte". Kurz über Sekten.

Ein bisschen Idiotie

Jeder weiß, was ein bedingter Operator ist. Es gibt kein Leben ohne ihn. Kein anständiger Algorithmus wird funktionieren. Weder im Computer noch im Leben.

Stellen Sie sich nun vor: Eine bestimmte Person, zum Beispiel John, erschien und bemerkte, dass es in BASIC eine bedingte Aussage gibt. Ich nahm es auf, fand es heraus und stellte sicher, dass es funktioniert, ohne es in irgendeiner Weise.

Nehmen wir an, John ist dumm. Aber er beschloss, die Welt zu erobern. Ging BASIC verkaufen. Nicht die Sprache selbst, sondern eine Art „coolste Softwareentwicklungstechnik“, deren zentraler Zusammenhang ... Und John wird es erst sagen, wenn Sie den Kurs abgeschlossen haben.

Okay, es gab Kursliebhaber, zumal der Preis nicht hoch ist. Sie kamen, hörten zu und schnappten nach Luft. Das Hauptelement der coolsten Softwareentwicklungsmethode ist der bedingte Operator. Wir haben viel über die bedingte Aussage gehört. Zum Beispiel, wie man es in einen Multiple-Choice-Operator verwandelt. Sie schnappten erneut nach Luft - was für ein mächtiger bedingter Operator.

Die Hälfte des Publikums waren Programmierer. Wiehernd ging er nach Hause. Ein weiteres Quartal waren Manager. Sie wurden nachdenklich, stellten Fragen, jemand beschloss, diese coole Technik in ihrem Haus zu implementieren. Das letzte Quartal war das gleiche wie John. Sie überredeten den Mann, ein Franchise, eine Community, eine Zertifizierungsstelle und eine kontingente Universität zu gründen.

Programmierer aus dem Kurs kehrten zur Arbeit zurück und erinnerten sich nicht mehr an den bedingten Operator. Aber eine Stunde später kamen Manager und kündigten an, dass die Softwareentwicklung nun nach der coolsten Methode durchgeführt wird. Ja, hier geht es um den bedingten Operator. Im Allgemeinen ist es besser, in Basic zu schreiben.

Die schüchternen, wenn nicht schüchternen Einwände der Programmierer wurden ignoriert. Sätze wie „Verdammt, es ist ein bedingter Operator, es ist überall“ wurden als Versuche wahrgenommen, anzugeben. Das Rad drehte sich.

Und John wurde schnell klar, dass nur ein bedingter Operator nicht ausreicht. Es sollte auch eine Schleife, ein Unterprogramm, eine Variable, ein Array usw. geben. Wir sollten es irgendwie alles nennen ... Mit einem Wort ... Oh, lass es Artefakte sein! Nicht mehr und nicht weniger!

Die Hauptsache blieb: der Methodik eine Klausel hinzuzufügen, dass die coolste Softwareentwicklungsmethodik ganzheitliches, ganzheitliches Wissen ist. Es kann also kein einziges Stück herausgeworfen werden. Und Sie können nichts hinzufügen - es funktioniert nicht mehr. So wie es geschrieben steht, tu es auch.

Dank der Begeisterung von John und seinen Freunden verwendet die ganze Welt laut Liste keinen bedingten Operator, sondern einen bedingten Operator, keinen Zyklus, sondern einen Zyklus usw. Diejenigen, die die Idiotie der Situation verstanden haben, sind längst in Rente gegangen oder haben die Klappe gehalten. Diejenigen, die kürzlich gekommen sind, glauben fest daran, dass der bedingte Operator Teil der coolsten Softwareentwicklungstechnik ist, die von John entwickelt wurde. Und alle anderen bedingten Operatoren sind ein miserabler Anschein, eine verblasste Kopie und ein Stück Wissen, das aus dem Zusammenhang gerissen wurde.

Jeder, der es wagt, im Internet abzustimmen (oder, Gott bewahre, im Team), wird heftiger Verurteilung und wütender Minuskulatur ausgesetzt - Sie, Stiefel, sehen die Vorteile des bedingten Betreibers nicht! Und wenn die unglückliche Person nach der Bedeutung und dem Unterschied zum bedingten Operator in C ++, Javascript oder sogar 1C fragt, erhält sie die Antwort "Es ist unmöglich zu erklären", "Sie verstehen nicht" oder "Lesen Sie die Anleitung".

Werkzeuge und Algorithmen

Jeder versteht, was ein bedingter Operator ist und wie er in Algorithmen verwendet wird. Auf die gleiche Weise versteht jeder, was zum Beispiel ein Aufkleber mit einer aufgezeichneten Aufgabe ist. Aufkleber erschienen vor dem Gedränge und leben außerhalb davon. Schauen Sie sich den Computer eines Buchhalters, Lieferanten oder Verkäufers an. Sie haben die Gewohnheit, ein paar Aufkleber mit dringenden Aufgaben auf den Monitor zu hängen, noch nicht beseitigt. Auf einen der Aufkleber wird ein Passwort geschrieben.

Jede Technik ist leicht mit Werkzeugen, Prinzipien und Beziehungen vertraut. Genau wie jeder Algorithmus in Figuren verschiedener Formen und Zwecke zerlegt wird - Anfang und Ende des Algorithmus, Aktion, Bedingung, Unterprogramm.

Jede Technik hat einen Anwendungsbereich. Nicht alles ist absolut da - es gibt eine geeignetere Umgebung, es gibt weniger. Gleich wie Algorithmen.

Jede Technik kann modifiziert werden. Teile wegwerfen, neue hinzufügen, bestimmte Werkzeuge modifizieren. Genau wie Algorithmen.

Alle Techniken können ganz oder in Stücken gemischt werden. Nehmen Sie die Hälfte von einem, ein Viertel vom anderen, ein weiteres Viertel - erfinden Sie sich. Wenn Sie eine Anwendung oder einen Dienst erstellen, ist dies für Sie offensichtlich.

Es bleibt die Frage: Wird die Methodik eine Methodik sein, wenn sie geändert wird?

So beantworten Sie diese Frage, zum Beispiel den bekannten Scrum Guide:

„Die Rollen, Artefakte, Regeln und Ereignisse von Scrum können sich nicht ändern. Obwohl die Verwendung einzelner Elemente dieses Frameworks akzeptabel ist, kann das Ergebnis nicht als Scrum bezeichnet werden. Scrum existiert nur als Ganzes, kann aber auch andere Techniken, Methoden und Praktiken berücksichtigen. “

Ein bisschen wie John und sein Bedingter Operator, nicht wahr? Es scheint, als ob Sie sich ändern, wenn Sie wollen, nur wird es kein Gedränge sein. Und was das Ergebnis sein wird - die Hölle weiß es. Nur für den Fall, sie haben bemerkt, dass Sie versuchen können, etwas hinein zu schieben. Aber das Rückgrat muss bleiben. Ansonsten ... Es ist sogar beängstigend, sich das vorzustellen.

Ist es wirklich beängstigend? Was passiert, wenn einige der Artefakte weggeworfen oder ersetzt werden? Und überhaupt, worum geht es? Woher kamen sie? Warum wird angenommen, dass sie nur in einer solchen Kombination arbeiten, wie die Autoren entschieden haben?

Versuchen wir, die Teile herauszufinden.

Sprint und Sprint Backlog

Tolles Werkzeug übrigens. Wahrscheinlich vor tausend Jahren erfunden. Es wurde immer anders genannt, aber das häufigste ist wahrscheinlich der "Plan". Und menschlich - "eine bestimmte Menge an Arbeit für einen bestimmten Zeitraum zu erledigen."

Für mich als 1Sniku ist es besser bekannt als Raumkalenderplanung (OKP). Es ist weit verbreitet in der Produktions- und Verkaufsplanung. Zum Beispiel ist der Verkaufsplan eines Managers von 1 Million Rubel pro Monat ein Rückstand und ein Sprint. Manchmal reicht eine Zahl aus, manchmal gibt es eine Aufschlüsselung nach Produktgruppen oder Markteinschränkungen oder es gibt sogar eine bestimmte Liste von Artikeln, falls dies von der Unternehmensstrategie gefordert wird.

Die Produktion ist noch einfacher. Buchsen - 1000 Stk., Wellen - 2000 Stk., Rotoren - 500 Stk. Dies ist beispielsweise ein Wochenplan. Er ist der Rückstand des wöchentlichen Sprints der Produktionsstätte. Zwar kann den Arbeitern nicht erklärt werden, dass dies kein Plan, sondern ein Sprint ist.

Das Tool ist im Vergleich zum weit verbreiteten Zeitmanagement gut, wenn der Aufgabenpool des Programmierers anhand der Arbeitskosten geschätzt wird, sortiert nach einem Kriterium, und jede Aufgabe eine Frist hat. In der Produktion wird dies als Schichtplanung oder Werkstattplanung bezeichnet, aus der dann Produktionsaufgaben erstellt werden, die eine Liste von Teilen und Halbzeugen, technischen Vorgängen, Materialien, Inputs und Outputs enthalten (wo was zu bekommen ist und wohin das Ergebnis zu übertragen ist).

Für Programmierer funktioniert die Workshop-Planung nicht gut, und hier gibt es nichts zu besprechen. Die Bearbeitungszeit eines Teils an einem bestimmten Modell der Maschine ist seit langem bekannt und ziemlich genau. Servicefrequenz - auch. Ausreichende Materialbewertung. Nehmen und tun. Abweichungen, die die Umsetzung des Plans in der Massenproduktion beeinträchtigen, haben in der Regel keine wesentlichen Auswirkungen. Und wenn doch, gibt es hervorragende Methoden, um sie zu analysieren und zu eliminieren.

Programmierervarianten sind viel stärker. Er ist keine Werkzeugmaschine, wie es einige Manager, die aus dem Vertrieb oder der Produktion zur IT gekommen sind, nicht möchten. Daher ist die Workshop-Planung (Aufgabe + Frist) für einen Programmierer nicht geeignet. So kamen vernünftige Leute auf die Idee - Sie müssen auf ein höheres Niveau aufsteigen, um die Aufführung nicht in Minuten zu planen, sondern für einen bestimmten Zeitraum Volumen zu geben. Nur sie hatten einen anderen Namen - Sprint und Rückstand.

Das Ausfüllen des Produktionsplans für den volumetrischen Kalender basiert auf Prinzipien, die der Bildung eines Sprint-Rückstands ähneln. Sogar es gibt so etwas - "wähle einen Plan". Es gibt Anforderungen derselben Vertriebsabteilung (= großer Auftragsbestand), Produktionsdurchsatz (= Teamfähigkeiten in Zahlen) sowie klare Auswahlkriterien - Umsatzmenge, Rentabilität jeder Position, Kundenparameter (z. B. Zahlungsbedingungen). Erzielte einen Produktionsplan - und sah sofort, was für ein ungefähres finanzielles Ergebnis Sie erhalten. Dies ist keine kurzlebige "Veröffentlichung".

Gibt es irgendwelche Nachteile bei diesem Tool? Natürlich wie jeder andere auch.

Wenn Sie verstehen, ist der Sprint-Rückstand dieselbe Workshop-Planung, nur ohne eine gut organisierte Abfolge von Problemlösungen. Daher haben alle Aufgaben eine Frist - das Ende des Sprints. Sobald die Aufgaben eine Frist haben, tritt ein unangenehmer Effekt auf - zu Beginn des Sprints kann die Aktivität erheblich geringer sein als am Ende.

So funktioniert jede menschliche Psychologie. Sie möchten immer zu Beginn des Ausführungszeitraums herumhängen, egal ob es sich um eine Aufgabe oder einen Rückstand handelt. Machen Sie vor allem eine Pause von der vergangenen Periode - vom letzten Teil, als es notwendig war, ein "großes" Ergebnis zu erzielen. Natürlich gibt es Leute, die stabil und rhythmisch sind und die ganze Woche mit der gleichen Geschwindigkeit arbeiten, aber die meisten beginnen irgendwo am Mittwoch "normal zu arbeiten".

Kann man auf Sprint und seinen Rückstand verzichten? Einfach.

Wenden Sie das Tool beispielsweise "so schnell wie möglich" an. Im Allgemeinen ist dies keine Praporsky-Manier, sondern eine ganz normale Strategie für dieselbe Workshop-Planung (so bald wie möglich, so schnell wie möglich). Dies bedeutet, dass die Probleme am Anfang des Zeitintervalls bleiben, d. H. Bis Montag, nicht Freitag, wie bei der Strategie „So zuletzt wie möglich, ALAP“.

Eine Planung als solche ist in diesem Fall nicht erforderlich. Es gibt einen Produktstau, es gibt Prioritäten, es gibt eine Regel "so schnell wie möglich". Du nimmst den ersten und machst es. Fertig - du nimmst den zweiten. Und so - vom Zaun bis zum Abendessen. Sprint oder vielmehr seine Essenz, d.h. Die Zeitspanne, die Sie zum Verstehen und Analysieren der Produktivität verwenden können (Woche zu Woche, Monat zu Monat usw.).

Gibt es Mängel in der Strategie "so schnell wie möglich"? Natürlich eine Million. Erstens kann eine Person schnell müde werden. Zweitens wird er sich wie eine Werkzeugmaschine fühlen. Drittens wird er höchstwahrscheinlich weglaufen - dorthin, wo gewöhnliche Sprints mit einem Rückstand eingesetzt werden. Oder sie setzen einfach Aufgaben und warten auf das Ergebnis. Im Allgemeinen, wo es ruhiger ist. Die Praxis zeigt jedoch, dass "so schnell wie möglich" durchaus möglich ist, jahrelang zu leben, wenn es vernünftig ist, dass dies eine Planungsstrategie und kein Sweatshirt ist.

Ist es möglich, einen Sprint und seinen Rückstand zu werfen? Nein. Nicht weil dies eindeutige Begriffe desselben Scrums sind, sondern weil dies eine natürliche Planungsmethode ist, die jeder in der einen oder anderen Form verwendet. Es gibt viele Variationen, ein Prinzip: Sie müssen für einen bestimmten Zeitraum eine bestimmte Menge an Arbeit erledigen.

Ist ein Werkzeug wie ein Sprint ein einzigartiges und Schlüsselelement einer Technik? Nein. Dies ist das Gleiche wie zu sagen, dass das Eingeben von Code auf der Tastatur ein einzigartiger Begriff einer Technik ist. Fast alle Texte werden auf der Tastatur eingegeben.

Scrum Board

Formal ist ein Board kein Artefakt oder eine Regel, aber ich denke, es lohnt sich auch, darüber zu sprechen, da es unter Menschen ein ziemlich offensichtliches Muster gibt: Ein Scrum ist ein Board mit Aufklebern.

Hier verstehen Sie im Allgemeinen selbst alles. Eine Tafel mit Aufklebern, auf die Aufgaben geschrieben sind, ist nicht eindeutig. Dies ist grob gesagt ein plattformübergreifendes Tool. Meine Frau am Kühlschrank formt manchmal Aufkleber mit To-Do-Listen, obwohl sie nichts über Scrum weiß.

Ist dieses Tool gut? Es kommt darauf an, was zu vergleichen ist. Ja, vielleicht eine gute.

So können Sie beispielsweise schnell auswerten und sich im Aufgabenpool umsehen. In einem Computer oder einem anderen elektronischen Gerät müssen Aufgaben umgedreht werden - normalerweise passt nicht alles auf einen Bildschirm. Deshalb auch auf einen Blick.

Ein weiteres wichtiges Plus ist die Gesamtverfügbarkeit für das Team. Sie können jederzeit kommen und sehen, in kein System gehen, suchen, eine Auswahl treffen usw.

Viele Leute mögen die nicht virtuelle Natur des Boards. Schließlich ist in einem Computer alles virtuell, Sie berühren es nicht mit Ihren Händen. Und hier - bitte zumindest lecken. Einige lieben in dieser Hinsicht Korkbretter. Der Unterschied liegt in etwa zwischen Papier und E-Books.

Speziell für ein Scrum Board kann man einen Vorteil wie die Trennung in zwei Teile feststellen - es wird in der Arbeit gemacht. Beim Umgang mit Aufklebern im Haushalt werden bereits fertiggestellte weggeworfen - nicht sehr gut, weil Fortschritte werden schlechter gesehen.

Gibt es Nachteile von Scrum Boards? Natürlich. Wie jedes Board.

Zunächst der Haushalt - Entwürfe, Aufkleber von schlechter Qualität, schlechte Handschrift, Sabotage. Infolgedessen verlorene Aufgaben und Verwirrung im Management.

Auf dem Brett ist der Fortschritt nicht sehr sichtbar. Im Allgemeinen für den Sprint - ja. Heute, gestern - nein. Daher die Notwendigkeit einer täglichen Diskussion.

Insbesondere ist der Status von Aufgaben auf dem Scrum Board nicht sichtbar, wenn das Leben komplizierter ist als "geplant" - "erledigt". Kanban Board sieht vorzuziehen.

Das Board erlaubt keine normale Arbeit, wenn das Team geografisch verteilt ist. Daher erscheinen elektronische Karten.

Die elektronische Tafel scheint mir ein sicheres Zeichen für Sektierertum zu sein. Sie hat alle Vorteile des Üblichen verloren, nutzt es aber aus unbekannten Gründen weiterhin. Wahrscheinlich nur, weil es ein Board ist. Teil der Methodik.

Im Allgemeinen ist ein Werkzeug wie ein Werkzeug. In bestimmten Situationen - gut. In einigen ist es schrecklich.

Funktioniert Scrum ohne Board? Einfach. Und durch die Praxis bewiesen. Und da das Board kein obligatorisches Artefakt ist, wird es anscheinend möglich sein, weiterhin scrum - scrum zu nennen.

Scrum Master

Wer ist diese Wunderrolle? Wie ist es

Es gibt viele Möglichkeiten. Zum Beispiel ist ein Scrum Master wie ein Trainer im Sport. Es gibt zum Beispiel einen Fußballverein. Der Eigentümer der Produkte dort ist ein Manager, der die Ziele des Teams definiert. Ein Trainer ist einer, der einem Team hilft, diese Ziele zu erreichen.

In der üblichen Produktionsumgebung gibt es keine Trainer - wenn der Fußballverein so arbeiten würde, würde der Chef einfach vor dem Spiel in den Umkleideraum kommen und sagen: „Geh und gewinne.“ Und wenn sie verlieren, würde er mit dem Betrug zufrieden sein. Er hat jemanden rausgeschmissen, jemanden bedroht usw. Wie eine Fabrik.

Und der Coach fungiert wie der Scrum Master als Versorger zwischen Team und Manager. Natürlich hat der Trainer mehr Macht - er ist kein Anführer. Das Ergebnis wird aber auch schneller und verständlicher von ihm verlangt - niemand wird warten, bis er dort jemanden unterstützt. Der Trainer versteht wie der Scrum Master, wie das Team funktionieren soll, d. H. er setzt einfach aufgaben und erklärt, wie man sie löst. Stellt Verbindungen her, motiviert, schafft und erhält eine Atmosphäre usw.

Eine andere Analogie ist der Zugführer, einige Spezialeinheiten. Dies ist ein Spieltrainer. Erledigt Aufgaben zusammen mit Untergebenen und löst Kampfmissionen auf die gleiche Weise. In seiner Freizeit überwacht er die Vorbereitung und Verbesserung der Fähigkeiten, die Entwicklung neuer Geräte und das körperliche Training. Natürlich arbeitet er ständig mit dem Team in Bezug auf Psychologie zusammen - es motiviert, unterstützt, hilft. Natürlich manchmal mit besonderen Methoden, aber das Ziel ist eines - die maximale Kampfeffektivität des Zuges.

Scrum Master, verglichen mit diesen Jungs, einem Freeloader. Für das Ergebnis ist nicht besonders verantwortlich. Der Mangel an formaler Autorität wird anscheinend als Vorteil wahrgenommen - er ist ein Führer-Diener, aber tatsächlich kann er sich zu Verantwortungslosigkeit entwickeln. Kann man endlos erleichtern, ohne Einfluss auf das Ergebnis auszuüben? Und wenn sie sie rausschmeißen, suchen Sie nach einem anderen Team, das sie dort unterstützt.

Ist es möglich, die Rolle eines Scrum Masters zu ändern oder zu entfernen? Natürlich. Kombinieren Sie diese Rolle beispielsweise mit dem Product Owner. Ich weiß, dass in der Methodik geschrieben steht, dass es besser ist, dies nicht zu tun - dies verhindert, dass der Meister erleichtert. Auf der anderen Seite werden jedoch klare Ziele und Verantwortlichkeiten hinzugefügt. Wenn das Ziel verständlich und messbar ist, verwandelt sich die Erleichterung von einem optionalen, unverständlichen Mist in eine sehr spezifische, greifbare Pflicht, die sich direkt auf das Ergebnis auswirkt. Wie ein Trainer oder eine Mannschaft.

Es stimmt, dann geht die Bedeutung, ihn einen Scrum Master zu nennen, verloren. Dies wird wahrscheinlich ein Teamleiter sein - vergessen Sie nicht, dass der "Leiter" der Leiter ist.Ein Führer ist nicht nur eine Flagge in seinen Händen, sondern arbeitet auch mit Motivation, Zielen, der Fähigkeit zum Mitnehmen, der Einführung neuer Arbeitsmethoden, Trainingskompetenzen usw. Kurz gesagt, der Fahrer des Befehls. Und im Sinne der internen Entwicklung und im Sinne der Erzielung von Ergebnissen.

Was passiert, wenn Sie den Master durch Timlida in Scrum ersetzen? Dies kann nicht mehr als Scrum bezeichnet werden - eine der Schlüsselrollen wurde verworfen. Und wie wird sich das auf das Ergebnis auswirken? Und wenn überhaupt ohne Scrum Master? Wie wurde Belbin empfohlen, wenn seine Funktionen auf Befehl verschmiert werden? Einer erleichtert, der andere motiviert, der dritte überwacht die Umsetzung der Regeln. Es ist durchaus möglich, dass Sie so leben.

Insgesamt

Nun, alles, dann ist das Prinzip klar. Scrum ist wie jede andere Technik ein Algorithmus, der aus Komponenten oder Werkzeugen besteht. Wer hat es gewebt? Sagen wir Jeff Sutherland und Ken Schwaber.

Stellen Sie sich vor, zwei Leute, Jeff und Ken, haben eine Komponente entwickelt, die gute Vorteile bei der Entwicklung von Webanwendungen bringt. Du hast es in einen Github gegraben, installiert, ausprobiert - wow, es ist cool! Es funktioniert! Und die Wahrheit ist, es ist besser geworden!

Und dann fing irgendwann etwas an, Sie an dieser Komponente zu ärgern. Zum Beispiel scheint das Aufrufen seiner Methoden nicht polymorph genug zu sein. Sie gehen in den Quellcode und entdecken ...

Was können Sie dort finden? Ja, irgendetwas. Zum Beispiel Ausleihen, die Sie nicht mögen. Oder geliehene Komponenten sind korrekt, werden aber schief verwendet. Oder eine bestimmte Version einer guten Komponente wird direkt angezeigt, aber sie entwickelt sich gut und ist vor langer Zeit viel cooler geworden, aber Entwickler möchten keine übergeordnete Komponente anpassen. Oder Sie finden im Algorithmus ein Stück von anständiger Größe, das Ressourcen gut frisst, aber Ihrem Projekt keinen besonderen Nutzen bringt.

Was wirst du tun? Natürlich wird jeder etwas anderes beantworten. Jemand wird nicht einmal hineinkommen. Jemand wird gabeln und reparieren, was er nicht mag. Natürlich wird es einige Probleme beim Aktualisieren geben. Obwohl keine Tatsache - solche Dinge wie Scrum ändern sich seit Jahren nicht mehr. Jemand wird an die Entwickler schreiben. Ich weiß nicht, was sie antworten werden.

Jemand nimmt nur die Quellkomponenten und setzt sie auf ihre eigene Weise wieder zusammen - je nach Bedarf in einem bestimmten Projekt oder Produkt.

Sie können das gleiche mit jeder Technik tun. Ich wollte schreiben "es ist möglich und notwendig", habe aber meine Meinung nicht durchgesetzt - jeder entscheidet schließlich.

Ich möchte mit einem Goldratt-Zitat abschließen. Dies ist vielleicht die einzige der Leuchten, die einige Methoden entwickelt hat und ehrlich über die Notwendigkeit ihrer Änderung, Anpassung, Anordnung und vor allem des Verständnisses der Funktionsprinzipien spricht.

Es gibt einen Unterschied zwischen praktischen Methoden und den grundlegenden Konzepten, auf denen diese Methoden basieren. Konzepte sind allgemein, praktische Methoden sind die Anpassung von Konzepten an eine bestimmte Umgebung. Wie wir bereits gesehen haben, ist eine solche Anpassung nicht einfach und macht es erforderlich, bestimmte Elemente der Lösung zu entwickeln. Wir müssen uns daran erinnern, dass eine solche Lösung auf den anfänglichen (manchmal verborgenen) Prämissen einer bestimmten Umgebung basiert. Wir sollten nicht erwarten, dass diese Lösung in einer Umgebung funktioniert, für die diese anfänglichen Prämissen nicht zutreffen. Wir können viel Aufwand sparen und Enttäuschungen vermeiden, wenn wir diese ursprünglichen Prämissen sorgfältig formulieren.