Nesnel tahminler neden yazılım geliştirmede işe yaramıyor?

Bir yazılım projesinin gerektirdiği çabayı objektif olarak tahmin edebilir misiniz? Bu rakamlar sonuç olarak bir özelliğin uygulanmasının ne kadar sürdüğünü ve maliyetinin ne kadar olduğunu açıklığa kavuşturacaktır. Bu, geliştirme hizmetlerini işe alırken yardımcı olabilir.

Çevik yöntemlerle, bir hikayenin uygulanıp uygulanmayacağına karar vermek için toplantıların planlanmasında bir özelliğin taahhüdü bir hikaye olarak tahmin edilebilir. Bu isteğe bağlıdır: NoEstimates anahtar sözcüğü herhangi bir çaba tahmini gerektirmeyen projeleri tanımlar. Avantajı, tahminler için gereken çabanın ortadan kaldırılması ve hikaye geliştirmek için kullanılabilmesidir. Tüm ekip üyelerinin şu anda en değerli özellik üzerinde çalışıyor olması yeterlidir. Woody Zuill bu alanda öncüdür ve hiçbir zaman farklı çalışmamıştır.

Bir hikaye tahmini genellikle bir referans hikayesine veya bir boyutu atanmış bir özelliğe dayanır. Diğer hikayeler, hikaye tahmin ekibi tarafından bu referansa göre tahmin edilmektedir. Buna takımın hızı da eklendi. Yineleme başına uygulanan hikaye noktalarıyla ölçülür ve proje boyunca değişebilir.

Nesnel tahminler?

Yani tahmin objektif değil çünkü ilgili takımı kapsıyor ve hız da zamanla değişiyor. Ancak tahmin metodolojisi hedefe ulaşır: Ekipler için çalışmayı planlamanıza olanak tanır. Referans geçmişi ve hız ile analojiyi tahmin ederek ekibin neyi başarabileceğine dair nispeten iyi bir tahmin yapmak da mümkündür.

Elbette bu ölçümleri nesnelleştirmeyi deneyebilirsiniz. Örneğin, tek tip bir referans hikayesi seçebilirsiniz. Çok daha ileri giden yaklaşımlar var. İşlev noktası yöntemi, bir teknik gereksinimin nesnel karmaşıklığını işlev noktalarında ölçmeye çalışır. Ancak bu yöntemlerin tahminlerinde de farklılıklar vardır. Ayrıca tahmin etme konusunda deneyim gerektirirler ve karmaşıktırlar. COCOMO gibi teknikler, sonuçların kesin tahminler değil, yalnızca kaba tahminler olduğu konusunda bile uyarıda bulunuyor.

Bu tahminlerin faydası şüphelidir: projeler her zaman kapsam değiştirir. Yazılım pratikte kullanıldığında yeni arzular ortaya çıkıyor. Yazılım geliştirme, mühendislerin ve kullanıcıların iş süreçlerini yazılımla en iyi şekilde nasıl destekleyebileceklerini birlikte öğrendikleri bir süreçtir. Yeni bir şey öğrendiğinizde kapsamınızı değiştireceksiniz. O zaman orijinal akış hızına ilişkin kesin tahminlerin artık pek bir değeri kalmaz ve ilave hassasiyet için çaba harcamaya değmez. Belki de pratikte çevik tahminin kullanılmasının nedeni budur, ancak bundan daha karmaşık yöntemler pek yoktur.

Genel olarak projelerin taahhüt yönüne yapılan vurgu sıklıkla abartılmaktadır. Herhangi bir yatırım gibi, bir yazılım yatırımının da yatırımın kendisinden daha fazla, ideal olarak kat kat daha fazla değer üretmesi gerekir. Ancak değer tahmini, çabaya kıyasla çoğu zaman göz ardı ediliyor gibi görünüyor.

Başlatmak

Çok başarılı yazılımlar geliştiren çok küçük ekipler var. Bu tür aykırı değerler, objektif bir tahminin mümkün olup olmadığı sorusunu gündeme getiriyor. Instagram, satın alınmadan önce bir milyar dolar değerindeydi ve yalnızca 13 çalışanıyla küresel ölçekte bir sistem işletiyordu. Satın almadan önce WhatsApp'ın 900 milyon kullanıcısı vardı; Bu sistemi 50 mühendis geliştirdi ve işletti. Bu, köklü şirketlerdeki birçok BT projesinde yer alan çalışan sayısının çok küçük bir kısmıdır.

