Category Archives: Extreme Programming

Çevik Retrospektif Teknikleri – 4L Retrospektif Tekniği

Çevik Retrospektif Teknikleri – 4L Retrospektif Tekniği

4L Retrospektif Tekniği

4L retrospektif tekniği, retrospektif toplantısını eğlenceli bir hale getirmek için bir başka tekniktir. Mary Gorman’ın kullandığı 3L retrospektif tekniğinden türetilmiştir.

3L retrospektif tekniğindeki L’ler aşağıdaki gibidir:

Liked / Loved – Hoşlandıklarım / Sevdiklerim

Lacked – Eksik Olduğunu Düşündüklerim

Longed For – Özlemini Çektiklerim

3L tekniğinden sonra Ellen Gottesdiener tekniğe bir L(Learned) daha ekleyerek 4L retrospektif tekniğini oluşturmuştur.

4L şu şekilde sıralanır:

Liked / Loved – Hoşlandıklarım / Sevdiklerim: Geçtiğimiz döngüde sevdiğim şeyler.

Learned – Öğrendiklerim: Geçtiğimiz döngüde öğrendiğim şeyler.

Lacked – Eksik Olduğunu Düşündüklerim: Geçtiğimiz döngüde eksik olduğunu düşündüğüm şeyler.

Longed For – Özlemini Çektiklerim: Geçtiğimiz döngüde keşke olsaydı diye düşündüğüm şeyler.

Continue reading Çevik Retrospektif Teknikleri – 4L Retrospektif Tekniği

Çevik Retrospektif Teknikleri – MAD, SAD, GLAD Tekniği

Çevik Retrospektif Teknikleri – MAD, SAD, GLAD Tekniği

Retrospektif, Çevik yaklaşımların hayatımıza soktuğu en önemli pratiktir. Retrospektiflerin hayatımıza girmesiyle sürekli olarak iyileşme şansı elde ettik. Geleneksel yaklaşımda iyileştirme şansı sadece proje sonunda “Öğrenilmiş Dersler” bölümünde yer alıyor. Geleneksel proje yönetimiyle geliştirdiğim projelerin hiç birinde “Öğrenilmiş Dersler” aktivitesini gerçekleştirmedim. Çünkü birkaç proje hariç çoğu için teslim tarihini geçmiştik. Teslim tarihini geçtiğiniz bir proje de “Öğrenilmiş Dersler” aktivitesini yapamıyorsunuz. Projenizi teslim ettikten sonra sıradaki projeye başlıyorsunuz. Halbuki Çevik yaklaşımlarla kendimizi her gün iyileştirme şansına sahibiz. Yukarıda geleneksel yaklaşımda bu şansın neredeyse hiç verilmediğini vurgulamam bu şansın ne kadar değerli olduğunu göstermek içindir.

İlerleyen bölümlerde farklı retrospektif tekniklerine, bu tekniklerin aktivite olarak nasıl gerçekleştirileceğine, gereksinimlerine değineceğim. MAD-SAD-GLAD ile başlıyoruz. 🙂

MAD-SAD-GLAD Tekniği

MAD-SAD-GLAD, en basit retrospektif tekniklerinden biridir. İçine kapanık, çok fazla konuşmayan takım üyelerinin bulunduğu takımlarda bu teknik kullanılarak takım üyelerinin retrospektife katkıları artırılabilir. Duygulara yönelik bir teknik olduğu için daha önce az katılım gösteren takım üyelerinin daha fazla katılım gösterdiğini gözlemleyeceksiniz. Bunu kesin bir bilgi gibi söylüyorum çünkü deneyimlerim hep bu yönde oldu. Eğer hali hazırda çok konuşan, iletişimi kuvvetli, içine kapanık olmayan takım üyeleriniz varsa bu retrospektif tekniği sizin için uygun olmayabilir. Zaten konuşkan kişileri daha da fazla konuşturarak iletişimlerine ve koordinasyonlarına çok fazla enerji harcamak doğru olmayabilir.
Continue reading Çevik Retrospektif Teknikleri – MAD, SAD, GLAD Tekniği

