REVERSE-TAILORING: EIN VERFAHREN ZUR PROJEKTPLANUNG UND AUFWANDSSCHÄTZUNG

Größe: px
Ab Seite anzeigen:

Download "REVERSE-TAILORING: EIN VERFAHREN ZUR PROJEKTPLANUNG UND AUFWANDSSCHÄTZUNG"

Transkript

1 mehr zum thema: der autor REVERSE-TAILORING: EIN VERFAHREN ZUR PROJEKTPLANUNG UND AUFWANDSSCHÄTZUNG Wie kann man bei der Projektplanung Standards nutzen und gleichzeitig projektspezifischen Randbedingungen folgen? In dem Artikel wird eine Projektvorgehensweise als Synthese aus klassischen Vorgehensmodellen und Agilität vorgeschlagen, deren Anpassung an konkrete Projektsituationen genau anders herum als gewohnt funktioniert eben reverse. Anstatt aus einem allumfassenden, großen Modell die nicht benötigten Anteile herauszuschneiden, wird ein kleines, das gerade einmal Notwendige enthaltendes Rumpfmodell um zusätzliche Spezifika ergänzt. Indem die vorzunehmenden Release-Zyklen von vornherein berücksichtigt werden, entsteht eine Projektplanung, die auch für die nachfolgende Aufwandsschätzung verwendbar ist. Prof. Dr.-Ing. Christian Roth ist Geschäftsführer und Berater bei der akquinet engineering GmbH. Er ist öffentlich bestellter und vereidigter Sachverständiger für Systeme und Anwendungen der Informationstechnik sowie für Softwaretechnik an der Handelskammer Hamburg. Projektplanung und Aufwandsschätzung das hört sich zunächst an wie ein antiquiertes Vorgehensmodell mit Function-Point- Methode. Ist es aber nicht, senn die hier vorgestellten Konzepte sind durchaus praxisrelevant und das erläuterte Verfahren zur Umsetzung liefert Neues und Brauchbares: Zunächst geht es um die Feststellung, dass Aufwandsschätzungen in einem externen oder internen Auftrag - geber/auftragnehmer-verhältnis natürlich auch immer Leistungsversprechen beinhalten, im positiven wie im negativen Sinne. Legt ein Projektleiter seine Auf - wandsschätzung vor, sind die darin enthaltenen Positionen zu leisten und die darin nicht enthaltenen sind nicht geschuldet. Dadurch verschiebt sich der Blick weg von den reinen funktionalen Anfor - derungen an ein Softwaresystem, hin zu den Projektleistungen insgesamt, also z. B. auch zu den Fragen des Nach arbei - tens/konkretisierens von Anforderun gen im Projektverlauf, dem Testen oder der Einführungsunterstützung. Solche Leistungspflichten ergeben sich oft nicht direkt aus dem Lasten- oder Pflichtenheft, sondern es handelt sich eher um Fragen des Projektvorgehens und der darin insgesamt enthaltenen Tätigkeiten. Womit wir beim eigentlichen Thema wären: Wie entsteht die Projektplanung und was ist darin enthalten? Man könnte meinen, dass durch eine inzwischen agile Welt und eine Scrum- Kultur in der Softwareentwicklung eigentlich alles geklärt sein sollte. Aber das ist weit gefehlt: Agilität hilft bei der inneren Organisation im Entwicklerteam weiter und stellt insgesamt eine Philosophie für den Umgang mit Benutzern und ihren Anforderungen dar ein Vorgehensmodell für Softwareentwicklung ist aber Scrum nicht und kein Vorgehensmodell ist auch keine Lösung. So schwerfällig und bürokratisch Vorgehensmodelle auch daher kommen mögen, ganz ohne Leitplanken lassen sich größere Projekte, an denen gegebenenfalls auch unterschiedliche Parteien (z. B. Fachbereiche, Zulieferer und Nach - barprojekte) beteiligt sind, nicht erfolgreich bewerkstelligen. Es geht hier also zuerst um die Definition einer tragfähigen Projektvorgehensweise, wobei eine Synthese aus klassischen Vorgehensmodellen und Agilität vonnöten ist. Erst darauf kann eine brauchbare Aufwandsschätzung aufsetzen. Für eine praxisrelevante Umsetzung in Softwarepro - jekten bedarf es eines pragmatischen Ver - fahrens, woraus sich die Frage nach einer geeigneten Werkzeugunterstützung ergibt. Abb. 1: Gängige Praxis zur Aufwandsschätzung. Aufwandsschätzungen: So besser nicht Gängige Praxis ist die Zerlegung des Las - ten- oder Pflichtenhefts in eine zum agilen Vorgehen konforme Struktur und die an - schließende Aufwandsbewertung der ermittelten Strukturelemente. So entstehen zuerst Story-Cards, aus denen dann durch Konkretisierung Features abgeleitet werden, für die dann wiederum der Aufwand geschätzt und zugeordnet wird. Aus der Summe der Feature-Aufwände werden durch Kumulation die Aufwände der geplanten einzelnen Iterationen (Releases) ermittelt, über die Summe aller Releases entsteht der Projektaufwand. Mitunter schlägt man noch eine Pauschale für Projektleitung und Dokumentation hinzu und erhält darüber den Angebotspreis für den internen oder externen Auftraggeber seines Projekts (siehe Abbildung 1). Dieses Verfahren ist ungeeignet, weil es in erster Linie die funktionalen Anfor

