Ich habe gerade einen Job bei Scrum angefangen und es scheint etwas zu fehlen. Ich bin neu bei Scrum

23

Der Code ist ein komplettes Durcheinander einer Kombination aus klassischem ASP / ASP.NET. Das Gedränge besteht darin, dass wir das große Durcheinander ausbessern oder ergänzen. Wir sind alle zu beschäftigt damit, um ein Umschreiben zu starten, also wundere ich mich ..

Wo ist der Teil in Scrum, in dem die Entwickler die Macht haben können, zu sagen, dass genug genug ist, und verlangen, dass ihnen Zeit gegeben wird, um mit dem großen Umschreiben zu beginnen? Wir scheinen uns in einer endlosen Schleife zu befinden, in der wir nur alten Code mit 'Stories' patchen.

Die Dinge werden also von nicht-technischen Leuten geleitet, die offenbar keine Lust haben, auf ein Umschreiben zu drängen, weil sie nicht verstehen, wie schlimm die Codebasis geworden ist.

Also, wer ist dafür verantwortlich, dass diese große Änderung beim Umschreiben zustande kommt? Die Entwickler? Der Scrum Master?

Die aktuelle Strategie ist einfach zu finden , Zeit und tun es selbst ohne die höheren-ups beteiligt , da sie meist zu Schuld für den aktuellen Schlamassel sind wir in .. sind <-Einsatz schimpfen über nicht-technische Menschen sagen , technische Menschen , was hier zu tun ->.

Punkouter
quelle
20
Sham agile hebt wieder den hässlichen Kopf ... Viele Unternehmen sagen, sie seien "agil" und verwenden "Scrum", obwohl sie dies auch nicht tun.
Oded
4
Du machst kein Scrum
20
Drucken Sie ein großes Poster davon aus und bringen Sie es an der Wand an, genau dort, wo Ihre nicht-technischen Mitarbeiter es deutlich sehen können: Manifest für Half-Arsed Agile Software Development ... während die Elemente auf der linken Seite theoretisch gut klingen ein Unternehmen , Unternehmen, und es gibt keinen Weg wir gehen von den Positionen auf der rechten Seite sind im Stich gelassen
gnat
12
Obligatorischer Link zu Joels Blog: joelonsoftware.com/articles/fog0000000069.html
marco-fiset
8
"<-Insertieren Sie, dass Nicht-Techniker Technikern sagen, was sie hier tun sollen->" , das Management sollte zu 100% Technikern sagen, was sie tun sollen. Deshalb sind sie Management und verantwortlich für das Geschäft , das ist es, was sie tun sein Bestes tun. Was sie zu 100% nicht tun sollten , ist ihnen zu sagen, wie sie es tun sollen. Die Techniker sollten darüber entscheiden, wie sie technisch das erreichen sollen, was sie tun sollen. Alles andere ist völlig naiv !

Antworten:

7

Ich bin mir nicht sicher, warum das für die Menschen so schwer ist. Sein Business Case ist genau hier:

We seem in an endless loop of just patching old code with 'Stories'.

Entwicklerzeit ist Geld. Viel Geld. Ich verließ eine Firma, die vor über einem Jahr eine Überarbeitung ihrer Benutzeroberfläche plante, und hoffte, dass die Übernahme von Scrum ihnen dabei helfen würde, nicht mehr mit den Rädern zu drehen. Was ist passiert? Gleiche alte 'gleiche alte'. Sie bauten weiterhin neue Funktionen auf und "Technical Debt" hatte keinen Geschäftsgrund, obwohl der halbe Code, den wir geschrieben hatten, bei jeder Iteration bedeutungslos wurde, da die zugrunde liegende Codebasis ein völlig veraltetes Durcheinander war. An ihrem Frontend hat sich nichts geändert, seit ich gegangen bin, und ich wurde dazu erzogen, es komplett zu überarbeiten. In den zwei Monaten, in denen ich dort war, habe ich kein bisschen CSS oder JavaScript angerührt. Ich habe gerade mit HTML und einem alten Java-Templatensystem aus den späten 1990ern rumgespielt.

Meine Antwort? Tun Sie, was Sie können, aber wenn die anderen Entwickler bereits aufgegeben haben und zu spät arbeiten, um die Sprintziele zu erreichen, anstatt praktischere Fristen geltend zu machen und darauf zu bestehen, dass die Verschuldung im technischen Bereich tatsächlich ein Blockierungsproblem darstellt, nehmen Sie das Schlimmste an und beginnen Sie, nach einem neuen Job zu suchen jetzt. Ihre Entwickler sind entweder nicht in der Lage oder nicht in der Lage, ihre Bedenken mitzuteilen, oder das Geschäft ist zu kurzsichtig, um zu verstehen, wie viel Geld sie verpissen.

Das Ignorieren dieser Probleme kostet IMMER auf lange Sicht mehr. Und nicht ein bisschen mehr, sondern VIEL mehr. Es ist nicht nur eine saugende Brustwunde, wenn es um Entwicklungszeit geht, sondern es wird auch zwangsläufig Ihr Talent reduzieren, da Entwickler, die es besser wissen und andere Optionen haben, Ihr Unternehmen wie die Pest meiden werden. Mein derzeitiger Chef ist ein Entwickler UND der Eigentümer des Unternehmens. Es gibt Dinge, die wir nicht neu schreiben, um uns auf andere Prioritäten zu konzentrieren, aber wenn etwas wirklich einen Refaktor benötigt, weil es eine konsistente Zeitsenke ist, bekommt es einen richtigen Refaktor. Und die Ergebnisse liegen auf der Hand. Das Ändern und Hinzufügen neuer Elemente wird durch mehrere Faktoren einfacher und schneller. Was einst Stunden gedauert hat, kann bei richtiger Architektur Minuten dauern. Unternehmen hören es nicht gern, aber es lohnt sich, die Dinge dafür zurückzustellen.

Scrum ist ein Fehler in Umgebungen, in denen Entwickler nicht viel Einfluss haben, IMO, weil es für die Unternehmenstypen zu einfach ist, Wartungen und Aktualisierungen zu ignorieren, um Stichpunkte zu finden, die sie in ihre Listen für erfolgreiche Initiativen aufnehmen können, wenn Auswertungszeit kommt herum. Sie werden immer ihre Häute und Beförderungsmöglichkeiten zugunsten der langfristigen bevorzugen, auch wenn es sie konsequent in den Arsch beißt, diese Themen auch zu ignorieren.

