Eski kod tabanında zaman maliyetlerinin tahmini

Son zamanlarda, çok eski bir monolitik uygulamanın mikro hizmet tabanlı bir mimariye geçirildiği bir proje üzerinde çalışmaya başladım.

Eski kod temeli çok dağınıktır ('spagetti kodu') ve genellikle görünüşte basit bir işlev (örneğin "multiplyValueByTen" olarak adlandırılır) daha sonra "3 farklı şemadaki 10 tabloyu içeren binlerce doğrulama kodu satırı" olarak kendini gösterir.

Şimdi patronum (haklı olarak) yeni mimaride X özelliğini yazmanın ne kadar süreceğini tahmin etmemi istiyor. Ancak gerçekçi bir tahmin yapmakta zorluk çekiyorum; sıklıkla derece nedeniyle yukarıda belirtilen nedenlerden görevi hafife ve ben zamanında bitirmek olamaz çünkü kendimi rezil.

Mantıklı olan şey gerçekten koda girmiş gibi görünebilir, her dalı not alın ve diğer işlevlere çağrı yapın ve ardından zaman maliyetini tahmin edin. Ancak eski kodu belgelemekle yeni sürümü yazmak arasında gerçekten küçük bir fark var.

Böyle bir senaryoya nasıl yaklaşmalıyım?

Eski kod yeniden düzenleme işleminin nasıl çalıştığını tam olarak anlasam da sorum, "yeniden yapılandırma / yeniden yazma nasıl yapılır?" İle ilgili değil. ama "X bölümünü yeniden yazmak / yeniden yazmak ne kadar sürer?"

Bob Martin'in "Temiz Kodlayıcısı" nı (ve bu sırada “Temiz Kod” u) okuyun. Aşağıdakiler bellekten geliyor ancak şiddetle kendi kopyanızı satın almanızı öneriyorum.

Yapmanız gereken, üç puan ağırlıklı bir ortalama. Her iş için üç tahmin yaparsınız:

• en iyi durum senaryosu - her şeyin yolunda gittiğini varsaymak (a)
• en kötü durum senaryosu - her şeyin ters gittiğini varsaymak (b)
• gerçek tahmin - muhtemelen alacağını düşündüğünüz şey (c)

Tahmininiz daha sonra (a + b + 2c) / 4

