Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

AgilePM® (PL) - Zwinne zarządzanie projektami by Mind Map: AgilePM® (PL) - Zwinne
zarządzanie projektami
5.0 stars - 29 reviews range from 0 to 5

AgilePM® (PL) - Zwinne zarządzanie projektami

DSDM®, Atern®, AgilePM® are registered trade marks of Dynamic Systems Development Method Limited in the United Kingdom and other countries. AgilePgM™ is a trade mark of Dynamic Systems Development Method Limited in the United Kingdom and other countries. Trademarks are properties of the holders, who are not affiliated with mind map author.

AgilePM® - iteracyjno-przyrosoto-adaptacyjna (ang. change-driven / empirical) metoda zwinnego zarządzania projektami oraz framework (nie tylko sam framework jak Scrum) z Wielkiej Brytanii stosowany do niezależnego od branży (nie związanym z konkretną branżą typu IT, Inżynieria czy Budownictwo) zwinnego zarządzania projektami. Metoda AgilePM® jest postrzegana jak hybrydowa metoda, która łączy w sobie zarządzanie projektem z wytwarzaniem produktów w ramach jednej metody. AgilePM® powstała jako pochodna z innej metody o nazwie DSDM® z jej wersji v5 zwanej jako DSDM® Atern® w 2010 roku. Podobnie jak DSDM®, AgilePM® została opracowana przez konsorcium DSDM® Consortium - www.dsdm.org

Current DSDM family

Pierwsza wersja AgilePM® (v1.0) została opublikowana 07.2010.

Wersja v1.1 zawierająca drobne poprawki została opublikowana 09.2012

Wersja v1.2 zawierająca drobne poprawki została opublikowana 12.2013

Wersja v2.0 została opublikowana 09.2014

AgilePM® Fazy cyklu życia projektu (7) (a.k.a. 'building blocks')

aka. “cheese and pizzas” diagram

Overview

W zgodnie z pryncypiami 5 i 6 cykla życvia projektu AgilePM® jest zarówno iteracyjny i przyrostowy., AgilePM® provides an iterative and incremental framework, with seven lifecycle phases., Each phase has objectives and pre-conditions., This configurability of AgilePM® Lifecycle allows the project manager significant opportunity to deliver business value early and to demonstrate progress. The framework is highly configurable, depending on the size and formality of the project being delivered., It is sequential for Pre-project, Feasibility and Foundations,, Can have many iterations of Exploration and Engineering., Can have many separate Deployments!, Post Project will be sequential with the last Deployment., Solution may not be delivered to the business in one go, but in a series of increments that increase the breadth and/or depth of the solution with each delivery., Urgent business needs can be addressed early while less important features are delivered later., Iterative nature of AgilePM® enables business representatives to see work under construction, comment on it and request changes during the development of an increment of the solution., Each lifecycle phase will deliver Products and, within AgilePM®, delivery of Products (to the appropriate and agreed level of quality) is used to assess progress., It is important to keep the phases of the lifecycle visible to the SDT during the project., Typically, plan for Feasibility and Foundations phases to be shorter than would be the case for a traditional one-delivery project. Allow for just enough design up front (EDUF), Project phases are 'building blocks' from which you are building project lifecycle., see example project lifecycles

AgilePM® provides an iterative, incremental and adaptive framework, with 7 lifecycle phases.

AgilePM® Project Lifecycle Phases with requirements

1. Faza Przedprojektowa

Wprowadzenie, In most organisations projects exist as part of a portfolio of other projects and sometimes exist as part of a programme of projects with a shared business change objective. Regardless, projects need to be set up correctly from the outset to ensure success., The work of the pre-project phase simply formalises a proposal for a project and places it in the context of other potential work to be, or already being, carried out by the organisation.

Cele, To describe the business problem to be addressed., To identify a Business Sponsor and Business Visionary., To confirm that the project is in line with business strategy., To scope, plan and resource the Feasibility phase.

Consider, The intended work of the Pre-project phase should be short, sharp and ideally restricted to the creation of a short statement that has the purpose of justifying and prioritising a Feasibility investigation.

2. Faza Oceny Wykonalności (ang. Feasibility Assessment)

Wprowadzenie, Project management best practice dictates that the viability of the project should be continually assessed throughout the project, ensuring that the benefits predicted from the use of end products of the project outweigh the costs of delivering them., The Feasibility phase provides the first opportunity for deciding whether a proposed project is viable from both a business and a technical perspective by means of a high level investigation of the potential solutions, costs and timeframes.

Cele, To establish whether there is a feasible solution to the business problem described in the Terms of reference defined during Pre-Project., To identify the benefits likely to arise from the delivery of the proposed solution., To outline possible approaches for delivery, including strategies for sourcing the solution and project management., To describe the organisation and governance aspects of the project., To state first-cut estimate of timescale and costs for the project overall., To plan and resource the Foundation phase.

Warunki wstępne, The Terms of Reference for the project have been approved., the required resources are available to carry out the feasibility investigation., the Business Visionary has sufficient time available to help shape the project.

Uwagi, If you are going to stop work on a project then it is important that you stop as early as possible., The Feasibility phase should be kept as short and sharp as possible, remembering that its only purpose is to justify progressing to the Foundations phase. The detail of the investigation happens in the Foundations phase.

3. Faza Określenia Podstaw (ang. Foundations phase)

Wprowadzenie, The Foundations phase is aimed at establishing firm and enduring foundations for the project. In establishing the foundations, the three essential perspectives of business, solution and management need to be combined to provide a clear project focus that is both robust and flexible. To create solid foundations, it is vital that detail, particularly around the solution, is strictly limited so that it does not unnecessarily constrain the way the solution evolves but still clearly demonstrates how it will meet the needs of the business.

Cele, To baseline the high-level requirements for the project and describe their priority and relevance to the business need, To describe the business processes to be supported by the proposed solution, To identify information used, created and updated by the proposed solution, To describe the strategies for all aspects of solution deployment, To detail the Business Case for the project, To start designing the solution architecture and identifying the physical or infrastructural elements of solution, To define technical implementation standards, To decribe how quality will be assured, To establish appropriate governance and organisation for the project, To describe the solution development lifecycle for the project along with techniques to be applied in managing the project and for demonstrating and communicating progress, To baseline a schedule for development and deployment activities for the solution, To describe, assess and manage risk associated with the project

Warunki wstępne, agreement of the Feasibility Assessment (if created)

Uwagi, Significant business input will be required during the Foundations phase. The relevant business representatives must be identified early and their level of involvement agreed. Set a time limit for the Foundations phase and try to stick to it. The aim of this phase is to create a high-level but sound view of the business and technical aspects of the project. Only produce the Foundation products to the level that allows the project to move into the first exploratory development phase.

4. Faza Eksploracji (ang. Exploration phase)

Wprowadzenie, The Exploration phase is used to iteratively and incrementally investigate detailed business requirements and translate them into a viable solution., The preliminary solution created during Exploration is not expected to be production-ready but is focused on demonstrating that it will deliver what is needed, whilst fitting precisely with the ever-changing detail of overall need., The end-product of Exploration will be refined further during the Engineering phase to ensure technical acceptance criteria such as performance, capacity, security, supportability and maintainability are met.

Cele, To elaborate on the requirements captured and baselined in the Prioritised Requirements List during Foundations, To explore the full detail of the business need and provide detailed requirements for the evolving solution, To create a functional solution that demonstrably meets the needs of the business, To give the wider organisation an early view of the solution that they will eventually operate, support and maintain, Where needed, to evolve the Business Area Definition and System Architecture Definition products of the Foundations phase into models that describe how the solution works and how it supports all impacted business processes and systems

