Wir haben kürzlich eine neue Managementmethode eingeführt, die besagt, dass es keine Rollen im Team gibt (ein „funktionsübergreifendes“ Team, in dem „alle Teammitglieder Entwickler sind“) und jeder alles tun sollte, also haben wir jetzt UX-Designer und QA-Ingenieure, die versuchen, dies zu tun Schiffscode mit etwas Copy Paste und Online-Kursen.
Ich war noch nie ein Manager und ich bin kein Manager dieser Leute, aber da wir das halbe Team plötzlich zu Entwicklern haben und als einziger tatsächlicher Softwareentwickler (sorry, wenn abwertend, aber keiner dieser Leute hat vorher Code geschrieben) nicht nur Ich ignoriere Neuling-Slack-Nachrichten. Ich bekomme nichts erledigt.
Es hilft nicht, dass jeder Entwickler eine bestimmte Anzahl von Punkten benötigt, die pro Sprint benötigt werden, und es gibt keinen Unterschied zwischen Menschen, die auf Erfahrung basieren. Die Anfänger-Entwickler sollten wirklich nicht die gleichen Punkterwartungen haben wie Leute, die jahrelang programmiert haben.
Ich habe mich an meinen Vorgesetzten gewandt, aber die Projektmanagementmethode wurde mir von oben vorgegeben. Der Manager ist auch Entwickler und will sich damit nicht wirklich beschäftigen. Sein Manager findet die Methodik seltsam, ist aber nicht bereit, gegen die Leute mit den Zertifizierungen vorzugehen. Grundsätzlich glaube ich nicht, dass es wirklich so viel geändert werden kann, also muss ich lernen, wie man innerhalb des Frameworks arbeitet.
Welche Möglichkeiten habe ich, damit umzugehen? Wie managt man eine Armee wirklich grüner Leute und bekommt nützlichen Code aus ihnen heraus?
Die Vorstellung, dass „jeder ein Entwickler ist“ und „jeder Code schreibt“, ist nicht dasselbe. In diesem Sinne bedeutet „Entwickler“ nicht „Programmierer“, sondern „eine Person oder Sache, die etwas entwickelt“. UX-Designer, Programmierer, Tester, Business-Analysten und andere sind alle an der Entwicklung eines Produkts beteiligt.
Manchmal kann die Idee, dass „jeder ein Entwickler ist“, nützlich sein, um eine Kultur zu schaffen, in der alle gleich sind. Etwas, das ich schon einmal gesehen habe, sind Programmierer, die denken, dass sie besser sind als Tester, oder die einen UX-Designer in Bezug auf Designentscheidungen nicht zurückdrängen. Als Entwickler an alle zu denken, kann jeden in eine Position als gleichberechtigte Mitarbeiter versetzen.
Es gibt keinen Grund, jeden dazu zu bringen, Code zu schreiben. Stattdessen sollte sich jeder mit seinen Fähigkeiten einbringen. Es könnte Möglichkeiten zum Cross-Training geben. Vielleicht können UX-Designer Front-End-Programmierfähigkeiten erlernen, um ein tieferes Verständnis für die Implementierung ihrer Designs zu erlangen. Tester können Programmieren lernen, um White-Box-Tests oder Testautomatisierung durchzuführen. Ebenso können Programmierer diese Fähigkeiten erlernen, um diese Rollen etwas zu entlasten und die Gesamtarbeitslast zu teilen.
Das Problem, dass jeder die gleiche Anzahl von "Punkten" erreichen muss, macht dies wahrscheinlich noch schlimmer. Typischerweise wird die Messung solcher Arbeiten auf Teamebene durchgeführt. Das Team als Ganzes plant und führt die Arbeiten aus. Jeder bringt all seine Fähigkeiten ein, um dem Team zu helfen, die Arbeit zu beenden und qualitativ hochwertige Produkte und Dienstleistungen zu liefern.
Ich glaube nicht, dass dies etwas ist, an dem gearbeitet werden kann, zumindest effektiv. Etwas muss sich ändern, sonst werden Sie Leute haben, die Arbeiten erledigen, für die sie nicht qualifiziert oder qualifiziert sind, im Namen des „Erreichens von Punkten“, anstatt ihr Wissen und ihre Erfahrung zu den Zielen des Teams beizutragen.
es gibt keine Rollen im Team (ein „funktionsübergreifendes“ Team, in dem „alle Teammitglieder Entwickler sind“)
Eine Sache, die ich anmerken möchte, ist , was genau funktionsübergreifend bedeutet :
Es ist kein Team, in dem jedes Mitglied alles kann. Vielmehr ist es ein Team, das alles kann.
Was ich in erster Linie vorschlagen würde, ist zu bestätigen, was das obere Management genau mit „funktionsübergreifend“ meint. Es ist möglich, dass das obere Management einfach gesagt hat: „Machen Sie die Teams funktionsübergreifend!“ und das mittlere Management interpretierte dies fälschlicherweise als „Lass jeden alles tun!“. und das ist alles ein großes Missverständnis.
Es hilft nicht, dass jeder Entwickler eine bestimmte Anzahl von Punkten benötigt, die pro Sprint benötigt werden, und es gibt keinen Unterschied zwischen Menschen, die auf Erfahrung basieren.
Ich habe zwei Worte für dich.
Um gut zu sein, müssen Schätzungen auf der Realität beruhen. Geordnet in Bezug auf das Beste, aber am wenigsten wahrscheinlich bis zum Schlimmsten, aber am wahrscheinlichsten:
Es ist üblich, dass Schätzungen vom Team selbst in nicht selbst verwalteten Teams vorgenommen werden. Eine unrealistische Schätzung, die von jemandem auferlegt wird, der mit der Arbeit nicht vertraut ist, ist die zum Speichern verwendeten Bits nicht wert und sollte als solche behandelt werden.
Darüber hinaus muss sich das Management der Auswirkungen von Entscheidungen bewusst sein. Transparenz ist der Schlüssel - das Management, das schlechte Entscheidungen trifft, wenn es alle Fakten hat, ist Inkompetenz, aber das Treffen schlechter Entscheidungen, weil es nicht weiß, was vor sich geht, ist eine vermeidbare Tragödie.
Analogie: „Jeder, der weiß, wie man ein Haus bewohnt, oder der sich dafür interessiert, wie sein Haus aussieht, weiß, wie man ein Haus baut – und der daher weiß, wie er einen sinnvollen Beitrag dazu leisten kann, wie so etwas soll gebaut werden."
Meine Erfahrung: Ich behaupte nicht , es zu wissen. Bitte schenken Sie mir zu Weihnachten keine Home Depot-Geschenkkarte. Ich entscheide mich dafür , professionelle, lizenzierte Auftragnehmer einzustellen . Sie geben mir Stapel von Visitenkarten, und ich verteile sie pflichtbewusst und glücklich.
Beste Empfehlung: „Dieses Schiff sinkt. Auf zu den Rettungsbooten.“
Das riecht für mich nach einem sehr schlimmen Missverständnis von Scrum. Die Absicht war nie, alle so zu homogenisieren, dass sie die gleichen Fähigkeiten haben und die gleichen Aufgaben ausführen, als ob Menschen mit unterschiedlichem Fachwissen austauschbar wären. Vielleicht suchen Sie nach Klarheit darüber, was mit diesen Richtlinien gemeint ist. Wenn Teammitglieder sich gegenseitig schulen möchten, um die Arbeit des anderen zu verstehen, ist das von Vorteil, aber wenn Sie niemanden mit null Erfahrung in dieser Arbeit für die Arbeit eines Entwicklers einstellen würden, dann erwarten Sie nicht, dass ein anderer Mitarbeiter mit anderen Fähigkeiten dies tut besser in einer anderen Rolle. Diese Vorstellung, dass jeder Mitarbeiter eine bestimmte Quote an „Punkten“ erfüllen muss, ist Unsinn. Wenn das wirklich die Richtung ist, die Sie erhalten haben, müssen Sie möglicherweise die Definition von "Punkten" verwerfen,
Bogdan