Welche Programmiermethode passt zu uns?

Leider hat jemand unserem oberen Management das Wort "Agil" beigebracht und möchte nun, dass wir uns darauf zubewegen. Ich habe ein peripheres Verständnis von Agilität (im Prinzip), habe es aber in der Praxis nie angewendet. Soweit ich weiß, wird es nicht gut zu unserer Organisation passen. Im Moment sind die Dinge ziemlich schmuddelig. Hier ist, wie es ist;

Wir sind ein sehr kleines Team - zwei Entwickler, ein DBA, ein Designer. Das Unternehmen, für das ich arbeite, verdient im Verhältnis zu seiner Größe unverhältnismäßig viel Geld, und fast 95% davon sind reine Online-Verkäufe.

Aus entwicklungspolitischer Sicht sind wir an einem typischen Tag vielen Schreibtischinvasionen ausgesetzt (wir sind sowohl technischer Support als auch Entwickler). Die Arbeit kann regelmäßig kurzfristig vom Himmel fallen, wenn ein Mitglied des Verkaufsteams jemandem etwas verspricht . Wir führen auch größere Projekte durch und sie sind ein Albtraum mit den ständigen Unterbrechungen. Einige von uns fangen an, sich die Haare auszureißen! Projektpläne werden von nicht technischen Managern in Excel-Tabellen erstellt, in denen sie versuchen, die Aufgabe in mundgerechte Sätze zu unterteilen, die sie verstehen und neben jedem ein Datum einfügen können. Diese Daten sind immer schrecklich unrealistisch und werden oft verpasst, und unsere Treffen (die wir ungefähr wöchentlich haben) sind regelmäßig mit unangenehmen Momenten gefüllt, in denen Leute fragen: "Warum wurde das noch nicht getan?".

Ich bin mir ziemlich sicher, dass Agile nicht das Richtige für uns ist. Nun, da (und ich habe es versucht) dieses Unternehmen seine Wege nicht ändern wird und nur das Entwicklerteam bereit ist, sich zu ändern, gibt es eine Entwicklungsmethode, die wir anwenden könnten, die gut dazu geeignet ist, uns nur etwas Vernunft zu ersparen?

Agile wurde entwickelt, um viele der genauen Probleme zu lösen, die Sie haben. Wenn sich das Management wirklich eingekauft hat und den Prozess nicht verfälscht, könnten Sie eine große Verbesserung feststellen. Lassen Sie mich Ihre Probleme Punkt für Punkt ansprechen. Meine Erfahrung ist mit Scrum, daher werde ich von diesem Standpunkt aus sprechen, aber ich bin sicher, dass andere Implementierungen ähnliche Vorteile haben.