2 Abb. 2: Feature-Aufwände als ein Teil des gesamten Projektaufwands. derungen aufgreift also das, was sich als Features fachlich ableiten lässt. Diese sind selbstverständlich relevant, darüber hinaus existieren aber weitergehende Aufgaben - stellungen im Projekt, z. B. gerade in agilen Projekten die regelmäßige Anforderungs - konkretisierung zu Release-Beginn und das regelmäßige Bereitstellen der Teillösung am Release-Ende, inklusive der damit verbundenen Testaktivitäten. Weiterhin gibt es einzelnen Releases übergeordnete Anfor - derungs positionen, wie etwa das Aufsetzen der Projektinfrastruktur, die Unterstützung des vom Auftraggeber zu leistenden Abnahmetests oder die Einführungsunter - stützung. Last but not least sind je nach Projektaufgabe spezifische Vorgänge zu erledigen, etwa das Erstellen einer Sicherheitsanalyse für eine Online-Anwen - dung oder eine Altdaten-Übernahme. Abb. 3: V-Modell-Tailoring in der Praxis. Solche zusätzlichen Anforderungsposi - tionen treten sowohl innerhalb von Release- Verläufen als auch übergeordnet, also das Gesamtprojekt betreffend, auf. Sie bilden den Release- oder Projektrahmen, das Drum - herum um die fachlichen Anforderun gen (siehe Abbildung 2). Der gesamte Projekt - aufwand lässt sich also erst ermitteln, wenn man neben den über die Features bestimmten Release-Aufwänden auch alle weiteren Aufwandspositionen in den Release-Rahmen und dem Gesamt projekt-rahmen kennt. Diese Rahmen (das Drum herum ) werden über die nachfolgend erläuterten Projektvorgehensweisen be stimmt. Entschei - dend ist zunächst, dass eine tragfähige Aufwandsschätzung ohne Berücksichti gung der Projektvorgehens weisen nicht zustande kommt bzw. dass die Betrachtung allein der fachlichen Release-Aufwände zu kurz greift. Auch wenn einzelne, über die Fachfunk - tionen hinausgehende Projektanforderun gen im Vertrag oder im Anforderungsdoku ment vorkommen, müssen die notwen digen Arbeitsschritte systematisch ermittelt und im geplanten Vorgehenskonzept berücksichtigt werden. Eine solche planmäßige Heran - gehens weise soll nicht nur die vollständige Erfassung von Projektanforderungen ge - währ leis ten, sondern auch das Einbeziehen unternehmensinterner Standards und Prak - tiken in der Vorgehensplanung erleichtern. Ein auf diese Weise der Aufwands - schätzung zu Grunde gelegtes, definiertes und adäquates Projektvorgehen bildet zugleich auch die Grundlage für die spätere Projektsteuerung, der insbesondere in agilen Projekten ein hoher Stellenwert zukommt. Vor diesem Hintergrund wäre es geradezu sträflich, mit pauschalen Zu schlägen beim Aufwand zu arbeiten oder notwendige Projektschritte einfach auszublenden. Projektplanung: So besser nicht Trotz aller berechtigter Begeisterung für Scrum (vgl. [Scr11]) und ähnliche agile Vorgehensweisen ersetzt Agilität als primäres Zusammenarbeitsparadigma kein Vor - gehensmodell: Die Hoffnung, über Agilität allein zu einer Systematik des Projekt - vorgehens zu finden, ist deswegen unberechtigt. Geeigneter erscheinen da schon die gängigen Vorgehensmodelle. Diesen ist in der Regel auch gemein, dass sie sich über so genanntes Tailoring an konkrete Projekterfordernisse anpassen lassen. Ist das nicht genau die Systematik, nach der wir suchen? Fast, wenn da nicht der berühmte Teufel im Detail stecken würde. Betrachten wir zur Erläuterung beispielhaft das V-Modell XT (vgl. [BIT11]). Dieses berücksichtigt moderne Projektkonzepte wie Kompo - nenten orientierung, Standardsoftware- Integration und sogar Agilität, es differenziert verschiedene Projektszenarien für das Tailoring und es bietet sogar eine Werk - zeugunterstützung dafür an. Haben Sie das schon einmal für ein konkretes Projekt ausprobiert? Sie nehmen sich die gut 800 Seiten V-Modell-Doku - mentation, müssen sich, jedenfalls dann, wenn Sie nicht gerade jede Woche damit arbeiten, zuerst einarbeiten, tailorn danach auf Ihre Anforderungen und sind das erste Mal erstaunt: Aus den 800 ursprünglichen Seiten sind um die 500 geworden. Das macht die Sache besser, aber nicht gut, denn zum zweiten Mal sind sie erstaunt festzustellen, dass viele Spezi - fika Ihrer Projektsituation trotz Tailorings leider noch nicht in Ihrem Modell enthalten sind. Und so kommt das dicke Ende zum Schluss: Der Versuch, in 500 Seiten getailortem Modell eigene Projektspezifika unterzubringen, endet spätestens nach zwei bis drei Tagen mehr oder weniger ergebnislos dann nämlich werden Sie gefragt, warum das alles so lange dauert und so kompliziert ist. Trösten Sie sich: Sie sind nicht allein und eine Antwort auf das so lange und so kompliziert können Sie jetzt auch geben: Das V-Modell-Tailoring ist für die Praxis in dieser Form schlicht nicht geeignet! Dabei bezieht sich die Kritik nicht allein auf den Tailoring-Mechanismus, sondern insbesondere auf den Gegenstand des Tailorings, also den Umfang und die Unübersicht lichkeit des Ausgangsmodells (siehe Abbil dung 3). Für ein maßgeschneidertes V-Modell muss man zuerst einmal den Gesamt - umfang präsent haben was unter realistischen Praxisbedingungen (es gibt keinen greifbaren Experten, der das jeden Tag macht) und auch für V-Modell-zertifizierte Projektingenieure mindestens eine Heraus - forderung darstellt. Das sich dann anschließende modellkonforme Tailoring ist zu grob, denn es berücksichtigt nur ganz grund legende Aspekte, beispielweise ob es sich um ein Organisations- oder Entwicklungsprojekt handelt, ob das Projekt mit oder ohne Hardwareent wick - lung ablaufen soll oder ob es eine formelle Auftraggeber-Auftragnehmer-Schnittstelle geben muss. Dies alles ist für die 2/2012

3 Projektpraxis aber eher nachrangig zumeist handelt es sich ohnehin um reine Softwareprojekte ohne formelle Unterauf - trag nehmer. Die tatsächlich wichtigen Aspekte ob nämlich ein Projekt groß oder klein ist, ob es eine Wartung, Weiterentwicklung oder Neuentwicklung verkörpert oder mit welchem agilen Konzept vorgegangen werden soll werden kaum unterstützt. Auch unternehmensinterne Standards zum Vorgehen, z. B. großes Projekt erfordert ein Berichtswesen für den Lenkungs aus - schuss, kleines nicht oder für Neuent - wicklungen ist immer ein Performancetest zu machen, lassen sich nur schwer einbeziehen. Das Einarbeiten solcher Spezifika in das bereits getailorte Projekt ist nicht nur zeitaufwendig, sondern vor allem kompliziert: Die eigenen Anpassungen liegen nämlich auf unterschiedlichen Abstrak - tions ebenen und müssen daher auf unter - schied liche Weise und mit Bedacht eingepasst werden, wenn man die Konsistenz des Gesamtmodells nicht gefährden will eine nur schwer zu leistende Aufgabe. Alles in allem enthält das V-Modell hier stellvertretend für die meisten Alternativen dazu aufgeführt zwar nützliche Pattern und Anregungen, nur müssen diese erst einmal nutzbar gemacht werden. Projektvorgehen durch Reverse-Tailoring Einer der grundlegenden Vorschläge dieses Aufsatzes ist das Reverse-Tailoring : Anstatt aus einem fast allumfassenden, großen Modell durch Tailoring die nicht benötigten Anteile herauszuschneiden, wird dabei genau das Gegenteil gemacht: Ein kleines, gerade einmal das zwingend Not wendige enthaltende respektive als solches definiertes Rumpf-Modell wird um zusätzliche Spezifika ergänzt, um so ein spezifisches Projektvo - rgehen zu definieren (siehe Abbildung 4). Dieses Rumpf-Modell besteht aus einem Raster zur Abwicklung von Releases ( Mikro-Level ), das ein- oder mehrfach in einen übergeordneten Gesamtprojekt- Rahmen ( Makro-Level ) eingehängt wird. Insofern sind über die Rahmen sowohl das Vorgehen zur Release-Ent - wicklung als auch das für das Gesamt - projekt vordefiniert. V-Modell und Scrum integriert Das Konzept der Mikro- und Makro-Ebe - nen hat grundsätzlich nichts mit dem Projektvorgehen per se oder der Abb. 4: Prinzip des Reverse-Tailoring. Aufwandsschätzung zu tun, es ist aber gut geeignet, um die Welten von V-Modell und Scrum zueinander zu bringen. Die Kombination eher schwerer Vorgehens - modelle (eine Übersicht gibt z. B. [Tho10]) mit leichtgewichtigen agilen Konzepten hat in der Projektpraxis inzwischen deutlich Raum gegriffen (vgl. z. B. [Can10]). Es werden unterschiedliche Herangehens weisen verfolgt; eine pragmatische Art und Weise der methodischen Integration stellt das hier vorgeschlagene Makro-Mikro-Ebenenkonzept dar. Auf der übergeordneten Makro-Ebene kommen in der Regel die eher formalen Aspekte der Vorgehens - modell-sicht zum Tragen, also etwa Tätigkeiten für den Test, für die Abnahme oder für die Interprojekt- und Auftrag - geber-kommunikation. Auf der darunter liegenden Mikro-Ebene geht es um die agile Abwicklung der Erstellung eines Releases. Hier gibt es zwar auch deutlich sichtbare formelle Elemente, z. B. im Zusammenhang mit dem Anforderungs - tausch (Change-Requests) oder dem Release-Test. Das Vorgehen und insbesondere die Teamarbeit und die Fachbereichs - abstimmungen sind aber bestimmt durch Praktiken aus Scrum, verkörpert durch die Rollen Product Owner (PO), Master und Team. Das Makro-Mikro-Konzept ist zugegebenermaßen recht einfach, aber eben dadurch auch gut anwendbar und eingängig: V-Modell-Praktiken kommen zuerst in den Makro-Topf und agile Verfahren zuerst in den Mikro-Topf. Beides koexistiert (fast) ungestört nebeneinander. Beispielhaft möchte ich dies für das Thema Anfor - derungsmanagement erläutern: Nach dem V-Modell wäre danach zu trachten, den Gesamtumfang der Anforderungen zu Projektbeginn zu strukturieren und hinsichtlich Aufwänden und Prioritäten zu bewerten. Nach Scrum dagegen würde man für jedes einzelne Release und erst zu dessen Startzeitpunkt einen Anforderungs- Backlog anlegen. Die darin enthaltenen Anforderungspositionen würden insofern unmittelbar vor ihrer Umsetzung konkretisiert und bewertet werden. Nach dem hier vorgestellten Vorgehen schlägt sich Anforderungsmanagement auf der Makro-Ebene und damit V-Modellkonform darin nieder, zu Projektbeginn alle Anforderungen durch Epics zu erfassen und grob in Form von User-Storys zu konkretisieren. Dergestalt konkretisierte User- Storys landen im Projekt-Backlog und repräsentieren den gesamten (funktionalen) Leistungsumfang eines Projekts. Sie bilden zugleich auch die Grundlage für die Aufwandsschätzung und auch für die Zuordnung von Anforderungspunkten zu einzelnen Release-Backlogs. Dadurch entsteht früh im Projektverlauf auch die Release-Planung. Über die ermittelten Aufwände lassen sich weiterhin für jedes Release Timeboxen definieren, d. h. festgelegte Bearbeitungssdauern

