Kodlamaya başlamadan önce bir yazılım ürünü ne kadar iyi tanımlanmış olmalıdır?


13

İnsanların kodlamaya başlamadan önce genellikle bir yazılım ürününü ne kadar iyi tanımladıklarını ve onlar için ne kadar iyi çalıştığını bilmek istedim? Kullanım örneklerini tanımlama, riski analiz etme, sınıf diyagramları çizme vb.

Nihai ürünün gelecekte risklerden kaçınmak için ne kadar iyi bir fikre sahip olmanın iyi bir fikir olduğunu biliyorum, ancak bir ürünü o kadar iyi tanımlamamak da uyum sağlamak zor değişiklik.

Diğer daha spesifik sorular muhtemelen:

  1. Bir projenin zamanının yüzde kaçı normalde geliştirme öncesinde planlama aşamalarında harcanır?

  2. Kodlamaya başlamadan önce karşılamaya çalıştığınız belirli ölçülebilir ölçütleriniz var mı veya daha fazla bağırsak meselesi mi?

  3. Kodlamaya başlamadan önce tüm sınıfları çiziyor musunuz, yoksa en baştan bir şeylerin değişmesini beklerken dinamik bir tasarım oluşturmaya mı çalışıyorsunuz?

Paylaşmak istediğiniz herhangi bir deneyim harika olurdu!

Yanıtlar:


10

"Ne kadar iyi tanımlanmış?" dır-dir

Başlayabileceğiniz kadar iyi tanımlanmış.

İlk iş kapsamını tanımlayabilecek kadar iyi tanımlanmış (başlangıç ​​konsepti için). Bu, kaçınılmaz olarak gerçekleşecek değişiklikleri belirlemeye yardımcı olmak için yeterlidir.

Sprintlere öncelik verebileceğiniz kadar iyi tanımlanmış.

Kullanım örneklerini tanımlamaktan bahsediyorum,

Her zaman yardımcı olur. Ama hepsi değil . Öncelikle önemli kullanım durumlarına öncelik vermeli ve bunları kapsamalısınız. Diğer kullanım durumları daha sonraki sürümlerde ele alınacaktır. Bazı kullanım durumları o kadar düşük önceliğe sahip olacak ki, asla yapılmayacaklar.

risk analizi,

Genellikle zaman kaybı.

sınıf diyagramları çizme vb.

Eğer yardımcı olursa.

Bir projenin zamanının yüzde kaçı normalde geliştirme öncesinde planlama aşamalarında harcanır?

Çok değişir. "Yetkili" numaralar almak için Yazılım Mühendisliği Ekonomisi gibi iyi bir kitap satın alın.

Kodlamaya başlamadan önce karşılamaya çalıştığınız belirli ölçülebilir ölçütleriniz var mı veya daha fazla bağırsak meselesi mi?

"ölçülebilir". Bunu tanımlamak neredeyse imkansız.

"bağırsak". Kötü politika.

Sorun "ne yaptığınızı anlıyor musunuz?"

Bağırsak bir şey değil. Bu bir Evet / Hayır sorusu.

Sadece bir evet / hayır sorusu olduğu için "ölçülebilir" değildir.

Ve ayrıca, öncelik vermelisiniz. Sen her şeyi yapmıyorsun. İlk birkaç sprint ile başa çıkmak için yeterli.

Kodlamaya başlamadan önce tüm sınıfları çiziyor musunuz, yoksa en baştan bir şeylerin değişmesini beklerken dinamik bir tasarım oluşturmaya mı çalışıyorsunuz?

Her şeyi önceden bilemezsiniz.

Denemeyin.


Şahsen ben çok fazla zaman sınıf diyagramları yazma modeli ve kod zaten başladıktan sonra yine de değişir beri yazma zaman harcamak bulmak.
AndersK

Her şeyi önceden bilemeyeceğinizi kabul ediyorum, ancak iyi bir tasarım belgesi en azından gerçekleştiğinde kapsamı ve özellik sünmesini belirlemenize yardımcı olacaktır.
Tim Post

