Agile

1
Agile
2
Geriausia užsakovo-vykdytojo santykiu iliustracija

• Pigs and chicken
• Chicken užsakovas naudotojai, vadovai
• Pigs vykdytojas produkto savininkas, komanda

3
Waterfall vs. Agile (waterfall istorija)

• Waterfall yra paklydimas!
• Waterfall kaip savoka (ir kaip siulomas IS
  igyvendinimo budas) atsirado iš Winston W. Royce
  straipsnio
• Pats W.W.Royce apie Waterfall sake, kad ji ne
  taip suprato, o jo paties nuomone yra I believe
  in this concept, but the implementation described
  above is risky and invites failure. (iš to
  paties straipsnio)
• O tapo iteisintas del žmogiško poreikio tureti
  lengvai suprantama (racionalu) sprendima
• vs.

4
Waterfall vs. Agile (waterfall istorija)

• David L. Parnas et al. A Rational Design Process
  How and Why to fake it
• For all of these reasons, the picture of the
  software designer deriving his design in a
  rational, errorfree, way from a statement of
  requirements is quite unrealistic. No system has
  ever been developed in that way, and probably
  none ever will.
• Išeitis tureti racionalu procesa neimanoma, tai
  tenka imituoti ji
• F.Brooks, The Design of Design
• The Rational Model may seem naive to us today.
  But it is a very natural model for people to
  conceive.
• Išsamiau privaloma pasižiureti prezentacija
  Real Software Engineering - Glenn Vanderburg

5
Projektu valdymas

• Projektas karo lauko ligonine
• Nesaugo nuo kulku, bet nuo dulkiu saugo
• Projekto paskirtis suteikti apsauga nuo
  neigiamu itaku organizacijos viduje
• Tikslo pametimo
• Motyvacijos stokos
• Nenoro bendradarbiauti
• Finansavimo trukumo
• Projekto valdymo priemones?

6
Waterfall vs. Agile (projektu valdymas)

• Kiek teisingas teiginys, kad tradicinis projekto
  valdymas reikalauja daug nereikalingu pastangu?
• Neapsigaukite ne tradicinis, o blogas projekto
  valdymas!
• Apie tai jau kalbejome Tema10.ppt
• Ar Scrum master yra projekto vadovas?
• Kas yra projekto vadovas Scrum projekte?

7
Waterfall vs. Agile (projektu valdymas)

• Projekto sekmes supratimas

Sekmes faktorius Naujas apibrežimas
Tvarkaraštis 61 mano, kad svarbiau sistema pateikti ne tiek laiku, o kiek tada, kai ji parengta diegimui
Apimtis 87 mano, kad tikruju suinteresuotu šaliu poreikiu patenkinimas svarbiau nei atitikimas reikalavimu specifikacijai
Kaina 79 mano, kad sistemos atsipirkimo (ROI) optimizavimas yra svarbiau nei sistemos sukurimas biudžeto ribose
Kokybe 87 mano, kad aukšta kokybe svarbiau nei sistema pateikti laiku ir už planuota kaina
Darbuotojai 75 mano, kad psichologiškai ir fiziologiškai sveika darbo aplinka ir darbo salygos yra svarbiau nei sistema pateikti laiku ir už planuota kaina
Nuomones cituojamos iš http//drdobbs.com/architec
ture-and-design/202800777
8
Waterfall vs. Agile (projektu valdymas)

• Projekto sekmes faktoriai valdiškuose IT
  pirkimuose (iš United States Government
  Accountability Office 2011 spalio men.
  ataskaitos)

Sekmes faktorius
1 Program officials were actively engaged with stakeholders.
2 Program staff had the necessary knowledge and skills.
3 Senior department and agency executives supported the programs.
4 End users and stakeholders were involved in the development of requirements.
5 End users participated in testing of system functionality prior to formal end user acceptance testing.
6 Government and contractor staff were stable and consistent.
7 Program staff prioritized requirements.
8 Program officials maintained regular communication with the prime contractor.
9 Programs received sufficient funding.
Šaltinis http//www.gao.gov/new.items/d127.pdf
9
Agile

