Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Podejście zwinne a fazy projektu

No description
by

Krzysztof Gradek

on 4 May 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Podejście zwinne a fazy projektu

Zwinne relacje pomiędzy zamawiającym i dostawcą
Czym jest "zwinna relacja"?
Finał
Zwinna relacja - współpraca na rzecz osiagniecia celów zamawiajacego w warunkach obopólnych korzysci stron projektu
Faza "przedsprzedaży"
Umowa
Realizacja projektu
Dziękujemy za uwagę
Mariusz Wieteska
Dyrektor Business Intelligence, Kierownik Projektów
mariusz.wieteska@pentacomp.pl
Krzysztof Gradek
Kierownik Projektów, Architekt
krzysztof.gradek@pentacomp.pl
Kiedy warto wprowadzać zwinna relację?
Istnieje wcześniejsza relacja zaufania między partnerami

Zamawiajacy rozumie i akceptuje ryzyka oraz szanse wynikające z takiego podejścia

Przedmiot projektu nie jest określony w precyzyjny sposób
Kiedy relacja zwinna niewskazana?
Brak decydenta po stronie Zamawiającego

Brak zaufania wynikajacy z poprzednich doświadczeń

Brak zaangażowania partnera w projekt (czas, decyzyjność)

Partner gra na jednostronne zwycięstwo, nie interesuje go rozwiązanie win-win
Podejście tradycyjne vs zwinne
Źródło: Mitch Lacey, Implementing Scrum as a Cost Saving Measure, presented in Lisbon in 2009
Korzyści dla zamawiającego
Wynik projektu odpowiada ostatniej definicji wymagań biznesowych
Możliwość dowolnej zmiany, dodawania wymagań - przy założeniu, że sumaryczna ilość pracy nie ulega zmianie
Kolejność realizacji wymagań ustalana przez zamawiającego
Opcja zakończenia projektu wcześniej - jeśli zrealizowana zostanie wystarczająca biznesowo część funkcji
Ken Schwaber Jeff Sutherland
Scrum - podstawy
Źródło: http://en.wikipedia.org/wiki/File:Scrum_process.svg
O czym rozmawiamy?
Co po kolei?
Tworzymy rejestr wymagań - Product Backlog
Szacujemy przewidywany czas trwania (bez buforów)
Wskazujemy optymistyczny i pesymistyczny wariant
Typy umów
Fixed-date
Fixed-cost
Fixed-scope
All-fixed
T&M - dla prac nieplanowanych (lub całości)
Umowa ramowa ze zleceniami
Budowa hurtowni danych i platformy analityczno-raportującej dla klienta sektora "Media i rozrywka"

Przed rozpoczęciem projektu:
"W systemach źródłowych jest porządek"
"Wiemy czego chcemy"
Przykład
SCRUM zapisany w kontrakcie:
stała cena (5 sprintów)
stały termin
wstępnie (i ogólnie) wypełniony Product Backlog
możliwość szybkiego wprowadzania zmian zakresu ("Change for free")
możliwość wcześniejszego zakończenia projektu, np. po 4 Sprintach ("Money for nothing")
Jakie ma doświadczenia z projektów (negatywne)
Ilość dostępnego czasu na realizację
Zapoznanie z zespołem dostawcy
Przyjęcie formuły all-fixed oznacza, że:
dostawca dodaje bufory, a to podnosi cenę
nie powstaje relacja zaufania
często rezultat nie odpowiada oczekiwaniom
Jest alternatywa
Przykład 2
System dla sektora finansowego, w domenie nieznanej wcześniej na rynku lokalnym, o wysokim poziomie innowacyjności technologicznej.

Formuła współpracy z klientem:
pierwszy etap - analiza i architektura - All-Fixed
budowanie relacji, bieżące działania oparte o metodę Scrum
kolejne etapy - realizacja w oparciu o metodę Scrum wpisaną w definicję umowy ("Contract Scrum")
Backlog prac zdefiniowany, ale zmiany wprowadzane wg potrzeb
Możliwość zakończenia prac po dowolnym etapie
Wspólna praca nad Backlogiem
Zaangażowanie zamawiajacego
obecność zamawiającego w trakcie planowania i odbioru etapów (Sprintów)
obecność zamawiającego w codziennych spotkaniach
wspólny (mieszany) zespół zamawiającego i dostawcy
Czynniki sukcesu
Symptomy zagrożeń
Brak stabilności Product Backlogu - częste zmiany, wszystkie wymagania o tym samym priorytecie
Brak wspólnej definicji MVP
Brak jednej osoby po stronie zamawiającego "ogarniającej" całość zagadnień
Brak zrozumienia przez zamawiającego wpływu swoich decyzji na dalsze prace -> czy na pewno zamawiający rozumie proces oparty na metodzie Scrum?
Brak zaangażowania kluczowych interesariuszy
Brak stałej weryfikacji wyników - "wszystko jest OK"
Spadające morale zespołów
Od czego zaczynamy?
Jeśli mamy spójny Product Backlog:
potwierdzenie priotytetów
doszczegółowienie najważniejszych wymagań
podjęcie realizacji wymagań przewidzianych na pierwszy etap

Jeśli wynik jest niedookreślony - wstępna analiza - w ramach osobnego projektu:
konieczna wspólna praca zespołów zamawiającego i dostawcy
wynik prac (czyli Product Backlog) podstawą dla docelowej umowy na realizację
Relacja zwinna?
Zaufanie w relacji to podstawa
Literatura:
Jim Highsmith: Agile Software Development Ecosystems
Mary Poppendieck: Lean Software Development
Zaufanie to pewność, że partner wypełni zobowiazania i ...
nie wykorzysta słabości

Jeffrey Dyer, Collaborative Advantage, 88
Tak! Ale pod warunkiem win-win
Full transcript