Daha büyük bir yazılım projesi için gereken süreyi tahmin etmenin zor olduğunu nasıl açıklayabilirim?

Küçük bir geliştiriciyim ve daha büyük bir yazılım projesini bitirmenin ne kadar zaman alacağını tahmin etmekte zorlanıyorum. Genel olarak mimariyi nasıl yapılandıracağımı biliyorum, ancak hangi ayrıntıları yapmam gerektiğini ve hangi sorunları çözmem gerektiğini bilmek zor. Bu yüzden daha büyük bir projeyi bitirmenin ne kadar zaman alacağını tahmin etmek zor, çünkü hangi sorunları çözmem gerektiğini ve bunları çözmenin ne kadar sürdüğünü bilmiyorum.

Bunu bir yazılım geliştiricisi olmayan bir kişiye nasıl açıklayabilirim ?

Ondan, dünyanın ıssız bir köşesinde uzaktaki bir yere erişmesinin ne kadar süreceğini tahmin etmesini isteyebilirsiniz. Aşırı bir örnek olarak, çok az sayıda (varsa) insanların tırmandığı Himalayalar'da daha az bilinen bir zirve seçelim. Yolculuğa başlamadan önce çok fazla hazırlık yapması ve pratik yapması gerekiyordu, ayrıca her biri aylarca yıl boyunca yolculuğu geciktirebilecek bir grup izin ve ... iyi bir destek ekibi ... sonra tepeye çıkacaktı. yokuşta zirveye doğru tırmanmaya başlaması için iyi havalarda beklemesi ve dua etmesi gerekir. vb. Bunların çoğunun, önceden deneyimle olsa bile, tahmin edilmesi imkansızdır.

Mesele şu ki: Her yazılım projesi, daha önce kimsenin olmadığı yeni bir dağa tırmanmak gibi bir şey, bu yüzden hiç kimse doğrudan bir önceki deneyime sahip değil. Deneyimli geliştiriciler az ya da çok deneyim toplanmış olabilir benzer projelerde, ancak her zaman yeni elemanlar ve sürprizler olacak - Aksi, bir yazılım projesi olsaydı tam bazı öncekinde olduğu gibi, bunu yaparken kesinlikle hiçbir anlamı olmazdı .

Bunu kişiye anlattın mı? Sizler profesyonel yazılım mühendisisiniz, bu yüzden yazılım inşa ettiğiniz kişi, yazılım sistemlerinin tasarımı ve uygulaması söz konusu olduğunda bilginizi ve geri bildirimlerinizi dikkate almalıdır.

Belirsizliğin Koni muhtemelen iyi başlangıç noktasıdır. Yazılım projelerinin, daha sonra projede olacak olan daha fazla ayrıntı bilinene kadar tahmin edilmesi zor. Ek olarak, değişen şartlar tahminleri de değiştirecektir. Bir projenin başlangıcındaki ilk tahminleriniz büyük miktarda değişkenlik gösterecektir.

Diğer tahmin teknikleri ile de ilginizi çekebilir. Sadece küçük bir geliştirici olduğunu söylemiştin. Genel olarak, daha deneyimli geliştiriciler daha fazla sorun gördükleri, çözdükleri ve (umarım) gerçek zamana göre tahminleri takip ettikleri için daha iyi bir tahmin yeteneğine sahiptir. Bundan geniş bant delphi veya planlama poker gibi kestirim tekniklerini kullanarak bundan yararlanabilirsiniz .

Küçük bir geliştirici olarak, şimdi tahminleri ve gerçek zamanı izlemeye başlayın. Yazılım Mühendisliği Enstitüsünde geliştirilen Kişisel Yazılım Süreci hakkında okumak isteyebilirsiniz. Çekirdek PSP kitaplar A Yazılım Mühendisliği Disiplin , Yazılım Mühendisleri için bir Self-Geliştirme Süreci: PSP ve Kişisel Yazılım Süreci giriş . Kişisel Yazılım Sürecine Giriş'in en yararlı bulacağınız konuları kapsayacağına inanıyorum. Bence çoğu geliştirici için genel bir sorumluluk var ama kişisel verimliliğinizi artırmak ve kariyeriniz boyunca sürekli kullanacağınız çeşitli beceriler (tahmin dahil) geliştirmek için kullanılabilecek bazı iyi fikirler ve iyi uygulamalar var.

Tahminde çok daha fazla çalışma yapacaksanız, iki tane Steve McConnell'in kitabını tavsiye ederim: Yazılım Tahmini: Siyah Sanatın Demistleştirilmesi (bir sanat ve bilim olarak tahmine odaklanır) ve Hızlı Gelişim: Vahşi Yazılım Programlarının Tamize Edilmesi (genel yazılım mühendislik süreci ve proje yönetimi konuları).

Literatüre bakınız. Uygulama tarafından kanıtlandığı gibi (deneyler) beklendiği gibi çalışmayan çok sayıda karmaşık ve sıklıkla çelişkili materyal yığını vardır. En azından akademisyenler bir yığın kitap tarafından sallanıyor.

Okumalısınız: http://en.wikipedia.org/wiki/The_Mythical_Man-Month