Warunki wstępne (dla wyjścia z fazy Określania Podstaw), The Business, Solution and Management Foundations products have ben collectively accepted as provide an adequate foundation from which a solution can evolve, The environments (physical and, where appropriate, technical) are in plase and adequately set up to support the development of solution, All required project personnel and stakeholders are engaged as necessary

Uwagi, There are many paths through the iterative phases of Exploration, Engineering and Deployment. The three basic patterns to be considered in determining the most appropriate development approach are in the chapter on Configuring the Lifecycle for Evolution.

5. Faza Inżynierii (ang. Engineering phase)

Wprowadzenie, The Engineering phase is used iteratively and incrementally to evolve the preliminary solution created during Exploration to achieve full operational readiness., Development effort here is focused primarily on addressing non-functional requirements (such as performance, capacity, security, supportability and maintainability)., Continued involvement from the Business representatives during this phase provides an ongoing opportunity to validate fitness for business purpose from a functional perspective.

Cele, To refine the Evolving Solution from the Exploration phase to meet the agreed acceptace criteria, To expand and refine any products required to successfully operate and support the solution in live operation

Warunki wstępne, The Evolving Solution from the Exploration phase has been approved., Business Visionary has acknowledged that the features demonstrated in the Evolving Solution are in line with the vision for the final business solution., The environments (physical and, where appropriate, technical) are in plase and adequately set up to support the development of solution, All required project personnel and stakeholders are engaged as required

Uwagi, There are many paths through the iterative phases of Exploration, Engineering and Deployment. The three basic patterns to be considered in determining the most appropriate development approach are in the chapter on Configuring the Lifecycle for Evolution.

6. Faza Wdrożenia (ang. Deployment phase)

Wprowadzenie, The primary purpose of the Deployment phase is to get the solution into live use. Where the end-products of the project are to be sold or distributed outside of the organisation creating it, the Deployment phase is used to get the products ready to ship., A secondary purpose is to act as a key review point prior to Deployment or future development work., The number of passes through the Deployment phase will depend on whether it is sensible and feasible for the business to accept delivery of the overall solution incrementally.

Cele, To confirm the ongoing performence and viability of the project and re-plan as required, To deploy the solution (or increment of it) into the live business environment, Where applicable, to train the end users of the solution and/or provide necessary documentation to support the live operation of the solution in the business environment, To train and/or provide documentation for operations and support staff who will responsible for supporting and maintaining technical aspects of the solution, To assess whether the deployed solution is likely to enable the delivery of intended elements of business benefit described in the Business Case (where created), After the final deployment:, To formally bring the project to a close., To review overall project performance from a technical and/or process perspective., To review overall project performance from a business perspective.

Warunki wstępne, The Deployable Solution has been approved for deployment

Uwagi, If the solution is being deployed incrementally, it is usually appropriate to formally assess whether the project should continue after each interim deployment., The Pareto Principle (or 80:20 rule) implies that it is possible that the vast majority of the benefit might be enabled by an early interim delivery., It therefore makes sense to check that investment in the rest of the planned project will provide a reasonable return., Justification to continue is likely to reflect the cost of operating the solution as it stands against the cost of operating a more complete solution.

7. Faza Poprojektowa (ang. Post Project phase)

Wprowadzenie, The Post-Project phase takes place after the last planned deployment of the solution. Its purpose is to reflect on the performance of the project in terms of the business value actually achieved., Assessment should start as soon as the value can be measured., Depends on the project but, normally three to six months after the completion of the project.

Cele, To assess whether the benefits described in the Business Case (where created) have actually been achieved through use of the Deployed Solution, Mostly, the project will have been closed prior to the start of the Post-Project phase., In some projects where the overall solution is delivered incrementally, it is often appropriate to start the benefits realisation process before the final deployment., Under such circumstances it may be appropriate to feed any proposals for change or enhancement back into the ongoing project., The BS and BV have an ongoing responsibility for ensuring that the benefits enabled by the project are actually realised through proper use of the solution provided.

Warunki wstępne, The solution has been successfully deployed.

Uwagi

AgilePM® Pryncypia (8)

Principles are universally applicable statements.

They provide guidance to organizations.

The 8 principles of AgilePM® direct the team (not mandates) in the attitude and culture they must take and the mindset they must adopt in order to deliver consistently.

A way of thinking and working.

Jeśli zespół projektowy nie przestrzega wszystkich zasad, to nie uzyska pełnych korzyści AgilePM®.

Nieprzestrzeganie prycypiów należy traktować jako ryzko / zagrożenie dla projektu.

Ponieważ łamanie którejkolwiek z pryncypiów złamie ideę AgilePM® i powstanie znaczne ryzyko wpływające na powodzenie projektu.

The 10 Golden Rules for Successful Agile Projects (by Keith Richards)

https://www.youtube.com/watch?v=P84PqqJV7Es

No. 1: Define the project objective in less than 10 words, You must start with the end in mind, You need to know exactly where you are going, The business case is your best friend, This will take you a long time to do, It will help you to kill a project going nowhere, The scope of the project will map on to this., TIP, Can you write the project objective on a Post-it note with a flip chart marker?

No. 2: Build a team with those who say ‘can’, A lot of being agile is about options, If you get the right people you are half way there, Choose the right person above the right skill set, “If you think you can’t, you’re right” – Carol Bartz, You need collaboration and team spirit., TIP, Ask a team member this question: Can I ask a favour?

No. 3: Go slow early to go fast later, This is counter intuitive, How much ‘DUF’ is enough? Answer EDUF!, Build from firm foundations, You must avoid analysis paralysis, Try and spot early solutioneering., TIP, Ask yourself: Is it safe to move on?

No. 4: Look backwards to go forwards, Learn your lessons – both good and bad, Evolve the process – it has to evolve, If it doesn’t work – do something else!, Try this! - Review, Plan, Do, Share your experiences with other teams., TIP, Ask yourself: How many of your projects have ended with a project review?, The answer should be ‘all of them’!

No. 5: Change is great!, You need to anticipate change and embrace it, This allows a more accurate solution to result, Do not confuse the breadth of the scope with the depth, Evolve and converge on the solution with the right kind of change., TIP, How do you feel when a customer says “I’ve changed my mind”?

No. 6: To be understood, seek first to understand., Command and control may not work with Agile, Facilitation is a core competency, Big ears, big eyes, small mouth, You have to play with the cards you are dealt, This will give you ownership., TIP, Try the 10 second silence when getting a progress update - nothing else can compete with it!

No. 7: Collect Actuals – this is the oxygen for your project, ‘You cannot control what you cannot measure’ – Tom de Marco, Meten is weten – to measure is to know, Start now – build a metrics database, Keep it simple to start with, Calibrate your estimates., TIP, Do you know (to the nearest day) how much time was spent on testing during your last project?

No. 8: Use fat communication channels, Shift the communication traffic to bigger pipes, The written word is a silent killer, Go visual, Use workshops., “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer), TIP, Try turning a document over and take a look at what is on the back

No. 9: Work hard at controlling what you can’t control, Continuously manage external risks, You may get your team right but what about 3rd parties?, Are they playing by the same rules as you?, Get the team involved, Be ‘a bit of a worrier’., TIP, Actively manage your risk log – it is not a storage area

No. 10: One more day? NO! We’ll catch up? NO!, Time focus is your greatest weapon, Force the issue – understand your condition, Timeboxes not milestones, If you are going to fail – fail early, Prioritise with MoSCoW – it should be natural., TIP, Set a deadline and hit it - never extend it, not even once!

