Welche Zeit sollte für Fehler gegen die ursprüngliche Entwicklung aufgewendet werden? [abgeschlossen
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Diese Frage ist ein wenig abstrakt, aber ich hoffe, dass mich jemand in die richtige Richtung verweisen kann.
Meine Frage ist, wie viel Zeit Sie erwarten können, um den Fehler eines Softwareprojekts in Bezug auf die ursprüngliche Entwicklungszeit zu widmen. Mir ist klar, dass es eine große Anzahl von bestimmenden Faktoren gibt, die eingehen, aber ich hatte auf einen typischen oder durchschnittlichen Zusammenbruch gehofft.
Wenn das Projekt A beispielsweise 40 Stunden dauert und zusätzliche 10 Fixierfehler dauert, hätte dieses Projekt ein Verhältnis von 4: 1.
Wenn ein weiteres Projekt (b) 10 Stunden dauert, aber weitere 8 bei Fehler, dann hätte es ein Verhältnis von 5: 4.
Ist dies ein dokumentiertes/recherchiertes Konzept?
AKTUALISIEREN
Vielen Dank für alle informativen Antworten. Ich verstehe, dass es aufgrund aller beteiligten Variablen und Umgebungsfaktoren unmöglich ist, diese Art von Metrik zu stecken. Bevor ich eine Antwort zugewiesen habe, würde ich gerne wissen, ob diese Metrik einen vereinbarten Namen hat, damit ich weitere Nachforschungen anstellen kann. Ich möchte einen Punkt erreichen, an dem ich die Messungen verstehen kann, die erforderlich sind, um die Metriken selbst zu erzeugen, und schließlich einen Grundlinienstandard für mein Projekt zu finden.
Lösung
Der Gleichgewichtsprozentsatz der Gesamtkapazität, die dem Defektfixieren zugewiesen ist Defekteinspritzrate.
Viele Faktoren können diese Rate natürlich beeinflussen: Welche Art von Produkt entwickelt das Team, welche Technologien und technischen Praktiken sie verwenden, das Fähigkeitsniveau des Teams, die Unternehmenskultur usw.
Wenn man das Team B in Betracht zieht, werden durchschnittlich 8 Einheiten von Nacharbeit pro 10 Einheiten von Arbeiten erstellt, die sie abschließen, und das Arbeiten dieser 8 Einheiten schafft neue 6,4 -Arbeitseinheiten. Wir können die Gesamtaufwand schätzen, die sie schließlich als Summe eines geometrischen Fortschritts ausgeben müssen:
10 + 8 + 6.4 + 5.12 + ...
Die Anzahl der Fehler wird mit der Zeit exponentiell abnehmen, aber Team B hat einen solchen Koeffizienten in ihrem Exponenten, dass es sehr langsam auf Null dauert. Tatsächlich beträgt die Summe der ersten drei Begriffe in der obigen Serie nur 24,4; der ersten fünf, 33,6; der ersten 10, 45; der gesamten Serie 50. SO, Team B Zusammenfassung: Defekt -Injektionsrate, 0,8; Feature -Entwicklung 10/50 = 20%; Defektfixierung, 80%. 20/80 ist ihre nachhaltige Kapazitätszuweisung.
Im Gegensatz dazu ist Team A in viel besserer Form. Ihr Fortschritt sieht so aus:
40 + 10 + 2.5 + 0.625 + ...
Die Summe dieser Serie beträgt 53 1/3 .
Tatsächlich sind alle Begriffe in der Serie von Team A nach den ersten drei vernachlässigbar klein. Dies bedeutet praktisch, dass das Team A wahrscheinlich alle Fehler mit ein paar Wartungsveröffentlichungen zerquetschen kann, wobei die zweite Veröffentlichung im Umfang ziemlich klein ist. Dies schafft auch eine Illusion, die irgendein Das Team kann das tun. Aber nicht Team B.
Ich dachte über diese Äquivalenz beim Lesen nach David Andersons neues Buch "Kanban". (Das Buch befasst sich mit einem anderen Thema, befasst sich jedoch auch mit Qualitätsbedenken.) Bei der Diskussion von Softwarequalität, Anderson Quotes Dieses Buch von Capers Jones, "Software -Bewertungen, Benchmarks und Best Practices":
"... im Jahr 2000 ... gemessene Softwarequalität für nordamerikanische Teams ... reichte von 6 Defekten pro Funktionspunkt bis weniger als 3 pro 100 Funktionspunkte, ein Bereich von 200 bis 1. Der Mittelpunkt beträgt ungefähr 1 Defekt pro 0,6 bis 1,0 Funktionspunkte. Dies impliziert, dass es für Teams üblich ist, mehr als 90 Prozent ihrer Aufwand für Fixfehler auszugeben."Er zitiert ein Beispiel, das von einem seiner Kollegen eines Unternehmens bereitgestellt wird, das 90% der Zeit damit verbringt, ihre Fehler zu beheben.
Die fließende Sprachausstattung, mit der Anderson von der Defekt-Injektionsrate zur Deftext-Fixing-Kapazitätszuweisung geht (Versagensnachfrage ist der Begriff dafür) legt nahe, dass die Äquivalenz der beiden Dinge den Forschern von Softwarequalität bekannt ist und wahrscheinlich seit einiger Zeit bekannt ist.
Die Schlüsselwörter in der Argumentation, die ich hier präsentieren möchte, sind "Equlibrium" und "nachhaltig". Wenn wir die Nachhaltigkeit wegnehmen, gibt es eine offensichtliche Möglichkeit, diese Zahlen zu betrügen: Sie führen die erste Codierung durch, dann gehen Sie an einen anderen Ort und überlassen Sie die Wartung anderen. Oder Sie steigen die technische Schulden und entladen sie für einen neuen Eigentümer.
Offensichtlich entspricht keine bestimmte Zuordnung für alle Teams. Wenn wir festgelegt haben, dass 20% für Fehler ausgegeben werden müssen, wird es einfach nicht genügend Fehler haben, um die Zeit zu füllen, und wenn ein Team eine sehr hohe Rate hatte, hat es einfach nicht genügend Fehler wird sich weiter ansammeln.
Die Mathematik, die ich hier verwendet habe, ist viel vereinfacht. Ich habe Dinge wie Transaktionskosten (Planungs- und Schätzungstreffen, Post-Mortems usw.) vernachlässigt, die die Prozentsätze etwas beeinflussen würden. Ich habe auch Gleichungen weggelassen, die ein Produkt aufrechterhalten und ein anderes gleichzeitig entwickelt haben. Aber die Schlussfolgerung steht immer noch. Tun Sie das, was Sie in Bezug auf technische Praktiken wie Einheiten-Tests, kontinuierliche Integration, Code-Bewertungen usw. können, um Ihre Defekt-Einspritzrate und folglich Ihre Ausfallnachfrage zu senken. Wenn Sie nur einen Fehler für alle 10 Funktionen erstellen können, haben Sie viel Freizeit, um neue Funktionen zu entwickeln und Ihre Kunden zufrieden zu stellen.
Andere Tipps
Leider glaube ich, dass dieses Verhältnis in einem bestimmten Projekt sehr unterschiedlich ist. Es wird drastisch von Ihrer Umgebung, Sprache, Tools, Teamgröße und Erfahrung beeinflusst.
Sie sollten nur Zeit für einen Fehler verbringen, wenn das, was Sie vom Fix erhalten, von dem, was Sie investieren, größer ist.
Verwenden Sie eine Matrix wie die folgende (horizontale - Zeit, die zum Behebung des Fehlers, der vertikale Fehlertyp - Auswirkungen auf Benutzer erforderlich ist).
| Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix | Fix
Beispiel für Probleme:
| Few hours | Many hours
--------------+--------------------------------------+---------------------------------
| Window moves 1px every 10 | Windows is painted incorrectly
Minor problem | times when you open the application. | every 100th time the app is open.
| Fix is: handle window resize event | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening | Poor performance when >100 users
| SQL connection. | are connected (unusable app)
| Fix: Fix invalid query + add nice | Fix: change architecture + DB
| message |
Die Matrix kann komplexer mit unterschiedlichem Schweregrad, Aufwand, Risiken usw.
Sie können sogar einen Rang für jeden Fehler erstellen und diese basierend auf dem Ranking beheben. Etwas wie:
Bug priority = Risk x Severity x Effort
*Könnte (1-x) für einige Operanden sein, je nachdem, welche Skala Sie wählen :)
Um Ihre Frage zu beantworten: Hängt von der Art der Fehler, der verfügbaren Zeit/des Budgets usw. ab.
Es ist nicht nur (natürlich) in Bezug Ich werde verwenden.
In einem Wasserfallmodell können Sie beispielsweise genau den ersten Fehler in der ersten Testphase festlegen, aber in einer agilen Umgebung kann es schwierig sein, eine Linie zu erheben, in der es sich um "von hier aus korrigieren wir Fehler", da sich die Funktionen ändern können (sich ändern können (sich ändern können (sich Und für mich ist es nicht fair, eine Feature -Änderung als Fehler zu zählen)
Aus Erfahrung sage ich, dass es etwas ist, das immer unterschätzt wird und sehr leicht die gleiche Anzahl von Stunden verbringen kann wie das "Originalprojekt".
Die wirklich korrekte Antwort wäre null Stunden bei Fehlerbehebungen, da Ihr Code perfekt ist. :-)
Realistisch gesehen kann ich nicht sagen, dass ich jemals jemanden gehört oder diese Art von Verhältnis anbietet. Das heißt nicht, dass einige Unternehmen nicht die Zeit für Entwicklung und Wartung verfolgen. Die Entwicklung einer Anwendung ist jedoch ein so kurzer Zeitrahmen im Vergleich zu der Wartung, dass die meisten Unternehmen dieses Verhältnis nicht berechnen. Sie sind wahrscheinlich mehr besorgt darüber zu lernen, warum eine App Wartung und Anwendung dieser Ergebnisse auf neue Anwendungen erfordert.
Zu breite Kriterien für einen Fehler kann Ihre Zeit fast verdoppeln. Ein übereifriger Manager, der die Anfrage eines Kunden, einen Knopf größer zu machen (Mausprobleme), ist eine großartige Möglichkeit, die Anzahl der von uns behobenen Fehler zu erhöhen. Die Behebung wird nur wenige Sekunden dauern, da es nicht erforderlich ist, einen Patch zu berücksichtigen, zu testen, neu zu kompilieren und zu verteilen. Oh, und es wird als neues Feature doppelt bezeichnet.
Der größte entscheidende Faktor dafür ist, ob Sie mit einer neuen oder einer vorhandenen Technologie arbeiten. Wenn Sie mit etwas Neuem zusammenarbeiten und etwas entwickeln, das unter verschiedenen Umständen einige Male nicht getan wurde oder einige Male getan wurde, werden Sie viel Zeit mit Bugfixes verbringen und Ihr Projekt so wie Sie wollen, . Häufig sind Fehler das Ergebnis der Arbeit in eine Ecke, und Sie müssen erhebliche Mengen an Arbeit leisten, um das zu umstrukturieren, was Sie getan haben. Darüber hinaus resultieren viele Fehler aus einem unvollständigen Verständnis der Erwartungen der Benutzer und der Unkenntnis des Entwicklers bei Randfällen.
Wenn Sie an einer etablierten Technologie arbeiten, wurden die meisten Probleme von den Bibliotheken oder von Praktiken in der Community behandelt, und Sie sollten in der Lage sein, Google zu kaufen, zu kaufen oder sich aus den Fehlern zu fragen, auf die Sie begegnen.
Bei kritischer Sofware ist ein Verhältnis von 1: 1 nicht ungewöhnlich. Allein für Unit -Tests habe ich Indikatoren gesehen, die 1 Tag in Einheiten -Tests für alle 10 Codezeilen erwähnt haben.
ich denke, dass Diese Frage ist verzerrt: Sie startet aus der Voraussetzung, dass die Korrektur von Fehler eine Phase ist, die ähnlich ist als die Entwicklung neuer Funktionen. Das ist nicht der Fall.
Ein guter Entwickler wird nicht viel Zeit damit verbringen, den Code zu debuggen, da sein Code von Anfang an fehlerfrei ist. Ein schlechter Entwickler wird viel Zeit damit verbringen, seinen Code zu debuggen, weil er keine geeigneten Abstraktionen erstellen kann, um echte Probleme zu lösen.
Beachten Sie, dass Entwickler ihren eigenen Code selbst testen sollten. Es ist ihre Arbeitsplatzverantwortung, fehlerfreien Code zu liefern. Es ist also schwierig, das Codieren vom Debuggen zu trennen.
Es ist auch eine Frage der Priorität. Bei der Entwicklung hängt die Zeit, die für die Korrektur eines Fehlers erforderlich ist, exponentiell mit der Zeit, die seit dem Moment, in dem Sie den Fehler in den Code eingefügt haben, exponentiell zusammenhängen. Die Korrektur von Bugs sollte daher von größerer Priorität sein als die Entwicklung neuer Funktionen.
Anstatt über "Zeit für Fehler aufgewendet" zu sprechen, sollten Sie über "Zeit für Tests" sprechen (Integrationstests, Benutzerakzeptanztests ...).
Ich denke, Sie haben Recht - Sie werden aufgrund der Anzahl der Einflussfaktoren keine sinnvolle Metrik erhalten.
Wenn es hilft, kann ich Ihnen Projekte sagen, an denen ich arbeite (Unternehmensraum, große komplexe Systeme, viel Integration zu anderen Systemen), haben ein Verhältnis von ca. 3: 2. Die meisten davon sind keine Fehler mit dem Code - normalerweise Fehler mit den Schnittstellen. Zum Beispiel sprechen System A und B über die Schnittstelle X miteinander. Die Entwickler von System A interpretieren Schnittstelle X geringfügig anders als die Entwickler von System B. Comedy folgt.
Eine Beobachtung ist, dass die Entwicklung von Code und Test-/Fehlerbehebung von Code nicht zwei unterschiedliche Phasen sein sollte. Wenn Sie testen, während Sie die "Kosten" der Fehlerbehebung entwickeln, ist geringer.
Ich nehme eine rein praktische Sichtweise ein: Was behindert den praktischen Nutzen des Projekts mehr? Wenn es sich um Fehler in der vorhandenen Funktionalität handelt, sollten Sie Fehler beheben. Wenn es fehlt, sollten Sie die originelle Entwicklung durchführen. Gehen Sie dann zurück und beheben Sie die Fehler, sobald die schwersten fehlenden Funktionen implementiert sind. Dies erfordert Vertrautheit mit Ihren Anwendungsfällen. Ein Fehler, der das Programm in einem seltsamen Eckfall abstürzt, kann eine geringere Priorität haben als geringfügige Usability -Verbesserungen, die alle betreffen. Ein kleiner Ärger Fehler in der am häufigsten verwendeten Funktionalität kann wichtiger sein als eine Funktion, die nur Menschen zugute kommt, die Ihre Software an die Extreme drücken.
