Schlagwortarchiv für: Agile Methoden

Tiger and Turtle, Duisburg

ZA208 - Agilität im Systems-Engineering

25.07.2023 46 Minuten



On Air in dieser Episode

avatar
Björn Schorre
avatar
Thaddäus Dorsch

Zusammenfassung

In dieser Folge tauchen wir in die Welt der Systemtechnik ein und untersuchen die Einbeziehung von Agilität in den Prozess. Mein heutiger Gast ist Dr. Thaddäus Dorsch, ein Experte auf dem Gebiet des Systems-Engineering und der agilen Methoden. Wir erfahren etwas über die Kernkonzepte des Systems-Engineering, wie Agilität eine entscheidende Rolle spielt, Best-Practice-Benchmarks für die Implementierung von Agilem Systems Engineering und die wichtigsten Erfolgsfaktoren, damit es effektiv funktioniert.

Das agile Manifest der Software-Entwicklung: https://agilemanifesto.org/iso/de/manifesto.html (bitte zuerst lesen)

Link auf das agile Manifest der System-Entwicklung: https://www.agile-systems-engineering.com/

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

 

###############

Du brauchst Hilfe bei der Definition der Anforderungen an Dein Produkt?

Dann kannst Du Dir in meinem Online-Kalender gerne einen Termin buchen: https://kalender.bjoernschorre.de

 

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

 

ZA153 - Projektmanagement in der Automobilentwicklung

11.09.2018 36 Minuten



On Air in dieser Episode

avatar
Maik Pfingsten
avatar
Alin Javorsky

Zusammenfassung

Empfehlungen aus der Episode:

ZA133 - Agiles Requirements Engineering

08.08.2017 41 Minuten



On Air in dieser Episode

avatar
Maik Pfingsten
avatar
Michael Mahlberg

Zusammenfassung

Verweise in der Episode

Auto-Transcript

Dieses Transcript ist mit einem AI-Algorithmus automatisch erstellt worden und dient dem Test und der Weiterentwicklung des AI-Systems.

[0:00] Hallo und herzlich willkommen beim ZukunftsArchitekten. Der Projektmanagement Podcast für Entscheider. Am Mikrofon ist wieder Maik Pfingsten. Als Troubleshooter a.D. gebe ich euch Tipps und Impulse aus der Praxis damit du deine Projekte auf die nächste Ebene heben kannst.

ZA130 - Top 7 Fehler beim Lastenheft

18.07.2017 22 Minuten



On Air in dieser Episode

avatar
Maik Pfingsten

Zusammenfassung

ZA125 - Die typischen Fehler beim Product Backlog

27.06.2017 31 Minuten



On Air in dieser Episode

avatar
Maik Pfingsten
avatar
Michael Mahlberg

Zusammenfassung

Transcript

[0:02] Hallo und herzlich willkommen beim ZukunftsArchitekten. Der Projektmanagement Podcast für Macher und Game Changer. Am Mikrofon ist wieder Maik Pfingsten. Als Troubleshooter a.D. gebe ich euch Tipps und Impulse aus der Praxis damit ihr eure Projekte auf die nächste Ebene heben könnt.

ja was ist eigentlich ein, Product Backlog und ist das Regal mit Requirements Management oder ist das eine To-Do-Liste wie sie klassischen Projektmanagement kennen und vor allem wie kann ich es eigentlich nutzen und so wirst du diese Episode erfahren ob ein Product Backlog für dich Sinn macht was die größten Fehler in der Praxis typischerweise sind und vor allem was da, wirklich hinein gehört ja und so dachte ich mir bevor ich jetzt alleine über dieses Thema,

rätselrater hole ich mir doch in absoluten Experten zum Thema Lean und Agil mit hier in den Podcast ist seit dem letzten Jahrtausend in diesem Kontext unterwegs mittlerweile schon fast Stamm Inventar ein Podcast ist jetzt die vierte Episode mit dem wo wir uns austauschen zu den verschiedensten Themen, er begleitet Projekte und Produkte im ganzen Kontext Agile und und parallel auch, begleitet Unternehmer Organisation,

immer dann wenn es um Prozesse geht und mich mich hier im Podcast in der Show als Gast zu haben Michael Mahlberg.

Hallo Maik schön wieder hier zu sein ja genau ich hatte ja die letzten noch mal 9 Monate, einen intensiveren wissenschaftlichen.

[1:35] Kontext und Konsens und Konflikt mit dem Product Backlog als als ein Teil der mannigfaltigen Möglichkeiten im agilen Kontext Sachen zu,

betreiben soll ich jetzt mal sehr gemeint und ich will einfach mal einsteigen mit dir was ist ein Product Backlog aus deiner Erfahrung aus deiner Sicht,

