Kategori arşivi: Agile

Davranış Odaklı Geliştirme Nedir?

Davranış Odaklı Geliştirme (DOG), Test Odaklı Geliştirme(TOG)’den evirilen bir yazılım geliştirme yaklaşımıdır. Ortak bir dilde yazılmış olmasıyla farklılık gösterir ki bu da teknik ve teknik olmayan ekipler ile paydaşlar arasındaki iletişimi geliştirir. Her iki geliştirme yaklaşımında da testler koddan önce yazılır; fakat Davranış Odaklı Geliştirme’de testler daha kullanıcı odaklı ve sistemin davranışına dayanmaktadır.

DOG ’yi Neden Seçmeliyiz?

TOG, iş sahibi, kullanılan Birim Test çerçevesine aşina olduğu ve teknik yetenekleri güçlü olduğu(her zaman böyle değildir) müddetçe tatmin edici bir şekilde çalışır. Bu şartlar altında DOG avantaja sahiptir çünkü testler paydaşların da bildiği, örneğin İngilizce gibi ortak bir dilde yazılır. Daha açık olması, minimum miktarda mesleki argo kullanarak etkili iletişime erişim sağlaması, DOG kullanmanın muhtemelen en büyük avantajıdır. Teknik ve teknik olmayan ekipler arasında yüksek verimlilikle çalışılabilmesi için iş birliğini mümkün kılar.

Davranış Odaklı Geliştirme Nedir? yazısına devam et

Çevik Proje Lideri Nedir?

Bu makaleyi iki gözlemim nedeniyle yazdım:

1. Birçok kurum, kullanmaması gereken durumlarda bir “proje modeli” kullanır.

2. Çevik topluluğunda projeler ve proje liderliği tanımı hakkında birçok kafa karışıklığı ve tartışma vardır.


“Cevabım” olduğunu iddia etmiyorum, ancak bunu çok düşündüm ve müşterilerimde de deneyimledim (onlar duymasın… sshhhh). Bu nedenle işte burada çevik bağlamda proje liderliğinden anladıklarımı paylaşıyorum.Oh, ve bu arada, bu makale bir Bait & Switch*. “Çevik Lider Nedir?” adlı makaleyi okumanızı sağlamaya çalışıyorum. Bunu atlayıp hemen oraya giderek zaman kazanabilirsiniz. 🙂

Çevik Proje Lideri Nedir? yazısına devam et

Siperden Retrospektif Teknikleri ve Deneyimleri

Önsöz

Retrospektif, Çevik yaklaşımlarla hayatımıza giren en önemli pratiktir. Bunun nedeni retrospektiflerin hayatımıza girişiyle sürekli olarak iyileşme şansı elde etmemizdir. Geleneksel proje yönetimi yaklaşımında iyileştirme şansı sadece proje sonunda “Öğrenilmiş Dersler” bölümünde yer alır. Geleneksel proje yönetimiyle geliştirdiğim projelerin hiç birinde “Öğrenilmiş Dersler” aktivitesini gerçekleştiremedim. Çünkü projelerin teslim tarihi çoktaaaan geçmişti. Teslim tarihi geçen bir proje de “Öğrenilmiş Dersler” aktivitesine zaman ayrılmıyor. Projenizi teslim ettikten sonra sıradaki projeye başlıyorsunuz. Çevik yaklaşımlarda sürekli iyileştirme anlayışı vardır. Burada dikkat edilmesi gereken sözcük süreklidir. Scrum ve eXtreme Programming yaklaşımlarında döngü sonunda, Kanban’da sizin belirlediğiniz zamanlarda kendinizi iyileştirmek için bir aktivite gerçekleştirirsiniz. Ayrıca kendinizi geliştirmek için döngünün sonunu beklemenize bile gerek yok. Döngü içinde de aksiyon alabilirsiniz. 🙂 Retrospektif teknikleri, iyileştirme aksiyonlarınızı planlamanızı kolaylaştırmak için var.

Kitabın ilerleyen bölümlerde farklı retrospektif teknikleri, tekniklerin NASIL gerçekleştirilebileceği, retrospektifin faydaları, retrospektiflerde sık karşılaşılan problemlere, retrospektifleri eğlenceli bir aktiviteye dönüştürmek için neler yapılabileceğine değineceğiz. MAD-SAD-GLAD ile başlıyoruz. 🙂

Nisan 2019,

Cihan Yılmaz

