15. Kad lietot Scrum? Nepieciešams ātrs rezultāts Augsta izmaiņu nepieciešamības iespēja Izmaksu efektivitāte Iespēja zaudēt finansējumu
16. Kad nevar lietot tīru Scrum? Projekta sākumā precīzi jānosaka projekta tvērums, termiņš un izmaksas Pasūtītāja (ne) iesaiste Daudzas iesaistītās puses, kas nelieto Scrum
17. Scrum pielāgojumi Dokumentācija kā parasti, Scrum tikai izstrādei/testēšanai Dalītā dokumentācija Regulāri nodevumi Liela Pasūtītāja iesaiste ...
18. Scrum publiskajos iepirkumos? Cilvēki pret funkcionalitāti? Fiksēts budžets/termiņš Iepirkums Ātrs rezultāts Iespēja zaudēt finansējumu
19.
20. DPA piedāvājums Scrum ieviešana Autoruzraudzība Konsultācijas un atbalsts Iepirkumi Izmantot projektos
Excel?5-10%Produkts – OK, projekts – ne visai. 45-70% funkcionalitātes netiek izmantota vispār vai tiek reti izmantota.Kā iegūt to, ko vēlas / ietaupīt naudu uz to, kas nav vajadzīgs? – SCRUM!GuntaPastāstīšu par to ... ->1-4 – kāpēc; kāpēc man;15 – trīs daļāsPēdējais – DPA piedāvājums.
.. kas tad ir scrum, publiskais/privātais sektors kā un kad to var pielietot, kā un kad to labāk nepielietot, kā arī īsumā par DPA pieredzi saistībā ar to.Jautājumu uzdošana...
In 1986, Hirotaka Takeuchi and IkujiroNonaka described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, computer, photocopier, and printer industries.[1] They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the scrum (or whole team) "tries to go the distance as a unit, passing the ball back and forth".[1]In 1991, DeGrace and Stahl first referred to this as the scrum approach.[2] In the early 1990s, Ken Schwaber used such an approach at his company, Advanced Development Methods, and Jeff Sutherland, with John Scumniotales and Jeff McKenna, developed a similar approach at Easel Corporation, and were the first to refer to it using the single word Scrum.[3]
Nedaudz detalizētāk par to, kas scrum ir un kāpēc tā notiek..
Nedaudz sīkāk tieši par SCRUM – būtībā ietvars, kas norāda svarīgākos notikumus, lomas un atribūtus, pie kā jāturas projekta gaitā. Trīs lomas – es, PO (Jūs), komanda.Tātad nedaudz par galvenajiem notikumiem/procesiem scrum:Produkta plānošana – pirmais solis projektā, kas turpinās visu projekta dzīvi; Nodefinē projekta mērķi, kā arī izveido prioritizētu sarakstu ar projektam nepieciešamo funkcionalitāti lietotāja stāstu veidā.Iterācija – visa izstrāde (ieskaitot dokumentāciju) tiek dalīta iterācijās, kur katra iterācija ir vienu līdz 4 nedēļas gara. Garums atkarīgs no projekta izmēra, komandas izmēra un projekta termiņa. Katra iterācija sākas ar iterācijas plānošanas sapulci – svarīgākā funkcionalitāte, komanda paņem, cik var, izrunā ar Pasūtītāju, ko tas nozīmē.. Un beidzas ar atskatu uz to, kā gāja konkrētajā iterācijā, kā arī izstrādātās funkcionalitātes demonstrāciju. Katras iterācijas beigās izstrādāto funkcionalitāti principā varētu laist ekspluatācijā, protams, jāskatās, kādā secībā funkcionalitāte tika izstrādāta (drošība, piemēram).Par pašu scrum mehāniku (iterācijas gaitu, tai skaitā ikdienas sapulcēm u.tml.) no izstrādes puses šobrīd sīkāk nestāstīšu, ja vēlaties, varēsiet uzdot jautājumus pēc prezentācijas. Tagad parunāsim par to, ko tas nozīmē Pasūtītājam
Vision is enough to start the work, we do not need specific details in the very beginningBusiness and IT meet very often and agree the functionality during those meetingsWe take active part in describing the requirements, can help with our experience – Glezna ir labs piemērsNecessary documentation is produced during the projectHigher efficiency thanks to absence of formal communication and bureaucracy
Vision is enough to start the work, we do not need specific details in the very beginningBusiness and IT meet very often and agree the functionality during those meetingsWe take active part in describing the requirements, can help with our experience – Glezna ir labs piemērsNecessary documentation is produced during the projectHigher efficiency thanks to absence of formal communication and bureaucracy
We show added functionality every weekBusiness can decide the functionality that will be added nextAll this provides business with:quick feedback about the real pace of the workall problems come up very quicklythe possbility to STOP the work at any momentWorking software is main metrics of progressIf there is no software to show to customers, then progress is 0%, not 25%, 50% or 90%Vienmēr zināms, cik tālu ir ticis.
Changes are OK in daily life, so can software requirements also changeWe never argue about the changed requirements in the manner like “but we agreed like this...”Priorities of functionality can be changed very easily as business people are deciding about the whole projectYou can erase the functionality that you don’t need any more
Resursu, ne funkciju pirkšanaĪsāka iepirkuma dokumentācija!!! – publiskajam sektoram.Drošāk, ka nebūs sūdzību.Ātrs rezultāts.Pietiek ar vīziju, lai sāktu.Kad atņem naudu... Prioritizētas prasībasPielāgots izmaiņu vadības processIteratīva pieejaAkceptēt funkcionalitāti, nevis nodevumus
Agendā – kāpēc scrum der publiskajiem iepirkumiem;1-4 – kāpēc; kāpēc man;15 – trīs daļāsPēdējais – DPA piedāvājums.Vienmēr zināms, cik tālu projekts ir ticis.Pēdējo bildi labāk sākumā. Vēsture, tad par to, kā bija (10:90) uz (50:50), tad kāpēc tas ir kruta valsts sektorāJa pietiek vietas