Poker Planlama

Çevik yaklaşımlarda işin maliyetini belirleme konulu yazı serisinin üçüncü bölümünde Scrum, eXtreme Programming ve Kanban takımlarında kullanılan Poker Planlama konusunu anlatacağım. Poker Planlama, Çevik Bildiri’ye imza atan 17 kişiden biri olan James Grenning tarafından geliştirilmiştir. Bir eXtreme Programming tekniğidir. Scrum uygulayanlar tarafından faydalı bulunup Sprint ve Release planlamasında kullanılmaktadır. Poker Planlama, uzman görüşünü, benzeşimi –karşılaştırmayı- ve küçük parçalara bölmeyi eğlenceli bir şekilde bir araya getirmiştir.

Hikaye Puanı Nedir?

Kullanıcı hikayelerini değerlendirmek için kullanılan öznel bir birimdir.

Hikaye Puanı Neye Göre Verilir?

Hikaye Puanı verilirken bir kullanıcı hikayesi için harcanacak efora, kullanıcı hikayesinin içerdiği riske, bağımlılıklara ve kullanıcı hikayesinin karmaşıklığına bakılır.

Hikaye Puanı Kullanarak Tahmin Yapmak Neden Faydalı?

Hikaye Puanı ile yapılan tahminler göreceli tahminlerdir. Bir kullanıcı hikayesinin tamamlanabilmesi için gerekli mutlak saatin ya da günün tahmin edilmesi işi zordur. Neden zor olduğunu yazı serisinin ikinci yazısında anlatmıştım. Mutlak tahminle müşteriye verilen saat ya da gün bilgisi bir kontrat gibi algılanırken, Hikaye Puanı ile yapılan tahminler sadece tahmin olarak anlaşılır.

Hikaye Puanı Serileri

Fibonacci serisi, her sayının kendinden önceki iki sayıyla toplanması sonucu elde edilen seridir:

0, 1, 1, 2, 3, 5, 8, 13…

0 + 1 = 1

1 + 1 = 2

1 + 2 = 3

2 + 3 = 5

Ayrıca 0, 4, 4, 8, 12, 20, 32 de bir Fibonacci serisidir. Gördüğünüz gibi her sayı kendinden önceki sayı ile toplanıp dizinin yeni elemanına ulaşılmaktadır.

İkinin Gücü serisi, iki üzeri n şeklindeki sayı formudur.

2n => n bir tam sayıdır. Seri şu şekildedir;

20 = 1

21 = 2

22 = 4

23 = 8

24 = 16

Poker destesi Fibonacci serisinden ya da İkinin Gücü serisinden oluşturulabilir.

Neden Fibonacci veya İkinin Gücü Serisi?

Çünkü kademeli tahmin ölçeği, tahmini yapılan kullanıcı hikayesi hakkında doğrusal ölçekten daha etkilidir. Tahmini gerçekleştiren kişilere kullanıcı hikayesi hakkında daha çok fayda sağlar. Fibonacci Serisi ve İkinin Gücü Serisi gibi eksponansiyel büyüyen seriler kullanmak bilginin kümülatif olarak büyüdüğü sistemlerde doğruya yakın tahmin yapılmasını kolaylaştırır. Bilginin kümülatif olarak büyümesi ise “Bilgi Kuramı” ile açıklanabilir. Bilgi Kuramı, bilginin ölçülmesini -nicelikselleştirilmesi, miktarının belirlenmesi- içeren uygulamalı matematik, elektrik mühendisliği, istatistik, fizik, teoloji ve bilgisayar bilimlerinin ortak dalıdır. Bilgi Kuramı’nın bizi ilgilendiren anahtar noktası olan entropi, Claude Shannon tarafından geliştirilmiştir. Shannon’a göre;

Entropi, bir mesajdaki belirsizliğin miktarıdır. Mesajın, herhangi bir metin olması gerekmez, basitçe bilgi akışı olarak düşünülebilir. Mesajdaki belirsizlik arttıkça entropi eksponansiyel bir şekilde artar, mesajdaki belirsizlik azaldıkça entropi eksponansiyel şekilde azalır.

Bu nedenle eksponansiyel seriler kullanmak daha iyi bir pratiktir.

Burada özellikle bir noktayı vurgulamak istiyorum. Poker Planlama doğru tahmini yapmak üzerine olmamalıdır. Poker Planlama doğru tahmini yapabilmek için gerekli olan etkileşimi gerçekleştirebilmek için geliştirilmiştir. Toplantı katılımcıları arasında bu etkileşim gerçekleştirildikten sonra doğru tahmini yapmak zaten sonuç olarak kendiliğinden gerçekleşecektir.

Poker Planlama Nasıl Oynanır?