1. Koncentruj się na potrzebie biznesowej (ang. Focus on the business need)

Gwarantowany Minimalny Użyteczny Podzbiór

Ustanownie Uzasadnienia Biznesowego

Poszukiwanie ciągłego zaangażowania i biznesu i finanoswania projektu

Zrozumieć priorytety biznesowe

Każda decyzja podjęta w trakcie realizacji projektu musi być rozpatrywana w świetle nadrzędnego celu projektu.

Projekt jest środkiem do celu, a nie celem sam w sobie.

Dostarczanie tego, co wymaga organizacja oraz w terminie jaki wymaga organizacja. Priorytety biznesowe muszą być rozumiane i określone w ustalonym Uzasadnieniu Biznesowym.

2. Dostarczaj na czas (ang. Deliver on time)

Zawsze na czas

Skupić się na priorytetach biznesowych

Dziel pracę na łatwo zarządzalne cześci

Okienka czasu są planowane z wyprzedzeniem oraz zakres czasowy Okienek Czasu jest ustalony. Daty nie podlegają zmianom, natomiast dostarczone cechy / funkcjonalności tak - są zależne od priorytetów biznesowych tak, aby zmieścić się w ustalonych terminach.

3. Współpracuj (ang. Collaborate)

Encourages increased understanding, greater speed & shared ownership

Involve right stakeholders at the right time

Ensure team members are empowered to make decisions

Actively involve business

Build a one team culture

Atern Business Visionary, Business Ambassador and Business Advisor roles bring appropriate subject matter experts into project to contribute to solution

Business analyst is responsible for facilitating high level collaboration between team members

Facilitated workshops enable stakeholders to share knowledge with the project team

Involve the right stakeholders, at the right time, throughout the project.

Ensure that the members of the team are empowered to take decisions on behalf of those they represent.

The risk of building the wrong solution is greatly reduced.

The final solution is more likely to meet the users' real business requirements.

Deployment is more likely to go smoothly, because of the co-operation of all parties concerned throughout development.

Teams work in a spirit of active co-operation and commitment. Collaboration encourages understanding, speed and shared ownership. The teams must be empowered and include the business representatives.

People want to be part of something.

4. Nigdy nie idź na kompromis w kwestii jakości (ang. Never compromise quality)

Level of quality is agreed at the start.

A solution has to be “good enough”.

Projects must test early and continuously and review constantly.

Fail fast.

If the business agrees features in Minimum Usable Subset have been provided, then the solution should be acceptable, Ensure quality does not become a variable, Design, document and test appropriately, Build in quality by constant reviews, Test early & continuously, MoSCoW & timeboxing ensure testing is appropriate, without introducing unnecessary risks

5. Buduj przyrostowo na solidnych podstawach (ang. Build incrementally from firm foundation)

EDUF (Enough design Up Front)

Incremental delivery

Increments deployed into operational use for early ROI

Strive for early delivery of business benefit where possible.

Continually confirm the correct solution is being built.

Formally re-assess priorities and ongoing project viability with each delivered increment.

Implement this principle using Atern lifecycle

Increments allow the business to take advantage of work before the final product is complete, encouraging stakeholder confidence and feedback. This is based on doing just enough upfront analysis to proceed and accepting that detail emerges later.

6. Wytwarzaj Iteracyjnie (ang. Develop iteratively)

Do enough design up front (EDUF) to create strong foundations.

Accept that work is not always right first time. Use Timeboxes to allow for change yet continuously confirm that the solution is the right one.

Iterative approach on all projects

Build customer feedback into each iteration.

Accept most detail emerges later rather than sooner., Often end user does now what then need and think they know what they want!

Embrace change, the right solution will not emerge without it.

Be creative, experiment, innovate, test, learn, evolve.

Previous steps can be revisited as part of its iterative approach.

7. Komunikuj się ciągle i jasno (ang. Communicate continuously and clearly)

Run daily stand-ups, Same like Daily Scrum Meetings in Scrum framework. Agile daily team stand-up session are exactly the same.

Use facilitated workshops, daily stand-ups, modeling, prototyping, presentations and encourage informal face-to-face communication.

Use rich communication techniques such as modelling, prototyping, wireframing.

Present instances of the evolving solution early and often.

Keep documentation lean and timely.

Manage stakeholder expectations throughout the project.

Conversation, Collaboration, Community.

Encourage informal face to face communication at all levels

8. Demonstruj kontrolę (ang. Demonstrate control)

The team needs to be proactive when monitoring and controlling progress in line with Foundations Phase. They need to constantly evaluate the project viability based on the business objectives.

Use an appropriate level of formality for tracking and reporting.

Make plans and progress visible to all., Even to low level team members.

Measure progress through focus on delivery of products rather than completed activities.

Manage pro-actively

Evaluate continuing project viability based on the business objectives.

AgilePM® Filozofia (1)

The AgilePM® Philosophy is that any project must be adopted and adapted or simply aligned to clearly defined strategic goals

6P Model

Philosophy

Prionciples

Process

People

Products

Practices

Best achieved when key stakeholders understand the business objectives, are empowered to an appropriate level and collaborate in order to deliver the right solution

Philosophy is achieved when all stakeholders

Understands and buy into the business vision and objectives

Are empowered to make decisions within their area of expertise

Collaborate to deliver a fit for purpose business solution

Collaborate to deliver to agreed timescales in accorddance with business priorities

Accept that change is inevitable as the understanding of the solution grows over time

The 8 principles are themself supported by people, Agile process, clearly defined products and recommended practices

The AgilePM® philosophy is supported by a set of 8 principles that build the mindset and behaviours necessary to bring the philosophy alive

Project Approach Questionnaire (PAQ)

AgilePM® provides a simple questionnaire - the Project Approach Questionnaire (PAQ), PAQ helps to identify and confirm the level of achievement of all the above factors and to assess potential risk areas to be addressed

PAQ is completed during Feasibility phase and re-assessed as part of Foundations phase

PAQ is original document form DSDM® method

PAQ is based on Instrumental Critical Success Factors (ICSFs), AgilePM® Principles and other situational factors

Pobierz: AgilePM® Project Approach Questionnaire (PAQ) (XLS)

AgilePM® Role i odpowiedzialności (13)

Wprowadzenie

Project-level roles are the directors, managers and co-ordinators of the project work. They will either be on or directly report to any project board or steering committee.

The Business Visionary and the Technical Co-ordinator hold the customer and supplier visions of solution excellence.

The Project Manager ensures that the funding supplied is used effectively to create the envisaged solution.

Make a clear link between life cycle phases and the AgilePM® products

The Development roles are, Team Leader, Business Ambassador, Business Analyst, Solution Developer and Solution Tester., Jointly these roles form the engine room of the project.

The Development roles shape and build the solution, are collectively responsible for its day-to-day development and for assuring its fitness for business purpose.

There may be one or more SDT: the membership of each team should be stable and cover all the responsibilities defined for the Development roles.

The other roles (Business Advisors, Workshop Facilitator and DSDM / Atern Coach) provide assistance and guidance to the project on a more ad hoc basis throughout the lifecycle.

The project may also bring in subject matter experts as necessary for their specialist expertise., Called in AgilePM® - Specialist roles.

Role projektowe

