Komplexität als Frühindikator für Probleme

Die Kenntnis der Vergangenheit ermöglicht es uns, die Zukunft vorherzusagen, zumindest in bestimmten Bereichen des menschlichen Handelns. Ich bin überzeugt, dass die Softwareentwicklung ein solcher Bereich ist. Das Thema dieses Blogs lautet 'messen = wissen und wissen = vorhersagen'. Durch die Transitivität von Gleichungen können wir also sagen 'messen = vorhersagen'. Aber was sollten wir messen? Ich schlage vor, dass Sie zumindest die folgenden Punkte messen, und werde weiter unten versuchen zu erklären, warum: Trends bei der Verbrennung, Trends bei den Fehlern, Trends bei der Testabdeckung und Trends bei der Komplexität. Trends in Burn Down ist ein Maß für die Anzahl der Story Points, die in einer Iteration implementiert werden (wenn Sie keine Story Points verwenden, können Sie auch ein anderes Maß wie Anwendungsfälle oder Seiten in einem Anforderungsdokument oder was auch immer verwenden, solange Sie über einen längeren Zeitraum messen können und die gemessene Einheit im Laufe der Zeit konstant bleibt). Wenn ein Team eine Zeit lang an einem System arbeitet, wird sich die Anzahl der Story Points in jeder Version tendenziell stabilisieren. Das liegt daran, dass das Team mehr über die Materie des Systems erfährt, die Fähigkeiten der anderen kennenlernt und lernt, wie man Anwendergeschichten in Technologie umsetzt. Wenn Sie also die Anzahl der Story-Punkte pro Iteration gegen die Zeit auftragen, sollten Sie eine horizontale Linie finden. Wenn die Anzahl der Story-Punkte pro Iteration sinkt, stimmt etwas nicht und Sie sollten der Ursache nachgehen. Mehr dazu weiter unten, wenn wir über Komplexität sprechen. Trends in Bugs ist die Anzahl der offenen Bugs in Jira oder Bugzilla. Wenn das Entwicklungsteam Story Points implementiert und Fehler behebt und das Testteam User Stories testet, sollte die Anzahl der gefundenen Fehler die Anzahl der behobenen Fehler ausgleichen. Wenn die Zahl der offenen Bugs steigt, kann das daran liegen, dass die Tester besser (oder mehr) testen und daher mehr Bugs finden. Das ist eigentlich eine gute Sache (denn der Sinn des Testens ist es, Fehler zu finden), auch wenn es bedeutet, dass das Team mehr Arbeit zu erledigen hat. Wenn der Testaufwand gleich bleibt und die Anzahl der Fehler trotzdem steigt und die Geschwindigkeit konstant bleibt, produziert das Team mehr Fehler und wir haben ein potenzielles Problem. Auch dazu weiter unten mehr. Trends bei der Testabdeckung. Die Testabdeckung von Unit-Tests sollte hoch sein (80% oder besser ist unsere Faustregel) und während des Projekts hoch bleiben. Wenn die Testabdeckung sinkt, kann dies auf Schlamperei zurückzuführen sein: Niemand kümmert sich mehr darum und das Schreiben von Tests wird als zusätzliche Arbeit angesehen, so dass es leicht ist, mit dem Schreiben von Tests aufzuhören. Das bedeutet, dass das Team ein Risiko eingeht, das später zu mehr Jira-Problemen führen kann. Aber auch hier kann es eine andere Ursache geben, siehe unten. Bei der Entwicklung der Komplexität geht es um die durchschnittliche Komplexität der Methoden in einem System. Ein allgemein anerkanntes Maß für die Komplexität ist die zyklomatische Komplexität von McCabe. Das tatsächlich verwendete Maß spielt keine Rolle, solange es während des Projekts gleich bleibt. Ich schlage vor, die Komplexität von Klassen als Maß zu verwenden. Wenn ein Projekt zu entgleisen droht, wollen wir das so früh wie möglich wissen. Meine Aussage ist, dass die Komplexität das Maß ist, das wir verfolgen sollten:

1. Wenn die Komplexität zunimmt, wird es schwieriger, neue Funktionen zu implementieren. Das führt zu einer geringeren Geschwindigkeit, aber nicht sofort. Nach einer Weile wird die Geschwindigkeit sinken, weil es länger dauert, neue Funktionen zu implementieren.
2. Komplexer Code weist auch mehr Fehler auf, so dass das Verhältnis zwischen neuen Fehlern und behobenen Fehlern ansteigt. Auch dies wird einige Zeit in Anspruch nehmen, vor allem, wenn die Tests bei einer Veröffentlichung von einem separaten Testteam durchgeführt werden, anstatt von einem Tester, der Teil des Teams ist.
3. Das Schreiben von Unit-Tests für komplexen Code ist schwieriger. Wenn Sie also Schwierigkeiten haben, die Story zu implementieren, weil die Codebasis schwer zu verstehen ist, ist das Schreiben von Unit-Tests möglicherweise die erste Aktivität, die fallen gelassen wird. Zunächst wird die Testabdeckung gleich bleiben, aber wenn es schwieriger wird, Tests zu schreiben, weil die Komplexität zunimmt, wird die Abdeckung sinken.

Die Messung, die Sie beobachten sollten, ist also die Komplexität, wie sie sich im Laufe der Zeit entwickelt. Eine ausgezeichnete Möglichkeit, dies zu tun, ist die Installation von Sonar (https://www.sonarsource.org/) und das Hinzufügen zum Maven-Build auf Ihrem Build-Server. Die anderen Messgrößen (Burndown, Bugs und Testabdeckung) sind für sich genommen interessant und dienen als unterstützende Beweise, daher schlage ich vor, auch sie zu messen und sie gegen die Zeit aufzuzeichnen.