Scrum ist auch eine gewinnorientierte Branche und noch viel mehr. Unternehmen zahlen viel Geld für Scrum-Training. Menschen, die adoptieren möchten, sollten ein wachsames Auge darauf werfen, an wen vermarktet wird und wie realistisch es in ihrer jeweiligen Kultur sein wird.

Egal, wenn Sie sich wirklich für die Entwicklung interessieren, eine beschissene Codebasis, das Management mit Wachs in den Ohren und Entwickler ohne Rückgrat sind ein Rezept für Elend und eine Umgebung, die Ihre Fähigkeiten in keiner nützlichen Hinsicht verbessern wird. Zögern Sie nicht, GTFO in Bewegung zu setzen, bevor Sie tatsächlich feststellen, dass sich Ihre Bemühungen zur Behebung des Problems auszahlen.

Erik Reppen
quelle
Was Refactoring angeht, finde ich es seltsam, dass die Leute nicht „internalisieren“ können, dass Refactoring ein ständiger Bestandteil jeder Entwicklung ist, und nicht etwas, mit dem man sich schwer tut, wenn das Problem so schlimm ist, dass man nicht viel tun kann.
nicodemus13
1
Oder Sie haben keine Unit-Tests. :) Einer der Hauptvorteile von Unit-Tests besteht darin, dass Sie mit Zuversicht umgestalten können. Das größte Problem mit guten Praktiken ist das Gleiche wie alles - es erfordert Disziplin und im Allgemeinen bevorzugen die Menschen es, faul zu sein.
nicodemus13
2
Das oder sie sind ein weiteres Geschenk der extremen Coding-Masse, das sich genauso leicht in ein Werkzeug verwandeln lässt, das schlechtes Benehmen in den falschen Händen ermöglicht. Automatisierte Tests sind an wichtigen Punkten nützlich, aber ich bevorzuge die Soundarchitektur und das Schreiben auf eine Benutzeroberfläche anstelle eines Tests.
Erik Reppen
1
Ich würde sagen, dass das für alles gleich ist, ich persönlich schreibe die Tests, um die Schnittstelle zu definieren.
nicodemus13
1
Dann kommt der Schmerz all der Klumpen, die wieder hineingelegt werden müssen, da es diese kleinen Ausnahmen gibt, die bei der anfänglichen Analyse nicht leicht zu fassen sind.
JB King
33

Wenn Sie wirklich Scrum machen würden, was ich bezweifle, wäre der Product Owner dafür verantwortlich, über eine Neufassung zu entscheiden. Meistens ist ein Umschreiben keine gute Idee, übrigens, weil es keine neuen Funktionen hervorbringt, sondern nur neue Fehler einführt.

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

"Umschreiben ist keine gute Idee" zu erweitern:

Es ist fast immer besser, eine schrittweise Verbesserung zu versuchen. Finden Sie, wie Jarrod Robertson in einem Kommentar schrieb, ein Modul, das verbessert werden muss, und schreiben Sie eine Geschichte für den nächsten Sprint, um dieses bestimmte Modul zu verbessern. Erklären Sie dem Product Owner, warum dieses Modul Arbeit benötigt.

EricSchaefer
quelle
8
Wenn Sie so viel Erfahrung und Weisheit haben , wie Sie behaupten, verstärken und der Kerl sein , dass die Zahlen darauf hin , dass fehlerhafte Modul, auf das der Experte werden und es beheben, und dann einen Business Case zusammen zu re-write es, weil dann Sie wird der Experte für dieses Modul sein.
3
Einige Unordnung müssen aufgeräumt werden. Das Zitieren von Joel-Artikeln und die Behauptung, dass Umschreibungen nur selten ohne Statistiken herauskommen, die sowieso zweifelhaft wären (denn wer prahlt mit erfolgreichen Umschreibungen?), Ändert daran nichts.
Erik Reppen
3
@ErikReppen Also, wenn dein Wohnzimmer unordentlich ist, reißst du das Haus nieder und baust ein neues?
EricSchaefer
4
Wenn Sie seine Kommentare lesen, spricht er nicht über das Wohnzimmer. Es ist wahrscheinlich schwierig zu sagen, wo ein Raum beginnt und ein anderer endet. Und das ganze Haus brennt.
Erik Reppen
5
Whoa dort, Cowboy. Bevor wir nur eine pauschale Aussage zum Thema "Umschreiben ist keine gute Idee" machen, müssen wir dies mit der Wahrheit versehen, dass die Umstellung auf neue Technologien und die Anpassung an die Zeit für das Überleben Ihres Unternehmens durch die IT von entscheidender Bedeutung sind. Wenn Sie keine neueren (hoffentlich besseren) Technologien und die damit verbundenen Vorteile einsetzen, werden dies Ihre Konkurrenten tun. Dies gilt für die Technik im Allgemeinen. Der Model-T war ein perfektes Fahrzeug, aber dank der Konkurrenz und der Einführung neuer Technologien wurden Autos vielfach in die viel besseren Fahrzeuge "umgeschrieben", die wir heute fahren.
Fleisch
18

Ich werde wirklich stumpf sein ...

  • Sind Sie verantwortlich für die Entwickler in diesem Job?
  • Sind Sie der Projektleiter?
  • Wie viel "Anteil" halten die Entwickler an dem Projekt?
  • Was ist Ihre geschäftliche Rechtfertigung für ein Umschreiben?
  • Was ist mit der Codebasis, die sie völlig unbrauchbar und nicht wiederherstellbar macht?

Sie haben angegeben, dass Sie gerade einen Job angefangen haben, und dennoch scheinen Sie ein Meister der Situation dort zu sein. Vielleicht habe ich die Absicht Ihrer Frage falsch verstanden, aber ich habe den Eindruck, dass Sie einen Job angetreten haben, bei dem Sie eine Reihe von Problemen sehen, und Sie sind zu der einfachsten Schlussfolgerung gelangt, in der der Code gebrochen ist und der einzige Weg in die Zukunft ist eine Umschreibung, aber haben Sie wirklich die Kosten für Ihren Arbeitgeber in Betracht gezogen, um dies zu tun?

