Copilot Evaluierung bei der Telekom

Hebt KI die Software-Entwicklung auf ein neues Level? Sind EntwicklerInnen mit KI Support schneller als ohne? Diesen Fragen stellen wir uns bei der Deutschen Telekom IT GmbH. Dazu führten mein Team und ich eine Evaluierung von GitHub Copilot durch. Ich stelle euch hier die Ergebnisse und Meinungen des Teams vor.

Warum Copilot?

Copilot integriert sich in die Entwicklungsumgebung der Programmierenden. Es analysiert den vorhandenen Sourcecode und macht mittels KI unterstützter Text-Completion Vorschläge für weiteren Code. Diesen können die ProgrammiererInnen per Tastendruck übernehmen. Das beschleunigt insbesondere das Schreiben von sich wiederholendem Code.

Copilot in der Praxis

ChatGPT hilft EntwicklerInnen bei technischen Fragestellungen. Dazu unterbrechen wir das Schreiben von Code in der IDE, öffnen im Browser die Chat-KI und stellen unsere Frage oder Anforderung. Mit der Antwort von ChatGPT wechseln wir in die IDE und probieren sie aus. Im Unterschied zu ChatGPT unterstützt Copilot die Entwickelnden direkt beim Schreiben von Code in der IDE. Ich sehe die beiden KI Tools nicht als Konkurrenten sondern als Werkzeuge für unterschiedliche Zwecke. Mehr zu ChatGPT für EntwicklerInnen findet Ihr hier: chatgpt-coding.html 

Ziel und Rahmen der Copilot Evaluierung

Vor der konzernweiten Einführung eines neuen, kostenpflichtigen Tool findet meist eine Evaluierung statt. Konkret war das Ziel im Evaluierungsteam herauszufinden, ob die tägliche Arbeit in der Software-Entwicklung beschleunigt wird und wenn ja, um wie viel.

Ich selbst bin Software Entwickler und Architekt im Scrum-Team Asteroid. Das Asteroid Team baut Microservices und Self-Contained Systems als Teil des Geschäftskunden-Portal der Deutschen Telekom. Im Sinne von DevOps ist unser Team sowohl für die Entwicklung als auch für den Betrieb unserer Systeme verantwortlich. Den Schwerpunkt unser täglichen Arbeit bildet aber die Entwicklung. Unser Technologie-Stack besteht im wesentlichen aus Java, Spring und Vue.js. Als Entwicklungsumgebung verwenden wir größtenteils IntelliJ.

Durchführung der Evaluierung

Als Scrum-Team schätzen wir den Aufwand jeder UserStory bevor wir sie bearbeiten. Vor der Evaluierung hatte unser Team bereits 25 zweiwöchige Sprints abgeschlossen.
Zu jedem Sprint erfassten wir folgende Daten:

• Entwicklungskapazität: Wie viele Story Points kann das Team wahrscheinlich im kommenden Sprint abschließen.
• Burndown-Charts: Wie viele Story Points hat das Team im vergangenen Sprint tatsächlich abgeschlossen.
• Anzahl der Software-EntwicklerInnen im jeweiligen Sprint. Die Größe unseres Teams hatte sich in den 25 Sprints verändert, z. B. durch Fluktuation, Neueinstellungen, Urlaube oder Schulungen.

Zu Beginn des 26. Sprints erhielten alle EntwicklerInnen die Copilot-Lizenz und installierten das Plugin innerhalb eines Tages in ihrer IDE. Da wir eine 30-tägige Evaluierungs-Lizenz hatten, konnten wir Copilot in 2 kompletten Sprints verwenden.

8 von 9 EntwicklerInnen machten in unserem Team bei der Copilot Evaluierung mit. 1 Entwickler entschied sich dagegen, da er Copilot bzw. GitHub hinsichtlich der Daten-Sicherheit misstraute.

Ergebnisse durch Scrum-Metriken

Unser ScrumMaster lieferte die folgenden Mess-Ergebnisse:

• Im ersten Sprint mit Copilot erreichten wir 38 Story Points.
• Im zweiten Spint mit Copilot erreichten wir 28 Story Points.
• Der Durchschnittswert an Story Points in den 25 vorherigen Sprints ist 23.
• Beide Copilot Sprints waren also überdurchschnittlich erfolgreich.
• Die Top 5 Sprints vor Copilot hatten als Ergebnis 48, 40, 37, 34 und 33 Story Points.
• Der erste Copilot Sprint war also unser drittbester Sprint von insgesamt 27 Sprints.