Poker Planlama, genelde en deneyimli kişinin konuştuğu toplantılara alternatif bir yaklaşım olması için yaratılmıştır. Maliyet belirleme toplantıları genelde en deneyimli kişinin konuştuğu aktiviteler halinde geçer. Diğer katılımcılar konuşulan kullanıcı hikayesi hakkında bilgi sahibi olsalar dahi sessiz kalmayı ve konuşmamayı tercih edebilmektedir. Halbuki sessiz insanların da birçok güzel fikri olabilir ya da kullanıcı hikayesi hakkında bilgi sahibi olabilirler.

• Tek kişinin konuştuğu ya da sadece iki kişinin diyaloğunun olduğu toplantılarda aynı konu ya da hikaye dakikalarca konuşulabilmektedir.
• Ulaşılan sonuç genelde doğru değildir.
• Bu toplantılar sıkıcı ve uzun toplantılardır.
• Toplantı sonunda elde edilen planlama çıktısı uygulanmaya çalışıldığında birçok sorunla karşılaşılır.

Poker Planlama, yukarıda saydığım engelleri kaldırmak için çözüm getirir. Şimdi Poker Planlama Toplantısı’nın akışını ve yeri geldikçe klasik toplantılarda karşılaşılan sorunlara nasıl çözümler üretildiğini anlatacağım.

Poker Planlama Oynama

Uzun süren ve katılımcıların katılım göstermediği toplantıya çözüm biraz poker oynamaktır. Hadi bir el oynayalım! Toplantıda müşteri rolündeki kişi kullanıcı hikayesini anlatır. Yazılım geliştiriciler konuyla ilgili akıllara takılan soruları sorar ve kullanıcı hikayesini net bir şekilde anlamaya çalışır. Kısa süren bilgilendirmeden sonra herkes kendi destesinden bir kağıt seçer ve tahminde bulunan kişiler aynı anda seçtikleri kartları açarlar.

Yazılım geliştiricilerin sorularını cevaplayan kişi her zaman müşteri rolündeki kişi olmayabilir. Takımın bazı soruları –özellikle teknik konuları- kendi içinde cevaplaması gerekebilir.

Klasik toplantılarda daha yetkin ya da deneyimli –daha çok konuşan- kişiler daha az deneyimli ya da sessiz kişileri etkileyebilmektedir. Buna çözümse kişilerin poker kartlarını aynı anda açmalarıdır. Kartlar açıldıktan sonra bir anlaşma durumu oluşmadıysa en yüksek ve en düşük değeri veren katılımcılar arasında aşağıdakine benzer bir diyalog yaşanır:

• Mehmet: Neden bu kadar büyük olduğunu düşünüyorsun?
• Ayşe: Çünkü bu datamart’ta, ApplicationFact gibi birçok tablodan besleniyor, üzerinde birçok kolon var. Bu kolonların hepsinin üzerinde hesaplamalar yapılması gerekiyor. Sadece SELECT atıp doldurabileceğimiz bir datamart değil. Peki, sen neden bu kadar kolay olduğunu düşünüyorsun?
• Mehmet: Çünkü bunu daha önce yapmıştık. Yapmamız gereken yeni bir paket oluşturmak ve eski paketle yeni paketin arasındaki farkları bulmak.
• Vs.vs…
• Vs.vs…

Kartlar Açıldığında

Kartlar açıldıktan sonra anlaşma durumunun olmaması iyi bir şeydir. Burada dikkat edilmesi gereken nokta tahmini yapan kişilerin birbirini etkilemeye çalışmamasıdır. Tahminde bulunan kişiler diğerlerinin ne bildiğini anlamaya çalışmalıdır. Aktivite bilgi dağılımını sağlayabilmek için yapılır. Takımdaki kişiler zamanla(5-6 toplantı sonra) aynı bilgi seviyesine gelecektir. Geliştirilecek iş hakkında herkesin bilgisinin olması ve bilgi seviyesinin eşit olması istenen ama elde edilmesi zor bir durumdur. Bu zorluğu aşmak için buradaki tartışma ortamı çok değerlidir.

Belirli bir süre(3-5 dakika) konuştuktan sonra ortak karara varılmaya çalışılır. Eğer ortak karara varılamıyorsa yeniden kart seçimine gidilir. Süreç yeniden yaşanır. Net bir kullanıcı hikayesi için harcanan süre 1-2 dakikadır. Kullanıcı hikayesine tekrar tekrar puan veriliyorsa bu kullanıcı hikayesinin yeterince net olmadığına dair bir işarettir. Net olmama durumu bulunuyorsa kullanıcı hikayesi küçük parçalara bölünmelidir ya da daha derinine inilmelidir. Böylece bilinmeyenler bilinir duruma getirilmelidir. Anlaşmaya varıldıktan sonra sıradaki kullanıcı hikayesine geçilir.