4 Abb. 5: Beispiel für Projekt- und Release-Rahmen. Auf der Mikro-Ebene für die Scrum-konforme Release-Erstellung wird der betreffende Release-Backlog vor Inangriffnahme der Release-Erstellung gemeinsam mit den Fachbereichen erneut auf seine Umsetzung hin bewertet, gegebenenfalls finden Anforderungstausche statt. Dabei werden die enthaltenen User-Storys in Gestalt von Features weiter konkretisiert. Die festgelegten Timeboxen bilden den Aufwands - rahmen für Anforderungstausche und den bei der Konkretisierung zu diskutierenden konkreten Umfang zu realisierender Anforderungen. Die Release-Erstellung folgt dann entsprechend dem gemeinsam konkretisierten, abgestimmten und aktualisierten Release-Backlog. Dieser wird gegebenenfalls in einzelne Sprints unterteilt, d. h. es entstehen Sprint-Backlogs. Das eher aus der V-Modell-Sicht herrührende Change-Management wird durch dieses Vorgehen quasi auf Agilität hin getrimmt und erfolgt letztlich durch das Verschieben von Anforderungspunkten zwischen Pro - jekt-, Release- und Sprint-Backlogs. In diesem Vorgehen ist auch das Einfrieren des Release-Backlogs nach seiner endgültigen Abstimmung zum Release-Beginn enthalten: Im V-Modell-Verständnis würde man von einem Entscheidungspunkt sprechen, einer markanten Stelle im Projekt - verlauf, von dessen Ausgang das weitere Vorgehen abhängt. Trotz aller Agilität sollte zumindest für Teilabschnitte im Projekt (hier das Release ) klar sein, was umzusetzen ist und was nicht. Das Einziehen eines formalen Meilensteins zum Fixieren von Anfor - derungen ist insofern eine Anleihe beim V- Modell, die sinnvoll für das Scrum-Vorgehen ist und die insbesondere bei Festpreis- Projekten eine wichtige Rolle einnimmt. Anhand dieser Schilderung kann man gut nachvollziehen, dass die Bedürfnisse einer eher ganzheitlich-formalen Betrachtung von Anforderungen (V-Modell-Sicht) gut mit den agilen Prinzipien der Scrum-Sicht (kurze Rückkopplung, Iterationen mit zeitnaher Anforderungskonkretisierung) vereinbar sind. Ergänzung der Releaseund Projektrahmen Zurück zum Reverse-Tailoring: Der entscheidende Punkt ist die minimale Größe der genannten Rahmen. Als minimal gilt, dass genau nur jene Arbeitsschritte im jeweiligen Rahmen enthalten sind, die man immer zwingend braucht. Da sich dies in unterschiedlichen Projektkonstellationen unterscheiden kann bzw. soll, definiert man in der Regel mehrere solcher Rahmen, also z. B. einen für kleine Wartungs projekte, einen für Neuentwicklungen from the scratch, einen für die Standardsoftware- Einführung usw. We sent lich ist, dass das jeweils definierte Minimum immer direkt ohne Anpassungen verwendbar und zu - gleich in seiner Größe überschaubar ist. Abbildung 5 zeigt das Prinzip anhand eines Projektrahmens mit zwei eingebetteten Release-Zyklen für ein Projekt aus der Versicherungswirtschaft. Zur Erstellung solcher minimaler Rahmen orientiert man sich an der gängigen Praxis, also z. B. beim Gesamtprojekt- Rahmen am V-Modell und beim Release- Rahmen an Scrum. Weiterhin sollten und werden üblicherweise zusätzlich eigene Vorgehensstandards einfließen, also die gängige Hauspraxis in einer Softwareorga - nisation. Hierzu zählen Erfahrungs werte und daraus zu ziehende Konse quen zen sowie auch feste Vorgaben der Me tho - den/verfahren-abteilung, etwa zum An - forderungs- und Testmanagement. Au ßer - dem gelten häufig formale Vorgaben, etwa seitens der Revision zur Systemdoku - mentation oder branchenspezifisch, wie z. B. MaRisk für die Finanzdienstleister 2/2012

