Daily Build@Hardware – Workshop – Rückblick auf die ASK 2018

Erstellt am 11 Dezember 2018
von Schreibe einen Kommentar
This entry is part 2 of 2 in the series Hardware Scrum

Neue Brücken bauen und alte Brücken umsichtig abbauen – so auch die Devise bei der agilen Systementwicklung. https://commons.wikimedia.org/wiki/File:BAB3-Talbr%C3%BCcke-Heidingsfeld-02.jpg

Wir von HOOD haben in diesem Jahr bereits das zweite Mal infolge zu unserer Agile Systems Konferenz – kurz ASK in München eingeladen. Neben interessanten Keynotes nehmen unsere Workshops einen wichtigen Teil der Konferenz ein. Der Workshop über den ich heute berichte, heißt “Daily Build@Hardware”.
Wir haben einen Nachmittag lang komplett spielerisch Entwicklungsmodelle erkundet. Der Output konnte sich sehen lassen: Wir bauten Lego-Autos und Papierfliegermodelle am laufenden Band. Doch unsere Modelle hatten einen schweren Stand. Schließlich mussten sie sich den schwierigsten Anforderungen und Testabläufen stellen.

Triablog V-Modell Teil 3: Das V-Modell ist tot, es lebe Scrum!

Erstellt am 8 Oktober 2018
von Schreibe einen Kommentar
This entry is part 3 of 3 in the series Triablog-Vmodel

Man sieht es den vielen Rettungsversuchen an. Das V-Modell wird gerade ausgemustert. Ist das V-Modell auch ein Diesel?

Verblüffend ähnlich der aktuellen Diesel-Diskussionen gibt es da auch ein “Euro-6 V-Modell” Lager. Nur wird den Produktentwicklungsprozessen kein neuer Schadstofffilter dazugebaut, sondern agile “Schleifchen”.

Ich denke, die Geschichte wird sich wieder einmal wiederholen. Wieder mal eine “Kodakisierung”?

Triablog V-Modell Teil 2: Das V Gebäude

Erstellt am 28 Februar 2018
von Schreibe einen Kommentar
This entry is part 2 of 3 in the series Triablog-Vmodel

 

Entwicklung muss organisiert und strukturiert werden, das ist klar. Das V kann wohl als das Erfolgsmodell bezeichnet werden, um dieses zu tun. In Deutschland ist es aber nicht nur das standardisierte V Model XT des Bundes, es sind viele Variationen von V-Modellen, die für das Vorgehen in großen und kleinen Produktentwicklungen Pate standen.

Die Grundprinzipien, die zum V führen

Triablog V-Modell Teil 1: Das V entsteht

Erstellt am 31 Januar 2018
von 2 Kommentare
This entry is part 1 of 3 in the series Triablog-Vmodel

Cycle V temps details

In diesem und den nächsten zwei Blog’s beschäftige ich mich mit dem V-Modell. Zum einen wird das eine Basis für meinen REConf2019-Workshop “Daily Build@Hardware” sein, zum anderen geht es mir auch um eine “Dekonstruktion” des Models um die Sicht für grundsätzlich andere Vorgehensweisen zu öffnen. Im ersten Teil des Triablogs will ich erst mal die historischen Wurzeln mit einer Betrachtung der Evolution des V Models erläutern. Im zweiten Teil geht es dann um die verschiedenen Umsetzungssichten, hybride Ansätze und Erweiterungen, die zu einem agilen V-Modell führen. Der finale dritte Teil diskutiert alternative Ansätze, untersucht “Revolutionäres” und “Disruptives” und wirft einen Blick auf deren Tauglichkeit für die Produktentwicklung der Zukunft.

Wie der Product Owner die drei Sprachen der User Story lernte

Erstellt am 6 Dezember 2017
von Schreibe einen Kommentar

“Elisabeth Jerichau-Baumann [Public domain], via Wikimedia Commons; (Brothers Grimm)”

Mir wurde einmal folgende Story zugetragen:

