Sıkı zaman çizelgeleri ve zamanlama basıncı toplam sahip olma maliyetini ve teslimat süresini nasıl etkiler?

Bir yazılım mühendisliği müdürü olan bir arkadaşının babası, "Zaman aşımlarını planlamanın bir numaralı nedeni, zamanlama baskısıdır." Dedi.

Araştırma nerede duruyor? Orta derecede bir programlama basıncı canlandırıcı mı, ya da bahsettiğim yönetici doğru mu yanlış mı, yoksa "ne kadar fazla programlama basıncı, teslimat süresi ve daha fazla toplam sahip olma maliyeti?" İdeal olarak yazılım mühendisliğinin zamanlama baskısı olmadan çalışacağı şeylerden biri mi, ama pratikte gerçek dünyadaki durumların kısıtlamaları ile çalışmak zorundayız?

Yazılım mühendisliği literatürüne olan bağlantılar takdir edilecektir.

Zamanlama aşımlarının bir numaralı nedeni, zamanlama basıncıdır.

Katılmıyorum. Zaman aşımlarının planlanmasının bir numaralı nedeni, gerçekliği yansıtmayan ve aşırı iyimser bir programdır. İnsan doğası, bazı programlama basıncının mutlak bir zorunluluk olduğunu belirler. Bir miktar programlama baskısı olmadan ortaya çıkan sorunlardan sadece birkaçı ilginç problemlerdir ve "en iyisi yeterince iyinin düşmanıdır." Teknik insanlar, ürünü kapıdan çıkarmak için çözülmesi gereken sorunlardan çok bizi ilgilendiren sorunlar üzerinde çalışmayı tercih ederdik. Son tarihleri ​​(program baskısı olarak da bilinir) alın, bu ilginç sorunlar üzerinde ürünün zararına çalışacağız.

Başka bir sorun ise ürünün "yeterince iyi" olması gerektiğidir. Mükemmel olması gerekmez. Mühendisler ve bilim adamları, bazı özel durumlar için geçerli olmayan basitleştirici varsayımları görüyorlar. Grafik tasarımcıları, diğer herkes tarafından görülmeyen diğer adlandırma sorunlarını görür. Programcılar mimarilerinde ürünün davranışları üzerinde sıfır etkisi olan siğiller görürler. “En iyisi yeterince iyinin düşmanıdır”, yani bazen gerçekten sorun olmayan problemlerle yaşamak zorunda kalıyoruz.

Programlama baskısının olmaması, sahip olma maliyeti çok yüksek olan bir ürüne yol açacaktır. Taşmalara neden olan şey kötü programlardır. Bu çeşitli şekillerde olabilir. Gerekli çabayı küçümsemek, bağımlılıkları hesaba katmamak, zaten geç olan bir projeye insanları eklemek. Sadece birkaç isim.

Zaman, kalite, kaynaklar ve özelliklerin sayısı birbirine bağlıdır. Bunlardan üçünü düzeltebilir ve sonuncusunu zamanlama işleminizin çıktısı olarak alabilirsiniz.

Sorunuzun formüle edilme şekli, zamanın değişkeniniz olduğunu ve diğer üçünün (kalite, kaynaklar ve özellik sayısı) sabit olduğunu gösterir. Soru, zamanı ^* sabitleyerek ve kalitenin yüzmesine izin vererek perspektifi biraz değiştirmekten yararlanabilir .

Şimdi sorunuz şu hale geliyor: "Zamanlama kısıtlamaları kaliteyi olumsuz etkiliyor mu?" Bu sorunun cevabı çınlayan bir "Evet" dir: araştırmalar , insanların matematikle ilgili problemler üzerinde baskı altında daha kötüye gittiğini ^** daha önce kapsamlı bir şekilde uygulamadıklarını (yani elli kez veya daha fazla denedi) doğrular , bu nedenle arkadaşınızın babası haklıdır.

^** Burada, programlamanın matematik yapmaya benzer olduğuna dair örtük bir varsayım vardır; Bu varsayımın adil olduğunu düşünüyorum.

Ne kadar fazla programlama basıncına sahip olursanız, teslimat süresi de o kadar uzun olur ve toplam sahip olma maliyeti nedir?

Teknik müdür ile görüşmeden yönetici tarafından yapılan herhangi bir çizelgeleme buna eğilimlidir. Gerçeklere dayalı OLMAYAN Planlama veya tahminlerin başarısızlığa eğilimli olduğu çok açık bir gerçektir .