• Arbeit fällt vom Himmel Diese Geschichten werden auf den Grund des Rückstands gestellt, bis sich der Produktbesitzer und das Team treffen können, um zu vereinbaren, sie nach oben zu verschieben. Die Priorität wird im Verhältnis zu allen anderen Verpflichtungen Ihres Teams festgelegt, und diese Priorität ist für jeden Stakeholder sichtbar, der daran interessiert ist, nachzuschauen. Es sollte äußerst selten sein, mitten in einem Sprint eine neue Funktion hinzuzufügen, und nur Fehler mit der höchsten Priorität sollten einen Sprint unterbrechen dürfen. Es ist erstaunlich, wie viele "Notfälle" bis Ende nächster Woche warten können, wenn dies regelmäßig erwartet wird.
• Durchführen größerer Projekte Sie haben die Möglichkeit zu zeigen, wie sich kurzfristige Prioritäten auf Ihre langfristigen Projekte auswirken. Wenn Benutzer User Stories ständig vor Ihre langfristigen Projekte stellen, ist das in Ordnung, aber um diese Entscheidung zu treffen, weiß jeder, welche Auswirkungen dies auf den Zeitplan des langfristigen Projekts hat.
• Projektpläne werden von nicht technischen Managern erstellt. User Stories sollten aus nicht technischer Sicht verfasst werden. Ihr Scrum-Team sollte jedoch befugt sein, Schätzungen vorzunehmen und Implementierungsdetails zu ermitteln.
• Daten sind schrecklich unrealistisch Ihr Team kümmert sich um alle Schätzungen, weil Sie diejenigen sind, die wissen, was Sie tun. Wenn diese Schätzungen für das Unternehmen nicht akzeptabel sind, müssen sie entscheiden, wie die Funktionen priorisiert werden sollen. Wenn sie mehr Arbeit benötigen, als Sie bewältigen können, wird die Notwendigkeit, mehr Mitarbeiter einzustellen, deutlich sichtbar.
• Termine werden oft verpasst Erstens sind Ihre Schätzungen realistischer, was hilfreich sein sollte. Außerdem beißen Sie kleinere Stücke ab und beenden sie tatsächlich , was dem Unternehmen das Gefühl gibt, etwas Nützliches produziert zu haben, auch wenn die Funktion nicht vollständig ist.
• Besprechungen voller unangenehmer Momente Agile bietet mehr Sichtbarkeit und einen viel schnelleren Feedback-Zyklus, wobei ein Produktbesitzer stark involviert ist. Ihre Blockierungsprobleme und Gründe für die Verzögerung sollten keine Überraschung sein.
• auch technischen Support leisten Entgegen der landläufigen Meinung ist Agilität nicht mit einem geteilten Zeitplan unvereinbar. Scrum berücksichtigt Ihre Unterbrechungen in der Geschwindigkeit Ihres Teams. Wenn Sie normalerweise die Hälfte Ihrer Zeit mit technischem Support verbringen, haben Sie einfach die Hälfte der Geschwindigkeit.

Management und Vertrieb müssen sich darüber im Klaren sein, dass Agilität keine Möglichkeit ist, eine engere Kontrolle über das Entwicklungsteam auszuüben. Sie gibt dem Team mehr Autonomie, um das zu tun, was es kann, und hilft dem Unternehmen dabei, alle Prioritäten bei der Zuweisung von Arbeit realistisch zu berücksichtigen Das Team.

Ich würde sagen, nutzen Sie die Launen Ihres Managements! Klingt so, als würden sie Ihnen einen Gefallen tun und Ihnen eine Hebelwirkung geben, um Ihre Arbeitsmethoden zu verbessern.

Sagen Sie ihnen OK, wir werden agil, es erfordert unter anderem: -

• eine Trennung von Entwicklung und Unterstützung
• Ein formaler Prozess zur Erfassung von Anforderungen - unter der Kontrolle des IT-Teams. "Geschichten" usw. klingen alle sehr vage - aber es ist eigentlich eine "formelle" Methode, die so gestaltet ist, dass sie informell aussieht.
• Die Planung wird vom IT-Team gesteuert.

Wenn sie dies nicht akzeptieren, sagen Sie ihnen, dass Sie nicht agil werden können.

Agile ist keine Programmiermethode, Agile ist eine Projektmanagementmethode. Wenn das obere Management wirklich möchte, dass Sie dieses neue Schlagwort ausprobieren, das es gefunden hat, muss es verstehen können, dass die agile Methode von oben beginnt und das Management bei jedem Schritt des Weges einbezieht. Wenn Sie ihnen eine harte Dosis Realität geben müssen, organisieren Sie möglicherweise eine 30-minütige Powerpoint-Präsentation über Agile, um ihnen ein wenig Bildung zu vermitteln. Manager lieben Powerpoint.

Wenn jedoch, wie Sie sagen, das Entwicklerteam die einzigen Personen sind, die bereit sind, Änderungen vorzunehmen, kann Ihnen keine Entwicklungsmethode helfen. Ohne eine Erleichterung für den Rest Ihrer Pflichten werden weiterhin Unterbrechungen auftreten und Sie werden weiterhin aufgefordert, Fristen einzuhalten, die Sie einfach nicht einhalten können.

Mein Rat in diesem Szenario ist, das Management darüber zu informieren, nicht zu beschimpfen, wie es wirklich an vorderster Front steht.

