Büyük projeler geliştirirken en büyük darboğazlar nelerdir? [kapalı]

Diyelim ki şirketim MS Word'ün bir kopyasını geliştirmekti (örnek olarak). Birinin sonsuz paraya ve Microsoft gibi bir organizasyona sahip olduğu varsayılarak, geliştirme sürecindeki darboğaz ne olurdu? Başka bir deyişle, bu tür yazılımları hızlı geliştirmenin en yaygın engelleri nelerdir? Tüm spesifikasyonların yerinde olduğunu ve kuruluşun mükemmel bir şekilde çalıştığını varsayalım, bu yüzden ürün gönderilmeye hazır olana kadar yazılım geliştirmeye odaklanıyoruz. Bazı alternatifler şunlar olabilir: - Kod yazma - Test yazma - Son ürünü manuel olarak test etme - İlk etapta kötü tasarım nedeniyle kodu yeniden yazma - Kod tasarlama - Deneyimli geliştiriciler tarafından yapılan kod incelemesi - GUI tasarımı - Alfa tabanlı GUI'yi yeniden tasarlama / beta kullanıcı geri bildirimi - Kullanıcılardan geri bildirim işleme - Alfa / beta kullanıcı geri bildirimi bekleniyor

Lütfen cevabınızdaki referansları kullanın veya konuyla ilgili deneyiminizi belirtin.

Benim tecrübeme göre, büyük "darboğaz" öğrenme sürecidir . Varsayımsal şirketiniz bir sonraki Microsoft Word'ü geliştirmek için yola çıktığında, bilmeniz gerekenler ile aslında bildikleriniz arasında büyük bir boşluk vardır. Boşluğun boyutu birçok faktöre bağlıdır, teknoloji veya etki alanında olabilir. Sorunuzdaki bu sorunların bazılarına, örneğin tasarım, kullanıcı geri bildirimi vb.

Eğer bunu deneyecek olsaydım, hem teknik hem de yönetim alanında deneyime sahip en iyi insanları işe alırdım. Alanındaki mevcut literatürü okumaya çalışın. Ayrıca en kısa sürede müşteri geri bildirimi almaya çalışacağım. En büyük sorun, bilmediğiniz ve sürecinizin çok geç zamanlarında bulabileceğiniz kritik şeylerdir.

Bu arada, yazılım projelerine özgü değil. Yeni bir şeyler yapmaya çalıştığınız her büyük ölçekli proje için geçerlidir. Örneğin, Boeing Dreamliner'a bakın. Bu konuda yazılmış birçok kitap var. Efsanevi Adam Ayı birdir.

Tüm spesifikasyonların yerinde olduğunu ve kuruluşun mükemmel şekilde çalıştığını varsayalım.

Yazılım geliştirme süreçlerindeki en büyük iki “darboğaz” ın var olduğunu varsaydınız (kişisel deneyimlerimden).

Varsayımsal, mükemmel dünyanızda bile görebildiğim bazı sorunlar var:

Muhtemelen en önemlisi, kendi açımdan, müşterilerle ilgilenmektir. Kendi tecrübelerime göre, işletme geliştirilirken sık sık projeyi değiştirmeye çalışan müşterilerle uğraşmak zorundadır. Bazı durumlarda, herhangi bir para ödemek zorunda kalmamak için bir değişiklik isteğini bir hata düzeltmesi olarak kanatlandırmaya çalıştılar. Bu, bir projeyi geciktirebilecek veya kodun hızlı bir şekilde hacklenmesine yol açabilecek çok sayıda bürokrasiye yol açabilir ve bu da daha sonra teknik borca ​​dönüşür. Nefes almak kadar kolay bu sorunlarla uğraşan ekipleri okudum ve duydum ve eminim onlardan birinde olsaydım :)

İkinci sorun, uygun bir alan modelinin olmamasıdır. Eric Evans, Domain Driven Design adlı kitabında bu konuyu iyi bir şekilde ele alıyor . İyi bir etki alanı modelinin bulunmaması, Glenn'in cevabında, bir hata bulmaya çalışmak gibi vurgulanan bazı sorunlara yol açar. Temiz bir etki alanı modeli olmadan, bir sorunu yalıtmak ve düzeltmek için kodun içinden geçmek / hata ayıklamak zaman alabilir. İyi bir etki alanı modelinin, uygulamayı devam ettirirken ve daha da genişletirken, hayatı ve hata ayıklamayı çok daha kolay hale getirdiğini iddia ediyorum.

Yukarıda bahsettiğim sorunlar herhangi bir acil sorun yaratmaz, ancak bu ürünü uzun süre korumanız gerekirse, size ve ekibinize musallat olabilirler.

"Organizasyon mükemmel çalışıyor" derken ne demek istediğinizden emin değilim, ama harika bir organizasyonda bile, büyük bir projedeki en büyük darboğaz iletişimdir. Efsanevi Adam Ayı, bir proje ekibi büyüdükçe iletişim kombinasyonlarının nasıl patladığını, neredeyse hataları ve eksik bilgileri nasıl garanti ettiğini belirtir.

Şimdiye kadar işte gördüğüm kadarıyla, büyük bir darboğaz kaynağı sadece hatalardan ve onları yaratan insan hatasından geliyor. Sadece kodu hata ayıklamak için gereken süreyi düşünün, sorun için bir düzeltme bulun ve sonra yeni çözümü yeniden test edin. Şimdi bu düzeltmenin başka bir ince hataya neden olup olmadığını hayal edin. Büyük bir ağrı akışı olabilir ve bu nedenle genel olarak gelişimi yavaşlatır.

Bence Brandon Moretz en iyi cevaba sahip. Ama şunu eklemek isterim ki, büyük bir projeden ilk versiyonu almak o kadar da zor değil. Şahsen bunu asla başaramadım.

Ne yapamadım ilk sürümü ikinci, üçüncü vb sürümü ve / veya hata düzeltmeleri ve veya küçük özellik geliştirmeleri de zamanında teslim edilebilecek şekilde oluşturmak oldu.

Evet, yukarıdaki şeyleri kabul edeceğim ve yazılım modellerini takip etmesi gerekiyor. Bildiğim kadarıyla, ana şeyler şunlardır:

1. Zaman Yönetimi 2. Takım Verimliliği ve takım yönetimi 3. Takımda Koordinasyon ve 4. Müşteri ile daha iyi anlayış

Eğer dördüncüsü varsa, o zaman kişilik ve yazılım açısından başarı ve çok fazla gelişme ile yeni bir dünyaya geçebiliriz.

Gizli kusurlar, gereksinimler, tasarım, uygulama, dağıtım .... gibi şeylerde kırık ama henüz bulamadım. Her yeni hatanın en son değişikliklerden kaynaklandığını düşünün.