Koordynator Techniczny (KT) (ang. Technical Coordinator), Techniczna władza projektowa w projekcie, Techniczna władza projektowania architektury, Ensures technical consistency and coherence across SDTs, Ensures adherence to agreed standards, The “glue” that holds the project together for technology and innovation, Equivalent to the Business Visionary, ensuring the solution is technically sound and cohesive, Odpowiedzialności, Agreeing and controlling the technical architecture, Determining the technical environments, Advising on and co-ordinating each team's technical activities, Identifying and owning architectural and other technically based risk, escalating to the Project Manager as appropriate, Ensuring the non-functional requirements (NFRs) are achievable and subsequently met, Ensuring adherence to appropriate standards or best practice, Controlling the technical configuration of the solution, Managing technical aspects of the transition of the solution into live use, Resolving technical differences between technical team members

Kierownik Projektu (KP) (ang. Project Manager), Koncentracja na dostarczaniu, Zapewnia wysoko poziomowe ukierunkowanie dla ZRR, Dla wielu zespołów ZRR naraz, jeśli zespół projektowy jest podzielony na kilka zespołów ZRR, Dobre umiejętności komunikacyjne, planowania, zarządzania i umiejętności koordynacji prac dla kilku zespołów, Kierownik Projektu to rola - niekoniecznie osoboa posiadającą tę rola musi być zatrudniowa w organizacji jako Kierownik Projektów, W małych projektach AgilePM® rolę Kierownika Projektu może pełnić Lider Zespołu, Zwykle jest tylko jeden Kierownik Projektu lub co najmniej jedna osoba jest ostatecznie odpowiedzialna za dostarczenie projektu, Co oznacza, że ta rola może być łączona (np. Kierownik Projektu od strony dostawcy i od strony klienta), Odpowiedzialności, Communicating with senior management and the project governance authorities (Business Sponsor, project board, steering committee, etc.) with the frequency and formality that they deem necessary, Wysoko poziomowe planowania projektu i harmonogramowanie, ale nie szczegółowe planowanie zadań, Monitorowanie postępów w realizacji zatwierdzonych planów projektu, Zarządzanie ryzykiem i zagadnieniami projektowymi, eskalacja do starszych ról biznesowych lub technicznych w razie potrzeby, Zarządzanie ogólną konfigurację projektu, Projektową NIE techniczną, Motywowania Zespołów Rozwoju Rozwiązania (ZRR) do realizacji ich celów, Może to być nietypowe, że motywowanie jest elementem pracy Kierownika Projektu a nie tylko przez Lidera Zespołu, ale pamiętaj o pryncypoum - "Współpracuj" - jedna kultura zespołu, poza zakresem egzaminów AgilePM®, Douglas McGregor (1960) Motivation Theory X, Motivation Theory Y, David McMlelland (1961) Motivational needs theory, Frederick Herzberg (1968) Motivating Factors, Zarządzanie zaangażowanie biznesu w ramach Zespołów Rozwoju Rozwiązania (ZRR), Pozyskiwania ról Specialistów w ramach potrzeby, Jednak Sponsor Biznesowy musi wyrazić zgodę, Obsługa problemów eskalowanych od Zespołów Rozwoju Rozwiązania (ZRR), Coaching Zespołów Rozwoju Rozwiązania (ZRR) w trundych sytuacjach, Może to być nietypowe, że coaching jest elementem pracy Kierownika Projektu a nie tylko przez Lidera Zespołu, ale pamiętaj o pryncypoum - "Współpracuj" - jedna kultura zespołu

Wizjoner Biznesu (WB) (ang. Business Visionary), Starsza rola biznesowa na poziomie projektu, Dostarsza szerokiego, całościowego spojrzenia na projekt z perspektywy biznesowej, Zaangażowany w większym stopniu w projekt niż Sponsor Biznesowy, Odpowiedzialny za interpretowanie potrzeb Sponsora Biznesowego, komunikowanie ich zespołom oraz w razie potrzeby zapewnienie, że są one prawidłowo reprezentowane w Uzasadnieniu Biznesowym, Jeśli projekt jest częścią większego programu, Wizjoner jest w stanie ocenić problemy projektowe w świetle programu i potencjalnych skutków poza projektem, Pozostaje zaangażowany w projekt przez cały okres trwania projektu, Oferuje zespołom strategiczne ukierunkowanie, Zapewnienie, że dostarczane rozwiązanie pozwoli uzyskać korzyści opisane w Uzasadnieniu Biznesowym, Odpowiedzialności, Definiuje wizję biznesową dla projektu, Komunikowanie i promowanie wizji biznesowej dla wszystkich zainteresowanych stron, Monitorowanie postępów w realizacji projektu, zgodnie z wizją firmy, Jest odpowiedzialny za szersze implikacje jakichkolwiek zmian biznesowych z organizacyjnego punktu widzenia, Przyczynianie się do określania kluczowych wymagań, projektowania i sesji przeglądów (w ramach Okinek Czasu), szczególnie tam, gdzie aspekty rozwiązania adresują kluczowe elementy wizji biznesowej, Zatwierdzanie zmian w wymaganiach wysoko poziomowych w Liście Wymagań Urzegregowanej Według Priorytetów (ang. PRL), Zapewnienie współpracy z różnymi obszarami interesariuszy biznesowych, W razie potrzeby zapewnienie dostępnośći zasobów biznesowych, Promowanie i tłumaczenie wizji biznesowej na codzienne praktyki pracy, Uczestnictwo jako końcowy arbiter w sytuacjach sprzecznych między członkami zespołów

Sponsor Biznesowy (SB) (ang. Business Sponsor), Champion projektu., Najbardziej uprzywilejowana rola biznesu na poziomie projektu., Zapewnia ogólny kierunek strategiczny i finansowanie., Posiadają wystarczająco wysoką pozycję w organizacji, aby być w stanie rozwiązać zagadnienia biznesowe i podejmować decyzje finansowe., Odgrywa kluczową odpowiedzialność za zapewnienie i umożliwiienie szybkich postępów w całym projekcie., Nie jest zalecane, aby rola była współdzielona., Główną troską są wartości i korzyści projektu, a nie szczegóły techniczne, Odpowiedzialności, Jest właścicielem Uzasadnienia Biznesowego, Odpowiedzialny za Uzasadnienie Biznesowe., Zapewnia bieżącą rentowności projektu zgodnie z Uzasanieniem Biznesowym., Zapewnia, że fundusze i inne środki są dostępne w razie potrzeby., Zapewnia, żę proces decyzyjny dla eskalowanych problemów zagadnień jest skutecznie i szybko przeprowadzany., Szybka reakcja dla eskalowanych zagadnień.

Zespół Rozwoju Rozwiązania (ZRR) (ang. Solution Development Team, SDT). Projekt może psiadać kilka zespółów ZRR.

The SDT on an AgilePM® project is empowered to make decisions on a day-to-day basis within their agreed terms of reference., They do not have to formally agree each and every decision with the PM.

Lider Zespołu (ang. Team Leader), Leadership rather than management., Person holding it will ideally be elected by his or her peers as the best person to lead., Reporting to the PM., Ensures that a SDT functions as a whole and meets its objectives., Works with the team to plan and co-ordinate all aspects of product delivery at the detailed level.

Ambasador Biznesowy (ang. Business Ambasador), A true “ambassador”., Business role within the SDT., Working closely with the rest of the SDT., Responsible for the day-to-day communication between the project and the business., Guides the evolution of the solution., Generally comes from the business area being addressed., Provides business-related information from the perspective of those who will ultimately make direct use of the solution., Provides the business perspective for all decisions related to the way the solution's fitness for business purpose is defined and implemented., Stress key nature of this role., These are typically very busy people who the business struggle to spare.

Doradca Biznesowy (ang. Business Advisor), Often a peer of the Business Ambassador., Called upon to provide specific, and often, specialist input to solution development or solution testing., Often user or beneficiary of the solution., May, for example, simply provide legal or regulatory advice with which the solution must comply.