5 Direkter Vergleich der Verfahren Das V-Modell XT mit seinen Tailoring- Mechanismen folgt nicht grundsätzlich anderen Prinzipien als denjenigen, die auch für das hier vorgestellten Reverse-Tailoring gelten. Beide Verfahren arbeiten jeweils mit unterschiedlichen Vorgehensrahmen (bzw. Rumpfmodellen) zur Anpassung. Aller - dings sind diese verschiedenen Rahmen beim V-Modell inhaltlich nur wenig eben nur ganz grundlegend differenziert, sodass man faktisch von einem Rahmen sprechen muss. Dieser eine Rahmen ist weiterhin allgemein und dadurch umfangschwerpunkt (Mindestanforderungen an das Risiko - management, vgl. Da die Rahmen minimal sind, müssen sie um die verschiedenen Spezifika eines konkreten Projekts ergänzt werden. Dies geschieht über eine Erfahrungswerte-Datenbank, die in Checklisten-Form angewendet wird. Es sollte mindestens folgende Checklisten geben: Eine für Projektrisiken ( Wodurch ist der Projekterfolg gefährdet? ) Eine für Projektmerkmale ( Was beeinflusst mein Projektvorgehen grundsätzlich? ) Projektrisiken und Projektmerkmale sind nicht streng zu trennen und beide Aspekt - gruppen könnten deswegen auch über eine gemeinsame Checkliste abgefragt werden. In der Praxis wird man aber in der Regel eine explizite Risikoanalyse für bestimmte Projekttypen vornehmen. Insofern ist es praktisch, die Projektrisiken separat zu behandeln. In diesen Checklisten werden Aspekte abgefragt wie z. B.: Reicht das Technische Know-how für den Architekturentwurf hin? Werden Nutzerdaten über das Inter - net zugänglich gemacht? Trifft ein Aspekt zu, definiert die Checkliste zugleich auch die Konsequenz daraus, nämlich das, was zusätzlich im Projektverlauf an welcher Stelle durch wen zu tun ist. Die Konse - quenz aus Nutzerdaten werden über das Internet zugänglich gemacht wären etwa zusätzlich Aktivitäten wie Sicherheits - analyse erstellen und Penetration-Tests durchführen. Für die Sicherheitsanalyse beispielsweise wäre die Rolle Chef - architekt vorzusehen; die Aktivität selbst gehört im Projektverlauf zeitlich hinter die Erstellung der Story-Cards und vor das Aufsetzen des ersten Releases. reich, weil in der Projektpraxis immer auch die Notwendig keit mehr oder weniger umfangreicher Kürzungen daran entsteht. Auch Erwei terun gen an einem immer noch umfangreichen gekürzten Rahmen sind eher schwierig, weil die dazu heranzuziehenden Projektmerkmale begrenzt sind und ebenfalls zu wenige konkrete Projekterfor - dernisse aufgreifen. Diese Effekte treten beim Reverse- Tailoring nicht auf: Es gibt beliebig viele und tatsächlich inhaltlich unterschiedliche Projektrahmen und diese müssen und sollen wegen ihrer minimalistischen Gestalt auch nicht gekürzt werden. Erweiterungen an den Projektrahmen erfolgen über wiederum beliebig umfangreiche und differenzierte Merkmals-Checklisten, die sowohl Hilfestellung bieten als auch Standardi - sierungseffekte ausüben, jedenfalls sollen sie die Projektpraxis sehr viel konkreter und detaillierter als im V-Modell aufgreifen. Minimale Rahmen und simple Checklisten lassen sich durch die Anwender sehr leicht pflegen und erweitern: eine Grundvoraus setzung für Akzep - tanz und Praxistaug lichkeit. Last but not least werden beim Reverse- Tailoring auch die vorzunehmenden Release-Zyklen von vornherein geplant und dem Projektrahmen zugefügt. Diese Release-Planung ist im V-Modell XT nicht vorgesehen, für eine Projektplanung und insbesondere die nachfolgende Aufwands - schätzung aber nötig. Inhaltlich dürften die per Reverse- Tailoring entstandenen Vorgehenspläne insgesamt stärker konkreten Projektbedürf - nissen genügen, da eher bottom up vorgegangen wird und insbesondere durch die Checklisten solche Vorgehensschritte aufgegriffen werden, die einen direkten Bezug zur Aufgabenstellung aufweisen. Interes sant dabei ist nicht allein das direkte Einbeziehen von Hausstandards über die Rahmen oder die Checklisten, sondern auch die Philosophie des Vorgehens überhaupt: Wie viel V-Modell oder wie viel Scrum in den Rahmen vorgegeben wird, ist explizit Definitionssache und soll unternehmensspezifische Bedürfnisse zur Anpassung befriedigen. Oftmals erscheinen V-Modell-Praktiken zu schwer, sodass sie nicht angewendet werden können/sollen; andererseits haben viele Scrum-Anwender längst festgestellt, dass sie ohne die Rolle Projekt leiter nicht auskommen (wollen) und Scrum insofern ergänzen. Solche Effekte lassen sich mit Reverse- Tailoring sehr leicht heilen. Durch die Projektrahmen findet ein quasi vorweggenommenes Tailoring auf reale Projekttypen statt, die konkrete Praxisan - for derungen aufgreifen sollen. Die dabei auch gewonnene Übersichtlichkeit trägt entscheidend zur Akzeptanz und zur Nachvollziehbarkeit bei. Während das Tailoring des V-Modells darauf angelegt ist, eine spezifische V- Modell-Instanz zu erzeugen, produziert Reverse-Tailoring ein Projektvorgehen, das (neben anderen Bausteinen) nur einzelne V- Modell-Elemente enthalten kann und jedenfalls nicht notwendig ein V-Modell- Instanzi ierung im formalen Sinne darstellt. Damit wird die Voraussetzung für eine wirkliche Synthese zwischen z. B. V-Modell und Scrum geschaffen, was beim starren Festhalten an einem vorgegebenen, zu instanziierenden Vorgehensmodell eher schwer fällt. Die eigentliche Aufwandsschätzung Sind die Projektrahmen über die Check - listen zu einem projektspezifischen Vor - gehen ergänzt, werden im letzten Schritt die aus den Story-Cards abgeleiteten Features (oder ersatzweise die Story-Cards selbst) entsprechend der geplanten Release- Zugehörigkeit eingefügt, sodass ein vollständiger, alle Anforderungen enthaltender Projektverlauf entsteht. Für dessen Darstel - lung verwendet man am besten eine Excel- Tabelle. Auf dieser Basis wird dann je vorkommender Tätigkeit eine Aufwands - schätzung vorgenommen und in dieser Excel-Tabelle den Anforderungspositionen zugeordnet (siehe Abbildung 6). Woher die einzelnen Aufwands schät - zungen kommen bzw. wie sie entstehen, obliegt der eigenen Entscheidung. Die Grund voraussetzung für eine tragfähige Aufwands schätzung unabhängig von der Methode ist die vorherige Strukturierung der Anforderungen in abschätzbare und insofern eher kleine als große Einzel - positionen. Dies ist einerseits bei der Projekt planung zu berücksichtigen und durch das hier vorgestellte Verfahren auch gewährleistet. Andererseits müssen auch die Story-Cards und abgeleiteten Features hinreichend klein sein erfahrungsgemäß sollte man in Arbeitspakete mit einem Aufwand bis um die 20 Personentage (PT) schneiden. Ein gängiges und einfaches Verfahren zur Aufwandsbestimmung ist die Analogie - schätzung durch zwei unabhängig arbeiten

6 schwerpunkt Abb. 6: Sinnvolle Ableitung der Aufwandsschätztabelle. de Personen: Jeder schätzt für sich allein die Positionstabelle durch. Am Ende werden die ermittelten Zahlen zusammengetragen und miteinander verglichen. Gegenstand des Vergleichs ist die Analyse nennenswerter Abweichungen: Sie fördert meistens unterschiedliche Vorstellungen über den Inhalt einer Anforderung oder ihre Umsetzung zutage. Die Abweichungsanalyse ist deswegen ein gutes Instrument zur Klärung und Absicherung der Schätzung, manchmal sogar des Projektvorgehens überhaupt. Für Festpreisprojekte ist dieses Herangehen zusätzlich wertvoll, da man auf diese Weise in der Regel immer auch Punkte identifiziert, die man für das angesetzte Budget nicht realisieren kann auf solche Leistungsausschlüsse frühzeitig hinzuweisen, hat schon manches Festpreisrisiko eingedämmt. Ein Werkzeug für die Projektpraxis Alle hier genannten Arbeitsschritte lassen sich gut und gerne über Excel oder ähnliche Instrumente durchführen. Will man jedoch mit der Zeit Standardisierungseffekte fördern und auch eine gemeinsame Erfahrungswerte-Datenbank für die Checklisten weiter entwickeln, bietet sich eine (un- Abb. 7: Schematisches Funktionsprinzip von PEST. 2 / ternehmensweite) Werkzeuglösung für die Projekte an. Unter dem Namen Project Excecution Strategy Tool (PEST) (vgl. [Sou11]) hat die akquinet engineering GmbH ein OpenSource-Werkzeug für eben diesen Zweck zur Verfügung gestellt. Dabei handelt es sich um eine Java-basierte Web-Anwendung, die Projektrahmen verarbeitet und Checklisten anbietet und über die so das Projektvorgehen einschließlich der ReleasePlanung abgewickelt werden kann. Enthalten ist je Vorgehensschritt auch eine Zuordnung zur verantwortlichen Rolle und den zur Durchführung angebotenen

7 Methodenbausteinen. In der Projektpraxis hat es sich bisher bewährt, Rollenbe - schreibungen und Methodenbausteine in einem Wiki bereitzustellen und dies zusammen mit einem Coaching-Angebot so in die Projekte hinein zu tragen. Das Tool produziert derzeit eine Datei im Format Gantt Project (vgl. [Gan11]), die dort eingelesen, weiter bearbeitet und/oder nach Excel zur Aufwandsschätzung exportiert werden kann (siehe Abbildung 7). Im Unterschied zum Tailoring-Werkzeug Projektassistent aus dem V-Modell arbeitet das Werkzeug generisch, da sowohl Projekt- und Release-Rahmen als auch die Checklisten und sich ergebenden Konse - quenzen auf den Projektablauf über XML- Dateien frei definiert werden können. Diese werden in die Datenbank des Werkzeugs eingelesen und stehen dann zur Benutzung zur Verfügung. Über die Benutzungsober - fläche werden Projekttypen zur Auswahl angeboten, die zu konkreten Projekten instanziiert und über die Release-Planung und die Checklisten ausgebaut werden können. Sinnvollerweise würde man eine Anzahl geeigneter Standard-Projektrahmen und Erfahrungswerte-Checklisten nicht nur vorgeben, sondern kontinuierlich pflegen und verbessern. Durch die regelmäßige Literatur & Links [BIT11] Bundesstelle für Informationstechnik (BIT), V-Modell XT, Stand September 2011, siehe: Methoden/V-Modell_20XT/node.html [Can10] S. Canditt, D. Rauh, M. Wittmann, Brückenschlag: Das V-Modell XT mit Scrum inside, in: OBJEKTspektrum 5/2010 [Gan11] Gantt Project, Stand: September 2011, siehe: [Scr11] Scrum, Stand September 2011, siehe: Anwendung des Verfahrens entsteht ein gemeinsames Verständnis über Projekt - planung und Aufwandsschätzung, das durch ein einfaches Vorgehen und eine schlanke Werkzeugunterstützung gute Erfolgsaussichten in der Praxis hat und zu besseren Planungsergebnissen führt. [Sou11] Sourceforge, Project Excecution Strategy Tool, Stand September 2011, siehe: [Tho10] O. Thomas, K. Leyking, M. Scheid, Serviceorientierte Vorgehensmodelle: Überblick, Klassifikation und Vergleich, in: Informatik Spektrum 33 aus 4/

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich

Di 7.2. Sprinten mit dem V-Modell XT. Olaf Lewitz. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Di 7.2 January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Sprinten mit dem V-Modell XT Olaf Lewitz Sprinten mit dem V-Modell XT Olaf Lewitz microtool GmbH, Berlin Konkurrenz

Mehr

Projektmanagement durch Scrum-Proxies

Projektmanagement durch Scrum-Proxies Cologne Intelligence GmbH Projektmanagement durch Scrum-Proxies Integration von Vorgehensmodellen und Projektmanagement 17. Workshop der Fachgruppe WI-VM der Gesellschaft für Informatik e.v. Stuttgart,

Mehr

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012

Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012 Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel Verglühte die Raumfähre Columbia durch einen unflexiblen Projektmanagementprozess? Rückblick: 2003 verglühte

Mehr

Software Engineering. 2. V-Modell XT

Software Engineering. 2. V-Modell XT Software Engineering 2. V-Modell XT Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Implementierung Konfigurationsmanagement

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Von 0 auf 13 oder mit Vollgas ins agile Zeitalter

Von 0 auf 13 oder mit Vollgas ins agile Zeitalter Von 0 auf 13 oder mit Vollgas ins agile Zeitalter Silvio Simone, Bison Group Susanne Mühlbauer, HOOD GmbH Scrum Day 2012 Bison Schweiz AG Surentalstrasse 10 CH-6210 Sursee www.bison-group.com HOOD GmbH

Mehr

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch -

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch - Prof. Dr. Roland Petrasch, Beuth Hochschule für Technik prof.beuth-hochschule.de/petrasch Stefan Lützkendorf Projektron GmbH

Mehr

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch

Agiles Testmanagment. Hugo Beerli bbv Software Services AG. Luzern, September 2011. www.bbv.ch Agiles Testmanagment Hugo Beerli bbv Software Services AG Luzern, September 2011 Product Backlog (Agenda) 1) Warum System Tests 2) Agile Arbeitsmethode Stand up Meeting 3) Vorteile der agilen Methode 4)