Mit jeder vorhandenen Codebasis - egal in welchem ​​schlechten Zustand sie sich befindet - hat der Eigentümer normalerweise eine beträchtliche Investition in die Produkte, die der Code darstellt. Mit der Codebasis sind sowohl direkte als auch indirekte Kosten verbunden. Als Softwareentwickler ist ein erneutes Schreiben oft das Letzte, was Sie tun möchten, da Sie das Risiko eingehen, Ihre Codebestände zu entwerten und somit eine geringere Rendite für alle vorherigen zu erzielen Bemühungen.

Nehmen Sie das Betriebssystem des Fensters als Beispiel. Mit jeder neuen Version wurde ein großer Teil des Codes aus der vorherigen Version übernommen. Manchmal werden ganze Bibliotheken und APIs über mehrere Betriebssystemgenerationen hinweg verschoben. Warum? Weil die Entwickler wissen, dass diese Elemente funktionieren, getestet, gepatcht und repariert wurden, um Sicherheits- und Speicherprobleme zu vermeiden, und weil sie verdammt viel Geld gekostet haben, um in diesen Zustand zu gelangen. Niemand möchte Arbeitscode wegwerfen, wenn er Geld verdient, auch wenn die Wartungskosten relativ hoch sind, die Kosten für den Neuanfang immer noch höher sind und in einem Unternehmen wie Microsoft Milliarden auf der Bank haben erlaube ihnen, von vorne zu beginnen, wenn sie wollen, aber sie tun es nicht t weil sie ihre Rendite aus ihrer Investition maximieren wollen. Ihr Arbeitgeber unterscheidet sich nicht von Microsoft, mit Ausnahme der Tatsache, dass Sie Milliarden in bar für ein Projekt ausgeben müssen.

Der Code ist also ein Chaos, und es scheint, als gäbe es Kommunikations- und Grenzprobleme zwischen den verschiedenen Bereichen des Unternehmens. Was können Sie oder Ihre Kollegen dagegen tun?

Eine Möglichkeit ist, einfach so weiterzumachen wie bisher und auf ein Wunder in der Zukunft zu hoffen. Wahrscheinlich keine gute Idee, und wahrscheinlich nur Ihre Frustration und Stress zu erhöhen.

Eine bessere Option ist es, sich einfach an die Arbeit zu machen, aber als Teil davon suchen Sie nach Möglichkeiten, Tests hinzuzufügen, um die Bereiche des Codes zu unterstützen, die am anfälligsten erscheinen, und sie dann zu überarbeiten, bis sie stabiler werden. Es fällt Ihnen leichter, ein überzeugendes Argument für die Verbesserung der Unternehmensinvestition vorzulegen, als sich zu streiten, alles einfach wegzuwerfen.

Eine noch bessere Option ist es, als Team organisiert zu sein und sicherzustellen, dass Sie jemanden mit einem ausreichenden Dienstalter an die Seite bekommen, der es dem Team ermöglicht, flexibler Zeit zu planen, um die Codebasis zu verbessern. Es ist mir egal, wie beschäftigt ein Unternehmen ist oder wie streng der Zeitplan zu sein scheint, es gibt immer wieder "Pausen" in der Aktivität, die genutzt werden können, um ein oder zwei Verbesserungen zu erzielen. Es ist jedoch noch besser, wenn die Verbesserungen während der Ausführung anderer Aufgaben vorgenommen werden können. Wenn ich es wäre, würde ich mich mit einem Manager anfreunden und ihn mit Konzepten in einigen der kanonischen Bücher bekannt machen, die Softwareentwickler lesen. Code bereinigenist wahrscheinlich die, die Ihr Team am meisten braucht. Pflanzen Sie ein paar Punkte ein, um den Code zu verbessern, und geben Sie ein paar Beispiele dafür, was Sie meinen. Ein guter Manager wird den Wert erkennen, inkrementelle Verbesserungen am Code vorzunehmen, insbesondere wenn Sie das Konzept der technischen Verschuldung beschreiben können . Helfen Sie Ihrem Teamleiter oder Manager, ein gutes Geschäftsmodell für die Verbesserung von Code zu erstellen, und er hat eine bessere Motivation, darauf zu reagieren.

Es ist auch nicht genug zu sagen "der Code ist unordentlich". Sie müssen Ihre Kollegen dazu ermutigen, die Codierung die ganze Zeit über zu üben und saubere Codierungstechniken zu verwenden, um ein wenig Aufräumen zu fördern. Ich habe ein kleines Plakat, das ich jedes Mal, wenn ich einen neuen Job annehme, ausdrucken und an meiner Bürowand aufhängen kann. Es heißt "Bemühe dich immer, den Code ein wenig schöner zu lassen, als du ihn gefunden hast". Gleich daneben füge ich ein weiteres hinzu, das besagt "Lilien müssen nicht vergoldet werden". Sie erinnern mich beide daran, dass ich immer versuchen sollte, das zu verbessern, was ich finde, aber vermeiden, einfach ein Problem mit dem anderen zu vergolden. Massive Rewrites sind oft die schlechteste Art der "Vergoldung", weil sie oft aus den falschen Gründen durchgeführt werden. Sicher, eine völlig neue Produktversion könnte irgendwann gerechtfertigt sein.

