Bewerten Sie den Entwickler anhand objektiver Daten

Leider leben wir nicht in einer idealen Welt, in der jeder Entwickler ein ideales und ausgewogenes Produktivitätsniveau hat, während wir uns auf Aufgaben konzentrieren und diese von einer zur anderen durchdenken. Die Teamzusammenarbeit ist auch nicht immer so konzipiert, dass alle Teammitglieder mit maximaler Effizienz arbeiten. Wie bei vielen Problemen im Allgemeinen spart die frühe Entwicklung im Entwicklungsteam Ressourcen, Managementnerven und schafft eine gute Arbeitsatmosphäre.

In einem kleinen Team kann der Teamleiter versuchen, alles, was passiert, anhand subjektiver Gefühle zu beurteilen. Je größer das Unternehmen, desto wichtiger ist es jedoch, objektive Daten und Metriken zu verwenden. Alexander Kiselev ( AleksandrKiselev ) und Sergey Semenov haben in ihrem Bericht über TeamLead Conf gezeigt, wie Sie die bereits gesammelten Daten verwenden, wo Sie zusätzliche Daten erhalten und wie sie zusammen helfen können, nicht offensichtliche Probleme zu identifizieren. Und selbst nachdem sie die Erfahrung vieler Kollegen gesammelt hatten, schlugen sie Lösungen vor.


Zu den Referenten: Alexander Kiselev und Sergey Semenov, wir sind seit mehr als 8 Jahren in der IT tätig. Beide gingen vom Entwickler zum Teamleiter und weiter zum Produktmanager. Jetzt arbeiten sie am Analysedienst GitLean, der automatisch Analysen von Entwicklungsteams für Teamleiter und CTO sammelt. Ziel dieses Dienstes ist es, dass technische Manager ihre Entscheidungen auf der Grundlage objektiver Daten treffen können.

Problemstellung

Wir haben beide als Teamleiter gearbeitet und waren bei unserer Arbeit häufig mit dem Problem der Unsicherheit und Zweideutigkeit konfrontiert.


Infolgedessen war es oft notwendig, Entscheidungen blind zu treffen, und manchmal war nicht klar, ob es besser oder schlechter war. Daher haben wir uns die auf dem Markt vorhandenen Lösungen angesehen, die Methoden zur Bewertung der Leistung von Entwicklern untersucht und festgestellt, dass es keinen Service gibt, der unsere Anforderungen erfüllt. Deshalb haben wir uns entschlossen, es selbst zu erstellen .

Heute werden wir darüber sprechen, was Sie den Daten mitteilen können, die Sie bereits gesammelt haben, aber höchstwahrscheinlich nicht verwenden.


Dies ist in zwei Hauptfällen erforderlich.

Leistungsbeurteilung ist ein ziemlich komplexer und subjektiver Prozess. Es wäre großartig, automatisch Fakten über die Arbeit des Entwicklers zu sammeln.

Wir haben mit Vertretern eines großen deutschen Unternehmens mit einem großen Entwicklungspersonal gesprochen. Ungefähr einmal im Jahr wurde die gesamte Entwicklungsarbeit für zwei Wochen eingestellt, und nur das gesamte Unternehmen führte eine Leistungsüberprüfung durch. Die Entwickler schrieben den ganzen Tag über anonyme Anzeigen für Kollegen, mit denen sie ein Jahr lang zusammengearbeitet hatten. Wenn dieses Unternehmen die Möglichkeit hätte, Fakten automatisch zu sammeln, würde es sich eine Menge Zeit sparen.

Der zweite Aspekt ist die Überwachung der aktuellen Situation im Team. Ich möchte die auftretenden Probleme schnell verstehen und schnell darauf reagieren.

Entscheidungsmöglichkeiten

Es kann mehrere Lösungen geben.


