Branchendurchschnitte für die für die Wartung aufgewendete Zeit

Ein Manager kündigte kürzlich an, dass er viel zu viel Zeit damit verbringe, Fehler zu beheben. Ich schätze, er meint, wir sollten die ganze Zeit perfekten Code schreiben (und trotzdem natürlich die unmöglichen Fristen einhalten!), Und ich habe mich gefragt, wie viel Zeit die Branche im Durchschnitt damit verbracht hat, Fehler zu beheben und neuen Code zu schreiben.

Hat jemand Messdaten zur Zeit, die für die Behebung von Fehlern bei der Entwicklung von neuem Code aufgewendet wurde? Oder gibt es eine empirische Analyse der Fehlerbehebungszeit für die gesamte Branche? Sind 50% der Ausgaben für die Fehlerbehebung zu hoch oder ungefähr richtig? Wie wäre es mit 20% oder 33%?

Ich bin froh, anekdotische Beweise aus persönlicher Erfahrung zu akzeptieren, da dies Teil einiger Statistiken sein würde, mit denen ich unsere Leistung vergleichen könnte.

Ein Manager gab kürzlich bekannt, dass er viel zu viel Zeit damit verbringe, Fehler zu beheben.

Oben klingt sehr unwissend. Empfohlene Lektüre für solche Fälle: Fakten und Irrtümer des Software-Engineerings von Robert L. Glass, insbesondere "Fakt 43. Wartung ist eine Lösung, kein Problem."

Wikipedia-Artikel erwähnt 80% Aufwand für die Software-Wartung.

Mein Manager lässt Dilberts PHB wie ein Genie aussehen :)

Ich würde mich auch bemühen, zu analysieren, ob alle Ihre Anfragen tatsächlich Fehler sind .

Nach meiner Erfahrung wurden Anfragen nach Verbesserungen oder neuen Funktionen viel zu oft als Fehler gemeldet. Gute Manager binden ihre Programmierer ein, um das herauszufinden - schlechte Manager beklagen sich immer wieder über zu viel Zeit, um Fehler zu beheben .

Die erste Frage ist, ob Ihre "Fehlerbehebung" tatsächlich Codierungsfehler oder etwas anderes behebt. Die Behebung tatsächlicher Codefehler sollte in den meisten Fällen relativ gering sein, solange Sie eine gute Codebasis haben. Wenn Sie mit einer schlechten Codebasis arbeiten, ist eine umfassende Fehlerbehebung unumgänglich.

Während der Inbetriebnahme eines Programms werden Sie jedoch auf nicht dokumentierte Anforderungen, unerwartete Benutzeraktivitäten, Datenanomalien, Hardware-Inkompatibilitäten, Installationsprobleme und andere Probleme stoßen, bei denen es sich nicht ausschließlich um Codefehler handelt. Manager und Benutzer werden diese Probleme bei der Produktionsunterstützung / -wartung häufig als Fehler ansehen, da sie normalerweise Codeänderungen erfordern.

Ich bin auch auf Manager gestoßen, die das, was als kleinere Erweiterungsanforderungen bezeichnet werden sollte, als Fehler gruppieren. Oft werden diese in ein Bug-Tracking- oder Problem-Reporting-System eingegeben und dies kann Ihre "Bug" -Statistiken höher machen als sie wirklich sind.

Es hängt davon ab, wie viel Code Sie da draußen haben, wie lange es dort draußen war usw.

Die Zeit, die für die Behebung von Fehlern in der Software aufgewendet wird, sollte auf die ersten 6 bis 12 Monate der Veröffentlichung vorgeladen werden. Wenn sich die Zeit jedoch dem Unendlichen nähert, wird die für die Wartung aufgewendete Zeit im Vergleich zu der Zeit, die für die anfängliche Entwicklung aufgewendet wird, mehr als 100% betragen - genau so ist es Arbeit.

Ich habe zwar keine genauen Statistiken (Code Complete, kann aber nicht genau sagen, welche Seite / welcher Abschnitt), aber meiner Erfahrung nach werden ungefähr 40% der Entwicklung (manchmal bis zu 60%) für die Wartung aufgewendet. Es ist offensichtlich, dass Sie umso mehr Wartungszeit haben, je mehr Code Sie freigeben. Fehler sind nicht immer funktionsfähig und sind ebenso eine Folge von Unsicherheiten wie programmatische Fehler.