S.Robins
quelle
Nein, ich bin nicht verantwortlich. Ich bin ein Entwickler, der 12 Jahre professionell und 7 Jahre .NET programmiert hat. Ich habe viele Verträge abgeschlossen und nach einer Weile kann man schnell ein Gefühl für die Qualität des Codes bekommen. Wie viel 'Einsatz'? Ich bin mir nicht sicher, was du damit meinst. Wir können den alten CLASSIC ASP, der jetzt extrem zerbrechlich ist, immer wieder reparieren, und es dauert zehnmal länger, als wenn diese Änderungen Teil einer guten modernen Architektur wären. Die geschäftliche Rechtfertigung ist , dass die Website nun in der Produktion zu einem Modul aufgrund abstürzt , dass niemand wegen des hohen Umsatz zu verstehen scheint
punkouter
Ich glaube nicht, dass Sie verstehen, wie schlecht diese Codebasis ist. Darüber hinaus ist dies keine Raketenwissenschaft. Dies ist CRUD 101. Dies zeigt ein Formular an, in dem ein Benutzer es ausfüllen, validieren und dann einige Berichte und PDFs aus den Daten erstellen kann. Das ist es im Grunde. Aber über 10 Jahre ist der Code in so viele Teile zersplittert worden, dass es schrecklich ist. Ich war in den letzten 12 Jahren an ungefähr 20 Projekten beteiligt und dies muss die schlimmste Sammlung von Code sein, die ich je gesehen habe und die tatsächlich in der Produktion verwendet wird ... Ich wünschte, ich könnte euch alles zeigen
Punkouter
Was ich für den Anfang mache, ist, die Leute im Team zu finden, die eine Leidenschaft für das Codieren haben und daran interessiert sind, ein Teil davon zu sein, dies endlich richtig zu machen. Es ist nicht einfach, diese Leute zu finden, weil ... brucefwebster.com/2008/04/11/…
punkouter
16
@punkouter: Ich glaube nicht, dass Sie verstehen, worauf es hier ankommt. Die Codebasis, die "schlecht" ist, ist kein Geschäftsfall für ein Umschreiben. Die Leidenschaft für das Codieren zu haben und Dinge richtig machen zu wollen, ist kein Geschäftsgrund für ein Umschreiben. Kostspielige Produktionsfehler und -ausfälle und die Implementierung trivialer, aber wichtiger neuer Funktionen dauert Monate - DIESE bieten einen Business Case für ein Umschreiben.
Michael Borgwardt
1
@punkouter Ihr Link zu einer Beschreibung des Phänomens "Totes Meer" ist auch besonders passend. Es ist für das Unternehmen von keinem Wert, Wissen durch Abnutzung zu verlieren, und es ist von großem Wert, das zurückzugewinnen, was es kann. Eine Investition Ihrer Zeit, um ein möglicherweise teures und unnötiges Umschreiben zu vermeiden, hat einen höheren geschäftlichen Wert als der Verlust von Wissen und Know-how. Bessere Einstellungspraktiken zu fördern und sich der Herausforderung zu stellen, das Problem zu beseitigen und das System zu verbessern, ist für Sie eine Gelegenheit, ein wenig Anerkennung zu verdienen und ein geschätzter Vorteil für Ihren Arbeitgeber zu werden.
S.Robins
13

Hier ist die offizielle Definition des Scrum-Entwicklungsteams aus dem offiziellen Scrum-Handbuch . Ich lege Wert auf die Teile, die Sie direkt betreffen:

Das Entwicklungsteam besteht aus Fachleuten, die am Ende jedes Sprints ein potenziell ablösbares Increment of Done-Produkt bereitstellen. Nur Mitglieder des Entwicklungsteams erstellen das Inkrement. Entwicklungsteams werden von der Organisation strukturiert und befugt , ihre eigene Arbeit zu organisieren und zu verwalten . Die daraus resultierenden Synergien optimieren die Gesamteffizienz und Effektivität des Entwicklungsteams. Entwicklungsteams haben die folgenden Eigenschaften:

  • Sie organisieren sich selbst. Niemand (nicht einmal der Scrum-Master) teilt dem Entwicklungsteam mit, wie das Product Backlog in Inkremente potenziell freigebbarer Funktionen umgewandelt werden kann.

  • Entwicklungsteams sind funktionsübergreifend und verfügen über alle Fähigkeiten, die zur Erstellung eines Produktinkrements erforderlich sind.

  • Scrum erkennt keine anderen Titel für Mitglieder des Entwicklungsteams als Entwickler, unabhängig von der von der Person ausgeführten Arbeit. Es gibt keine Ausnahmen von dieser Regel.

  • Die einzelnen Mitglieder des Entwicklungsteams verfügen möglicherweise über spezielle Fähigkeiten und Schwerpunkte, aber die Verantwortung liegt beim gesamten Entwicklungsteam. und,

  • Entwicklungsteams enthalten keine Unterteams, die bestimmten Bereichen wie Tests oder Geschäftsanalysen gewidmet sind.

Das Entwicklungsteam ist daher für sein eigenes Durcheinander verantwortlich und sollte es selbst ansprechen, ohne jemanden außerhalb des Teams fragen zu müssen.

Nehmen Sie in jede Ihrer zukünftigen Schätzungen eine Zeit für die technische Schuldenbereinigung auf und stellen Sie sicher, dass die Qualität der von Ihnen gelieferten Software erstklassig ist.

Wenn Sie wirklich ein vollständiges Umschreiben durchführen müssen, müssen Sie das Problem in der Scrum-Restrospektive beheben. Möglicherweise bricht der Product Owner das Projekt ab und startet ein neues. Der Product Owner ist auch der einzige, der einen Sprint abbrechen kann.


quelle
8
Das Team ist für sein eigenes Durcheinander verantwortlich, kann sich jedoch nicht für die Priorität der technischen Verschuldung gegenüber den neuen Funktionen entscheiden. Es ist der Product Owner, der das entscheidet. Es ist nur so, dass das Team entscheiden kann, wie es den Rückstand liefern soll, sobald die Bestellung die Priorität des Rückstands festgelegt hat. Sie können sagen, "wir können Feature X nicht liefern, ohne zuerst Y umzugestalten", aber sie können nicht sagen, "nein, entschuldigung, wir werden keine neuen Features hinzufügen, bis wir es von Grund auf neu schreiben".
Bryan Oakley
6
@BryanOakley: Von Grund auf neu zu schreiben ist nicht das, was ich vorschlage. Ich schlage vor, die technische Verschuldung schrittweise zu reduzieren, während das Entwicklungsteam in den betroffenen Bereichen arbeitet. Und ich schlage auch vor, dass sie entsprechend schätzen.
1
Das ist gut, aber was ist, wenn wir neue Server, neue Datenbanken und neue Software benötigen, damit wir Entwickler über alle Tools verfügen, die wir für das Neuschreiben benötigen? Und wie beginnt das Neuschreiben, wenn es in den einzigen „Geschichten“ um die Behebung aktueller Probleme geht und niemals um das Konzept, ein Neuschreiben zuzulassen?
Punkouter
1
@punkouter: Wenn Sie neu schreiben müssen, wenden Sie sich an die Scrum-Retrospektive, um das Problem zu beheben. Dann übernimmt der Product Owner die Verantwortung, das aktuelle Projekt abzubrechen und ein neues zu starten.
5
Gehen Sie nicht davon aus, dass die Entscheidung zum Umschreiben die 'richtige' ist, nur weil sie diejenige ist, die die Entwickler am meisten anspricht. Manchmal gibt es einen guten geschäftlichen Grund, Funktionen jetzt bereitzustellen, obwohl dies die technische Verschuldung erhöhen wird.
DJClayworth
8