das sind wir gleich drei Fragen auf einmal ich glaube populär gemacht wurde der Begriff durch Scrum damals,

und.

Damals war das auch mit damals meine ich tatsächlich so ein bisschen sogar die Zeit bevor adaleta hieß also vor 2001 komm ist er deutlich älter,

Bernd damals war es sehr sehr klar definiert was das ist und irgendwann zu gucken woher kommt der Begriff überhaupt,

Warum Bettler.

Energien Zähne hat sich dieser Begriff inzwischen für Liste von Dingen die Verantwortung verstehen verallgemeinert aber man sich den Wortursprung anguckt stellt man fest das heißt was anderes.

Wenn er uns im englischen das angucken mehr Möpse dictionary dann steht da.

Zu Bett lag an der Kumulation of tasks an performed also eine.

Sammlung von Aufgaben die noch nicht erledigt wurden macht uns noch ein bisschen gemeiner und guckt in die Übersetzung das stehende solche Übersetzung wie Rückstand oder Nachholbedarf.

[3:05] Das heißt.

[3:09] Der eigentliche Ursprung dieses Wortes ist keineswegs etwas Gutes sondern eher okay das sind die Dinge die wir noch nicht geschafft habe.

Was ja in meiner Welt eine Liste offener Punkte nah kommt z.b. z.b. okay jetzt hat gefragt nach dem Product Backlog.

Und das tolle speclog ist halt eine Liste von Sachen die noch nicht getan wurden auf einem.

Ganz bestimmten ablations Niveau auf einem ganz bestimmten Uhrzeit Zions Level und das entscheidende dabei ist dass wir im fördert beck-blog Sachen sammeln.

Die innerhalb fester iterationszyklen abgearbeitet werden sollen hier auch wieder aus das garnwelt stammt der ursprüngliche Gedanke war.

Wir haben eine Menge von Anforderungen die im Moment theoretisch bekannt sind und wir wissen wir haben.

Bestimmte Zyklen den wir sie abarbeiten und wir haben einen kleinen Teil davon den nächsten Zyklus.

Üblicherweise des Prince der damals noch 30 Tage lang war eine heute meistens 14 Tage lang essen.

Abgearbeitet werden kann und da drunter Sachen die ungenaue sind nur noch die alten Spezifikationen und realen Beschreibung von dem was Blacklock ist angucken dann ist es tatsächlich eine Liste von Dingen.

[4:41] Die noch in der Software oder ein Produkt es geht gar nicht nur um Softwareprodukt umgesetzt werden sollen in unterschiedlicher Granularität unterschiedlicher Feinheit und.

Diese Liste ist völlig unabhängig davon ob da diese User Stories drin sind ob das.

Ja noch alles Use-Cases Features oder auch Bugs und in Hand mit requests oder sonst was sind das sagt der Begriff paclog nicht.

Limbecker stehen immer User Stories turtleback da steht immer User Stories ist einfach zu kurz gesprungen die Leute die das schon ein paar Jahre länger macht springt eigentlich von Korat iCloud items.

Und dieser Vorderdeckel Items können halt durchaus.

Aus unterschiedlichen Bereichen standen sind ziemlich verbreitet und den großen Vorteil haben dass sie.

[5:39] Requirement die Anforderung aus Sicht des Users beschreiben.

Aber auch User Stories NT ein missverstandenes Ding das heutzutage ganz oft darunter verstanden wird ist das.

Zygarde Tonformat zeigte Halbton Format weil ein Mic counters weil ursprünglich geschrieben hat,

und das besteht halt aus den drei Bereichen wer möchte dieses,

diese Fähigkeit ist es James und welche systemfähigkeit geht ist und dann sogar den alten Sachen von Cohen gar nicht so.

Weit in Vordergrund gestellt aber fulminant wichtig.

Warum zu welchem Zweck die Klasse, die klassische Formel dafür ist als ein Art des Benutzers.

Möchte ich Verhalten Systems so dass ein bestimmter geschätzt wird erzählt hat.

Das ist die heute am häufigsten anzutreffende Form.

Von Berg von Vereine von Fallout beadlock tatsächlich ist es aber durchaus gute Praxis auch alle anderen Anforderungen wieso auftauchen mit in das toiletbag Lok einzutippen.

Und es gibt sogar noch ganz viel zu sagen z.b. wer darüber die Hoheit hat das ist sehr sehr klar geregelt in Scrum das ist in anderen Prozessen nicht so klar geregelt.

Das ist halt Verhandlungssache gucken wir uns die kann man Welt an das.

[7:09] Ganz klar geregelt wir müssen es nur explizit machen nicht.

Wer das macht dick geworden das kann man ja kein process Framework ist sondern das kann man in Freiburg etwas Prozesssteuerung Prozessverbesserung ermöglicht.