Keine Softwareentwicklungs- und Projektmanagementmethode kann in einer Organisation helfen, in der Vertriebsmitarbeiter den Tagesablauf bestimmen. Wie soll man ein Projekt in einer so chaotischen und ablenkenden Arbeitswoche leiten?

So viele obere Manager sehen den Wert von Agile und möchten die Vorteile davon nutzen, aber sie sind fast nie in der Lage, die internen Änderungen vorzunehmen, die erforderlich sind, um sicherzustellen, dass der Umzug erfolgreich ist. Die einzigen erfolgreichen Agile-Shops, von denen ich wusste, hatten auf diese Weise begonnen. Ich kann mich nicht an eine einzige Instanz in meiner Berufserfahrung erinnern, in der ein verkaufsgesteuertes oder Wasserfall-Softwareentwicklungsgeschäft den Umzug unternahm, da dies einen grundlegenden Kulturwandel erfordert.

Ist dieser Kulturwandel möglich? Ja, aber in Ihrem Fall mit ziemlicher Sicherheit nicht.

Ein Kulturwechsel ist normalerweise erforderlich, wenn ein Wettbewerber die Existenz des Unternehmens oder eine Make-or-Break-Situation oder eine andere ähnlich involvierte Situation bedroht, um eine Neuorganisation zu rechtfertigen. In Ihrer Situation befindet sich Ihr Unternehmen am anderen Ende des Spektrums, wo Geld im Moment einfach ist und jeder fett wird.

Unternehmen wechseln NIEMALS von innen heraus, wenn das Geld einfach ist. Warum sollten sie, sie sind trotz der Softwareentwicklungsfehler erfolgreich, nicht wegen der Softwareentwicklungserfolge.

Mein letzter Rat ist, wenn ich du wäre, würde ich nach etwas Besserem suchen. Die Leute hier haben großartige Ratschläge, aber ich habe dieses Lied und diesen Tanz schon einmal gesehen und es funktioniert in Ihrer Situation einfach nicht.

Schauen Sie sich extremeprogramming.org an - XP ist eine Form von Agile mit leicht verständlichen Aspekten, die Sie a la Cart auswählen können. Ein sehr guter Anfang

Die Verpflichtung des Kunden, seine Meinung während einer Interaktion nicht zu ändern, wäre vom Klang her ein guter Ausgangspunkt für Ihre Umgebung ;-)

Wenn man die Landschaft der traditionellen und zeitgenössischen Methoden betrachtet, würde man erkennen, dass "Agile" eher eine "Anti-Methodik" als eine Methodik ist. Muster zielen darauf ab, die "Best-Case" -Lösung für ein bestimmtes Problem in einem bestimmten Kontext darzustellen. Versuche, eine solche Lösung oder ein solches Muster direkt zu verletzen, werden allgemein als "Anti-Muster" oder Praktiken im schlimmsten Fall bezeichnet. Während echte Softwareentwicklungsmethoden versuchen, Best-Case-Praktiken bei der Entwicklung von Lösungen vorzuschreiben, versucht "Agile" (Scrum, XP usw.), alle Strukturen innerhalb des Softwareentwicklungsprozesses direkt zu verletzen, und zwar zugunsten eines zufälligen, chaotischen Ansatz - der (in letzter Zeit) auch von (naiven) Zuschauern Beifall zu fordern scheint.

Vor diesem Hintergrund ist es angebracht, den Kontext zu berücksichtigen, in dem die agile Philosophie entstanden ist. Obwohl zu dieser Zeit ausgefeilte iterative Methoden (z. B. Unified Process) existierten, war die primäre Methodik immer noch der alte Wasserfallansatz, der eine "Best Practice" der vollständigen Anforderungsanalyse, des vollständigen Entwurfs, der Entwicklung / Codierung der Lösung und der Implementierung vorschrieb die Lösung. Dieser technische Ansatz für die Softwareentwicklung war eindeutig schlecht beraten - und führte zu einer Menge Papierkram, bevor (und manchmal ohne jemals) eine ausführbare Lösung gefunden wurde.

