So halten Sie das Management von unserem Entwicklungsprozess fern

Ich bin ein Softwareentwickler in einem Softwareentwicklungsteam. Die letzten 3 Jahre haben wir für einen internen Kunden an einem neuen Produkt gearbeitet. Jetzt, da dieses Produkt fertig ist, werden wir an wichtigen neuen Funktionen für vorhandene Produkte arbeiten. Nach Schätzungen des Produktmanagements dauert die Entwicklung eines bestimmten Features 150 Stunden. Zusammen mit unserem Projektmanager haben wir einen sehr detaillierten Plan erstellt und wir bemühen uns um 300 Stunden. Gestern haben wir darüber gesprochen und sie denken, wir hätten die Dinge grob überschätzt.

In unserer Planung haben wir Stunden für das Schreiben von Komponententests veranschlagt, um Zeit zu sparen. Die Entscheidung ist noch nicht gefallen und ich werde diese Planung und die Unit-Tests bei Bedarf verteidigen. Was mir hier aber nicht gefällt, ist, dass das Management in unseren Entwicklungsprozess eingreift. Wie halte ich sie aus unserem Entwicklungsprozess heraus? Und welche Argumente könnte ich verwenden, um die Einheitentests an Ort und Stelle zu halten (abgesehen von Qualität und langfristiger Zeitersparnis)?

Nebenbei bemerkt hat unser Unternehmen 3 Ingenieurteams und das Team, in dem ich bin, liefert seine Software pünktlich aus (geben oder nehmen Sie eine Marge von 10%). Während die anderen Teams immer zu spät liefern, vor allem aufgrund von Unterschätzungen in der Planung. Sie planen nur die Codierung und nicht die Verwaltung, Prüfung und Handhabung.

Lassen Sie mich zunächst sagen, ich sympathisiere vollkommen mit Ihrer Position. Es kann frustrierend sein, wenn Sie ein Unverständnis oder eine Kommunikationsstörung zwischen verschiedenen Teilen des Geschäfts haben. Trotzdem denke ich nicht, dass Sie versuchen sollten, sie draußen zu halten. Stattdessen sollten Sie ihnen die Zahlen darüber zeigen, warum dies eine gute Idee ist. Welche Fakten rechtfertigen es, dass Unit-Tests den Aufwand wert sind, den Sie in sie gesteckt haben? Wenn Sie keine haben, sollten Sie mit der Erfassung dieser Zahlen beginnen oder Nachforschungen anstellen, um Ihre Behauptungen zu belegen.

Ich musste mich selbst mit ähnlichen Szenarien auseinandersetzen und beantwortete diese Frage zu einem ähnlichen Thema . Ich habe auch darüber gebloggt, wie ich damit umgegangen bin:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Wenn Sie keine Lust haben, nach Links zu suchen, wiederhole ich meine Zusammenfassung der entsprechenden Frage:

Zusammenfassend habe ich unsere geschätzten Stunden mit den tatsächlichen Stunden für das Projekt verglichen und dann unsere Fehlerquote mit der Fehlerquote anderer Teams verglichen. In unserem Fall waren diese Zahlen günstig und es gab keine Bedenken mehr.

Mein Fazit aus dieser Erfahrung lautet:

... Der beste Weg, jemanden davon zu überzeugen, dass Ihre Vorgehensweise praktisch und pragmatisch ist, besteht darin, sie zu tun und sie an anderen Vorgehensweisen zu messen. Die Menschen interessieren sich nicht für Dogmen, oder warum Sie denken, dass etwas der beste Weg sein sollte. Nur wenn Sie den Menschen die Zahlen zeigen und die Effektivität Ihres Ansatzes messen, können Sie wirklich zeigen, dass Ihre Praktiken effektiv sind.

Wenn Ihr Management-Team nicht damit einverstanden ist, zusätzliche 150 Stunden für Einheitentests aufzuwenden, können Sie es möglicherweise davon überzeugen, in einen kleinen Bereich des Produkts zu investieren (oder sogar die Stunden selbst aufzusaugen, um Daten bereitzustellen) ). Führen Sie in diesem einen Bereich des Produkts Komponententests durch, und erfassen Sie dann Daten zu den Fehlerraten in diesem Bereich des Produkts sowie zu den Kosten für das Auffinden und Beheben dieser Fehler im Vergleich zu den Fehlerraten in anderen Bereichen des Produkts. Hoffentlich sammeln Sie einige Daten, um Ihren Fall zu sichern, und dies ist für Ihr nächstes Projekt kein Problem.