Aus Evaluierungssicht hatten wir Seiteneffekte in beiden Sprints, so dass die zuvor genannten Ergebnisse leider relativiert werden müssen:

• Verglichen mit den vorherigen Sprints hatte das Asteroid Team mehr Entwickelnde in der Evaluierungs-Phase als zuvor. Mit den vorhandenen Daten könnten wir die Story Points jedes Sprints ins Verhältnis zur Anzahl der Entwickelnden setzen. Da neue EntwicklerInnen aber Einarbeitungszeit benötigen, lässt sich dieser Seiteneffekt trotzdem nicht ganz eliminieren.
• Ein weiteres Rauschen war die Bearbeitung von Bugs und anderen operativen Tasks. Den Aufwand dafür messen wir nicht in Story Points. In den beiden Evaluierungs-Sprints hatten wir relative wenige Bugs, während wir in den vorherigen Sprint durch einen großen Go-Live relativ viel ungeplante Arbeit hatten.

Interviews mit Software-EntwicklerInnen zu Copilot

Um den Wert von Copilot besser einzuschätzen, habe ich neben den Messungen Interviews mit allen Team-KollegInnen durchgeführt. Als erstes haben wir die Interviews vom Hersteller selbst überprüft. GitHub selbst erstellte die Umfrageergebnisse im folgenden Bild links. Auf der rechten Seite beantworten die Entwickelnden im Asteroid Team die selben Fragen:

 

Vergleich GitHub Copilot "Werbung" mit Erfahrung in meinem Team

Zwischen der Umfrage des Herstellers und der Erfahrung in unserem Team gibt es signifikante Unterschiede. Allerdings bestätigt unsere Umfrage die Ergebnisse zu den wichtigen Fragen nach höherer Produktivität und Geschwindigkeit.

Da bei unserer Evaluierung die Frage nach dem Nutzen in der täglichen Arbeit eines Scrum-Teams im Fokus stand, habe ich noch 4 andere Fragen gestellt:

• Using it? - Verwendest Du Copilot wirklich in der täglichen Arbeit?
• Is helpful in your Daily Work? - Hilft Copilot Dir bei Deiner täglichen Arbeit in der Software-Entwicklung?
• Makes Copilot you faster? - Macht Dich Copilot bei Deiner Arbeit insgesamt schneller? Hintergrund neben dem reinen Entwickeln verwenden wir auch viel Zeit für Tests, Betriebsaufgaben (DevOps-Team), Scrum-Rituale etc. Das eigentliche Programmieren bei dem uns Copilot unterstützt ist nur ein Teil unserer täglichen Arbeit.
• What impact do you expect in future? - Welchen Effekt auf Deine Arbeit erwartest Du durch Copilot in der Zukunft?

Interview zu Copilot

Zusammenfassung der Antworten:

• Alle TeilnehmerInnen verwendeten Copilot in der täglichen Arbeit während der Evaluierung.
• Für fast alle war Copilot hilfreich. Insbesondere bei ähnlichem Code oder sich wiederholendem Code wurde die Nützlichkeit festgestellt.
• Einige berichten, dass Copilot bei komplexen Aufgaben scheiterte.
• Fast alle waren durch Copilot zumindest ein wenig schneller.
• Die meisten erwarten in Zukunft einen noch größeren Effekt auf die tägliche Arbeit durch Copilot.

Fazit und Ausblick

Copilot erzielt ein gutes Evaluierungsergebnis. Wir empfehlen die Verwendung von Copilot. 

GitHub Copilot kostet im September 2023 19$ pro Benutzer pro Monat. Basierend auf den Evaluierungsergebnissen nehme ich an, dass die meisten EntwicklerInnen durch Copilot mindestens 1 Stunde pro Monat schneller sind. Die Stundensätze von Developern liegen in den meisten Länder deutlich über 19$, daher sehe ich hier eine positive Kosten-Nutzen-Rechnung.

In naher Zukunft erwarte ich weitere Features in Copilot, welche die Entwicklung beschleunigen und die Qualität verbessern, siehe GitHub Labs. Daher empfehle ich jedem zumindest das Ausprobieren von GitHub Copilot.