Mehr

Berliner XML Tage 2005: Abbildung des V-Modell XT in Projektron BCS

Berliner XML Tage 2005: Abbildung des V-Modell XT in Projektron BCS Berliner XML Tage 2005: Abbildung des V-Modell XT in Projektron BCS Prof. Dr. Roland Petrasch Dipl.-Inform., M.Sc. Florian Fieber Fachbereich VI Informatik und Medien Technische Fachhochschule Berlin Luxemburger

Mehr

Agiles Vorgehen Do s und Don ts im Umfeld und beim Management

Agiles Vorgehen Do s und Don ts im Umfeld und beim Management Agiles Vorgehen Do s und Don ts im Umfeld und beim Management Vortrag bei der Fachgruppe IT-Projektmanagement 22. Mai 2015, Steinbeis-Transferzentrum IT-Projektmanagement, Stuttgart hoffmann@stz-itpm.de

Mehr

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung

Agile BI Kickstart. Beschreibung des Workshops. Workshopbeschreibung Bereich: Workshop: Dauer: In-House Workshop Agile BI Kickstart 2 Tage Beschreibung des Workshops Agile Vorgehensweisen werden bei der Entwicklung von BI- und Data Warehouse-Lösungen heutzutage mehr und

Mehr

Projektmanagement V-Modell XT-konform gestalten

Projektmanagement V-Modell XT-konform gestalten Projektmanagement V-Modell XT-konform gestalten PMI Munich Chapter Meeting 20. März 2007 Dr. Marc Sihling 2007 4Soft GmbH Agenda Überblick V-Modell XT Projektinitialisierung Tailoring Rollenbelegung Projektplanung

Mehr

Unsere Kunden erzählen keine Geschichten. Ursula Meseberg microtool GmbH Berlin

Unsere Kunden erzählen keine Geschichten. Ursula Meseberg microtool GmbH Berlin Unsere Kunden erzählen keine Geschichten Ursula Meseberg microtool GmbH Berlin Unsere Kunden erzählen keine Geschichten Ein modellbasierter Prozess für die Anforderungsanalyse im Vorfeld agiler Produktentwicklung

Mehr

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare

Praktische Erfahrungen beim Einsatz des Vorgehensmodells SCRUM bei AGFA HealthCare Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare SCRUM Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" eines Entwicklerteams von AGFA HealthCare 2 Praktische

Mehr

Requirements Engineering für die agile Softwareentwicklung

Requirements Engineering für die agile Softwareentwicklung Johannes Bergsmann Requirements Engineering für die agile Softwareentwicklung Methoden, Techniken und Strategien Unter Mitwirkung von Markus Unterauer dpunkt.verlag Inhaltsverzeichnis 1 Einleitung 1 1.1

Mehr

Machbar? Machbar! 07.10.2010

Machbar? Machbar! 07.10.2010 TANNER AG 2010 TANNER AG Kemptener Straße 99 D-88131 Lindau (B) Telefon +49 8382 272-0 Fax +49 8382 272-900 www.tanner.de info@tanner.de Agile Softwareentwicklung im regulativen Umfeld. Machbar? Machbar!

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

Bekannte Tools in einem agilen Ansatz. Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013

Bekannte Tools in einem agilen Ansatz. Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013 Bekannte Tools in einem agilen Ansatz Frank Schwichtenberg SourceTalkTage 2013 Göttingen, 2.10.2013 Vorher Lange Planungszeiten und Releasezyklen Manche Features brauchten lange und wurden nicht gebraucht

Mehr

Management großer Projekte Ein modellbasierter Ansatz

Management großer Projekte Ein modellbasierter Ansatz Management großer Projekte Ein modellbasierter Ansatz Dr. Dehla Sokenou Herausforderungen des Projektmanagements Projekt Initialisierung Aufgaben sinnvoll planen/partitionieren Projekt Monitoring Arbeitsergebnisse/Status

Mehr

Requirements Lifecycle Management (RLM)

Requirements Lifecycle Management (RLM) Whitepaper Requirments Lifecycle Management Requirements Lifecycle Management (RLM) Die Weiterentwicklung der klassischen Anforderungsanalyse 1 Einleitung War noch vor einiger Zeit die klassische Anforderungsanalyse

Mehr

DP ITS Vorgehensmodell Build und Microsoft Team Foundation Server

DP ITS Vorgehensmodell Build und Microsoft Team Foundation Server DP ITS Vorgehensmodell Build und Microsoft Team Foundation Server Martin Tappe Düsseldorf, April-08-2009 GIWIVM AGENDA Referent Zum Forschungsprojekt DP ITS Vorgehensmodell Build (VMB) Microsoft Team Foundation

Mehr

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Projektplan Software Engineering Projekt November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1 Der Projektplan Grundlage der gemeinsamen Arbeit innerhalb des Teams und mit

