Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Mit ganzheitlichen Verfahren Grenzen durchbrechen

Ähnliche Präsentationen


Präsentation zum Thema: "Mit ganzheitlichen Verfahren Grenzen durchbrechen"—  Präsentation transkript:

1 Mit ganzheitlichen Verfahren Grenzen durchbrechen

2 Willkommen! Arno Dämon IBM Deutschland Wilhelm-Fay-Straße 30-34
D Frankfurt-Sossenheim Phone: Ich möchte Sie ganz herzlich bei meinem Vortrag: „Mit ganzheitlichen Verfahren Grenzen durchbrechen“ begrüßen. Mein Name ist Arno Dämon. Ich bin seit über 10 Jahren als „Technical Sales Specialist“ bei der IBM Rational und vorher bei Telelogic beschäftigt. Durch den immer weiter steigenden Druck, aus wirtschaftlicher, zeitlicher und inhaltlicher Sicht, auf die Softwareprojekte haben Agile Methoden mehr und mehr an Bedeutung gewonnen. Leider sind sich viele Projektmanager nicht wirklich sicher ob die Entscheidung ihre Projekt mit agilen Methoden zu entwickeln richtig ist. Sicherheitshalber werden dann die bisher üblichen Methoden weiter verwendet. Ich glaube das agile Methoden durch ganzheitliche Betrachtung in vielen Projekten eingesetzt werden kann. Ich möchte Sie bitten die in diesem Vortrag gegebenen Anregungen aufzugreifen und in Ihren eigenen Projektkontext zu setzten. Sie werden sehen das agile Praktiken viel flexibler eingesetzt werden könne als das den Anschein hat. Am Ende des Vortrags wird ein wenig Zeit zur Verfügung stehen um Ihre Fragen zu beantworten.

3 Agil an jedes Ziel? „Die ganzheitliche Betrachtung der agilen Prozesse reduziert die Aufwände an den Nahtstellen und erhöht die Effizienz und Transparenz.“ Agil ist das Megaschlagwort der letzten Jahre im Softwaregeschäft. Wir haben alle gehört das es mit agilen Methoden möglich ist qualitativ gute Software in kürzerer Zeit an den Kunden zu liefern. Das agile Manifest legt es uns bei der Projektplanung nahe nach ausschließlich agilen Prinzipien zu arbeiten, doch in der Praxis bleiben Fragen offen: Wie können die Schnittstellen zu übergreifenden Funktionen aussehen? Wie geht man mit umfangreichen Projekten um. Usw usw. In diesem Vortag möchte ich das möglicherweise am weitesten verbreitete agile Verfahren SCRUM beispielhaft benutzen. Alle Aussagen können im Prinzip auf andere agilen Verfahren übertragen werden. Es geht also darum an ein paar exemplarischen Anwendungsfällen zu zeigen wie durch gekickte Projektplanung agile Methoden in mehr Projekten genutzt werden können als es oft den Anschein hat.

4 Definition der agilen Werte
Individuals Interactions Processes and Tools Working Software Comprehensive Documentation We value over Customer Collaboration Contract Negotiation Respond to Change Many people point to the values of the agile manifesto as a definition for agile development. The values are a great set of philosophies, but likely not a good definition. Value #1: Individuals and interactions over processes and tools.  Teams of people build software systems, and to do that they need to work together effectively – including but not limited to programmers, testers, project managers, modelers, and your customers.  Value #2: Working software over comprehensive documentation.  Documentation has its place, written properly it is a valuable guide for people’s understanding of how and why a system is built and how to work with the system.  However, never forget that the primary goal of software development is to create software, not documents – otherwise it would be called documentation development wouldn’t it? Value#3: Customer collaboration over contract negotiation.  Only your customer can tell you what they want.  Having a contract with your customers is important, having an understanding of everyone’s rights and responsibilities may form the foundation of that contract, but a contract isn’t a substitute for communication.  Value #4: Responding to change over following a plan.  Change is a reality of software development, a reality that your software process must reflect.  There is nothing wrong with having a project plan, in fact I would be worried about any project that didn’t have one.  However, a project plan must be malleable, there must be room to change it as your situation changes otherwise your plan quickly becomes irrelevant.  Following a Plan That is, while there is value in the items on the right, we value the items on the left more. (Source: 4 4