Die wichtigste Regel, die Sie unabhängig von der von Ihnen verwendeten Methode befolgen müssen, ist die folgende

1. Entwickler sollten das Recht haben, ihre eigene Arbeit einzuschätzen.
2. Die Interessengruppen sollten das Recht haben, bei dieser Arbeit Prioritäten zu setzen.

Schätzung und Priorisierung sind zwei Kräfte, die sehr gut zusammenarbeiten, wenn beide Parteien ihre eigene Verantwortung übernehmen. Also, anstatt Zeit mit Streiten zu verschwenden, stimmen Sie dem zu und respektieren Sie, dass beide Parteien ihre Arbeit nach besten Kräften tun werden.

Sie könnten darauf hinweisen, dass Unit-Tests Zeit sparen. Wenn Sie sie also fallen lassen, werden 500 Stunden veranschlagt.

Erzählen Sie ihnen von der technischen Verschuldung und dem Wert von Unit Tests

Schauen Sie sich diesen Beitrag von einer guten Idee über technische Schulden an. Im Anschluss an diesen Beitrag gelangen Sie zum folgenden PDF

Ich mag diesen Beitrag über den Wert von Unit-Tests (es gibt wahrscheinlich mehr zu finden)

Die Hoffnung besteht nicht darin, sie aus Ihrem Entwicklungsprozess herauszuholen, sondern sie auf die richtige Art und Weise einzubeziehen und zu engagieren.

IMHO müssen Sie Ihre ursprüngliche Planung aufschreiben und Kapitel 1 und 2 (nicht in einem Anhang) hinzufügen, in denen Sie die technische Verschuldung und den Wert von Unit-Tests erläutern. Gib ihnen Alternativen:

• Weniger Stunden (nicht die gesamten 150, das klingt lächerlich), in denen jede Änderung (während der Entwicklungsphase und während der Wartung) im Durchschnitt dauern wird:
  • kleine 4 Stunden
  • Mittel 16 Stunden
  • große 40 Stunden
• Ihre geschätzten Stunden, in denen jede Änderung (Entwicklungsphase und während der Wartung) durchschnittlich dauern wird:
  • kleine 2 Stunden
  • mittel 8 Stunden
  • große 20 Stunden

(Die Stunden sind nur Richtwerte. Sie sind viel besser gerüstet, um korrekte Schätzungen vorzunehmen.)

Vergessen Sie nicht, Ihren Track Record für pünktliche Lieferungen innerhalb des Budgets beizufügen.

Schreiben Sie es auf und besprechen Sie dies mit ihnen. Möglicherweise verfügen sie über einige wichtige Punkte in Funktionen, die sie derzeit nicht benötigen, oder über eine technische Verschuldung, die sie bereit sind, zu übernehmen, um pünktlich zu liefern. Stellen Sie einfach sicher, dass dies bewusste Entscheidungen sind.

Hoffe das hilft und viel Glück.

Teilen Sie "Write Unit Tests" nicht als separate Aufgabe auf, die geschätzt, geplant und möglicherweise gekürzt werden soll. Ihre Schätzungen sollten auf der Funktionsebene "Implementieren Sie die XYZ - 18 Stunden" liegen. Diese 18 Stunden sollten alles einschließen, was in Ihrem Prozess erforderlich ist, um diese Funktion zu "FERTIG" zu machen, einschließlich "Einheitentests schreiben".

Das ist ein guter Weg, um die nicht-technische Entwicklung "aus Ihrem Entwicklungsprozess heraus" zu bekommen. Nehmen Sie Ihren Entwicklungsprozess nicht in die Aufgabenliste oder den Projektplan auf, die Sie ihnen geben!

Zweitens scheint es, dass Ihr Team bereits gute Produkte pünktlich liefert, andere Teams jedoch nicht. Vielleicht ist diese Managementgruppe es gewohnt, diese Teams im Mikromanagement zu führen. Spielen Sie mit Ihren Stärken - bieten Sie an, wöchentliche oder zweiwöchentliche Updates mit funktionierenden Funktionen zu zeigen, und Sie werden über den "Entwicklungsprozess" auf dem Laufenden bleiben.

