German 🇩🇪

KI-lesbare Dokumentation

Derzeit gibt es viel Trubel um ein Entwicklungs-Tool namens GitHub Copilot, das über KI-unterstützte Funktionen verfügt. Es herrscht die Meinung, dass dieses Tool nur für Ingenieure gedacht ist. Dies ist teilweise wahr, aber auch teilweise falsch. GitHub Copilot hat in der Tat eine unglaubliche Fähigkeit, die Arbeitsweise von Ingenieuren zu verändern. Wenn sich die Arbeitsmethoden der Ingenieure ändern, müssen sich auch die Organisationen anpassen. Wenn Sie sich in einer PM- oder PO-Position befinden, ist dies auch für Sie ein wichtiges Thema. Da von Ihrem Team erwartet wird, dass es Ihre definierten Anforderungen so schnell wie möglich umsetzt, ist es wichtig, AI-lesbare Dokumentation zu erstellen, um eine Zusammenarbeit mit der KI zu ermöglichen.

Dokumentationskultur und AI-native Entwicklung

In den letzten Jahren hat sich die KI-Technologie rapide weiterentwickelt, mit Modellen wie LLM (Large Language Model), die Aufmerksamkeit erregen. GitHub, eine Open-Source-Entwicklungsplattform, hat sich ebenfalls auf dem Gebiet der KI-Entwicklung betätigt. Ein herausragendes Beispiel hierfür ist "GitHub Copilot". Interessanterweise haben KI-unterstützte Entwicklung und Open-Source-Entwicklung gemeinsame Schnittstellen in Bezug auf Zusammenarbeit. Beide Methoden beinhalten speziell das Arbeiten mit dokumentenbasierten Formaten wie Markdown. Formate wie Markdown sind darauf ausgelegt, strukturierte Informationen darzustellen und sind einfacher von der KI zu analysieren als PowerPoint- oder Excel-Dateien. Daher tragen sie zur Verbesserung der von der KI generierten Code-Qualität bei.

Die KI bevorzugt einfache CSV-Dateien gegenüber komplexen Excel-Tabellen, die mit Metadaten gefüllt sind. Wenn Sie als PM beispielsweise Kundenanforderungen auflisten und die notwendigen Informationen für eine Datenbank sammeln, können Ingenieure sie einfach in Code konvertieren, wenn die Anforderungen in einer CSV-Datei oder in Markdown zusammengefasst sind. Wenn Sie die Informationen jedoch in einem Excel-Dokument, das an Ihre Vorlieben angepasst ist, zusammenstellen, müssen Ingenieure sie zuerst kopieren, formatieren und dann in Code konvertieren. Welcher Ansatz ist besser?

Darüber hinaus kann die Qualität der Dokumentation in der Open-Source-Entwicklung direkt mit dem Erfolg eines Projekts in Verbindung gebracht werden. Open-Source-Projekte sind für jeden zugänglich, und eine gut gepflegte Dokumentation ermöglicht es neuen Entwicklern, reibungsloser einzusteigen. Daher wird die Dokumentation in der Open-Source-Entwicklung sehr geschätzt. Ähnlich verhält es sich in der KI-Entwicklung, wo eine etablierte Dokumentationskultur zu einer effizienteren und qualitativ hochwertigeren Entwicklung führen kann. Selbst wenn Sie kein Ingenieur sind, kann Ihre natürliche Sprache, die in Markdown geschrieben ist, erheblich zum Endprodukt beitragen, nämlich dem Code. Dies könnte Code sein, der Gesch äftslogik, Tabellendefinitionen oder sogar Test-Szenarien darstellt. Ist Ihr Entwicklungsteam bereit, die KI einzubeziehen? Sind AI-lesbare Dokumente vorbereitet? Wenn die Antwort nein lautet, müssen Sie ein Entwicklungsteam erstellen, das bequem für die Zusammenarbeit mit der KI ist.

AI-native Entwicklung und InnerSource-Strategie