5 Level of Agility 100% Agil? Formal Pure Agile
Betrachten wir das „Agile Manifesto“ als die Definition für das 100%ige agile Entwickeln und das Wasserfallmodell als die Definition für das formale Entwickeln, so ist jedem hier im Raum klar das diese beiden Vorgehensmodelle nicht überall gleich effizient angewendet werden können. Vielmehr wird die beste Wertschöpfung dadurch erreicht das die wirklich zielführenden Praktiken identifiziert und implementiert werden. Die nächste Folie zeigt Ihnen wie groß das Interesse der Projekten an den agilen Methoden ist. The Nokia Test is in two parts. First, are you doing Iterative Development? Iterations must be timeboxed to less than 4 weeks Software features must be tested and working at the end of each iteration The Iteration must start before specification is complete The experience is that if you ask a lot of "Scrum" teams if they can pass this part of the test, they can't. If you are at a conference, often not a single team in the room. The next part of the test checks whether you are doing Scrum (in Nokia's opinion): •You know who the product owner is •There is a product backlog prioritized by business value •The product backlog has estimates created by the team •The team generates burndown charts and knows their velocity •There are no project managers (or anyone else) disrupting the work of the team Um von agilen Methoden zu profitieren müssen nicht alle Praktiken im Projekt in gleich hohem Maß implementiert sein. Pragmatismus sollte vor formalen Kriterien wie dem „Nokia-Test“ kommen.

6 Agile ist Mainstream… Marktanalysen haben ergeben dass sich ca. ¾ aller Projekte schon mit agilen Methoden beschäftigt haben. Die aktuellste Erhebung macht deutlich das lediglich 14% aller Projekte das agile Manifest 100% umgesetzt haben. 18% ... 41% … 27% … 14% … Neben dem klaren Interesse an Agilen Methoden ist hier dennoch zu erkenn des es eine gewisse Unsicherheit bei der Implementierung der Methoden gibt. 6

7 Die Nahtstellen Um den Sachverhalt ein wenig näher zu untersuchen möchte ich den „Scrum Construction Lifecycle“ als Beispiel benutzen wie bereits vorher erwähnt. Bereits an der Namensgebung kann man erkennen das es sich um einen „Lifecycle“ zur Konstruktion der Applikation handelt. Es geht also um das erstellen der angestrebten Lösung oder Produktes. This is the Scrum construction life cycle. There are a lot of good ideas here, but it’s not complete. Scrum practices: Product Backlog – Prioritized stack of requirements Value-Driven Life Cycle – Deliver potentially shippable software each sprint Self Organization – The people who do the work are the ones that plan and estimate it Release Planning – Develop and then maintain a high-level project plan Sprint Planning – At the beginning of a sprint the team plans in detail what they will deliver and how they will do the work Daily Scrum Meeting – Each day hold a 15 minute coordination meeting Sprint Demo – At the end of the sprint demo what you’ve built to key stakeholders Roles: Scrum Master Product Owner Team Member The Scrum community likes to claim that Scrum is a process framework, but this in only true in the consultware meaning of the word because as you see in the next slide Scrum leaves some gaping holes that customers need to fill in for themselves. See

8 Perfekt für die Implementierung
Die Nahtstellen Perfekt für die Implementierung Man kann als ganz einfach sagen: Agile Methoden sind für die Konstruktion von Produkten optimiert.

9 Bei vielen Projekten besteht jedoch Anpassungsbedarf
Die Nahtstellen Bei vielen Projekten besteht jedoch Anpassungsbedarf Bei vielen Projekten besteht allerdings Anpassungsbedarf. Die nächste Folie zeigt ein paar Beispiele dafür.

10 Anpassungsbedarf Was, wenn…
der Kunde eine vertraglich festgelegte funktionale Leistungsbeschreibung und eine Lieferfrist wünscht? ein Software-Produkt unternehmensweit ausgerollt und eingesetzt werden soll? der Kunde einen langatmigen Zulassungsprozess für das „fertige“ Produkt hat? es kritische Sicherheitsanforderungen gibt? der Kunde von Ihnen geographisch entfernt ist? der Kunde zu beschäftigt ist, um mit Ihnen häufigen Kontakt zu haben? der Kunde eine vertraglich festgelegte funktionale Leistungsbeschreibung und eine Lieferfrist wünscht? ein Software-Produkt unternehmensweit ausgerollt und eingesetzt werden soll? der Kunde einen langatmigen Zulassungsprozess für das „fertige“ Produkt hat? es kritische Sicherheitsanforderungen gibt? der Kunde von Ihnen geographisch entfernt ist? der Kunde zu beschäftigt ist, um mit Ihnen häufigen Kontakt zu haben?

