Wie mit Kunden und Iterationen in Agile-Team beschäftigen? [geschlossen]

Question

Dieser Thread ist ein Follow-up auf meinen vorherigen . Es ist in der Tat zwei Fragen, so dass ich niemanden Köpfe hoffen, da sie voneinander abhängig sind.

Wir sind ein neues Projekt bei der Arbeit beginnen und wir betrachten es als große Chance Agile-Techniken in Aktion zu versuchen. Wir hatten ein Brainstorming über Ideen, die wir in mehrere Bücher und Artikel lesen, und kam mit Konzept, das uns die besten passen würde: 2 Wochen Iteration, gefolgt von Ruf mit Kunden, die wählen würde, was sie stopfen in der nächsten Iteration haben wollen. Ich habe nur einige Fragen, die wir können nicht herausfinden selbst.

Was in der ersten Iteration zu tun?

Was kann man im Allgemeinen in den ersten paar Iterationen tun, wenn wir aus dem Grund auf neu beginnen? geben sie nur einen Monat der Entwicklung Code Kern der Anwendung oder beginnen mit einfachen Drahtrahmen mit begrenzten vorcodierte Funktionalität? Was in der Regel Kunden sehen wollen? Glänzende Sachen das nicht funktioniert oder hässliche Sachen, die funktionierts?

Wie mit den Kunden kommunizieren?

Unser erster Gedanke es um den Prozess zu etwas wie folgt zu setzen:

alt text http://img690.imageshack.us/img690/2553/communication .png

Ist es eine gute Idee, einen Focal Point auf Client-Seite zu haben oder ist es besser, direkt zu kommunizieren mit allen Kunden Missverständnisse zu verhindern?

---

Alle Gedanken sind willkommen! Vielen Dank im Voraus.

Answer 1

Meiner Meinung nach ist ein wesentlicher Erfolgsfaktor für agile Entwicklung ist in jeder Iteration auf der Bereitstellung von Wert für die Kunden zu konzentrieren. Ich würde auf jeden Fall „hässliche Sachen, die Arbeit macht“ pick über „shiny Sachen, die nicht funktionieren“. glänzend UIs zu tun und zu versuchen, den Client zu bekommen Hut Business-Logik zu verstehen, nimmt immer riskant viel Zeit zu implementieren ist, die a href <= „http://www.joelonsoftware.com/articles/fog0000000356.html“ rel = "nofollow noreferrer "> Joel Spolsky einen guten Artikel darüber geschrieben hat.

Wenn der Client-Erweiterungen der Benutzeroberfläche will, können sie immer setzen, dass als Voraussetzung für die nächste Iteration.

In Bezug auf die Kommunikation mit Kunden Ich denke, dass Ihre scetch sollte leicht angepasst werden. Im Gespräch in gedränge Begriffe Ihre „Brennpunkt“ ist „Product Owner“ genannt. Mit einer Person mit den Kunden zu koordinieren ist gut, da es sehr viel Zeit in Anspruch nehmen können die verschiedenen Akteure auf die Bedürfnisse vereinbaren zu bekommen. Doch der Product Owner (oder Brennpunkt) sollte mit dem Entwickler in direktem Kontakt, ohne den Umweg über die Projektmanager zu gehen. In der Tat hat der Product Owner und der Projektmanager ganz unterschiedliche Rollen, die viel gewinnen durch Split auf zwei Personen zu sein.

Der Product Owner ist der zwischen den Beteiligten Stimme an das Entwicklungsteam. Der Projektmanager auf der anderen Seite ist für das Wohlbefinden des Projektteam verantwortlich und hält oft den Überblick über Budget usw. manchmal Diese Rollen haben Agenden gegenüberliegt, und mit ihnen auf zwei Personen aufgeteilt gibt eine gesunde Möglichkeit für Verhandlungen zwischen widerstreitenden Interessen. Wenn eine Person beiden Rollen hat, neigt diese Person oft einen von ihnen zu begünstigen, automatisch die andere zu reduzieren. Sie wollen nicht in einem Team zu arbeiten, wo der Projektmanager den Client vor dem Team der Bedürfnissen immer stellt. Auf der anderen Seite will kein Kunde ein Produkt Besitzer, die immer die ersten Bedürfnisse Team bringt, den Kunden neglegting. Die Aufteilung der Verantwortlichkeit auf zwei Menschen hilft, um diese Situation zu beheben.

Answer 2

würde ich mit Anders Antwort zustimmen. Meine eine zusätzliche Beobachtung ist, dass viele Kunden finden es unmöglich, das Hässliche ignoire. Sie erhalten über Präsentation besorgt anstatt Funktion. Daher müssen Sie die Kugel und machen mindestens ein „Nice“ Bildschirm zeigen, beißen, dass Sie die Aufmerksamkeit auf Präsentation Details zahlen.

