it-swarm.dev

Programcı olmayanların gelişim sürecini anlamalarını sağlamak

Öncelikle bir programlama şirketi olmayan bir şirket için bir proje başlatırken, beklentilerden biri, sonunda tüm hatalardan arınmış bir bitmiş ürün olması ve hemen gereken her şeyi yapmasıdır. Ancak, nadiren durum söz konusudur.

Beklentileri yönetmenin ve programcı olmayanlara yazılım geliştirmenin diğer ürün geliştirme türlerinden ne şekilde farklı olduğunu açıklamanın bazı yolları nelerdir?

66
user8

Hemen hemen bir bilgisayar olan herkes bugünlerde "böcek" kavramıyla karşılaştı, bu yüzden orada başlayabilirsiniz. "Bir uygulamanın sizin için başarısız olmasının en sinir bozucu yolu nedir? Bunu on ile çarpın ve test ve bakım için yeterli kaynak ayırmazsak kullanıcılarımızın deneyimine sahip olacaksınız."

Ve programcı olmayanlarla iyi bir iş ilişkisi kurmanın değerini hafife almayın. Yargınıza güvenilebileceğini belirleyebiliyorsanız, eğer Y pronto yapmazsanız, X'inizin mantıksal olarak başarısız olacağı alarmını verdiğinizde, mantığınızı tam olarak anlamasalar bile sizi ciddiye alırlar.

34
BlairHippo

Başarılı bulduğum bir yaklaşım şudur:

Hepimiz bir bilgisayarın sadece ve tam olarak ne söylendiğini yaptığını biliyoruz.

Programlama, bir bilgisayara şimdi ne yapacağımızı daha sonra söylememizin yoludur .

Bu, davranışınızın şimdi davranış biçiminin makinenizde çalışan herhangi bir kodu yazan herkesin birleşik niyetlerinden kaynaklandığı anlamına gelir. İşletim sisteminin, sürücülerin, programlama ortamının, kütüphanelerin vb. Karmaşıklığını düşündüğünüzde, çoğu sistemde 20k'dan fazla kişinin dahil olması ve 100 binden fazla olabileceğini görmek kolaydır.

Her kişinin yazdığı kod kendi anlayışını, motivasyonunu, niyetini ve kabiliyetini yansıtır. Sistemin kusursuz çalışmasının, bu 20k kişi tarafından yazılan kodun tümü kodunun hatasız olarak etkileşime girmesini gerektirdiği göz önüne alındığında - kodun tümü kodunun anlamı ve yorumu üzerinde anlaşması gerekir Şaşırtıcı gerçek, böceklerimiz değil, onlardan çok azımız olması.

28
Bevan

IMO, çevik süreçlerin (örneğin Scrum, Crystal vb.) Sunduğu şeffaflığın, gelişimin ortalama paydaşlara nasıl işlediğini göstermek için uzun bir yol kat ettiğini gördüm.

12
Brandon

Metaforun açıklaması sızdıran bir soyutlamadır, ancak işte benim için sıklıkla işe yarayan bazı fikirler:

Bu açıklamaların hiçbirinin özensiz işi mazur görmediğini unutmayın.

Her değişkenin hareketli bir parça olduğu bir bilgisayar programını makine olarak düşünün. Bu önemsiz bir programı bile yüzlerce hareketli parçadan oluşan bir makine haline getirir.

Bu başarısız olduğunda, bir programın hatasız olduğunu ispatlamak matematiksel olarak mümkün olsa da, büyük miktarda zaman alır ve çabaya değmez.

Son olarak, Intel ve Microsoft'un hataları önleyemediğini soruyorum, nasıl yapmamızı bekliyorlar?

3
KevDog

Bunu belirtmenin geleneksel yolu Proje Yönetim Üçgeni'dir: kapsam, maliyet ve çizelgenin birbiriyle yarışan üç kriteri; tipik olarak "ucuz, hızlı, iyi seçim iki" olarak ifade edilir.

Bir tasarım, geliştirme ve dağıtım sürecinin son değerinde, bir ürünün tasarım kusurlarından nispeten arınmış olması ve belirli bir işlevsellik ile çalışması beklenir. Aynı beklentiler bir proje, süreç veya mesleğe ilişkin olarak tamamen mantıksızdır.