Sürekli Entegrasyon 4

Sürekli Entegrasyon 4

 

10. Herkes Ne Olduğunu Görebilir

Sürekli Entegrasyon iletişimdir. Böylece herkes sistemin son halini ya da şimdiye kadar neler yapıldığını rahatça görebilir. İletişimin yapıldığı birinci konu ise ana branch üzerinde gerçekleştirilen build işleminin durumunun ne olduğudur. Sürekli Entegrasyon için kullanılan araçlar bir web sitesi ile gelirler ve yapılan build’i, bu web sitesi üzerinden herkes izleyebilir. Kimi kurumlar bunun daha da görselleştirmek isterler başarılı build’ler için yeşil ışık sorunlu build’ler için kırmızı bir ışık yakarlar. Kimi kurumlar daha eğlenceli yaklaşırlar olaya ve build yapan yazılım geliştiricinin makinesinin üzerinde plastikten bir horoz bulunur. Herkes build yapıldığını ve kim tarafından yapıldığını bilmiş olur.

Web sitesinin diğer bir avantajı ise aynı ofiste çalışmayan kişilerin build’in son durumu hakkında kolayca bilgi edinebilmesidir. Ayrıca tarihçesi tutulan sistemlerin hangi build’lerinin başarılı olduğu hangilerinin olmadığı ve neden olmadığı bilgisi de bulunmaktadır.

Continue reading Sürekli Entegrasyon 4

Sürekli Entegrasyon 3

Sürekli Entegrasyon 3

6. Bozuk Build’i Hemen Düzeltin

Sürekli build yapabilmenin anahtarı ana branch’te gerçekleştirilen bir build hata aldıysa bunu hemen düzeltmektir. Sürekli Entegrasyon ile çalışmanın amacı stabil bir ortamda geliştirme yapmaktır. Ana branch’te bir build’in hata alması kötü bir şey değildir fakat sürekli olarak yaşanıyorsa bu yazılım geliştiricilerin yeterince dikkatli olmadıklarının göstergesidir. Yine de önemli olan nokta eğer bir build hata aldıysa bunun biran önce düzeltilmesidir. Böyle bir sorun genellikle ana branch’e gönderilen son kodun geri alınması ve kodu gönderen kişinin kendi makinesinde sorunu bulmasıyla çözülebilir.

Continue reading Sürekli Entegrasyon 3

Sürekli Entegrasyon 2

Sürekli Entegrasyon 2

 

2. Otomatize Edilmiş Derleme

Kodlar, bir tane kod kaynağında çalışır duruma geldikten sonra yapılması gereken işlem bu kodların otomatize edilmiş bir şekilde derlenmesidir. Otomatize edilmiş derlemelerin içinde entegrasyon testleri ve birim testleri otomatik olarak çalışmalıdır. Otomatize edilmiş derleme için farklı yazılım dillerinin, farklı platformların, farklı toplulukların farklı uygulamaları mevcuttur.

Büyük bir derleme zaman alır. Bunun için derleme aracınızın bir önce gerçekleştirdiğiniz derleme ile şu anda gerçekleştireceğiniz derleme arasındaki farkları bulması, bu değişiklikler ile ilgili bağımlılıkları bulması ve sadece bunları derlemesi iyi bir özelliktir. Yapılan ufak bir değişiklikten sonra uzun bir derleme süresini beklemek doğru değildir. İyi derleyiciler bu tarz işlemlerle başa çıkabilir durumdadır fakat başa çıkamayanlarda bulunmaktadır. Bir yazılım geliştirici kendi bilgisayarında kullandığı yazılım dilinin IDE’sine bağlı olan derleme sistemini kullanabilir fakat onlarca yazılım geliştiricinin kodunun aynı anda derlenmesi için bir ana bilgisayar üzerinde bahsettiğim platformlardan biri kullanılmalıdır.

Continue reading Sürekli Entegrasyon 2