Während Sie dies beschreiben, muss ich sagen, dass ich nichts sehe, was irgendetwas mit SCRUM zu tun hat, oder dass Ihr Produktentwicklungsteam derzeit ein Problem darstellt .

Das ist normal

Was Sie beschreiben, ist die normale Entropie einer Codebasis. In Ihrem Fall ist das Team wahrscheinlich weiter vom Ideal entfernt gestartet, aber dennoch wird jede Codebasis irgendwann zu einem Big Ball of Mud .

In einem vollkommen perfekten Szenario auf der grünen Wiese können Sie möglicherweise nur weiter von der absoluten Entropie entfernt beginnen und sich langsamer darauf zubewegen.

Ich stimme anderen zu, das Chaos in der Codebasis ist auf Entwickler zurückzuführen. Ich bin sicher, dass es viele Jahre vor der Einführung von SCRUM liegt.

Dies ist keine technische oder Entwicklerentscheidung, sondern eine geschäftliche Entscheidung.

Sie wissen nicht, warum die Produktbesitzer kein Neuschreiben wünschen. Sie als Entwickler denken, dass dies erforderlich ist, aber gibt es wirklich einen Geschäftsgrund dafür?

Wenn es einen echten Business Case gibt , winkt nicht nur eine Hand; "Der Code ist ein altes Durcheinander, mit dem ich auf der grünen Wiese anfangen möchte, weil ich genau das möchte" , dann würde das Management die Kosten für ein erneutes Schreiben in Anbetracht der Rendite dieser Investition in Kauf nehmen.

Sie haben kein solides Geschäftsmodell für ein erneutes Schreiben angegeben, nur eine Schimpfe über Ihre Meinung, wie alle anderen dieses Chaos verursacht haben, und Sie möchten nicht damit umgehen.

Beweis - Profit treibt Geschäftsentscheidungen an, um funktionierende Software wegzuwerfen, und nicht einige OCDs, die eine saubere Codebasis benötigen

Wenn Sie wirklich den Beweis erbringen können , nicht nur die Theorie, sondern auch den Beweis, dass das Ausgeben von XDollars für ein Neuschreiben auf der grünen Wiese garantiert wird, umX * N Dollars für das Geschäft im YZeitrahmen (wo Nhoch und Ykurz ist) zu verdienen , erhalten Sie möglicherweise eine gewisse Unterstützung vom Management . Dies ist ein höchst unwahrscheinlicher Fall, den Sie vorlegen und beweisen können.

Ansonsten muss man sich nur darum kümmern, das ist Realität. Entgegen Ihrer unerschütterlichen Behauptung, dass es ohne dieses großartige, makellose Umschreiben absolut keinen Weg vorwärts gibt, würde ich wetten, dass die von Ihnen beanstandete Codebasis in mehr als 5 Jahren noch irgendwo funktionieren und jemandem Funktionalität und Wert bieten wird Sie haben die Firma verlassen.

Peter Mortensen
quelle
1
Das bedeutet nicht, dass es nicht in der Verantwortung der Entwickler liegt, ein Versionskontrollsystem unabhängig davon intern zu verwenden . Ich würde sagen, dass es immer noch in der Verantwortung der Entwickler liegt, unabhängig davon für sich selbst und ihre Interessen zu sorgen. In Ihrem Strohmann haben diese 200 Entwickler nicht getan, was sie tun mussten, das Management hat ihnen keine Waffe auf den Kopf gestellt und ihnen verboten, das Versionskontrollsystem selbst einzurichten.
3
Messy Code-Datenbanken sind niemals ein direktes Ergebnis des Managements, da das Management niemals direkt für das Schreiben von Code verantwortlich ist. So einfach ist das. Manangement ist dafür verantwortlich, dass die Entwickler ein weniger als ideales Arbeitsumfeld haben und fördern, aber die Verantwortung, Probleme wie fehlende Versionskontrolle zu lösen, liegt immer bei denjenigen, die die eigentliche Arbeit erledigen.
Peter Lange
1
Ausgelagerte Entwickler sind ein Managementproblem. Die Leute von innen wussten es besser. Das Management tat gern so, als ob es mit der Einstellung von 200 Entwicklern eine Menge Geld sparte, obwohl es mit 20 kompetenten Entwicklern wahrscheinlich großartig hätte abschneiden können. Ähnlich wie bei vielen Scrum-Implementierungen, die ich gesehen habe, war die verabschiedete Strategie das Produkt von Inkompetenz und nichts, worüber die Entwickler, die tatsächlich Angestellte des Unternehmens waren, Kontrolle hatten.
Erik Reppen
2
@Erik, ohne zu sagen, dass Manager keine Verantwortung für eine fehlerhafte Codebasis (oder andere in ihrer Abteilung getroffene Entscheidungen) übernehmen müssen und dass Manager nicht direkt dafür verantwortlich sind, die Umgebung bereitzustellen, in der der Entwickler arbeitet, wie z. B. das von Ihnen beschriebene Szenario. Die einzige Person, die direkt für die Codebasis verantwortlich sein kann, ist die Person, die den Code selbst schreibt.
Peter Lange
3
Ich möchte auch hinzufügen, dass es dumm ist, Ihre Entwickler nicht für geschäftliche Ziele zu sensibilisieren. Ich habe nie verstanden, warum die Leute so darauf bedacht sind, dieses Zeug vor den Leuten zu verbergen, die das Verhalten ihres Produkts bestimmen. Das Wissen um die langfristigen Ziele eines Unternehmens kann in der Tat Aufschluss darüber geben, wie Sie eine App erstellen. Außerdem lösen Entwickler, zumindest gute, Probleme. Sie lösen ständig Probleme. Einige von uns antizipieren und lösen sie frühzeitig in unseren Köpfen oder lassen zumindest die richtigen Türen in unserem Code offen.
Erik Reppen
7