11 Die Nahtstellen Hier die Offensichtlichten Nahtstellen
Anforderungsmanagement: Der Product Backlog wird bei Bedarf geändert. Das bedingt eine permanente Einbindung der Stakeholder. Ich habe schon in Projekten gearbeitet in denen der Auftraggeber noch nicht einmal gewillt war einen Änderungsantrag online einzustellen. Das wurde dann immer von Mitarbeitern erledigt! Testing: Entwickler wollen nicht gerne als Tester arbeiten. Wenn das Team nicht 100% TDD implementiert hat dann bleibt am Ende vom Sprint Testarbeit übrig. Ein kontinuierlicher Test könnte das verbessern. Noch problematischer ist die Einbindung der Stakeholder in den Test um das zeitnahe Feedback zu bekommen. Was passiert wenn das Team warten muß? Demo und Dokumentation: Wer führt bei umfangreicheren Produkten die Sprint Demo durch? Oft kann es einen erheblichen Aufwand bedeuten die Testumgebeung zu bestücken. Kann das Team das leisten? Wer betreut die Demo, wenn die Dokumentation noch nicht so weit fertig gestellt ist?

12 Requirements, Anforderungen, Backlogs Kontradiktional?
Requirements Engineering ist die Methode um Anforderungen aufzunehmen Anforderungen präzise und in sich schlüssig zuformulieren Kurz und prägnant zu dokumentieren Inhaltliche Konsistenz herbeizuführen Aufgaben des Product Owners Erfassung der Kundenbedürfnisse Beschreibung der Anforderungen Kommunikation mit Stakeholdern Projektmanagement Kommunikation mit dem Team

13 Requirements, Anforderungen, Backlogs Kontradiktional?
Die Aufgaben des Product-Owners und des Requirements Engineers sind sehr vergleichbar Eine formales Requirements Engineering kann problemlos der Implementierung mit agilen Methoden vorangestellt werden. Der Product Owner wird entlastet Die Qualität des Backlogs wird durch einen erfahrenen Requirments Engineer erhöht Formale Vorgeben der Kunden werden eher erfüllt Klassisches Requirements Engineering kann die Umsetzbarkeit von agilen Methoden wie Scrum erhöhen