Unturned wir uns Aral XP Feature Driven Development dsdm angucken die ganzen alten in Anführungsstrichen agieren Prozesse die haben davon leicht unterschiedliches Verständnis.

Wenn sofern das Quadrat Beckett muss man dann eigentlich wirklich im Kontext Denise definiert wurde betrachten das Scrum.

Okay und ich warte jetzt gerade schon von ganzen Themen Anforderungen und das ist ja auch so dicker Ursprung gewesen warum ich da auf die Reise gegangen bin eben.

Ich kenne das Lastenheft sag mal meiner klassischen Welt die Lasten aus Sicht des Auftraggebers die Anforderungen wünsche dir damit formuliert und.

Immer häufiger.

Komme ich eben halt an dem Punkt dass Leute mir zurück spielen Java wir brauchen kein lassen affair mir jetzt ein Kodak Back Lock wo ich immer so das Gefühl habe es noch da wird so Äpfel mit Birnen verglichen werden oder ob du nur,

gesagt wird wir brauchen keinen.

20 Seiten Dokument wir machen jetzt ein PDF also sprich ob man sich nicht eigentlich nur über die unterschiedliche Form unterhält was macht denn für dich das Lastenheft aus.

[8:41] Also ein entscheidender. Für mich ist Lastenheft der richtige Detaillierungsgrad dass ich als Auftraggeber meine Wünsche meine Anforderung an das von mir,

zu lösende was man sich zu lösende Problem formuliere und zwar in einer Form formuliere wie gesagt hassen dass ich,

500 Flug Ebenen nicht zu niedrig Sitze zu weit rein geht dass ich halt nicht das Problem dass ich eine Lösung anfange zu dokumentieren nein gesagt und du musst genau diese,

Quellcode Zeile umsetzen als requirement.

Dann eine sinnvolle Struktur die nachvollziehbar ist ein ganz wesentliches Element weil ich darüber viel mit Schablonen arbeiten kann.

Hersteller aber im anderen Kontext auch als als Lisa.

Mich immer wieder finde ja die wir besser die das Laster strukturiertes und so einfacher ist es für den Leser den Inhalt aufzunehmen und dazu kommt eben dass ich auch eine eine Schablone.

Bequemes Ingenieurin Ansätze reimatic Einsätze eh nicht wie du gerade beschrieben hast das Schablonen User Stories wobei diese Schablone auch ganz Clans Weg erzeugt wo ich eben.

[9:56] Interpretierbarkeit.

Maximal versuche rauszunehmen wir sind da ziemlich ähnlich unterwegs für Juristen die versuchen mit juristischen Texten auf die Interpretierbarkeit aus der klassische Problem wenn ich Statement habe.

Es ist immer interprété was wissen wir als Mensch wenn ich aber diese Schablone nutzen requirements contact also das System muss.

Bei Information SAP Impuls.

[10:25] Aktivität auslösen als globales Beispiel habe ich verschiedene Sachen wie gravitätisch muss es das soll es das kann es dass das Objekt des klar benannt der Trick aus Kabeln an die Aktivität ist klar genannt.

Wie sieht’s mal ganz schrecklich ja ist ja jetzt auch kein kein wie soll ich sagen ist jetzt auch kein Unterhaltungsroman so ein Lastenheft und es geht ja um ein,

technisches Dokument aber durch diese Vereinzelung der Anforderung durch diese requires, drin so weiter nehme ich möglichst viel Interpretierbarkeit raus wobei für mich das Entscheidungen lassen es gar nicht hinter die Verschriftlichung in einem.

20 seitigen.

Dokumente ist die sollten doch einfach nur Gutes lassen es ungefähr Umfang von 20 bis 30 Seiten und nicht wie die klassischen Lastenhefte beim industrie-contact von 300 bis 500 Seiten das ist definitiv zu detailliert und wahrscheinlich auch völlig,

inhaltlich sinnlos aber ein gutes professionelles Lastenheft wirklichen Wert hat.

Zweck bitte dann auch erfüllt hat diese großen Ordnung aber es ist gar nicht ist sondern es ist diese wir haben uns dadrüber.

[11:34] Ausgetauscht und Klarheit geschaffen dass ich verstanden habe was ich überhaupt mir wünsche genau jetzt redest du über einen ganz anderen Aspekt der,

agieren Umfelds extrem wichtiges wenn es darum geht wie kommen wir von einer Idee einer systemfähigkeit dazu dass man dieses Sehfähigkeit wirklich nutzen kann das hat auch gar nicht so viel mit dem Begriff peclot zu tun.

Das ist ein Problem dass wir heutzutage immer häufiger haben die mehr Leute agil machen.