Wir haben die Open-Source-Entwicklung diskutiert, aber es gibt auch ein ähnliches Konzept namens InnerSource. InnerSource ist ein Ansatz, der die bewährten Methoden der Open-Source-Softwareentwicklung in Organisationen übernimmt, die proprietäre oder nicht Open-Source-Software entwickeln. Es zielt darauf ab, die Zusammenarbeit über organisatorische Grenzen hinweg zu fördern und organisatorische Silos abzubauen.

InnerSource wird für Unternehmen zunehmend wichtiger, um das Rad nicht neu erfinden zu müssen, die Entwicklung zu optimieren, um Kosten zu reduzieren und durch Zusammenarbeit neuen Mehrwert zu schaffen.

Wie auf der Seite AI-native Entwicklung erwähnt, tendiert die KI dazu, erfahrene Menschen zu ergänzen. Erfahrene Personen in einer Organisation, die die Architektur verstehen, werden gestärkt, während andere einfache Aufgaben zugewiesen werden.

Da die KI jedoch hauptsächlich auf Wissen aus dem Internet trainiert wird, kann sie nicht auf proprietäre Domänen, geschlossenes Wissen innerhalb von Organisationen oder unveröffentlichte Informationen zugreifen. Daher stellt dies ein Problem dar, wenn diese Informationen nicht dokumentiert oder ordnungsgemäß innerhalb der Organisation geteilt werden. Dies bedeutet, dass Ingenieure nicht nur keinen Zugang zu den Informationen haben, sondern auch die KI wie GitHub Copilot nicht darauf zugreifen kann.

Wissen, das nicht aus dem Internet bezogen werden kann, wird derzeit immer wichtiger und ist eine Kernkompetenz von Unternehmen. Es gibt ein Zitat aus einem Einführungsbuch zum InnerSource ("Getting Started with InnerSource") von O'Reilly:

InnerSource unterscheidet sich von klassischem Open Source, indem es innerhalb der Ansicht und Kontrolle einer einzigen Organisation bleibt. Die "Offenheit" des Projekts erstreckt sich über viele Teams innerhalb der Organisation. Dies ermöglicht es der Organisation, differenzierende Geschäftsgeheimnisse in den Code einzubetten, ohne befürchten zu müssen, dass sie an Außenstehende offenbart werden, während sie von der Kreativität und den vielfältigen Perspektiven profitieren, die von Menschen in der gesamten Organisation beigetragen werden.

Viele Unternehmen stehen vor der Wahl, entweder mit der KI zusammenzuarbeiten oder durch sie ersetzt zu werden. Es ist wichtig, die internen Informationen, die die Quelle des Wettbewerbsvorteils einer Organisation darstellen, zu aggregieren und von der KI nutzen zu lassen. Um dies zu erreichen, ist eine Dokumentation mit AI-Lesbarkeit unverzichtbar.

In Bezug auf InnerSource gibt es bereits eine reife Community, in der Methoden zur Realisierung von Co-Creation innerhalb von Organisationen und zur Erstellung von Dokumentationen geteilt werden. Greifen Sie auf diese Community zu und nutzen Sie die Initiativen von InnerSource. Auf diese Weise können Sie internes Wissen und Informationen effektiv nutzen und die Zusammenarbeit mit der KI optimal nutzen.

InnerSource-Referenzen

Die Erstellung von kontextreicher Dokumentation

Mit der Reife von Open-Source-Entwicklung entsteht Zusammenarbeit über Ländergrenzen und Zeitzonen hinweg. Geographische Distanz und Zeitunterschiede können jedoch die synchronen Kommunikationen erschweren. Beispielsweise ist es in New York tagsüber, während es in Tokio nachts ist, und es ist unerwünscht, japanische Committer nachts zu stören oder die Familienzeit zu beeinträchtigen. Daher bevorzugt man im Allgemeinen eine dokumentenbasierte Dokumentation. Dies könnte etwas wie RFCs oder Design-Dokumente sein oder Kommentare, die in GitHub Issues geschrieben wurden. Dokumente, die aus Kommentaren in Issues und ähnlichen Plattformen bestehen, werden auch als passive Dokumentation bezeichnet. Diese sind auch Formen von Dokumentation.