Net Kullanıcı Hikayeleri

Bazı kullanıcı hikayeleri çok basit ya da yapılacak iş çok net olabilir. Eğer katılımcıların hepsi bu hikaye hakkında bilgi sahibi ise ortak karara varmak daha kolay olacaktır. Bu, katılımcıların seçtikleri kartlardan da anlaşılabilir. Tahminde bulunan kişiler, bu kullanıcı hikayeleri için ortak bir kartı ya da birbirine yakın değere sahip kartları seçecektir.

Yönlendirmeyi Seven Kişiler ve Sessiz Kalan Kişiler

En düşük ve en yüksek kartları seçenler konuştuğu için toplantılarda sessiz kalmayı tercih eden kişiler bile konuşma şansı bulacaktır. Deneyimli ya da konuşkan kişilerin toplantıyı yönlendirmesinin önüne bir adım geçilmeye çalışılır. Elbet bu kişiler yine de toplantıyı yönlendirmeye ve herkesten fazla konuşmaya, kendi fikirleriyle diğerlerini etkilemeye çalışabilirler. Böyle durumlar için toplantıyı yöneten kişinin gözlemde bulunması önemli olabilir. Toplantıyı yöneten kişi çok konuşanları, arkadaşlarını da dinlemeleri yönünde uyarabilir. Hiç konuşmayan kişilerin toplantıya katılımları hakkında daha gönüllü olmalarını sağlayabilir.

Referans Kullanıcı Hikayesi

Soyut bir işe göreceli efor tahmini yaptığımız için ilk toplantılarda katılımcılar arasında sıklıkla yukarıdaki diyaloğa benzer diyaloglar yaşanabilir. Bu diyalogların çok yaşanmaması için referans bir kullanıcı hikayesi belirlemek gerekebilir. Referans kullanıcı hikayesi ne çok büyük bir iş ne de çok küçük bir iş olmalıdır. Referans kullanıcı hikayesi orta büyüklükte bir kullanıcı hikayesi seçilmelidir. Böylece referans kullanıcı hikayesinden daha basit kullanıcı hikayeleri geldiğinde aşağıya doğru, daha karmaşık kullanıcı hikayeleri geldiğinde yukarıya doğru genişleme sağlanabilir. Örnek Referans kullanıcı hikayesi;

• Giriş sayfasına kullanıcı adı ve şifre textbox’larının ve Giriş butonunun yerleştirilmesi, Giriş sayfasından kullanıcının sisteme giriş yapabilmesi.

Yukarıdaki kullanıcı hikayesinin değerine takımca seçeceğiniz bir değer verebilirsiniz. Örneğin bu kullanıcı hikayesine 8 diyelim. Bundan daha basit bir kullanıcı hikayesi karşınıza geldiğinde 5-3-2-1 değerlerinden birini, daha karmaşık bir kullanıcı hikayesi geldiğinde 13-21-34-55 değerlerinden birini seçebilirsiniz. Ekrana bir textbox yerleştirilmesi gereken bir kullanıcı hikayesinin değeri 1 olabilir. Öte yandan ekrana 5 textbox, 3 buton yerleştirmeniz gereken bir kullanıcı hikayesinin değer 21 olabilir. Buradaki değerleri sadece örnek olması için veriyorum. Dördüncü, beşinci toplantıdan sonra artık herkesin referansı ortak bir değer olacaktır. Mehmet ve Ayşe arasında geçen diyaloglar çok yaşanmayacak, kullanıcı hikayeleri tekrar tekrar değerlendirilmeyecektir.

Kullanıcı Hikayesinin En Büyük Sabit Değerini Belirlemek

Başka bir iyi pratik ise bir kullanıcı hikayesinin alabileceği en büyük sabit değeri belirlemektir. Yani bir kullanıcı hikayesi en fazla 34 Hikaye Puanı olabilir gibi. 34 Hikaye Puanı’ndan büyük bir iş fazla karmaşık, fazla efor gerektiren ve yüksek riski bulunan bir iş olarak değerlendirilebilir. “Bir kullanıcı hikayesi 34 Hikaye Puanı’ndan büyükse küçük parçalara ayrılması gerekir” şeklinde bir kural koymak çok işe yarar. Bu büyüklüğe takımca karar verilebilir 34’ü örnek olması için veriyorum. Böylece geliştirilen işlerin karmaşıklığı, eforu ve riski her bir kullanıcı hikayesi için birbirine yakın seviyede tutulur. Böylece geliştirme işini yaparken “Sustainable Pace” denilen sürdürülebilir hıza ulaşmak ve orada kalmak daha kolay olacaktır. Ayrıca biraz evvel anlattığım büyük bir kullanıcı hikayesini küçük parçalara bölmenin görülmeyen, akla gelmeyen şeyleri görünür kılması ve akla getirmesi cabasıdır.