Die Leute der der die Menge der Leute die agil arbeiten verdoppelt sich alle zwei bis drei Jahre Bern was bedeutet das im Umkehrschluss das bedeutet das.

Die Hälfte aller Leute die agil machen das erst zwei bis drei Jahre lang tun.

So was heißt da sitzen wir ganz viel auf kariertem Wissen auf das ist wie in anderen Branchen auch wenn die die Anwender schafft größer wird muss das wissen.

Anders verteilt werden als sind wenige Spezialisten sind und gerade um dieses ganze Thema wie kommen wir von der Idee zum.

Eigentlichen hinterher nutzbaren Ding gibt’s.

Ganz ganz viele Ansätze die haben unter anderem immer was mit der eben schon genannten Story zu tun die haben das mit der ID eines fördert Beck lautunterscheidung eines Product Backlog gegen ein.

Gegen ein Sprint Backlog zu tun die haben das damit zu tun dass innerhalb dieser eben von mir genannten User Story Schablone.

[13:10] Auch eine eine weitere Semantik enthalten ist das man User Stories zum späteren Zeitpunkt.

Ergänzt um Akzeptanzkriterien und dieser Kriterien sogar formal beschreibt und so weiter das hat aber eigentlich gar nichts mehr mit dem eigentlichen Gedanken des maclocks zu tun der eigentliche Gedanke des maclocks ist tatsächlich nur dass wir.

Unsere Dinge die wir durch das System jagen also.

Außerdem ist die Menge von Menschen und Maschinen die dafür sorgt dass am Ende etwas nutzbar sind dabei rauskommt wie die Systeme organisiert ist und ob das ein siebenmann Team ist oder.

Das 10 verschiedene Teams über die Welt verteilt sind bei der Mama hingestellt der Gedanke des pollerberg blocks ist einfach zu sagen okay.

Wir sammeln diese noch offenen Anforderung wir haben diese noch offenen Anforderungen in einer.

[14:07] Vom vorliegen.

Für den nächsten Zeitraum für den nächsten Sprint klassischerweise detailliert genug ist um damit tatsächlich zu arbeiten.

Und die meinte wir nach unten kommen desto epischer werden die Geschichten übrigens ein schönes Beispiel für das was Martin Fowler.

So schön formuliert hat als semantische Diffusion der Begriff epic bezeichnete früher mal,

eine noch ungenau definiert Jesus soll man weiß noch nicht ob das eine ist oder das 10 sind auf die klein ist oder ob die groß ist Gewitter werkzeuge.de das in einem ganz bestimmten Sinne verwenden denkt jeder heutzutage nur weil in.

Ja da epic eine Klammer.

Um mehrere User Stories ist das nur eine Möglichkeit damit umzugehen sein Epics immer diese Klammern.

Früher hat man das was Indira ein eckiges Martin genannt das ist dann auch wieder anders benannt worden später also die Sprache ist das.

Frieder deshalb kann ich auch gut verstehen dass du da ganz ganz viele Informationen zu Thema Blacklock bekommen hast vieles von dem was du jetzt aber als Eigenschaft mit Lastenheft geschildert hast ist er tatsächlich.

Etwas was Eigenschaft der Dinge in dem Bett lag sind und.

[15:33] Das Finden der richtigen Abstraktionsebene ganz klar ist dieser Unterscheidung zwischen.

Product Backlog und Sprint Backlog da haben wir komplett unterschiedliche Abstraktionsebenen.

Und wir gehen dann häufig noch weiter dann reden aber nicht mehr über eine einfache beadlock sowas sondern über sowas wie Story maps.

Wo wir tatsächlich noch in.

Noch größere abstraktions Einheiten unterscheiden und sagen dass wir einen Bereich haben der ist jetzt eine User activity der.

Kann den ganzen onboarding-prozess beschreiben so.

User Story aus dem Bereich wäre dann sowas weh als ein User möchte ich in der Lage sein.

Ja irgendwie bei dem System bekannt zu sein damit ich hinterher damit interagieren kann natürlich keine User Story keine queimadas mal umsetzen kann das ist so eine Top Level.

Aussage und das kann man sich dann überlegen wie man das in echte Stories runterbrechen kann kann im einfachsten Fall.

Irgendwas sein dass man dich gerne anmelden möchte das kann irgendwas komplexes sein.

Voreingestellter kannst dann ganz ganz viele Ausprägungen geben und das muss er gar nicht Mini was müssen sie Verhalten zu tun haben das kann auch.

Sein ich möchte in der Lage sein an einem Kiosk in der Straße eine Postkarte auszufüllen und danach dann hinterher mein Essen bestellen zu können.

[17:08] Ist eine User Story der vielleicht sogar klein genug in um innerhalb einer Iteration umgesetzt.

[17:16] Insofern viel von dem was du geschildert hast ist von den Begriff paclog in erster Näherung kann ich.

