Frage:
Entschuldigung für den langen Beitrag, aber ich bin mir nicht sicher, wie ich damit umgehen soll.
Hintergrund:
Wir haben ein 3-köpfiges Entwicklungsteam in einer anderen Stadt. Der Hauptentwickler ist seit 6 Jahren dabei und die anderen Entwickler sind seit < 6 Monaten dabei und beide Absolventen.
Das letzte Projekt hat alle aufgrund schlechter Kommunikation, sich ständig ändernder Anforderungen und scheinbar schlechter Entwicklungspraktiken/Prozesse ausgefranst. Ein Teil, den ich umstritten fand, war, wo Entwickler ihre Aufgabe darin sahen, zu „codieren“, und es die Aufgabe des Unternehmens war, zu „testen“. Dies bedeutete, dass ungelernte Helpdesk-Mitarbeiter über riesige Testskripte verfügten und Funktionen von Hand testeten, die automatisiert werden konnten, und das Testen doppelt so lange dauerte wie der „Entwicklungs“-Teil. Sie bestanden auch darauf, dass es sich um Blackbox-Tests handelte, also testeten wir wahrscheinlich Dinge, die sie bereits getestet hatten. Der Hauptentwickler zerlegte die Arbeit in Aufgaben, die in seinem Entwicklungstool verfolgt wurden, weigerte sich jedoch, irgendjemanden über die Aufgaben zu informieren oder ihre Schätzung offenzulegen.
Szenario:
Ich wurde beauftragt, die Entwicklung der nächsten Version zu überwachen. Das Management möchte kein Geld ausgeben und ist noch nie auf einen anderen Softwareentwicklungsprozess gestoßen, als zum Telefon zu greifen und Anforderungen herunterzubrüllen. Ich möchte zu einer agilen Methodik übergehen, aber niemand, einschließlich Entwickler, ist zuvor auf so etwas gestoßen. Aus diesem Grund habe ich zunächst einige kleine Änderungen gefordert:
Miteinander ausgehen:
Der Hauptentwickler hat akzeptiert: (2) Anforderungen aufzuschreiben und möchte nun alles als vollständige Spezifikation aufschreiben. Trotzdem weigern sich Entwickler, nach dieser erschöpfenden Spezifikation zu testen, weil „es die Aufgabe des QA-Teams ist“. Ich habe das Gefühl, als Geisel gehalten zu werden, da das Management den Nutzen davon gesehen hat, aber nicht daran interessiert ist, weitere Änderungen vorzunehmen, weil es „zu viel Aufwand“ ist, sich auf den Streit einzulassen. (1) wurde zurückgewiesen, da sie sich weigern, eine Schätzung vorzunehmen, damit sie nicht an dieser Schätzung festhalten. (3) wurde abgelehnt, weil ihre Aufgabe darin besteht, „zu entwickeln“, und die Aufgabe des QA-Teams darin besteht, Fehler zu finden. (4) wurde abgelehnt, weil die Schätzung „zu lange dauert“ und sie sich nicht daran halten wollen. Wie der leitende Entwickler es genannt hat: es
Wir haben jetzt einen Prozess, bei dem die Zeit unterteilt ist in: x (Spezifikationen schreiben) + x ('Entwicklung') + 2x (Testen) - die Entwicklung sitzt die Hälfte dieser Zeit herum und wartet.
Rekapitulieren:
Entschuldigung für den langen Beitrag, aber ich bin mir nicht sicher, was ich versuchen soll. Ich fühle mich wie eine Geisel, und kleine Veränderungen, die ich als „zu hart“ empfunden habe, waren für alle Beteiligten?
Mein Ansatz würde sich darauf konzentrieren, Ihren leitenden Entwickler davon zu überzeugen, dass er Folgendes akzeptiert:
Ich denke, es läuft nur darauf hinaus, diese Disziplin aufrechtzuerhalten und eine Person, die diese Veränderung anführt. Bevor ich irgendwelche anderen Winde der Veränderung durch einen Prozess hereinbringe, werde ich mit diesen „kulturellen“ Veränderungen beginnen.
Sie brauchen jemanden, der daran glaubt und Sie zu Änderungen überreden/durchsetzen kann, leitender Entwickler? ein Architekt ? oder du ?
Willkommen bei PMSE!
Zunächst einmal neige ich dazu, ein klares und durchdachtes Thema vorzuziehen, als irgendwelche zweizeiligen Fragen von Leuten, die nicht einmal wissen, was sie wissen wollen. Stattdessen haben Sie viele Details zu Ihrer Situation angeboten, die zu großartigen und genauen Antworten führen könnten, die (hoffentlich) in Ihr Szenario passen.
Wenn ich alle Probleme lese, die Sie vorgestellt haben, würde ich meine Bemühungen darauf konzentrieren, wie mit dem Verhalten von "nur Entwicklercodes" umzugehen ist . Wenn man an Agile denkt, ist das Konzept, dass Menschen nur eine Rolle spielen, lächerlich. In Agile verwendet jeder mehrere Hüte, insbesondere Entwickler*.
Der Schlüssel wäre also zu verstehen, warum Entwickler eine solche Kultur haben .
Ich würde mich fragen, einige Ursachen :
Diese Liste könnte riesig sein ... aber ich würde sagen, dass ein offenes Gespräch mit Ihren Entwicklern ein persönliches Treffen ist, um zu verstehen, warum die Kultur der "Entwickler sind nur (arme) Programmierer" existiert.
Die anderen Probleme sind aus meiner Sicht Begleiterscheinungen. Das Grundproblem ist die Qualität der Entwickler, die Ihnen zur Verfügung stehen.
Es ist wichtig hervorzuheben, dass auch das QS-Konzept falsch ist : QS soll, wie der Name schon sagt, die Qualität des Liefergegenstandes sicherstellen. Ein QA-Team ist kein Testteam. Im Idealfall würde die QA keine Fehler entdecken, aber normalerweise findet die QA nur wenige Fehler. Die meisten nicht. Das ist sicherlich die Aufgabe der Entwickler.
Es ist wichtig zu betonen, dass Sie zu gegebener Zeit vielleicht lieber das Team als Ganzes bewerten möchten .
Denken Sie daran: Der Versuch, mit dieser Entwicklermentalität zu Agile zu wechseln, ist eine Zeitverschwendung. Eine der Grundlagen von Agile ist, dass jeder alles tut. Vergiss also vorerst „Sprints“. Ich würde sagen, dass eine Mischung aus Agile + Waterfall zu besseren Ergebnissen führen könnte (und weniger Ressourcenverschwendung, wie die Entwickler, die Kartenspiele spielen, während die „QA“ ihre Codes testet).
'* Haftungsausschluss: MEIN Agile-Wissen ist sehr begrenzt, also korrigiere mich bitte, wenn ich falsch liege!
Ich denke, Ihr erster Schritt muss ein Kulturwandel bei Ihren Entwicklern sein. Ich habe es tatsächlich mit einem ähnlichen Problem zu tun, bei dem viele meiner Entwickler (ich war bis vor kurzem Teamleiter) es – wie Sie – als ihre Aufgabe betrachteten, den Code zu schreiben, die Aufgabe der QA, die Fehler zu finden, und ihre, sie zu beheben .
Wir versuchen – langsam – diese Kultur so zu ändern, dass es in die Verantwortung der Entwickler fällt, keinen Code zu schreiben, sondern ein Produkt zu produzieren, das die Anforderungen erfüllt, was natürlich beinhaltet, dass es alle Qualitätsstandards erfüllt, die Sie haben.
Eine Sache, die wir begonnen haben, ist, die Qualitätssicherung anzuweisen, dass sie, wenn sie jemals (zum Beispiel) 5 Fehler in 5 Minuten in einem Projekt findet – oder einen sehr offensichtlichen Fehler in dieser Zeit – das Testen beendet und ihn zurück an die Entwicklung schickt sie reparieren es. Das ist ein ziemlich starker Motivator, denn es ist peinlich zu hören, dass deine Arbeit so schlecht ist, dass es sich nicht einmal lohnt, sie zu testen.
Wow, es hört sich so an, als hätten Sie hier Ihre Arbeit abgeschnitten, Jeff!! Ich stimme Tiago zu, ich glaube nicht, dass ein umfassender Wechsel zu Agile in dieser Situation gut funktionieren wird, da das gesamte Team wirklich so weit wie möglich als funktionsübergreifende Einheit funktionieren muss, und Sie sind noch nicht so weit. Es gibt viele agile Techniken und Artefakte, die Sie im Laufe der Zeit einbringen können, die jedoch dazu beitragen können, die kurzfristige Situation zu verbessern. Es hört sich so an, als ob das Hauptproblem die Denkweise des Entwicklungsteams und nicht der Prozess selbst ist (obwohl es auch hier einige Probleme gibt!).
Sie haben bereits die richtigen ersten Schritte unternommen, indem Sie versucht haben, die Entwicklung dazu zu bringen, mehr Verantwortung für die Test-/Qualitätsrolle zu übernehmen, aber das war nicht erfolgreich. Ich frage mich, ob Sie es noch einmal versuchen könnten, indem Sie von der Unit-Test-Seite kommen? Vielleicht ist das Entwicklungsteam offener für die Verbesserung der Unit-Test-Abdeckung (da dies wirklich Teil einer Entwicklerrolle sein sollte ). Sie könnten dies dann nutzen, um sie ein wenig mehr auf die Seite zu ziehen, da das Konzept der Qualitätssicherung etwas ist, das während des gesamten Projekts stattfindet. Sobald sie aktiver gute Komponententests erstellen, könnten Sie vorschlagen, dass sie bei einer Form von automatisiertem UI-Testen helfen. Mein Team hat gerade damit begonnen, Selenium-Keywords für alle neuen Funktionen als Teil der Definition of Done für die Entwicklung zu erstellenKriterien. Sie waren anfangs zögerlich, sind aber jetzt ziemlich für die Idee, da es der schnellste und produktivste Weg war, sie zu erstellen. Für Ihr Team würde ich mich an automatisierte Tests halten, die ein Element des Schreibens von Code beinhalten, da sich das leichter verkaufen lässt.
In Bezug auf die dokumentierten Anforderungen ist dies ein Bereich, in dem Agile möglicherweise helfen kann. Wenn Sie das User-Story-Format verwenden und die Tatsache vorantreiben, dass die Geschichten selbst nur hilfreiche Memoiren für ein richtiges Gespräch sind, kann dies dazu beitragen, dass das Entwicklungsteam und das Unternehmen enger miteinander kommunizieren. Das User-Story-Format ist für das Unternehmen einfach zu erstellen, und da sie kurz sind (weil viele Details in der eigentlichen Konversation enthalten sind), sollte die Aktivierungsenergie, die erforderlich ist, um das Unternehmen davon zu überzeugen, sie zu erstellen, gering sein. Sie können dies erweitern, indem Sie die Zufriedenheitsbedingungen auflistenfür jede Geschichte und bitten Sie die Entwickler, diese in einer regulären Demo vorzuführen. Dies wird die Entwickler dazu bringen, zumindest ein gewisses Maß an Tests durchzuführen, bevor es für die QA „bereit“ ist. Das ist eindeutig nicht perfekt, aber es ist ein kleiner Schritt in Richtung Nirvana.
Könnten Sie für die zweiwöchigen Iterationen und Schätzungen darauf drängen, Story Points als Schätzungsmechanismus zu verwenden? Diese sind nicht zeitbasiert, bieten aber eine Möglichkeit, den Fortschritt zu verfolgen. Ich bin nicht zu 100 % davon überzeugt, dass dies ohne eine gute Arbeitsbeziehung zwischen den QA- und Entwicklungsteams allzu gut funktionieren wird, aber es könnte einen Versuch wert sein. Ich nehme an, der Grund, warum die Entwickler so gegen Schätzungen sind, liegt darin, dass sie in der Vergangenheit verbrannt wurden, weil sie an Schätzungen festgehalten wurden. Sie müssen hart arbeiten, um sicherzustellen, dass dies nicht geschieht. Story Points sind eine gute Möglichkeit, etwas anderes als Kickstarter auszuprobieren, aber sobald Sie einige Schätzungen haben, müssen Sie sicherstellen, dass sie sorgfältig verwendet werden. Sie wollen das Vertrauen des Teams nicht verlieren, da es so klingt, als würde es schwierig sein, es zurückzugewinnen.
Zusammenfassend schlage ich daher folgende Schritte vor:
Viel Glück, es hört sich so an, als hätten Sie ein paar lustige Monate vor sich. Die Denkweise der Menschen zu ändern ist keine schnelle Sache, also überstürzen Sie diesen Prozess nicht. Wenn Sie nur einen Aspekt verbessern können, machen Sie sich keine Sorgen, zumindest haben Sie etwas verbessert.
Ich bin mir nicht sicher, wo Ihre Autorität liegt, aber es ist kein methodisches Problem, das Sie haben, es ist ein Verantwortungs-/Rechenschaftsproblem. Und solange/sofern sich das Management nicht einmischt, wird sich nichts ändern.
Das Problem ist, dass Sie eine Gruppe von Menschen haben, die bestimmen, was ihre Arbeit ist und was sie bereit sind zu tun, auch wenn ihnen etwas anderes gesagt wird.
Die einzige Möglichkeit, dies zu korrigieren oder zu ändern, besteht darin, aufzuzeigen, „warum“ sich das Management einmischen muss. Skizzieren Sie die Probleme aus dem letzten Projekt. Zeigen Sie, wie die vorgeschlagenen Änderungen die Dinge verbessern werden. Zeigen Sie ihnen, wie viel sie diese Einstellung kostet (Nacharbeit, Verzögerungen, Fehlerbehebungen usw.)
Erklären Sie mgmt, dass Sie ein Team haben, das nicht bereit ist, abzuschätzen, wie lange etwas dauern wird, weil es dabei nicht helfen möchte. Mgmt zahlt für diese Zeit, wie können sie also etwas vorhersagen oder nachverfolgen, es sei denn, sie erhalten von Anfang an etwas? Alles andere bedeutet, dass das Entwicklerteam ein offenes Budget hat, das es sich so lange nehmen kann, wie es möchte.
Fazit: Bis Sie einen Weg finden, mgmt dazu zu zwingen, die Probleme zu sehen und zu handeln, wird sich nichts ändern.
Jeff, die Implementierung neuer Prozesse ist eine komplexe Aufgabe. Zu komplex - glaube ich - um es in einer PMSE-Antwort zu beschreiben. Darüber hinaus ist die Implementierung nicht das Ziel, das Ziel sollte darin bestehen, den neuen Prozess aufrechtzuerhalten und die Änderung stabil zu machen .
Kurzfristig können Sie einige Verbesserungen und Änderungen vornehmen, aber langfristig müssen Sie die Kultur sowohl im Management als auch im Entwicklerteam ändern. Ich habe nie eine Änderung gesehen, die nur durch ein mittleres Management erzwungen wurde und die erfolgreich war. Das heißt, Sie müssen das Konzept an das Management und die Entwickler verkaufen, was die Politik einschließt.
Situation, die Sie beschrieben haben, würde ich so umschreiben:
Sie haben eine Reihe von Kollegen, die eine gute Zeit damit verbracht haben, in ihrer Komfortzone zu sitzen und ihre Arbeit auf die Schultern anderer zu schieben oder sie überhaupt nicht zu erledigen. Zum Beispiel verwaltete das Management die sich ändernden Anforderungen nicht und die Entwickler kümmerten sich nicht um die Qualität. Jetzt können Sie sie dazu bringen, die Situation zu erkennen und sich die Unterstützung zu verdienen ODER zu entscheiden, ob Sie in einem Chaos arbeiten wollen ...
Meine Abteilung wechselte von „überhaupt kein Prozess“ zu Agile, also zögern Sie nicht, mich zu kontaktieren, falls Sie „Offshore-Unterstützung“ benötigen. Außerdem finden Sie auf dieser PMSE-Website viele kurzfristige Lösungen.
Als Softwareentwickler kann ich Ihnen mit 100%iger Gewissheit sagen, dass es die Aufgabe des Softwareteams ist, zu testen, ob die von ihnen gelieferte Software funktioniert, unabhängig davon, welchen Entwicklungsprozess Sie verwenden (agil/Wasserfall/RUP/Hacking). Dazu gehören nicht nur Unit-Tests, sondern (mindestens) Software-Integrationstests. Es ist für das Softwareteam möglicherweise nicht praktikabel, Tests auf Systemebene durchzuführen, da Hardwareressourcen vorhanden sind und/oder dem Softwareteam dedizierte Hardwareressourcen zur Verfügung gestellt werden, aber sie sollten sehr wohl in der Lage sein, Softwareakzeptanztests durchzuführen, die ALLE Softwareanforderungen erfüllen .
Leider, wenn Sie keine Managementunterstützung haben, dann sind Sie wirklich abgespritzt. Wenn Sie jedoch etwas Management-Unterstützung (auch nur ein wenig) haben, würde ich nur darauf drängen, dass das Softwareteam Software-Abnahmetestverfahren bestehen muss, bevor die Software an die QA weitergegeben wird. Das bedeutet, dass alle Anforderungen, die für das jeweilige Release implementiert werden, auf irgendeine Weise getestet werden müssen. Wenn das Softwareteam die Prozeduren nicht schreiben möchte, ist das in Ordnung, aber nachdem ihre Software die Abnahmetests wiederholt nicht bestanden hat, wird sie diese Aufgabe schließlich gerne übernehmen. Dann muss nur noch jemand überprüfen, ob seine Verfahren tatsächlich die Absicht der Anforderungen testen.
Ein zentraler Punkt, denke ich, ist, dass man nicht versuchen sollte, die Mannschaft zu irgendetwas zu überreden.
Wenn Sie eine wenig vertrauensvolle Kultur und ein neu gebildetes Team haben und die Entwickler Sie als verlängerten Arm des Managements sehen, das versucht, sie zu einer Änderung ihrer Verhaltensweisen zu zwingen, wird es Ihnen schwer fallen, den Prozess zu verbessern. Wenn Sie jedoch in der Lage sind, 1) das Team dazu zu bringen, eigene Verbesserungen vorzuschlagen, und 2) diese nach besten Kräften umzusetzen, dann bauen Sie das nötige Selbstvertrauen auf, damit das Team wachsen und lernen kann.
jmort253