Efsanevi Adam Ayı: Yazılım Mühendisliği Üzerine Denemeler, Fred Brooks'un yazılım mühendisliği ve proje yönetimi üzerine bir kitaptır. Merkezi teması "geç bir yazılım projesine insan gücü eklemek" anlamına gelir. Bu fikir Brooks'un yasası olarak bilinir ve ikinci sistemin etkisi ve prototipin savunuculuğu ile birlikte sunulur.

Brooks'un gözlemleri, OS / 360'ın gelişimini yönetirken IBM'deki deneyimlerine dayanıyor. Programın gerisinde kalan bir projeye daha fazla programcı eklemişti, daha sonra projeyi daha da geciktirmek için daha sonra sezgisel olarak sonuçlanacağına karar verdi. Ayrıca, bir projenin - bir ALGOL derleyicisi yazarken - ilgili işçi sayısına bakılmaksızın (daha uzun süre gerekli) altı ay süreceğini iddia etme hatasını yaptı. Yöneticilerin proje geliştirmedeki bu hataları tekrarlama eğilimi, Brooks'un kitabının "Yazılım Mühendisliği İncil" olarak adlandırıldığını, çünkü "herkesin alıntı yaptığını, bazılarının okuduğunu ve birkaç kişinin geçtiğini" hatırlamasını sağladı. Kitap, yazılım mühendisliğinin insan unsurlarında klasik olarak kabul ediliyor ...

Bu tahminde ne yapmayı planladıklarını öğrenin. Akıllarında, aylarca mı yoksa yıllarca mı süreceğini bilmek istiyorlar ve tam saati almaya çalışıyorsunuz (Tipik Mühendis).

Projenin bir parçası üzerinde çalışıp çalışamayacağınıza bakın ve gerekirse daha iyi bir tahmin hazırlayın.

Eğer zorlamaya devam ederse, bir zaman dilimi uygulayabileceğiniz kadar görevlerin çoğunu sıraya koymak zorunda kalacaksınız. Tahmini etkileyebilecek ve düzeltmeler yapabilecek herhangi bir şey görür görmez onlara bildirmelerini söyleyin. İnsanlar genellikle sürprizlerden kaçınmaya çalışırlar.

Yazılım tahmin edebileceğini iddia eden insanlarla tanıştım, ancak nasıl yaptıklarını bilmiyorum. Hiçbiri nasıl yaptıklarını açıklayamadı.

Bir danışman olarak müşterilerim sık sık sabit bir teklif temelinde çalışmamı istiyor. Dolayısıyla, gerçekçi bir teklif hazırlayabilmek için tahmin etmem gerekiyor. Bunu asla bir kez başaramadım. Biri benim teklif ettiğim kadar sık ​​teklif vereceğimi düşünürdü, ama bu asla böyle olmaz. Sonuç olarak, sözleşmelerimde sıklıkla çok para kaybediyorum ve bir şirkette normal bir çalışan olarak çalışıyor olsaydım kazanacağımdan çok daha az kazanıyordum.

Yıllardır, yazılımı nasıl tahmin edeceğimi öğretecek bir kitap arıyorum, ancak henüz bir tane bulamadım.

Bunu kodlayıcı olmayan birine açıklamaya gelince. Sektördeki hiç kimsenin tahminlerini tutarlı bir şekilde yerine getiremediğini belirtebilirsiniz. Yeni yazılım ürünlerinin önceden duyurulması her zaman gerçekleşir, yalnızca ilk olarak ilan edildiği tarihten aylar veya yıllar sonra gönderilir.

Microsoft gibi büyük bir şirket kendi ürünlerini üretecek zamanı nasıl tahmin edeceğini çözemezse, nasıl yapabilirim?

İş saati veya mesai ile ödeme yapılıyor olsun, müşterilerim her zaman bu tahminleri yapmamı beklerler. Böyle bir tahminde hiçbir yerde öğretilmediği zaman onları nasıl üretmemi beklediklerini bilmiyorum ve tahminlerim için rasyonel bir temelim yok.

Tüm projenin zamanının tahmini, genellikle programcı tarafından değil, proje yöneticisi tarafından yapılır.

Proje yöneticisinin gereken görevlerin tam listesine sahip olduğu gerçeğine dayanarak bir argüman oluşturabilirsiniz. Bu liste olmadan, herhangi bir tahmin “kötü” bir tahmin olacaktır.

Ayrıca, zaman, kaç kişinin müsait olduğu ve sizin sahip olmadığınız söylemediğiniz gereksinimlerin kapsamı gibi birçok faktöre bağlıdır. Yalnız mimarlık yeterli değil.

Yapabileceğiniz bir başka nokta da, yazılım mühendisliğinin diğer mühendislik alanlarına göre halen başlangıç ​​aşamasında olduğu ve tahmin edilebilir geliştirme tekniklerinin ortaya çıkması için yeterince olgunlaşmadığıdır.

Yazılım mühendisliği de sürekli bir akış halindedir. Bir teknoloji olgun olarak kabul edilebilecek kadar etrafta olduğu zaman, genellikle bazı yeni teknolojilerin lehine terk edilir. Bu, güvenilir tahminler üretebilmek için herhangi bir teknolojiyle kimsenin yeterince tecrübe kazanmasını önler.

Bunu inşaat tahmini ile karşılaştırın. Bu çok iyi anlaşılmış bir sorundur, sadece sözleşmeler tekliflere dayalı olarak verildiği için değil, aynı zamanda insanlığın medeniyetin başından beri bir şeyler inşa ettiği için.