So direkt abgedeckt sondern das ist dann wirklich die Frage was mache ich da drin nachdem dieses Beispiel genannt.

Dass die Konversation zum wichtiger Aspekt ist.

Und ist schön weil ich mir gar nicht sicher ob ich das Wort Konversation in den Mund lege dass du was anderes die Unterhaltung was ich meinte es früher für diese für User Stories.

Aus altes Tonformat vorher gab’s die nämlich auch schon gab’s die schöne Beschreibung des eine User Story vereinigen dem CCC.

[18:03] Hardeck Modell eines PID des CCC entsprechen sollten das ist nicht der Chaos Computer Club sondern CCC steht für kalt.

Conversation confirmation heißt Karte.

Konversation Bestätigung und das bezeugt bescheid wie wir.

Die unterschiedlichen Detail level zeitlich sehen ganz zu Anfang ist das eine grobe Idee über die Mama geredet hat die sehr abstrakt beschrieben ist wo man gerade eine karte hat auf der der kurze Begriff steht.

Danach wenn wir in die Verfeinerung kommen sodass wir anfangen zu überlegen okay jetzt sollten wir mal wissen was damit genau gemeint ist damit wir es wirklich umsetzen können haben wir diese Konversation und erst wenn diese Konversation.

Stattgefunden hat können wir tatsächlich die Umsetzung gehen den hatte Umsetzung kann man doch noch mal die Bestätigung das jetzt richtig verstanden habe.

Und die die klassische Vorgehensweise einer das wirklich auch Beck noch Mensch mit Betracht übertragen ist dass wir.

Diese Kaltphase haben solange die Sachen relativ weit unten im Bett lag sind und wenn sie weiter nach oben kommen.

Gibt’s jetzt in den neueren Scrum Guide sogar eine explizit benannte Phase namens Reymond in denen das Back Lock verfeinert wird damit diese Konversation.

[19:35] Und dann sind halt doch Mittel um diese Konversation wiederum festzuhalten das heißt das Back login demnächst eine Zeile steht ist an der Stelle erstmal ein Platzhalter und ein Zeiger auf durchaus mehr entstehende Dokumente.

Heißt wenn ich mich mit ihm unterhalte früher war das dann so zu XP Zeiten irgendwann hat die Inhalte der Unterhaltung auf die Rückseite der Karte geschrieben genau heutzutage schreibt man das dann eher an ein entsprechendes System.

Sehr häufig in mehr oder weniger gut organisierte Vickys so dass man die Zusatzinformationen zu dem eigentlichen zu der eigentlichen Anforderungen sind es dann nämlich schon eine antwortung auch in deinem Sinne.

[20:18] Das zeigt auf eine Antwort umhin zu würde ich es jetzt vom Generation rechtes durch die Überschrift zu Anforderung und innerhalb dieser.

Normalerweise bis zu drei Nationen umfassenden.

Ist dies bis zu 3000 umfassenden Blogs ganz oben im Bett lag sind die Sachen so verfeinertes genau diese Informationen auch dahinterliegenden seist.

Das ist das was dafür sorgt das ganze bereit zur Umsetzung ist tatsächlich und.

Die Bestätigung es ist etwas das weiß ich nicht wie du das in deiner Lastenheft Welt tatsächlich ab bildest ich habe jetzt eine über These und man dir abgestimmt.

Diese Bestätigung ist hat sich der Dialog während der Umsetzungszeit es ist also im ursprünglichen Gedanken die man damit umgeht mittigen.

Antwort und keineswegs so dass man nachdem man die Unterhaltung hat und sich drauf committed hat ja das machen wir zusammen Situation.

Dann ist alles gut und dir reden erst am Ende wieder und haben die Konfirmation dann in Form des Tests nein die confirmation ist dass man unterwegs sagt Moment ich habe jetzt hier folgende offene Frage gefunden meintest du grün oder blau oder meintest du links oder rechts.

Und dann der Auftraggeber tatsächlich noch mal bestätigt oder eben halt verfeinert ja ich meinte rechts das hast du schon richtig verstanden oder ich meinte.

[21:41] Aber das haben wir auch das ist das ist manchmal so ein bisschen gerade im Bereich Projektmanagement und wenn es ums Lastenhefte geht immer dieses diese Trugschluss Lastenheft ist ein.

Statisches Element was einmal eingefroren für alle Ewigkeit gilt das ist ja aus meiner Sicht eben überhaupt nichts Zweck gemäß sondern diese zwei Wochen Geschichte und dann habe ich einen freigegebenen stand nach besten Wissen und Gewissen.

Aktueller Stand der Technik die Welt dreht sich weiter solche Fragen kommen hoch.

