Agile

W tej lekcji omówimy, jak zarządzać zakresem w środowisku Agile, w porównaniu do tradycyjnego, predykcyjnego podejścia do zarządzania zakresem.

W środowisku predykcyjnym wszystkie wymagania są jasno określone na początku projektu. Z kolei w środowisku adaptacyjnym definiujemy jedynie te wymagania, które można przewidzieć na początku, a następnie priorytetyzujemy je, tworząc backlog produktu. Nowe wymagania pojawiają się w kolejnych iteracjach, a zakres projektu jest stopniowo rozwijany i uściślany.

Dla przykładu, jeśli budujemy stronę internetową w środowisku predykcyjnym, musimy od razu zdefiniować cały zakres projektu, np. stronę główną, stronę kontaktową i blog. Natomiast w środowisku Agile zaczynamy od stworzenia strony głównej jako priorytetu, a następnie rozwijamy pozostałe elementy, takie jak blog czy strona kontaktowa, w kolejnych iteracjach.

W środowisku predykcyjnym zmiany zakresu są niepożądane, a w adaptacyjnym zmiany są nieuniknione i stanowią integralną część procesu. Zakres jest elastyczny, a budżet i czas są stałe, podczas gdy w środowisku predykcyjnym zakres jest stały, a budżet i czas mogą być elastyczne w zależności od zmian.

W predykcyjnym podejściu do zarządzania zakresem, produkt końcowy jest dostarczany na końcu projektu, natomiast w Agile dostarczamy mniejsze fragmenty produktu w trakcie cyklu życia projektu. Każda dostarczona część, zwana również deliverable, powinna przynosić wartość biznesową, rozwiązywać problemy lub przyczyniać się do osiągnięcia zysków przez firmę.

W podejściu Agile tworzymy backlog produktu, gdzie wymagania są definiowane w postaci opowieści użytkownika (user stories). Jeśli wymagania są niejasne, tworzymy epiki, które później są dekomponowane na bardziej szczegółowe funkcje i opowieści.

Kluczowym elementem jest również definiowanie kryteriów akceptacji, które pomagają określić, czy prace projektowe zostały zakończone. W środowisku predykcyjnym kryteria akceptacji są stałe, podczas gdy w adaptacyjnym mogą ulegać zmianom w trakcie trwania projektu.

Managing Scope in a Predictive Environment

In a predictive environment, all the requirements are clearly defined at the start of the project. Once these requirements are established, we fully define the project scope and work according to this fixed plan.

Managing Scope in an Agile Environment

In an Agile environment, only the requirements that can be predicted are defined at the outset. These are then prioritized in what’s called the product backlog. As the project progresses, new requirements emerge during iterations, and the scope evolves accordingly.

To illustrate the difference, let’s take a simple example. Imagine you’re building a website.

• In a predictive environment, you would need to define all the requirements upfront, such as creating a homepage, a contact page, and a blog. The entire scope is set from the start.
• In contrast, in an Agile environment, you would begin by focusing on the most critical feature—let’s say the homepage. Once that’s complete, you might move on to the blog, and then the contact page, adjusting based on the project’s progress, available budget, and time.

Flexibility in Scope Management

In a predictive environment, scope changes are typically undesirable. The scope is fixed, and while the time and budget may be flexible, changes to the scope require formal approval through a change request process.

In an Agile environment, the triangle is inverted: time and budget are fixed, but the scope remains flexible. We refine the scope iteratively to fit within the established time and budget constraints.

Deliverables in Predictive vs. Agile Environments

In predictive environments, deliverables are typically produced at the end of the project. However, in Agile environments, small parts of the final product (also known as deliverables) are completed and delivered to the customer throughout the project life cycle. These incremental deliverables should always provide value, as delivering business value is the primary goal of the project.

Role of the Business Case and Project Charter

The business case outlines why the project is needed and how it aligns with the organization’s objectives. It defines the value the project is expected to deliver. The project charter then refers to this business case and formally authorizes the project manager and team to begin work.

• In predictive environments, the project charter tends to be more detailed.
• In Agile environments, the project charter is less detailed at the start, as the project scope and requirements are continuously refined throughout the project.

Collecting and Defining Requirements

In predictive environments, most requirements can be collected and defined at the start of the project. The scope is clearly outlined in the project scope statement, and the work is broken down into work packages using a Work Breakdown Structure (WBS). Each work package is further detailed in the WBS dictionary, which helps prevent scope creep.

In Agile environments, many requirements are not clear at the beginning. Instead, high-level requirements are gathered, and more detailed requirements are developed over time. The product roadmap provides a high-level view of the features to be delivered, and the product backlog contains user stories that define the requirements for each iteration.

Acceptance Criteria and Definition of Done

When defining scope, it’s essential to establish acceptance criteria for each deliverable to determine when the work is complete.

• In predictive environments, acceptance criteria are usually fixed and documented in the requirements document or WBS dictionary.
• In Agile environments, acceptance criteria are defined for each user story, and they can evolve as the project progresses. The project also has its own high-level acceptance criteria, typically outlined in the project charter.

In Agile projects, we also define a “definition of done,” which provides a shared understanding among the team about what “done” means for each user story. Unlike acceptance criteria, which are specific to individual requirements, the definition of done applies more generally to all stories in the backlog.