Agile product backlog for the gov project

621 views

Published on

Presentation from Agile Day 2012, Vilnius, Lithuania

Published in: Technology
2 Comments
1 Like
Statistics
Notes
  • P.S. Idomi prezentacija. Dekui.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Kazkaip pasigedau Riziku skaidres. Man rodos toks vykdymas labai daug priklauso nuo to ar yra zmogus pas uzsakova, kuris nesibaido atsakomybes ir pasirenges priimti sprendimus, bei turi laiko isigilinti/reviewinti tarpines versijas. Kitu atveju tas scrum procesas butu tik geresnio produkto/paslaugos kurimo iliuzija.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
621
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
5
Comments
2
Likes
1
Embeds 0
No embeds

No notes for slide

Agile product backlog for the gov project

  1. 1. Produkto darbų sąrašo planavimas valstybiniam projektui Aleksej Kovaliov Įvairių projektų vadovas www.linkedin.com/in/aleksejkovaliov
  2. 2. Turinys • Planavimo stiliaus svarba • Valstybinių projektų planavimo ypatumai • Planavimo procesas • Projekto pavyzdys
  3. 3. Agile komanda Darbai Rezultatai Darbai Darbai Darbai Darbai Darbai 1 ciklas „Skaidrios juodos dėžės“ mechanizmas Progreso matavimas ir vizualizavimas Žmonių, įrankių ir procesų sistema
  4. 4. Kad mechanizmas veiktų sklandžiai http://www.ak47rifles.net
  5. 5. Reikia paruošiamųjų pastangų http://www.ak47rifles.net
  6. 6. Įvesties formatas turi atitikti mechanizmą Darbai Darbai Darbai Darbai Planas – įvestis judrios komandos mechanizmui
  7. 7. Judraus projekto planavimo procesas Tikslai Prioritetai Paleidimų planas Darbų sąrašas
  8. 8. Valstybinis projektas? Informacinės sistemos kūrimo arba modernizavimo projektas, vykdomas viešojo pirkimo pagrindu, finansuojamas struktūrinių fondų lėšomis ar pan. Charakteristikos: • Ilgai rengtas • Sunkiai keičiamas • Daugiapakopė atskaitomybė
  9. 9. V-projekto reikalavimai Programa Galimybių studija Techninė specifikacija Pirkimo dokumentai Konkursas Sutartis Analizė 1-3 metai 0,5 metų
  10. 10. V-projekto plano modelis Pastaruoju metu populiarėja iteraciniai planai
  11. 11. Ką turime ir ko norime Turime Norime Fiksuoti terminai ir biudžetas Taikyti judrias metodikas Reikalavimų entropija Reikalavimai galėjo pasenti „Vieno šūvio“ projektas
  12. 12. Fiksuotas judrusis © «Иван Василиевич меняет профессию», Mosfilm
  13. 13. Ar gali toks projektas būti judrus? Fiksuoti elementai „Judrūs“ elementai Biudžetas Nedidelė komanda Galutinis ir tarpiniai terminai Pokyčiai Reikalavimų rinkinys Netikslūs prieštaringi reikalavimai Dėl Tiekėjo apribojimų Abi pusės dažnai motyvuotos fokusuotis ties reikalavimų sąrašu! Pagrindinės bėdos
  14. 14. Bėda 1: Neaiškius projekto tikslus užstoja gausūs reikalavimų sąrašai ...kaip nurodyta pirkimo dokumentų priedo A techninės specifikacijos punktuose 1 – 1489...
  15. 15. Pasirinkite TOP 3 prioritetus! Surūšiuokite reikalavimų lapelius Bėda 2: Dažnai nėra net galimybių formaliai prioritetizuoti darbus
  16. 16. Bėda 3: Tiekėjas įpratęs kirsti kampus ir turi puikius formalaus pridavimo įgūdžius
  17. 17. Kokia projekto prasmė? Kaip suvalgyti dramblį? ... ar būtina valgyti? Planavimo iššūkiai
  18. 18. Ken Swabber sako, kad tai ne Scrum Scrum’s principle is “the art of the possible,” not “you give me what I paid for, when you said that you’d deliver it.” http://www.incrementor.com/agilenyc/past-events/2010-2/110310-ken-schwaber/ Agile Project Management with Scrum by Ken Schwaber Microsoft Press © 2004
  19. 19. You give me what I paid for, when you said that you’d deliver it
  20. 20. The art of the possible Analizės pastangos Realizacijos pastangos
  21. 21. Jeigu sugebame priduoti projektą kertant kampus, tikrai yra vietos judriam planavimui V-projekto judrumo šaltiniai • Kliento orientacija į naudingą rezultatą – Būna paslėpta už formalių reikalavimų ir įpročių • Tiekėjo gebėjimas suvokti prioritetus ir planuoti • Laisvė nustatytuose rėmuose – Tikslų ir prioritetų tikslinimas – Reikalavimų interpretacija – Neformalios apimčių korekcijos galimybės
  22. 22. Kaip planuoti V-projektą? • Kaip produktą rinkai – Apibrėžti ir vizualizuoti tikslus – Strateginis planas (Roadmap) – Riboženkliai (Go Live) – Tarpiniai paleidimai (Beta testing) – Auginimas versijomis – Kirsti niekam nereikalingus kampus • Formalumai – dalis produkto pakuotės • Fokusuotis tieks tikrais tikslais ir prioritetais +
  23. 23. Tikslų paieška Oficialūs tikslai Specifikacijos reikalavimai Paklausimai Analizė Ekspertinės žinios ir intuicija Geriausiai klaust Kliento, bet būna prireikia tyrimo
  24. 24. Prioritetų paieška Tikslų sulyginimas su oficialiais Teisiniai veiksniai (nauji įstatymai) Valstybės programos Kitų įstaigų įtaka Tinkamumas viešiems ryšiams Paklausimai Analizė Ekspertinės žinios ir intuicija Geriausiai klaust Kliento, bet būna prireikia tyrimo
  25. 25. Paleidimų planavimas Oficialios projekto iteracijos Oficialios projekto pateiktys Įrangos pristatymas Išoriniai teisiniai veiksniai Politiniai ir viešųjų ryšių renginiai Vidiniai veiksniai (ištekliai, projektai) Riboženklių planas Alfa, Beta ir Galutinių versijų paleidimų planas Kiekvienas paleidimas – naudotinas mini-produktas su savo tikslais. Po kiekvieno paleidimo hipotetiškai galima stabdyti projektą ir naudotis.
  26. 26. Darbų planavimas Paleidimo tikslai Oficialūs reikalavimai pagal paleidimo pateiktis Paleidimo specifikacijos dokumentas Scenarijų sąrašas pagal paleidimo specifikaciją Kitų projektinių veiklų rezultatų sąrašas Vertinimas (santykinis, kalendorinis) Filtras ir rūšiavimas pagal tikslus ir prioritetus Reikalavimų korekcijos, išlaikant scenarijaus esmę Darbai planuojami konkrečiam paleidimui
  27. 27. Produkto elementai / Darbai • Scenarijai arba teiginiai I.N.V.E.S.T. principu – I – Independent – N – Negotiable – V – Valuable – E – Estimable – S – Small – T – Testable • Priėmimo kriterijai • Tie patys panaudos scenarijai (use case) arba specifikacijos reikalavimai kartojami darbų sąraše po N kartu, auginant produktą © Bill Wake, http://xp123.com/
  28. 28. V-projekto pavyzdys Atviras konkursas Integruotos baudžiamojo proceso informacinės sistemos programinės ir techninės įrangos pirkimas (VRM-D23-70)
  29. 29. Apie sutapimų atsitiktinumą Toliau pateikiama medžiaga – reikalavimai, planai, darbų aprašymai ir kt. - yra tik iliustracija, kuri parengta remiantis asmenine paviršutine pasirinkto projekto pavyzdžio reikalavimų analize. Pilnai galimi neatitikimai, lyginant su galutine techninės specifikacijos versija. Bet kokie sutapimai su realiais tiekėjų pasiūlymais arba planais yra visiškai atsitiktiniai.
  30. 30. Reikalavimai Reikalavimai: 368 (+100), 52 psl. Kompiuterizuojami dokumentai: 255 Panaudos scenarijai: 60+ Integruojamos sistemos: 17 (?)
  31. 31. Oficialūs tikslai © IBPS techninė specifikacija, VRM • Projekto bendrasis tikslas – Skatinti ir vystyti koordinavimą, kooperaciją ir tarpusavio supratimą tarp baudžiamąją teisę įgyvendinančių institucijų Lietuvoje bei kitų institucijų Latvijoje ir Estijoje. • Šio pirkimo tikslas – Sukurti Integruotą baudžiamojo proceso informacinę sistemą • Šio pirkimo uždaviniai: – Įteisinti IBPS, – Pakoreguoti modernizuotų IS nuostatus ir IS specifikacijas, – Sukurti IBPS posistemius, – Modernizuoti PRĮR, – Modernizuoti IPS, – Modernizuoti LITEKO, – Sukurti ir išbandyti integracines sąsajas tarp IBPS ir ikiteisminiame tyrime dalyvaujančių įstaigų sistemų PRĮR, IPS ir LITEKO. – Sukurti sąsajas su IKTAŽR, NVŽR, IAR, GR, JAR, AŽŽR (HDR), TAAR, AR (per Vidaus reikalų informacinės sistemos Adreso komponentų tvarkymo posistemį), DDR, DNRDR, UR, INDR. – Įsigyti, įdiegti ir sukonfigūruoti IBPS kūrimui reikiamą techninę įrangą, – Įsigyti, įdiegti ir sukonfigūruoti IBPS kūrimui reikiamą licencinę programinę įrangą
  32. 32. Tikslai ir prioritetai 1. Gerinti bendradarbiavimą tarp teisėsaugos bei kitų susijusių institucijų ikiteisminio tyrimo (IT) eigoje per – Automatizacijos lygio suvienodinimą – Informacijos ir darbo priemonių standartizaciją – Automatizuotus informacijos mainus 2. Kelti pareigūnų ir kitų atsakingų asmenų veiklos efektyvumą užtikrinant galimybę kontroliuoti IT eigą ir mainytis informacija realiuoju laiku 3. Mažinti popierinių dokumentų apyvartą ikiteisminio tyrimo eigoje, pereinant prie elektroninių dokumentų ir informacinių sistemų Turi būti galima vizualizuoti
  33. 33. Medžiaga paleidimų planavimui1 • I iteracija turi būti ištestuota ir priimta iki 2012-12-20. I iteracijos apimtyje turi būti sukurtas ir ištestuotas toks funkcionalumas: – IT vykdymo posistemio.... punktuose nurodytos funkcijos ar reikalavimai ... – IT kontrolės posistemio ... punktuose nurodytos funkcijos ar reikalavimai ... – IT teisėjų veiksmų posistemio ... punktuose nurodytos funkcijos ar reikalavimai ... – DUVP posistemio ... punktuose nurodytos funkcijos ar reikalavimai ... – Integracinės sąsajos su GR, JAR, UR, NVŽR, IKTAŽR • II iteracija turi būti ištestuota ir priimta iki 2013-05-20. II iteracijos apimtyje turi būti sukurtas ir ištestuotas toks funkcionalumas: – IT vykdymo posistemio.... punktuose nurodytos funkcijos ar reikalavimai ... – IT kontrolės posistemio ... punktuose nurodytos funkcijos ar reikalavimai ... – IT teisėjų veiksmų posistemio ... punktuose nurodytos funkcijos ar reikalavimai ... – DUVP posistemio visas funkcionalumas – Naudotojų administravimo posistemio visas funkcionalumas – Klasifikatorių posistemio visas funkcionalumas – Integracinės sąsajos • III iteracija turi būti ištestuota ir priimta iki 2013-07-10. III iteracijos apimtyje turi būti sukurtas ir ištestuotas visas likęs funkcionalumas © IBPS techninė specifikacija, VRM
  34. 34. Medžiaga paleidimų planavimui2 • Visi įsipareigojimai pagal sutartį (išskyrus garantinį aptarnavimą) turi būti suteikti iki 2013-08-10 • Šalių susitarimu kiekvienas sutartinių įsipareigojimų vykdymo terminas ... gali būti pratęstas 2 (du) kartus, bet iš viso ne ilgesniam kaip 6 mėnesių laikotarpiui • IBPS specifikacijos projektas turi būti parengtas ir suderintas su PO (neįskaitant tarpinstitucinio derinimo) per 6 mėn. nuo sutarties įsigaliojimo datos • Techninė ir licencinė programinė įranga turi būti pristatyta, įdiegta ir sukonfigūruota per 7 mėnesius nuo sutarties įgyvendinimo pradžios • Tarpinstitucinis derinimas ??? mėnesių • Finansinių metų pabaiga 2012-12-15 • Garantinis laikotarpis turi būti ne trumpesnis kaip 24 mėnesiai nuo galutinio perdavimo-priėmimo akto pasirašymo datos • Lietuvos Respublikos Seimo rinkimai 2012-10-14 • Galimas projekto inicijavimas 2012-07, įvertinus konkurso ir sutarties pasirašymui reikalingą laiką © IBPS techninė specifikacija, VRM
  35. 35. Pateiktys • IT vykdymo posistemis (ITVP) • IT kontrolės posistemis (ITKP) • IT teisėjų veiksmų posistemis (ITTVP) • Duomenų mainų posistemis (DMP) • Dokumentų ir užduočių valdymo posistemis (DUVP) • Naudotojų administravimo posistemis (NAP) • Bendrųjų klasifikatorių posistemis (BKP) • Bendro naudojimo posistemiai (BNP) • Techninė įranga ir licencijos • Dokumentacija • Modernizuojatos 3 išorinės sistemos Kokie projekto riboženkliai? Koks paleidimų procesas? Kas įeina į 1 paleidimą?
  36. 36. Išorinis produkto planas (Roadmap) Santykiniai terminai Sutartiniai riboženkliai ProductRoadmap
  37. 37. 1 riboženklis 6 mėn. nuo pradžios Pateiktys pagal prioritetus Pagrindimas ir komentarai Duomenų mainų posistemis Beta1 Projekto tikslas nr. 1 Integruojamų ir modernizuojamų sistemų rizikos Tarpinstitucinio derinimo rizikos Dokumentų ir užduočių posistemis Beta1 Projekto tikslas nr. 2, 3 Galutinė versija jau kitą iteracija IT vykdymo posistemis Beta1 Projekto tikslas nr. 1, 2 Daug panaudojimo scenarijų IT kontrolės posistemis Beta1 Projekto tikslas nr. 1, 2 IT teisėjų veiksmų posistemis Beta1 Mažai reikalavimų ir panaudojimo scenarijų Naudotojų administravimo posistemis Beta1 Grįžtamasis ryšis nėra kritiškas Bendrųjų klasifikatorių posistemis Beta1 Grįžtamasis ryšis nėra kritiškas Bendro naudojimo posistemiai Beta1 Grįžtamasis ryšis nėra kritiškas Dokumentacija / IBPS specifikacija Įeina į „Done“ Specifikacija pagaminama iš „Done“ dokumentacijos Pristatyta, sumontuota ir įdiegta platforma Pagal reikalavimus terminas - 7 mėn.
  38. 38. 1 riboženklio paleidimai 1 2 3 4 5 6 Vidiniai Išoriniai Tiekėjo aplinkoje Alpha6XAlpha2X Alpha4X Alpha4Alpha1 Alpha2 Alpha3 Alpha6Alpha5 Išoriniai darbinėje aplinkoje BETA1 Beta1 kandidatas
  39. 39. Paleidimų pateikčių planas Pateiktys pagal prioritetus Alpha1 Alpha2 Alpha3 Alpha4 Alpha5 Alpha6 Duomenų mainų posistemis Beta1 Dokumentų ir užduočių posistemis Beta1 IT vykdymo posistemis Beta1 IT kontrolės posistemis Beta1 IT teisėjų veiksmų posistemis Beta1 Naudotojų administravimo posistemis Beta1 Bendrųjų klasifikatorių posistemis Beta1 Bendro naudojimo posistemiai Beta1 Dokumentacija / IBPS specifikacija Pristatyta, sumontuota ir įdiegta platforma Produktas auginamas. Išorinės versijos sutampa su vidinėmis savo funkcionalumu, skiriasi tik pakuotė.
  40. 40. Alpha1 paleidimo tikslai • Tvarkyti IT bylos dokumentus be pasirašymo • Skirti IT užduotis įstaigos viduje ir tarp įstaigų • Gauti ir perskaityti IT užduotis • Inicijuoti IT pagal PRĮR įvykį Mini-produktas, kuriuo jau galima naudotis
  41. 41. Alpha1 Produkto elementas / Darbas Pateiktys Komanda gali kurti ir saugoti dokumentus bei išeities kodą Projekto aplinka Komanda gali diegti ir testuoti savo programas Testavimo aplinka Sukurti IT bylos dokumentą, aprašant bylą metaduomenyse DUVP Įkelti IT bylos dokumento rinkmenas DUVP Sukurti užduotį pradėti IT DUVP Sukurti užduotį pradėti IT automatiškai pagal įvykį iš PRĮR DUVP, DMP Sukurti užduotį, susijusią su IT bylos dokumentu įstaigos viduje DUVP Sukurti užduotį, susijusią su IT bylos dokumentu, kitai įstaigai DUVP Peržiūrėti paskirtų IT užduočių sąrašą DUVP Užregistruoti IT bylos formą, bylos dokumentus ir tarnybinį pranešimą apie pradėtą IT ITVP, DUVP Komanda gali diegti ir testuoti savo programas testavimo aplinkoje su išorinių sistemų simuliatoriais DMP Valdyti IT bylos dokumentus DUVP
  42. 42. Alpha2 Produkto elementas / Darbas Pateiktys ... ... ... ... ... ... ... ... ... ... ... ... ... ... Pradėti IT be kontrolės ITVP, DUVP, DMP Tvarkyti įtariamojo apklausą be kontrolės ir teisėjo ITVP, DUVP, DMP Tvarkyti liudytojo ar nukentėjusiojo apklausą be kontrolės ir teisėjo ITVP, DUVP, DMP Tvarkyti akistatą ITVP, DUVP, DMP Tvarkyti parodymų patikrinimo veiksmus ITVP, DUVP, DMP Išvardinti stambūs formalūs panaudojimo scenarijai su aiškiais apribojimais
  43. 43. Produkto elemento pavyzdys • Pavadinimas: – Sukurti užduotį, susijusią su IT bylos dokumentu, kitai įstaigai • Naudotojo istorija: – Kaip prokuroras, aš sukuriu prašymą Vilniaus mieto 3 apylinkės teismo teisėjui pripažinti Vardenį Pavardenį įtariamuoju tam, kad IT pareigūnas galėtų sukurti šaukimą • Priėmimo kriterijai: – Sistema automatiškai pasirenka mažiausiai apkrautą teisėją – Teisėjas mato užduotį skyriuje „Mano bylos“ – Prokuroras mato, kuriam teisėjui paskirta užduotis, skyriuje „Mano bylos“ – Tenkina reikalavimus ### specifikacijos punktuose
  44. 44. I.N.V.E.S.T principas • I – Independent • N – Negotiable • V – Valuable • E – Estimable • S – Small • T – Testable • + Priėmimo kriterijai © Bill Wake, http://xp123.com/
  45. 45. Reziumė • Planavimo stilius nusako, ar jūsų komanda dirbs judriai • V-projekte yra vietos „judrumui“ • Formalūs reikalavimai nusako „pakuotę“, bet ne planą – Formali specifikacija ir terminai galioja • V-projektą planuoti, kaip produkto paleidimą į rinką – Tikslai->Prioritetai->Riboženkliai->Paleidimai->Darbai – Inkrementinis auginimas • I.N.V.E.S.T. + priėmimo kriterijai • Tai didina abiejų šalių pastangas • Tai didina produkto praktinę naudą
  46. 46. Klausimai?

×