Herkese merhaba! Yazılım geliştirmeye başlamak için bilmeniz gereken muazzam miktarda teori var. Bazı uzmanlar (örneğin, Java ve diğer dilleri kullanan arka uç geliştiriciler) daha fazlasını bilirken diğerleri (örneğin, JavaScript ve React Native kullanan ön uç geliştiriciler) biraz daha az şey biliyor olabilir. Bununla birlikte, her iki grup da yalnızca teknik değil, aynı zamanda "örgütsel" bilgi birikimine de sahip olmalıdır. Bu "kurumsal" bilgi, ön uç ve arka uç geliştiriciler için örtüşen bir alandır. Bugün bu teknik olmayan, organizasyonel bilginin bir yönünden bahsetmek istiyorum. Bugün efor tahmini hakkında konuşacağız . Çünkü sadece Agile metodolojisini kullanma deneyimim var.(en popüler olarak kabul edilir), daha spesifik olarak Scrum çerçevesi, çaba tahminini Scrum bağlamında ele alacağım . En başta, efor tahmininin zor olduğunu söylemeliyim. Benim için bir geliştirici olarak işimin en zorlu/hoş olmayan yönlerinden biri bu. Bir görev için gereken çabaya ilişkin tahmininizi etkileyebilecek, dikkate alınması gereken birçok farklı faktör vardır. Ek olarak, gelecekteki geliştirme planları tahminlerinize dayanacaktır.
Kötü bir tahminde bulunursanız ne olur?
Bir geliştirici, bir görev için, görev için harcanan saatten çok daha fazla saat tahmin ederse, tahmin çok yanlış olduğu için uzmanlığı şüpheye düşebilir. Başka bir deyişle, çılgınca bir tahmindi. Aynı zamanda, bir geliştirici işi öngörülen sürede yapmazsa, müşterinin ürünü veya yeni özelliği yayınlama planlarını tehlikeye atmış olur. Bu iştir ve iş paradır. Çok az müşteri böyle bir fişten memnun olacaktır. Aslında, bu yüzden tahmin etmeyi sevmiyorum - çünkü bazen bir görevi tamamlamak için gereken süreyi doğru bir şekilde belirlemek çok zordur.
Zaman tahmini nasıl yapılır
Kural olarak, tahminler saat veya hikaye puanları cinsinden yapılır. Benim kişisel tercihim hikaye noktalarını kullanarak tahmin işlemini yapmaktır . Somut fiziksel nesneler hakkında yanılmak zordur, ancak hikaye noktaları biraz daha soyuttur. Yazılım geliştirme ekipleri genellikle tahminleri süre olarak sağlar: saatler, günler, haftalar, aylar. Bu zaman tahminleri öncelikle kişisel deneyime, tahmine ve/veya sezgiye dayalıdır. Bu durumda, geliştiriciler göreve bakar ve ne kadar zaman alacağına dair varsayımlarını ifade eder. Sonuç olarak, bu tahminler çok nadiren doğrudur, çünkü işin süresini etkileyebilecek çok fazla faktör vardır. Çevik metodolojiyi kullanan birçok takımın aynı zamanda hikaye noktalarını da kullanmasının nedeni budur . Haydi dalalım!
Hikaye noktaları nedir?
Hikaye noktası, belirli bir işlevsellik parçasını tam olarak uygulamak için gereken toplam çabanın tahminini ifade eden bir ölçü birimidir. yani akrabadan bahsediyoruzkarmaşıklık Ekipler, işin karmaşıklığına, iş hacmine ve risk veya belirsizliğe dayalı olarak hikaye noktalarında bir tahmin atar. Bu değerler genellikle işi daha verimli bir şekilde daha küçük parçalara bölmek ve böylece belirsizliği ortadan kaldırmak için atanır. Zamanla bu, ekiplerin belirli bir süre içinde neler başarabileceklerini anlamalarına ve sonraki iş parçalarını daha doğru bir şekilde planlamalarına yardımcı olur. Bu size tamamen mantıksız gelebilir, ancak bu soyutlama gerçekten kullanışlıdır: ekibi işin karmaşıklığı hakkında zor kararlar almaya iter. Planlama yaparken hikaye noktalarını kullanma nedenlerinden bazılarına bir göz atalım:
Yanlış zaman tahminlerinden kaçınabilirsiniz.
Zaman birimleri cinsinden yapılan tahminlerin aksine, hikaye noktaları, genel giderleri hesaba katmanıza izin verir: ekip üyeleri ve müşteri arasındaki iletişimler, çeşitli ekip tartışmaları ve planlama etkinlikleri ve ayrıca öngörülemeyen durumlar.
Her takım çalışmalarını farklı ölçekler kullanarak tahmin edecek, bu da kapasitelerinin (puanla ölçülen) farklı olacağı anlamına gelir.
Her hikaye noktasını atamak için bir ölçek tanımlayarak, çok fazla tartışma olmadan noktaları hızlı bir şekilde tahsis edebilirsiniz.
Hikaye puanları nasıl KULLANILMAZ?
Ne yazık ki, hikaye noktaları genellikle kötüye kullanılır. Hikaye puanları, insanları değerlendirmek, ayrıntılı teslim tarihlerini ve kaynakları tanımlamak için kullanıldıklarında ve bir performans ölçüsüyle karıştırıldıklarında yanıltıcı olabilir. Bunun yerine, ekipler bunları her görevin kapsamını/karmaşıklığını anlamak ve öncelikleri belirlemek için kullanmalıdır. Belki de önce daha zor görülen kısımlar ele alınmalı, böylece sprint bitmeden yapılabilir , muhtemelen daha kolay görevler daha sonraya kaydırılabilir. Size Scrum metodolojisi bağlamında bir sprintin ne olduğunu hatırlatmama izin verin :
Sprint, planlanmış bir işlevsellik parçasının uygulandığı tekrarlanabilir sabit bir zaman aralığıdır.
Bu sürenin uzunluğu, geliştirme başladığında belirlenir ve ekip ile müşteri arasında kararlaştırılır. Bu, iki haftalık veya bir aylık bir süre veya başka herhangi bir dönem olabilir. Kural olarak, tamamlanan iş müşteriye teslim edildiğinde sprint sonunda tamamlanabilecek işi planlamak için her sprint başında efor tahminleri yapılır.
Sprint sırasında tamamlanan iş müşteriye sunulduğunda buna demo diyoruz.
Demo, ürünü geliştirmedeki ilerlemenizi görmenize, müşteriden geri bildirim almanıza ve projenin gidişatını müşterinin vizyonuna göre ayarlamanıza yardımcı olur. Ama biraz dalıyoruz. Tahminlere geri dönelim. Tek bir geliştiricinin tüm görevler için tahminler sağlaması çok öznel olurdu. Dolayısıyla bu süreç genellikle bir ekip çalışmasıdır. Ekiplerin tahminler oluşturmak için kullanabileceği epeyce teknik var. Bugün en popüler tekniğe bakacağız: scrum poker . Bu teknik, scrum poker için moderatör olarak hareket edecek bir yönetici gerektirir . Bu, bir saldırı ustası veya muhtemelen bir PM olan biri olabilir .
Scrum pokeri nedir?
Scrum poker veya planlama pokeri, bir anlaşmaya varmaya dayalı bir tahmin tekniğidir. Esas olarak ilerideki işin karmaşıklığını veya yazılım geliştirme görevlerinin göreli boyutunu tahmin etmek için kullanılır. Hemen o scrum poker diyeceğimyaygın bir yazılım geliştirme uygulamasıdır ve bunun neyle ilgili olduğunu bilmeniz gerekir. Genellikle, bir ekibin belirli bir görev için ortak bir tahmin oluşturmasını kolaylaştırmak için bir uygulama veya web sitesi içerir. Bu nasıl olur? Ekip, birikmiş iş listesinden bir şeyler alır (yeni bir görev, bazı işlevler) ve olası tuzakları ve onunla ilişkili diğer nüansları kısaca tartışır. Daha sonra her katılımcı, karmaşıklık tahminlerini yansıtan bir sayı içeren bir kart seçer. Oh, bir şey daha, bu tahminleri yaparken, sıradan sayılar yerine Fibonacci dizisindeki sayıları kullanıyoruz . Fibonacci sayıları scrum pokerde popülerdir, çünkü aralarında giderek artan bir boşluk var (bir piramidin seviyelerine benzeyen). Bazı görevler son derece karmaşık olacak ve az sayıda hikaye noktasıyla paçayı sıyıramayacağız. Aşağıdaki anlamlara sahip bazı sıra dışı kartlar vardır:
Bilinmeyen uç nokta sayısı
Sonsuz uzun görev
Molaya ihtiyacım var
Daha az yaygın olan tahmin yöntemleri şunları kullanır:
Tişört bedenleri — S, M, L, XL
Köpek ırkları — chihuahua, pug, dachshund, bulldog, vb.
Ekip daha sonra aynı görev için farklı geliştiriciler tarafından verilen tahminleri karşılaştırır. Kabul ederlerse, o zaman harika! Değilse, farklı tahminlerin nedenlerinin (argümanların) tartışılması gerekir. Bundan sonra ekip, aşağı yukarı herkesin kabul ettiği tek bir tahmin oluşturmak için birlikte çalışır. Öyleyse poker neden ciddi yazılım projelerini planlamak için kullanılıyor? Bunun garip olduğunu kabul etmelisin. Gerçek şu ki, bu tür bir oyunlaştırma ekip üyelerini bağımsız düşünmeye teşvik eder ve ekip arkadaşlarıyla aynı anda tahminlerini açıklamaya davet eder. Bu da, bazı ekip üyelerinin diğerlerinin fikirlerine bağlı olduğu bir durum yaratmaktan kaçınır. Bu şekilde yapılmasaydı, daha az deneyimli geliştiriciler daha deneyimli ekip üyeleri tarafından sağlanan tahminlere bakar ve bunlara odaklanırdı. ve bu, kendi tahminlerini daha az yararlı hale getirir. Ancak aynı anda tahminlerin gösterilmesi bunu esasen imkansız kılıyor. Atlassian teklifleriplanlama sürecinde kullanmak için bir scrum poker uygulaması .
Çaba tahmini örneği
Ekibinizin tahminlere hikaye puanları atamak için aşağıdaki ölçeği oluşturduğunu varsayalım:
1. Bu tür bir görevle ilgili herhangi bir deneyiminiz var mı?
+1 — Bu görevi daha önce yaptım
+2 — Bu görevi yapmadım ama benzer bir görev üzerinde çalıştım
+3 — Bu görevi yapmadım ve benzer bir şeyle ilgili deneyimim yok
2. İşlevsellik için gereken iş hacmi
+1 — Küçük hacim
+2 — Ortalama ses
+3 — Büyük hacim
3. İşlevselliği uygulamanın karmaşıklığı
+1 — Kolay
+2 — Ortalama
+3 — Zor
4. İşlevselliği test etmenin karmaşıklığı
+1 — Kolay
+2 — Ortalama
+3 — Zor
Her görev için Scrum poker oynanır ve aşağıdaki gibi bir tahminde bulunursunuz:
Daha önce hiç benzer işlevsellik uygulamadınız: +3
İşlevsellik ortalama boyuttadır: +2
Uygulama oldukça karmaşık olacaktır: +3
İşlevsellik için testler yazmak oldukça karmaşık olacaktır: +3
Her bileşeni topladığınızda toplam 11 hikaye puanı alırsınız, ancak böyle bir kart yoktur, bu nedenle 13'ü önerirsiniz. Bir iş arkadaşınız görev için aşağıdaki tahmini ileri sürer:
Daha önce benzer bir görevde çalıştı: +1
İşlevsellik ortalama boyuttadır: +2
Uygulama ortalama karmaşıklıkta olacaktır: +2
İşlevsellik için testler yazmak, ortalama karmaşıklıkta olacaktır: +2
Ara sonucu 7 hikaye puanıdır, ancak bu sayı Fibonacci serisinde yoktur, bu nedenle en yaklaşık sayı olan kartı sunar - 8. Diğer ekip üyeleri de tahminlerini öznel görüşlerine göre yapar. Sonra herkes kartlarını gösterir ve 8 öneren bir geliştirici dışında, iş arkadaşlarınızın neredeyse tamamının 13 tahmini verdiğini görürsünüz. Bu durumda, daha düşük tahmininin nedenlerini açıklamak için konuşmasına izin verilir. Diyelim ki şu gerekçeyi sunuyor: Daha önce aynı görev üzerinde çalıştı ve göründüğü kadar zor değil. Sonunda, ekibin geri kalanını fikrini 13'ten 8 hikaye puanına değiştirmeye ikna eder ve bu görevi üstlenene yardım edeceğini söyler. Ya da belki kendisi yapacaktır. Her halükarda, Diğerlerinin argümanlarını kabul edip etmemesi önemli değil, çünkü öyle ya da böyle göreve bir tahmin atanacak ve ekip bir sonrakini düşünmek için ilerleyecek. Başlangıçta, sonraki zaman diliminde (sprint) yapmayı planladığınız iş miktarına ilişkin tahminler gibi, tahminler de yanlış olacaktır. Sonuçta, bu tahminler tahminler kullanılarak yapılmıştır. Bir süre sonra, belki üç ay sonra ekip, görevler için gereken süreyi daha doğru tahmin etmeye başlayacak ve ekibin bir sprintte gerçekleştirebileceği ortalama iş miktarı ortaya çıkacaktır. Ancak bu, işin kapsamı için genel bir plan yapmak için bir süreçtir. Esas olarak zamana odaklanır, ancak bu durumda birçok farklı ilgili faktör olabilir. Örneğin, bir geliştiricinin iki haftalığına tatile gittiğini varsayalım. Belirli bir miktarda planlanan işi (planlanan işlevsellik) kesmeniz gerekecektir. Veya ekibe yeni bir geliştiricinin katıldığını ancak henüz tam olarak hızlanmadığını varsayalım, bu nedenle ona projeye aşina olması için birişe alım süreci. Bu, projenin karmaşıklığına bağlı olarak iki hafta sürebilir veya bir hafta sürebilir. Hepsi bugün için! Umarım, yazılım geliştirmenin teknik olmayan gerekli bir yönü olan efor tahmini bilginizi biraz geliştirdim. Bu konunun daha derinine inmek ve scrum'un ayrıntılarına inmek istiyorsanız, Jeff Sutherland'ın yazdığı "SCRUM" kitabını okumanızı şiddetle tavsiye ederim. Sonuçlar hakkında herhangi bir söz veremem çünkü okuduktan sonra can sıkıcı bir saldırı ustası olma arzunuz olacak =D
Bugün bu teknik olmayan, organizasyonel bilginin bir yönünden bahsetmek istiyorum. Bugün efor tahmini hakkında konuşacağız . Çünkü sadece Agile metodolojisini kullanma deneyimim var.(en popüler olarak kabul edilir), daha spesifik olarak Scrum çerçevesi, çaba tahminini Scrum bağlamında ele alacağım . En başta, efor tahmininin zor olduğunu söylemeliyim. Benim için bir geliştirici olarak işimin en zorlu/hoş olmayan yönlerinden biri bu. Bir görev için gereken çabaya ilişkin tahmininizi etkileyebilecek, dikkate alınması gereken birçok farklı faktör vardır. Ek olarak, gelecekteki geliştirme planları tahminlerinize dayanacaktır.
Aşağıdaki anlamlara sahip bazı sıra dışı kartlar vardır: 