Ich bin in der Regel skeptisch, wenn Leute auf "große Umschreibungen" drängen. Es gibt Fälle, in denen es definitiv Sinn macht, aber in den meisten Fällen hat dieser Legacy-Code einen Wert (da er bereits in Produktion ist und für die Zwecke verwendet wird, die zu seiner Erstellung geführt haben). Das Durchführen eines großen Umschreibens ist in vielen Fällen das Gegenteil von Agilität. Wie lange würde es dauern, bis die neue Version der Anwendung so weit ist, dass sie die vorhandene Anwendung ersetzen kann?

Den Ansatz, den ich vorziehen würde, nennt Martin Fowler die Würgepflanze . Implementieren Sie neue Funktionen (einschließlich Änderungen an vorhandenen Funktionen) mit dem neuen Ansatz, aber verwenden Sie die vorhandene Anwendung als Gitter, auf dem die neuen Funktionen aufbauen können. Dies gibt Ihnen das Beste aus beiden Welten. Sie müssen nicht alles anhalten, während das große Umschreiben auf snuff gebracht wird, aber Sie erhalten den Vorteil, neuen Code zu schreiben, der die Vorteile aktualisierter Frameworks nutzt. Es ist definitiv ein schwierigerer Ansatz, als sauber anzufangen, und vielleicht nicht so sexy, aber es bietet mehr Wert für das Geschäft als alles wegzuwerfen, was da ist, weil es veraltet ist.

Michael Brown
quelle
Das kann schwierig sein, wenn die vorhandene Basis ziemlich durcheinander ist. Er spricht über mehrere ältere asp.net-Systeme von völlig verschiedenen Autoren, die für dieselbe verdammte Site eng miteinander verbunden sind. Web Forms alleine ist ein Monster und ich bin mir sicher, dass das in der Mischung steckt.
Erik Reppen
Oh, ich habe nie gesagt, dass dies der einfachste Weg ist ... aber für die Beteiligten ist er schmackhafter. Wenn Sie es einmal durchgehen, stellen Sie hoffentlich auch sicher, dass es einfacher ist, es auslaufen zu lassen, wenn das Neueste von heute und das Beste von morgen veraltet ist.
Michael Brown
Genau. Aber wie ich schon sagte (und nicht sicher, ob jeder hier ist). Was jetzt existiert, ist eine Sammlung von ungefähr 9 verschiedenen Webanwendungen, von denen die eine Hälfte klassisches ASP und die andere Hälfte verschiedene Formen von ASP.NEt sind. Alle verwenden völlig andere Methoden, um mit dem Datenzugriff umzugehen usw. Die einzige Möglichkeit, über die gesprochen wird, besteht darin, die Benutzeroberfläche so zu fälschen, dass sie so aussieht, als wäre der neue Code Teil des alten Codes die Datenbank .. Eine Tabelle hat 400 Felder!
Punkouter
Ich bin neugierig. Was repräsentiert diese Tabelle? Das ist das Schlimmste, von dem ich gehört habe, seit ich i ++ gesehen habe. doSomething (i); mehr als ein Dutzend Mal in einem Code wiederholt, der aus einem kaputten JSP-Tag hervorging.
Erik Reppen
5

Wo ich bin und wie wir arbeiten, ist das, was wir tun würden: Schreiben Sie eine neue Geschichte und übergeben Sie sie dem Produktbesitzer, der dann entscheidet, wie er sie priorisieren soll. Ein Beispiel wäre: "Als Entwickler von Produkt X möchte ich den Code in diesem Bereich neu schreiben, damit die zukünftige Entwicklung effizienter ist." Die Akzeptanzkriterien müssten dann lauten: x neu schreiben / umgestalten damit es auf diese weise besser ist.

Ich weiß nicht, in welcher Situation Sie sich befinden, aber wenn wir von vorne anfangen wollen, müssen wir uns mit dem Produktbesitzer zusammensetzen und ihn überreden, warum und dann einen Stapel von Geschichten schreiben, um das Bestehende neu zu erschaffen Funktionalität.

Die anderen Dinge, die wir unternommen haben, um mit schlechtem Code und / oder Legacy-Code umzugehen, waren Aufgaben für die Überarbeitung, wenn die User Storys herausgegeben wurden.

BennyB
quelle
Also können die Entwickler 'Geschichten' schreiben und sie einreichen? Das Problem ist, dass die Gründe für das erneute Schreiben zu technisch sind, als dass sie damit
fertig werden könnten.
6
@punkouter: Wenn die Gründe für das Neuschreiben rein technischer Natur sind (dh nicht das Geschäftsgeld kosten), HABEN Sie KEINEN ausreichenden Grund für ein Neuschreiben.
Michael Borgwardt
@MichaelBorgwardt: Wollen Sie damit sagen, dass technische Gründe niemals ausreichen, um etwas umzuschreiben? Das ist ein grundsätzlich gebrochener Ansatz, wenn ich Sie richtig verstehe. Eine Sache, die mich ständig nervt, ist der normale Master / Slave-Ansatz, bei dem das "Geschäft" alles bestimmt, was "IT" oder eine Abteilung tut. Das stimmt nur bedingt. Die IT hat ihre eigenen Anforderungen, die intern sind und nicht vom Unternehmen entschieden werden. Dies ist eine Sache, die normalerweise fehlt und zu nicht entwickelter, nicht zweckmäßiger Software führt.
nicodemus13
1
@ user12355 Wie ich gesehen habe, ist Michaels Punkt, dass es keinen Fall gibt, wenn es ihnen kein Geld einbringt. Wenn sie kein Geld verlieren, kostet sie ein Umschreiben Geld. Geld, das nicht zurückgefordert werden kann. Ein Entwickler könnte den Fall "Dieser Code ist zum Kotzen" bringen, aber wenn er seinem Arbeitgeber keinen finanziellen Vorteil nachweist, erhält er niemals grünes Licht zum Umschreiben, es sei denn, er tut es alleine.
Rig
1
@ user12355: Technische Gründe sind für eine User Story auf jeden Fall ausreichend. Sie reichen nicht unbedingt aus, um diese Geschichte an die Spitze der Liste zu bringen und in einen Sprint zu verwickeln.
Adam V
4

