Ich bin derzeit Entwickler bei einer kleinen Softwareentwicklungsfirma, und wir beginnen, agile Philosophien (insbesondere Scrum) in unsere Kultur und unseren Projektmanagementstil aufzunehmen. Wir haben nur wenige Entwickler, daher ist es wichtig, dass abrechnungsfähige Arbeit und Effizienz optimiert werden.
Aus persönlicher Erfahrung haben unsere Entwickler immer mehr Arbeit als unsere Designer, die erfahrungsgemäß durchschnittlich 60 % weniger Arbeit pro Projekt haben. Wenn eine einzelne User Story auf der Grundlage einer einheitlichen Anstrengung (Story-Point-Beitrag) geschätzt wird, sehe ich einige Probleme, die auftreten:
Soweit ich das beurteilen kann, führt dies zu einem Sprint, der mit einem erheblichen Ungleichgewicht der Arbeit beginnt und zu den Entwicklern neigt. Dies wird aufgrund einer einheitlichen Schätzung nicht ersichtlich sein.
Ist es stattdessen besser, pro Person zu schätzen und aufzuhören, wenn die Entwickler einen vollen Sprint haben? Sicher, die Designer werden immer noch früh fertig sein, aber zumindest ist es durch ihre eigene personalisierte Geschwindigkeit bekannt.
Striktes Scrum mag sagen, dass der Designer daran arbeiten sollte, auf alternative Weise zusätzlichen Wert zu schaffen (Verfeinerung, Code-Schuld im CSS usw.), aber da wir klein sind, müssen wir sicherstellen, dass jede Stunde, die wir investieren, einen signifikanten Mehrwert bringt , just in time Wert heraus.
BEARBEITEN: Dies könnte zu einem Phänomen führen, bei dem Geschichten kontinuierlich in äquivalente Bereiche geschnitten werden - bis zu einem gewissen Punkt -, aber ich denke nicht, dass das der Punkt ist.
Ich versuche, mich um diese Frage zu kümmern, also verzeihen Sie mir, wenn ich von der Basis abweiche. Ich werde dies unter der Annahme Ihrer Abrechnung als Team angehen. Ich gehe auch davon aus, dass ein Designer eine UI-Person ist.
Das Team hat eine Geschwindigkeit, nicht die Individuen. Ihre Sprintplanung muss sich also darauf konzentrieren, was das gesamte Team im Sprint bewältigen kann. Wenn Ihre Entwickler Ihre Einschränkung darstellen, wird der Sprint für diese Einschränkung geplant.
Wenn Sie versuchen, die Arbeit für jeden Funktionsbereich zu planen, können Sie schnell aus dem Takt geraten und sich selbst noch mehr Probleme bereiten. Dies passiert häufig, wenn Unternehmen versuchen, agil zu werden, während sie die Qualitätssicherung als separaten Sprint oder sogar später im selben Entwicklungssprint beibehalten. Wenn ein QA-Team nicht über eine vollständige Automatisierung verfügt, kann es selten mit einem leistungsstarken Entwicklungsteam mithalten. Das Entwicklungsteam ist der Qualitätssicherung also immer weiter voraus, und das bedeutet, dass zwischen der Erstellung und Identifizierung eines Fehlers immer mehr Zeit vergeht. Je später Sie identifizieren, desto schwieriger ist es zu beheben.
Um auf Ihr Beispiel zurückzukommen: Wenn Ihre Designer die gesamte Arbeit, die sie erledigen müssen, in der Hälfte der Zeit der Ingenieure erledigen können, dann haben Sie zu viele Designer oder nicht genügend Ingenieure für die Planung. Mehrere Lösungen hierfür, darunter: - Cross-Training: Designer könnten Test- oder Programmierarbeiten lernen. Ein starkes agiles Team hat die Fähigkeit, mehr als eine Rolle zu übernehmen. - Teilen Sie Ihre Designer. Angenommen, Sie haben zwei Engineering-Projekte, lassen Sie die Designer an beiden arbeiten. Dies ist nicht ideal, da es den Fokus auf sich zieht, passiert aber häufig bei gemeinsam genutzten Ressourcen wie Datenbank, Lokalisierung und dergleichen. - Stellen Sie mehr Ingenieure ein: Stellen Sie genügend Ingenieure ein, um mit den Designern Schritt zu halten, und liefern Sie mehr Produkte schneller aus. - Reduzieren Sie die Anzahl der Designer: Einer dieser Elefanten im Raum, über die niemand sprechen möchte. Macht es nicht weniger gültig, nur weniger wünschenswert.
Joel Bancroft-Connors
Joel Bancroft-Connors
Daniel
AdrianGW