Eine junge Frau wurde von einer renommierten Automobilfirma als Entwicklerin eingestellt. Es stellte sich jedoch heraus, dass sie sich schwer tat. Die versierten Kollegen, die das komplexe Software Code System überschauten, sprachen abfällig über sie. Der Chef der Abteilung erkannte, dass doch noch etwas mehr Fortbildung nötig wäre. Sie wurde in ein Kursprogramm eines sehr bekannten Bildungsinstituts geschickt, dort von erfahrenen Meistern des Fachs unterrichtet.

Als der System Product Owner mit dem Daily Build den Stairway to Heaven hinaufstieg

Erstellt am 10 Oktober 2017
von Schreibe einen Kommentar
This entry is part 4 of 4 in the series Agile Organisationsentwicklung

Giorgio Vasari II - Jacob's Dream - Walters 372508

Dass neue Technologien die Arbeitswelt verändern, manchmal schnell, manchmal langsam und unmerklich, das ist heutzutage offensichtlich. Dieser Wandel vollzieht sich auch in der Arbeitswelt der Erfinder und Entwickler. Es fängt damit an, dass wir am Entwicklungsplatz Neuerungen in den Entwicklungsgegenstand einbringen können. Dieser wird dann virtuell gebaut und wir können sofort testen. Klingt jetzt nicht atemberaubend, nur war das früher mit viel mehr Wartezeit verbunden.

Requirements Austausch ist Silber – Virtuelle Zusammenarbeit ist Gold

Erstellt am 14 Juni 2017
von Schreibe einen Kommentar
This entry is part 1 of 1 in the series Projektmanagement

 

Er hat der Forschung viele Rätsel aufgegeben, der um 820 entstandene sogenannte St. Galler Klosterbauplan. Heute geht man davon aus, dass es sich um einen Entwurf als Grundlage für einen weiteren eigenständigen Planungsvorgang handelt, der zwischen Auftraggebern und den Bauverantwortlichen ausgetauscht und besprochen wurde.

Das Ende des Requirements Engineerings wie wir es kennen

Erstellt am 1 April 2017
von 3 Kommentare

Nun ist es passiert ! Nach jahrhundertelangem Bemühen der Menschheit, den Weg von der Idee in die Realisierung zu verkürzen, ist der Durchbruch geschafft. Was haben sich Informatiker Gedanken über die semantische Lücke gemacht, was hat man Sprachen erfunden, um es für verschiedenste Fachdomänen praktischer zu machen, sich Hilfssysteme zu bauen. Es war immer die Hoffnung, dass wenn das Problem formuliert ist, die Lösung damit auf dem Tisch liegt.

Da hat man z.B. COBOL in die Welt gesetzt, um Wirtschaftlern  eine direkte Möglichkeit zu geben, einer Maschine sagen zu können, was man möchte. Da wurde SQL erfunden, so dass jedermann auf der Straße mal eben eine Datenbank abfragen könnte. Es ließen sich tausende weitere Beispiele und Versprechungen aufzählen, die nach einem ähnlichen Muster gestrickt sind.

Guter Kunde, schlechter Kunde – Product Owners Glück und Leid in agilen Zeiten

Erstellt am 10 Mai 2016
von Schreibe einen Kommentar

Das richtige Paradigma

b_01Wenn wir nur so gut Software und Systeme wie Häuser bauen könnten. Nein, wie ein gut gepflegter Garten- so sollten wir entwickeln. Halt, unsere Systeme sollen schon wachsen, aber die sollen auch gleich verkaufbar sein, also einen Wert stiften. Also besser, erst einmal einen Roller entwickeln, dann ein Motorrad und dann ein Auto. So sind doch erfolgreiche Produkte entstanden. Oder?

Word considered harmful

Erstellt am 12 Januar 2016
von Schreibe einen Kommentar

Anforderungsmanagement (AM) mit Word und anderen Vertretern der Office Tools Liga zu bewerkstelligen liegt nahe. Es sind bekannte Werkzeuge, sie sind praktisch überall verfügbar. Früher oder später kann es aber dazu kommen, dass Office Tools nicht als ausreichend erachtet werden. Oft ist das der Fall, wenn eine effiziente Entwicklungs-Methodik und eine höhere Automatisierung im AM nachgefragt werden. In dieser Situation kommen Lösungen ins Spiel, die spezialisiert für das Anforderungsmanagement entworfen wurden.