Analityk Biznesowy (ang. Business Analyst), Fully integrated with SDT., Focuses on the relationship between the business and technical roles, Ensures accurate and decisive direction is provided to the SDT on a day-to-day basis., Ensures that the business needs are properly analysed and are correctly reflected in the guidance the team.

Twórca Rozwiązania (ang. Solution Developer), Interprets business requirements and translates them into a deployable solution that meets functional and non-functional needs., Should ideally be allocated full time to the project., Where they are not full time, the project ought to be their first priority - if this cannot be achieved, significant risk is introduced with regard to timeboxing., AgilePM states that ideally we are looking for true Analyst/Programmers, Soft skills cannot be underestimated - especially communication, negotiation, selling, listening etc.

Tester Rozwiązania (ang. Solution Tester), Fully integrated with the SDT., Performs testing in accordance with the Technical Testing Strategy., Ensure quality solution., Independence of testing is key, Typically the Solution Tester reports to the TC in terms of test results and quality. rather than to the Team Leader.

Doradca Techniczny (ang. Technical Advisor), Technical equivalent of a Business Advisor., Supports SDT., Provides specific and often specialist technical input and advice., could be in real life for example ..., IT Security Expert, IT Security Consultatant, Risk Manager (from organization), Support

Pozostałe / Wspierające role

Facylitator Warszatów (ang. Workshop Facilitator), Independent from project team and client., Independent of workshop outcome., Managing the workshop process., Responsible for the context of the workshop, not the content., Catalyst for preparation and communication.

Coach DSDM (ang. DSDM / Atern Coach), Key to helping a team with limited experience of using AgilePM® to get the most out of the approach within the context of the wider organisation in which they work., Should ideally be independently to ensure competence to fulfil this role.

Specjaliści / Eksperci (ang. Specialist roles), nie widoczne na diagramie, The SDT roles will not always cover every skill needed in a project., Specialist roles may also need to be involved and brought into the AgilePM® project (not only Solution Development Team) on an ad-hoc basis by the PM or TL to fulfil specific functions., Project level, Possible to have Specialist roles at the Project level., Is less likely to be ad-hoc and would more commonly be throughout the project., Common example of a Project level specialist role would be an Operations Co-ordinator., Solution Development Team level, Need to be properly integrated into the project team as appropriate., Required specialist input to the SDT should be formally planned., Individuals identified and their availability checked so that they can attend relevant meetings, facilitated workshops, etc

AgilePM® Produkty (17 główynch, 53 wszystkich) (precyzując Produkty Zarządcze, upraszczając dokumentacja)

Products definitions: - Orange - Business product - Blue - Managemet products - Green - Solution products

Wprowadzenie

AgilePM® identifies deliverables associated with each phase of the lifecycle. These are referred to as Products.

Not all products are required for every project., Enables the product set for a particular project to be kept to a minimum.

Formality associated with each product will vary from project to project and from organisation to organisation., aka. 'Adopt and Adapt' principle.

Some products are specific to a particular phase in the lifecycle, others may continue to evolve through subsequent phases. (see diagram)

Formal products definitions specifies:, When the product is produced, used, updated and archived. This gives a clear view of the transience of a given product and therefore enables appropriate levels of quality control to be applied., The roles that could be responsible for producing, contributing to, accepting and approving the product., These are only suggestions but give an indication of what product responsibilities could be allocated to the people in each role., The product's Quality Criteria, i.e. the set of questions that should be answered positively if the product has fulfilled its purpose satisfactorily.

Legenda

Ikonka, Oznacza, że wybrane produkty są produktami kontrolnymi, które mogą być użyte do podjęcia decyzji TAK/ NIE czy należy kontywuować projekt (tzw. bramki decyzyjne)

Pomarańczowy, Produkty skupiające się na binesie / korzyściach

Niebieski, Produkty skupiające się na zarządzaniu

Zielony, Produkty skupiające się na rozwiązaniu

Faza Przedprojektowa

Warunki Referencyjne (ang. Terms of Reference, ToR), High-level definition of the business driver., Scope and justification of Feasibility phase., Very short document (one two sides maximum)., Can be less formal - email, verbal agreement., Sugerowana zawartość, A brief outline of the business need and the objectives and scope for the project to meet that need., Rekomendowane odpowiedzialności, Tworzy, Ktokolwiek (nie określono konkretnie kto w AgilePM®), Zatwierdza, Sponsor Biznesowy, Konsultowany, Ktokolwiek (nie określono konkretnie kto w AgilePM®), Akceptuje, Analityk Biznesowy, Kierownik Projektu

Faza Oceny Wykonalności (ang. Feasibility Assessment)

Studium Wykonalności (ang. Feasibility Assessment), High-level overview of the project., Assessing the feasibility of the project both from a business and a technical perspective., Addresses main risks, by providing a description and a mitigation strategy for any risks significant enough to influence the viability of the project., Outline Business Case, At a very high level deals with the likely costs and benefits., Sugerowana zawartość, The business vision of success., The scope and objectives of the proposed project., High-level assumptions, dependencies and risk that may impact project viability., Any alternatives that were considered and rejected., The major deliverables of the proposed project., A high-level description of a solution to support the Business Case., An initial identification of any technical constraints to which the solution must adhere., (optional) A disposable 'candidate' of the solution (or key elements of it), demonstrating how it will eventually work and/or demonstrating the technical feasibility of its more risky or complex elements., Rekomendowane odpowiedzialności, Tworzy, Analityk Biznesowy, Zatwierdza, Sponsor Biznesowy, Konsultowany, jakakolwiek wymagana osoba, Akceptuje, Wizjoner Biznesowy, Koordynator Techniczny, Kierownik Projektu

Zarys Planu (ang. Outline Plan), Overview of the project from a Project Management and Solution Delivery perspective., Analyses the responses to the incorporated Project Approach Questionnaire (PAQ), Povides a detailed plan for the work of the Foundations phase., Sugerowana zawartość, An overview of the likely project approach based on the responses to the Project Approach Questionnaire, A likely profile of resources required to work on the project, A description of the facilities and tools required to support the Iterative Development process, The organisation structure and processes required for project governance, An analysis of Risk and Issues impacting on the feasibility of the project (considering both development and deployment of the proposed solution), An outline schedule for the project overall - with top level milestones related to delivery and deployment of the solution, A detailed plan for the Foundations phase of the project, clearly stating the scope and objectives of the work to be completed, the resources required a delivery schedule and an analysis of risk associated with the successful completion of the phase, Project Approach Questionnaire (PAQ), A series of 21 questions, the responses to which, from key project participants and stakeholders, will influence the overall project approach described above., Rekomendowane odpowiedzialności, Tworzy, Kierownik Projektu, Zatwierdza, Sponsor Biznesowy, Konsultowany, Analityk Biznesowy, Akceptuje, Wizjoner Biznesowy, Koordynator Techniczny

Faza Określenia Podstaw (ang. Foundations phase)

Podstawy Biznesowe (ang. Business Foundations), Evolution of the Business Vision from the Feasibility Assessment, Provides information for and / or about the business that is fundamental to the success of the project and that, Needs to be understood by all project stakeholders before development of the solution commences., Sugerowana zawartość, The business, as it will be after the project has completed., The big picture., How that picture differs from the current reality., How this project will contribute to the required change., Any other projects, either planned or in progress, that form part of the vision or may have an impact on it.