Mehr

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015 Agiles Vorgehen 2 Agiles Vorgehen 3 WAS BEDEUTET AGIL Abstimmung über Ziel (nicht konkretes Entwicklungsergebnis)

Mehr

Projektmanagement. Projektmanagement

Projektmanagement. Projektmanagement Projektmanagement Dipl.-Ing. Oliver Lietz Was ist ein Projekt? Projektmanagement Eindeutiges Ziel Individuell (einmalig) Begrenzt (Anfang und Ende) Komplex (keine Routineaufgabe) Warum Projektmanagement

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Markup-basiertes Spezifikationsund Anforderungsmanagement in agilen Softwareprojekten

Markup-basiertes Spezifikationsund Anforderungsmanagement in agilen Softwareprojekten Roman Roelofsen Prof. Dr. Stephan Wilczek Markup-basiertes Spezifikationsund Anforderungsmanagement in agilen Softwareprojekten Konferenz Software Engineering & Management 2015 Dresden 19.03.2015 3 Rollen

Mehr

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer Wasserfall vs. Agile: Eine Erfolgsstory 2 Umsetzung agiler Prinzipien Entwicklungsprozess 2009 30.6% 13.4% 20.6% 35.4% Agil Iterativ

Mehr

Produktphilosophie erstellen

Produktphilosophie erstellen User Experience Produktphilosophie erstellen Bereich Anforderungen Aktivität Ziele Erleichterte Kommunikation zwischen Stakeholdern Designentscheidungen erleichtern/rechtfertigen schnell durchführbar einfach

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen

Scrum technische Umsetzung und kaufmännische Rahmenbedingungen Scrum technische Umsetzung und kaufmännische 9. Darmstädter Informationsrechtstag 2013 Darmstadt, 15. November 2013 Franziska Bierer 2 andrena ojects ag Gründung 1995 Standorte in Karlsruhe und Frankfurt

Mehr

Scrum undprojektmanagement à la GPM. Markus Schramm compeople AG Frankfurt

Scrum undprojektmanagement à la GPM. Markus Schramm compeople AG Frankfurt Scrum undprojektmanagement à la GPM Markus Schramm compeople AG Frankfurt GPM scrum ed GPM, Scrum, warum? Projektablauf koordinieren Einheitliches Vorgehen Gemeinsames Verständnis Gemeinsame Sprache Freestyle

Mehr

Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren

Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren Agile Entwicklung in IT-Projekten - Anforderungen an Systemintegratoren Unternehmensberatung H&D GmbH AFCEA Mittagsforum M. Sc. Dipl. Ing. (FH) Matthias Brechmann Agenda Unternehmensberatung H&D GmbH Anforderungen

Mehr

Firmenportrait open4business GmbH. open4business. Softwareentwicklung für Unternehmen

Firmenportrait open4business GmbH. open4business. Softwareentwicklung für Unternehmen Firmenportrait open4business GmbH open4business Softwareentwicklung für Unternehmen Wer sind Wer wir sind Kurzprofil Die open4business GmbH ist ein mittelständisches IT-Dienstleistungsunternehmen mit Firmensitz

Mehr

agile.agreement Beschaffung und Durchführung von agilen Projekten in der öffentlichen Verwaltung simplify your business

agile.agreement Beschaffung und Durchführung von agilen Projekten in der öffentlichen Verwaltung simplify your business agile.agreement Beschaffung und Durchführung von agilen Projekten in der öffentlichen Verwaltung simplify your business Agenda 1. Herausforderung «agile» - Frage: Wie schaffen wir Voraussehbarkeit und

Mehr

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Softwareentwicklungsprozesse optimieren wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren Dipl.-Inform. Dipl.-Math. Wolfhart Grote Software Ring e. G., Erlangen 25. Oktober 2007

Mehr

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/

Mehr

Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum

Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum Leichtgewichtige Traceability im agilen Entwicklungsprozess am Beispiel von Scrum Traceability Workshop SE 2013 Aachen 26. Feb. 2013 Elke Bouillon 1, Baris Güldali 2, Andrea Herrmann 3, Thorsten Keuler

Mehr

Produktmanagement vom Kundenticket zum Release

Produktmanagement vom Kundenticket zum Release Produktmanagement vom Kundenticket zum Erfahrungen aus vier Jahren Entwicklung nach SCRUM, Geschäftsführer, Scrum Master 7 von 58 9 von 58 Bekannte Kunden 10 von 58 17 von 58 20 von 58 Ziele der Einführung

Mehr

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten

Projektmanagement. Dokument V 1.2. Oliver Lietz - Projektmanagement. Probleme bei Projekten Projektmanagement Agile Methoden: Extreme Programming / Scrum Dokument V 1.2 Probleme bei Projekten Viel Arbeit, die an den Zielen vorbeigeht Viel Dokumentation für f r unbenutzte Bestandteile Fehlende

Mehr

1 Einleitung. 1.1 Unser Ziel

1 Einleitung. 1.1 Unser Ziel 1 Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde

Mehr

Vor dem Projektstart Work-Break-Down-Structure (Arbeitspakete)

Vor dem Projektstart Work-Break-Down-Structure (Arbeitspakete) 5. Projektplanung und -verfolgung Vor dem Projektstart Work-Break-Down-Structure (Arbeitspakete) Netzplan Gantt-Diagramm Ressourcenverwaltung Projektverfolgung 112 Vor dem Projektstart Bevor die eigentliche

Mehr

Vor dem Projektstart. 5. Projektplanung und -verfolgung. Vor dem Projektstart Work-Break-Down-Structure (Arbeitspakete) Netzplan Gantt-Diagramm

Vor dem Projektstart. 5. Projektplanung und -verfolgung. Vor dem Projektstart Work-Break-Down-Structure (Arbeitspakete) Netzplan Gantt-Diagramm 5. Projektplanung und -verfolgung Vor dem Projektstart Work-Break-Down-Structure (Arbeitspakete) Netzplan Gantt-Diagramm Ressourcenverwaltung Projektverfolgung Vor dem Projektstart Bevor die eigentliche

Mehr

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Taking RM Agile CLICK TO EDIT MASTER OPTION 1 Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum Click to edit Master subtitle style Christian Christophoridis Requirements Management

Mehr

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: +49 631/3724-5329 http://www.hs-kl.de/~amueller

Mehr

Plagemann Rechtsanwälte. Mediation

Plagemann Rechtsanwälte. Mediation Plagemann Rechtsanwälte Mediation Was ist Mediation? Bei der Mediation handelt es sich um ein Verfahren der außergerichtlichen Konfliktlösung. In Gesprächen der Konfliktparteien unter Begleitung des Mediators

Mehr

V-Methode, RUP, Waterfall oder was?

V-Methode, RUP, Waterfall oder was? 5. Bayerischer IT-Rechtstag am 26. Oktober 2006 auf der SYSTEMS 2006 in München Übersicht über die verschiedenen Vorgehensmodelle Dr. Sarre & Schmidt EDV-Sachverständige, München Öffentlich bestellter

Mehr

Mi 2.3. Erfolgreiche Projektplanung und Fortschrittskontrolle mit Use Cases. Tom Krauß. Copyright 2008 GEBIT Solutions www.gebit.

Mi 2.3. Erfolgreiche Projektplanung und Fortschrittskontrolle mit Use Cases. Tom Krauß. Copyright 2008 GEBIT Solutions www.gebit. Mi 2.3 Erfolgreiche Projektplanung und Fortschrittskontrolle mit Use Cases Tom Krauß Agenda Motivation Use Case orientiertes Projektmanagement Grundsätzliche Idee Variationsmöglichkeiten Integration in

Mehr

Pflegende Angehörige Online Ihre Plattform im Internet

Pflegende Angehörige Online Ihre Plattform im Internet Pflegende Angehörige Online Ihre Plattform im Internet Wissen Wichtiges Wissen rund um Pflege Unterstützung Professionelle Beratung Austausch und Kontakt Angehörige helfen sich gegenseitig Wir suchen Sie

Mehr

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise

Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Klausur mit Lösungshinweisen zur Vorlesung Planung und Entwicklung von IuK-Systemen Sommersemester 2005 02. August 2005 Deckblatt Hinweise Die Bearbeitungszeit der Klausur beträgt 90 Minuten. Es sind alle