• Hayır doğru olmayacak. Tahmin etmenin daha iyi yolları var, ancak bu yöntem hızlı, anlaşılması kolay ve en kötü durumu düşünerek iyimserliği azaltıyor.
• Evet, yöneticinize, kodu bilmediğinizi ve tahminleri iyileştirmek için her seferinde kodu araştırmaya uzun zaman harcamadan kesin, doğru tahminler yapmanın sizin için öngörülemeyeceğini açıklamanız gerekir (bunu yapmak için teklif Diyelim ki sadece kaç gün süreceğini kesin olarak tahmin etmek için n güne ihtiyacınız var. Eğer bir "JuniorDev" iseniz, makul bir yönetici için bu kabul edilebilir olmalıdır.
• Ayrıca yöneticinize, tahminlerinizin ortalama olduğunu, en iyi durum, en kötü durum ve olası duruma göre açıklamalısınız ve onlara hata çubukları da veren rakamlarınızı vermelisiniz.
• Bir tahminde pazarlık ETMEYİN - yöneticiniz her tahminde en iyi vakayı kullanmaya çalışırsa (aptaldırlar - ancak bazılarıyla tanıştım) ve sonra zorbalık / son tarihi vurmaya çalışmanız için sizi motive ederler, Bazen hayal kırıklığına uğrayacaksın. Tahminlerin arkasındaki mantığı açıklamaya devam edin (en iyi durum, en kötü durum ve muhtemel durum) ve çoğu zaman ağırlıklı ortalamaya yaklaşmaya devam edin. Ayrıca, kendi amaçlarınız için tahminlerinizin bir elektronik tablosunu saklayın ve tamamladığınızda gerçeklerinizi ekleyin. Bu, tahminlerinizi nasıl değiştireceğiniz konusunda size daha iyi bir fikir vermelidir.

Düzenle:

Buna cevap verdiğimde varsayımlarım:

1. OP bir Junior Developer (seçilen kullanıcı adına göre). Bu nedenle verilen herhangi bir tavsiye, geliştirme ortamının olgunluğuna bağlı olarak daha karmaşık tahminler yürütmesi beklenen bir Proje Yöneticisi veya Ekip Lideri açısından değildir.
2. Proje Yöneticisi, birkaç ay sürmesi planlanan çok sayıda görevden oluşan bir Proje planı hazırladı.
3. OP'den, proje planını beslemek ve ilerlemeyi izlemek için kullanmak için makul derecede doğru bir sayı (olasılık eğrisi değil :)) isteyen Proje Yöneticisi tarafından verdikleri görevler için bir takım tahminler sağlamaları istenmektedir.
4. OP, her bir tahminde bulunmak için haftaları yoktur ve aşırı iyimser tahminler vererek daha önce yakılmış ve havaya parmağınızı sokmaktan ve "2 hafta, özellikle de bu durumda bu durumda 2 aydır" yada daha fazla".

Üç nokta ağırlıklı ortalama bu durumda iyi çalışıyor. Teknik olmayanlar için hızlı, anlaşılır ve birkaç tahminde yaklaşan doğruluk derecesine göre sıralanmalıdır. Özellikle OP, tahminlerin ve gerçekleşenlerin kaydını tutmak konusunda tavsiyemi alırsa. Gerçek dünyadaki "En kötü durum" ve "En iyi durum" un ne olduğunu bildiğiniz zaman, gerçekleri gelecekteki tahminlerinize göre besleyebilir ve hatta en kötü durum düşündüğünüzden daha kötüyse proje yöneticiniz için tahminleri bile ayarlayabilirsiniz.

Bir örnek çalışalım:

• En iyi durum, deneyimden en hızlı şekilde yaptığım en basitinden birincisi, bir haftaya kadar başlamaktı (5 gün)
• En kötü durum, deneyimden, her yerde bağlantıların olduğu bir zamandı ve 6 hafta (30 gün) beni aldı.
• Gerçek Tahmini, muhtemelen 2 hafta sürer (10 gün)

5 + 30 + 2x10 = 55

55/4 = 13.75, Başbakanınıza söylediğiniz şey bu. Belki 14 güne kadar yuvarlanırsın. Zamanla, (örneğin on görev), ortalamanın üzerinde olması gerekir.

Formülü ayarlamaktan korkma. Belki görevlerin yarısı kabus olur ve sadece yüzde onu kolaydır; Böylece a / 10 + b / 2 + 2c / 5 oranını hesaplarsınız. Deneyiminizden öğrenin.

Not: Başbakan'ın kalitesi hakkında herhangi bir varsayımda bulunmuyorum. Kötü bir PM, onay almak için proje kuruluna kısa bir tahmin ve ardından proje ekibine taahhüt ettikleri gerçekçi olmayan süreye ulaşmak için zorbalık yapacak. Tek savunma, bir kayıt tutmaktır, böylece tahminlerinizi verirken ve onlara yaklaşırken görülebilir.

Bu yarı çevik bir yaklaşım sunmak için iyi bir an olabilir. Saat / gün cinsinden tahmin yapmak yerine, bir fibonacci tipi ölçek tahsis ettiyseniz ve her bir göreve ne kadar büyük olduğuna bağlı olarak bir değer verdiyseniz:

• 0 - anlık
• 0.5 - hızlı kazan
• 1 - basit değişiklik
• 2 - birkaç basit değişiklik
• 3 - daha zorlu
• 5 - biraz düşünmeyi gerektirecek
• 8 - önemli miktarda iş
• 13 - Muhtemelen yıkılması gereken büyük bir iş yığını
• 20 - Kesinlikle yıkılması gereken devasa bir iş parçası

Daha sonra, bunun gibi bir sürü görevi tahmin ettikten sonra, üzerlerinde çalışırsınız. Çevik bir ortamda, bir haftada kaç puan kazandığınızı ölçen 'hız' geliştirirsiniz. Birkaç haftalık bir test et ve öğren yaptıktan sonra (bunu yöneticinize sürecin bir parçası olarak satabilirsiniz - "Birkaç haftalık teste ihtiyacım olacak ve tahmin sürecini anlamayı öğreneceğim") Her hafta kaç noktaya iteceğinize daha çok güveniyorsunuz ve bu nedenle puanlarınızı daha kolay tahmin edebileceğiniz zamana çevirebiliyorsunuz.

https://pm.stackexchange.com/questions/4251/why-would-teams-use-the-fibonacci-sequence-for-story-points

https://stackoverflow.com/questions/9362286/why-is-the-fibonacci-series-used-in-agile-planning-poker

Törenleri içermeyeceği için bu gerçekten çevik değil, ancak OP'den kendi başına olduğu fikrini alıyorum. Umarım bu yaklaşım daha güvenli tahminler verebilir.

Yapacağınız ilk şey, şu anda bir işlem yapmanın ne kadar sürdüğü hakkında veri toplamaya başlamaktır. Takımınızın performansıyla ilgili veriniz ne kadar fazlaysa, o kadar iyidir. Tahtanın her tarafında olacak, ama şu anda bunun için endişelenme. Gerçek bu ve patronuna gerçeği göstermen gerek.

O zaman gidip birkaç kitap almaya gideceksin.

1. Yazılım Tahmini: Siyah Sanatın Demonte Edilmesi Steve McConnell
2. Michael Feathers'ın Eski Koduyla Etkili Çalışma

McConnell'in kitabı size veri toplamaya başlamanızı söyleyecek ve daha doğru tahminler almak için nasıl kullanılacağını açıklayacaktır. Her zaman 3 puanlık bir tahmin verin! Her zaman. Kitabın, düşük kod kalitesinin tahminlerinizi ne kadar etkileyeceği hakkında konuşan kısımlarını seçtiğinizden emin olun. Onları patronuna göster.

Eğer doğru tahminler şirket için önemliyse, Feather'ın kitabından öğrendiğiniz şeyleri uygulamaya başlamanız gerekeceğini açıklayın. Hızlı, sorunsuz ve tahmin edilebilir bir şekilde gitmek istiyorsanız, kodu yeniden düzenlemeye başlamanız ve bir test donanımına sokmanız gerekir. Ben senin olduğun yerdeyim. Gelişme süresi tamamen tahmin edilemez, çünkü neyi kırabileceğinize dair hiçbir fikriniz yok, değil mi?… Evet. Test bandına sokun. Bu testleri çalıştırmak için kullanılan bir CI sunucusu da zarar görmedi.

Son olarak, patronunuza işlerin bir süre daha tahmin edilemeyeceğini açıklayın. Muhtemelen birkaç yıl, ancak bu gelişme günlük olarak kolaylaşacak ve daha fazla veriye sahip olduğunuzdan ve kod daha iyi hale geldiğinden tahminler daha doğru hale gelecektir. Bu şirket için uzun vadeli bir yatırımdır. Geçenlerde bunu yaşadım, çoğunlukla tahmin edilebilir olmak yaklaşık 2 yıl sürdü.

Kodları tahmin etmekten daha fazla bahsettiğimi biliyorum, ancak asıl gerçek şu ki, tahminlerinizin eski kod tabanını evcilleştirene kadar berbat olacağı yönünde. Bu arada, ne kadar süreceğini ölçmek için tarihi performansı kullanın. Zaman geçtikçe, tahminlerinizde belirtmek üzere kodu zaten alıp almadığınızı dikkate almak istersiniz.

Şimdi patronum haklı olarak bana yeni mimaride X özelliğini yazmanın ne kadar süreceği konusunda bir tahmin soruyor. Ancak gerçekçi bir tahmin yapmakta zorluk çekiyorum; Sık sık, yukarıda belirttiğim nedenlerden dolayı görevi küçümsüyorum ve zamanımı bitiremediğim için kendimi utandırıyorum.

Belki bir tahmin yapmayı düşünüyorsun . Eski kodda çalışmak zorundayım ve daha resmi bir tahmin yaptığımda, genellikle iki ya da üç tane yaparım :

1. Birincil Tahmin - kazmaya biraz zaman harcamak zorunda olduğumu varsayarsak, ancak mimari istediğimiz değişikliklere izin veriyor
2. Angelic Estimate - her şeyin şeffaf / kolay bulunabileceğini ve sadece küçük değişiklikler yapmak zorunda olduğumu varsayıyor (bazen dışarıda bıraktığım şey… özellikle de belirli bir kod tabanında sadece şeytanlar olduğunu bildiğimde)
3. Abyssal Tahmini - eski kodun temel yapısının istenen özellik ile uyuşmadığını ve işleri yürütmek için büyük refactoring yapacağımı varsayar.

Her üç tahmin de, bu özelliğin kendi başına ne kadar zor olduğunu, bu genel kod temeliyle yaşadığım herhangi bir deneyimi ve değişime karşı duyduğum içgüdüleri (bulduğum oldukça doğru olabilir) göz önünde bulunduruyor

Bu tahminler ortaya çıktıktan sonra, müdürümün üzerinde çalıştığımız gibi göründüğü bilgiyi güncel tutuyorum. Görünüşe göre bir cehennem özelliğine bakıyoruz, o zaman onu feda etmek zorunda kalabiliriz - oldu. Patronunuz belli bir miras kanunu için berbat özellikler olduğunu kabul edemezse, onlara iyi şanslar diliyorum, çünkü çok zor ve sinir bozucu bir hayata sahip olacaklar.

Bu tür bir sorunla karşılaştığımda, tahminlerimde aralıklar bırakmaya güvenmiştim. Patronlarıma "Bu kod temeli üzerinde manşet dışı iyi tahminler yapmak zordur. Bir tane istersen, çok geniş bir tahminde bulunacağım." Bir keresinde bir tahmin olarak "3 gün ila 3 yıl" verdim. Bunun popüler bir tahmin olmadığını söylemeye gerek yok ama verdiğim şey buydu.

Bunun anahtarı, çalışma ilerledikçe tahminlerimi güncelleyeceğim bir anlaşma. Öyleyse "XYZ Uygula, ne kadar sürecek?" cevabım "bir gün ile 4 ay arasında bir yerlerde olabilir. Ancak, birkaç saat boyunca koda bakmama izin verirseniz, o penceredeki belirsizliği azaltabilirim." Sonra gidip koda baktım ve "2-4 hafta" ile geri dönüyorum. Bu hala ideal bir pencere değil, ama en azından idare edilebilecek bir şey.

Bunun birkaç anahtarı var:

• Nedeniyle bu tahminler daha iyi bir konuşma olarak işlem görmeleri patron ikna edecektir görev bunu çalışırken nasıl göründüğünü hakkında daha fazla bilgi. Bu, patronunuzun sadece bir tahmin isteyip istemedikleri konusunda sahip olamayacakları bilgileri edinmesi için bir fırsattır.
• Hangi ticari kod geliştirme hızına karşılık tahminleri iyileştirme konusunda ileriye yönelik seçenekleri önerin. Onlara dönebilecekleri fazladan bir topuz verin. Bazen patronlar bir işin sadece yapılması gerektiğini bilirler ve sadece bir oyun sahası tahminine ihtiyaçları vardır. Diğer zamanlarda bir görevin artılarını ve eksilerini yönetiyorlar ve tahminleri hassaslaştırma yeteneği değerli.
• Mümkünse, aynı zamanda sinerji bonusları da sunacağım. Çoğu zaman birçok işte fayda sağlayacak mimari gelişmeler vardır. Eğer "1-2 ay sonra, ancak X’in yükseltilmesiyle 2 hafta sürebilir" olan 10 görevim varsa, X’in yükseltilmesi için alabileceği 20 haftayı satmak daha kolaydır.

Gittikçe güncellenen bir dizi almak konusunda rahat olmayan bir patronum varsa, onlara tek bir numara ve metodolojimi vereceğim. Metodolojim, genç bir geliştirici olarak bana söylenen bir kural ve Hofstader yasasının bir birleşimidir .

Görevin ne kadar süreceğini düşündüğünüzü tahmin edin, ardından bu sayıyı dört katına çıkarın ve bunu tahmininiz olarak verin.

ve

Hofstadter Yasası: "Hofstadter Yasasını hesaba katsanız bile, her zaman beklediğinizden daha uzun sürer."

Mantıklı olan şey gerçekten koda girmiş gibi görünebilir, her dalı not alın ve diğer işlevlere çağrı yapın ve ardından zaman maliyetini tahmin edin. Ancak eski kodu belgelemekle yeni sürümü yazmak arasında gerçekten küçük bir fark var.

Sorununun çözümü bu. Gereksiniminiz olmadığını tahmin edemezsiniz. Patronunuza kodlamaya başlamadan önce bunu yapmanız gerektiğini söyleyin. Birkaç fonksiyon ve modülden sonra, hepsinin tutarlı bir şekilde kodlanmış olduğunu keşfedebilirsiniz (bu durumda kötü), bu nedenle gelecekteki tahminleri belirlemek için bir temeliniz vardır. Kodlamanın daha da kötüleştiğini tespit ederseniz, tahmininizi ayarladığınızdan emin olun.

Patronunuzun bir tahmin istediğini anlıyorum, ancak bu bilgilerin nasıl kullanıldığını bilmeden, tahminlerinizin tam olarak ne olması gerektiğini bilmiyoruz. Onunla bir konuşma yap ve öğren. Patronuna vermek için sadece bir numaraya ihtiyacı olursa, tahminleri bir miktar şişirebilir ve bir sayı sağlayabilirsiniz. Bu işlem tamamlanıncaya kadar kodunuzu ödemeyi bekleyen müşteriler için, kesin satır son tarihlerinin önemli gelir getirip getirmeyeceğini öğrendiğinizden emin olun.

Böyle bir durumda iyi tahminler vermenin mümkün olduğuna inanmıyorum. Temel problem şu ki, bunu yapmanın büyük bir kısmı tam olarak ne yapması gerektiğini bulmaktır.

Bu gibi durumları, neye benzediğini belirten bir tahmin vererek, ancak sürprizlerin muhtemel olduğu mağara ile ele alıyorum. Eski kodlar konusunda çok fazla uğraşmama rağmen, girdilerle ilgili çok kötü sürprizler yaşadım - birkaç saatin birkaç haftaya dönüştüğünü ve bir kez bunun imkansız hale geldiğini gördüm. önemli kazma Belirli bir durumda, çizim tahtasına geri dönecek kadar veriye sahip olmadığımı anladım.) Neyse ki, patronum böyle tahminler verdiğimde anlıyor.