Ancak bu uygulamaların sadece basit bir fotoğraf paylaşım veya mesajlaşma uygulaması olduğu ortaya çıktı. Bu düşük personel maliyetlerini açıklıyor mu? Sigorta veya tasarruf sözleşmesi de basittir: Para ödersiniz ve belirli koşullar altında parayı geri alırsınız. Arama motorları da kolaydır; belgeleri indekslemenize ve aramanıza olanak tanıyan standart yazılımlar bile vardır.

Yüzeysel düzeyde her şey basit görünüyor. Sorunun karmaşıklığı ancak ayrıntılara baktığınızda ve sorunu gerçekten anladığınızda ortaya çıkar.

Karmaşıklığı ne olursa olsun: Bir projenin ekonomik başarısı aslında en önemli sonuçtur. Instagram ve WhatsApp'ın gerçekten etkilediği nokta burası: Milyarlarca değer yarattılar. Bu neredeyse yalnızca başarılı start-up'lar için mümkündür. Her başarılı start-up'a karşılık, başarılı olmayan pek çok girişim vardır.

Kurulu şirketler

Kurulu bir şirketin bir fotoğraf paylaşım uygulaması veya mesajlaşma uygulaması oluşturması gerektiğini varsayalım. Bunu tipik mekaniğiyle inşa edecekti: potansiyel olarak yüzlerce geliştirici, gelişmiş proje yönetimi ve proje planları. 13 Pazara girmek için merkezi bir sistem geliştiren kişilerin risk olarak algılanma olasılığı daha yüksektir. Büyük ekipler ve projeler aynı zamanda katılan herkes, yöneticiler ve aynı zamanda teknisyenler için de büyük bir prestij taşır. Son olarak, kurulu şirketlerin genellikle birçok yazılım projesi vardır ve yeni kurulan şirketlerden farklı olarak şirketin hayatta kalması genellikle bunlardan hiçbirine bağlı değildir. Yani basınç nesnel olarak daha düşüktür.

Yani tamamen farklı düzeyde bir çabaya yol açan yeterli mekanizma var. Bu nedenle kurulu bir şirket, tipik olarak kullandığı mekanizmalarla bir yazılım sistemi geliştirecek ve kendisini bir start-up'tan farklı bir rekabet ortamında bulacaktır. Ancak bir start-up'ta ekonomik koşullar, bir şeyin mümkün olduğu kadar çabuk başlatılmasını gerektirecek şekildedir ve buna karşılık gelen sonuçlar da vardır.

Sorunları farklı şekilde çözün

Ayrıca köklü bir şirketin fotoğraf paylaşımı veya mesajlaşma gibi bir sorun için birebir aynı uygulamayı oluşturması da pek mümkün değil. Uygulamaların entegre edilmesi gereken BT ortamı farklıdır. Bir start-up'ın ekonomik koşullar nedeniyle yapamayacağı gereksinimler genişletilebilir.

Bu nedenle bir start-up, geleneksel olarak karmaşık yazılım sistemleriyle uygulanan alanlarda bile muhtemelen çok daha basit bir çözüm geliştirecektir çünkü pazara hızlı bir şekilde girmeleri ve çok sınırlı bir bütçeye sahip olmaları gerekir.

Nesnel çabayı değerlendirmeye çalışmak daha da anlamsızdır: Yazılım, bir kuruluşun karşılaştığı bir sorunu çözer. Örneğin organizasyon yeni bir ürün yaratmak istiyor. Bunu yapmak için organizasyona sabitlenmiş sosyal süreçlere dayanır. Bir startup'ın köklü bir şirkete yaklaşımı ne kadar yabancıysa, bir startup'a da köklü bir şirketin yaklaşımı o kadar yabancıdır. Bu sadece geliştirme sürecini değil aynı zamanda ürünü de içerir.

Sonuçta endişelenmemeliyiz. Her şey verilen durumda nasıl daha iyi yazılım geliştirebileceğimize bağlı. Ve bunun için her zaman çok sayıda ve heyecan verici seçenek vardır.

tl; Dr.

Bir özellik için gereken eforun objektif olarak belirlenmesi büyük bir çaba ile mümkün olabilir. Ancak planlama gereksiz ve zaman alıcı olduğundan çoğu projede bu tür teknikler kullanılmaz bile. Yazılım aynı zamanda bir iş sorununun çözümünün “sadece” bir uygulamasıdır. Organizasyonlar sorunlara farklı yaklaşırlar, dolayısıyla çözüm ve çaba da sırf bu nedenle farklı olacaktır. Ancak verimlilik ve daha iyi bir yaklaşımla ilgili soru sorulabilir ve sorulmalıdır.

(Ben)