Erstens können Sie überhaupt keine Analysen verwenden , sondern nur Ihre subjektive Einschätzung. Dies funktioniert, wenn Sie ein Teamleiter in einem kleinen Team sind. Wenn Sie jedoch bereits CTO sind und viele Teams haben, können Sie Ihre subjektive Einschätzung nicht verwenden, da Sie nicht alles wissen. Sie müssen auf eine subjektive Bewertung Ihrer Timlids zurückgreifen, und dies ist ein Problem, da Timlids die subjektive Bewertung häufig ganz anders angehen.


Dies ist das nächste, was zu tun ist. Da subjektive Einschätzungen oft nicht ausreichen, können Sie verwirrt werden und Fakten von Hand sammeln .

Zum Beispiel vermutete ein CTO, mit dem wir gesprochen hatten, dass das Team eine Codeüberprüfung zu langsam durchführte, aber es gab nichts, was sie präsentieren könnte. Da er nur ein vages Gefühl hatte, beschloss er, die Fakten zu sammeln, nur ein paar Wochen, um das Team zu beobachten. CTO zeichnete die Zeit auf, die das Team für die Überprüfung benötigte, und was er am Ende herausfand, schockierte ihn. Es stellte sich heraus, dass zwei Senioren bei der Codeüberprüfung lange Zeit in Konflikt geraten waren, obwohl sie es überhaupt nicht herausgenommen hatten. Sie saßen wie Mäuse, niemand schrie jemanden an - das Team wusste überhaupt nichts. Das einzige, was sie taten, war, regelmäßig zum Kühler zu gehen, sich etwas mehr Wasser einzuschenken und zu rennen, um witzige Antworten in einer Codeüberprüfung an ihren Feind in Pull-Anfrage zu schreiben.

Als CTO herausfand, stellte sich heraus, dass das Problem so alt war, dass es unmöglich war, irgendetwas zu tun, und am Ende musste einer der Programmierer entlassen werden.


Jira-Statistiken sind eine häufig verwendete Option. Dies ist ein sehr nützliches Tool, in dem Informationen zu Aufgaben enthalten sind, das jedoch auf hohem Niveau ausgeführt wird. Es ist oft schwierig zu verstehen, was speziell in einem Team passiert.

Ein einfaches Beispiel - der Entwickler im vorherigen Sprint hat 5 Aufgaben erledigt, diese - 10. Kann man sagen, dass er angefangen hat, besser zu arbeiten? Es ist unmöglich, weil die Aufgaben völlig unterschiedlich sind.


Die letzte Lösung besteht darin, einfach die Ärmel hochzukrempeln und ein eigenes Skript für die automatische Datenerfassung zu schreiben. Auf diese Weise kommen mehr oder weniger alle CTOs in großen Unternehmen. Er ist der produktivste, aber natürlich der schwierigste. Über ihn werden wir heute sprechen.

Ausgewählte Lösung

Die gewählte Lösung besteht also darin, Ihre Skripte zu beschädigen, um Analysen zu sammeln. Die Hauptfragen sind, wo Daten abgerufen und was gemessen werden soll.

Datenquellen

Die wichtigsten Datenquellen, in denen Informationen über die Arbeit des Entwicklers gesammelt werden, sind:

1. Git - die Hauptentitäten: Commits, Zweige und Code in ihnen.
2. Codeüberprüfungstools - Git-Hosting-Dienste, die Codeüberprüfungen hosten, enthalten Informationen zu Pull-Request, die verwendet werden können.
3. Task-Tracker - Informationen zu Aufgaben und ihrem Lebenszyklus.

Zusätzliche Datenquellen:

1. Messenger - Dort können Sie beispielsweise eine Stimmungsanalyse durchführen und die durchschnittliche Antwortzeit des Entwicklers auf eine Informationsanfrage berechnen.
2. CI-Services , die Informationen zu Builds und Releases speichern.
3. Teamumfragen.

