Agile
Geriausia užsakovo-vykdytojo santykių iliustracija
• Pigs and chicken
– Chicken – užsakovas: naudotojai, vadovai
– Pigs – vykdytojas: produkto savininkas, komanda
Waterfall vs. Agile (waterfall istorija)
• Waterfall yra paklydimas!
• Waterfall kaip sąvoka (ir kaip siūlomas IS
įgyvendinimo būdas) atsirado iš Winston W.
Royce straipsnio
– Pats W.W.Royce apie Waterfall sakė, kad jį ne taip
suprato, o jo paties nuomonė yra: „I believe in this
concept, but the implementation described above is
risky and invites failure.“ (iš to paties straipsnio)
• O tapo įteisintas dėl žmogiško poreikio turėti
lengvai suprantamą (racionalų) sprendimą:
vs.
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: turėti racionalų procesą neįmanoma, tai tenka
imituoti jį
• 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žiūrėti prezentacija:
Real Software Engineering - Glenn Vanderburg
Projektų valdymas
• Projektas = karo lauko ligoninė
– Nesaugo nuo kulkų, bet nuo dulkių saugo
• Projekto paskirtis – suteikti apsaugą nuo
neigiamų įtakų organizacijos viduje:
– Tikslo pametimo
– Motyvacijos stokos
– Nenoro bendradarbiauti
– Finansavimo trūkumo
• Projekto valdymo priemonės?
Waterfall vs. Agile (projektų valdymas)
• Kiek teisingas teiginys, kad tradicinis
projekto valdymas reikalauja daug
nereikalingų pastangų?
• Neapsigaukite: ne tradicinis, o blogas projekto
valdymas!
– Apie tai jau kalbėjome Tema10.ppt
• Ar Scrum master yra projekto vadovas?
• Kas yra projekto vadovas Scrum projekte?
Waterfall vs. Agile (projektų valdymas)
• Projekto sėkmės supratimas
Sėkmės faktorius
Tvarkaraštis
Naujas apibrėžimas
61% mano, kad svarbiau sistemą pateikti ne tiek laiku, o
kiek tada, kai ji parengta diegimui
87% mano, kad tikrųjų suinteresuotų šalių poreikių
Apimtis patenkinimas svarbiau nei atitikimas reikalavimų
specifikacijai
Kaina
Kokybė
79% mano, kad sistemos atsipirkimo (ROI) optimizavimas
yra svarbiau nei sistemos sukūrimas biudžeto ribose
87% mano, kad aukšta kokybė svarbiau nei sistemą
pateikti laiku ir už planuotą kainą
75% mano, kad psichologiškai ir fiziologiškai sveika darbo
Darbuotojai aplinka ir darbo sąlygos yra svarbiau nei sistemą pateikti
laiku ir už planuotą kainą
Nuomonės cituojamos iš http://drdobbs.com/architecture-and-design/202800777
Waterfall vs. Agile (projektų valdymas)
• Projekto sėkmės faktoriai valdiškuose IT pirkimuose
(iš United States Government Accountability Office 2011 spalio
mėn. ataskaitos):
Sėkmės 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
Agile
• Geriausia matyta Scrum prezentacija:
Jurgen Appelo The Zen of Scrum
Waterfall vs. Agile (reikalavimų valdymas)
Nusistebėjimai, klausantis Agile entuziastų:
• User-story pavyzdys: „Aš kaip klientas
norėčiau turėti galimybę išleisti sukauptus
lojalumo taškus?“
– ar čia user story?
• Ar tikrai organizacijos darbuotojai (užsakovai)
nežino, ko jiems reikia?
O gal IT žmonės nemoka išgirsti, ko jiems
reikia?
• Kas yra Product owner?
Kaip tokį užsiauginti?
Waterfall vs. Agile (reikalavimų valdymas)
• Agile vs. Tradicinė projektų valdymo terminologija:
• Iš verto perskaityti palyginamojo straipsnio:
http://herdingcats.typepad.com/my_weblog/2011/07/c
onnecting-the-dots-in-agile.html
Kanban
• Vizualiai Kanban gali atrodyti kaip Scrum be
iteracijų
• Tačiau Kanban esmė – sutelkti žmonių dėmesį,
ribojant WIP (atliekamų vienu metu užduočių)
kiekį
– To išdava: užtikrinamas pastovus atliekamų darbų
srautas
– Scrum siekia to paties tikslo, tačiau ne srauto
ribojimu, o darbo užduočių paketavimu į iteracijas
(t.p. žr. Why Kanban Board is a Value Stream Map
but a Scrum Board Isn’t)
Kanban principai
First adopt foundational
principles:
Then:
• Start with what you
do now
• Limit WIP
• Agree to pursue
incremental,
evolutionary change
• Visualize the workflow
• Manage Flow
• Make Process Policies
Explicit
• Improve
• Respect the current
Collaboratively (using
process, roles,
models & the scientific
responsibilities & titles
method)
Šaltinis: David J. Andersson „The principles“, iš:
http://agilemanagement.net/index.php/Blog/the_princi
ples_of_the_kanban_method/
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: OnePiece Continuous Flow
Scrum board realizacija
• Projektorius
• Kamera su judesio jutikliu
• RFID kortelės
• Sinchronizacija su Jira
• Veiksmas:
http://www.youtube.com/user/olekristensendk
• Technologijos pristatymas:
http://video.demodag.org/video/909052/voda
fone-scrumboard
LEAN software development vertinimas
• Jie mano, kad pritaikę LEAN požiūrį, padarė
savo procesą atitinkantį 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 significance 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 fit well with existing corporate standards.
Fin!