Your SlideShare is downloading. ×
0
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Scrum
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Scrum

553

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
553
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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
  • Transcript

    • 1. Soli priekšā projektu vadībā. Scrum.<br />Gunta Strode<br />DPA vadošā projektu vadītāja<br />
    • 2. Saturs<br />Kas ir Scrum?<br />Scrum pielietojums<br />DPA un Scrum<br />
    • 3.
    • 4.
    • 5. Scrum<br />
    • 6. Sadarbība starp IT un biznesu<br />Komunikācija<br />Vīzija<br />Sadarbība prasību definēšanā<br />Nepieciešamā dokumentācija<br />Minimāla birokrātija<br />Pieņemšanas process<br />
    • 7.
    • 8.
    • 9. Sadarbība starp IT un biznesu<br />Komunikācija<br />Vīzija<br />Sadarbība prasību definēšanā<br />Nepieciešamā dokumentācija<br />Minimāla birokrātija<br />Pieņemšanas process<br />
    • 10.
    • 11.
    • 12. Regulāra programmatūras piegāde<br />Demonstrācijas<br />Prioritātes<br />Gatava programmatūra ir galvenais progresa mērs<br />
    • 13. Izmaiņas<br />Prasības var mainīties<br />«bet tas nebija prasībās..»<br />
    • 14. Scrum pielietojums<br />
    • 15. Kad lietot Scrum?<br />Nepieciešams ātrs rezultāts<br />Augsta izmaiņu nepieciešamības iespēja<br />Izmaksu efektivitāte<br />Iespēja zaudēt finansējumu<br />
    • 16. Kad nevar lietot tīru Scrum?<br />Projekta sākumā precīzi jānosaka projekta tvērums, termiņš un izmaksas<br />Pasūtītāja (ne) iesaiste<br />Daudzas iesaistītās puses, kas nelieto Scrum<br />
    • 17. Scrum pielāgojumi<br />Dokumentācija kā parasti, Scrum tikai izstrādei/testēšanai<br />Dalītā dokumentācija<br />Regulāri nodevumi<br />Liela Pasūtītāja iesaiste<br />...<br />
    • 18. Scrum publiskajos iepirkumos?<br />Cilvēki pret funkcionalitāti?<br />Fiksēts budžets/termiņš<br />Iepirkums<br />Ātrs rezultāts<br />Iespēja zaudēt finansējumu<br />
    • 19.
    • 20. DPA piedāvājums<br />Scrum ieviešana<br />Autoruzraudzība<br />Konsultācijas un atbalsts<br />Iepirkumi<br />Izmantot projektos<br />
    • 21. Paldies par uzmanību!<br />Gunta Strode<br />gunta.strode@dpa.lv<br />26182739<br />

    ×