Da alle Quellen, über die ich oben gesprochen habe, mehr oder weniger Standard sind und die letzte nicht so Standard ist, werde ich etwas mehr darüber sprechen.


Ein anderer CTO teilte diese Methode mit uns. Am Ende jeder Iteration schickte er dem Team automatisch eine Umfrage, in der es nur zwei Fragen gab:

1. Wie wichtig war Ihrer Meinung nach das, was wir in dieser Iteration getan haben?
2. Denken Sie, dass das, was wir tun, interessant war?

Dies ist eine ziemlich billige Methode, um die Stimmung in einem Team zu messen und möglicherweise Probleme mit der Motivation zu bekommen.

Was und wie messen?

Zunächst werden wir die Messmethode diskutieren. Eine gute Metrik sollte 3 Fragen beantworten:

1. Ist es wichtig Es muss nur gemessen werden, welche Signale über etwas Bedeutendes für das Unternehmen vorliegen.
2. Ist es schlechter / besser / gleich geworden? Metrisch sollte klar sein, ob es besser oder schlechter geworden ist.
3. Was zu tun ist? Aus der Metrik sollte klar sein, was zu tun ist, um die Situation zu korrigieren.

Im Allgemeinen lohnt es sich, dem Prinzip zu folgen:

Messen Sie, was Sie wollen und können sich ändern.

Es ist sofort erwähnenswert, dass es keine universelle Metrik gibt, und wir werden heute aus folgenden Gründen nicht über eine universelle Metrik sprechen:

• Der Entwickler hat viele Aspekte der Aktivität - er arbeitet mit Anforderungen, schreibt Code, testet, führt Codeüberprüfungen durch, führt Bereitstellungen durch - und es ist unmöglich, all dies in einer einzigen universellen Metrik zusammenzufassen. Daher ist es besser, sich auf einzelne Fälle zu konzentrieren, die erkannt werden können.
  
• Der zweite Grund, warum sich die einzige Metrik nicht lohnt, ist, dass eine Metrik leicht zu umgehen ist, da die Entwickler klug genug sind und herausfinden, wie sie es alleine machen können.

Neuer Ansatz

Aus diesem Grund haben wir einen Ansatz formuliert, bei dem wir von Problemen ausgehen: Wir versuchen, bestimmte Probleme zu identifizieren und eine Reihe von Metriken für sie auszuwählen, die sie erkennen. Ein guter Entwickler wird der Entwickler mit der geringsten Anzahl von Problemen genannt.


Worauf basiert unsere Auswahl an Problemen? Es ist ganz einfach: Wir haben ein Interview mit 37 CTOs und Teamleitern geführt, die über die Probleme in ihren Teams und darüber sprachen, wie sie diese Probleme lösen.

In der daraus resultierenden riesigen Liste haben wir Life Hacks und Metriken für diese Probleme priorisiert und gesammelt. Wir haben alle Probleme in zwei Gruppen unterteilt:

1. Probleme eines einzelnen Entwicklers (der Entwickler ist für diese Probleme verantwortlich).
   
   
2. Teamprobleme. Das Team ist für diese Probleme verantwortlich. Um sie zu lösen, müssen Sie mit dem gesamten Team zusammenarbeiten und die Prozesslösungen ändern.
   
   

Lassen Sie uns jedes Problem im Detail betrachten, welcher Schlüssel aus den Metriken ausgewählt werden kann. Beginnen wir mit den einfachsten Problemen und bewegen uns langsam entlang des Komplexitätsgradienten zu den am schwierigsten zu messenden.

Entwicklerprobleme

Entwickler wenig Leistung

Darüber hinaus bedeutet „geringe Leistung“ normalerweise, dass der Entwickler fast nichts tut . Bedingt hängt ein Ticket in Jira daran, es berichtet irgendwie darüber, aber es passiert wirklich keine Arbeit. Es ist klar, dass dieses Problem früher oder später auftreten wird, Sie werden es finden, aber es wäre cool, es automatisch zu tun.

