Das agile Team bilden - Agile Trainingsserie Teil 2

1. Die Agile Team erstellen: Hallo, ich bin Teresa Bennett, und das ist Teil zwei der agilen Kursschulungsreihe für Wirtschaftsanalysten. Und in diesem Teil der Serie werden wir uns mit der Bildung des Agile-Teams beschäftigen. Es gibt vier Themen, die wir in dieser Schulung behandeln werden. Die erste sind die Einheiten des Teams. Wir werden über die Geschäftseinheit und die Entwicklungseinheit sprechen und welche Bereiche der Organisation in jede dieser Einheiten fallen. Wenn wir über unser Team sprechen und die Leute zusammenbringen, die Teil dieses Agile-Teams sein werden. Dann schauen wir uns die Rollen der Teammitglieder an und schauen uns an, welche Rollen von den Leuten auf diesen beiden Einheiten ausgeführt werden. Dann befassen wir uns mit Best Practices für das Team. Was müssen wir konsequent tun, um sicherzustellen, dass unser Team erfolgreich ist? Für jeden Sprint und jedes Projekt, das wir fertigstellen. Dann sprechen wir über dein Team, deine Rolle in deinem Agile-Team und welche Denkweisen du brauchst, um einen Auftrag zu erteilen, um erfolgreich in einem Agile-Team zu sein. Und was Flexibilität für Sie bedeutet, wenn Sie in einer agilen Umgebung arbeiten. Begleite mich im nächsten Video und lass uns loslegen. 2. Units des Agile Teams: Zwei Einheiten bilden das Agile Team. Zunächst haben wir die kundenorientierte Einheit, die Sie auch als Geschäftseinheit vorstellen können. Die Leute, die dieses Team bilden, sind vor allem der Kunde , der Sponsor des Projekts ist. Sie haben auch das Marketing-Team, das Marketingteam Ihres Unternehmens oder das Unternehmen, für das das Produkt verwendet wird. Wenn Ihr Unternehmen ein Beratungsunternehmen ist undbei einem Projekt in einer anderen Organisation unterstütztwurde bei einem Projekt in einer anderen Organisation unterstützt , dann wäre es das Marketing-Team dieser Organisation. Der Produktmanager ist die Person, die die Vorgänge des Produkts verwaltet. Und sie sind auch Teil der kundenorientierten Einheit. Und dann haben wir natürlich die Führungskräfte, die ich für jeden auf Direktorenebene oder höher halten würde . Wir haben auch das CMMI, die Fachexperten sind. Das sind die Menschen, die mit UND ODER das Produkt unterstützen. Sie sind also diejenigen, die wirklich Tag für Tag damit arbeiten und wirklich alle Muttern und Schrauben des Produkts kennen. Sie sind also in der Lage, Ihre Fragen zu beantworten, wie Sie das tun? Was passiert, wenn ein Kunde danach fragt? Wie durchlaufen Sie diesen Prozess? Sie sollten in der Lage sein, solche Fragen zu beantworten. Wir haben auch Stakeholder als Teil der kundenorientierten Einheit. sind Personen oder Gruppen, die etwas aus dem Ergebnis Ihres Projekts gewinnen oder verlieren können. Der Grund, warum ich hier etwas zu verlieren erwähne, ist darüber nachzudenken , wenn Sie ein Update für einen Prozess machen, es gibt manchmal Dinge, die aus dem Prozess entfernt werden , da wir die Dinge effizienter machen. Und das kann Schritte, die eine bestimmte Gruppe von Menschen getan hat, oder nehmen Sie einen Prozess ganz, die Gruppe getan hat. Ein Pfahlhalter, der etwas verliert, könnte also eine Gruppe sein, die keine Funktion mehr ausführen muss , weil die vorgenommenen Änderungen die Dinge effizienter machen und diese Funktion nicht mehr benötigt wird. Und dann könnte es natürlich andere Leute je nachdem, was das Projekt ist. Daher müssen Sie vielleicht Kundendienstmitarbeiter, Verkaufspersonal, vielleicht Rezeptionisten in Betracht ziehen. Wenn zum Beispiel die Software vielleicht ein Hotelreservierungssystem ist. Also würden Sie Mitarbeiter an der Rezeption haben, jede dieser Art von Menschen, die Sie vielleicht darüber nachdenken müssen , könnte entweder glatt oder eine andere Gruppe von Menschen, die in das Projekt involviert sein müssen , und dann andere Produktmanager und Stakeholder. Wer könnte also außer den Stakeholdern, an die Sie bereits gedacht haben, involviert sein? Gibt es andere Menschen, die betroffen sein könnten? Werfen wir nun einen Blick darauf, wer in der Entwicklungseinheit enthalten ist. Wir haben natürlich die Entwickler, oder? Das sind die Leute, die codieren. Sie entwickeln die Anwendung. Sie nehmen Änderungen an der eigentlichen Software vor, dem Business Analyst. Dies ist also die Person, die die Geschichten während der Grooming-Sitzungen mit der Business Unit detailliert . Also, wenn Sie der Business-Analyst sind, dann. Hier wird der Großteil Ihrer Arbeit im Agile-Team erledigt. Qa ist auch in der Entwicklungseinheit involviert. Das QA-Team sind also die Leute, die Softwaretests, Prozedur Testing, Prozessfluss-Tests durchführen, alles andere als die Unit-Tests, was normalerweise von den Entwicklern durchgeführt wird weil sie ihre eigenen -Code, bevor sie ihn umdrehen. Unit-Tests sind also nicht in QA enthalten, das ist Teil der Entwicklerfunktion. Aber alle anderen Tests, die passieren, sind in der Regel in der QA Lebensmittel Kinn und dann der Projektmanager enthalten. Der Projektmanager kann vom Scrum Master getrennt werden. Oder der Projektmanager kann auch diskriminierend sein. Oder ich habe das in beiden Richtungen in verschiedenen Organisationen gesehen, in denen ich gearbeitet habe. Es hängt also nur davon ab, wie Ihre Organisation eingerichtet ist und wie sie Rollen und Verantwortlichkeiten innerhalb ihrer Organisation definieren. So können Sie eine kombinierte Rolle haben, wo der Projektmanager und der Scrum Master oder die gleiche Person, oder waren sie separate Rollen von zwei verschiedenen Personen durchgeführt. Als nächstes haben wir die technischen Autoren und oder Schulungshandbuch Autoren. Sie sind verantwortlich für die Erstellung von technischen Dokumentationen und Schulungsunterlagen. Schulungsunterlagen können von der Kundeneinheit durchgeführt werden. So kann jemand aus der Geschäftseinheit beauftragt werden, das Schulungshandbuch zu schreiben. Auch hier hängt es nur davon ab, wie die Organisation in dem Unternehmen eingerichtet ist, in dem Sie arbeiten. Also habe ich in Organisationen gearbeitet, in denen sie noch keinen speziellen Schulungshandbuch Schriftsteller hatten. Das technische Team, das das technische Schreiben gemacht hat, erstellt also auch die Schulungsunterlagen. Und ich habe auch in Organisationen gearbeitet, in denen die Geschäftseinheit, richtig, die Kundenabteilung hatte ein Trainingsteam und jemand ist, der die Schulungsmaterialien schreibt. Es hängt also nur davon ab, wie sie eingerichtet sind. Wenn sie eine Person haben die die Schulungsmaterialien als Teil der kundenorientierten Einheit erstellen kann, würden sie in diesen Bereich und nicht in die Entwicklungseinheit aufgenommen. Dann haben wir unsere UX und Design Creative People. Sie sind also die Menschen, die das Erscheinungsbild der Anwendung und die Benutzererfahrung definieren . Dann haben wir die Architektur Menschen, die auch in der Entwicklungseinheit enthalten sind weil wir über Systemarchitektur, Datenbankarchitektur sprechen. Es geht eher um die technische Architektur als um alles, was geschäftlich zu tun hätte. Und dann haben wir eine andere Art von anderen Kategorien, richtig? Also jede andere IT oder I S Mitarbeiter, die für den Erfolg des Projekts notwendig ist. Und auch hier hängt das davon ab, wie Ihre Organisation eingerichtet ist und wofür dieses bestimmte Projekt bestimmt ist, welche anderen Einheiten an diesem bestimmten Projekt beteiligt sein könnten. 3. Teamrollen: Als nächstes werfen wir einen Blick auf die Teamrollen. Also werden wir darüber reden, wer für was in beiden Einheiten verantwortlich ist , über die wir gerade gesprochen haben, der kundenorientierten Einheit und der Entwicklungseinheit. Jeder dieser Personen hat bestimmte Verantwortlichkeiten innerhalb des Teams. Für die kundenorientierte Einheit sind sie also für die Produktvision und die Roadmap verantwortlich. Sie sind auch verantwortlich für die Verwaltung des Product Backlogs, was der Umfang ist, aber betrachten es als den Umfang des Projekts. Was machen wir für dieses Projekt? Es wird erwartet, dass sie zu gegebener Zeit mit Einzelheiten vorbereitet werden. Also an jedem Punkt, dass das Projektteam braucht spezifische Details in Bezug auf alles für die Geschäftsfunktionen des Projekts. Sie müssen bereit sein, diese Fragen beantworten zu können. Sie müssen klare Erwartungen an die Akzeptanz setzen, was bedeutet, dass sie sicherstellen müssen, dass das gesamte Team versteht, wofür sie erwartet , wenn sie sagen werden, dass das Entwickelte und Gebautes ihren Erwartungen entspricht. Sie müssen uns also vorab sagen, was diese Erwartungen sind, damit wir aufbauen , um diese Erwartungen zu erfüllen. Dass die Hoffnung ist, wenn wir zu dem Punkt kommen, wo wir ein Produkt zu ihnen demontieren. Sie sagen ja, so habe ich es erwartet. Und sie sind natürlich sehr stark an der Kommunikation im gesamten Team beteiligt und helfen dem Team nicht nur zu definieren und zu helfen, zu verstehen, was es ist, was sie wollen, sondern auch in der Kommunikation von Änderungen und ihrem Feedback zu dem, was für sie geschaffen und gebaut wird. Die Entwicklungseinheit ist für die Schätzung verantwortlich, was bedeutet, dass sie einen guten Griff haben müssen, um die Zeit zu schätzen, die sie brauchen wird, um alles zu vervollständigen, was im Rahmen des Projekts ist. Sie sind verantwortlich für die Planung und das Commitment für die Iteration. So ist eine Iteration auch als Sprint in der agilen Welt bekannt. Und ein Sprints dauert in der Regel zwei Wochen, vielleicht drei Wochen. Ich habe gesehen, wie einige Organisationen vierwöchige Sprints machen. Allerdings warne ich vor denen, weil Sie beginnen, sich in mehr von einer Wasserfall-Denkweise zu bewegen , wenn Sie in einen Sprint, der vier Wochen lang oder sogar länger ist als das. Der bessere Zeitrahmen für einen Sprint ist also zwei Wochen oder drei Wochen, Mann. Und während dieses Sprints, oder was als Iteration bekannt sein könnte, ist die Erwartung, dass die Entwicklungseinheit in der Lage ist, zu planen, was sie während dieser Iteration tun und sich dazu verpflichten, und dann aus dem anderes Ende davon mit diesen Dingen abgeschlossen. Offensichtlich müssen sie die Iteration ausführen, oder? Nachdem sie also geplant und engagiert haben, was sie tun werden, müssen sie in der Lage sein, dies auszuführen und die Aufgaben zu erledigen, die erledigt werden müssen. Und danach kommt die Demo ins Spiel, die ich zuvor erwähnt habe, als ich über die Geschäftseinheit sprach. Also wird das Entwicklungsteam am Ende eine Demo machen , die zu sprinten, um zu zeigen, was während dieses Zeitrahmens abgeschlossen wurde. Und wenn die Kommunikation gut passiert ist und jeder das gleiche Verständnis hatte, als das, was er in der Demo sieht , das sein sollte, was er erwartet hat. Und deshalb sollten sie sagen: Ja, ich akzeptiere das, weil es so gebaut wurde, wie wir es erwartet haben. Und natürlich wird erwartet, dass sie während jedes Sprints bis zum Abschluss des Projekts eine klare Kommunikation bieten . 4. Best Best Practices und dein Team: Lassen Sie uns nun über Best Practices des Teams sprechen. Wir wollen als Team starten und als Team beenden. Was wir damit meinen, ist, wenn Sie zum ersten Mal mit einem Projekt beginnen , damit alle sehr aufgeregt sind. Schießpulver wie ja, wir werden dieses Ding machen, wo wir an Bord damit nicht in einen Zyklus kommen wollen, wo wir über Dinge aufgeregt sind. Und dann geraten wir in eine Iteration und wir beginnen, durch sie zu arbeiten und Probleme treten auf. Und zu dem Zeitpunkt, als wir diese Iteration in diesem Zeitraum von zwei Wochen oder drei Wochen beendet haben. Und wir kommen zum Ende, alle zeigen Finger und sagen: Nun, wir haben das nicht getan, weil das nicht klar war. Und wir haben das nicht geschafft, weil diese Person das nicht getan hat. Wir wollen als Team starten und als Team fertig. Und das bedeutet, dass wir während dieser gesamten zwei- bis dreiwöchigen Periode zusammenarbeiten und zusammenarbeiten. Wir bringen Probleme auf, die auftauchen, und wir lösen sie zusammen, damit wir diesen Sprint vollenden. Immer zusammen als Team und wir zersplittern nicht. Und wenn diese Dinge passieren, kann dies auseinander brechen und den kranken Willen während eines Teams verursachen. So ist die Kommunikation während des gesamten Prozesses der Schlüssel , damit das Team zusammenhängend bleibt und zusammenarbeiten kann. Und ein Teil davon ist Nummer zwei, die offene und ehrliche Kommunikation ist. Wenn dir etwas fehlt, wenn du eine Straßensperre hast, die dich davon abhält, etwas zu erledigen. Wir müssen in der Lage sein, über diese Dinge zu sprechen und Lösungen für diese Dinge zu finden. Nummer drei wird inspiziert und angepasst. Was diese Best-Practice bedeutet, ist, dass wir uns immer ansehen, was wir tun, darüber nachdenken, wie wir es besser machen können, und dann passen wir diese Änderungen voran und machen sie voran. Das bringt uns auf Nummer vier, was eine schrittweise Verbesserung von Produkt und Prozess ist. Damit wir das Produkt verbessern können, also was wir liefern, müssen wir immer auch unsere Prozesse verbessern. Während dieser offenen und ehrlichen Kommunikation und der Inspektion und Anpassung wollen wir unsere Prozesse verbessern, damit wir das Produkt verbessern, das wir Ihrem Team liefern. Lassen Sie uns also über Ihre Erwartungen sprechen. Welche Erwartungen haben Sie, wenn Sie in einem Agile-Team arbeiten? Welche Verschiebungen und Denkweisen müssen vorgenommen werden wenn Sie vom Wasserfall zu einem agilen Ansatz wechseln. Eines der Dinge für mich, wahrscheinlich das Größte für mich war, zu verstehen und in Ordnung zu sein mit der Tatsache, dass ich nicht alles auf einmal wissen werde. Wenn Sie also in einer Wasserfallumgebung arbeiten , erfüllen Sie alle Anforderungen. So können Sie in der Analysephase eines Projekts arbeiten. Vier. Sicherlich wochenlang, manchmal monatelang, je nachdem, wie groß das Projekt ist. Und wenn Sie bis zum Ende der Analysephase kommen, wissen Sie, dass das Produkt jetzt drin ist. Sie arbeiten schon so lange daran, dass Sie jetzt ein CMMI für das Produkt geworden sind. Und mit Agile wirst du nicht am Ende einer Iteration da sein, am Ende eines Sprints, richtig? Alles, was Sie sich wirklich wohl fühlen und wissen, sind die Anforderungen, also die Geschichten, die während dieses Sprints abgeschlossen und bearbeitet wurden. So bauen Sie Ihr Wissen zur gleichen Zeit auf, das Entwicklungsteam baut sein Wissen auf. Und das war wahrscheinlich die größte Veränderung, die ich in meiner Denkweise machen musste, war Ordnung mit der Tatsache, dass ich nicht alles wissen würde, was ich auf dem Weg lernen würde, zusammen mit allen anderen. Die andere Sache, mit der Sie sich wohl fühlen müssen, ist Flexibilität. So springen Sie da rein, wo Sie gebraucht werden. Eines der Dinge, die wirklich gut in einer agilen Umgebung funktioniert, die wir in einer Wasserfallumgebung nicht viel tun können, ist, in anderen Bereichen zu springen und zu helfen. Denn in einer Wasserfallumgebung sind Sie so darauf ausgerichtet , alles in einer Zeit zu erledigen. Sie erledigen alle Anforderungen, die Sie tun, alle Ihre Dokumentation. Sie haben also alle Ihre Anforderungssitzungen. Sie erstellen alle Ihre Anforderungen. Sie erstellen alle Prozessflüsse. Sie erstellen alle Ihre Datenflussdiagramme, jede Art von Dokumentation, die Sie tun müssen, Anwendungsfälle, was auch immer es ist, Sie tun das Ganze. Du bist also sehr auf all das konzentriert. Was in dieser Welt zu tun hat. Und du hast Blinder an, weil du es tun musst, um das alles durchzustehen. In einer agilen Welt haben Sie jedoch etwas mehr Flexibilität, da Sie sich nur auf einen bestimmten Teil der Arbeit gleichzeitig konzentrieren. Und das lässt Sie die Möglichkeit Ihre Augen zu öffnen und in der Lage zu sein, zu sehen, was um Sie herum passiert und worauf sich der Rest des Teams konzentriert und zu hören, welche Herausforderungen haben und vielleicht verstehen als ob sie eine Straßensperre oder eine Herausforderung mit diesem Ding haben. Auch wenn das nicht Teil meiner täglichen Aufgaben ist, weiß ich, wie ich dabei helfen kann. Ich kann ihnen helfen, diese Straßensperre zu überwinden. Und du kannst sprechen und sagen, weißt du was, ich kann dir dabei helfen. So flexibel zu sein und das in Betracht zu ziehen und diese Schritte zu unternehmen, um irgendwie zu springen und Ihren Teamkollegen zu helfen , ist eine andere Sache, die Sie lernen, wie es zu tun und sich mit in einer agilen Welt vertraut zu machen. Ihr Projekt für diese Klasse ist es, zu dokumentieren, welche Erwartungen Sie für die Arbeit an einem agilen Projekt haben und welche Verschiebungen und Denkweisen Sie persönlich machen müssen, wenn Sie von einer Wasserfallumgebung zu einer agilen Ansatz oder wenn Sie neu bei Agile sind und noch nicht an Waterfall gearbeitet haben. Sie müssen also nicht unbedingt eine Schicht machen. Dann listen Sie drei Dinge auf, die Sie für eine erfolgreiche Denkweise, für eine agile Arbeitsumgebung, notwendig sind .