Ayrıca, Kanıta Dayalı Programlamadan kaçınan yöneticiler de projelerinin bir sonraki başarısızlığına doğru ilerliyorlar. Bu konuda çok sayıda çalışma vardır ve metrik tabanlı planlama takip etmenin doğru yoludur.

Sağdan sola programlama.

Yönetimde bir kişi her zaman ünlü gerçeklik bozulma bölgesi ile Steve Jobs olduğunu düşünüyor. Ürün geliştirmedeki biri onları eğitene kadar, teknik olmayan yöneticiler, roket bilimi için ilk Fransız filmi "Le voyage dans la lune" ("Aya Gezisi") kadar sofistike bir planlama hakkında genellikle bir görüşe sahip olabilirler .

Sorun bir süredir ortalıkta. Fred Brooks, Mythical Man-Month'da bağırsaksız tahmin hakkında konuşuyor . Barry Boehm , yönetime bir Teori-K yaklaşımı önerilerinde bunu anlatıyor . Daha yakın zamanlarda, Steve McConnell ( Code Complete yazarı ) ilkeli müzakere konusu kavramını "Popüler Olmayan Bir Programı Nasıl Savunuruz" konusuna odaklar .

Agile, projelerin kapsamını oldukça görünür olduğu bir yere iter. Çevik Manifestosu "sözleşme müzakere üzerinde Müşteri işbirliği" çağrısında bulunuyor. Ayrıca, umarım, sorumlu tutulan insanları güçlendirir. Planlama oyun gereksinimleri ya da yeni keşifler değişikliklerden aşıldı olmuştur onlar önce uzun yapılan vaatlerin geliştiriciler coercing teknik olmayan paydaşları önler.

Kuruluşunuz çevik bir şekilde reddederse, kazanılan değere göre bir takvimi yeniden temel almak için tahminlerin kalibrasyonu ile ilgili harika yöntemler vardır . Kazanılan değerin, tahminle ilgili bazı gerçek problemlerle harika bir iş yaptığını düşünmüyorum, ancak projelerin hızı ve tahminler üzerinde bir şekilde gerçekler olarak uyma konusundaki sanrıları ortadan kaldırmaya yardımcı olabilir.

Kodlamaya ne kadar erken başlarsanız, o kadar uzun sürer. Program basıncı, metodoloji değişikliğini zorlama etkisine sahip olabilir. Bazen şelaleden "cehennem gibi kod" a kadar. Bu, işçiler ellerinden gelenin en iyisini yapamadıklarında ve akranları ve gelecekteki bakıcıları, onları en iyi şekilde değil, en kötü şekilde gördüklerinde moralden bahsetmeye gerek kalmadan kalite üzerinde olumsuz bir etkiye sahip olabilir. Böyle bir ortamda, bir miktar kaos, kaynak kontrolü, günlük oluşturma ve test (veya sürekli entegrasyon ve birim testi), kod incelemeleri, deneyimli ve yüksek vasıflı bir ekip kullanılarak kontrol edilebilir ve personelin geç saatlere eklenmesine karşı direnebilir proje ve eski bekleme, fazla mesai.

Diğer zamanlarda metodoloji değişikliği şelaleden artımlı tekrarlamaya kadar olabilir. Benim deneyim yönetimi Agile kucaklamak için yavaş oldu. Fakat bir süre sonra Agile'ye karşı daha destekleyici yeni bir yönetim vardı. Zaman boksu bütçeleme gibi olabilir - bizi sınırlı bir kaynağın en iyi kullanımını düşünmeye zorlayabilir. Scrum'un iki zaman kutusu vardır - biri ekip üyeleri arasında geri bildirim için günlük, diğeri ise yakma listesinden sprint için aylıktır.

Creative Commons Lisansı - bkz. Http://en.wikipedia.org/wiki/File:Scrum_process.svg

Yazılım mühendisliği literatürüne ihtiyacınız yok. Tüm ihtiyacınız olan kavramsal olasılık ve istatistik.

Bir tahmin sadece budur, bir tahmin. Kesin değildir, garanti edilmez. Herhangi bir tahmin için, onu alt etme veya burnuna vurma olasılığınız ve onu aşma olasılığınız vardır.

Olasılık 101: p (az aşılmış veya tam olarak vurulmuş) + p (aşmış) =% 100.