Mehr

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt

myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt myscrum Scrum in der Praxis Markus Schramm compeople AG Frankfurt Überblick Agilität und Scrum Grundlagen der agilen Softwareentwicklung Rahmenbedingungen bei der Einführung eines agilen Projektvorgehens

Mehr

m.e.d. concept methode erfolg datenverarbeitung V-Modell XT im Überblick 2 V-Modell XT Einführung - Analyse und Roadmap 3

m.e.d. concept methode erfolg datenverarbeitung V-Modell XT im Überblick 2 V-Modell XT Einführung - Analyse und Roadmap 3 Projektmanagement Kompetenztraining V-Modell XT Das V-Modell XT ist urheberrechtlich geschützt, Bundesrepublik Deutschland, 2004, Alle Rechte vorbehalten m.e.d. concept methode erfolg datenverarbeitung

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches

Einleitung. Was ist das Wesen von Scrum? Die Ursprünge dieses Buches Dieses Buch beschreibt das Wesen von Scrum die Dinge, die Sie wissen müssen, wenn Sie Scrum erfolgreich einsetzen wollen, um innovative Produkte und Dienstleistungen bereitzustellen. Was ist das Wesen

Mehr

Aufwandsschätzung in Scrum

Aufwandsschätzung in Scrum Aufwandsschätzung in Scrum 1 Planning Poker und Varianten 2 HINWEIS Aus lizenzrechtlichen Gründen sind in dem Handout die meisten Bilder und Grafiken entfernt worden. Ich bitte um Verständnis. 3 1. Scrum

Mehr

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming /

Software- Projektmanagement. Dokument V 1.2-2010. Oliver Lietz - Projektmanagement. Projektmodelle im Vergleich. Agil Extreme Programming / Software- Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.2-2010 Projektmodelle im Vergleich Klassisch Wasserfall -Modell Spezifikation/Pflichtenheft

Mehr

Testmanagement im agilen Entwicklungsprozess

Testmanagement im agilen Entwicklungsprozess Testmanagement im agilen Entwicklungsprozess Unser Beratungsangebot für die effiziente Abwicklung von Projekten: n Anforderungen erkennen n Software-Qualität steigern n Teams zum Erfolg führen Unser Erfolgskonzept:

Mehr

SCRUM. Software Development Process

SCRUM. Software Development Process SCRUM Software Development Process WPW 07.08.2012 SCRUM Poster www.scrum-poster.de Was ist Scrum? Extrem Schlanker Prozess 3 Rollen 4 Artefakte Wenige Regeln Die Rollen Product Owner Der Product Owner

Mehr

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen

ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen ISO 13485 konforme Entwicklung medizinischer Software mit agilen Vorgehensmodellen Bernhard Fischer Fischer Consulting GmbH MedConf 2009 Folie 1 Wie soll Software entwickelt werden? MedConf 2009 Folie

Mehr

das agile.agreement Agilen Projekten gehört die Zukunft. Wir zeigen Ihnen, wie Sie diese richtig anpacken.

das agile.agreement Agilen Projekten gehört die Zukunft. Wir zeigen Ihnen, wie Sie diese richtig anpacken. das agile.agreement Agilen Projekten gehört die Zukunft. Wir zeigen Ihnen, wie Sie diese richtig anpacken. was Sie JETZT lernen werden 1. Methode, um mit agilen Projekte einen festen Kostenrahmen, einen

Mehr

PQ4Agile Agiler Referenzprozess

PQ4Agile Agiler Referenzprozess PQ4Agile Agiler Referenzprozess ARBEITSPAKET 1.1 KONSORTIUM Projekt Förderprogramm PQ4Agile KMU Innovativ Förderkennzeichen 01IS13032 Arbeitspaket Fälligkeit 31.07.2014 Autor Status Klassifikation AP1.1

Mehr

Agile Programmierung - Theorie II SCRUM

Agile Programmierung - Theorie II SCRUM Agile Programmierung - Theorie II SCRUM Arne Brenneisen Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Christian

Mehr

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter. Dirk.Prueter@gmx.de SCRUM Legalisierung der Hackerei? GI Regionalgruppe Dortmund 07.12.2009 Dipl.-Inform. (FH) Dirk Prüter Dirk.Prueter@gmx.de Überblick Was ist SCRUM Wie funktioniert SCRUM Warum lohnt es sich, SCRUM anzuwenden

Mehr

Agile Methoden bei der Entwicklung medizinischer Software

Agile Methoden bei der Entwicklung medizinischer Software Agile Methoden bei der Entwicklung medizinischer Software Bernhard Fischer Fischer Consulting GmbH Fischer Consulting GmbH Technologie-Forum 2008 Folie 1 Wie soll Software entwickelt werden? Fischer Consulting

Mehr

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Marcus Winteroll oose GmbH Agenda I. Ziele und Zusammenarbeit II. Was wir vom agilen Vorgehen lernen

Mehr

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007

Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Software Engineering und Projektmanagement Fragenausarbeitung der Prüfung vom 26.04.2007 Christoph Redl Quelle der Fragen: http://www.informatik-forum.at/showthread.php?t=54097 1 SCRUM Prinzip + Vorteile

Mehr

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer

Agiles Projektmanagement. erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011. Thomas Hemmer Agiles Projektmanagement erklärt in 30 Minuten! IT-Forum Agiles Projektmanagement, NIK 29. Juni 2011 Thomas Hemmer Chief Technology Officer thomas.hemmer@conplement.de conplement AG, Nürnberg 2 conplement

Mehr

das agile.agreement Agile Projekte bedürfen agiler Vertragsmechanismen Thomas Molitor (Consultant)

das agile.agreement Agile Projekte bedürfen agiler Vertragsmechanismen Thomas Molitor (Consultant) das agile.agreement Agile Projekte bedürfen agiler Vertragsmechanismen Thomas Molitor (Consultant) Dr. Pascal AG Was ist der Nutzen des agile.agreements? Das agile.agreement, als ein praxistaugliches Vertragsmodell

Mehr

Das V-Modell XT in kleinen Projekten Möglichkeiten und Grenzen

Das V-Modell XT in kleinen Projekten Möglichkeiten und Grenzen Das V-Modell XT in kleinen Projekten Möglichkeiten und Grenzen Erfahrungen aus einem sehr kleinen Projekt Dr. Ralf Kneuper Prof. Dr. Matthias Knoll 1 Ralf Kneuper Dipl.-Mathematiker, Univ. Bonn PhD Computing

Mehr

Timeboxing. Rückgrat agiler Projekte. Bernd Oestereich (Geschäftsführer) Christian Weiss (Geschäftsführer) Timeboxing Rückgrat agiler Projekte

Timeboxing. Rückgrat agiler Projekte. Bernd Oestereich (Geschäftsführer) Christian Weiss (Geschäftsführer) Timeboxing Rückgrat agiler Projekte Bernd Oestereich (Geschäftsführer) Timeboxing Rückgrat agiler Projekte Christian Weiss (Geschäftsführer) Copyright by oose GmbH 2006 Das Wasserfallmodell ein historisches Mißverständnis. Der Wasserfallprozess-

Mehr

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander?

INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung. Robust und Agil gegeneinander oder miteinander? INFOGEM AG Informatiker Gemeinschaft für Unternehmensberatung Rütistrasse 9, Postfach 5401 Baden, Switzerland Phone: +41 56 222 65 32 Internet: www.infogem.ch Robust und Agil gegeneinander oder miteinander?

Mehr

HERMES 5 und Requirements-Engineering

HERMES 5 und Requirements-Engineering HERMES 5 und Requirements-Engineering Emmerich FUCHS, zur Zeit aktiv für Eidgenössisches Finanzdepartement EFD Eidgenössisches Personalamt EPA / Ausbildungszentrum der Bundesverwaltung AZB HERMES 5 und

Mehr

DSDM Atern: Agiles Vorgehen für Konzerne? Carsten Sahling, Malte Sörensen Holis3con AG