Dinge funktionieren nicht Einforderung ändern sich alles mögliche das heißt ich muss in dieser,

diesen Dialog Einsteigen in die Kommunikation muss Sachen klären und irgendwann komme ich mit einem Punkt wo ich eben halt nach okay jetzt muss ich ein Update mal machen von meinem Lastenheft.

Also verfeinern Sachen vielleicht rauswerfen anders machen oder so aber das haben wir auch und das kann teilweise sehr schnell vielleicht noch mal um auf deinen Anfang dann anfangen Frage zurückzukommen.

[22:45] Wenn jemand sagt wir brauchen keine Lastenheft für mehr wir haben jetzt hier weg locks das ist wirklich keine keine vergleichbare Aussage.

Weil der Bahn paclog gar nicht über die Inhalte so detailliert reden sondern MacLeod bescheid wie wir das Managen.

Wir reden darüber der den Wert der einzelnen Items hättest das macht nämlich derjenige der das Backlog verwaltet das Kontor Altona darüber wer die Kosten der einzelnen Blogeinträge schätzt oder.

Bewertet das macht es Umsetzung Steam darüber.

In welcher Reihenfolge wir wann wir die Reihenfolge wie ändern können beispielsweise nicht umsonst diese.

Hanus klingt aber sehr ernst gemeinte Formulierung ist ist eine sortierte Liste dass es gibt keine zwei Einträge mit derselben Priorität sondern fängt mit einem Eintritt angeht mit dem nächsten weiter.

Infinitum und all dieses das ist er das Management der Anforderung das.

Ist das was mit dem Begriff Becker zu dir ins Korn definiertes eigentlich beschrieben ist Mazda tatsächlich als Inhalt drin steht.

Ist eine Frage der Ausprägung und das können User Stories sein das können und Körper aufgebaut sein.

[24:07] Das können die Einträge ans Lastenheft sein meistens glaube ich so wie ich das nächste bisher gesehen habe vor euch von deinem noch nicht so viele gesehen habe aber leichten glaube ich das ja unterschiedliche Kandidaten haben.

Weil häufig wenn wir einen Förderbeitrag haben was user-stories hat ihren sehr starker nutzt sehr starker Fokus auf den.

Party Benutzer Wahrnehmung und auf dem Benutzer nutzen.

Dann da ist während ich den Undercut mit dem Lastenheften häufig dass es dem Verhalten im Vordergrund steht aber das mag an Diskussionen,

Detail sein,

ja, jetzt wahrscheinlich nur eine eigene Episode zu machen aber ganz kurzes für mich ist der Nutzen den das System für den Benutzer stiftet eine relevante Maßgabe uns entscheiden ob eine Anforderung einer Lastenheft rein muss,

weil der Nutzen durch diese Anfrage stark erhöht wird oder überhaupt nicht rein darf weil mit dieser Anforderung der Nutzen kaputtgemacht würde oder ob ein neutrales dann sind meistens,

Rahmenbedingung klassisch nicht funktionale Anforderungen.

[25:16] Nicht funktionale Anforderungen weglassen und ein spannendes Thema.

Wir haben die Situation.

Dass wir Anforderung haben die wir auch dokumentieren ich meinen requirement engineering requirements management ist jetzt auch keine neue Disziplin vieles von dem was ich.

Auch so recherchiert und gefunden und darüber,

Detox gesehen habe zu dem Thema erinnert mich so an an die gute alte requirements-engineering Zeit von vor 35 Jahren da haben wir auch auf Karten Anforderungen draufgeschrieben holt er ist ja ein Sünden,

lea ist eins und eins und eins von damals und es hat sich ja diese dieses ganze,

Handwerkszeug des requirement engineering requirements Sven Schmidt hat sich aber die Firma sich ja auch weiterentwickelt faszinierend macht man dann da zu gucken was in.

In context grad gemacht wird wenn er manchmal dann dann das was vor 35 Jahren reg Wahnsinn vergiss mal ganz andere Person.

Aber manchmal ist es auch wirklich notwendig Sachen in einem Kontext neu zu entdecken das finde ich gar nicht schlimm.

Rufe zurückzufordern Bäcker was sind so die ganz typischen Probleme die du aus deiner Praxis damit immer wieder siehst.

[26:34] Die größten Probleme sind eigentlich immer die die gleichen.

[26:42] Die Leute nehmen es nicht ernst genug die Leute schreiben.

Sachen ins Product Backlog bei den sie vorher nicht abgesprochen haben was eigentlich drin steht.

[26:54] Da kann ganz viel drin stehen dann muss ich noch eingeben was man da drin stehen haben will das paclog wird zu.

Selten gemanagt und es wird dieser.

Der alte CCC Gedanke vergessen und das Vollbackup wird nur.