Es ist jedoch immer noch nicht gerechtfertigt, das Baby mit dem Badewasser wegzuwerfen, wie dies bei den Beschwörern von Agile der Fall war. Der agile Ansatz erzwingt fast eine direkte Negation von allem, was zuvor verwendet wurde - außer vielleicht der tatsächlichen Codierung der Lösung. Dies ist eindeutig ein Hinweis auf begrenzte Einsichten seitens seiner Urheber, oder vielleicht ist es einfach ein Fall von "es gibt keine, die so blind sind wie diejenigen, die nicht sehen wollen".

Der Vorteil von Agile besteht jedoch darin, dass es optimierte Prozesse fördert und sich auf ausführbaren Code konzentriert - was unweigerlich Ihr ultimatives Ergebnis ist.

JETZT, um Ihre Frage direkter zu beantworten:

Angesichts Ihres Überblicks über Ihre Umgebung empfehle ich Ihnen, zunächst eine agile Implementierung auszuwählen (z. B. Scrum, XP usw.). Passen Sie dann den Ansatz an Ihre Umgebung an und legen Sie einen klaren Prozess für die Arbeitsweise Ihres Teams fest, z.

• Anfrage von Benutzer (n) erhalten;

• Benutzeranforderungen priorisieren;

• Messen Sie die Auswirkungen von Verbesserungen auf das vorhandene System (möglicherweise während Ihrer täglichen / wöchentlichen Stand-up-Meetings).

• Schätzen Sie die Entwicklungszeit jeder Erweiterung - und teilen Sie diese verschiedenen anfordernden Benutzern mit.

• Führen Sie tatsächliche Verbesserungen am vorhandenen System durch (z. B. Codierung).

• Führen Sie Benutzertests durch - und lassen Sie sich von den Benutzern (z. B. per E-Mail) bestätigen, dass die angeforderten Änderungen erfolgreich implementiert wurden.

Dies sollte eine gewisse Struktur (und Ordnung) bieten und gleichzeitig den Anschein eines agilen Ansatzes erwecken.

Denken Sie daran, dass die alte englische Redewendung "So agil wie ein Affe" nicht ohne Grund geprägt wurde!

Ich würde sagen, Sie brauchen eine Methodik wie Agile, die für Ihr Team unerlässlich ist . Da Ihr Unternehmen so unorganisiert ist, müssen Sie in Ihrem eigenen Entwicklerteam besser organisiert sein. Ich denke jedoch nicht, dass Ihre nicht technischen Manager etwas damit zu tun haben sollten.

Wenn Sie Ihre Vertriebsmitarbeiter zurückdrängen und realistische Fristen fordern möchten, müssen Sie dies mit organisierten Plänen begründen.

Auch wenn sie mit Schätzungen ohne Rücksprache mit dem Techniker zu Ihnen kommen, lehnen Sie sie einfach ab.

Vielleicht müssen sich sowohl Ihr Team als auch die Stakeholder, die vom Himmel fallen, auf die inkrementellen / iterativen Aspekte konzentrieren können, um regelmäßig und konsistent liefern zu können. Mit der Zeit werden das Verkaufsteam und das Management darauf vertrauen, dass sie bei der Einreichung einer neuen Funktionsanforderung sicher sein können, dass Ihr Team in einem geeigneten Zeitrahmen liefert.

Natürlich müssen Sie in Einheiten- / System- / Regressionstests, automatisierte Builds, Hundefutter usw. investieren, um dorthin zu gelangen, wenn Sie noch nicht dort sind.