Ich war einmal in einer Situation, in der ich mit einer Codebasis in einem sehr guten Zustand arbeitete. Innerhalb kürzester Zeit wurde eine herausfordernde neue Funktion benötigt, und es gelang mir, die Funktion innerhalb kürzester Zeit bereitzustellen. Zu diesem Zeitpunkt befand sich die Codebasis in einem viel schlechteren Zustand. Das Feature wurde also geliefert, aber meine Arbeit wurde nicht getan: Ich musste alles wieder in einen gleich guten Zustand versetzen.

Ich erklärte dem Manager zwei Stufen höher: Es ist, als würde man bei Ihnen zu Hause malen. Wenn alle Werkzeuge da sind, wo sie hingehören und sich in einem guten Zustand befinden, alle Bürsten gereinigt sind usw., können Sie sehr schnell malen. Aber dann muss man sich die Zeit nehmen, um alle Werkzeuge wieder in Ordnung zu bringen. Wenn Sie das nicht tun, wird Ihre nächste Lackierung viel länger dauern. Eigentlich werden Sie sich nicht erinnern, wo sich Ihre Werkzeuge befinden, Ihre Pinsel können nicht mehr geborgen werden und es kostet Sie viel mehr Zeit und Geld, als wenn Sie die Aufräumarbeiten sofort erledigt hätten.

Und das Gleiche gilt für meinen Programmierjob: Durch das Aufräumen versetze ich die Codebasis in einen Zustand, in dem ich beim nächsten Mal etwas sehr schnell wieder liefern kann. Wenn nicht, dauert es das nächste Mal viel länger.

Sie können sie nicht vollständig aus Ihrem Prozess heraushalten, schließlich zahlen sie Ihren Lohn und sie werden Ihr Produkt verwenden (wenn nicht direkt, ist vermutlich jemand in Ihrem Unternehmen der Endverbraucher).

Manager, die Entwickler beschuldigen, die Zeit überschätzt zu haben, sind meiner Erfahrung nach ein weit verbreitetes Szenario, und wenn dies nicht behandelt wird, kann dies zu einem ziemlich blöden Wettrüsten führen, bei dem sich Ihre nächsten Schätzungen verdoppeln, da Sie wissen, dass die Bosse sie halbieren werden Sie vierteln sie, also vervierfachen Sie sie usw. usw. Sie müssen diesen Teufelskreis nach Möglichkeit vermeiden.

Unter der Annahme, dass es keinen Grund für die Deadline gibt, würde ich 2 Dinge vorschlagen.

1. Stellen Sie einen detaillierten Plan bereit, wie viel Sie Ihrer Meinung nach in 150 Stunden leisten können, und halten Sie dabei an Ihrem derzeitigen Ansatz für qualitativ hochwertige Arbeit fest. Zählen Sie genau auf, was in diesem Zeitraum geliefert werden kann. Die Antwort von KeesDijk enthält einige sehr gute Links zur Planung.
2. Fahren Sie mit der gleichen detaillierten Planung fort, um alle Funktionen abzudecken, und zeigen Sie, wie viel Zeit 300 Stunden in Anspruch nehmen werden (oder wie hoch die Zahl auch sein mag).

Machen Sie sich dann an die Arbeit und berichten Sie regelmäßig über den Fortschritt. Wenn möglich, sollten Sie in regelmäßigen Abständen einige Ergebnisse vorlegen. Dies sollte dem Management Vertrauen in Ihre Einschätzungsfähigkeiten und -bereitschaft geben.

Fragen Sie sie nach der Grundlage ihrer Schätzungen. Es ist nur fair, die Diskrepanzen zu diskutieren. Unit-Tests ausgeben ist eine falsche Wirtschaftlichkeit, was Sie nicht ausgeben, um Unit-Tests zu schreiben, die Sie später (und länger) in einem Debugger ausgeben. Im Wesentlichen haben Sie dokumentiert, dass Sie die von Ihnen durchgeführten Arbeiten testen möchten. Sie sagen Sie nicht zu Test überhaupt . Unabhängig davon, ob Sie bei der Entwicklung des Projekts Unit-Tests oder Ad-hoc-Tests durchführen, müssen Sie diese Zeit berücksichtigen. Durch Entfernen der für den Komponententest zugewiesenen Zeit wird auch die für den Ad-hoc-Test zugewiesene Zeit entfernt.