Alle paar Wochen je nachdem Vegetationsdauer ist angeguckt das größte Problem was ich glaube ich kenne ist das man.

Ja das Cordas paclog fertig schreibt.

Was führt mich jetzt abschließend zur letzten Frage was sind so deine drei Top-Empfehlung eben bei Portable Programme zu die Probleme gesehen.

Was würdest du sagen für den hören wenn es geht.

[27:44] Nun eine sehr schöne Frage ist die Frage wirklich.

[27:53] Auf welche Seite man anfängt wenn es nur um das fördert Becker geht würde ich wirklich als wichtigstes als erstes.

Sehen dass man sich an diese ganzen alten Regen hält das man tatsächlich eine klar sortierte Liste hat das man.

Sich drum kümmert dass der oberste Teil so klar definiert ist das die Leute die das hinterher umsetzen sollen zu diesem Zeitpunkt schon wissen was.

Damit tatsächlich gemeint ist dass man sich darüber einig lass den eigentlich drin steht der.

[28:31] Und wenn wir uns in diese Szene Grauzone.

Der Anforderung begeben finde ich ist es extrem wichtig sich darüber zu reinigen und sie hat anzuhalten dass man im vordersberg halt tatsächlich Anforderungen stehen hat Aussicht.

Des Benutzers nicht Aussicht desjenigen der das ganze bezahlt.

Sondern aus Sicht desjenigen der am Ende mit dem System arbeiten soll und.

[29:06] Das sind eigentlich so die die Hauptgänge ich glaube dass.

Was mir spontan einfällt bei der Frage ist sich an die ganzen alten Regeln halten müssen und das ist tatsächlich.

Ganz ganz wichtig speclog ist halt vor einigen etwas um.

Die Anforderung zu managen wie die Anforderung Aussehen ist noch ein ganz eigener Prozess.

[29:33] Okay bin ganz eigenes ist eine ganz eigene Abstimmung das muss man auch lernen und einfach nur Sachen.

[29:40] Bin total bekloppt stehen immer Stories ist so ein grundsätzliches Verständnis und nur weil etwas der Form als ein X Willich y damit z.

Nürnberger diese Formel entspricht hat man auch noch keine echte User Story dazu gehört halt ein bisschen mehr aber das ist wirklich ein ganz anderes Thema das Thema wie kriege ich einen Quader mit,

beschrieben mrgn Kontext für mich zusammenfassend ist das Product Backlog ein Methode ein.

Werkzeug im Grunde wo ich erstmal dieses ganze Thema.

Anforderungsmanagement wechseln kann man das Projekt Anforderung an das Produkt.

Alles erstmal kann ich da rein kippen und auch das Format wie ich es nicht ob das richtig sehe sie an die Regeln halten und eben eine gemeinsames Verständnis davon sagen was gehört rein was der Richter November Rain am Bast von den verschiedenen Sachen haben wir dann eigentlich dieser Stelle.

Herzlichen Dank Michael schön dass du dabei warst wieder Freude an Ehre und ich Tickets für dich das letzte Mal noch eine ganze Menge Themen würde mich freuen.

Auch schöne neue Studie zu sagen DANKE SCHÖN gut zusammenfassung,

Free hot Episode du musst schauen ob das Product Backlog in seiner Form die du jetzt hast wirklich für dich einen Nutzen stiftet und schau ob du nicht ein diese typischen Fehler begehst die wir besprochen habe fallen was ich dir sehr ans Herzen legen kann ist eben schau dir die Tipps an die dir.

[31:13] Michael gegeben hat du hast keine Lust dass das Budget für dein Projekt explodiert und die Termine gerissen werden,

dann wird es mit dem agilen Lastenheft auf die effektivste Möglichkeit dein Projektrisiko frühzeitig zu reduzieren du hast keine Zeit oder keine Erfahrung mein Team und ich erstellen dir ein professionelles Lastenheft innerhalb von zwei Wochen zum,

Festpreisen das Beste daran mit unserer Erfolgsgarantie gehen wir mit dir,

ins Risiko wenn du Interesse hast sprich mich einfach an das war die heutige Episode des zu uns Architekten der Projektmanagement Podcast Uhrmacher,

entweder ich bin Maik Pfingsten und danke dir fürs zuhören ich wünsche dir eine schöne Zeit nach viel und habe viel Spaß was immer du gerade machst und so sage ich tschüss und bis zum nächsten Mal.

ZA098 - Warum agile Methoden das Problem nicht lösen!

02.10.2014 00:00:00.000 Stunden 00:00:00.000 Minuten



On Air in dieser Episode

Zusammenfassung