Answer 3

Was kann man im Allgemeinen in den ersten paar Iterationen tun, wenn wir aus dem Grund auf neu beginnen?

verwenden Viele Teams einen Iteration Zero zu:

• Setup der Entwicklungsinfrastruktur (Quellcodeverwaltung, Entwicklungsmaschinen, die automatisierte Build, ein kontinuierlicher Integrationsprozess, eine Testumgebung, usw.),
• die Kunden gebildet und vereinbaren mit ihm auf der Methodik,
• eine erste Liste von Funktionen erstellen, identifiziert die wichtigsten und tut eine erste Schätzung,
• definieren Zeit der Sitzungen (Planungstreffen, Demo, retrospektiv), wählen Sie die die Iterationslänge.

Iteration Zero ist sehr speziell, weil es keine Funktionalität für den Kunden nicht liefern, sondern konzentrieren sich auf das, was notwendig ist, um die nächsten Iterationen in einem agilen Art und Weise auszuführen. Aber nachfolgende Iterationen sollten Startwert für die Kunden zu liefern.

geben sie nur einen Monat der Entwicklung Code Kern der Anwendung oder beginnen mit einfachen Drahtrahmen mit begrenzten vorcodierte Funktionalität?

Nein, entwickeln sich nicht den Kern Ihrer Anwendung während eines Monats. Stattdessen starten vertikale Scheibe der Anwendung liefern (von der Benutzeroberfläche der Datenbank) sofort, nicht horizontale Scheiben. Dies bedeutet nicht, dass ein Bildschirm vollständig zu sein hat (zum Beispiel nur ein Suchfeld in einem Suchbildschirm implementieren), aber es sollte idealerweise repräsentativ für den endgültige Look & Feel (es sei denn, Sie mit dem Kunden auf einem Zwischenschritt vereinbart). Der wichtigste Teil ist zu bauen Dinge, die unmittelbaren Mehrwert für die Kunden bieten inkrementell .

Was in der Regel wollen Kunden sehen? Glänzende Sachen das nicht funktioniert oder hässliche Sachen, die funktionierts?

Zu meiner Erfahrung wollen sie nachweislich Fortschritte sehen, und Sie mögen Feedback zu bekommen, so bald wie möglich.

Ist es eine gute Idee, einen Focal Point auf Client-Seite zu haben oder ist es besser, direkt zu kommunizieren mit allen Kunden Missverständnisse zu verhindern?

Sie müssen ein Person, die die Kunden repräsentieren (die aufgerufen wird, die Product Owner in Scrum):

• Er bietet eine einzige maßgebliche Stimme
• er hat eine perfekte Kenntnis des Unternehmens (das heißt er Fragen beantworten kann)
• er weiß, wie man den ROI zu maximieren (das heißt, wie Funktionalitäten zur Priorisierung)

Answer 4

Agile generally wants to provide the client something valuable, quickly.

So I certainly would not spend "month of development to code core of the application". To me, that smells of the "big up front design" anti-pattern. Also, see YAGNI.

Get as much information from the clients about what they need soonest, and implement that in your first iteration. "Valuable" is in the eye of the client. Thet will know if they want to see slick UI (maybe they want to give a slide show about the product at a trade show, so functionality can be fake) or simple working features (maybe you're developing something that they need to start using ASAP). Business Value is what they say will help them do their job.

I'd make my iterations as short as I can (your 2 weeks could work, I suggest considering 1 week) If you absolutely can't have your dev team and your clients co-located, instead of having a call with the clients, I suggest a meeting. Demo what you've done over the previous iteration and solicit feedback about what should stay, what should change, and what should be added.

As others have said, your "Focal point" sounds like a Product Owner. What worries me about your drawing is if it is meant to imply that devs don't interact with the PO or the clients. One thing that makes Agile work is when there is lots of communication. Having communication to/from the dev team always filtered through the Project Manager is almost certainly bound to result in miscommunication, unnecessary work, and missed details.

Answer 5

I agree with the two answers given but I would just add one thing from personal experience. Are your customers bought in to the change towards quick iterations? As well as providing feedback after each iteration which is going to require the customer performing usability tests on each feature.

Now I don't know what your groups relationship is with your customer but its not unusual for customers to take a "Put request in - get working system out" attitude in that they are enthusiastic when giving requirements but not so forthoming with time when it comes to testing the feature.

Now this may be totally inappropriate to your situation but its always worth considering how your customer workflow will have to change as well as your groups.

Cheers