Zor veya yumuşak bilimlere dayalı olan profesyonel, bir keşif sürecinden geçmez, yanlış ve kesin olmayan kavramsallaştırmalar oluşturur, optimalden daha az (veya sadece düz yanlış) taktikleri takip eder, deneme ve hata yoluyla neyin işe yaradığını keşfeder ve Kaynak tükenene veya yeterli düzeyde performans elde edilinceye kadar tekrar tekrar işlenmeli mi?

Asemptotik olarak daha yüksek kalite seviyelerine yaklaşabilmesine rağmen, hiçbir süreçte hiçbir kusur yoktur.

Bu, taktiklerin genellikle tahmin ve protokolleri içerdiği ve etkinliğin çoğunun temelde çoğunlukla bir ıslak yazılım makinesinde hata ayıkladığı tıp mesleği için geçerlidir. Yeni mühendislik malzemelerinin uygulamalarının sahada doğrulanması gerektiği ve standartlara sıkı sıkıya bağlı kalmasına rağmen yıllar süren hizmetten sonra aniden başarısız olabileceği inşaat mühendisliği ve mimarisi için geçerlidir. Yaş ve çalışma koşullarındaki değişikliklerin, uygulanan mühendislik veya onarım hizmetlerinde herhangi bir hata olmaksızın performansı genellikle arıza noktasına kadar etkilediği otomotiv sahası için geçerlidir. Yazılım geliştirme değil bu tür mesleklerden temelde farklıdır, sadece yeni, amaçlı makinelerle ilgili odaklanmanın daha büyük bir kısmına sahiptir.

2
jerseyboy

Benzer bir soruyu cevapladım daha ayrıntılı olarak , ama Gist, "Programlama bir fabrika veya bir Montaj hattı oluşturmak gibidir."

2
Huperniketes

Onu görebilecekleri bir şeyle karşılaştırabilir ve mümkünse her gün kullanabilirsiniz.

Örneğin, otomobil. Otomobiller, bugün olduğundan daha az rafine ve güvenilir cihazlara başladı. Arabalar 100 yılı aşkın bir süredir yapılmış olsa da, yazılım muhtemelen yaklaşık yarısı kadar. Otomobiller önemli özelleştirmelere sahiptir, bazıları fiyata dahildir (renk seçimi gibi), diğerleri motor boyutu, şanzıman tipi, tekerlek/lastik, trim seviyesi gibi önemli maliyet sürücüleridir.