14 Test Driven Development und Independent Testing
Die Effektivität des Teams verbessert sich wenn funktionierende Build regelmäßig einem investigativen Test unterzogen werden. z.B. Pre-production system integration testing Usability testing Security testing Non-functional testing When it comes to testing on agile projects it is common practice for agile teams to adopt a "whole team testing" approach where the team itself does its own testing.  To accomplish this agile teams will often embed testers in the development team.  Programmers will work closely with the testers, often via non-solo development strategies such as pair programming, to pick up their valuable testing skills.  The testers will in turn pick up new skills from the programmers, and in effect both groups will move away from being just specialists (testers or programmers) to being what's called generalizing specialists.  Whole team testing can be very different from traditional approaches where programmers may do some testing, often unit testing of their own code, and then throw it over the wall to testers and quality assurance (QA) professionals for verification and validation. My experience is that whole team testing is a very effective strategy, that agile testing and quality strategies in general appear to be far more effective than traditional testing and quality strategies, but that whole team testing isn't the full agile testing picture.  At scale, particularly in complex domains, complex technical situations, or in regulatory compliance situations, Disciplined Agile Delivery (DAD) teams will extend whole team testing with a parallel independent test team.  Although the development team still does the majority of the testing, the independent test team which is working in parallel to the development team looks for problems which are harder or more difficult for the development team to find and then reports potential defects back to the development team.  The types of testing that the parallel independent test team performs may include: Pre-production system integration testing.  Does the solution work within your overall organizational ecosystem?  Importantly, if this is one of several teams currently developing new solutions, does this team's solution work with what will be in production (including the work in progress of other teams) when they go to release?  In mid-to-large organizations the only economical way to do this sort of testing is via an independent, centralized team. Usability testing.  Although it's possible to do usability testing on the development team, the reality is that usability testing is a specialized skill that few people have (although could pick up via non-solo development).  Furthermore, particularly for solutions with many potential users, you may want to invest in a usability testing lab.  This is a centralized resource, or an outsourced resource these days, which is shared across many teams. Security testing.  Security testing is also a specialized skill, albeit one well supported with sophisticated security testing tools such as the Rational Appscan suite which can be included in your continuous integration (CI) strategy.  Many organizations will centralize their security testing efforts. Exploratory testing.  The fundamental goal of exploratory testing is to discover where the solution breaks, as opposed to confirmatory testing which focuses on showing that the solution conforms to the requirements (this is the type of testing the development team typically focuses on).  Exploratory testing is also a skill, a good one which everyone should strive to pick up, but exploratory testers are often few in number in many organizations.  So, to leverage their skills effectively you may want to have some of them on the independent test team while they mentor others while doing so. Non-functional testing. Non-functional requirements have a tendency to fall through the cracks on some development teams.  Knowing this the independent test team will often "test to the risk" and focus on non-functional issues. And much more.  The above points are just exemplars, not an exact list.  Please follow some of the links above for greater detail. I'd like to leave you with several important thoughts: The developers still do the majority of the testing.  Just because there's an independent test team it doesn't imply that they are the ones doing all the testing.  In fact, nothing could be further from the truth.  They should be doing the minority of the testing effort, albeit the more difficult forms of it. An independent test team will support multiple dev teams.  For example, a test team of 5-6 people could support several development teams totalling 70 to 80 people.  I typically look for a 15:1 or 20:1 ratio of developers to independent testers, hopefully even higher than that. You need to consider better tooling.  Although the development team will still be using common agile testing tools such as the xUnit and FIT frameworks the independent test team (ITT) will need more sophisticated tooling.  First, the ITT will need to be able to report defects back to the team easily.  When the development team is using a Jazz-based tool such as Rational Team Concert (RTC) then this can easily be done using either RTC (the web interface may be sufficient) or another Jazz-enabled product such as Rational Quality Manager (RQM).  Second, the ITT will likely need more sophisticated testing tools, such as Rational Appscan for static and dynamic security testing and Rational Performance Tester (RPT) for performance testing (just two of several software quality management tools you should consider). Independent testing is economical. Although I listed several tools in my previous point (hey, I do work for a vendor after all) an "unfortunate" implication of my advice (unfortunate for IBM at least) is that you can reduce the number of licenses that you require and still get this critical testing done by centralizing their use. It may be a bit more complicated in regulatory environments.  In a strict regulatory environment the independent test team may need to repeat, or at least validate, the testing efforts of the development team.  In regulatory environments my fundamental advice is always this -- Have practical people, including yourself, read and interpret the regulations.  If you leave it to the bureaucrats you'll get a bureaucratic solution. This is an important scaling technique.  Parallel independent testing, when done in an agile manner, is an important technique which you should consider when scaling agile strategies to meet the uniques needs of the situation that you find yourself in. 

15 Am Beispiel von Disciplined Agile Development
Erweiterter Ansatz Am Beispiel von Disciplined Agile Development

16 Erweiterter Ansatz

17 Erweiterter Ansatz

18 Erweiterter Ansatz

19 … aber Agilität muss oft auch skalieren können
Management der Anforderungen geringes Risiko Kritisch, auditfähig Agile Entwicklung Einige der Skalierungsfaktoren weisen in die Richtung der Projektorganisation und Projektkommunikation: Geografische Verteilung und outsourcing partnerships-> Skills werden genutzt wo vorhanden Team size -> Das benötigte Team ist einfach zu groß für ein Scrum-Team. Application Complexity ->Die Architektur kann nich mehr überblickt werden… …. Im Folgenden möchte ich auf ein paar Praktiken eingehen die Sie in die Lage versetzen effektiv mit diesen Skalierungsfaktoren sinnvoll umzugehen.

20 … aber Agilität muss oft auch skalieren können
Management der Anforderungen geringes Risiko Kritisch, auditfähig Geschäftspolitische Einflüsse Minimal Signifikant Agile Entwicklung Einige der Skalierungsfaktoren weisen in die Richtung der Projektorganisation und Projektkommunikation: Geografische Verteilung und outsourcing partnerships-> Skills werden genutzt wo vorhanden Team size -> Das benötigte Team ist einfach zu groß für ein Scrum-Team. Application Complexity ->Die Architektur kann nich mehr überblickt werden… …. Im Folgenden möchte ich auf ein paar Praktiken eingehen die Sie in die Lage versetzen effektiv mit diesen Skalierungsfaktoren sinnvoll umzugehen.

