(
c )
Fast seit dem Aufkommen der Technologiebranche ist sie auf der Suche nach dem „Weißen Wal“ - den Arbeitsmetriken der Entwickler. Vielleicht entsprang der Wunsch, KPI-Programmierer zu zählen, einem im traditionellen Geschäftsleben üblichen Satz: „Sie können nicht planen, wenn Sie nicht messen können.“
Nach den Hunderten von verschiedenen KPIs, die die Programmierer zu umgehen versuchten, erschienen viele verschiedene Methoden zur Analyse von Betriebsdaten - von der Verfolgung der Blickrichtung auf den Monitor bis hin zu Scrum und Kanban. Messungen der Arbeitsqualität haben in vielen Branchen so gut funktioniert, dass es logisch erschien, diese Erfahrung auf die Softwareentwicklung zu übertragen. Das Ergebnis war entmutigend.
Das Messen und Verwalten der Entwicklerproduktivität hat nicht zu einem einzigen internationalen Qualitätsstandard geführt. High-Tech-IT-Unternehmen entwickeln ihre eigenen Kennzahlen. Einige von ihnen lassen sich kaum mit herkömmlichen KPIs in anderen Tätigkeitsbereichen vergleichen.
In diesem Artikel werden wir über die interessantesten aktuellen Metriken und über die "Metriken" in der IT sprechen.
Es ist bereits schwierig, (zumindest in offenen Quellen) Informationen über die Anzahl der geleisteten Arbeitsstunden, die Anzahl der Zeilen im Quellcode (SLOC), Funktionspunkte oder die Anzahl der von jedem Entwickler als Metrik erstellten Fehler zu finden.
Im öffentlichen Diskurs konnte ein Konsens erzielt werden, dass mehr arbeiten
nicht besser bedeutet, dass eine Lösung mit 200 Codezeilen schneller oder produktiver sein kann als eine Lösung mit 1000 Zeilen, und die 1979 erstellte Metrik Function Points ist hoffnungslos veraltet.
Aber was ist aus dem Wunsch geworden, alles zu messen und zu berechnen? Anscheinend ist es nicht verschwunden.
Netflix
(
c )
Netflix konzentrierte sich darauf, die Barrieren zu überwinden, die Benutzer von Inhalten trennen. Jedes Mal, wenn etwas Sie daran hindert, die nächste Episode Ihrer Lieblingsserie anzusehen, beheben die Entwickler das Problem und messen die Zeit, die zur Lösung benötigt wurde.
Die Streaming-Plattform testet neue Ideen real und misst die statistisch signifikanten Unterschiede in der Benutzerinteraktion mit dem Produkt. Darüber hinaus sind Fehler beim Testen von Hypothesen durchaus akzeptabel. "Der einzige wirkliche Fehler, der in Netflix inakzeptabel ist, ist die Unfähigkeit zur Innovation."
Die Produktentwicklung bei Netflix beginnt mit einer Hypothese, die ungefähr so aussieht:
Algorithmus / Funktion / Design (×) erhöhen die Interaktion der Abonnenten mit dem Dienst und letztendlich deren Beibehaltung.
Die Hypothese könnte darin bestehen, die Relevanz von Suchergebnissen zu erhöhen, ein neues Design für Benutzeroberflächen oder eine neue Funktion zu verwenden - beispielsweise den Teilnehmern zu zeigen, wie ihre Freunde aus sozialen Netzwerken Netflix betrachten. Die Intuition und die Vorstellung, wie Abonnenten besser mit Diensten versorgt werden können, werden zur Grundlage des Entwicklungsansatzes.
Der zweite Entwicklungsschritt besteht darin, einen Test zu schreiben, der die Auswirkung der Hypothese misst. Manchmal bedeutet dies, dass Sie sofort einen Prototyp erstellen können, der das Wesentliche des Konzepts widerspiegelt. Auf diese Weise können Sie die Hypothese schnell testen und nach einer besseren Lösung streben.
Der dritte Schritt ist der Test selbst, an dem Hunderttausende von Zuschauern teilnehmen können. Der Prototyp wird für einen bestimmten Zeitraum für die Versuchsteilnehmer bereitgestellt. Er kann zwei Kohorten zum Testen haben oder 20, von denen jede einen anderen Ansatz verwendet oder verschiedene neue Elemente mischt. Dutzende verschiedener Verbrauchertests können jederzeit gestartet werden.
Auch ein Scheitern der Hypothese gilt als erreichtes Ergebnis. Folglich steigt die Wahrscheinlichkeit, dass sich die folgende Hypothese als besser herausstellt, nur an. Das Entwicklungsteam hat über einen langen Zeitraum große Freiheit, Ideen auf das Produkt anzuwenden.
Ibm
(
c )
Die älteste und naheliegendste Messgröße für die Softwareentwicklung ist die Anzahl der Zeilen, die von einem einzelnen Entwickler oder Team erstellt wurden, und die dafür aufgewendete Zeit. Diese Metrik wurde erstmals von IBM verwendet. In dem Dokumentarfilm Triumph der Nerds: Der Aufstieg zufälliger Imperien stellte Steve Ballmer fest, dass IBM in den 1980er Jahren die Religion zu diesem Indikator gemacht zu haben scheint.
2011 führte IBM
ein Tool
ein , mit dem Quellcode automatisch auf Leistung, Sicherheit und technische Komplexität hin analysiert werden kann. Die Entwickler, deren Code am höchsten bewertet wurde, erhielten die höchste Punktzahl vom System. Niedrige Leistungsindikatoren dienten als Signal zur Beachtung der Mitarbeiterschulung (IBM gab an, dass eine niedrige Endpunktzahl nicht als Bestrafung herangezogen wurde).
Spätere
Veröffentlichungen erwecken jedoch den Eindruck eines Paradigmenwechsels - die Methodik zur Konstruktion von Hypothesen wird bereits im Mittelpunkt der Entwicklung genannt. Die hypothetische Entwicklung kann nicht ohne Zeit- und Ressourcenverlust auskommen.
Die Hauptsache in dieser Metrik ist das Kundenfeedback zum Produkt. Wir müssen uns auf das konzentrieren, was für Kunden am wichtigsten ist, und Funktionen aufgeben, die nicht vorteilhaft sind oder die Benutzer sogar stören. Diese Strategie ist im obigen Diagramm dargestellt.
Spacex
(
c )
Über die Arbeit der Entwickler in SpaceX gibt es nur sehr wenige Informationen, was mit der allgemeinen Geheimhaltung der Projekte dieses nicht öffentlichen Unternehmens zusammenhängt.
Indirekten Informationen zufolge können Sie jedoch die ungefähren Umrisse des Gesamtbildes verstehen. Und dieses Bild spricht von der Wichtigkeit von Tests.
In der Raketenwissenschaft sind Tests die Grundlage des Designs. In der Programmiersoftware für Raketen werden
dieselben Prinzipien verwendet . Wenn die Rakete beispielsweise sicher gelandet ist, haben alle für die Entwicklung verantwortlichen Teams den KPI vervollständigt. Ohne Vorversuche ist es nicht möglich, ein solches Projekt erfolgreich abzuschließen.
Angesichts der Probleme, mit denen Teams konfrontiert sind, wenn es darum geht, Geräte für die raue Weltraumumgebung vorzubereiten, ist es nicht schwer zu verstehen, welche Verantwortung bei ihnen liegt.
SpaceX
versucht, Code zwischen verschiedenen Projekten
zu parallelisieren - mit diesem Entwicklungsparadigma erstreckt sich die Fehlerkorrektur für ein Projekt (relativ gesehen, Raketen) automatisch auf andere Projekte.
Das Unternehmen wählte C ++ als Hauptprogrammiersprache. Erstens können Sie so viele hochkarätige Entwickler einstellen, da die Sprache immer noch relativ beliebt ist. Gleichzeitig wird die Wahl häufig zugunsten von Spieleentwicklern getroffen, die es gewohnt sind, Code zu schreiben und in Umgebungen mit begrenztem Arbeitsspeicher und begrenzter Rechenleistung zu arbeiten.
Zum anderen profitieren sie vom großen C ++ - Ökosystem. Es ist nicht erforderlich, spezielle Software zu erstellen, wenn Sie altbekannte Tools wie gcc und gdb verwenden können.
Und schließlich wird bei der Entwicklung großen Wert auf das Testen von Metriken gelegt. Entwicklern und Ingenieuren wird geraten, alles, was Sie sich vorstellen können, auf Sicherheit und Fehlertoleranz zu überprüfen.
Die während der Tests gesammelten Daten werden zusammen mit dem Quellcode gespeichert, der während der Tests funktioniert hat. Wenn während des Raketentests eine Fehlfunktion auftritt, kann SpaceX die genaue Startumgebung neu erstellen, das Problem reproduzieren und beheben.
Die kontinuierliche Integration wird verwendet, um den gesamten Code automatisch zu testen. Sie verfügen sogar über Prüfstände mit allen Motorkomponenten, um das Starten vollständig zu simulieren und potenzielle Probleme zu erkennen.
Amazon
Amazon hat eine der interessantesten Strategien, die in diesem 40-minütigen Interview mit dem Direktor der AWS Developer Tools vorgestellt wurden.
Die Schlüsselidee bei der Bildung von Entwicklungsteams ist die mitotische Skalierung. Die Teams werden in kleinere Gruppen aufgeteilt, wodurch die Kontinuität und die Funktionen der "Mutter" -Teams voll erhalten bleiben.
Jeff Bezos, CEO von AWS Developer Tools, ist der
Ansicht, dass ein ideales Team nicht mehr Personen umfassen sollte, als zwei Pizzen füllen können.
In kleinen Teams ist die Kommunikation viel effektiver, sie bleiben dezentral, unabhängig, entwickeln sich schneller und führen Innovationen ein.
Amazon hatte ursprünglich eine monolithische und Software-Architektur (Perl / Mason / C ++). Dann wurde die Architektur in Services und die Organisationsstruktur in Pizzateams zerlegt. So wurde der Cloud-Dienst Amazon Elastic Compute Cloud (Amazon EC2) von einer Gruppe bestehend aus nur zwei „Pizzateams“ gebildet.
Amazon ist bestrebt, alle Prozesse (Erstellen, Bereitstellen, Übertragen usw.) vollständig zu automatisieren. In jeder Bereitstellung werden verschiedene Testarten verwendet: Integration, Browser, Web und Laden. So wird alles kontrolliert und gemessen.
Die Sicherheit wird während des gesamten Produktstarts überwacht. Daher ist es für Amazon völlig normal, in jeder Amazon-Kultur „wie ein Sicherheitsingenieur zu denken“. Wenn Entwickler ein neues Projekt starten, arbeiten sie hauptsächlich an der Architektur und dem Bedrohungsmodell.
Über eine Kombination aus lokalen und globalen Vertrauensrichtlinien werden Validierungen in alle Pipelines integriert. Der Leiter kann die Überwachungsrichtlinie für sein Team unabhängig festlegen (z. B. sollte jedes neue Commit vor der Bereitstellung zu 70% durch Komponententests abgedeckt werden).
Gleichzeitig gelten für jede Bereitstellung allgemeine Amazon-Regeln (z. B. ein Verbot der einmaligen Bereitstellung in jeder Region).
Es sind die Entwickler im Team und nicht der Architekt, die für die Architektur des Projekts verantwortlich sind. Und nur dann wird es von einem Architekten oder Chefingenieur in Betracht gezogen. Die gleiche Situation bei Sicherheit und Tests: Das Team verwaltet den gesamten Prozess. Dieser Ansatz hat zwar ein Minus, das in einer langen Einarbeitungszeit besteht.
Jedes Jahr erstellen die Teams auf sechs Seiten einen Betriebsplan (solche "Geschäftspläne" werden auf allen Ebenen von Amazon vorgestellt). Der Plan gibt an, was im nächsten Jahr mit festen Mitteln erreicht werden soll und was mit zusätzlichen Mitteln erreicht werden kann. Manager sammeln sechsseitige Dokumente von allen von ihnen verwalteten Teams, erstellen ihre eigenen sechsseitigen Dokumente und reichen sie an ihre Geschäftsleitung weiter - und so weiter bis zu Jeff Bezos. In umgekehrter Richtung werden die Ressourcen den Teams zugewiesen.
Was haben Startups dort?
Dank Umfragen,
die von Stackify (einer Cloud-Plattform zur Überwachung und Fehlerbehebung von Webanwendungen) durchgeführt wurden, war es möglich, die Einstellung zu Metriken bei einigen bekannten Start-ups und Unternehmen der "mittleren Hand" herauszufinden.
CircleCI ist ein in Russland beliebter Continuous Integration-Dienst mit flexiblen Einstellungen für Web- und mobile Anwendungen. Rob Zuber, CTO CircleCI, ist der Ansicht, dass die beste Messgröße zur Messung der Produktivität und Effektivität der Softwareentwicklung ein Maß für die Zeit ist, die der Code benötigt, um vom Commit zum Deployment überzugehen - Commit-to-Deploy Time (CDT).
Das Ziel der CDT-Messung besteht darin, Hemmnisse für die Bereitstellung „aufzuspüren“. Wenn Sie Automatisierung und / oder Tests von guter Qualität verwenden, können Sie im Idealfall innerhalb von Minuten (oder sogar Sekunden) zur Bereitstellung eines Mikroservices wechseln. Wenn Sie hauptsächlich den manuellen Qualitätskontrollprozess verwenden, bedeutet dies wahrscheinlich, dass die Bereitstellung länger dauert.
Die CDT-Analyse von CircleCI zeigt, wo Verbesserungsmöglichkeiten bestehen. Verbesserungen können technischer (z. B. effektivere Tests), prozessorientierter oder eine Kombination aus beiden sein. Je kleiner Ihre Commits sind, desto schneller können sie gestartet werden bzw. desto schneller können Sie die Situation beheben, wenn etwas schief geht.
Adeva ist ein Rekrutierungsunternehmen und bildet vorgefertigte Entwicklungsteams für Startups. Um den Kunden einen besseren Service zu bieten, forscht sie seit mehreren Jahren nach Leistungsmetriken für Programmierer. Die Schlussfolgerung ist einfach: Es gibt keine formale und objektive Messung der Wirksamkeit und Produktivität der Softwareentwicklung.
Anstatt KPI zu verwenden, organisiert Adeva kurze Besprechungen mit Entwicklern, bei denen das Management sorgfältig Geschichten über Erfolge und Misserfolge abhört. Um die Effektivität der gesamten Abteilung zu bestimmen, werden den Entwicklern Fragen zum Nutzen und zum Bewusstsein des restlichen Teams gestellt. Bei diesen Meetings kann jeder Ideen äußern, die sowohl sich selbst als auch anderen Teammitgliedern helfen könnten.
Neben der zwischenmenschlichen Kommunikation untersucht Adeva, wie sich der Entwicklercode in die Codebasis integriert, prüft seine Leistung und Sicherheit und stellt fest, ob der Code auf lange Sicht niedrigere Servicekosten verursacht.
Scorchsoft, ein englischer Web- und Mobile-App-Entwickler, schätzt die Projektlaufzeiten. Da die meisten Scorchsoft-Kunden ein Produkt zu einem festen Preis erwarten, sollte das Unternehmen sofort eine klare, eindeutige Spezifikation identifizieren. Die Leistung wird anhand der Entwicklungszeit gemessen, die auf den Tools Toggl (Zeiterfassung) und Jira basiert.
Ein Projekt gilt als erfolgreich, wenn der Kunde zufrieden ist und das Team die Frist einhält.
Fazit
Manchmal können Sie bei der Auswertung von Metriken immer noch zu einem gemeinsamen Nenner kommen - dies ist ein Schwerpunkt auf den Benutzerkomfort. Anstatt zu versuchen, die Produktivität des Programmierers direkt zu messen, liegt der Fokus darauf, alles zu messen, was den Fortschritt bei der Wertschöpfung für den Kunden behindert.
Wenn der Endkunde der Hauptindikator für den Erfolg ist, ist es viel einfacher, Kennzahlen zu verwenden, die aus dem Marketing stammen: Conversion-Rate, Nutzerverhalten oder Bewertungen. In diesem Bereich hängt der Erfolg in hohem Maße vom Management ab, das möglicherweise die falsche Entscheidung trifft. Beispielsweise wirkt sich die Entwicklung einer Funktion, die für den Kunden nicht erforderlich ist, viel negativer auf das Geschäft aus als ein Entwickler, der sich von „Standards“ abhebt.