Agile Methoden versprechen ganz viele Dinge. Die Realität sieht aber deutlich anders aus. Ich greife in dieser Episode die Frage auf, ob wir mehr Agilität brauchen oder das Ganze nur ein wichtiger Schritt auf eine ganz andere Ebene ist. Am Ende der Episode wirst du erfahren, warum agile Methoden kein „Siver Bullet Aproach“ sind und wo aus meiner Sicht die Zukunft hin gehen muss.

Der Inhalt dieser Episode:

  1. Warum agile Projekte nicht besser laufen
  2. Wie kann es besser funktionieren?

Subscription link

Wenn dir der Podcast gefällt, abonniere ihn und erhalte zukünftig kostenlos alle neuen Episoden direkt auf dein Smartphone:

iTunes | RSS

Der Newsletter

Aktuelles, Tipps und Tricks gibt es im Newsletter zum Podcast

Beim Newsletter eintragen

ZA061 - Scrummerfall - Wenn Scrum scheitert

27.08.2013 00:00:00.000 Stunden 00:00:00.000 Minuten



On Air in dieser Episode

Zusammenfassung

Mich erreichte eine Hörerfrage zu Scrummerfall und ob Scrum und klassische Vorgehensweisen zusammen funktionieren können.

Scrummerfall ist eine Verwässerung von Scrum durch klassische Methoden. Eine absolute Katastrophe! Im Gegensatz dazu sind WaterScrum und Water-Scrum-Fall zwei Ansätze um klassische Vorgehensweise im Positiven durch Methoden aus der agilen Welt zu ergänzen. In dieser Episode bespreche ich die verschiedenen Ausprägungen, warum sie entstehen und wie damit umgegangen werden kann.

Die Themen der Episode:

  • Scrummerfall, WaterScrum und Water-Scrum-Fall
  • Warum entstehen die verschiedenen Varianten?
  • Wie kann mit den verschiedenen Varianten umgegangen werden?

Hinweise in der Episode:

Mich live als Speaker treffen

Subscription link

Wenn Euch der Podcast gefällt, abonniert Ihn und erhaltet zukünftig kostenlos alle neuen Episoden direkt auf Eurer Smartphone:

iTunes | Zune | RSS

Euer Feedback

Wenn Ihr eine Idee habt für den Podcast oder eine Frage für eine der zukünftigen Episoden, schreibt mir eine Mail an feedback@zukunftsarchitekten-podcast.de

Wenn Euch die Episode gefallen hat, bitte bewertet sie bei iTunes und schreibt eine ehrliche Meinung. Das würde sehr helfen, die Commuity zu erweitern! Danke.

Frage: Wie ist Eure Erfahrung mit Scrummerfall? Habt Ihr mit einen der anderen Varianten in Euren Projekten zu tun?

ZA057 - Retrospektiven - Wie ich sinnlose Meetings durch sinnvolles Lernen ersetzen kann

23.07.2013 00:00:00.000 Stunden 00:00:00.000 Minuten



On Air in dieser Episode

Zusammenfassung

Heute unterhalte ich mich mit Marc Löffler. Er arbeitet als Agile Coach bei KARL STORZ in Schweiz. Als absoluter Experte in Retrospektiven erzählt er über seine Erfahrungen und seine Tipps und Tricks. Wir sprechen auch über sein neues Buch zum Thema Retrospektiven, das er bald veröffentlichen wird.

Der Inhalt dieser Episode:

  1. Warum machen Retrospektiven Sinn?
  2. Wie kann ich Retrospektiven durchführen?
  3. Welche Tipps und Tricks gibt es?
  4. Was sind die größten Fehler?

Themen: Retrospectiven, Scrum, Agile Methoden, Die fünf Phasen einer Retrospektive, Umgang mit dem Management, Verteilte Retrospektiven, Do’s and Dont’s in Workshops

Marc Löffler im Netz

Abonnieren Sie den kostenlosen Podcast und erhalten Sie zukünftig alle neuen Episoden direkt auf Ihr Smartphone:

ZA023 - Agilität nachhaltig einführen

29.08.2012 48 Minuten



On Air in dieser Episode

Zusammenfassung

In dieser Epsiode bin ich im Gespräch mit Thomas Götz. Mit im unterhalte ich mich über die Herausforderungen in Projekten und den pragmatischen Umgang mit agilen Methoden.

Der Inhalt dieser Episode:

Weiterlesen

ZA021 - Die sieben Mythen der Agilität

30.07.2012 25 Minuten



On Air in dieser Episode

Zusammenfassung

In dieder Epsiode werde ich mich mit einigen Mythen rund um die Agilität beschäftigen. So greife ich den Blogpost „7 Agile Myths“ von Marc Löffler auf. Ich bespreche die sieben Mythen, gebe Tipps aus meiner Erfahrungen und zeige wie ich mit den Mythen umgegangen bin.

Der Inhalt dieser Episode:

Weiterlesen