Wie kann das gemessen werden?

Das erste, was mir in den Sinn kommt, ist nur die Anzahl der aktiven Tage mit dem Entwickler zu betrachten. Der aktive Tag wird als der Tag bezeichnet, an dem der Entwickler mindestens ein Commit durchgeführt hat. Für die Vollzeitentwickler beträgt die charakteristische Anzahl aktiver Tage pro Woche mindestens 3. Wenn weniger, dann vermuten wir, dass der Entwickler nicht viel leisten wird.

Offensichtlich reicht schon die Anzahl der aktiven Tage nicht aus. Ein Entwickler konnte einfach Code schreiben und nicht festschreiben - schrieb, schrieb und dann eines Tages eine Menge Code festschrieb.

Daher ist die nächste Einschränkung, die wir auferlegen, dass der Entwickler auch einen kleinen Code haben muss . Wie bestimme ich den Schwellenwert "kleiner Code"? Wir empfehlen, dass Sie es so klein machen, dass jeder, genauso wie ein leistungsfähiger Entwickler, es leicht überwinden kann. In unserem Service für JS sind dies beispielsweise etwa 150 Codezeilen und für Clojure 100 Codezeilen.

Warum so eine kleine Schwelle? Die Idee ist, dass wir nicht cool arbeitende Entwickler von durchschnittlich arbeitenden Entwicklern trennen wollen, sondern diejenigen, die fast nichts tun, von denen, die zumindest eine vernünftige Menge an Arbeit leisten.

Aber selbst wenn der Entwickler nur wenige aktive Tage und wenig Code hat, bedeutet dies überhaupt nicht, dass er nicht funktioniert hat. Er könnte zum Beispiel Fehlerbehebungen vornehmen, die eine kleine Menge Code erfordern. Infolgedessen scheint eine Person viele Aufgaben erledigt zu haben, aber sie hat möglicherweise nur wenige Codes und aktive Tage. Das heißt, wir berücksichtigen die Anzahl der Aufgaben .

Das nächste, was es wert ist, gesehen zu werden, ist die Menge an Codeüberprüfungen , die er durchgeführt hat, da eine Person keine Aufgaben ausführen und keinen Code schreiben konnte, sondern vollständig in die Codeüberprüfung eintauchte. So etwas passiert.

Wenn also für all diese Metriken - und nur so! - Der Entwickler erreicht keine Schwellenwerte. Sie können vermuten, dass er keine gute Leistung erbringt.

Was tun?

Erstens, wenn Sie einen legitimen Grund kennen, müssen Sie überhaupt nichts tun - zum Beispiel ist ein Entwickler geschult oder hat einen freien Tag. Wenn Sie den legitimen Grund nicht kennen, lohnt es sich wahrscheinlich, mit einer Person zu sprechen . Wenn ein legitimer Grund nicht auftritt, lohnt es sich, ihn weiter zu überwachen, und wenn sich dieses Problem manchmal wiederholt, lohnt es sich wahrscheinlich, sich von einem solchen Entwickler zu verabschieden.

Dies war das einfachste und provokanteste Problem. Gehen wir weiter zu den schwereren.

Entwickler recycelt

Dies ist auch eine häufige Geschichte. Wenn eine Person es verarbeitet, brennt es aus, demotiviert es schließlich und kann infolgedessen das Unternehmen verlassen. Einer der technischen Manager, mit denen wir gesprochen haben, erzählte eine solche Geschichte. Er arbeitete für eine amerikanische Firma, in der die Kultur der Rallyes wild entwickelt wurde. Infolgedessen haben alle Entwickler, als sie zur Arbeit kamen, einfach das getan, was sie gesammelt hatten, und sie haben den Code nach Stunden und an Wochenenden geschrieben. Infolgedessen erreichte der Jahresumsatz der Entwickler im Unternehmen 30%, obwohl die Industrienorm 6% beträgt.