Siperden Retrospektif Teknikleri ve Deneyimleri kitabını indirebileceğiniz bağlantı: Siperden-Retrospektif-Teknikleri-ve-Deneyimleri.pdf (2654 indirme)

Siperden Retrospektif Teknikleri ve Deneyimleri yazısına devam et

Büyük Yazılım Sistemlerinin Geliştirilmesini Yönetme

Önsöz

Büyük küçük birçok şirket Çevik Dönüşüm başlattı ya da başlatmayı düşünüyor. Hatta Steve Denning bu durum için “Why Agile Is Eating The World” adlı bir makale yazdı ve bu makale oldukça popüler oldu. Çevik Dönüşüm, temelde geleneksel yaklaşımda işlemeyen ve üretken olmayan organizasyonu işler ve üretir duruma getirmektir. Geleneksel yaklaşım deyince aklıma gelen ilk yaklaşım Waterfall. Winston Royce tarafından adına basit metot (1970) denen daha sonra Bell ve Thayer tarafından adına Waterfall (1976) denen yaklaşımdan Çevik yaklaşımlara doğru bir evrim geçiriyoruz. Bu evrimi geçirirken nereden geldiğimizi hatırlamak ve nereye gidebileceğimize karar vermek bu makaleyi çevirmemdeki ana nedendi. Diğer bir neden Waterfall’un neden bu kadar popüler olduğunu anlayabilmekti. Bunlar:

  • Basit
  • Başlangıç maliyetinin düşük olması
  • Öğretmesi ve öğrenmesi kolay (Üniversitede hala Waterfall öğretiliyor, makalenin yayınlanmasının üzerinden 49 yıl geçtiğini unutmayın)
  • Zamanın üretim anlayışına paralel olması
  • Mantıklı olması 🙂
  • Başlangıç ve bitişinin olmasının sağladığı yanılsama

Çok büyük çoğunluğumuz bu makaleden doğan yaklaşımlarla iş yaptı. İş yaptı derken hayatını kazandı ve hayatını yaşadı. Kimileri emekli bile oldu. Kimileri projeleri bitirdiğinde mutlu oldu bitiremediğinde üzüldü. Kimimiz bu yapıya yatkın olmadığı için iş değiştirdi. Peki, tüm bunlar olurken aslında başlangıç noktası neydi? Kaçımız bu başlangıç noktasını düşündü? Ne yazık ki çok azımız. Bugünlerde Çevik yaklaşımların çok popüler olduğunu yazımın başında söylemiştim. Yine ne yazık ki Çevik Bildiri’yi bir defa bile okumamış Çevik Koç, Scrum Kılavuzu’nu bir defa bile okumamış Scrum Master artıyor. Bu çeviri birazda birey ve toplum olarak Waterfall’a yaptığımızı Çevik yaklaşımlara yapmamak için yapıldı.

Makaledeki önemli noktalar: Makalede bence önemli olan yerlerin arka rengini sarı yaptım. Böylece buraların daha dikkatli okunması gerektiğini vurgulamak istedim.

Makalenin orijinaline erişebileceğiniz bağlantı: http://www- scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf

Mart 2019,

Cihan Yılmaz

Büyük Yazılım Sistemlerinin Geliştirilmesini Yönetme makalesini indirebileceğini bağlantı: Büyük-Yazılım-Sistemlerinin-Geliştirilmesini-Yönetme.pdf (1618 indirme)

Büyük Yazılım Sistemlerinin Geliştirilmesini Yönetme yazısına devam et

Çevik Lider Nedir?

Çevik ürün geliştirme birçok sektörde norm haline geldi (özellikle yazılım sektöründe). Bunun anlamı; ürünler, küçük, kendi kendini yöneten, çapraz fonksiyonel takımlar tarafından geliştirilir ve gerçek müşterinin geri bildirimlerine göre sürekli iyileşen küçük ürün parçaları halinde teslim edilir. Çevik Bildiri’de anlatıldığı gibi – fakat “yazılım” kelimesini ürün ile değiştirin (çünkü bu konu sadece yazılım özelinde değildir).

Bunlar güzel. Ancak bir şeyler büyüdükçe, organizasyonel sınırlar içerisinde iş birliği yapan düzinelerce ekiple birlikte işler açıkça daha karmaşık ve acı verici hale gelir. Bütün organizasyon, Scrum Takımları halinde organize edilmiş olsa bile, hala aynı noktada olmayan bir organizasyonla karşılaşabilirsiniz! İşte tanıdık gelebilecek bir resim:

Çevik Lider Nedir? yazısına devam et