Transcript Slide 1
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!