Infolgedessen wurde das gesamte technische Management, das aus 30 Personen bestand, aus diesem Amt entlassen. Um dies nicht zur Sprache zu bringen, möchte ich dieses Problem rechtzeitig finden.

Wie kann das gemessen werden?

In der Tat ist nichts zu kompliziert - schauen wir uns die Menge an Code an, die der Entwickler nach Stunden schreibt. Wenn diese Codemenge bedingt vergleichbar oder größer ist als während der Arbeitszeit, verarbeitet der Entwickler sie explizit.

Offensichtlich leben Entwickler nicht als ein einziger Code. Ein häufiges Problem ist, dass genügend Zeit für den Code - den Hauptjob - vorhanden ist, jedoch nicht mehr für die Codeüberprüfung. Infolgedessen wird die Codeüberprüfung auf Abende oder Wochenenden übertragen. Dies kann einfach anhand der Anzahl der Kommentare in der Pull-Anfrage nach Stunden verfolgt werden .

Der letzte explizite Auslöser ist eine große Anzahl paralleler Aufgaben . Es gibt eine vernünftige Einschränkung von 3-4 Aufgaben für den Entwickler. Sie können sie per Git oder Jira verfolgen - wie Sie möchten. Es funktioniert ziemlich gut.

Was tun?

Wenn Sie einen Recycling-Entwickler finden, sollten Sie zuerst seinen Kalender überprüfen, um festzustellen, ob er mit nutzlosen Rallyes überladen ist. Wenn es überlastet ist, ist es ratsam, sie zu reduzieren und idealerweise einen Besprechungstag zu planen - einen bestimmten Tag, an dem der Entwickler die meisten seiner längsten Besprechungen konzentriert, damit er an anderen Tagen normal arbeiten kann.

Wenn dies nicht funktioniert, muss die Last neu verteilt werden . Dies ist eigentlich eine ziemlich komplizierte Frage - wie es geht. Es gibt viele verschiedene Möglichkeiten. Wir werden nicht tief gehen, aber beachten Sie den coolen Bericht über HighLoad 2017 von Anton Potapov, in dem dieses Thema sehr genau betrachtet wurde.

Der Entwickler konzentriert sich nicht auf die Freigabe von Aufgaben

Ich möchte verstehen, wie viele solcher Entwickler in Ihrem Team sind und wie viel es zeitlich kostet.


Es ist durchaus üblich, dass ein Entwickler eine Aufgabe übernimmt, sie beim Überprüfen, Testen in den Status versetzt - und sie vergisst. Dann kehrt sie zur Überarbeitung zurück und hängt dort unklar, wie viel Zeit. Ich selbst hatte einmal einen Entwickler in meinem Team. Ich habe das Problem lange Zeit unterschätzt, bis ich einmal die Zeit berechnet habe, die im Durchschnitt verschiedene Ausfallzeiten in Anspruch nimmt. Als Ergebnis stellte sich heraus, dass die Aufgaben dieses Entwicklers im Durchschnitt 60% der Zeit der Veröffentlichung untätig waren.

Wie kann das gemessen werden?

Zunächst müssen Sie alle Ausfallzeiten messen, die vom Entwickler abhängen. Dies ist die Zeit für die Korrektur nach Überprüfung und Testen des Codes . Wenn Sie eine kontinuierliche Lieferung haben, ist dies das Release-Timeout. Zu jeder dieser Zeiten sollte eine angemessene Einschränkung auferlegt werden - beispielsweise nicht mehr als ein Tag.

Der Grund ist wie folgt. Wenn ein Entwickler morgens zur Arbeit kommt, wäre es cool, zuerst die Aufgaben mit der höchsten Priorität zu analysieren. Die Aufgaben mit der höchsten Priorität, wenn es keine Fehlerbehebungen oder etwas sehr Wichtiges gibt, sind Aufgaben, die der Veröffentlichung und Veröffentlichung am nächsten kommen.

