GitHub, kod geliştirme, işbirliği ve sürüm kontrolü için kullanılan popüler bir platformdur.
GitHub, geliştiricilerin kodlarını saklamalarına, işbirliği yapmalarına, kod incelemeleri yapmalarına ve projelerini yönetmelerine yardımcı olan bir web tabanlı platformdur. Ayrıca açık kaynak projelerin paylaşılmasına ve topluluk katılımına olanak sağlar. GitHub, projelerin sürüm kontrolünü yapmak için Git adlı dağıtık bir sürüm kontrol sistemi üzerine kurulmuştur.
- GitHub'a gitmek için bir web tarayıcısı açın ve "https://github.com" adresine gidin.
- GitHub ana sayfasında, sağ üst köşede "Sign up" veya "Sign up for GitHub" gibi bir seçenek bulunmalıdır. Bu seçeneğe tıklayın.
- Kayıt formunu doldurun. Bu form, adınızı, kullanıcı adınızı, e-posta adresinizi ve şifrenizi içerir. Ayrıca, bir profil resmi eklemek isteyip istemediğinizi seçebilirsiniz.
- "Verify" veya "I'm not a robot" gibi güvenlik doğrulama adımlarını geçtikten sonra, "Create account" veya "Sign up for GitHub" gibi bir düğme ile kayıt işlemini tamamlayın.
- Kayıt işlemi tamamlandığında, GitHub hesabınıza giriş yapmanız gerekecektir. Kullanıcı adınızı ve şifrenizi kullanarak giriş yapabilirsiniz.
- İlk kez giriş yaptığınızda, GitHub size ilgi alanlarınıza ve projelere göz atmanızı, projelere katılmanızı veya kendi projelerinizi oluşturmanızı öneren bir yol haritası sunacaktır.
GitHub hesabınızı oluşturduktan sonra, projeler oluşturabilir, kodları depolayabilir, işbirliği yapabilir ve diğer geliştiricilerle iletişim kurabilirsiniz. GitHub'ın sunduğu hizmetlerin büyük bir kısmı ücretsizdir ve açık kaynak projeler için özel fırsatlar sunar. Özel projeler ve daha fazla depolama alanı gibi ek özelliklere erişmek için bir ücretli plana da kaydolabilirsiniz.
Bu kısımda sektörde yazılımcı olarak çalışan birinin gözünden Agile'ı tanıyacaksınız. Ama öncelikle temel kavramlardan başlayalım!
Proje yönetimi, belirli bir hedefi veya sonucu elde etmek için planlama, uygulama, takip etme ve kontrol etme sürecini içeren disiplinlerarası bir yaklaşımdır. Proje yönetimi, kaynakları etkili bir şekilde kullanarak, zaman çizelgelerine ve bütçelere uyarak belirli bir sonuca ulaşmak için kullanılan bir yönetim disiplinidir. Proje yönetimi, bir organizasyonun veya bireyin hedeflerini, iş akışını ve süreçlerini daha etkili bir şekilde yönlendirmesine yardımcı olabilir.
Proje yönetimi genellikle aşağıdaki temel adımları içerir:
Proje Tanımı ve Planlama: Proje hedefleri, kapsamı, bütçesi, kaynakları ve zaman çizelgesi gibi ana unsurları içeren proje planının oluşturulması.
Kaynakların Tahsisi: İhtiyaç duyulan insan kaynakları, malzemeler ve finansmanın belirlenmesi ve tahsis edilmesi.
Uygulama ve İzleme: Proje planının uygulanması ve proje ilerlemesinin izlenmesi. Bu aşamada herhangi bir sorunun tanımlanması ve gerekirse düzeltilmesi gerekir.
Kontrol ve Raporlama: Proje ilerlemesini sürekli olarak izleyerek herhangi bir sapmanın tespit edilmesi ve proje paydaşlarına düzenli raporlar sunulması.
Sonlandırma ve Değerlendirme: Projenin başarıyla tamamlanması, sonuçların değerlendirilmesi ve projenin sonlandırılması.
Proje yönetimi, her türlü proje için geçerli olabilir, örneğin inşaat projeleri, yazılım geliştirme projeleri, pazarlama kampanyaları veya organizasyonel değişiklikler gibi farklı türdeki projeler için kullanılır. Proje yönetimi, hedeflerin daha verimli bir şekilde ulaşılmasını sağlar ve riskleri minimize etmek için önemli bir araçtır. Birçok farklı proje yönetimi metodolojisi ve araçları bulunmaktadır, örneğin PMP (Project Management Professional), PRINCE2 ve Agile gibi. Bu metodolojiler, farklı projelerin ihtiyaçlarına ve gereksinimlerine uygun olarak seçilir.
Proje ilerlemesinin izlenmesi ve kontrol edilmesi, projenin sonlandırılmasına kadar devam eder.
ANKARA ÜNİVERSİTESİ ÖĞRENCİLERİ
ULUDAĞ ÜNİVERSİTESİ ÖĞRENCİLERİ
Geleneksel Proje Yönetimi: Geleneksel proje yönetimi, proje planlamasını ayrıntılı bir şekilde yapar, projeyi baştan sona sırasıyla işlemleri tamamlamak için tasarlar. Bu yaklaşım, özellikle inşaat projeleri gibi büyük, karmaşık projeler için uygundur. Waterfall model, bu yaklaşımın bir örneğidir.
Agile Proje Yönetimi: Agile, özellikle yazılım geliştirme projeleri için yaygın olarak kullanılan bir esnek proje yönetimi yaklaşımıdır. Agile, proje sürecini kısa dönemler halinde (sprintler) böler ve esneklik sağlar. Scrum, Kanban ve Lean gibi metodolojiler Agile yaklaşımının örnekleridir.
Scrum: Scrum, Agile yaklaşımının bir uygulama biçimidir ve yazılım geliştirme projeleri için popülerdir. Scrum, işbirliğine dayalı, yinelemeli bir yaklaşımı benimser ve belirli bir süre içinde (genellikle 2-4 hafta) çalışan işlevsel parçaların üretilmesini hedefler.
Kanban: Kanban, işin sürekli akışını izleyen ve yönlendiren bir görsel yönetim sistemidir. Proje yönetiminde, Kanban tahtaları kullanılır ve görevler veya işler kartlar üzerinde temsil edilir. Bu yaklaşım, iş akışını daha verimli hale getirmek için kullanılır.
Lean Proje Yönetimi: Lean, atıl kaynakları ve iş süreçlerini en aza indirmeyi hedefleyen bir yönetim felsefesidir. Bu yaklaşım, verimliliği artırmak, israfı azaltmak ve değeri artırmak için kullanılır.
PRINCE2 (Projects IN Controlled Environments): PRINCE2, İngiltere'de geliştirilen bir proje yönetimi metodolojisidir. Süreç odaklıdır ve proje yaşam döngüsünü ayrıntılı bir şekilde tanımlar.
Hybrid (Karışık) Yaklaşımlar: Bazı projeler, farklı metodolojilerin birleşimiyle yönetilebilir. Bu, "hybrid" proje yönetimi olarak adlandırılır. Örneğin, bir proje hem geleneksel proje yönetimi hem de Agile prensiplerini içerebilir.
Proje yönetimi yaklaşımı, projenin özelliğine ve organizasyonun ihtiyaçlarına bağlı olarak seçilir. İşin büyüklüğü, karmaşıklığı, süresi, kaynakları ve paydaşların talepleri, hangi proje yönetimi yaklaşımının kullanılacağını etkileyebilir.
Çok uzak değil belki son çeyrek asırdır proje denildiğinde tanım olarak , baştan sona planlanan ve bu planlara sıkı sıkıya bağlı kalınan bir dizi süreç aklımıza gelirdi. Yazımızın konusu bu değil tabii ki ama karşılaştırma amacıyla Waterfall (Şelale Döngüsü) modelinden de sık sık bahsedeceğiz. Dijital hayatın hızlanması ve rekabet gibi bileşenler hepimiz gibi proje yönetim şekillerini de etkiledi. Çoğumuz değişimin bir parçası olmak için kolları sıvadık. Bu yazımda değişime ayak uyduran veya uydurmaya çalışan hemen hemen bütün ekiplerin kullandığı bir yöntem olan Agile(Çevik) metodolojiler hakkında toparladığım notlarımı sizlerle paylaşacağım.
Bu yazıda özetle Agile süreçlerde en çok duyduğumuz veya duyacağımız konu başlıklarına değineceğiz. Teorik bilgileri pratik örneklerle destekleyip Agile’yı doğru kullanıyor muyuz noktasında kendimizi sorgulayacak ve bilgilerimizi pekiştireceğiz.
Baştan her şeyin planlandığı şelale(Waterfall) modelinde hangi zaman diliminde hangi adımın atılacağı ve dolayısıyla neyin ne zaman olacağı net olarak belirtilir. Fazlar ona göre en baştan planlanır ve bu işleyiş dışına pek çıkılmaz. Waterfall işe yarayan bir yöntemdir. Senelerce de çoğu firmadaki ekiplere rehber olmuştur. Fakat teknolojinin çok hızlı değişmesi, internetin hayatımıza girmesi, uzaktan çalışan ekipler, projelerin ömür döngülerindeki belirsizlikler gibi etkenlerden dolayı, ürün ya da hizmeti baştan sona kadar net tanımlayamadığımız noktalar oluşmaya başladı. Çoğu noktada keskin kararlar alınamadığı durumlar olabilir ve ekip üyeleri proje geliştirilirken başlangıçta kullanmaya başladıkları yöntemleri, projenin ilerleyen safhalarında değiştirme ihtiyacı duyulabilir. Bu durumlarda Waterfall ile ilerlemek pek mümkün değildir. Waterfall yöntemde demin de söylediğimiz gibi yapılan iş baştan planlanır. Ürün veya hizmet çıktısı ise en sonda ortaya konur.
Agile ise; “Tabloyu en azından kara kalem de olsa duvara asayım, geri kalan renklendirme işlemlerini sonradan yaparım.” şeklinde bir yaklaşım sunar. Müşteriye değeri aşamalı olarak sunabilmek önemli bir noktadır.
Manifestonun çıkışı 2001 yılında yazılım ağırlıklı meşhur topluluktan çıkmıştır. Örneklendirme bir yazılım projesi üzerinden gerçekleştirmiştir. Yazılım projelerinde projeyi en baştan planlayıp sonuna kadar bu plandan sapmadan ilerlesek bile sonuçta başta tasarlanan amaçtan farklı bir noktaya ulaşmış olabilir. En kötüsü de bu sorunu son ana kadar fark edememe halidir. Projeyi geliştiren kişiler kendi yöntemleriyle aralarda teslim ederek, değer koyarak ilerlemelidir. Bu strateji takıma hız kazandırır ve motive eder. Agile Manifesto da tam olarak bu ihtiyaçtan ortaya çıkmıştır. Scrum’ın kurucularından Jeff Sutherland de bu manifestonun imzalayıcıları arasındadır. (Jeff Sutherland’in “Scrum iki katı işi yarı zamanda yapma sanatı” kitabını da tavsiye ederim. :))
Resimlerde gördüğümüz takımlar Amerikan Futbolu ve Curling takımlarıydı. Görüldüğü üzere bu iki sporda da takımlar, oyuncuların birlik olup değer katmasıyla başarıya ulaşabilir. Açıkçası Amerikan Futbolu ve Curling ile çok ilgilenmiyor ve takip etmiyorum. En sevdiğim spor basketbol ve ondan örnek verebilirim. Üçlük sayı atışı dediğimizde aklımıza gelenler elbette ki yakın tarihte Golden State Warriors’un yıldız oyuncusu Stephen Curry. Biraz daha geçmişe gidersek Ray Allen ve Reggie Miller’ı da tabii ki göz ardı edemeyiz. Basketbolla yakından ilgilendiğim zamanlarda üçlük sayı atışını hep bir şekilde yeteneğe bağlardım ancak izlediğim bir belgeselde oyuncuların üçlük sayı isabet yüzdelerini arttırabilmek için disiplinli ve planlı bir şekilde çalıştıklarının farkına vardım. Aslına bakarsanız eski zamanlarda üçlük sayı atışı o kadar da kıymetli değilmiş, daha doğrusu üçlük sayı atışı kavramı bulunmuyormuş. Sonraları birçok oyuncu potaya hayli uzaktan kaydettikleri sayılarla maçları çevirmeye başlayınca üçlük sayı atışı kavramı basketbol terimlerine dahil olmuş,yaygınlaşmış ve yaygınlaştıkça da oyuncular bunun üzerine çalışmalar yapmaya yoğunlaşmışlardır. Buradan Agile’a nasıl geçeceğimi merak ediyorsunuz tabii.Her şey de olduğu gibi Agile ekiplerde de başarının kilit noktası doğru ve planlı çalışmaktır. Konuya Agile açısından yaklaşmak için Golden State Warriors oyuncularının durumunu bir inceleyelim derim. Golden State Warriors takımında herkes yapması gereken görevi, üzerine düşen sorumluluğu biliyor. Örneğin; çoğunlukla üç sayılık atışları ile anılan Stephen Curry, sayı isabeti düşük olmasına rağmen her maçta sürekli üçlük deneseydi ne olurdu? Peki takımın başarılı forveti olan Draymond Green, savunma yapmak yerine sürekli dışarıdan sayı kaydetmeyi deneseydi bu durum takımı etkiler miydi? Bu sorulara çoğumuzun verebileceği cevapları bir kelimede toparlayabilseydik eğer herhalde bu kelime, “Başarısızlık” olacaktır çünkü basketbol bir takım oyunudur. Basketbolda da tıpkı Agile ekiplerde olduğu gibi herkesin bir görev tanımı vardır ve oyuncular arasındaki görev dağılımı maç öncesinde gerçekleştirilir. Agile, takımların kendilerine verilen görevlere istinaden doğru ve planlı bir şekilde çalışmasını hedefler. Tabii ki Agile ekiplerde de,tıpkı basketbol maçlarında olduğu gibi, takım üyelerinin sahip olduğu görev tanımları dışında diğer arkadaşlarına destek olması gereken durumlar olabilir ama unutmayın ki bu da oyunun bir parçasıdır. :)
Scrum da grupların bir takım halinde topu istenilen hedefe götürürken birlikte çabaladıklarını gösterir. Amerikan futbolunda amaç, topun karşı tarafa geçmesini engellemektir ve o sırada takımdan kimse bireysel egosunu düşünmez. Topa sahip olan arkadaşın hedefe ulaşması için onu korur ve etrafında dururlar. Agile’da da belli bir hizmeti müşteri veya son kullanıcıya ekip olarak sürekli paslaşarak teslim etmek hedef alınır. Scrum kavramı da 19. yüzyılın ilk yarısında İngiltere’de kurulan birebir temasa dayalı bir takım oyunu olan Rugby’den gelmektedir. Agile kavramında da ,çoğu takım oyununda olduğu gibi, hedefe ulaşana kadar sürekli yeniden yön verme ve senkron olarak çalışma amaçlanır. Agile’ın normal proje yönetiminden farklılaştığı ilk nokta burasıdır. Agile kısa döngülerle değeri ortaya koymak üzerine oluşturulan bir felsefedir. Günümüzde bu felsefeyi uygulayıp Scrum’ı benimseyen birçok kurum ve kuruluş vardır. Bunlara örnek olarak Google,Apple,Facebook,Yahoo,Spotify,Adobe,AirBnB örnek olarak verilebilir. Agile olmak için;
- Agile doğru önceliklendirmelerle alınmış işlerin doğru şekilde parçalanarak işlenmesini ve iterasyon sonunda müşteri için değer olarak çıktı haline getirilmesini önemser.
- Sürekli iyileştirmeye önem verilmelidir.
- Paydaşların dikkate alınması önemlidir.
- Metodolojinin amaçlarından birisi takımın eksiklerini görüp kendisini iyileştirme imkanı yaratması ve buna bağlı olarak verimini arttırmaya çalışmasıdır.
- Adapte edilebilir planlama nasıl yapılmalı ? sorusuna cevap verilebilmelidir çünkü Agile yeniden yön vermeyi esas alır. Baştan sona kadar belirlenen bir yol yoktur. Yolun çizilmesinde müşterinin iterasyon bazlı istekleri de önem taşır. O nedenle ekipteki kişiler değişimlere kolayca ayak uydurmalıdır.
- 2001 yılında hazırlanan Agile Mindset; “Projelerde süreçler ve araçlar önemli ama daha önemlisi kişiler ve kişiler arası etkileşimdir. Süreçler ve araçlara uyum sağlamak önemli tabii ki ama daha önemlisi değildir.” düşüncesini savunur.
- Agile yaklaşım dokümantasyona daha az önem verir. Çünkü müşteri için işe yarar/çalışır çıktılar üretmek aslolandır. Tabii bu hiç dokümantasyon yapılmadığı anlamına gelmemelidir. En ufak User Story’den Test Case’ine kadar düzenli ve iyi yazılması gereken bir sürü içerik de mevcuttur.
- Bir işte sözleşmeye göre hareket edilmeli ve ürünü çıkarma noktasında engel teşkil edecek maddeler varsa geçici veya kalıcı olarak planlardan çıkarılmalıdır. Burada önemli olan müşteri ile iletişimde senkron kalmak ve işe yarar ürün parçaları hedefinden şaşmamaktır.
NOT: Agile sadece yazılım projeleri için kullanılmamaktadır. Ulaştırmadan uzay çalışmalarına, sanayiden akademik organizasyonlara, eğitimden sağlığa kadar pek çok sektörde kullanılmaktadır.
Sürekli Teslimat: Müşteri veya kullanıcıya ürünü parça parça sunmak Agile prensiplerinin en önemli unsurlarındadır.
Araçlar : Agile ekiplerin mümkün oldukça aynı ortamda olması gerekir ancak son zamanlarda pandemiden dolayı Agile ekipler de uzaktan çalışmaya alıştılar. Uzaktan çalışma ile bir arada bulunamayan takımlar yüz yüze görüşememenin sebep olabileceği sıkıntılara istinaden bazı uygulamalar kullanmaya başlamıştır. Online Boardlar için Miro,Vsts,Trello,Jenkins vs gibi alternatifler kullanılırken; toplantılar için Zoom, Webex, Teams, Skype vb alternatiflerden yararlanılmaktadır.
Definition of done: Sprint sonunda teslim etmeyi taahhüt ettiğimiz beş maddelik bir işimiz olduğunu ama sadece üç puanlık bir kısmını bitirebildiğimi düşünelim. Müşteri ile el sıkıştığımda tamamlanma kriteri beş puan üzerinden değerlendirilir. Dolayısıyla iş tamamlanmamış sayılır. Bu her ne kadar kötü görünse de, işe yarar çıktıların oluşturulması ve bir ürün değerinin ortaya konması açısından anlamlıdır. İşlerin bu şekilde eksik kalmaması ve istekleri tam olarak karşılanması için planlama toplantılarında üzerinde karar kılınan maddelerin takım tarafından iyice anlaşılır ve yapılabilir parçalara bölünmüş olması önemlidir.
İletişim: Kimse ekipte birbirini bir işin yapılması için uyarmamalıdır. Zaten planlamanın başında alınan işler bellidir ve takım bu işleri bitireceğine dair birbirine söz vermiştir. Bu sözün tutulması için de herkes elinden geleni yapmalıdır. O nedenle döngünün içerisinde takımdakilerin birbirlerini “Bu talebi bitirdin mi? Bitirecek misin?” şeklinde uyarması etik değildir. Eğer bir yavaşlık söz konusu ise veya belli başlı nedenler ile alınan talepler bitirilmediyse retrospective toplantısında tartışılmalıdır.
Toplantılar: Agile yaklaşımın iterasyonlar bazında vazgeçilmez toplantı ritüelleri vardır. Daily Meeting, Sprint Planning, Review, Retrospective vb. Bunları yazının ilerleyen kısımlarında ele alacağız.
Yalınlık : Agile süreçlerinde sadelik önemlidir.
Agile ekipleri Cross functional olmalıdır. Cross Functional ekip, ortak bir amaç için çalışan farklı işlevsel uzmanlığa sahip bir grup insandır. Agile metodoloji ile çalışan takımlardaki ekip üyelerinin cross functional olarak ifade edilen yetkinliklere sahip olması tercih edilir. Bu hem aynı ekipteki her geliştiricinin bir başkasının işini yapabilmesi farklı domainlerde çalışılabilmesi açısından önemli bir yetkinliktir
Projedeki ürüne göre uzmanlıklar değişebilir. Agile’da Proje Yöneticisi kavramına rastlanmamaktadır. Bunun yerine Agile Practitioner kullanılır. Agile Koç, Scrum Master veya Scrum Coach olarak da adlandırılabilir. Agile Practitioner ekiple birlikte işi yapan kişi değildir. Ekipte işle ilgili dönüp danışılacak kişidir. Ekibin önündeki engelleri açan kişidir ancak ekibin yerine iş yapmaz. Kurumsal anlamda sorunları çözmeye çalışır. Agile Practitioner’ın ortak amacı,ekibin engellerini ortadan kaldırmak demiştik. Bu engeller; bütçe desteği, yazılımsal araç eksikliği, yönetimsel sorunlar vb. olabilir. Bu sorunlar dahilinde operasyonel olarak işe yardım etmekle yükümlü değillerdir. Örneğin, ekip bir şeyi yanlış yapıyor ise Agile Pracititonerlar onların fikirleri alınmadığı sürece hiçbir şey yapmamalıdır.
Yazılım ekibi; işi yapmakla yükümlü olan,plan ve iterasyonlara bağlı olarak işleri tamamlamaya çalışan ve sürekli iletişim halinde kalan çok kalabalık olmayan ekiplerdir.
Ürünün sahibidir ve öncelikleri belirledikten sonra detayları sağlamakla yükümlüdür. Ürün veya hizmetin yol haritasını bilen, bunları biçimlendiren, ek olarak yapılacak işleri önceliklendiren kişidir. Product Owner ekipten olabileceği gibi müşteri organizasyonundan da olabilir.
- Önerilen 3–9 kişi arasıdır. Hatta şöyle bir tabir vardır. “Bir öğünde üç pizza ile doyan bir ekip Agile ekip olabilir. :)”
- Ekip kendi kendisini yönetebilmelidir. Bu şekilde problemler karşısında hızlı organize olup kolayca çözüm üretebilirler.
- Başlanmış olan işlerin sayısı veya büyüklüğü sınırlanmalıdır.
- Süreklilikte etkin ekip üyeleri olması avantajdır.
- Farklı yetkinliklerden farklı bilgilere sahip olan kişiler olmasında yarar vardır. (Cross-Functional)
- Fiziken aynı ortamda olmaları iletişimin gücü ve verimliliği açısından önemlidir. Bu nedenle şirketlerde agile takımlar genellikle çevreden izole olmuş ve bir arada yaşayabilecekleri odalarda çalışırlar. Ancak pandemi şartlarında çeşitli çevrimiçi araçlarla bu fiziki ortamı sanal dünyaya taşıdılar.
- Her bilgi ile ilgili ufak da olsa bilgisi olan ve takımı kuvvetlendiren takım arkadaşlarına T-Shaped adı da verilir. T-Shaped yaklaşımındaki takım arkadaşlarının her alanda bilgisi ufak da olsa vardır. Tek bir alanda da kendini tam anlamıyla geliştirmiştir ve derin bilgileri vardır.
- I-Shaped ise bir konuda uzmanlığım var, başka bir şeye bakmam yaklaşımında olan çalışanlardır. Bu çalışanların bir konuda derin bilgisi ve uzmanlığı bulunmaktadır. Eğer bildikleri konu ile ilgili sorun yaşanırsa adres bellidir. Üstlendiği rol itibariyle Feautereler, User Storyler ve bunların tamamlanıp tamamlanamadığı konusunun takip edilmesi Product Owner sorumluluğundadır.
*Bir projenin yaşam döngüsü genellikle aşağıdaki şekildeki gibi ifade edilir:-
- Konsept geliştirme
- Fizibilete çalışması
- Müşteri istekleri
- Çözüm geliştirilmesi
- Dizayn
- Prototip
- Yapı
- Test
- Geçiş
- Devreye alma
- Yol haritası incelemeleri
- Dersler çıkarmak
Genel planlama, release planlaması ve müşteri tarafı ile bir araya gelinmesi gibi konulardan ürün sahibi (Product Owner) sorumludur Release plan aşamasına temel paydaşlar haricinde isterse ekip de dahil olabilir. Takım tarafından yapılacak geliştirmelerde iterasyona dahil edilecek maddelerin önceliklendirilmesi zor ve çok mühim bir konudur. Product Owner sorumluluğunda olan bu konuya geliştirme takımı da dahil olabilir. İletişimin çift yönlü ve birlikte ilerleyecek şekilde gerçekleşmesi avantaj sağlar.
- Genel olarak bir yol haritasıyla nihai olarak yapılacak işlemler planlanır. Örneğin ilk altı ayda şunları, diğer altı ayda bunlarıyapacağız, önümüzdeki bir senede o hedefe varacağız vb. olursa bu bir Release planlamadır.
- Kaba taslak yapılan bir planlamadır. Bir başka deyişle detaylı olarak yapılan bir şey yoktur. Daha çok releaseler sonrası ortaya çıkacak şeyler belirlenir.
- Agile de releaseler içerisinde başlayan iterasyonlarla başlar. Bu iterasyonlar değişiklik gösterebilir. İterasyon iki hafta veya bir aylık olabilir ya da kurumun yaklaşımlarına göre değişebilir. Ancak hangi gün sayısıyla başlandıysa onunla devam edilmelidir. Bir iterasyon 15 gün, diğerinde 30 gün, sonrasında tekrar 15 gün şeklinde devam edilirse sıkıntılar olabilir.
- Her bir özelliğe göre görev dağılımı yapılır.
- User Story oluşturabilmek için gereksinimlerin parçalara bölünmesi gerekir.
- Ürün ya da hizmetle olan bağlantısı önemlidir.
- Şu roldeki kişi olarak şunun yapılmasını istiyorum, böylelikle şuna ulaşabileceğim formatında bir tanımlama yapılır.
- Kullanıcının aslında neye ihtiyaç duyduğu kavramlarla açıklanabilir.
- Bir User Story kendi başına özellik olabileceği gibi biren fazla Usery Story ürün için tek bir özelliği de ifade edebilir.
- Ürünün özellikleri User Story’lerden oluşur. Bu özelliklerin toplamı da bizi Releaselere doğru götürür.
- Product Backlog’da her biri User Story olarak tanımlanmış gereksinimler bulunur.
- Product Backlog’un oluşturulması Product Owner tarafından gerçekleştirilir. Ancak Agile pratiklerine göre takımla birlikte oluşturulması desteklenmektedir.
- User Storylerin tanımlı hale gelmesi ve içlerinde ne iş yapılacağının belirtilmesi de Product Owner sorumluluğundadır.
- Iteration Backlog ise ilgili döngüye hangi User Storyleri alacağız sorusuna cevap verir. Bunların önceliklendirilmesi Product Owner tarafından yapılır.
- Ancak bu işlemler yapılırken, daha önce de bahsettiğimiz gibi ekip “bu yapıyı bu iterasyonda yetiştiremeyeceğiz” diyebilir ve bu konuda ortak noktaya varılabilir.
- İşin zorluğunu da belirten büyüklük kavramı Story Point(SP) olarak ifade edilir. User Story’ler mutlaka SP değerleri ile açılır.
- Tahminleme yöntemlerinde genellikle Fibonacci Serisi kullanılır. Yani SP değerleri bu şekilde ifade edilir(1,2,3,5,8,13,21…)
Neden Man Hours(Adam Gün) kullanılmaz ? Man Hours(Adam Gün) işin büyüklüğü anlamında yanıltıcı olabilir. Agile ekipleri bir işi birlikte yaparak ilerler. Yani zamana bağlı bir ölçümlendirme yapmak tercih edilmez.
-
İş yakınımızda ise yani bu iterasyonda çözülebilecekse, sekiz ve altındaki puanlarla tahminleyebiliriz(1,3,5,8 )
-
Süreklilik arz eden ve tek sprint içinde tamamlanamayacak işler de söz konusu olabilir. Örneğin Refactor işlemleri, üretim ortamı hataları desteği gibi. Bunlar genel büyüklüklerde bırakılır(13,20 puan gibi)
-
Parçalanması için ayrıca çalışılması gereken veya ilk bakışta kapsamı büyük olup anlaşılamayan işler 20,40,100 SP ile Epic olarak adlandırılır. Genel görünümü aşağıdaki grafikte bulabilirsiniz.
Benzetme tahminlemesine göre eğer bir işe 3 SP(Story Point) kadar büyüklük veriliyorsa, diğerlerine de o tahmine benzer olacak şekilde puanlar verilebilir. Bu tahminleme şekli büyüklükleri belirlerken daha hızlı aksiyon almamızı sağlar. İlk etapta baz puanı belirlemek zordur ancak alıştıktan sonra işler kolaylaşır.
- Product Owner döngü için gerekli işleri Development Team’e ilettikten sonra Development Team bu talepler ile ilgili puanlama yaparken herkesin ortak görüşünü kolayca almak için çeşitli yöntemlerden yararlanır. Planning Poker bunlardan birisidir.
- Eğer ekipten birisi bir iş için 8 SP verirken diğeri, 1 SP veriyorsa, neden biri bu kadar yüksek diğeri bu kadar düşük verdiğine dair bir tartışma yapılır ve ekipçe ortak karara varılır.
- Yer yere iterasyon yer yer sprint olarak da adlandırılan kavram aslında takımın belirlediği koşu sürecini ifade eder.
- Product Backlog’dan buraya işler alınarak Sprint/iterasyon Backlog oluşturulur.
- Sprint Backlog’daki işler önceliklendirilir, büyüklükleri belirlenir ve daha küçük görevlere bölünerek takım arasında paylaşılır.
Her gün yapılan rutin toplantılardır. Bu toplantılarda amaç şu üç soruya cevap vermektir. 1-) Ekip olarak dün ne yaptım ? Neleri tamamladım?
2-) Bugün kişi olarak neleri yapacağım ?
3-) Bu işleri yaparken sıkıntıyla karşılaştım mı ? Yardıma ihtiyacım var mı ?
-
15 dakika ile sınırlıdır (Uzaktan çalışma döneminde ise bu süre 30 dakika olarak da belirlenebilir)
-
Sorun varsa bunu çözmek için Scrum Master/Scrum Coach devreye girer.
-
Bu toplantılarda PO,Agile Coach ve Development Team dışında kimse bulunamaz. Olsa da izleyici olarak katılabilir. NOT: AGILE KOÇUN KURUM DIŞINDAN OLMASI OBJEKTIF OLUNMASI AÇISINDAN DAHA İYİ OLABİLİR
- Günlük olarak ekibin işlerdeki durumunu gösteren grafiklerdir.
- Lineer bir grafik değildir. Nitekim bir çizgi ile ideal yol ifade edilirken diğeri ekibin güncel durumunu gösterir.
- Kırmızı çizgilerle günlük işin ne kadarının tamamlandığı gösterilir. Bu çizgiler gidişatta sıkıntı var mı yok mu onu belirtir.
- Dashbord göstergelerini izlemekte kullandığımız kavram radyatör, proje ara çıktısı ise artifact olarak adlandırılır.
Önceki döngülerde yaşanan sorunları çözümleme sonucunu değerlendirerek yani bu deneysel sonuçlardan yola çıkarak yeni yol haritası hazırlanır. Bu, takımın iş yapma beceresini iyileştirmek ve verimliliğini artırmak için kullanılır.
Transparency: Ekibin kendi içerisinde bilgiyi doğru paylaşmasıdır. Inspection : Kök nedenler bulmaktır. Adaptation: Bu kök nedenlere göre yeni kavramlar ortaya koyulmasıdır.
- Hızdan kasıt “ne kadar zamanda ne kadar iş bitiriyoruz?” sorusunun cevabıdır. Definition of Done’a göre bitiriyorsak ekip olarak hızımız budur.
- Bitmeyen işler tamamlanmamış olarak kabul edilirler. Tamamlanmayan işlerin değeri yoktur. Bunları çoğalması bir yerlerde hata yaptığımızı gösterir. İyileştirmek için Deneysel Süreç Kontrolünü kullanırız.
- Tamamlanma şartı anlamına gelmektedir.
- Baştan o işin yapılması ile ilgili metrik konulur. User Story açılırken o talep ile ilgili nelere ihtiyaç olduğu ve sprint sonunda hangi çıktıkların elde edileceği metrikler halinde belirtilir. Eğer bu metriklere ulaşıldıysa o zaman Definition of Done’a uygun demektir. Yani iş tamamlanmıştır.
- Definition of Done’ı Product Owner geliştirir. İşi ekip yapacağı için bunu ekiple birlikte geliştirmesi daha faydalı olur.
- Definition of Done projenin etkili yapılıp yapılmadığı ile ilgili bilgiler de verebilir.
- Bu süreci Product Owner sahiplenir ve süreç boyunca ekibin de işin içinde olması işin daha iyi anlaşılmasını sağlar. Agile genelde bunu tavsiye eder.
- Product Owner, bir sonraki Sprint’te veya iterasyonda üzerinde çalışılması gereken Product Backlog öğelerini çıkarır ve User Story’lere böler. Böylece ekip, bir sonraki Sprint sonunda teslim edilmesi beklenen işleri bilir.
- İşler öncelik sırasına göre alınır, büyüklükleri Development Team tarafından tahmin edilir ve story point olamayacak kadar büyük olanların türü epic olarak güncellenir. Epic olan işler daha küçük parçalara bölünmeden sprint’e alınamazlar..
- Döngünün sonunda yapılan işler ve ürün çıktıları müşteriye sunulur.
- Bu toplantılarda müşterinin ürünle ilgili eksiklikler de ortaya çıkabilir. Müşteri nezninde bu eksiklikler sonraki sprint için birer backlog maddesi olabilir.
- Toplantıya Product Owner, Development Team, Agile Coach ve müşteri (isteğe bağlı) katılır.
- Müşteriyle degil ekiple alakalı bir toplantıdır.
- Ekip kendi kendini eleştirir. Neyi iyi yapıp neyi kötü yaptığını tespit etmeye çalışır.
- Scrum Master ile birlikte sürecin nasıl iyileştirileceği tartışılır. Bu toplantılarda Scrum Master yol gösterici kimliği ile bulunduğundan etkisi büyüktür.
- Product Owner,Agile Coach,Scrum Master, Development Team ve ekibin tamamı katılır.
Son olarak aklımızdan çıkarmayalım ve uygulayalım! Shu Ha Ri 😊
Shu Ha Ri mantığında çalışan kişiler ;
- Yeterli olmadığı noktada koçtan destek alır(Shu).
- Belli bir noktaya geldiğinde bağımsız olarak öğrendikleriyle kendi kararlarını verebilir. Bir sonraki aşamada kendi stilini geliştirir(Ri).
- En önemlisi kendisine aktarım yapıldığı gibi yeni gelen kişilere de aynı ona yapıldığı gibi aktarım yapar, yardım eder ve o kişinin “Shu” evresinden “Ha” evresine geçmesi için elinden geleni yapar. Unutmayalım, bilgi paylaştıkça güzeldir. Bilgiyi paylaştığımızda değer kazanır.