Die Entscheidung für große Änderungen ist eine geschäftliche Entscheidung. Sie können versuchen, Geschäftsentscheidungen zu beeinflussen, indem Sie aus Ihrer Sicht an die Personen verkaufen, die für den geschäftlichen Teil der Dinge verantwortlich sind.

Jedoch; Die Änderung der Codequalität von einer Iteration zur nächsten ist eine Entscheidung des Entwicklers. Wenn Sie zulassen, dass die Codequalität abnimmt, fügen Sie technische Schulden hinzu, um die Erwartungen des Produktbesitzers jetzt zu erfüllen. Sie können die Verantwortung für den von Ihnen geschriebenen Code übernehmen und sicherstellen, dass die Codebasis verbessert wird, nicht umgekehrt. Dies bedeutet, dass Sie an Geschwindigkeit verlieren, da Sie die technische Verschuldung kontinuierlich verringern und Ihr Produktbesitzer mit Sicherheit enttäuscht sein wird. Sie können versuchen zu erklären, dass sich die Codequalität verschlechtert hat und Sie nun Schritte unternehmen, um dieses Problem zu beheben.

Jetzt ist mir klar, dass es ein schrecklicher Schritt ist, und es könnte sich verlockend anfühlen, ihn nur um einen weiteren Sprint zu verzögern, damit Sie Feature X vor einer wichtigen Frist beenden können. Leider wird es immer schwieriger, je länger Sie warten.

Übrigens handelt es sich nicht ausschließlich um ein Scrum-Problem, und ich schlage auch keine spezielle Lösung für Scrum vor. Hier geht es darum, dass Entwickler Eigentümer des Codes werden.

Buhb
quelle
1
Richtig, und wenn Sie eine Geschichte von 10 Jahren konstantem Umsatz und einmaligen Entwicklungen von Entwicklern haben, die die moderne Architektur eindeutig nicht gut codieren oder verstehen konnten, dann haben Sie das, was ich jetzt habe ... Ich bin mehr als jeder andere alarmiert, seit ich Ich bin neu in der Arbeit und nicht daran gewöhnt, eine so niedrige Qualität des Codes zu sehen. Ich möchte das Umschreiben nicht nur aus egoistischen Gründen, um Spaß am Schreiben von neuem gutem Code zu haben, sondern auch für alle anderen, selbst wenn Sie verstehen die Situation nicht so wie ich.
Punkouter
1
Ich kann nur wiederholen, was bereits gesagt wurde; Formal kann man sich nicht entscheiden, dass jetzt die Zeit für das große Umschreiben ist. Sie könnten versuchen, den Beteiligten zu zeigen, wie viel Aufwand erforderlich ist, um Ihre Codebasis schrittweise in einen etwas weniger schmerzhaften Zustand zu versetzen, und diesen mit dem Aufwand zu vergleichen, der für ein vollständiges Umschreiben erforderlich ist.
Buhb
3

Die Entwickler sind dafür verantwortlich, die Welt über den aktuellen Status der Codebasis zu informieren. Dies kann während eines täglichen Scrums, einer Retrospektive oder einfach nur informell geschehen. Es mag offensichtlich erscheinen, aber wenn Sie nicht klar ausdrücken, was für ein Chaos es ist und wie viel Zeit Sie damit verschwenden, wird es niemandem auffallen. Der Scrum-Master ist in der Regel dafür verantwortlich, die Informationen an die PO und die für das Projekt verantwortlichen Personen weiterzuleiten, sie davon zu überzeugen, dass etwas getan werden muss, und dann die Implementierung einer Lösung durch das Team zu erleichtern.

Als Randnotiz, ein Big Bang Rewrite ist IMO nicht unbedingt die richtige Antwort auf diese Art von Problem. Wie satt die Entwickler mit der aktuellen Codebasis sind, kleine messbare Schritte in Richtung einer saubereren Architektur sind oft eine bessere Idee, da Sie den Fortschritt sehen, Ihre Arbeit rechtfertigen können, indem Sie der PO regelmäßig die Erfolge zeigen und den Implementierungsprozess für neue Benutzer fortsetzen parallele geschichten statt sich in einer endlosen, ressourcen-monopolisierenden verjüngungskur zu verlieren.

guillaume31
quelle
Wie ich bereits erwähnte. Bei einer Sammlung von 6 klassischen ASP-Sites + 4 .net 1.1-Sites, die alle zu einer Site zusammengefasst sind, gibt es keinen Weg nach vorne. Alles auf unterschiedliche Art und Weise von unterschiedlichen Personen codiert.
Punkouter
Ich bin mir ziemlich sicher, dass sich die Codebasis in den kommenden Jahren weiterentwickeln wird, um Dr. Ian Malcom vom Jurrasic Park zu umschreiben .
Möglicherweise wird es in den kommenden Jahren noch einige geben, aber unterschiedliche Arten von .net-Legacy-Sites, die eng miteinander verbunden sind, werden sich in diesen Jahren wahrscheinlich nicht sehr weit bewegen.
Erik Reppen
Sicher, aber wenn all diese .net-Sites weiterhin funktionieren und ihre Funktionsweise weiterhin entweder direkt oder indirekt Einnahmen für das Unternehmen generiert, warum ist die Dynamik der Zukunft so wichtig? Wenn der Umsatz direkt von der Qualität der Codebasis abhängt, können Sie davon ausgehen, dass die Manager keine Zeit mit der Neugestaltung der Codebasis verschwenden werden, da alle wie die Entwickler Hypotheken zu zahlen haben.
Peter Lange
Unaufhörliche Vorwärtsbewegung ist meiner Erfahrung nach in der Regel die Wurzel des Problems. Der Schmerz beginnt, wenn die Turnaround-Erwartungen nicht nachlassen, während sie sich noch nicht mit den Problemen in der Architektur auseinandersetzen und glauben, Scrum werde alle zwei Wochen auf magische Weise neue Sätze vollständiger Funktionen entwickeln, ohne das Problem weiter zu verschärfen. Ich sage nicht, dass wir uns nicht vor dem Drang hüten sollten, Dinge herauszureißen, wenn wir keine Alternativen finden, die die Zeitnot lösen, die uns begegnen, aber ich habe mindestens zwei sehr gute Fälle für Major gesehen Überholungen in meiner Karriere.
Erik Reppen
2