@Tim Post: İyi öneri. Bu, sorunun "ne kadar iyi tanımlandığını" tanımlamanın bir yoludur. "Kapsamı ve özellik sürünmesini belirlemenize yardımcı olur." Daha fazla değil, değil mi?
S.Lott

@Tim Post: "kapsamı tanımla" yanıltıcıdır. Bu, projenin başlangıcında sizin için mümkün olan bazı “kapsam” bilgisi olduğu anlamına gelir, ki bu doğru değildir. İş ihtiyaçları değiştikçe kapsam projenin yaşam döngüsü boyunca değişecektir, çünkü hiçbir piyasa statik değildir.
Rein Henrichs

@ Henrichs Rein: Cevabınızı birleştirmek için cevabı hafifçe ayarladım. Başlamak için yeterli kapsam tanımı. "Ve daha fazla" eklemek için cazipim.
S.Lott

2

Müşteriniz projeye aktif olarak proje ekibinin bir üyesi olarak katılırsa, geliştiriciler için sorular için kullanılabilir ve işlevsellik hakkında hızlı kararlar alır. O zaman spec daha az ayrıntılı olabilir.

Müşteriniz uzaktaysa ve uzun süre geri bildirimde bulunmuyorsa, spesifikasyonunuz çok ayrıntılı olmalıdır.

Şirketimizde kullanıcı hikayeleri oluşturuyoruz ve projedeki geliştiricilerle Planning Poker oynuyoruz . Bu bize bir kullanıcı hikayesinde harcanacak saatlerin adil bir göstergesidir.


Bir "Müşteri Temsilcisi" (müşteri için önerdiğiniz rol) tüm ekip için en hayati roldür. Ekibiniz ürün ve iş soruları hakkında cevap alamazsa, doğru kararı nasıl almaları gerekir?
Rein Henrichs

Harika bir nokta, teşekkürler! Müşterinin katılımının belirli bir proje için en iyi olanı nasıl bu kadar büyük ölçüde değiştirebileceğini düşünmedim. Kesinlikle aklımda tutmam gereken bir şey. Ayrıca, "Planning Poker" i hiç duymamıştım ve bu gerçekten değerli olacak gibi görünüyor.
drewag

2

Projenin ne kadar iyi tanımlanması gerektiğine başlamanız ve önümüzdeki iki hafta boyunca nereye gideceğinizi bilmeniz yeterli.

Bir Scrum Master olarak, sadece özelliklerinizi takip etmek için ürününüzün brüt özelliklerini bir Excel sayfasında veya başka bir yerde tanımlamanız gerektiğini söyleyebilirim. Onları Kullanıcı Hikayeleri yapmak, bir sonraki ihtiyacınız olan özellik hakkında düşünmenize yardımcı olur. Ardından, bunlara öncelik verin: Zirveye En Önemli veya Zorunlu Özellik ve Alttan En Az.

En önemli özelliklerden bazılarını listeledikten sonra, geliştirebileceğinizi düşündüğünüz özellikleri, iki haftalık bir süre sonunda veya tercih ederseniz bir aylık süre sonunda Bitti durumuna getirin. Daha sonra, birkaç tanede kodlamaya başlayabilmeniz için bu seçilen özelliği patlatın.

Kodlama yaparken, seçtiğiniz özellikleri Tamamlandı durumuna getirmek için geliştirilmesi gereken diğer unsurları kesinlikle düşüneceksiniz. Bitti, yapacak başka bir şeyiniz olmadığı anlamına gelir, yani testler, kodlama, montaj, dokümantasyon Bitti!

Seçtiğiniz özellikler listesi, hedefle karşılaştığınız sürece genişleyebilir, yani belirli bir süre boyunca söylediğiniz her şeyi geliştirebilirsiniz.

Kısacası, hiçbir şey mükemmel olmak zorunda değildir. Bazı fikirleri atın, yoldaşlarınızla paylaşın ve yazılanların talep edilen ürün gereksinimlerini karşılamak için anlamlı olup olmadığını görün. Eğer öyleyse, o zaman içerdesin! Açıklamak gerekirse, basit bir Müşteri Yönetimi ürünü ile gideceğim. İhtiyaç duyulan şey?

