Tag 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 – Deniz Yıldızı Retrospektif

Çevik Retrospektif TeknikleriDeniz Yıldızı Retrospektif

Deniz Yıldızı Retrospektif

Deniz Yıldızı Retrospektif tekniğinde aşağıdaki 5 kategori bulunur:

  • Start / Başlayalım
  • Keep Doing / Yapmaya Devam Edelim
  • More Of / Daha Fazla Yapalım
  • Less Of / Daha Az Yapalım
  • Stop / Yapmayı Bırakalım

5 kategori bulunması takım üyelerine fikirleri söyleyebilecekleri daha fazla seçenek verir. Kimi zaman  fikirlerinizi iki ya da üç kategoriden birinde ifade edemeyebilirsiniz. Bazen siyah ya da beyaz arasında bir seçenek olması gerekebilir. Deniz Yıldızı Retrospektif bu ihtiyacı karşılar. Continue reading Çevik Retrospektif Teknikleri – Deniz Yıldızı Retrospektif

Çevik Retrospektifleri Eğlenceli Bir Aktiviteye Dönüştürmek için Ne Yapılabilir?

Çevik Retrospektifleri Eğlenceli Bir Aktiviteye Dönüştürmek için Ne Yapılabilir?

 

Retrospektif toplantıları takımın tecrübelerini gözlemlediği ve bu gözlemlere dayanarak iyileştirme aksiyonlarını belirlediği aktivitelerdir. Eğer bir retrospektif tekniği kullanılmazsa bu aktiviteler zamanla  takımlar için sıkıcı bir hale gelebilir. Çevik retrospektifleri eğlenceli bir aktiviteye dönüştürmek için ne yapılabilir?

Yazının bundan sonraki bölümünde retrospektif toplantısına katılan kişilerin tamamından takım diye bahsedeceğim. Eğer Scrum yapıyorsanız retrospektif toplantısına Geliştirme Takımı, Ürün Sahibi ve Scrum Master katılır. Eğer Kanban yapıyorsanız retrospektif toplantısına geliştirmeyi yapan takım ve ilgili paydaşları kimse onlar katılır. Eğer eXtreme Programming yapıyorsanız takım süreçlerini gözlemler ve süreçte çalışmayan şeyleri düzeltir. Yani Çevik yaklaşımların hepsinde retrospektif yapılır. Bu nedenle yazının bundan sonraki bölümünde takım dediğimde hangi yaklaşımı kullanıyorsanız, o yaklaşımda kimlerin retrospektif toplantısına katılması gerekiyorsa o kişileri anlatıyorum demektir. 😉 Continue reading Çevik Retrospektifleri Eğlenceli Bir Aktiviteye Dönüştürmek için Ne Yapılabilir?

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