(ang. Prioritised Requirements List (PRL)), Describes, at a high level, the requirements that the project needs to address if the Business Case is to be met, Baselined at a high level at the end of the Foundations phase, Refined for detail as the project proceeds through Exploration and Engineering reflecting changes to depth and detail drawn out by the Iterative Development process., There is one PRL list for project., Sugerowana zawartość, A list of high-level requirements to be addressed., A business driven prioritisation of the requirements in accordance with the MoSCoW prioritisation process.

Podstawy Zarządzania (ang. Management Foundations), Refinement of the Outline Plan from Feasibility, Introduction, The Management Foundations product describes essential governance and organisational aspects of the project and describes precisely how the project will be managed. It also describes how the Atern practices and techniques will be applied to ensure management of the project through to a successful conclusion., Note: it is important that the Project Approach Questionnaire responses created in Feasibility are reviewed at this point and that any changes to responses are considered when defining how the project will be managed from here on., Sugerowana zawartość, A validation of the Objectives and Success Criteria for the project, The project approach - based on analysis of the latest responses to the Project Approach Questionnaire and also including the processes required for governance and, where applicable, contact management, The project organisation, including roles and responsibilities, empowerment of teams and reporting lines and governance, Project Management controls for Monitoring and Reporting, Change Control and Risk Management, An overview of the key deliverables, milestones and incremental staging of product delivery, An analysis of major project dependencies

Plan Dostarczania (ang. Delivery Plan), Introduction, The Delivery Plan refines and elaborates on the schedule described in the Outline Plan., Sugerowana zawartość, The incremental nature of the project, The dates associated with the increments and other key milestones., The dates for deployment of the solution and, where applicable, subsets of it, An indication of the focus of each Development Timebox, The timing and dependencies of any activities not planned within the Development Timeboxes, The allocation of resources to timeboxes and other activities, An identification of the contingency associated with one or more of the key constraints of time, resource/cost or, preferably, scope

Pakiet Kontrolny Dostarczania (ang. Delivery Control Pack), Introduction, The Delivery Control Pack comprises reports, documents and logs related to the ongoing status of the project., Sugerowana zawartość, Risk Log, identifying and describing the nature of any risks to the project along with a counter-measure and a priority for action on each., Change Control Records, to record and track requested changes to the scope of the project only. Note: This is normally indicated by a change to the breadth of high-level Prioritised Requirements List baselined at the end of the Foundations Phase and not to the detail or the understanding of the requirements (i.e. the 'depth' of the requirements) which does not represent a change in scope from a business perspective., Periodic Reports, to describe progress towards delivering the solution, to quantify expenditure to date along with forecasts for the future and to highlight any major Risks and Issues currently under evaluation that are likely to have an impact on the scope of final solution or the timescales., Other elements may be added, An issues log, A communications log, A burn-down chart (refer to Glossary for definition), A project dashboard

Podstawy Rozwiązania (ang. Solution Foundations), Provides information for and/or about the solution that is fundamental to the success of the project., Need to be understood by all internal project stakeholders before development of the solution commences., Consists of 4 components, Solution Prototype (optional), The Solution Prototype may be a disposable prototype of the solution (or key elements of it), demonstrating how it will eventually work. Knowledge gained from the prototype will help clarify project estimates and strategies for development and deployment of the solution. This prototype is only created where it adds value in establishing the foundations of the project or in mitigating risk associated with the development., Business Area Definition (BAD), The Business Area Definition (BAD) should be created for any project where the proposed solution impacts on the way 'business as usual' is conducted in a specified organisation. For software projects, this should include a statement from a business perspective of the expected life expectancy and maintenance strategy for the system to be implemented, System Architecture Definition (SAD), The System Architecture Definition (SAD) should be created for any project where there is a systems aspect to the solution. It defines the technical framework within which the solution will be developed and provides a high-level description of the architecture of that solution., Development Approach Definition (DAD), The Development Approach Definition (DAD) defines how the SDT will develop and how they, and associated technical experts and stakeholders, will assess the fitness for purpose of the solution as it evolves against business and technical acceptance criteria. Note: This element of the Solution Foundations may be omitted if the PM and TC agree the required practices and standards are already fully embedded as custom and practice for the organisation as a whole., Recommeded content, A definition of development practices that SDT are expected to follow., All practices should be defined but as a minimum these must include:, Iterative Development of the solution., Business Review and Acceptance of the solution (including Business Acceptance Testing of any software)., Technical Review and Acceptance of the solution (including all non-business aspects of Testing of software)., A definition of any specific standards to be applied to development including, where applicable:, Analysis and Design Standards (including modelling)., Coding Standards., Style guides., Configuration Management standards (for all products that are part of the solution)., aka. BAD SAD DAD :)

Fazy Eksploracji i Budowy (ang. Exploration and Engineering phases)

Plan Wdrożenia (ang. Deployment Plan), Schedule of activities for the delivery of project products covering all aspects of Composition deployment of the solution from a business and a technical perspective, Introduction, Sometimes included as a subset of the Delivery Plan, the Deployment Plan is the detailed plan for the Deployment phase. Unlike the Timebox Plans used during development, the Deployment Plan tends to focus on specific tasks to be performed by specific individuals, rather than on products to be delivered by the Solution Development Team as a whole., Generally speaking it is not possible to Timebox a deployment, as time and resource cannot sensibly be fixed in favour of flexible scope., Benefits Realisation Plan, Introduction, The Benefits Realisation plan defines and schedules the activities required to assess the extent to which the benefits predicted in the Business Case are achieved through operation of the Deployed Solution, Sugerowana zawartość, A description of how and when the baseline of the current state of the metrics will be made for future comparison., A schedule of activities required to ensure that any new or changed working practices are properly embedded, A description of how and when future measurements will be taken, to demonstrate whether target metrics are being achieved and thus whether predicted benefits are being achieved, A description of how and when such measurements will be reported to the Business Sponsor and other interested parties. The Benefits Assessment created during the Post Project phase is the product intended to convey this information., Recommeded content, The work to be completed, The dates associated with the key activities and milestones, The allocation of resources to all activities, An identification of the contingency associated with one or more of the key constraints of time, resource/cost or, preferably, scope

Plan Okienka Czasu (ang. Timebox Plan), Introduction, The Timebox Plan elaborates on the objectives provided for each Development Timebox in the Delivery Plan., Sugerowana zawartość, A definition of the product(s) of an individual Development Timebox, An identification of key milestones, e.g. technical or user review dates, within a timebox, An agreed MoSCoW prioritisation of products and activities within a Development Timebox, An identification of all the resources (human and otherwise) required for successful completion of all work

Zapis Przeglądu Okienka Czasu (ang. Timebox Review Record), Introduction, The Timebox Review Record is produced/updated at the review points in the Development Timebox. They describe what has been achieved and any feedback which may influence plans moving forwards. After the timebox has completed any outstanding issues are considered in the context of the Delivery Plan and future Timebox Plans., The formality of this record will vary from official, signed documents to informal notes or emails depending on the project and the organisation. However the information encompassed by the Timebox Review Record should always exist in some physical form., Sugerowana zawartość, A record of the success of delivery, against the Timebox Plan, specifically describing what has been delivered and what has not., A record of the formal acceptance of the completed deliverables by the business representatives identified to accept them., An assessment of the priority of any work not completed and a plan to show whether and when it will be, either as part of the current timebox or at some point in the future., An assessment of the effectiveness of the timebox control processes and the Iterative Development techniques in line with the principles of Atern.