As a user, I may manage the Customers;
As a system, I persist changes to the underlying data store;
As a user, I need to enter my credentials to be able to manage customers;
As a system, I have to authenticate the user against the Active Directory;

İlk taslağınız bu kadar basit olabilir! O zaman güvenliğin sistemimizde önemli bir parça olduğunu görebiliriz, nihai önceliği (E / H) sağlayacak kadar önemli mi? Bu, karşılamanız gereken gereksinimlere bağlı olacaktır. Diyelim ki Müşteri Yönetimi burada en önemli şey. Bu nedenle, bir sonraki Sprint'te müşterileri temel ancak kabul edilebilir bir şekilde yönetebilmemiz gerekiyor. Müşteri Yönetimi Nedir?

As a user, I may manage Customers;
    -> As a user, I add a customer to the system;
    -> As a user, I change a customer details;
    -> As a user, I delete a customer;
    -> As a system, I flag a deleted customer as being inactive instead of deleting it;
    -> As a user, I need to list the customers;
    -> As a user, I search the customers data bank for a given customer;
    -> ...

Bu zaten uygulamayı geliştirmeye başlamak için yeterli işlevselliği göstermektedir. Programcılarınızın daha fazla talimat alması gerekiyorsa, belki de sınıf diyagramlarından memnun olan bir geliştirici, Müşteri sınıfını ve özelliklerini ve yöntemlerini tasarlayabilir! Ama endişelendiğim kadarıyla yazdığım bu az sayıda kişi ile başlamak için yeterli zamanım olacaktı. Bazı özellikler yol boyunca eklenebilir veya değiştirilebilir. Önemli olan Done olacağını söylediklerinize odaklanmaktır. Örneğimizde bu Müşteri Yönetimi meselesidir. Şu andan itibaren kullanıcı kimlik doğrulamasıyla ilgilenmemiz gerekmiyor Bu bir sonraki Sprint'te daha sonra gelecek.

Umarım bu yardımcı olur! =)


Çok teşekkürler! Bunu böyle özel bir senaryoda görmek harikaydı. Bunun, genel ürün hakkında tanımladığınız, ancak alt hedefleri ve özellik odaklı bir yaklaşımı vurguladığınız şeyle ilgili olarak en azından biraz ölçülebilir bir şeye sahip olmak için iyi bir çerçeve olduğunu hissediyorum. Gelecekte yeni projelere başladığım için bu yaklaşım kesinlikle önemli olacak!
drewag

Rica ederim! Tuz tahılımın sana yardım edebileceğine sevindim! =) Derinlemesine özellikler tanımlamamanız önemlidir, çünkü ürün gereksinimleri yol boyunca değişebilir, çünkü müşteri, Şimdiye kadar ne yaptığınızı göreceği zaman, sizin yaptığınız şeyde yapacak başka fikirlere veya değişikliklere sahip olabilir. Bitti. Ürünü, yeni gereksinimleri karşılayacak şekilde ayarlamanız gerekecektir. Yani, her şeyi projenin başında bir kerede kurduysanız, bunun neden olabileceği işin kaybolduğunu hayal edin! Belki de sadece atmak ve sıfırdan yeniden başlamak için saatlerce çalışmış olacaksınız. Let it evolve =)
Marcouiller

1

Benim için harika olan şey, "oldukça iyi" işlevselliğe sahip olmak ve yazılım mimarisinin sadece çok gevşek bir şekilde belirtilmiş olmasıdır.

Çalışmaya başlayabilmem için neye doğru çalıştığımı bilmem gerekiyor. Sadece müşterinin ihtiyaçlarını anladığımda benim için işe yaramıyor. Kendi kullanımım için bir araç yazsam bile, ekranları çiziyorum, işlevselliği, her düğmenin ne yaptığını, her şeyi açıklıyorum. Aksi takdirde başlayamıyorum.