DSDM Atern: Agiles Vorgehen für Konzerne? Carsten Sahling, Malte Sörensen Holis3con AG DSDM Atern: Agiles Vorgehen für Konzerne? Carsten Sahling, Malte Sörensen Holis3con AG Über uns... Carsten Sahling Leitung GeschäGsfeld Agil Cer3fied Scrum Professional Projektmanagement- Fachmann Level

Mehr

7 Projektplanung. V-Modell XT Anwendung im Projekt.

7 Projektplanung. V-Modell XT Anwendung im Projekt. <Datum> <Organisation> <Veranstaltungsort> <Vortragender> <Organisation> Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 7 Projektplanung V-Modell XT Anwendung im Projekt Überblick

Mehr

Scrum. Eine Einführung

Scrum. Eine Einführung Scrum Eine Einführung Scrum-Charakteristika einfache Regeln wenige Rollen Pragmatismus statt Dogmatik iteratives Vorgehen Scrum auf einer Seite erklärt 3 Rollen für direkt am Prozeß beteiligte 1) Product

Mehr

10 Trends und neue Entwicklungen im Projektmanagement

10 Trends und neue Entwicklungen im Projektmanagement 10 Trends und neue Entwicklungen im Projektmanagement 10.1 Zukünftige Anforderungen im Projektmanagement Produkte folgen einem typischen Lebenszyklus, der in der Regel mit einer innovativen Idee startet.

Mehr

Softwareentwicklung mit dem V-Modell XT. Erfahrungen, Einschätzungen, Empfehlungen

Softwareentwicklung mit dem V-Modell XT. Erfahrungen, Einschätzungen, Empfehlungen Softwareentwicklung mit dem V-Modell XT Erfahrungen, Einschätzungen, Empfehlungen Arne Schneikart - ZIVIT - 12.04.2006 Zentrum für Informationsverarbeitung und Informationstechnik Seit 1.1.2006: IT-Dienstleister

Mehr

Abb.: Darstellung der Problemfelder der Heine GmbH

Abb.: Darstellung der Problemfelder der Heine GmbH Entwicklung eines SOLL-Konzeptes Kehl Olga 16.05.10 Wie aus der Ist-Analyse ersichtlich wurde, bedarf die Vorgehensweise bei der Abwicklung von Projekten an Verbesserung. Nach der durchgeführten Analyse

Mehr

Der Business Analyst in der Rolle des agilen Product Owners

Der Business Analyst in der Rolle des agilen Product Owners Der Business Analyst in der Rolle des agilen Owners HOOD GmbH Susanne Mühlbauer Büro München Keltenring 7 82041 Oberhaching Germany Tel: 0049 89 4512 53 0 www.hood-group.com -1- Inhalte Agile Software

Mehr

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014]

Agiles Schätzen. Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Agiles Schätzen Quelle: Kap. 7 aus Wie schätzt man in agilen Projekten oder wieso Scrum-Projekte erfolgreicher sind [Boris Gloger 2014] Schätzen der Größe Wir bestimmen die Größe, nicht den Aufwand. Auf

Mehr

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. Wir erledigen alles sofort Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind. agilecoach.de Marc Bless Agiler Coach agilecoach.de Frage Wer hat

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Das neue V-Modell XT. Methodik, Anwendung, Nutzen

Das neue V-Modell XT. Methodik, Anwendung, Nutzen Das neue V-Modell XT Methodik, Anwendung, Nutzen Wolfgang Kranz EADS Deutschland GmbH Defence Electronics 85716 Unterschleißheim Landshuterstr. 26 Tel. +49 89 3179-2786, Fax -2528 mobil: +49 172 8488200

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

Mehr

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center

PRINCE2 TAG 2011. PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr. Peter Morwinski, Leiter Technologie Center Ihr starker IT-Partner. Heute und morgen PRINCE2 in Projekten der Bundesbehörden und der Bundeswehr PRINCE2 TAG 2011 Peter Morwinski, Leiter Technologie Center INHALT PRINCE2 und V-Modell XT Einleitung

Mehr

Agiles Testmanagement am Beispiel Scrum

Agiles Testmanagement am Beispiel Scrum Agiles Testmanagement am Beispiel Scrum SEQIS Software Testing Know-How Weitere Termine 16. September Testmanagement mit externen Partnern 21.Oktober Software unter Druck: Erfolgsfaktoren bei Last- und

Mehr

Vertragsrecht in agilen Softwareprojekten. Prof. Ursula Sury, RA

Vertragsrecht in agilen Softwareprojekten. Prof. Ursula Sury, RA Vertragsrecht in agilen Softwareprojekten Prof. Ursula Sury, RA 1 Agenda Die zentrale Frage/ Grundelemente des Softwarevertrags Ablauf der Softwareentwicklung Ziele der agilen Software Besonderheiten der

Mehr

Toolgestütztes Qualitäts- und Projektmanagement für die Software- Entwicklung

Toolgestütztes Qualitäts- und Projektmanagement für die Software- Entwicklung Expose Forschungsprojekt Toolgestütztes Qualitäts- und Projektmanagement für die Software- Entwicklung Version 1.0 Stand: 13.07.2005 Autor: Florian Fieber Forschungsassistent Dipl.-Inform., M.Sc. Florian

Mehr

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird.

Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. AGILO HOWTO Agilo [1] ist ein auf Trac [2] basierendes Scrum [3] Tool. Im Folgenden soll eine kurze Überischt gegeben werden, wie Agilo benutzt wird. ROLLEN IM TEAM In Scrum hat jedes Teammitglied eine

Mehr

Werte und Prinzipien der agilen Softwareentwicklung

Werte und Prinzipien der agilen Softwareentwicklung 1 Was ist Scrum? Scrum ist ein einfaches Projektmanagement-Framework, in das Entwicklungsteams selbstbestimmt erprobte Praktiken einbetten. Der Rahmen sieht einen empirisch, iterativen Prozess vor, bei

Mehr

Software Engineering

Software Engineering Software Engineering Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik Prof. A. Müller, FH KL Software Engineering 2015 1 Inhalte Begrüßung Vorstellung, Übersicht Formales

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Agile Projekte in Auftrag geben

Agile Projekte in Auftrag geben Agile Projekte in Auftrag geben Jens Coldewey (BDU) Coldewey Consulting Toni-Schmid-Str. 10 b D-81825 München Germany Tel: +49-700-COLDEWEY Tel: +49-700-26533939 Fax: +49-89-74995703 jens.coldewey@coldewey.com

Mehr

It s all about shipping software!

It s all about shipping software! 1 Shipping Software Raiffeisen Bausparkasse V-ARC, 21.12.2011 Gerhard H. Leonhartsberger It s all about shipping software! Seite 2 2 How fast do you ship quality software? Seite 3 Software Entwicklung

Mehr

2 Einführung in das V-Modell XT

2 Einführung in das V-Modell XT Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 2 Einführung in das V-Modell XT V-Modell XT Anwendung im Projekt

Mehr

Hilfe, mein SCRUM-Team ist nicht agil!

Hilfe, mein SCRUM-Team ist nicht agil! Hilfe, mein SCRUM-Team ist nicht agil! Einleitung: Laut unserer Erfahrung gibt es doch diverse unagile SCRUM-Teams in freier Wildbahn. Denn SCRUM ist zwar eine tolle Sache, macht aber nicht zwangsläufig

Mehr

WBS. Sprint. Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA

WBS. Sprint. Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA PM WBS Sprint Projektmanagement und Agile Methoden Widerspruch oder Ergänzung? Ing. Markus Huber, MBA Über den Vortragenden IT-Leiter der Austrian Gaming Industries (Novomatic Group of Companies) MBA in

Mehr

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services

Wir schützen Ihre Investitionen. Qualitätssicherung nach Maß. IT Quality Services Wir schützen Ihre Investitionen Qualitätssicherung nach Maß IT Quality Services Sicherheit, die senkt Mit den IT Quality Services schützen Sie Ihre Investitionen Ohne Qualitätssicherung Mit Qualitätssicherung

Mehr