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

Zwinne relacje

Czy ContractScrum jest osiągalny?
by

Krzysztof Gradek

on 8 May 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Zwinne relacje

Dominuje All-Fixed, ale ... Contract Scrum Czy to w ogóle możliwe? All-Fixed Contract Scrum Software to nie produkcja przemysłowa

Od współdziałania zależy sukces

Potrzeby i wymagania zmieniają się szybciej niż formalne zapisy Na początek Czy można inaczej, niż All-Fixed? Kim jesteśmy? Mariusz Wieteska O czym będziemy mówić? Manifest Agile a kontekst formalny

Komunikacja z zamawiąjacym na każdym poziomie, od użytkownika po sponsora projektu

Wpisanie zmiany jako naturalnego elementu procesu wytwórczego, brak potrzeby CRów Case Study - sektor finansowy Co się udało osiągnać tylko dzięki podejściu zwinnemu:
ewoluowanie koncepcji
weryfikacja hipotez
zarzucenie nietrafionych pomysłów
użycie rozwiązań technologicznych najlepszych, a nie najłatwiejszych do zastosowania Case Study - sektor publiczny Kontekst:
duży klient sektora publicznego
system transakcyjny, istotny na poziomie Państwa
24/7
sztywny unijny termin uruchomienia produkcyjnego Obszar współpracy z klientem
udział klienta w SprintReview z całym zespołem
wspólne ustalanie priorytetów na kolejny sprint Fixed-price, fixed-scope, ale:
najważniejsze dla klienta wymagania najpierw i bardziej szczegółowo
nie ma w SIWZ, ale potrzebne biznesowo -> realizujemy Case Study - sektor publiczny, cd. Zyski ze współpracy:
system zgodny z oczekiwaniami klienta
klient widzi na bieżaco postępy prac -> większe poczucie bezpieczeństwa po stronie klienta
strony widza zaangażowanie swoich zespołów -> większa motywacja po obu stronach
minimalizacja ryzyka czasu Zagrożenia dla dostawcy:
zwiększenie zakresu Contract Scrum? Zaufanie w relacji to podstawa W definicję umowy wpisana ciągła współpraca, udział w Sprint Review, wspólne ustalanie priorytetów

Regularne udostępnianie kolejnych wersji tworzonego systemu 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 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 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 Projekty Business Intelligence Dlaczego BI? Bo 70% wdrożeń BI kończy się porażką Stały termin Stały zakres Stała cena Fixed everything Kontrakt "tradycyjny" oparty o model kaskadowy Planowanie Analiza Projekt Implementacja Testy 16 - 24 miesiące Produkt Użytkownik Procedura kontroli zmiany Kontrakt zwinny oparty o SCRUM Ken Schwaber Jeff Sutherland Scrum Co oznacza "porażka"? Projekty BI - przyczyny problemów 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 Projekty BI - przyczyny problemów "Przetrwają nie najsilniejsze ani najinteligentniejsze gatunki ale te, które najlepiej reagują na zmiany" Karol Darwin http://www.flickr.com/photos/shehal/2259471847/ Podejście
"tradycyjne" Podejście
"zwinne" znaczące przekroczenie terminu
znaczące przekroczenie budżetu
niezadowolenie użytkownika końcowego nieodpowiednia komunikacja
brak zaangażowania użytkowników
częste zmiany wymagań nieodpowiednia komunikacja
brak zaangażowania użytkowników
częste zmiany wymagań Obszar współpracy z klientem
udział klienta w SprintReview z całym zespołem
wspólne ustalanie priorytetów na kolejny sprint
w pewnym momencie ... wspólna praca nad projektem Kontekst:
duży klient sektora "Media i rozrywka"
budowa hurtowni danych i platformy analityczno-raportującej
przed rozpoczęciem projektu:
"W systemach źródłowych jest porządek"
"Wiemy czego chcemy" 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") Case Study - sektor medialny Problemy w trakcie realizacji:
problemy z jakością danych w systemach źródłowych
zmieniające się wymagania raportowe
zmiany w systemach źródłowych (techniczne oraz biznesowe) Case Study - sektor medialny cd. Przebieg projektu:
pierwsze raporty zasilone produkcyjnymi danymi po zakończeniu Sprintu nr 1
bardzo szybka identyfikacja problemów oraz realnych potrzeb Klienta
błyskawiczna obsługa nowych wymagań Korzyści z zastosowania zwinnego podejścia:
bardzo szybkie poznanie nowej branży oraz rzeczywistych potrzeb Klienta (przez nas)
bardzo szybkie poznanie możliwości systemu (przez Klienta)
błyskawiczna obsługa nowych wymagań Tak! Ale pod warunkiem win-win Kontekst:
system dla sektora finansowego
domena nieznana wcześniej na rynku lokalnym
wysoki poziom innowacyjności technologicznej
kosztowne skutki błędów w systemie Formuła współpracy z klientem:
inicjalnie All-Fixed
budowanie relacji, bieżące działania oparte o metodę Scrum
przejście na formułę z metodą Scrum wpisaną w definicję umowy Case Study - sektor finansowy, cd. Zagrożenia dla dostawcy:
brak specyfikacji wymagań, wyłącznie opis potrzeb Elementy niezbędne do uzyskania wyników:
wysokie kompetencje i zaangażowanie zespołu
kompetencje i dostępność przedstawicieli klienta
zaufanie pomiędzy stronami Zagrożenia dla odbiorcy:
nie dotrzymanie terminu (strata prestiżowa)
błędy w kluczowych funkcjach Zagrożenia nie zmaterializowały się Zagrożenia dla odbiorcy:
system niezgodny z potrzebami
brak specjalistów znających domenę Case Study - sektor finansowy, cd. Case Study - sektor telco Kontekst:
duży klient sektora telekomunikacyjnego
hurtownia danych + platforma analityczno-raportowa
czas trwania projektu: 12 miesięcy
zespół po stronie Dostawcy: 10 osób
szybko rozwijający się rynek telco Realizacja na podstawie zatwierdzonej specyfikacji.

Procedura kontroli zmiany jako narzędzie pozwalające na zapanowanie nad częstymi zmianami zakresu.

Dokumentacja jako główny środek komunikacji pomiędzy Dostawcą a Klientem (ponad tysiąc stron dokumentacji analityczno-projektowej).

Duża grupa raportów nie wykorzystywanych po zakończeniu wdrożenia. Skąd jesteśmy? Pentacomp Systemy Informatyczne Krzysztof Gradek Contract Scrum - kiedy warto, a kiedy odpuścić? A co z sektorem "Public"? http://en.wikipedia.org/wiki/File:Scrum_process.svg
Full transcript