Öte yandan, kodu tam olarak nasıl geliştireceğimden gerçekten vazgeçtim. Belki bu en kötü uygulama, ama benim için çalışıyor. Ben oluşturacağım veritabanı tabloları bir dizi tanımlayabilirsiniz, ama her birinde hangi sütunlar değil. Hangi nesnelere ve sınıflara ihtiyacım olduğunu düşünebilirim, ama kesinlikle diyagram çizmiyorum.

Cehennem, bazen yanlış yapana kadar bunu nasıl yapacağımı bile bilmiyorum. Bir kez inşa ediyorum, yıkıyorum ve tekrar yapıyorum, şimdi nasıl olduğunu biliyorum. Bu noktada oldukça ayrıntılı bir yol haritası çizebilir ve yeniden başlayabilirim.


Deneyiminizi paylaştığınız için teşekkür ederiz. Önemli olan şey, geliştirici olarak, başlamak için yeterince rahat hissetmenizdir. Tabii eğer tekrar yaparsanız değiştireceğiniz şeyleri keşfedeceksiniz, aksi takdirde çok fazla zaman planlıyorsunuz. Bir ürün biter bitmez tam bir yeniden yazma yapmak istediğini biliyorum ve bu da kaçınmaya çalıştığım şeydir;) (en azından makul derecede).
drewag

1

Hangi dili ve metodolojiyi kullanıyorsunuz?

Java ve C ++ gibi bazı diller, Common Lisp veya Python gibi dillerden daha fazla başlangıç ​​yapısı gerektirir (Java'da yeniden düzenleme daha kolay olduğu için Java'dan C ++ daha fazladır). Leo Brodie (Bence "Düşünme"), kodlamaya ne zaman başlayacağınız konusunda iki parça tavsiyede bulundu: Forth'ta kendinizi rahat hissettiğinizden, diğer dilde olduğundan daha geç.

Şelale metodolojisi (özellikle erken tasarım bir teslim edilebilir olduğunda) çeviklerden daha fazla ön çalışma gerektirir (ancak çevik yöntemlerde erken planlamayı da ihmal etmek istemezsiniz). İyi bir otomatik test setine sahip olmak, daha büyük şeyleri değiştirmeyi daha güvenli hale getirir ve bu nedenle daha az ön çalışma yapmanıza izin verir.

Ayrıca, bireylere ve yaratılacak yazılım türüne aşina olmalarına bağlıdır. Bir noktada, öncelikle CRUD uygulamaları yaparken, birkaç özellik ve 3 "x5" boş not kağıdı ile başlayan bir program yazabilirim. Şimdi böyle yazdığım şeyleri yazamıyorum.


Perspektif için teşekkürler. Proje yönetimi söz konusu olduğunda dilin ve platformun en iyi uygulamaları nasıl etkileyebileceğini düşünmemiştim. Çoğunlukla Objective-C, UIKit ve AppKit hakkında konuşuyorum. Ancak diğer dillerde de çalışıyorum (C, C ++, C #, Java, Python, vb.). Bu, belirli bir yöntemin tüm projeler için en iyi olacağını varsaymamaya dikkat etmem gerektiği anlamına gelir, metodoloji tabanımı hedef platform ve dile göre ayarlamalıyım (ve belki de bir seçeneğim varsa buna dayalı bir dil seçmeliyim).
drewag

1

Burada iki yararlı terim MVP (Minimum Uygulanabilir Ürün) ve MMF (Minimum Pazarlanabilir Özellik). MMF, iş değeri sağlayan bir özelliğin en küçük sürümüdür. Bir MVP, bir ürün olarak uygun olan en az MMF'dir. Bir projeye başlarken yapılacak en iyi şey MMF'leri ve MVP'yi tanımlamak ve oradan başlamaktır.

Ürününüzü mümkün olan en kısa sürede serbest bırakın, ardından aşamalı olarak geliştirmeye devam edin.


Bu gerçekten harika bir terminoloji, teşekkürler! Bu, ölçülebilir bir şey bulmak için burada en iyi şey. Tabii ki mükemmel değil, ancak bir özelliğin pazarlanabilir olup olmadığına karar vermek ve / veya ürüne değer katmak için oldukça kolay olacak gibi görünüyor.
drewag
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.