Poker Planlama’nın İçerdiği Teknikler

Görüldüğü üzere, Poker Planlama’da uzman görüşü, benzeşim ve küçük parçalara bölme teknikleri beraberce kullanılmaktadır. Bu nedenle çok etkin bir maliyet verme, maliyeti belirleme aktivitesidir.

Burada dikkat edilmesi gereken önemli konu uzman görüşü bölümüdür. Uzman görüşü alınırken işi geliştirecek kişilere danışılması ve onların görüşünün istenmesi, işi sahiplenmelerini sağlar. Bu konu biraz borçlanma gibidir. Hiç kimse bir başkasının borcunu ödemek için elini taşın altına sokmaz fakat kendi borcunuzu ödemek için elinizden geleni yaparsınız. Başka birinin tahminde bulunduğu bir işi yapmak için canınızı dişinize takmazsınız fakat kendi verdiğiniz bir tahmini gerçekleştirebilmek için çalışırsınız.

T – Shirt Maliyet Verme

Sayılarla kullanıcı hikayelerinin maliyetini belirlemenin fazla analitik olduğunu ve 5 Hikaye Puanı mı yoksa 3 Hikaye Puanı mı diye tartışmanın fazla zaman aldığını düşünen takımlar T-Shirt büyüklükleriyle kullanıcı hikayelerinin büyüklüklerini belirler. Örneğin A kullanıcı hikayesi “extra small”, B kullanıcı hikayesi ise “large” olarak değerlendirilir. T-Shirt büyüklükleriyle kullanıcı hikayelerine harcanacak eforu belirlemenin en büyük avantajı takımdaki kişilere, sayılara takılmadan düşünme özgürlüğünü vermesidir. Böylece mutlak değere ulaşma isteğinin, içgüdüsünün önüne bir adım daha geçilir. Ayrıca analitik düşünce sürecinden uzaklaşarak daha esnek ve göreceli düşünce yapısının oluşmasına yardımcı olur.

Yukarıda saydığım avantajlar aynı zamanda T-Shirt büyüklükleriyle işin büyüklüğünü belirlemenin zayıf noktalarıdır. Çünkü numerik olmayan değerler süreci takip eden kişinin işini biraz daha karmaşık hale getirebilir.

İşin biraz da eğlenceli tarafına değinelim. Yaratıcı takımlar T-Shirt büyüklükleri yerine köpek ırklarıyla da kullanıcı hikayelerinin maliyetini belirlerler. Örneğin, A kullanıcı hikayesi tam bir Chihuahua’yken, B kullanıcı hikayesi Great Dane, C ise tam bir Pitbull çünkü çok risklidir.

Çevik yazılım geliştirmeye başlayan takımlar için T-Shirt büyüklükleriyle kullanıcı hikayelerini değerlendirmek iyi bir pratik olabilir.

Göreceli Toplu Değerlendirme

Göreceli Toplu Değerlendirme, hiç kullanmadığım bir tekniktir. Araştırmalarım sonucunda karşıma çıktı. David Green tarafından anlatılan Göreceli Toplu Değerlendirme’ye göre her kullanıcı hikayesi bir karta yazılır. Takım üyeleri, kartları okur ve kendilerine 3 referans kart belirler. Bunlar küçük, orta ve büyük hikayelerdir. Bir kullanıcı hikayesi küçük ise masanın en soluna, orta ise masanın ortasına ve büyük ise en sağına koyulur. Bir sonraki kullanıcı hikayesi küçük bir kullanıcı hikayesi ise o da masanın soluna konulur ve tüm hikayeler bu şekilde sıralanır.

David Green, sıralama yapıldıktan sonra her kullanıcı hikayesi için sayısal bir değer belirlenmesi gerektiğini söyler. En kolay kullanıcı hikayesi için 1 verilir. Onun iki katı zorlukta olan bir kullanıcı hikayesi içinse 2 verilerek maliyet verme tamamlanır. David, toplantıyı yöneten kişiye bir hatırlatmada bulunur; takımın detaylara fazla takılmaması gerektiği ve yapılan işin göreceli tahminleme olduğunu hatırlatması gerektiğidir.

Açıkçası Göreceli Toplu Değerlendirme birkaç adımdan oluştuğu için uzun bir yol gibi geliyor. Tabi kullansam belki de görüşüm tersine dönebilir. Bence kullanıcı hikayelerinin küçük, orta ve büyük olarak belirlenmesi bir projenin başında çok faydalı olacaktır. Yazı serisinin gelecek bölümünde bir projenin planlaması ve takibi nasıl yapılabilir konusuna değineceğim.

Serinin tüm yazılarına erişmek için bağlantıya tıklayabilirsiniz.