Tahmin, bazı insanların asla iyi öğrenemedikleri bir beceridir. İyi bir tahmin edemeseniz bile, bir geliştirici olarak sizi işe yaramaz yapmaz. Belki takım arkadaşları veya yönetim boşlukları doldurur. Ben çok kötüyüm, yine de çoğu takım benimle çalışmaktan hoşlanıyordu. Sakin ol, takım kur ve yeniden inşaa devam et.

Teknik borç size küçük zorluklar yaşatır, ancak borç üretmeyi bitiren bir şirketin / ekibin, takım ruhunda veya yönetiminde herhangi bir değişiklik olmadığı sürece borç vermeye devam edeceğini unutmayın. Kod sadece sosyal sorunları yansıtıyor, bu yüzden asıl konulara odaklanın.

Bir brownfield projesinde özellikleri tahmin etmek için bir sezgisel tarama kullandık: Bu özelliği bir yeşil alan projesinde daha önce herhangi bir uygulama yapılmadan uygulamanın ne kadar süreceğini tahmin ettik . Sonra, mevcut tahminleri temizlemek için bu tahminin 2 ile çarpılmasını sağladık.

Bu faktör, kuplaj miktarına ve genel kod boyutuna bağlıdır, ancak bu şekilde bazı özellikler yaparsanız, bu faktörü gerçek kanıtlara dayanarak enterpolasyon yapabilirsiniz.

Patronunla oturup gözlerinin doğrudan içine bakıp şunu söylemelisin:

'Patronu dinle! Burada sadece refactoring yapıyoruz. Sunulacak yeni bir işlev yoktur ve bu işlevi bekleyen müşteriler yoktur; bu yüzden herhangi bir son tarih olmamalıdır. Bu, sürdüğü sürece alacaktır, yapmamız gerekip gerekmediğine karar vermeniz gerekir. '

İşaret etmek ve sandalyenizde öne oturmak gibi güçlü iddialı gestülasyonlar kullanın.

Alternatif olarak, onu mutlu etmek için bazı numaralar oluşturabilirsiniz. Ancak yüzleşelim, işin yarısına kadar olana kadar tahminleriniz oldukça yanlış olacaktır.