• Geriausia matyta Scrum prezentacijaJurgen
  Appelo The Zen of Scrum

10
Waterfall vs. Agile (reikalavimu valdymas)

• Nusistebejimai, klausantis Agile entuziastu
• User-story pavyzdys Aš kaip klientas noreciau
  tureti galimybe išleisti sukauptus lojalumo
  taškus? ar cia user story?
• Ar tikrai organizacijos darbuotojai (užsakovai)
  nežino, ko jiems reikia?O gal IT žmones nemoka
  išgirsti, ko jiems reikia?
• Kas yra Product owner?Kaip toki užsiauginti?

11
Waterfall vs. Agile (reikalavimu valdymas)

• Agile vs. Tradicine projektu valdymo
  terminologija

• Iš verto perskaityti palyginamojo straipsnio
  http//herdingcats.typepad.com/my_weblog/2011/07/c
  onnecting-the-dots-in-agile.html

12
Kanban

• Vizualiai Kanban gali atrodyti kaip Scrum be
  iteraciju
• Taciau Kanban esme sutelkti žmoniu demesi,
  ribojant WIP (atliekamu vienu metu užduociu)
  kieki
• To išdava užtikrinamas pastovus atliekamu darbu
  srautas
• Scrum siekia to paties tikslo, taciau ne srauto
  ribojimu, o darbo užduociu paketavimu i
  iteracijas(t.p. žr. Why Kanban Board is a Value
  Stream Map but a Scrum Board Isnt)

13
Kanban principai

• First adopt foundational principles
• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles,
  responsibilities titles

• Then
• Visualize the workflow
• Limit WIP
• Manage Flow
• Make Process Policies Explicit
• Improve Collaboratively (using models the
  scientific method)

Šaltinis David J. Andersson The principles,
iš http//agilemanagement.net/index.php/Blog/the_
principles_of_the_kanban_method/
14
Kanban

• Aleksei Kovaliov Scrum vs. Kanban
• Tomas Bjorkholm Kanban kick-start (v2)
• Pavel Brodzinski Kanban story
• Mattias Skarin 10 kanban boards and their context
• Jim Coplien An Alternative to Kanban One-Piece
  Continuous Flow

15
Scrum board realizacija

• Projektorius
• Kamera su judesio jutikliu
• RFID korteles
• Sinchronizacija su Jira
• Veiksmas http//www.youtube.com/user/olekristense
  ndk
• Technologijos pristatymas http//video.demodag.or
  g/video/909052/vodafone-scrumboard

16
LEAN software development vertinimas

• Jie mano, kad pritaike LEAN požiuri, padare savo
  procesa atitinkanti CMMI L4 Lean Software
  Management BBC Worldwide Case Study
• This case study examines how the lean ideas
  behind the Toyota production system can be
  applied to software project management. It is a
  detailed investigation of the performance of a
  nine-person software development team employed by
  BBC Worldwide based in London. The data collected
  in 2009 involved direct observations of the
  development team, the kanban boards, the daily
  stand-up meetings, semistructured interviews with
  a wide variety of staff, and statistical
  analysis. The evidence shows that over the
  12-month period, lead time to deliver software
  improved by 37, consistency of delivery rose by
  47, and defects reported by customers fell 24.
  The signi?cance of this work is showing that the
  use of lean methods including visual management,
  team-based problem solving, smaller batch sizes,
  and statistical process control can improve
  software development. It also summarizes key
  differences between agile and lean approaches to
  software development.
• The conclusion is that the performance of the
  software development team was improved by
  adopting a lean approach. The faster delivery
  with a focus on creating the highest value to the
  customer also reduced both technical and market
  risks. The drawbacks are that it may not ?t well
  with existing corporate standards.

17
Fin!