Ein weiterer cooler Auslöser für dieses Thema ist die Menge an Codeüberprüfungen, die vom Entwickler wie von einem Prüfer abhängt. Wenn eine Person ihre Aufgaben vergisst, bezieht sie sich höchstwahrscheinlich auch auf die Aufgaben ihrer Kollegen.

Was tun?

Wenn Sie einen solchen Entwickler finden, lohnt es sich eindeutig, zu ihm zu gehen und zu sagen : "Sehen Sie, es sind 30-40% Ihrer Zeit für Ausfallzeiten!" Dies funktioniert normalerweise sehr cool. In meinem Fall hatte es beispielsweise einen solchen Effekt: dass das Problem fast vollständig weg ist.

Daher lohnt es sich nach Möglichkeit, sich sofort mit Prozesslösungen zu befassen. Dies kann beispielsweise eine Begrenzung der Anzahl aktiver Aufgaben sein . Wenn Ihr Budget und Ihre Zeit dies zulassen, können Sie einen Bot schreiben oder einen Dienst verwenden, der den Entwickler automatisch anpingt , wenn sich die Aufgabe zu lange in einem bestimmten Status befindet. Dies ist wahrscheinlich die coolste Lösung hier.

Der Entwickler denkt nicht über genügend Aufgaben nach

Ich denke, Sie kennen die Symptome - dies sind unverständliche Schätzungen der Zeit, die für die Erledigung von Aufgaben benötigt wird, in die wir nicht fallen, die langen Fristen am Ende, die Zunahme der Anzahl von Fehlern in Aufgaben - im Allgemeinen nichts Gutes.


Wie kann das gemessen werden?

Ich denke, Sie kennen die Symptome - dies sind unverständliche Schätzungen der Zeit, die für die Erledigung von Aufgaben benötigt wird, in die wir nicht fallen, die langen Fristen am Ende, die Zunahme der Anzahl von Fehlern in Aufgaben - im Allgemeinen nichts Gutes.

Wie kann das gemessen werden?

Dazu müssen wir zwei Metriken einführen, von denen die erste Churn-Code ist.


Churn ist ein Maß dafür, wie viel Code ein Entwickler bedingt vergeblich schreibt.

Stellen Sie sich die Situation vor. Am Montag begann der Entwickler mit einer neuen Aufgabe und schrieb 100 Codezeilen. Dann kam Dienstag, er schrieb weitere 100 neue Codezeilen in dieser Aufgabe. Leider ist es so gekommen, dass er am Montag 50 Codezeilen löscht und die Aufgabe freigibt. Infolgedessen schienen 200 Codezeilen in der Aufgabe erstellt worden zu sein, aber nur 150 überlebten bis zur Veröffentlichung, und 50 wurden vergeblich geschrieben. Diese 50 nennen wir Churn. In diesem Beispiel betrug der Entwickler Churn 25%.

Unserer Meinung nach ist ein hohes Maß an Abwanderung ein cooler Auslöser dafür, dass sich der Entwickler die Aufgabe nicht ausgedacht hat.

Es gibt eine Studie eines amerikanischen Unternehmens, in der das Churn-Niveau von 20.000 Entwicklern gemessen wurde und der zu dem Schluss kam, dass ein guter Churn-Code im Bereich von 10 bis 20% liegen sollte.

Es gibt jedoch zwei wichtige Bedingungen:

1. High Churn ist in Ordnung, wenn Sie beispielsweise einen Prototyp oder ein neues Projekt erstellen. Dann kann es für mehrere Monate gleich 50-60% sein. Es gibt nichts zu befürchten. Grob gesagt hängt Churn von der Stufe des Produkts ab - je stabiler das Produkt, desto niedriger sollte es sein.
2. Churn — . . - . delivery .

, , , , Fixed Tasks, . , .