In Understanding the InnerSource Checklist, veröffentlicht von O'Reilly, gibt es einen Absatz, der wie folgt lautet:

Passive Dokumentation ist der Bericht über die Dokumentation, die wir jeden Tag beim offenen Austausch erstellen. Es ist eine großartige Möglichkeit, Wissen, das auf Silos begrenzt ist, in ein Archivformat zu bringen und so besser auffindbar zu machen. Ein zusätzlicher Bonus ist, dass es normalerweise mit dem Projekt oder dem Code aufbewahrt wird, den es dokumentiert, so dass es an einem leicht zugänglichen, kontextrelevanten Ort ist.

Hier ist es wichtig, es angemessen zu formulieren, einschließlich des Kontextes. Es ist schwierig, nonverbale Kommunikation, Nuancen und Atmosphäre zu vermitteln, die durch Zoom oder face-to-face-Gespräche asynchron über Zeitzonen hinweg kommuniziert werden.

Überlegen Sie, ob Sie mit künstlicher Intelligenz entwickeln wollen. Wird GitHub Copilot zum Beispiel an Zoom-Meetings teilnehmen? Wird es im Teamraum sagen: "Hallo, ich bin GitHub Copilot, lasst uns ein schnelles Check-In-Meeting machen"? Die Antwort ist nein. Der gesamte Kontext muss AI schriftlich mitgeteilt werden. Dies ist auch erforderlich, wenn geeignete Dokumentation für asynchrone Kommunikation erstellt wird, wie im Open-Source-Entwicklungsprozess.

Natürlich gibt es Unterschiede in der Granularität der Dokumentation zwischen Open-Source-Entwicklung und AI-unterstützter Entwicklung. Wenn man in GitHub Issues schreibt: "Ich möchte diesen Fehler beheben", kann dies jemanden dazu bringen, eine Lösung zu finden, aber AI kann nicht so weit gehen. Es gibt jedoch definitiv Bereiche, in denen KI hervorragend ist. Wenn Sie beispielsweise Cloud-Architektur als Infrastructure as Code ausdrücken möchten, ist es besser, es in Mermaid zu schreiben oder es in natürlicher Sprache auszudrücken, anstatt es in PowerPoint zu zeichnen.

Der Punkt hier ist nicht, dass alle Kommunikation dokumentiert werden muss. Sie und Ihr Team müssen darüber nachdenken, welches Niveau der Dokumentation erforderlich ist, wie und wo Sie sie hinterlassen sollten.

KI koordiniert organisatorisches Wissen

Mit Funktionen wie GitHub Copilot for Docs, die in GitHub Copilot X enthalten sind, kann KI die perfekte Dokumentation für Sie erstellen. Die von Ihnen geschriebenen Dokumente können auch Einarbeitungsmaterialien für die nächste Person werden.

Früher war das Sammeln von Informationen und das Erstellen von Einarbeitungsmaterialien für neue Ingenieure eine gängige Aufgabe, aber in Zukunft wird KI diese Rolle wahrscheinlich übernehmen. Sie können das gesamte Wissen, das Sie besitzen, in Dokumenten einbetten, als einzige zuverlässige Informationsquelle.

Dieser Ansatz kann auch explizit in der Dokumentation von Atlassian gesehen werden. Das Lesen ihrer Dokumentation mit AI Native Entwicklung im Hinterkopf kann zu neuen Entdeckungen führen. Die von Ihnen geschriebenen Dokumente werden durch KI eine Persönlichkeit haben. Dies erfordert jedoch ausreichende Dokumentation, wie bereits erwähnt.

Der Abstand zwischen natürlicher Sprache und Implementierung wird geringer

Wie Sie vielleicht bereits bemerkt haben, wird der Abstand zwischen natürlicher Sprache und Implementierung immer geringer. Wie bereits erwähnt, könnte es aus pädagogischer Sicht möglich sein, Dokumentation in einer einzigen Datei zu erstellen, wenn Schreibimpulse und Code an einem Ort fortgesetzt werden. Diese Art von Veränderung ist faszinierend.

Checkliste

Last updated