21 … aber Agilität muss oft auch skalieren können
Management der Anforderungen geringes Risiko Kritisch, auditfähig Geschäftspolitische Einflüsse Minimal Signifikant Agile Entwicklung Organisatorisches Umfeld (Outsourcing, Partner) Einige der Skalierungsfaktoren weisen in die Richtung der Projektorganisation und Projektkommunikation: Geografische Verteilung und outsourcing partnerships-> Skills werden genutzt wo vorhanden Team size -> Das benötigte Team ist einfach zu groß für ein Scrum-Team. Application Complexity ->Die Architektur kann nich mehr überblickt werden… …. Im Folgenden möchte ich auf ein paar Praktiken eingehen die Sie in die Lage versetzen effektiv mit diesen Skalierungsfaktoren sinnvoll umzugehen. In-house Third party

22 … aber Agilität muss oft auch skalieren können
Management der Anforderungen geringes Risiko Kritisch, auditfähig Geschäftspolitische Einflüsse Minimal Signifikant Agile Entwicklung Organisatorisches Umfeld (Outsourcing, Partner) Einige der Skalierungsfaktoren weisen in die Richtung der Projektorganisation und Projektkommunikation: Geografische Verteilung und outsourcing partnerships-> Skills werden genutzt wo vorhanden Team size -> Das benötigte Team ist einfach zu groß für ein Scrum-Team. Application Complexity ->Die Architektur kann nich mehr überblickt werden… …. Im Folgenden möchte ich auf ein paar Praktiken eingehen die Sie in die Lage versetzen effektiv mit diesen Skalierungsfaktoren sinnvoll umzugehen. In-house Third party Grad der Governance Informal Formal

23 … aber Agilität muss oft auch skalieren können
Management der Anforderungen geringes Risiko Kritisch, auditfähig Geschäftspolitische Einflüsse Minimal Signifikant Agile Entwicklung Organisatorisches Umfeld (Outsourcing, Partner) Einige der Skalierungsfaktoren weisen in die Richtung der Projektorganisation und Projektkommunikation: Geografische Verteilung und outsourcing partnerships-> Skills werden genutzt wo vorhanden Team size -> Das benötigte Team ist einfach zu groß für ein Scrum-Team. Application Complexity ->Die Architektur kann nich mehr überblickt werden… …. Im Folgenden möchte ich auf ein paar Praktiken eingehen die Sie in die Lage versetzen effektiv mit diesen Skalierungsfaktoren sinnvoll umzugehen. In-house Third party Teamgröße Grad der Governance unter 10 über 100 Informal Formal

24 … aber Agilität muss oft auch skalieren können
Management der Anforderungen geringes Risiko Kritisch, auditfähig Geschäftspolitische Einflüsse Minimal Signifikant Agile Entwicklung Organisatorisches Umfeld (Outsourcing, Partner) Anwendungskomplexität Einige der Skalierungsfaktoren weisen in die Richtung der Projektorganisation und Projektkommunikation: Geografische Verteilung und outsourcing partnerships-> Skills werden genutzt wo vorhanden Team size -> Das benötigte Team ist einfach zu groß für ein Scrum-Team. Application Complexity ->Die Architektur kann nich mehr überblickt werden… …. Im Folgenden möchte ich auf ein paar Praktiken eingehen die Sie in die Lage versetzen effektiv mit diesen Skalierungsfaktoren sinnvoll umzugehen. Einfach Homogen Komplex, Heterogen In-house Third party Teamgröße Grad der Governance unter 10 über 100 Informal Formal

25 … aber Agilität muss oft auch skalieren können
Management der Anforderungen geringes Risiko Kritisch, auditfähig Geografische Verteilung Geschäftspolitische Einflüsse Lokal Global Minimal Signifikant Agile Entwicklung Organisatorisches Umfeld (Outsourcing, Partner) Anwendungskomplexität Einige der Skalierungsfaktoren weisen in die Richtung der Projektorganisation und Projektkommunikation: Geografische Verteilung und outsourcing partnerships-> Skills werden genutzt wo vorhanden Team size -> Das benötigte Team ist einfach zu groß für ein Scrum-Team. Application Complexity ->Die Architektur kann nich mehr überblickt werden… …. Im Folgenden möchte ich auf ein paar Praktiken eingehen die Sie in die Lage versetzen effektiv mit diesen Skalierungsfaktoren sinnvoll umzugehen. Einfach Homogen Komplex, Heterogen In-house Third party Teamgröße Grad der Governance unter 10 über 100 Informal Formal