Pakiet Zapewnienia Jakości Rozwiązania (ang. Solution Assurance Pack), Consists of 3 components, Technical Testing Pack, Introduction, The Technical Testing Pack builds on the firm foundation provided by the Technical Testing Strategy. It evolves, as the solution itself evolves, to demonstrate appropriate control over technical testing activities., Sugerowana zawartość, Technical Acceptance Test Plans, Technical Test Scenarios, Technical Test Data, Technical Test Records, Business Testing Pack, Introduction, The Business Testing Pack builds on the firm foundation provided by the Business Testing Strategy. It evolves, as the solution itself evolves, to demonstrate appropriate control over business testing activities., Sugerowana zawartość, Business Acceptance Test Plans, Business Test Scenario, Business Test Data, Business Test Records, Solution Review Records, Introduction, Solution Review Records provide a record (often informal) of all review activity for deliverable components of the Evolving Solution. They are a key input to the Timebox Review Records. They may sometimes be omitted if the Business Ambassador is fully empowered and fully integrated into the Solution Development Team and where timeboxes are very short., Sugerowana zawartość, A record and explanation of decisions as they are made, regarding the way requirements are addressed in the Evolving Solution., A record of any hitherto unconsidered risks, dependencies or other observations that may impact on future development work.

Rozwijane Rozwiązanie (ang. Evolving Solution), Introduction, The precise nature and composition of the Evolving Solution is entirely dependent on the objectives of the project and the current position in the project timeline. At one extreme, at the beginning of a project it could be a preliminary sketch of a new business process on a flip chart. Towards the end of a project it may be a fully evolved and documented business process supported by a software application and all documentation to use, support and maintain it. It is simply a convenient term to describe a 'work in progress'., Note: the Deployable Solution is a baseline of the Evolving Solution that is ready for deployment.

Faza Wdrożenia (ang. Deployment phase)

Raport z Przeglądu Projektu (ang. Project Review Report), Increment Review (one or more), Introduction, The Increment Review draws on status information from the Timebox Review Records to describe what has been achieved in the creation of the Deployable Solution. It is used as a foundation for plans for future action related either to further delivery increments, future projects and/or the support and maintenance cycle for the Deployed Solution., Sugerowana zawartość, A record of the success of delivery, against the Delivery Plan, specifically describing what has been delivered and what has not., An analysis of decisions recorded in the Timebox Review Records that impacted on the way requirements were addressed., A record of the formal acceptance of the Deployable Solution by the Business Visionary., An assessment of the priority of any work not completed and a plan to show whether and when it will be, either as part of the current project or at some point in the future., An assessment of the effectiveness of the project management and solution development approaches in line with the principles of Atern., Benefits Enablement Summary (one or more), Introduction, The Benefits Enablement Summary links what has been delivered by the project back to the Business Case that justified it., Sugerowana zawartość, A summary of which of the benefits described in the Business Case should now be able to accrue through the proper use of the Deployed Solution., End of Project Assessment, Introduction, The final element of the Project Review Report created at the end of the project, Sugerowana zawartość, A summary of the success of the project in terms of what has been delivered and what has not been delivered., A review of the overall cost of the project and a comparison of this with the estimates from the Foundations Phase for delivering equivalent value., A record of the formal acceptance of the final Deployed Solution by the Business Sponsor., An assessment of the priority of any work not completed that may need to be scheduled at some point in the future., A record of approval for the Project Manager to formally close down the project., A summary of the key learning points with respect to the effectiveness of the development and management processes and the techniques for the project that the organisation as a whole may benefit from.

Wdrożone Rozwiązanie (ang. Deployed Solution), Introduction, The Deployed Solution is an instance of a Deployable Solution from the Engineering phase that is now in operation in the live business environment., Sugerowana zawartość, Fully integrated and mutually consistent components of the final solution as well as any materials required to support it

Faza Poprojektowa (ang. Post Project phase)

Ocena Korzyści (ang. Benefits Assessment), Introduction, The Benefits Assessment describes how the benefits have actually accrued, as the Deployed Solution has been used. For projects where benefits in the Business Case are expected to accrue over a prolonged period, it is likely that Benefits Assessments will be produced on a periodic basis., Sugerowana zawartość, A quantitative description of how the benefits of using the Deployed Solution have been achieved., An analysis of any discrepancies between what has been achieved and what was predicted in the Business Case for the project.

Podsumowanie oraz wnioski

AgilePM® is a product-based approach, projects use delivery of the appropriate products to demonstrate progress., This is a more effective way than simple progress reports, since a product, whether a document, a model, a plan or an evolving solution, is a physical artefact that can be viewed, used, reviewed or tested.

Interaktywny glosariusz

Interaktywny glosariusz AgilePM® (PL)

Matoda AgilePM® składa się z: 1 Filozofii, 8 Pryncypiów, 9 Kluczowych Czynników Sukcesu, 7 Faz Cyklu Życia Projektu, 13 Ról projektowych, 17 głównych artefaktów/produktów zarządczych (upraszczając dokumentacja) i 53 całościowo oraz 7 Technik.

Pobierz: AgilePM® Matryca Fazy Projektowe vs Produkty Zarządcze vs Role vs Odpowiedzialności (PDF)

Pobierz: AgilePM® - Kwestionariusz Przeglądu Projektu (PHCQ) (XLSX)

Pobierz: Szablony dokumentów AgilePM® v0.1 ALPHA [DOCX, XLSX]

Pobierz: AgilePM® - Kwestionariusz Podejścia do Projektu (PAQ) (XLSX)

AgilePM® przykładowe cykle życia projektu (5 przykładów)

AgilePM® iterative and incremental framework is highly configurable.

An individual configuration will depend on the size and formality of the project being delivered.

The lifecycle provides scalability from small projects to large enterprise-wide programmes.

Governance is not lost in AgilePM®.

The project / programme characteristics must be taken into consideration in order to configure the optimum lifecycle for delivery of early business benefit and risk mitigation.

Example AgilePM® lifecycles, 4 separate projects, each with one Deployment phase.

Przykładowy projekt #1, 2 Okienka Czasu, 1 Wdrożenie

Przykładowy projekt #2, 4 Okienka Czasu, 1 Wdrożenie

Przykładowy projekt #3, 2 "dybrydowe" Okienka Czasu, 1 Wdrożenie

Przykładowy projekt #4, In this example 2 separate SDT teams are working separetly on two started parallel Timeboxes (one Timebox is type od Exploaration, second in engeenering)., 4 Okienka Czasu, 1 Wdrożenie

Przykładowy projekt #5, In this example 2 separate SDT teams are working separetly on two started parallel Timeboxes (one Timebox is type od Exploaration, second in engeenering)., 6 Timeboxes., 2 Wdrożenia, Project has two separate Deployments in one project lifecycle.

Ta darmowa mapa (zgodna z najnowszą wersją metody AgilePM®) została pieczołowicie stworzona z pasji i zamiłowania do nauki oraz ciągłego rozwoju jak również w celu promocji metody AgilePM®. Mam nadzieje, że ta mapa pomoże Ci również w nauce do egzaminów Foundation i Practitioner z metody AgilePM®. (podziel się tą mapą z innymi, polub i przekazaż informacje zwrotne - Twoja opinie, komentarze i sugestie są moją motywacją do dalszego jej rozwmoju THX.!)

Pytania / wątpliwość / błędy? Zapraszam do kontaktu. Mapa powstała jako pomoc w Twojej nauce. Każda uwaga jest cenna :-), Mirosław Dąbrowski.

http://www.linkedin.com/in/miroslawdabrowski

https://www.google.com/+MiroslawDabrowski

https://play.spotify.com/user/miroslawdabrowski/

http://www.miroslawdabrowski.com

https://twitter.com/mirodabrowski

miroslaw_dabrowski

Oprogramowanie do zarządzania projektami Agile

oprogramowanie do 'ogólnego' zwinnego zarządzania