Fazit: Halten Sie sich mit Ihrer Schätzung an Ihre Waffen. Aus Ihrer Erfolgsbilanz geht hervor, dass Sie wissen, wovon Sie sprechen, und auf der Grundlage Ihrer Einschätzung (Annahmen, Erwartungen, vergangene Wertentwicklung usw.) eine angemessene Antwort geben können. Es scheint, als ob Ihr oberes Management nicht die nötige Transparenz hat, um eine vernünftige Schätzung zu erstellen. Nehmen sie 8-Stunden-Tage ohne Unterbrechungen für Besprechungen an? Planen sie Systemtests in ihren Schätzungen ein? Wie sind sie auf die Hälfte von Ihnen gekommen, wenn man Ihre Erfolgsbilanz berücksichtigt?

Ich würde schätzen, dass es 300 Stunden dauern wird, und wenn sie das Budget von 150 haben, dann wird es entweder ein Buggy-Rush-Job oder eine verspätete Lieferung sein. Wenn das Projekt abgeschlossen ist und Sie es vorhersagen, können Sie ihnen nur sagen, dass Sie danach gefragt haben.

Was würde Wally tun?

Es gibt mehrere Möglichkeiten zu interpretieren, was das Management von Ihnen verlangt. Zum einen möchten sie nicht, dass Sie pünktlich liefern.

Scheint absurd? Ja, aber woher können sie sonst wissen, dass Sie nicht überschätzen? Halten Sie Ihre Fristen nicht ein (lassen Sie nach, wenn nötig), und stellen Sie sicher, dass Sie wirklich müde aussehen, wenn Sie versehentlich etwas pünktlich liefern, um nicht den Eindruck eines Spaziergangs im Park zu erwecken.

Du bist in einer Essiggurke. Wenn du an deinen Waffen festhältst und bei Unit-Tests bleiben willst und die 300 Stunden beanspruchen willst, wirst du Feinde machen.

Wenn Sie die Zeit bis zu 150 Stunden verkürzen und Tests mit Spannzangen durchführen, können Sie ein fehlerhafteres Produkt schneller ausliefern, dies verursacht jedoch später Probleme und verursacht höhere Wartungskosten.

In jedem Fall verlierst du.

Zumindest scheint es so.

Sie betreiben kein wissenschaftliches Labor an einer Universität. Sie bieten einem Geschäftsbereich in einem Unternehmen einen Unternehmensdienst an, der Kunden in einem Ökosystem von Unternehmen Dienstleistungen erbringt. Ihr Unternehmen benötigt möglicherweise Ihr Produkt, um seinen Kunden schnellere und bessere Dienstleistungen zu bieten und damit die erforderlichen Einnahmen zu steigern.

Sie sehen, was Sie brauchen, ist eine ROI-Analyse, und Sie haben nicht alle Daten, um diese Analyse durchzuführen. Sie haben nur einen Teil der Kosten (Sie kennen nicht alle Lohn- und Gehaltszahlen) und Sie haben sicherlich nicht die Einnahmen, insbesondere nicht die Einnahmenprojektionen.

Ob Sie es glauben oder nicht, Ihr Management ist in der Lage, die ROI-Prognosen zu erstellen (das wird an der Business School gelehrt). Möglicherweise hat es mehrere ROI-Prognosen durchgeführt und die Idee: "Wenn wir jetzt handeln, werden wir sogar noch viel mehr Geld verdienen." Mit der Verdreifachung der Kosten für die Wartung der Software beklagen sich die Bozos in der IT. "

Wenn Sie also das Joint leiten möchten, gründen Sie Ihr eigenes Unternehmen. Du wirst sehen, es ist nicht so einfach.

Mit anderen Worten: Tu, was dir gesagt wurde. Wenn das Management weiß, was es tut, haben Sie die Nase vorn. Wenn nicht, sind Sie arbeitslos, haben Unit-Tests oder nicht.

Welchen ROI fragen Sie? Return on Investment. Es ist allerdings ein schlechter Name. Es muss sich um eine Kapitalrendite (Return On Timely Investment, ROTI) handeln, denn das Timing ist alles, was in Investitionen investiert wird.