26 Inhärente Grenzen Agile Vorgehensmodelle gehen von Teams aus die aus maximal 10 Personen bestehen Team size: 1 - 4 5 - 10 11+ Average number of relationships: 3 26 55+ Estimated average management hours a: 15 48 68+ Productivity: OK Great Poor 4 people people people 6 relationships relationships relationships The project is staffed by a core dedicated team of 4 to 8 members to ensure simple manageability and close communication and collaboration, creating a Teaming environment. And initiative can be decomposed into these numbers, based on the attributes of that project. Reference: (see Stephen Robbins in Findings on High-Performance Teams and Katzenbach and Smith in Wisdom of Team – Creating the High Performance Organization) Agile principle # 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Keep teams between 5 – 10 people Less than 5 and team may not be able to perform all roles More than 10 and team will have too many communication channels and loose speed due to too much wasted interaction Example: Making decisions or schedule a meeting to discuss an issues becomes much more difficult as the number of team members increase a Based on PMI estimate of 10% - 25% of total hours

27 Agile Team Organisation
Generische Team Rollen: Team Lead Developers/Team Members Product Owner Stakeholders (nicht dargestellt) Unterstützende Rollen (Supporting cast): Technical Experts Mitarbeit bei Bedarf Domain Experts Requirements Breakdown und Project-Vision Independent Tester Main Team Roles: Team Coach. Responsible for facilitating the team, obtaining resources, and clearing roadblocks. Also called Project Lead, Team Lead, or Scrum Master. Developer. Responsible for creating and delivering the system, which includes modeling, programming, testing, and release activities. Stakeholder (not shown). Anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the "gold owner" who funds the project, support staff member, auditors, your program or portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals who may be affected by the development or deployment of a software project. Product Owner. Represents the stakeholders. Responsible for the prioritized work item list (called a product backlog in Scrum), for making decisions in a timely manner, and for providing information in a timely manner.

28 Grosse Teams können mit mehr Rollen effektiver sein.
Architecture Owner Erleichtert technische Entscheidungen und koordiniert technische Diskussionen im Team Domain Expert Hat Wissen über eine oder mehrere Aspekte des Problemgebietes einzeln aufgeführt Technical Expert Hat technisches Detailwissen, wird punktuell hinzugezogen Independent Tester Bearbeite komplexe Tests und arbeitet parallel und unabhängig vom Team Integrator Ist für den Build des Gesamtsystems zuständig Specialist Zum Beispie: lBusiness Analysten, Security Experten, Usability Professionals Organize the team/work around the architecture, not job roles: Most communication occurs between people working on subsystems or features. Organizing around job functions increases risk, cost, and time to value Other important strategies for organizing large teams: Organize requirements around architecture (and vice versa) Domain-driven architecture Coordinate project management, requirements management, and technical issues Re-introduce specialist roles as needed Maximize the responsibilities of the offshore team (if applicable) Provide guidance on enterprise infrastructure, development conventions

29 Welche Aufteilung der Backlogs macht Sinn?
Using a single Backlog for multiple Teams Team 1 Story 1 Story 2 Product Backlog Story 1 Story 2 Team 2 Story 3 Story 3 Story 4 Story 4 Story 5 Story 6 Story 7 Team 3 Story 5 Story 6

30 Welche Aufteilung der Backlogs macht Sinn?
Team 1 Story 1 Using a multiple Backlog for multiple Teams Story 2 Story ..n Product Backlog Story 1 Team 2 Story 2 Story 1 Story 3 Story 2 Story 4 Story ..n Story 5 Story 6 Story 7 Team 3 Story 1 Story 2 Story ..n

31 Welche Aufteilung der Backlogs macht Sinn?
Using a single Backlog for multiple Teams by features Product Backlog Team 1 Feature 1 Story F1-1 Story F1-1 Team 2 Story F2-1 Story F2-1 Feature 2 Story F2-2 Story F2-2 Team 3 Feature 3 Story F3-1 Story F3-1 Story F3-2 Story F3-2 Story F3-1 Story F3-1