Du hast gefragt:

Wo ist der Teil in Scrum, in dem die Entwickler die Macht haben können, zu sagen, dass genug genug ist, und verlangen, dass ihnen Zeit gegeben wird, um mit dem großen Umschreiben zu beginnen? Wir scheinen uns in einer endlosen Schleife zu befinden, in der nur alter Code mit 'Stories' gepatcht wird. Die Dinge werden also von nicht-technischen Leuten betrieben, die offenbar keine Lust haben, auf ein Umschreiben zu drängen, weil sie nicht verstehen, wie schlecht die Codebasis geworden ist.

Als Manager und Entwickler besteht die einfachste Antwort auf Ihre Frage darin, dass Scrum, eine andere Methode oder ein Geschäftsszenario, in dem der Entwickler die Befugnis hat, genug zu sagen und a zu fordern, keine Rolle spielt umschreiben. Viele Leute hier haben gute, stichhaltige Argumente vorgebracht, um zu erklären, warum Umschreibungen häufig schlechte Ideen sind, und um zu erklären, wie Änderungen inkrementell und agil herbeigeführt werden können und sollten. Und ich stimme ihnen allen zu.

Aber das Endergebnis ist noch einfacher. Du wirst diese Entscheidung NIE treffen müssen. Sie sind der Angestellte, und die einzige Entscheidung, die Sie wirklich treffen müssen, ist "werde ich weiterhin für diese Arschlöcher arbeiten oder einen neuen Job finden, der meine verrückten Fähigkeiten fürchtet." Ihr neuer Job erlaubt Ihnen auch nicht, diese Entscheidung zu treffen, aber zumindest werden Sie das Gefühl haben, Ihr Schicksal unter Kontrolle zu haben, wenn Sie von Job zu Job springen.

Peter Lange
quelle
1
Wenn ich hier richtig zwischen den Zeilen lese, hört es sich so an, als wären Sie ein bisschen bitter darüber, dass Sie nicht in der Lage sind, Neueinstellungen zu halten. Wenn ich mich nicht irre, haben Sie in Betracht gezogen, dass die neuen Mitarbeiter, deren Fähigkeiten tatsächlich so gefragt sind, dass sie laufen können, wenn sie nicht gerne in Ihrem Unternehmen arbeiten, die einzigen Nichtkonstanten in der Gleichung sind?
Erik Reppen
1
Nicht annähernd. Eigentlich sind die Mitarbeiter in meiner Abteilung schon seit ein paar Jahren bei mir. Ich habe praktisch keinen Umsatz. Der Punkt, den ich anstrebe, ist, dass letztendlich in jedem Unternehmen, in jeder Branche, die Arbeit, die der Mitarbeiter leistet, ganz der Person überlassen bleibt, die den Gehaltsscheck unterzeichnet, und nicht dem Mitarbeiter. Die einzige Entscheidung, die der Mitarbeiter treffen muss, selbst wenn mein Vorgesetzter eine Anfrage stellt, besteht darin, die Mitarbeiterbeziehung beizubehalten oder nicht beizubehalten. Auf dem Originalplakat wurde gefragt, wann er als Mitarbeiter die Entwicklung bestimmen darf. Die Antwort ist niemals.
Peter Lange
Was war dann mit der Charakterisierung "Angst vor meinem verrückten Talent"? Dieser Typ ist ein erfahrener Entwickler. Und ich kann Ihnen aus meiner Erfahrung mit ähnlichen Situationen sagen, dass das Problem, von dem er spricht, nicht nur darin besteht, die Dinge auf seine Weise zu wollen, sondern dass es sich tatsächlich um eine anhaltende Katastrophe handelt, die sowohl alle unglücklich macht als auch seinen Arbeitgeber viel mehr Geld für vergeudete Entwickler kostet Zeit und Talentbindung, als sie wahrscheinlich erkennen.
Erik Reppen
1
Weil ich den Irrtum des grundlegenden Arguments illustrierte, das im Ego verwurzelt war (im psychologischen Sinne). Es ist keine Frage, wie geschickt er ist. Es ist keine Frage, wie durcheinander der Code ist. Es ist keine Frage, was die Entwicklungsmethodik für ihn tun kann. Es ist eine Frage der Macht. Die Entscheidungsbefugnis in einem Arbeitsverhältnis liegt beim Arbeitgeber. Die einzige Entscheidungsbefugnis eines Mitarbeiters besteht darin, die Beziehung zu kündigen, wenn sie nicht mehr zu ertragen ist.
Peter Lange
1
Ich stimme zu, Scrum ist schlecht für den Umgang mit technischen Schulden. In Bezug auf die ursprüngliche Frage bin ich jedoch anderer Meinung. Er stellte tatsächlich eine Frage zur Beziehung zwischen Arbeitgeber und Arbeitnehmer, erwähnte aber gerade scrum in der Frage. Es ist, als würde ich gefragt: "Wie macht man als Christ eine Enchillada am besten?". Es ist nicht wirklich eine theologische Frage; Es ist eine Frage zum Kochen, auch wenn ich den Fehler gemacht habe, meine religiösen Vorlieben für relevant zu halten.
Peter Lange
1

Ich fühle deinen Schmerz, bin mir aber nicht sicher, was es mit Scrum zu tun hat. Die Entscheidung, ob Code neu geschrieben werden soll, hängt nicht vom Entwicklungsprozess ab.

Nemanja Trifunovic
quelle
Ein Entwicklungsprozess, der verspricht, dass alle zwei Wochen abgeschlossen wird, kann einem seit Jahren ignorierten groß angelegten Refactoring viel im Wege stehen. Das erste, was mir beim Scrum-Training aufgefallen ist, ist die Art und Weise, wie sie sich über das Thema Tech Debt hinwegsetzen. Es ist nicht aufregend zu erklären, dass Ihre App jetzt schlanker und gemeiner ist und Sie die Dinge schneller erledigen können. Unternehmen wollen sichtbare Wertschöpfungen, die sie Freunden und Investoren zeigen können.
Erik Reppen
1

Warte was?

Sie flicken ? Sie sollten umgestalten . Halten Sie sich an agile Werte. Verwenden Sie TDD und geeignete Praktiken und die Situation wird sich irgendwann verbessern.

Falke
quelle