Wenn Sie einen guten Ticket-Tracker (z. B. Jira von Atlasian) verwenden und Zeit damit verbracht haben, alle verschiedenen Kategorien, User Storys und Dringlichkeitsstufen korrekt und mit Zustimmung Ihrer Teamkollegen einzugeben, berechnen Sie diese Metriken (und mehr). sind erstaunlich einfach.

In einem früheren Projekt haben wir Jira verwendet, um unsere Fehler- / Aufgaben- / Aufgabenlisten zu verwalten, und am Ende hat es uns tatsächlich gezeigt, dass die Hauptursache für Verzögerungen und Probleme in ineffizienten Verwaltungspraktiken lag.

Seltsamerweise wurde uns beim Erscheinen dieser Informationen plötzlich mitgeteilt, dass wir Jira nicht mehr verwenden würden und dass ein neues Produkt eingeführt würde, um es zu ersetzen.

In der Zwischenzeit mussten alle Anfragen nach Daten, die über Jira weitergeleitet werden sollten, an das Management-Team gesendet werden, und unser direkter Zugriff wurde entfernt.

Was nicht bemerkt wurde, war, dass im Rahmen der Statistikberechnung das Entwicklerteam Jira Daten an einen Web-Hook senden ließ. Dieser Web-Hook wurde verwendet, um Daten an einen Endpunkt auf einigen internen Servern weiterzuleiten, auf denen Code erstellt wurde Diese Berichte werden automatisch erstellt.

Wir begannen mit der Überwachung des Web-Hooks und stellten fest, dass Jira, obwohl uns mitgeteilt wurde, dass es nicht mehr verwendet wird, noch eine beträchtliche Zeit (genauer gesagt 6+ Monate) am Leben blieb und der Missbrauch durch das obere Management groß war einfach nur zügellos bei falscher Verwendung.

Natürlich muss es nicht so komplex sein wie Jira.

Wenn Sie eine Lösung mit geringem Ertrag wünschen, können Sie ein Google Docs-Arbeitsblatt und die GDocs-Benachrichtigungs-API verwenden, um Aufgaben, Tickets, Fehler, Funktionsanforderungen usw. zu verfolgen.

GDocs selbst kann jetzt Web-Hooks und alles Mögliche ausgeben.

Wenn Sie das mit Git und / oder Github und einigen Hooks kombinieren, die ausgelöst werden, wenn Code in Ihr Repository geschrieben wird, haben Sie ein einigermaßen effizientes Home-Brew-System, das eine überraschende Datenmenge aufzeichnen kann.

Im Allgemeinen beträgt die Aufteilung zwischen Greenfield-Entwickler und Wartung bei 100% der natürlichen Lebensdauer eines Produkts jedoch im Allgemeinen 20/80. Der größte Teil der Kosten im ALM-Zyklus (Application Lifetime Management) entfällt auf Wartungs- und Supportkosten.

Es gibt keinen Grund, zu viel Zeit damit zu verbringen, Fehler zu beheben, da es einfach nicht möglich ist, fehlerfreien Code zu schreiben.

Gute Test- und kontinuierliche Integrationsrichtlinien verringern das Defizit, aber Sie werden es nie vollständig ausmerzen.

Jeder, der anders glaubt (IMHO), hat nicht genug Wissen, um ein genaues Urteil zu fällen, oder ist blind (der üblichere Fall) dafür, wie schwierig es tatsächlich ist, Software zu schreiben.

Wenn Ihr Vorgesetzter bereit ist, und einige von ihnen, dann möchten Sie vielleicht vorschlagen, dass er Sie für einen Tag beschattet, damit er genau sehen kann, was Sie tun und wie Sie es tun.

Ich habe in einigen Unternehmen gearbeitet, in denen diese Art der Arbeit aktiv gefördert wurde, wobei die Mitarbeiter der oberen Ebene die Mitarbeiter der unteren Ebene beschatteten, und umgekehrt kann dies für beide Beteiligten eine wirklich, wirklich gute Lernerfahrung sein.