32 Wie soll das ganze effizient und agil koordiniert werden ?

33 Requirements Discipline Testing Discipline Development Discipline
Collection Requirement Use Cases Sketches Bus. Goals Requirements Discipline Release Plan (Backlog) Testplan Iteration Plan (Sprint) Test Milestone Story Test Case Task Test Script Build Test Execution Record Defect Testing Discipline Development Discipline

34 Requirements Discipline Development Discipline Testing Discipline
Rational Requirements Composer Collection Requirement Use Cases Sketches Bus. Goals Rational Team Concert Rational Quality Manager Release Plan (Backlog) Testplan Requirements Discipline Iteration Plan (Sprint) Test Milestone Story Test Case Task Test Script Build Test Execution Record Defect Development Discipline Testing Discipline

35 Zusammenfassung Organizational Drivers Agile @Scale DAD
Technical and Regulatory Drivers Compliance Governance Application complexity Organizational Drivers Team Size Geographical Distribution Organization Distribution Entrenched process, people, policy Mature or existing projects Many developers Complex, multi-platform applications Distributed teams Need for scalability, reproducibility, and traceability DAD Maturing projects Multi-platform Growing in complexity Remote or offshore work Greater need for coordination and handoffs XP, Scrum As the development environment increases in complexity, the need for processes and enablement technology changes. We’ve mapped the challenges of Agile in the Mainstream into two broad categories – those that pertain to Organizational issues, and those that relate to technical and regulatory factors. The higher and further to the right you go, on this continuum, the greater the overall picture of project complexity. At the bottom left is the simple “Agile” scenario where Agile really started – that is, co-located teams with maybe half a dozen developers building applications of limited complexity and minimal risk In the middle, we find teams that needs to deal with additional complexity, often a combination of several of the complexity drivers, such as: Larger team sizes driving the need for more coordination and handoffs Distributed teams driving the need for more coordination and handoffs (e.g. through documentation or automated notifications) Multi-platform support, often requiring more extensive and rigorous test environments Complex or more mission-critical applications requiring more attention to analysis, architecture and testing In complex situations (top right) we find teams that face many of the complexity drivers, and often to a larger degree, including: Very large team sizes, forcing additional attention to coordination and handoffs. At this level, there is an increasing need to incorporate best practices to avoid teams reinventing the wheel with similar processes. Distributed and multi-cultural development, requiring attention to cultural issues as well as coordination and handoffs Compliance issues and the need to effectively managing audits which requires the regular collection of development information from multiple data sources. Very complex and typically safety-critical or mission-critical systems, frequently requiring complex test environments, dedicated test teams, and careful attention to analysis and architecture issues, such as recovery, fault tolerance, or systems requiring extensive load and capacity planning. The top two categories signify that you’re dealing with “Agility at Scale”, meaning that classic Agile strategies will need to be evaluated, tailored, and perhaps combined with some amount of traditional approaches to suit the unique needs of the team or project. Small team New projects Simple application Co-located Minimal need for documentation

36 Sehr viele mehr Projekte von den agilen Methoden profitiere können.
Fazit Agile Methoden wie Scrum haben ihre Grenzen, aber diese lassen sich beherrschen. Dennoch lohnt sich immer eine Analyse über mögliche Einsatzgebiete, denn die Erfahrung zeigt das: Durch eine geschickte Auswahl der Praktiken Zielgerichteter Einsatz unterstützender Lösungen Frühzeitige Prozessanalysen und Methodenplanung Sehr viele mehr Projekte von den agilen Methoden profitiere können. In agilen Projekten sind daher neben den fachlichen Qualifikationen, insbesondere die Soft-Skills von großer Bedeutung. Wer agil arbeiten will muss: Aktiv sein Teamfähigkeit beweisen Kommunikation beherrschen Selbstkritisch sein können Mutig sein

37 IBM Agile Resources Besuchen Sie unseren Stand (6.3)
um sich vom Portfolio an Lösungen für die Entwicklung von Software und Systemen selbst zu überzeugen.

38 Thank you! © Copyright IBM Corporation 2011. All rights reserved.
The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.


Herunterladen ppt "Mit ganzheitlichen Verfahren Grenzen durchbrechen"

Ähnliche Präsentationen


Google-Anzeigen