Otomobiller ve yazılımlar için birçok özellik, kalite ve maliyet sürücüsü vardır. O zaman yazılım teknolojisinin, uzmanlığın kullanılabilirliğinin, belki de kurulduğu yerde bile nasıl büyük bir fark yaratacağını tartışabilirsiniz. Uygun geliştirme döngüleri (örneğin, küçük değişikliklerle yıllık modeller, yaklaşık üç yılda bir gövde/motor/platform değişiklikleri), müşteri ihtiyaçlarının ve karmaşık bir tasarım sürecinin bir kombinasyonu tarafından yönlendirilir. Bazı ürünler küçük ve dumpy görünümlü başlar (Honda Accord'u düşünün), ancak en yüksek puan alana kadar her yıl geliştirilirler.

Otomobiller, parça listelerinde değişiklik yapma (düşünme hataları düzeltmeleri) şeklinde (genellikle yazılım güncellemelerinden çok daha maliyetli) ve artımlı iyileştirmelere sahiptir ve genellikle uzun vadeli desteğe ihtiyaç duyarlar (geri/ileri uyumluluğu düşünün). Arabanızın maliyetinin büyük bir kısmı eve götürdükten sonra gelir. Müşterileri güncellediğinizde ve yükseltirken, yazılım maliyetinin büyük bir kısmı ilk ürün sürümünden sonra gelir.

Bazı durumlarda, yazılım veya diğer yazılım ürünlerini içeren iyi bilinen ürünlere başvurabilirsiniz. Örneğin, telefonların bir satış döngüsü ve ilk satıştan sonra daha fazla gelir elde etmek için işlevler ekleme ve güncelleme yöntemleri vardır. Telefonlar ileri/geri uyumluluğun harika bir örneğidir. Çok fazla ve insanlar eskisini yeni bir tane almak için terk etmeyecek. Çok az ve müşteriler sözleşmesi bitmeden nefret etmeyecekleri bir telefona sahip olmaktan çaresizleşiyorlar.

Windows, Microsoft Office, web tarayıcıları ve web sayfaları gibi ürünlerin tümü tartışmalarda kullanılabilen yazılımlardır. Yıllık veya üç yıllık döngülerde güncellenmiştir, ancak otomatik güncellemeler daha sık olabilir. Müşterileri çeşitli derecelerde etkileyen hatalar ve güvenlik delikleri var, ancak en iyi çabalarımıza rağmen manzaranın bir parçası. Müşteriler düzeltmeleri ücretsiz alabilir, ancak genellikle paket olarak, bazen bireysel bir modül olarak veya bir lisans anahtarı aracılığıyla geliştirmeler için ödeme yaparlar.

Microsoft, Apple, Google ve Amazon gibi sektör liderlerinin tümü kullanıcılara nispeten ucuz müşteriler sunar. Ancak bu ürünleri sağlayan büyük masrafları var. Deneyimleri, yazılımın pahalı, ancak değerli ve karlı olduğunu göstermektedir. Çoğu zaman kalite, istedikleri tüm özelliklere sahip olma ve zamanlama doğru olduğunda pazarlara girme arasında uzlaşırlar. Yaptıkları her ürün başarılı değildir ve bazen köpekleri yeniden adlandırarak, pazarlama ve satışları iyileştirerek veya kayıplarını azaltarak ve sonraki ürünlerde öğrendiklerini kullanarak kazananlara dönüştürür.

0
DeveloperDon

Nükleer reaktör kontrolü, derin alan iletişimi veya tıbbi implant cihazları (vb.) Gibi hi-rel yazılım geliştirme hakkında bilginiz varsa, bu düzey yönetim ve kalite düzeyi için maliyet ve teslimat süresi yapısının nasıl olduğunu açıklayabilirsiniz. tipik işletmelerin yazılım projeleri için karşılayabileceklerinden daha büyük olabilir.

0
hotpaw2

Belki de birebir ya da küçük gruplar halinde, ideal olarak, geliştirmeniz gereken yazılım örneklerini kullanın. Kullanım durumlarını açıkladıkları için, farklı şeylerin olabileceği durumdaki noktaları (beklenmedik ancak mantıksız durumlar) tanımlayın. Onları numaralandırmaya başlayın, bazı açıklamalar isteyin ve alınması veya karara bağlanması gereken tüm kararları ve talimatları ve bunu yaparken yapılan ödünleşmeleri gösterin. Yorgun olana ve size cevap verene kadar devam edin. Onlarla şimdi yaptığınız şeyin tam olarak tüm gün, muhtemelen kendi başınıza yaptığınız şey olduğunu anlamalarını sağlayın, muhtemelen hem kursa karar vermek hem de kodu yazmak için yüzlerce veya binlerce hiç kimse tarafından konulmamış veya konulmamış vakaları kullanın. Kendinizi düşünmediğiniz bir durum olduğunda, programın ne yapacağını garanti edemezsiniz. Belki "doğru" şeyi yapar, belki not. İşte bu bir hatadır. Bu yüzden yazılım yazmak zaman alır. Ne kadar az zamanınız olursa, değerlendirme ve uyum sağlama şansınız o kadar az olur ve program bilinmeyen bir durumda "doğru" şeyi yapmayacaktır.

0
huntmaster

Maliyet ve Zaman.

Zaman

X'i Y olarak teslim edeceğiniz beklentileri belirleyin. Daha fazla, daha az hiçbir şey olmayacak. Sonra onlara bir sonraki sürümün ne zaman olacağını söyle. İlk başta X binasının Y süresine ihtiyaç duyduğuna inanmaya şaşırabilirler - burası, bir zamanın yazılım geliştirmenin zamanını ve karmaşıklıklarını açıkladığınız yerdir. Şaşırmazlarsa, ya çok daha az zaman tahmin ettiniz ya da yazılım oluşturma hakkında düşündüğünüzden daha iyi biliyorlardı.

Maliyet

Bu Steve McConnel'in Code Compete kitabından (bellekten alıntı yapıyorum, bu yüzden aynı etkiyle iletemezsem beni affedin) - Müşterilerin yeni özellikler istemesi kolaydır. Bir ürün yöneticisi olarak müşterinin ne istediğini söylememelisiniz. Bu yeni özelliği oluşturmak için ne kadar çaba ve maliyet gerektiğini tahmin etmelisiniz. Yavaş yavaş yeni özelliğin gerçekten para/zamana değmeyeceğini ya da belki de buna ihtiyaç duymadıklarını anlayacaklar. Onları korkutmak için bu silahı kullanmanızı önermiyorum, ama dürüstçe kullanın ve bu noktayı eve götürmede yardımcı olabilir.

0
Sundeep