Bir tahmine dayalı bir çizelge aynı özelliklere sahiptir.

Belirsizliği tamamen ortadan kaldıramazsınız. DAİMA biraz aşma olasılığı olacaktır. Küçük olabilir, İran'ın ofis binanızı nuking olasılığı, ama hala orada. Yapabileceğiniz en iyi şey HER ŞEYE bakmak ve belirsizliği olabildiğince azaltmaktır. Bunu yaptıktan sonra, eğer şanslıysanız, küçük belirsizlik ve her iki tarafta% 50 olasılıkla bir programa sahip olacaksınız.

Şimdi düşünün: Takvimi içeri çekerseniz, takvimin altına düşme veya tam olarak vurma olasılığı azalır. Toplam hala% 100'ü toplamalıdır. Bu olasılık nereye gidiyor? Cevap, taşma olasılığına giriyor.

General Dynamics / Fort Worth Division bunu zor yoldan öğrendi. F-16C / D gelişimi için ilk tahminlerini yaptılar ve besin zincirini gönderdiler. Birisi keyfi olarak bir yılı ondan kesti ve Hava Kuvvetleri'ne gönderdi. Doğrudan sonuç olarak, GD / FW uçuş testine bir yıl geçti ve Hava Kuvvetleri mutlu değildi. ("Bir yıl gecikmenin" gözden geçirilen takvime göre olduğunu, yani orijinal takvimin HEDEF ÜZERİNDE olduğu anlamına geldiğini unutmayın.)

Odaklanmaya yardımcı olduğu için bir projedeki belirli bir miktar baskının iyi olduğunu düşünüyorum.

Bununla birlikte, basınç gerçekçi değilse veya yönetim ile teknik kişiler arasındaki iletişim düzgün çalışmazsa, evet, basınç planlamanın kötü kalite ve / veya geç teslimat ile sonuçlanması riski vardır.

Deneyimli bir geliştirici, kendisinin mükemmel çözümü üretmesinin beklenmediğini, daha ziyade yeterince iyi bir çözümü üreteceğini bilecektir . Dolayısıyla, böyle bir geliştirici tarafından verilen tahmin, belirli bir proje için neyin iyi olduğunu anlamalarını zaten yansıtacaktır.

Yeterince iyi tanımını etkileyen birçok faktör vardır.

Örneğin, proje kaç ay sürüyor? Proje bir yıl sürerse, projenin başlangıcında bu özellikle zor modülün bir prototipini yazabilirsiniz ve daha sonra diğer rutin modüllerin geliştirilmesinde bir yan etkinlik olarak test etmek ve hata ayıklamak için birkaç ayınız vardır. (Bu modülün yeterince iyi olana kadar birkaç ay boyunca olgunlaşmasına izin verebilirsiniz , böylece en baştan denemenize gerek yoktur.) Bu stratejiyi çok etkili buluyorum, ancak size güvenen ve size izin verecek bir yöneticiye ihtiyacınız var bir projeyi aylarca açık tutmak. Başka bir (güvensiz) yönetici sizi bu modülü en kısa sürede bitirmeye zorlayabilir (daha sonra düzeltmeniz gerekip gerekmediği ve bu yaklaşımın toplamda çok daha fazla zaman alacağı önemli değil).

Başka bir örnek: proje, yalnızca bir sürümü olacak bir ürün içindir. Daha sonra hızlı bir şekilde yapılmasını deneyebilir ve ürünün beklendiği gibi çalışmasını sağlamak için kapsamlı testlere güvenebilirsiniz (hızlı ve kirli yeterince iyidir ). Öte yandan, ürünün iki veya üç sürümü olacaksa, kodun daha sonraki sürümler için kapsamlı bir şekilde yeniden yazılmasını önlemek için tasarım için biraz zaman ayırın. (Bu durumda, üç sürümdeki toplam geliştirme süresi daha büyük olduğu için hızlı ve kirli yeterince iyi değildir .)

Sonuç olarak, yönetim ve teknik insanlar arasındaki kötü iletişimin ve eldeki proje için neyin iyi olduğuna dair ortak bir anlayış eksikliğinin aşırı programlama basıncına yol açabileceğini ve bu da kötü kalite / geç teslimatla sonuçlanabileceğini düşünüyorum.

İlk seferinde düzgün bir şekilde yapmak için asla yeterli zaman yoktur, ancak daha sonra düzeltmek için her zaman yeterli zaman vardır.