Zuerst würde ich vorschlagen, einige Daten zu sammeln. Setzen Sie sich in einer ruhigen Zeit hin und finden Sie heraus, wie der Status Quo wirklich ist - wie die Dinge erledigt werden. Wenn das Management unbedingt etwas implementieren möchte, das es als agil bezeichnen kann, dann finden Sie etwas heraus, das für Ihr Team funktioniert, erstellen Sie ein Dokument, schlagen Sie "Agil" auf den Namen und los geht's. Denken Sie daran, dass das einzige, was sie wirklich über Agilität wissen, das Wort und eine vage Assoziation mit Schnelligkeit für die übliche Definition in Englisch ist. Ich befürworte also, dass Ihr Team sich dem Problem stellt, eine für Sie geeignete Variante findet und diese dann Ihrem Management als agile (tm) Methode vorstellt. Andernfalls wird ein PHB ein Buch in die Hand nehmen und versuchen, den quadratischen Stift in das runde Loch zu stecken, und niemand wird glücklich sein.

Wenn Sie sich für eine "reine" Form der Agilität entscheiden, kann es schwierig sein, dass Ihr Team auch die Support-Rolle erfüllen muss. Seien wir ehrlich, Ihr Chef könnte es schwierig finden, Mitglieder Ihres Teams zu akzeptieren, die auf die Helpdesk-Anfragen antworten und sagen: "Lassen Sie mich ein Backlog-Element erstellen, das werde ich in (Zeit bis zum Ende des Sprints) Wochen erledigen."

Die größte Hürde ist das Geld. Wenn alles grüne Soße ist, ist es viel schwieriger zu sagen, dass etwas nicht stimmt und sich ändern muss.

Viel Glück.

Im Gegenteil, es klingt für mich so, als ob eine agile Methode genau das ist, was Sie brauchen, um mit Terminüberschreitungen, unrealistischen Erwartungen und schlecht geplanten Projekten umzugehen.

Ihr Management hat angegeben, dass es an diesem neuen Buzz-Wort interessiert ist. Höchstwahrscheinlich möchten sie es verwenden, um die Vermarktung Ihrer Produkte zu beschleunigen. Dies ist nicht unbedingt eine schlechte Sache, aber es muss sehr sorgfältig verwaltet werden, wenn Sie möchten, dass eine agile Methode für Sie funktioniert .

Die halbe Miete besteht darin, sich vom Management zu beteiligen. Sie für die Idee von Agile empfänglich zu machen, ist der größte Teil des Kampfes. Der Rest besteht darin, sicherzustellen, dass ihre Erwartungen so verwaltet werden, dass sie weiterhin möchten, dass Sie agil sind, und dass sie nicht enttäuscht werden, wenn Ihre Manager das Gefühl haben, dass ihre Kontrolle über das Projektmanagement weitgehend durch ihre Finger rutscht.

Bevor Ihr Unternehmen etwas entscheidet, würde ich empfehlen, in einen agilen Coach zu steigen, um ein halbtägiges Seminar und einen Workshop zu absolvieren. Lassen Sie alle als Team - Manager und Entwickler gleichermaßen - darüber nachdenken, was für Agile Ihrer Meinung nach für Sie funktioniert und was nicht. Wenn das Management andererseits Ihrem Urteil vertraut, müssen Sie sich mit einer Reihe von agilen Praktiken und Methoden vertraut machen und ein oder Ihr eigenes Seminar erstellen. Persönlich würde ich mich darauf konzentrieren, einen erfahrenen Trainer zu gewinnen, damit Sie nicht viel Zeit verschwenden und die Dynamik beibehalten. Nehmen Sie sich in der Zwischenzeit ein paar gute agile Bücher als Referenz, lesen Sie sie gründlich durch, lassen Sie sie aber auch an Ihrem Schreibtisch hängen, wo das Management sie sehen kann. Unterschwellige Psychologie kann in einer Situation wie der von Ihnen beschriebenen Wunder wirken.

Ich würde zumindest empfehlen, Folgendes zu lesen:

• Lean-Software-Entwicklung - Mary & Tom Poppendieck
• Agile Softwareentwicklung - Robert C. Martin

und für zusätzliche Gutschrift (weil ich denke, dass es ein großartiger Begleiter für die anderen Bücher ist, die ich erwähnt habe):

• Sauberer Code - Robert C. Martin