SkyTap, http://www.skytap.com/

VersionONE, http://www.versionone.com/

Atlassian, https://www.atlassian.com/

Rally Software, http://www.rallydev.com/

Microsoft Team Foundation Server

Electric Cloud, http://www.electric-cloud.com/

Scaled Agile Framework, http://scaledagileframework.com/

oprogramowanie zgodne z AgilePM®

PROJECT in a BOX, http://www.projectinabox.org.uk/

AgilePM® rekomendowane techniki (7)

Kluczowe Czynniki Sukcesu projektów AgilePM® (9)

9 Instrumental Critical Success Factors (ICSF)

1. Acceptance of the AgilePM® philosophy before starting work, Includes the concept that in order to deliver the right thing at the right time and handle change dynamically may result in delivering less than 100% of the possible solution - this needs to be agreed by all parties., Accepting new philosophy in a new organisation may be difficult - piloting the philosophy (perhaps on a less critical initiative) first helps to win acceptance., All stakeholders must be prepared to accept that change is inevitable., Change will calibrate project course on 'true' Value., It is important that the Business Sponsor and senior management understand and accept the AgilePM Philosophy., This includes acceptance of the meaning of MoSCoW prioritisation - that some features may be de-scoped, by agreement, in order to deliver on time and on budget.

2. Appropriate empowerment of the Solution Development Team (SDT)., The senior business management must agree to delegate an appropriate level of decision-making to the Business Ambassador(s) in the SDT or to take that role themselves. (WHAT), Similarly, the Solution Developers in the team should also be empowered to make appropriate technical decisions. (HOW), If this is not possible, they would need to participate in the team themselves (i.e. in this circumstance, the Business Ambassador role may need to be taken by a more senior person from the Business)., Without business empowerment, team progress will slow down while awaiting decisions being made elsewhere and to a different timeframe., The Business Ambassador(s) should be empowered to make decisions without referral to higher authorities outside the team., Solution Developers in the SDT should also be empowered to make decisions., It is important that the concept of empowerment does not give all SDT members complete freedom to do whatever they want, whenever they want. In reality, empowerment is within agreed boundaries of decision-making., Where a decision is outside the agreed boundaries, this would still need to be formally escalated., However, this is the exception and the majority of day-to-day decision-making should be within the remit of the SDT., Empowerment is two-way - it is not enough to tell people new to AgilePM® that they are empowered -they may need constant reinforcement and coaxing to make their own decisions - the daily stand up will show whether there are risks here.

3. Commitment of senior business management to provide the necessary Business Ambassador (and Business Advisor) involvement, The level of business commitment for this project should be quantified and discussed in the early stages.

4. Incremental delivery, To achieve an early return on investment, the organisation needs to be amenable to the incremental delivery of solutions., Another benefit of the incremental approach is a reduction in risk (compared with the big-bang, large drop of a 100% final solution)., Delivering a partial solution allows the business to take on the solution in manageable chunks and also ensures the solution builds on previous increments, i.e. building from a position of confidence., It is still possible to gain all the project-focused benefits of incremental delivery even if the business chooses not to deploy the solution incrementally: for example building and, potentially, accepting the solution incrementally, ahead of a single production release., All stakeholders must be prepared to deliver a fit-for-purpose solution., Not 'all of nothing' solution.

5. Access by the Solution Development Team (SDT) to business roles, The best communication occurs if the SDT - including the Business Ambassador - are collocated in their own dedicated environment, free from daily interruptions., Collocation is recommended., Even if co-location is not possible, it is often useful to have a room where everyone can come together from time to time. This gives a focus for the project., Developers are in a different time zone from the Business Ambassador(s), there will be periods where it is not possible just to pick up the phone and this potential delay presents a risk to the AgilePM® approach which needs to be addressed.

6. Solution Development Team (SDT) stability, The overlapping development skills required (i.e. business and technical knowledge in use concurrently throughout the Iterative Development process), the speed of development together with AgilePM®'s emphasis on rich communication at the SDT level, rather than communication driven primarily through documents, means that an AgilePM® project will be put at serious risk if staff are swapped in and out. Specialists may be called in as long as the core team remains stable.

7. Solution Development Team (SDT) skills, Progress is significantly enhanced when the SDTs contains skilled people, both in terms of business knowledge and technical expertise., Cross-functional team members., This does not mean that every team member needs to be a multi-skilled expert., All team members must have good communication skills if a team with diverse skills is to function as a coherent unit.

8. Solution Development Team (SDT) size, For this to be effective, AgilePM® suggests that the optimum SDT size is 7 +/- 2 people - at this level, the team can communicate with one another with the minimum of formality, minimum of management overhead.., see George A. Miller: "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information", Bigger or smaller SDTs of course are possible but they can introduce risks, team is very small (3/4 people), There is a risk associated with delivering what has been promised from a Development Timebox., If one person is absent from the team for any reason this may represent a very significant percentage of the capacity to complete the work., team is 9+, Communication become more complex, daily stand-ups take longer which can impact productivity., Some of the team communication may need to be managed more formally., Where the SDT size is going to be greater than 9, splitting into a number of smaller teams may be a better option, although this in itself will introduce an overhead to manage the various teams., Larger teams (SDTs) can be subdivided into smaller teams if the products can be split accordingly., Cross-team stand ups can be a good way of maintaining collaboration.

9. Supportive commercial relationship, Where the supplier and the customer are from different organisations and development is covered by formal contract or where Solution Developers are from the same organisation but working within a service level agreement, the relationship must accommodate the evolution of the solution's requirements without imposing onerous change management overheads.

Understand your constraints

Consider the AgilePM® Principles, Will the organization support this way of working?

Consider the AgilePM® project variables, Is there flexibility in depth and detail of features?

Think about the people, Are all roles capable of and committed to the project approach?

This is rarely a black and white decision

AgilePM® Planowanie

AgilePM® Szacowanie

Watch: official AgilePM® introduction video (by Keith Richards)

AgilePM® Oficjalne publikacje

Agile Project Management Handbook

ISBN-13: 978-0954483241

ISBN-10: 0954483243

http://www.amazon.co.uk/Agile-Project-Management-Handbook-V1-1/dp/0954483243

Pages: 176

The most important, key position on AgilePM® preparing for Foundation and Practitioner exams

Newest version v1.2

Since AgilePM® is a derived methodology, Agile Project Management Handbook, it's 90% of content is identical to content provided in DSDM® Atern® Handbook., DSDM® Atern® The Handbook, ISBN-13: 978-0954482220, ISBN-10: 0954482220, http://www.amazon.co.uk/DSDM-Atern-Handbook-Consortium/dp/0954482220/, Pages: 201, That's because AgilePM® methodology was derived from DSDM® in 2010., Same consortium created both methodologies., DSDM® Atern® The Handbook is available online for FREE., http://www.dsdm.org/dig-deeper/book/dsdm-atern-handbook

AgilePM® Oficjalne zasoby

Copyright © AXELOS Limited.

AgilePM® przykładowe egzaminy, dostępne online

Foundation, http://www.apmg-exams.com/index.aspx?subid=87&masterid=26

Practitioner, sample Practitioner exams are not available online

AgilePM® sylabus egzaminacyjny

EN, http://www.pmweb.co.uk/wp-content/uploads/2013/01/AgilePM-Syllabus-v1.4.pdf

Glosariusz AgilePM®

EN, http://www.agilechangemanagement.co.uk/wp-content/uploads/2013/09/agile-glossary.pdf

AgilePM® White Papers

Agile Project Management White Paper, http://www.dsdm.org/sites/default/files/Agile-PM-White-Paper.pdf