, bug fixes , bug fixes . bug fixes 3 , , . , , , .

— . , , , - .

?

, , , . , , , estimation ..

CTO, , workflow, , . , , , - , .

Churn Fixed Tasks

, , :

• commit message, . commit message, , git .
• git-squash commit' , Churn .
• git. merge master, merge , . — , , Churn Fixed Tasks.

, — , . , , , . , - .

, , - 3-4 . , .

?

— - , , .


, 3 , , ( ), .

, , . — , .

— , — — , , .

Wie gehe ich damit um?

. , , . - , .

— , , . . , , . .

30-50 50-60 %. , .

, , . , , , . .


, — . product- , . , , .

?

product- , ?

, product- , :

• Churn, ;
• , , estimation;
• in progress product-.

?

product- : «, Churn - — ».

« » , 1-2 . , product-, .


. , , .

, , , . , , - , , . , . .

?

, , :

• ;
• ;
• ;
• -, - , ;
• .

?

-, , , , .

-, , , , , , .

— - , . best practise, , , , . 3 , 3 .


, — . , . - , , -. , , CTO, , 100%. , - .

?

, legacy refactoring . , . . , , , .


, legacy refactoring , , complexity , , .

?

, , . , CTO. , .

CTO , , Jira «» . , - estimation . , — , ..

CTO . , , , «Hack». - -, : « Hack — », . grep' «Hack» , .

. .

:

1. . , , Churn legacy refactoring. , .
   
2. . , , , — git , git-. — , .
3. , . , , .
4. Die meisten der hier aufgeführten Metriken funktionieren nur für Mehrzeitentwickler, da sich nur die Aktivitäten von Mehrzeitentwicklern in den verfügbaren Datenquellen gut widerspiegeln: git, Jira, GitHub, Instant Messenger usw.

Schlussfolgerungen

Wir wollten Ihnen Folgendes vermitteln:

• Entwickler und Team können und sollten gemessen werden . Es kann schwierig sein, aber es kann getan werden.
  
• Es gibt keinen universellen kleinen Satz von KPI . Für jedes Problem müssen Sie Ihre hochspezialisierten Metriken auswählen. Es muss beachtet werden, dass Sie nicht einmal die einfachsten Metriken vernachlässigen sollten. Zusammen können sie gut arbeiten.
  
• Git kann viele interessante Dinge über Entwicklung und Entwickler erzählen, aber Sie müssen bestimmte Praktiken befolgen, damit auf Daten bequem zugegriffen werden kann, einschließlich:
  
  • Anzahl der Aufgaben in Commits;
  • kein Kürbis;
  • Sie können die Release-Zeit bestimmen: Zusammenführen in Master, Tags.

Nützliche Links und Kontakte:

• In der Präsentationspräsentation gibt es mehrere Bonusprobleme und Metriken für sie.
  
• Autorenblog mit hilfreichen Artikeln für Entwicklungsmanager
  
• Telegrammkontakte: @avkiselev (Alexander Kiselev) und sss0791 (Sergey Semenov).

Bei TeamLead Conf diskutieren sie viele verschiedene Probleme bei der Verwaltung eines Entwicklungsteams und suchen nach Lösungen. Wenn Sie bereits einen Teil des Weges gegangen sind, mehr als eine Beule gefüllt haben, auf einen Rechen getreten sind, verschiedene Ansätze ausprobiert haben und bereit sind, Schlussfolgerungen zu ziehen und Ihre Erfahrungen zu teilen, warten wir auf Sie. Sie können sich bis zum 10. August für eine Aufführung bewerben .

Von den Teilnehmern wird auch erwartet, dass sie stärker involviert sind. Beginnen Sie mit der Buchung eines Tickets und versuchen Sie dann zu formulieren, was Sie am meisten begeistert. Dann können Sie Ihre Schmerzen besprechen und das Beste aus der Konferenz herausholen.