We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Managementwerkzeuge aus der Open-Source-Entwicklung

00:00

Formal Metadata

Title
Managementwerkzeuge aus der Open-Source-Entwicklung
Subtitle
oder wie gestalte ich ein Prozesshandbuch Hacker-kompatibel?
Title of Series
Number of Parts
94
Author
License
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Dieser Vortrag beleuchtet, wie Management-Prozesse entwicklerkompatibel gestaltet werden können und wie Manager einen Open-Source-Workflow und entsprechende Technologien für sich nutzen können. Der Arbeitsalltag in einem (wachsenden) mittelständischen Unternehmen besteht oftmals aus mehr Prozessen und Bürokratie, als einem Entwickler lieb ist. Wie gelingt es dem Management, die daraus erwachsenden »lästigen Pflichten« so kompatibel wie möglich zu gestalten, und was kann das Management aus den Workflows von Entwicklern lernen und sich zunutze machen? In diesem Vortrag wird exemplarisch die Gestaltung eines betrieblichen Prozesshandbuchs für Entwickler vorgestellt, und die Vorteile der verwendeten Technologien von git über Sphinx bis Jenkins werden beleuchtet.
15
Thumbnail
1:16:56
20
Thumbnail
59:24
23
Thumbnail
10:02
48
Thumbnail
50:08
56
76
Thumbnail
12:05
HTTPHacker (term)Hacker (term)Decision theoryProcess (computing)XMLUMLComputer animation
FachinformatikerProcess (computing)Computer animation
Computer programmingOpen sourceMultimediaLINUXKernel (computing)Computing platformDigital rights managementDevice driverTape driveVimComputer hardwareOperating systemEmacsWebsiteWeb pageDevice driverLINUXWEBComputer animation
Computer animation
Web pageProcess (computing)EditorInformationControl engineeringComputer animation
Patch (Unix)Kernel (computing)LINUXKernel (computing)Patch (Unix)LINUXLecture/ConferenceMeeting/InterviewComputer animation
LINUXPatch (Unix)Kernel (computing)Git <Software>EmailComputer animation
ASCIIEXCELGit <Software>Computer animation
Reading (process)Server (computing)Git <Software>Jenkins CIUniform resource locatorProcess (computing)Computer animation
MeasurementTemplate (C++)DownloadTable (information)Process (computing)Computer animation
MeasurementPDF <Dateiformat>Web pageProcess (computing)Computer animation
Web browserWEBComputer animation
Drum memoryComputer animation
Noten <Programm>Web browserHANS <Datenbanksystem>InformationCanonical ensembleComputer animation
PayPalRevision controlPayPalRevision controlXMLComputer animation
Revision controlComputer animation
Drum memoryWorld Wide WebInsertion lossCommon Language InfrastructurePrincipal ideal domainJenkins CISoftware testingProcess (computing)Computer animation
Source codeTable (information)Software testingComputer animation
EditorProcess (computing)Video trackingComputer animation
GeometryComputer wormProcess (computing)Route of administrationSubversion <Programm>Computer programmingComputer animation
TOUR <Programm>Inverter (logic gate)TypLeadProcess (computing)Computer animation
Insertion lossCommon Language InfrastructureProcess (computing)Normal (geometry)Eigenvalues and eigenvectorsWikiInformationThread (computing)Durchschnitt <Mengenlehre>Git <Software>Category of beingSoftware testingComputer animation
World Wide WebInsertion lossMono-FrameworkProcess (computing)Formalismus <Mathematik>Function (mathematics)WEBMoment (mathematics)EditorOpen sourceReading (process)SoftwareComputer animation
Common Language InfrastructureWorld Wide WebInsertion lossSoftware testingProcess (computing)WalkthroughMeeting/InterviewComputer animation
openSUSEXMLComputer animation
Transcript: German(auto-generated)
Ja, schön, dass ihr da seid. Ich darf euch heute noch mal erzählen, wie wir bei uns in der Firma das Prozesshandbuch so gebaut haben, dass die Hacker damit auch so weit zufrieden und glücklich sind, dass sie es tatsächlich einsetzen.
Zu Beginn möchte ich euch noch einmal mit zwei Fragen abholen. Kommt euch das bekannt vor? Wie haben wir das eigentlich das letzte Mal getan? Ihr nickt, ja? Und warum ist das eigentlich so?
Das gilt nicht nur für Software, sondern tatsächlich auch für ganz alltägliche Prozesse. Wie werden die Reisekosten eigentlich noch mal abgerechnet? Was muss ich tun, um die Fortbildung zu beantragen? Und warum wurden die Entscheidungen eigentlich so getroffen, wie sie
getroffen worden sind? Ich habe 2017, also jetzt gut vor zwei Jahren bei Pengotronics angefangen und bin irgendwie relativ schnell mit all diesen Fragen konfrontiert worden. Es fing damit an, dass ich erst einmal die ganzen
ja Prozesse überhaupt selbst entdecken musste, die wir so haben. Wie funktioniert die Verwaltung? Wie funktioniert das Management? Und dann aber auch irgendwann an den Punkt gekommen bin, dass wir Sachen ausarbeiten wollen, Prozesse aufschreiben. Mein erstes Projekt
war eine ordentliche Einarbeitungstaskliste zu gestalten, dass neue Mitarbeiter, die nach mir kamen und dann erfolgreich eingearbeitet worden sind und all die ganzen Prozesse, die wir bei uns im Unternehmen haben, auch entsprechend nachlesen konnten.
Jetzt ist relativ wichtig zu wissen und ich möchte hier kurz zu dem Werbeblock kommen. Pengotronics ist eine Embedded Linux Firma. Das heißt, all unsere Kunden haben in irgendeiner Art und Weise Embedded-Geräte im Feld, deren Betriebssystem wir helfen mit aufzusetzen
und für die wir dann auch weitere Treiber portieren und schreiben. Das heißt, meine Kollegen sind ganz, ganz, ganz dicht an der Hardware und noch viel dichter am Linux-Körnel dran. Das heißt, der Haupteditor ist Vim oder Emacs
und es wird eigentlich auch nichts anderes verwendet. Der Kollege, der jetzt direkt nebenan seinen Vortrag hält, hat diesen wunderschönen Satz gebracht. Naja, wenn ich meinen Kollegen einen Web-Editor, also er spricht über den Static Site Generator, den er geschrieben hat,
vorsetze, dann dauert es genau acht Minuten bis sich alle Kollegen ein Skript geschrieben haben, um wieder Vim oder Emacs nutzen zu können, um die Webseite zu bearbeiten. Also bloß nichts anderes. Dementsprechend kontraproduktiv war das Wiki, das wir hatten und es hatte all die
Probleme, die Wikis, und ich höre es auch aus anderen Firmen von Freunden, hatten. Es war nicht gepflegt. Also irgendwann veraltet, weil, naja, man muss sich halt damit auseinandersetzen.
Ein kurzer Disclaimer noch, wir sind nicht ISO 9001 zertifiziert und all mein Wissen habe ich aus diesem Buch. Das Wichtige, was ich in diesem Buch mitgenommen habe, ist, es geht um die Beteiligung der Mitarbeiter.
Wir wollen sie mitnehmen. Das sind diejenigen, die die Prozesse leben müssen. Und, naja, teilweise auch ausbaden. Also ist es halt schön, sie zu integrieren und, naja, wenn sich Prozesse weiterentwickeln, die auch wieder von den Mitarbeitern
einzusammeln und um die Prozesse aktuell halten zu können. Gleichzeitig sind diese Prozesse ja eine Art Vereinbarung zwischen der Geschäftsführung und den Mitarbeitern. Welche Fortbildungen werden genehmigt? Wann werden Fortbildungen genehmigt?
Welche Reisekosten dürfen abgerechnet werden? Und man möchte ja auch beim nächsten Mal, dass sich die Geschäftsführung wieder daran erinnert und hält. Deswegen schreibt man es auf. Was ich gerade schon gesagt habe, man möchte, dass die Prozesse aktuell sind.
Die entwickeln sich eben weiter. Im Alltag stellt man fest, ja, es ist zwar so und so, aber so ist es doch irgendwie viel leichter, den Prozess zu leben. Oder die Information in dem Formular, die brauchen wir gar nicht unbedingt. Warum sollen wir sie da jedes Mal reinschreiben?
Manchmal ändern sich auch gesetzliche Grundlagen, die wiederum Einfluss zum Beispiel auf Reisekostenregelungen haben, dass auf einmal jeder Tag vollständig abzurechnen ist. Da gibt es ja jetzt so ein paar Gerichtsentscheide und auch das muss natürlich wieder in die Prozesse reingepflegt werden.
Dann haben wir die Benutzbarkeit. Jetzt sind zwar die meisten meiner Kollegen nur mit ihrem Editor zugange, aber natürlich habe ich auch in der Buchhaltung Kollegen sitzen, die dann doch mal ganz gerne lieber sich eine Webseite anschauen möchten.
auch das ist also eine Anforderung, die wir uns überlegt haben, was wichtig ist, um die Prozesslandschaft, wie wir eben Prozesse gestalten möchten, zu gestalten. Und dann steht nicht zuletzt auch eine mögliche Zertifizierung im Raum. Also wenn wir das Prozesshandbuch schon neu gestalten und aufsetzen,
dann möchten wir es auch so bauen können, dass wir das vielleicht mal irgendwann einem Auditor in die Hand rücken können. Aber, naja, zusammenfassend, es geht darum das Team mitzunehmen. So, wie tun wir das?
Wir haben uns also angeschaut, wie arbeiten die Kollegen und mit was arbeiten die Kollegen. Das Wie ist relativ einfach. Das ist der Linux Kernel Patch Workflow. Es gibt auch die Contributor, die also feststellen, ist jetzt nicht so schön oder ich habe da einen Bug gefunden oder
hey, da ist ein Rechtschreibfehler. Gut, ich fixe das eben und ich schicke diesen Patch also an den Maintainer, damit der dort eingepflegt wird. Manchmal kommt der Patch zurück, manchmal sind das langwierige Diskussionen, manchmal muss der Maintainer auch noch mal darauf hingewiesen werden,
dass da noch ein Patch ist. Ja, das gehört dann leider dazu. Die Patches wandern dann an den Linux Next Branch, um dort getestet zu werden und dass eben geschaut wird, dass alles zusammenläuft,
dass Linux noch funktioniert. Und wenn alles gut ist, anschließend in den Mainline Kernel und von dort dann wieder zurück in die Community, um dann, ja, dort wieder den nächsten Änderungen von der Gemeinschaft wieder
eingepflegt werden zu können. Das Zweite sind die Technologien. Das sind tatsächlich vor allem viel, viel Text. Wir nutzen Swings, wir nutzen Git und immer wieder E-Mail.
Also gut. ASCII-Text und Git. Das sind die Sachen, auf die wir uns geeinigt haben, was also dieses Prozesshandbuch unbedingt erfüllen muss. Warum denn jetzt unbedingt ASCII-Text? Naja, ich möchte auch, dass meine Dateinversions
unabhängig gelesen werden können, dass dort von jedem Ort auch drauf zugegriffen werden kann und Git, das ist halt unglaublich praktisch. Wir haben den Master-Branche schreibgeschützt.
Das heißt, mit dem Merge auf den Master, das kann nur durch diejenigen geschehen, die diese Prozesse freigeben. Die also damit, dass sie in Reihen mergen, auch den Prozess für gültig erklären und damit auch die Zusagen treffen, die für die Mitarbeiter gelten
oder eben hinter dem, was sie einfordern, stehen. Und dann ist der zweite wichtige Punkt in Git die Commit-Messages. Mit den Commit-Messages haben wir die Möglichkeit und ja, die müssen dafür wirklich sauber gepflegt werden,
nachzuvollziehen, wann welche Änderung reingepflegt worden ist und vor allem, warum welche Änderung drin ist. Was ist denn jetzt der genaue Grund? Okay, der Prozess hat sich weiterentwickelt oder hier gibt es dann die rechtliche Änderung, die sich
geändert hat. Und dann haben wir noch einen dritten Schritt eingebaut. Wir haben uns für ein Continuous Deployment entschieden. Die Datei, die eben über Git dann auf dem Server landet, wird dort von einem Jenkins bei uns automatisch gebaut
und in einem Swings mit dem Read the Docs Format automatisch ausgeliefert. Das heißt, wenn jemand die URL für das Prozesshandbuch intern bei uns aufruft, ist sichergestellt, dass die aktuell gültigen Prozesse dort zu finden sind. Man muss also
nicht mehr irgendwie überlegen, ob es jetzt wirklich das Aktuelle ist, ob da nicht jemand vergessen hat, irgendwie was zu releasen, sondern das ist einfach, das passiert. Als nächstes möchte ich gern zeigen, wie bei uns
ein Prozess aussieht. Das ist hier ein Beispiel, Heather. Wir haben uns für Restructured Text entschieden und ein vorneweg erst mal eine Tabelle gestellt, die so grundlegende Metainformationen enthält.
Wann ist der Prozess auf gültig gesetzt worden? Man möchte das ja auch sehen können, ohne erst mal in die Git-Historie schauen zu können. Wann haben wir die nächste Wiedervorlage? Die Prozesse sollen ja schließlich auch
regelmäßig gereviewed werden. Wir wollen ja sicher sein. Dass sie aktuell bleiben. Wer ist der Prozess-Eigentümer? Und vor allem, wer muss sich an den Prozess halten? Dann bauen Prozesse aufeinander auf. Das funktioniert über die Ausgabe hier wunderschön mit einem Link,
auf dem man dann, wenn man zumindest auf der Webseite ist, oder ich glaube auch, falls man sich das mal als PDF gebaut hat, einfach klicken kann. Und es gibt eine Vorlage.
Zum Beispiel eben das genannte Reisekosten-Formular. Anschließend folgt die Prozessbeschreibung. Wir haben uns dann, wir haben uns eben ganz bewusst dafür entschieden, dass der Prozess als erstes kommt. Also das, was die Mitarbeiter wirklich interessiert. Was muss ich denn eigentlich als tun?
Und Wie müssen die Reisekosten beantragen? Muss ich vorher noch was einreichen? Und eben ganz am Ende dann die Rahmenbedingungen, die so etwas wie Qualitätsmerkmale enthalten,
die Durchführungszyklen enthalten. Wann wird dieser Prozess aktiviert? Na ja gut, beim Reisekosten-Formular ist es einfach jedes Mal, wenn ich ein Reise gemacht habe. Oder hier jetzt bei dem Beispiel, sobald ein Prozess abgelaufen ist, sollte eben geprüft werden, ob
ja, der Prozess noch eben gültig ist, ob die gesetzlichen Grundlagen noch in Ordnung sind und so weiter. Jetzt habe ich davon erzählt, dass wir das eben in einem Web-Editor, nicht Web-Editor, sondern einfach im Browser ausgeben können. Und das sieht dann so aus.
Das ist also hier auch einfach mit der Gliederung wunderbar durch zu navigieren und auch die Suche funktioniert erstaunlich gut. Das heißt,
wenn man jetzt zum Beispiel nach Überstunden- Abbau suchen möchte, kann man dort einfach Überstunden eingeben und bekommt die ganzen Ergebnisse von den Prozessen, in denen in irgendeiner Art und Weise Überstunden enthalten sind.
Ja, zu der einfachen Benutzbarkeit hier nochmal das Beispiel. Das sind eben Links und auch das Formular lädt man dann einfach in den Browser runter, kann das ausfüllen und sich einfach an den Prozess halten. Ich habe den Vortrag in Chemnitz schon einmal gehalten und anschließend die Frage bekommen,
was sind denn jetzt eigentlich die Vorteile? Schießt ihr hier gerade nicht mit Kanonen auf Spatzen? Also, ihr macht einen riesigen Workflow, baut den neu auf, nur um am Ende wieder einen Web-Browser zu haben? Ja und nein.
Ich würde sagen, bei uns in der Firma haben wir die Tools, die wir nutzen, minimiert, weil wir einfach genau die gleichen Technologien einsetzen, die wir an allen anderen Stellen sowieso einsetzen. Und das Wiki, das
ja, noch genutzt wird und in dem zwischendurch auch nochmal Informationen stehen, aber das sehr ungern genutzt wird, das eben einfach weiter abzubauen. Und wirklich so die Kollegen auch zu
animieren, das mitzunutzen. Und das funktioniert so hervorragend, dass sich die Kollegen nach dem gleichen Form-Bild ein eigenes Entwicklerhandbuch gebaut haben, das sie eben selbstständig pflegen und in dem sie die Informationen verwalten und mit dem es jetzt neuen Kollegen noch viel einfacher fällt,
diese ganzen kleinen Tricks, die sich über Jahre so angeeignet haben und die eigentlich bisher nur von Mund zu Mund weitergegeben worden sind, auf einmal wirklich definitiv vorzufinden. Und dann gibt es noch einen ganz entscheidenden Vorteil. Ihr kennt
dieses Dokument, PayPal informiert über geänderte Geschäftsbedienung. Wer von euch kann mir denn sagen, was PayPal von der letzten zur vorletzten Änderung der AGBs wirklich geändert hat? Ich habe hier hinter eine Versionskontrolle liegen.
Ich kann den Kollegen nicht nur sagen, dieser und jene Prozess hat sich geändert, bitte lest ihn, sondern ich kann ihnen dedizierte Diffs geben mit genau den Änderungen,
die passiert sind, von denen sie genau wissen, okay, ja, vielleicht dieser Prozess interessiert mich nicht, dann brauchen sie ihn gar nicht sich anschauen, aber wenn der Prozess sie betrifft, dann können sie halt sofort sehen, interessiert mich auch wirklich dieser Schritt
oder was muss ich zukünftig anders machen? Oh, schau mal, ich darf auf einmal meine Reisekosten irgendwie noch viel einfacher oder noch viel häufiger beantragen.
Jetzt gilt auf einmal die Frostcon auch als Firmenreise. Ja, ich habe einen Penguin auf meiner Webseite, auf meiner Folie, das ist toll. Ja, noch mal kurz zu dem Prozess selbst, denn es gibt einen weiteren
Vorteil, den wir auf dem, aufgrund des Continuous Deployments mit Jenkins haben. Habt ihr bemerkt, dass sich die Wiedervorlage in der Vergangenheit befindet? Auf den Jenkins haben wir eine Test,
oder einfach selbstgeschriebene Tests laufen, die uns dann informieren, wenn Prozesse ungültig geworden sind. Wir können uns das auch einfach anschauen, für die, die dann doch wieder gerne Grafik haben möchten. Das sind jetzt hier oben zwölf Tests,
die viel geschlagen sind. Das heißt, wir testen nicht nur auf das Wiedervorlagedatum, sondern wir testen auch noch darauf, dass zumindest die Tabelle
vollständig ausgefüllt ist und dass all die Überschriften, die wir in einem Prozess erwarten, vorhanden sind, dass der Prozess an sich zumindest formal gültig ist. Und diese Tests lassen sich, wenn wir feststellen sollten,
dass wir noch weitere Tests brauchen, beliebig erweitern und beliebig anpassen. Ich gebe zu, ich möchte euch ermutigen, auch mit eurem Management,
über einen neuen Workflow zu sprechen. Und mir ist bewusst, nicht jedes Management ist jetzt so ASCII-affin. Da habe ich deutlich Glück, dass ich das erste, was ich bei Pengotronics lernen durfte,
die Benutzung von Mathe war. Ja, aber es gibt grafische Editoren, wie z.B. GitLab, die dann auch noch den Charme eines Trackings haben, also eines
Issue Trackers, an dem man dann einfach, vielleicht sind die Prozesse in eurer Firma ja auch so gestaltet, dass ihr gar nicht direkt an den Prozessen mitschreiben sollt. Ihr habt ja nun auch wirklich besseres zu tun, schätze ich mal. Dass ihr dort einfach ein Bug-Report einkippen könnt und sich dann die Leute, die
für den Prozess verantwortlich sind, dem annehmen können und darum kümmern können, dass der Prozess aktualisiert wird. Ja, jetzt war ich wohl doch ganz schön nervös und bin auch schon beim Ende angelangt. Was ich euch
wirklich mitgeben möchte und was wir jetzt geschafft haben umzusetzen ist, schaut euch, wenn ihr Prozesse oder ein Prozesshandbuch etablieren wollt oder die Möglichkeit habt, euer Prozesshandbuch anders noch mal neu zu gestalten, schaut euch an, dass die Anwender
in der Lage sind mit den gewohnten Werkzeugen und Abläufen zu arbeiten. Das mag Git sein, das mag SVN sein.
GitLab macht es selbst, dass sie ihr eigenes Prozesshandbuch in GitLab selbst auch der Öffentlichkeit zur Verfügung stellen und auch von außen wieder Feedback einholen. Das funktioniert ganz hervorragend.
Sucht euch eine einfache Änderungsverfolgung. Es müssen keine kommerziellen Tools sein, das ist dort draußen in der Softwareentwicklung vielfach erprobt, ausprobiert und die Werkzeuge funktionieren. Schaut halt, dass alle damit leben können und
glücklich sind. Wichtig ist, dass es einen wirklich gut ausgeformulierten Prozess zur Prozesserstellung gibt. Überlegt euch genau, wer hat wann die Verantwortlichkeit.
Wann sollen Prozesse gereviewed werden, wer reviewt sie, wer sind die verantwortlichen Personen? Und bei den verantwortlichen Personen plant euch regelmäßige Termine ein. Das ist entscheidend.
Und dazu gehört dann plant euch genug Zeit ein. Das ist verdammt aufwendig, so ein Prozesshandbuch neu zu. Gestalten und zu überarbeiten. Lasst, das holt euch dieses Feedback von außen. Ich stelle das selber fest, wenn ich
fünfmal über einen Prozess nachgedacht habe und ihn dann doch sechsmal umformuliert habe, weil es gerade schöner war, dann schleichen sich Fehler ein, dann sind Sätze unvollständig und dann bin ich echt froh, wenn dann der Kollege mit dem Knitpicking kommt und mir den Satz gerade biegt oder die Rechtschreibfehler raushaut.
Ja und als allerletzten Rat geht davon aus, dass eure Prozesse auch gelesen werden. Habt ihr Fragen?
Ja, ich habe es gerade gelesen. Also die Frage war, wie der wesentliche Unterschied zur Verwendung des Wikis ist.
Für den Endanwender die Suche funktioniert und die Struktur funktioniert. Also das Prozesshandbuch ist wesentlich besser strukturiert. Das mag jetzt natürlich auch daran liegen, dass ich es gerade frisch
aufgebaut habe und wenn etwas wächst, dann ist es ja, will ich nicht ausschließen, dass auch ich irgendwann mal feststelle, na vielleicht sollte ich es besser nochmal umstrukturieren, weil so wie ich mir das damals überlegt habe, funktioniert es nicht mehr. Aber naja,
geht smooth. Also ich kann die Prozesse einfach verschieben. Ich kann über eine ganz einfache Änderungsverfolgung den Kollegen sagen, naja die Prozesse liegen jetzt da und im Zweifel, einen Moment,
die Suche funktioniert. Sie können die Prozesse immer noch über irgendein Stichwort wiederfinden. Und was für uns jetzt persönlich noch ein ganz entscheidender Unterschied ist, in dem Wiki ist ein Sammelsurium von Informationen gewesen.
Hier haben wir nur die Prozesse und es ist klar, dass wir hier nur die Prozesse finden und nicht noch 50 andere Querverweise von irgendwelchen Seiten, die vielleicht mal irgendwann als Draft geschrieben worden sind, die bei einer Suche im Wiki zu finden wären.
Also die Frage war die nach, wie funktioniert bei uns jetzt konkret die Prozessänderung durch die
Mitarbeiter. Wir sind eine relativ kleine Firma mit derzeit etwa 30 Mitarbeitern und wir treffen uns regelmäßig an der Kaffee Theke.
Das heißt zum einen kommen einfach größere Prozessänderungswünsche direkt an der Kaffee Theke an mich mündlich zugetragen. Und kleinere Änderungen werden bei uns einfach da hat jeder Mitarbeiter die Möglichkeit sich das Prozessernbuch zu klonen
und in einem eigenen Topic Branch einfach die Änderungen vorzuschlagen, von denen er denkt, dass sie sinnvoll sind. Die werden dann einfach als normaler Git Pull Request an meine Geschäftsführung gestellt
und naja, der muss sich dann die Zeit einplanen, die Pull Requests auch wieder zu merken. Die Frage ist nach der Anzahl der Prozesse.
Na ja, wir haben jetzt hier 1, 2, 3, 4, 5, 6, 7, 8 8 Kategorien zu denen in, ich würde sagen, jeder Kategorie mindestens 5 Prozesse so im Durchschnitt stehen. Also das sammelt sich
sehr, sehr schnell, sehr, sehr viel an, was man dann irgendwie doch feststellt. Wie wird Urlaub beantragt? Wie werden, wird bei uns die Zeit erfasst? Wie werden Arbeitspakete verteilt? Da kann man sehr schnell auf einmal sehr viel formalisiert niederschreiben.
Die Frage ist, ob wir die Reviews im GitLab nutzen, da würde ich gerne Ja sagen. Kann es aber nicht, weil wir derzeit noch keinen GitLab einsetzen, sondern bei uns der Workflow noch über Mail
funktioniert und der hat Schwierigkeiten. Also da zerfasern dann die Threads doch auch mal und ich habe wirklich großen Respekt vor den Maintainern, die das schaffen, die Threads alle wieder einzusammeln
und dann daraus eine vernünftige Lösung, mit der hinterher alle irgendwie glücklich sind, zu bauen. Ich hoffe ganz, ganz, ganz stark, dass wir demnächst irgendwann mal GitLab einsetzen können, um dann einfach auch diesen Review-Prozess, das eben auch nicht erst der Kollege, der die
ganzen Rechtschreibfehler findet, einen eigenen Branch wieder aufmachen muss, sondern die direkt und sofort in dem GitLab korrigieren kann. Du warst vorher noch
die Frage war nach, wie oft wir die Tests laufen lassen. Das passiert automatisch sobald das Prozesshandbuch einmal neu gebaut wird. Wir können die Testsuit manuell starten und ich glaube sogar einmal pro Nacht, also das läuft dann eben zusammen mit, wenn die Testsuit eh einmal
angestoßen wird, laufen nachts einmal alle Tests durch. Wir haben die ja nicht explizit für das Prozesshandbuch aufgesetzt, sondern nutzen die eigentlich, um unsere Software zu testen. Habt ihr schon das Problem gehabt, dass ihr den Prozess so formalisiert habt, dass der Plan bei Durchführung und Konflikt begraben ist?
Die Frage war, ob uns der Formalismus oder die formalisierte Prozesslandschaft einen beinstellt und wir feststellen, Das, was eigentlich sinnvoll wäre, aber der Prozess, was anderes vorschreibt, da gilt
die Regel Common Sense und im Zweifel dürfen, dann sollen die Prozesse angepasst werden. Also wenn wir wirklich feststellen, da gibt es Konflikte, dann muss man natürlich
in der Situation entscheiden, was machen wir jetzt und naja, daraus ergibt sich der Prozess ist wahrscheinlich falsch oder fehlerhaft oder nicht so gut. Auch das natürlich ein großer Vorteil einer sehr kleinen Firma. Ja bitte. Die Frage war, ob wir einen klassischen
Word-Nutzer in unserer Prozesswissenschaft bekommen haben. Ja. Also jein, ich habe natürlich eine Kollegin in der Buchhaltung, die auch sonst viele Formulare eben dann bei uns
ist nicht Word. Wir sind tatsächlich eine reine Open Source Software. Wir nutzen nur Open Source Tools. Man kann sich bei uns bewerben, so für den Werbeblock. Ja,
auch da ist es kein Problem gewesen. Auch die Kollegin ist mittlerweile fit da drin, geht zu nutzen. Ich glaube, sie nutzt Nano oder Kate, aber das ist ja jedem überlassen.
Wir geben keine Tools vor, die dann genutzt werden sollen, sondern es geht darum, dass jeder sich schon seinen Editor so einrichten kann, dass er damit gut arbeiten kann. Ich habe in Chemnitz das Feedback bekommen, dass dort eben in einer Firma auch für sonst
klassische Word-Nutzer GitLab eingesetzt wurde und die da sehr zufrieden mit sind und das hervorragend funktioniert. Mein Kollege hatte gerade noch die Anmerkung,
dass GitLab einen Web-Editor hat, der für sehr viele Leute gut funktioniert, der auch unterschiedliche Funktionen unterstützt. Ja, Bisse.
Die Frage ist gerade, ob wir die Prozesse nur seriell bearbeiten oder eben auch mit kollaborativ daran arbeiten. Im Moment würde ich sagen, ist es mehr seriell. In der
Diskussion kann das natürlich Auszüge von kollaborativen Arbeiten haben, aber allein die zeitliche Beschränkung und wer dafür zuständig ist, die Prozesse zu schreiben, das bin halt meistens ich. Ich bin mir nicht ganz sicher, wie es in dem
Entwicklerhandbuch gehandhabt wird. Ich glaube, dort ist das kollaborative Arbeiten noch deutlich ausgeprägter und da sitzen dann aber auch häufig die Kollegen direkt nebeneinander und naja, das ist halt das Schöne an der Firma, wenn wir eben alle
zusammen arbeiten. Im Zweifel haben wir noch das IRC, um dort uns mal schnell abzustimmen. Ja, bitte. Wie weit habe ich von der Idee bis zur Realisierung benötigt? Ich hatte
den Vorteil, dass die Prozesse ja alle schon irgendwie im Wiki standen. Das heißt, im ersten Schritt habe ich mir einfach nur das Read the Docs einmal gestartet bzw.
initialisiert. Das ging, glaube ich, in drei Minuten. Dann habe ich mir überlegt, wie denn so eine sinnvolle Ordnerstruktur aussieht und wie ich das gestalten möchte. Das hat ein bisschen länger gedauert. Da haben wir natürlich auch mit mehreren Kollegen zusammen überlegt und dran gesessen, was wollen wir in den Prozessen haben,
was ist uns wichtig, wie sollen die Prozesse aufgebaut sein. Und dann habe ich im allerersten Schritt die Prozesse, die ja alle in irgendeiner Form schon gültig waren, einfach erstmal nur stumpf in das neue Prozesshandbuch kopiert. Ein bisschen natürlich an die
RST-Syntax angepasst, ein bisschen an der Formatierung gefeilt. Aber gut, dann musste mein Chef natürlich trotzdem nochmal drüberschauen und die Prozesse alle freigeben. Das hat dann ein englisches Frühstück gekostet, ihn dazu zu bringen,
aber das ging dann relativ gut. Ich schätze zwei Wochen. Ich könnte jetzt versuchen, mal in einem Stundenzettel zusammenzurechnen. Dann ging es natürlich an die Arbeit,
die Prozesse nochmal wirklich alle anzuschauen, zu überarbeiten, zu gucken, wo es passt. Ich habe so eine Vermutung, dass ich so etwa anderthalb bis zwei Stunden für einen Prozess brauche.
Also, wie handhaben wir, wenn unsere Tests fehlschlagen, also wenn wir einen Prozess ausrollen wollen und ein anderer Prozess ist gerade abgelaufen und muss einem Review unterzogen werden. Es kommt ganz drauf an. Also jeder Prozess hat natürlich
ein eigenes Review-Datum. Das heißt, das Prozesshandbuch insgesamt läuft ja nicht ab, nur weil ich einen neuen Prozess ausrolle. Das heißt, erstmal wird natürlich der neue Prozess ausgerollt, wenn der soweit beschlossen ist. Und wenn man gerade noch ein bisschen Zeit hat, guckt man sich halt den gerade angelaufenen Prozess an und naja, es ist häufig genug,
dass es reicht. Ja, wir haben uns ihn angeschaut, er funktioniert noch genauso, wie er da drin steht. Wir ändern jetzt einfach nur die Daten. Und das kann man dann fast mit einmal machen. Also, ja, ich wiederhole es nochmal kurz für das Video. Ein fehlgeschlagener
Test blockiert nicht das Deployment. Ja, danke. Sonst noch Fragen? Dann wünsche ich
euch eine schöne weitere Konferenz. Viel Spaß!