Agile nedir diye baลlarsak, Agile geleneksel proje yรถntemine alternatif olarak ortaya รงฤฑkmฤฑล daha รงok yazฤฑlฤฑm geliลtirmesinde kullanฤฑlan bir metodolojidir. Temelinde artฤฑrฤฑmlฤฑ ve dรถngรผsel olarak geliลtirme dรผลรผncesine sahiptir. รzetle Agile metodolojisi ve Scrum hakkฤฑnda genel bilgi vermeye รงalฤฑลacaฤฤฑm.
Agileโda yapฤฑlmak istenen mรผลteriye minimum eforla ve maksimum รถฤrenimle; optimum รผrรผnรผ verebilmektir. รฤrenim dendiฤinde ise risklerin azaltฤฑlmasฤฑ, ideal market riskinin alฤฑnmasฤฑ gibi konular sรถz konusu olmaktadฤฑr. Tรผm fazlarฤฑn hepsi birden markete alฤฑndฤฑ ve aslฤฑnda kullanฤฑcฤฑmฤฑzฤฑn buna ihtiyacฤฑ yoktu. Bu durumda olan hem zaman hem de insan gรผcรผ kaybฤฑdฤฑr. รok bรผyรผk bir maliyetle minimum kazanฤฑm elde edilmiล olur. Bunun yerine รผrรผnรผn kรผรงรผk bir prototipiyle ilerleyip kullanฤฑmฤฑnฤฑ incelediฤimizde ve kullanฤฑcฤฑnฤฑn ilgisine gรถre ilerlediฤimizde kazancฤฑmฤฑz รงok daha fazla olacaktฤฑr. Az รถnceki durumda, baลarฤฑsฤฑz olacak bir projeyi en baลฤฑnda fark edeceฤimiz iรงin kaynaklarฤฑmฤฑzฤฑ baลka yรถne yรถnlendirebileceฤiz. Bu durum bรผyรผk firmalar รงok bรผyรผk kayฤฑp olmayabiliyorken; yaptฤฑฤฤฑ iลi satmak zorunda, aksi takdirde yaลamฤฑna devam edemeyecek olan firmalar iรงinse gerรงek bir zorunluluktur ki ortaya รงฤฑkma sebebi de zaten budur.
Prototipin kullanฤฑcฤฑlara aรงฤฑlฤฑลฤฑ farklฤฑ steplerde olabilir. Bu aลama aลaฤฤฑdaki 3 stepโden oluลmaktadฤฑr.
- Validation
- Limited
- Production
Production adฤฑndan da anlaลฤฑlacaฤฤฑ รผzere tรผm kullanฤฑcฤฑya aรงฤฑlmฤฑล bu Release sรผrecinin son aลamasฤฑdฤฑr. Bu sebeple ona deฤinmeden diฤer iki steple devam ediyorum. Validation, aslฤฑnda Learning Release olarak da tanฤฑmlanabilir. 1 ya da 2 kere yapฤฑlabilir. 2 ya da 3 Sprintโden sonra Validation Release รงฤฑkmak zaman olarak uygundur. Bu aลamada Release iรงeriye yapฤฑlฤฑr. Amaรง bir ลeyler รถฤrenmektir. ฤฐรงeriye aรงฤฑldฤฑฤฤฑ iรงin de risk dรผลรผktรผr. 2. Aลama biraz daha ciddi bir aลamadฤฑr. Burada รผrรผn, hem iรงeriye hem dฤฑลarฤฑya aรงฤฑlmaya baลlanฤฑr. รrneฤin, bir Android uygulamasฤฑ iรงin Alpha, Beta testerlar belirlenerek belki sonrasฤฑnda Google Playโin sunduฤu Stage Rollout seรงeneฤi kullanฤฑlarak Limited Release yapฤฑlabilir. Artฤฑk รผrรผn hem iรงeriye hem dฤฑลarฤฑya aรงฤฑldฤฑฤฤฑ iรงin hem kontrol edilebilir olan hem de kontrol edilebilir olmayan kullanฤฑcฤฑdan sรถz ediyor olmuล oluruz. Bรถylece kullanฤฑcฤฑdan aldฤฑฤฤฑmฤฑz feedbacklere gรถre ilerlemiล oluyoruz.
Sรผreci anlatmaya biraz sondan baลlamฤฑล oldum ama yazฤฑlฤฑm tarafฤฑnda olanlar iรงin geliลtirme belki de en bilindik kฤฑsฤฑm sรผreci daha geniล bir รงerรงeveden aldฤฑฤฤฑmฤฑzda bu ลekilde รถzetleyebiliriz. Tabi geliลtirme en alฤฑลkฤฑn olduฤumuz bรถlรผm derken ilerlenen sรผreรง alฤฑลฤฑk olduฤumuza oranla biraz daha farklฤฑ.
Detaylara inmeden Scrum ekipleri, proje ekipleri deฤil product ekipleridir. Bu ne demektir dediฤimizde ise ลรถyle ayrฤฑmฤฑ saฤlayabiliriz. Proje ekipleri, proje yeterli para kazandฤฑrdฤฑฤฤฑnda sonlandฤฑrฤฑlฤฑrken Product ekipleri รผrรผn istenen deฤere ulaลtฤฑฤฤฑnda daฤฤฑlฤฑr. Agile’da sรผrecin kendini deฤil, รผrรผn รถnemlidir. Scrum ise en basit agile sรผreci olarak tasarlanmฤฑลtฤฑr. Product team kavramฤฑ ise Agile’ฤฑn 3. jenerasyonuyla beraber ortaya รงฤฑkmฤฑลtฤฑr. ฤฐlk jenerasyon kรผรงรผk developer takฤฑmlarฤฑndan oluลuyordu. Tรผm gรผรง developerlara ait dรผลรผncesi hakimdi. 2. jenerasyonda bunun yerini product development akฤฑลฤฑ kavram olarak yerini aldฤฑ. 3. jenerasyonda ise product ekipleri oluลmuล oldu.
Peki Scrum tam olarak nedir dersek, Scrum Agile methodlarฤฑndan biridir. Kendi kendine organize olan ekiplerden oluลur. Her 2 ya da 4 haftada bir ise bir รผrรผn ortaya รงฤฑkarฤฑlฤฑr. Scrum’da 3 rol vardฤฑr. Bunlardan ilki Product Owner’dฤฑr. Product Owner vizyonu taลฤฑyan kiลidir. Product Backlog’dan temel olarak PO sorumludur. Bir diฤeri sรผrekli bahsettiฤimiz Scrum Team‘dir. Son olarak da Scrum Master vardฤฑr. Scrum Master ekibin bir elemanฤฑ olabileceฤi gibi, ekip dฤฑลฤฑndan da olabilir. SM yรถnetici ya da proje yรถneticisi deฤildir. Agile prensipleri ve deฤerlerinin uygulanmasฤฑnฤฑ saฤlar, sรผreci takip eder. Scrum Framework’unu, rollerin en iyi nasฤฑl uygulanacaฤฤฑnฤฑ herkese รถฤretir. Hizmet elemanฤฑdฤฑr ama bunu รงay, kahve taลฤฑyan, gelip omzumuza masaj yapan kiลi olarak dรผลรผnmemeliyiz. Ekibin dedike bir ลekilde, dฤฑล etkenlerden etkilenmeden รงalฤฑลmaya devam etmesini saฤlar. Aynฤฑ zamanda hem ekip elemanlarฤฑ hem de PO iรงin Change Agent olarak gรถrev alฤฑr. Riski yรถnetir. Sรผreรงte bir sorun gรถrdรผฤรผnde mรผdahale eder. Scrum ekipleri ortalama 5-9 arasฤฑ sayฤฑda kiลiden oluลur.
Scrum’da 5 tip toplantฤฑ vardฤฑr.
- Sprint Planning (Her Sprint’e baลlarken)
- Daily Stand-ups (Her gรผn max 15 dk, ayakta)
- Backlog Grooming(1 sprint’de 2 ya da 4 defa)
- Sprint Demo (Sprint sonunda)
- Sprint Retrospective(Sprint sonunda , sรผreci deฤerlendirmek iรงin)
Sรผreรง Product Backlog‘un oluลturulmasฤฑyla baลlamaktadฤฑr. Product backlog kabaca development ekibi iรงin iลlerin รถnceliklendirildiฤi bir todo listesidir. Product Backlog’un oluลturulmasฤฑnda temel gรถrev Product Owner’a dรผลmektedir ama bu sรผreรงte Development Team’in de fikrini alabilir. Her bir Product Backlog รงok sayฤฑda PBI (Product Backlog Item) iรงermektedir.Her bir PBI birden รงok Epic, Feature, Story ve Task’dan oluลuyor olabilir. Bir รผrรผn 1-7 epic’e sahip olabilir. Her bir epic, feature’lara sahiptir. Her bir feature iรงin de รงoklu sayฤฑda story’ler ve bu storylere de kabul kriterleri hazฤฑrlarฤฑz. Kabul kritlerini aynฤฑ zamanda test case’leri gibi de dรผลรผnebiliriz. PBI’yฤฑ scope olarak dรผลรผnebiliriz. Her bir PBI ise รงok sayฤฑda Sprint Backlog iรงermektedir. Sprint Backlog’lar Sprint Planning sonrasฤฑnda oluลur. Sprint Planning sฤฑrasฤฑnda PO neyi neden istediฤini sรถyler. Team bu istekleri analiz eder ve sonrasฤฑnda PO ve Team arasฤฑnda bir anlaลma kararฤฑ alฤฑnฤฑr. Bรถylece Sprint’e baลlanabilir.
Sprint planning’de yazฤฑlan her bir story’nin ne kadar sรผrede tamamlanacaฤฤฑnฤฑ ya da zorluk derecesini รถlรงรผmlemek iรงin estimation yapฤฑlฤฑr. Her bir story’ye story pointler verilir. Burada puanlama poker kartlarฤฑ ya da fibonacci numaralarฤฑyla yapฤฑlabilir. Story’lerden biri ortalama zorlukta olarak seรงilir ve mesela 5 puan verilir. Diฤer story’lere ise buna oranla bir puan verilir. Estimation yapฤฑlฤฑrken ise, mesela poker kartlarฤฑnฤฑz kullandฤฑฤฤฑmฤฑzฤฑ varsayalฤฑm. Story’ye tรผm ekip รผyeleri bakar sonrasฤฑnda herkes dรผลรผndรผฤรผ zorluk iรงin bir poker kartฤฑ seรงer. 3 dk sonunda herkes poker kartlarฤฑnฤฑ gรถsterir. Eฤer deฤerler birbirine yakฤฑnsa ortalama bir sayฤฑda konsensusa varฤฑlabilir. Ya da en dรผลรผk ve en yรผksek kartฤฑ gรถsterenler sebeplerini aรงฤฑklarlarlar ve tekrar oylama yapฤฑlฤฑr. Burada toplu bir karar alฤฑnmasฤฑ yerine herkesin dรผลรผndรผฤรผ rakamฤฑ gรถstermesinin sebebi, farklฤฑ bakฤฑล aรงฤฑlarฤฑnฤฑn farklฤฑ riskleri dรผลรผnebilme ihtimalidir.
Yukarda yer alan chart, cone of uncertainity’dir. Estimationlarฤฑ yaparken eฤer daha รถncesinden hiรง bilgi ve deneyimimiz yoksa, hiรง bir analiz yapma ลansฤฑmฤฑz olmadฤฑysa, verdiฤimiz estimationlarฤฑn da gerรงekรงiliฤi sรถz konudur deฤildir. 5 story pointlik bir iลe 400 verme ihtimalimiz vardฤฑr. Eฤer biraz analiz yapma ลansฤฑmฤฑz olduysa ya da kฤฑsmen bir bilgi sahipbiysek, yukarฤฑdaki eฤride orta kฤฑsฤฑmlara denk gelen bir tahminleme yaparฤฑz. Hem bilgi sahibiysek hem de analizimi yaptฤฑysak eฤer yaptฤฑฤฤฑmฤฑz estimation son kฤฑsฤฑmlara denk gelmektedir.
Sprint’de her gรผn max 15 dk’lฤฑk stand-up meetingler yapฤฑlฤฑr. Bu stand-up meetinglerin max 15 dk ayakta olmasฤฑnฤฑn aslฤฑnda sebepleri vardฤฑr. Ayakta olduฤu iรงin kiลi kendisini รงok rahat hissetmez ve bรถylece de kฤฑsa sรผre iรงerisinde anlatmak istediklerini bitirmek ister. Max 15 dk denmesinin sebebi ise, belli bir ลeye belli bir noktadan fazla zaman ayฤฑrdฤฑฤฤฑmฤฑzda verimde artma deฤil baลlangฤฑรงta dรผzleลme ardฤฑndan da dรผลme baลlar. Eฤer yarฤฑm sa konuลulacak denseydi de en az yarฤฑn sa konuลulurdu. Her gรผn yapฤฑlan bu standup meetinglerde son 24 sa iรงerinde bu Sprint’den amacฤฑna ulaลmak iรงin ne yaptฤฑm. Bundan sonraki 24 sa iรงerisinde Sprint’in amacฤฑna ulaลmak iรงin ne yapabilirim. Beni engelleyen herhangi bir ลey var mฤฑ gibi konulardan oluลur.
Her bir Sprint’de 1 ya da 2 kere Backlog Refinement(Grooming) yapmak faydalฤฑdฤฑr. Backlog Refinement’lar PO, SM, DT ve gerekliyse uzmanlarฤฑn katฤฑlฤฑmฤฑyla saฤlanฤฑr. Herkes iรงin uygun bir zamanda yapฤฑlabilir. รzel bir zamanda yapฤฑlmasฤฑna gerek yoktur. 2 haftalฤฑk bir Sprint iรงin, 60, 90 dk’lฤฑk bir toplantฤฑ yeterlidir. Temel olarak PO’yu aydฤฑnlatmak iรงin yapฤฑlฤฑr. Bu toplantฤฑda bazฤฑ story’lerde deฤiลiklik bรถlรผnmeler gerรงekleลebilir. Yenileri eklenebilir.
Sprint Planning’le aรงฤฑlฤฑลฤฑ yaptฤฑk. Artฤฑkdan Daily Standup’lar ve Backlog Refinement’lar yaptฤฑk. Her bir Sprint’in sonunda ise Sprint Review (Actual Performance), Sprint Demo(Actual Software Features) ve Sprint Retrospective (Process Improvement)yapฤฑlmalฤฑdฤฑr.
Peki bir Sprint’de iลimizi tamamladฤฑฤฤฑmฤฑzฤฑ, amacฤฑmฤฑza ulaลtฤฑฤฤฑmฤฑzฤฑ nasฤฑl รถlรงeriz. Sprint’e ilk baลlarken yapฤฑlmasฤฑ gereken bir Definition of Done tanฤฑmฤฑ vardฤฑr. DoD’da yer alan metrikler ise,
- Forecast vs. Accepted
- Sprint iรงerisinde bulunan bug’lar
- Outstanding buglar
- Build’in baลarฤฑsฤฑz olma sayฤฑsฤฑ
- Ekibin ivmesi
- Burndown-Burnup chart’lar
Dev. tamamlandฤฑ, test tamamlandฤฑ, PO tarafฤฑndan kabul edildi. Release Planning’i ise yazฤฑmฤฑn baลฤฑnda anlanmฤฑลtฤฑm.
Umarฤฑm genel bir fikir sahibi olabilmenizi saฤlamฤฑลฤฑmdฤฑr. ฤฐyi hafta sonlarฤฑ ๐
2 responses to “Let’s Talk About Agile!”
Reblogged this on burcugeneci and commented:
Agile ve Scrum hakkฤฑnda kฤฑsa รถz anlaลฤฑlฤฑr bilgilerle faydalฤฑ bir yazฤฑ
[…] kฤฑsa eฤitimin ardฤฑndan, genel kurallarฤฑn, konseptlerin, iลleyiลin neler olduฤuna dair bir yazฤฑ yazmฤฑลtฤฑm. ลimdi 1 yฤฑllฤฑk deneyim, Agile Yazฤฑlฤฑm Geliลtirme Sรผreรงleriย รผzerine bir MBA […]