Geliştirici ekibimizin teknik özellikleri şirketin iş bölümünden aldığı bir proje üzerinde çalışıyorum. Hem iş yönetimi hem de BT yönetimi olması gerektiği gibi tahminler ve son tarih tahminleri gerektirir.
İyi olan şey, tahminlerin çoğunlukla gerekli özellikleri yapan gerçek geliştiriciler tarafından yapılmasıdır. Kötü olan şey, spesifikasyonların genellikle çok basit (başınızın üzerinde birçok soru işaretiyle kaldığınız ortaya çıkıyor, çünkü çok fazla bilgi eksik görünüyor) veya çok karmaşık (yapabileceğiniz noktaya kadar) hatta her şeyin uygulamaya "sığacağı" yeri görselleştirmeyin). Daha sık olmamakla birlikte, teknik özelliklerin iş bölümü eksik ya da ne yapılabilir ve ne yapılamayacağından habersizdir (önceden uygulanmış iş mantığı göz önüne alındığında).
Dev ekibine tahmin vermek için yeni spesifikasyon başına yaklaşık bir gün verilir ve genellikle spesifikasyonu kimin yaptığıyla buluşarak belirsizlikleri gidermeye çalışırız. Çoğu zaman, spec yazarlarının gerçekten her şeyi düşünmediği ortaya çıkıyor ve genellikle sadece tasarım yapmaya ve geliştirmeye başladığımızda sorun çıkarıyoruz, çünkü spesifikasyonların çoğunda delikler var gibi görünüyor.
Nasıl anlaştın onunla birlikte? Önceden tahminler konusunda cömert misiniz?
Tasarım aşamasında sorunlar buluyorsanız, gerçekten bir sorununuz mu var?
Özellikleri yaratanların her şeyi önceden yapmak zorunda hissetmediklerinden emin olun. Onlar her şeyi düşünemezler, biz de düşünemeyiz. Ayrıca, bazı spesifikasyon belgelerinde sadece bir çakmak yapamayacaklarını ve sonra proje ile yapılamayacaklarını bilmeleri gerekir. Bu uygulama aynı zamanda düşünebilecekleri her şeyi eklemelerine de yol açar çünkü buna 'ihtiyaç duyabilirler' ve şimdi sormazlarsa, hiç elde ederler. Gerekliliklerini tekrar tekrar gözden geçirmeye, test etmeye ve onaylamaya hazır olmalıdırlar.
Tüm uygulamayı aynı anda tasarlamaya veya oluşturmaya çalışmayın. Herhangi bir proje/uygulama bir tür aşamaya, parçaya, modüle ya da ona ne demek isterse bölünebilir. Eğer bu senin işin değilse çevik olmak zorunda değilsin. Kullanıcı Güvenliği parçası ile başlayın ve oradan gidin.
Bu insanlarla oturmak ve gerçekten ne istediklerini öğrenmek için zaman ayırın. Birisinin bana tüm projeyi bir kerede oluşturmamı sağlayan teknik özellikleri teslim etmesini isterdim, ancak gelecek yıl bir buçuk için ne yapardım?
Belirsizlik Konisi kullanıyorum Yüksek sesli bir sesle söyleyin
Temelde sahip olduğunuz bilgileri verebileceğiniz en iyi tahmini yaparsınız.
Ama aynı zamanda, spesifikasyonlardaki belirsizlikler göz önüne alındığında, bu tahminlerde yüksek bir belirsizlik olduğunu belirtiyorsunuz (Sahadaki nokta yönetimi, prensibi okuyabilmeleri için).
Hedefe doğru ilerledikçe ve teknik özellikleri sıkılaştırdıkça tahmininizi güncelleyebilir ve belirsizliği azaltabilirsiniz.
Evet, tahminler konusunda cömertim. Unutmayın Hofstadter yasası
Hofstadter Yasası: Hofstadter Yasası'nı hesaba katsanız bile her zaman beklediğinizden daha uzun sürer. Gödel, Escher, Bach: Sonsuz Altın Örgü.
Tanımladığınız işlem aslında oldukça normaldir. Sorun, iş türlerinin "gereksinimler aşaması", sonra "tasarım aşaması", vb. Açısından bir şeyler düşünme eğiliminde olmasıdır. Bir ekip bir ürün oluştururken, gerçekten yinelemeli bir yaklaşıma ihtiyacınız vardır. İş bulduğum birkaç fikir:
İlk tahmininizin doğru olamayacağını unutmayın. Tahminlerinizi, aldığınız gereksinimlerin makul yorumlarına dayandırın ve varsayımlarınızı/yorumlarınızı belgeleyin. Keşfettiğiniz delikler nedeniyle daha fazla türetilmiş gereksinimler olacaktır. Bu normal.
Tahminlere karşı cömert olmak kulağa hoş gelebilir, ama hangi problemi çözüyor? Spesifikasyonu daha iyi hale getirmeyecek, planlamayı daha kolay hale getirmeyecek. 'Y olabilir' demekten farklı olarak 'X'ten daha kötü olamaz' diyor. Gerçek şu ki bilmiyorsunuz. Neler yapabileceğinizi öğrenin.
İş analistlerinin geliştiricileri daha erken dahil etmesi gerekiyorsa, onlara söyleyin. Yazılı bir rapor gerçekten en iyi iletişim yöntemi değildir. İlk gereksinimlerin toplanmasında bir geliştirici yardımına ve geliştirme ve teste yardımcı olan bir iş analistine sahipseniz, sonuçlarınız daha iyi olacaktır.
Az önce Belirsizlik Konisini okudum; iyi şeyler, ama yanlış anlamak kolaydır. Yönetim ilk resme bakıp şöyle diyebilir: 'tamam, iş gereksinimlerimiz var, bu yüzden tahmininiz koninize göre% 50 doğru olmalıdır. Bana söyle'. Bu yardımcı olmaz.
Araba benzetmesi: Birisi size bir arabanın maliyetini sorar ve gereksinimleri ile bir kağıt verir. Kağıt, yaklaşık 1200 kg ağırlığında, dört tekerleği ve en az iki kapısı olması gerektiğini, ancak belki dört kişinin dört kişiyi oturtması gerektiğini ve iyi farların gerçekten önemli olduğunu söylüyor. Renk gri olmalıdır (ancak siyah da mümkün mü?).
25 bin dolar diyebilirsiniz ve daha sonra ortaya çıkarsa, yepyeni bir Range Rover istiyorsun. Bu daha doğru veya 100K $ maliyeti söylemek daha yararlı yapmaz. Kullanılmış (üzgünüm, ikinci el) bir Prius'a ihtiyacı olabilir. Hangisini bulmak için zaman bulamazsan, asla bilemezsin.
Çoğu zaman, spec yazarlarının gerçekten her şeyi düşünmediği ortaya çıkıyor ve genellikle sadece tasarım yapmaya ve geliştirmeye başladığımızda sorun çıkarıyoruz, çünkü spesifikasyonların çoğunda delikler var gibi görünüyor.
çoğu kullanımı yanlış.
Spesifik yazarların her şey boyunca düşünmesi mümkün değildir. Dönemi. Eğer her şey aracılığıyla düşünürlerse, kaç satır kod yazacağını ve hangi kod satırlarının doğru olduğunu bilirlerdi.
Spesifikasyonun yanlış olması gerektiğinden, bu konuda yapabileceğiniz çok şey yok.
sorunla sonuçlanır sorun.
Hem iş yönetimi hem de BT yönetimi olması gerektiği gibi tahminler ve son tarih tahminleri gerektirir.
Belki de değil. Genel tahminler ve son teslim tarihleri en faydalı şeyler değildir.
Böylece Agile yöntemlerinin geliştirilmesi.
Mesele bu. Spesifikasyonlara dayalı tüm tahminlerde hatalar bulunmalıdır. Sadece şansla haklılar. Zamanın yarısı, tahminin çok altında ve yarının çok üstünde olduğu zaman. Bu, geleceği eksik bilgilerle tahmin etmeye çalışmanın mantıklı bir sonucudur.
Bunun olması gerektiğinden, yanıldığınızda bela ile sonuçlanmamalısınız. Yanlış olmalısın. Ve sürekli ve rastgele yanlış olmalısınız. Aksi takdirde sayıları geçersiniz.
Belirsiz şartnamelerde, tahmine çok az güven duyulduğunu yönetime açıklamalısınız. Yani, tahmininiz% 30 veya% 40 veya% 50 veya ne düşündüğünüze göre değişebilir. Yani bir şeyin 2 gün olduğu tahmin edilirse, bu aslında 2-3 gün arasındadır.
Sonra bir proje sorunu kaydı oluşturun (wiki veya Jira'da olabilir). Tüm sorularınızı sorun olarak oluşturun ve işletmenizi sorunuzu yanıtlamasını sağlayın. Bir sorun çözülmediği sürece tahmin belirsizliğini koruyor. Mümkünse, bir iş analisti bunu kolaylaştırmak ve daha iyi gereksinimler yapmak için kanal olsun. Test ekibinizi, spesifikasyonlara karşı test senaryoları oluşturmak zorunda oldukları için spesifikasyonları gözden geçirin. Onların katılımı genellikle daha iyi özellikler yazılmasına yol açabilir. Kaç tane çözülmemiş sorununuz olduğunu yönetime günlük/haftalık olarak bildirin. Ne kadar çok çözülürse, tahminleriniz o kadar iyi olur. Rakamlar objektif olarak düşünmelerini ve sizi de güçlü bir zemine oturttuğundan metrikleri her zaman yönetime sunun.
Ayrıca, projenin büyüklüğüne bağlı olarak, önemli sorunları (gerek gerek teknikler) attığınız çözüm tasarımı aşaması için 1-4 hafta koyun. Ticari KOBİ'lerle birçok çalıştay düzenleyin ve bunları anlamaya çalışın ve sonuç olarak sonuca varmak için görüşlerinizi açıklayın. Sadece büyük kullanım durumları anlaşıldıktan ve tahminlerinizin% 80 güvene ulaşmasından sonra aşamaya geçmeniz gerekir.
İletişim genellikle en azından sağlıklı bir organizasyonda yardımcı olur.
Bu gümüş mermi değil, ama yapmaya çalıştığım (ve şirketimizde çalıştı), iş adamlarını hemen bir çözüm önermek yerine sorunu açıklamaya ikna etmektir. Bu nedenle özellik taleplerimiz, sorunun veya ulaşmak istedikleri hedefin bir açıklamasıyla başlar.
Daha sonra, bazı etki alanı bilgisine sahip bir geliştirici, bir şeyle karşılaşmaya çalışırken, işlerin tarafındaki birisine danışmaya çalışır. Genellikle bu işlem, tahminlerle birlikte birkaç alternatif çözüm üretir.
Bu noktada maliyete ve bir çözümün ne kadar eksiksiz olduğuna bağlı olarak bir tane seçmek işinize kalmıştır. Bu yöntemi de onlara bu şekilde satabilirsiniz, burada sadece birkaç adam günü değil, almaları veya bırakmaları için seçenekleri vardır. Tabii ki, onların da daha fazla kaynağa ihtiyacı var, ancak tahminler ve spesifikasyonlarla ilgili sorunlarınız varsa, buna değer bir yatırım.
Neden eksik, çakışan gereksinimler içeren veya mümkün olmayan bir gereksinim belirtimini kabul edesiniz? İşleminizin, spesifikasyonu değerlendirmeniz ve kabul etmeden ve tahmin vermeden önce düzeltmeler için geri göndermeniz için bir yol içermesini tavsiye ederim.
İkna daha iyi özelliklere yatırım yapmaya değer yönetim/müşteri. Alan bilgisi olan kişileri daha fazla dahil edin. Sonunda herkes bundan faydalanacak.
Özellikleri ortadan kaldırın.
İşletmeyi bir proje için Agile'ı (veya en azından Agile-ish sürecini) denemeye ikna edin.
Bunun yerine spesifikasyonları yazmak
Gösteriliyor özellikler yapılır. Erken ve sık sık bırakın. Şeffaf ve duyarlı olun. Bunun anlamsız sürelerin ortadan kaldırılmasına yol açacağını fark ettim.
Mimari için düzenle
Kim lider olursa mimarın olması gereken şeylerle iletişim kurmak için bir başlangıç toplantısı olmalı. Lider ayrıca, tüm ihtiyaçların karşılandığından emin olmak için dilligence olması gereken kişidir.
Süreçinizde bunları eklemek yerine ek adımlara ihtiyacınız varsa. Takımın işi yapmasını kolaylaştıran bir süreç vardır. Hakkında bir şey çalışmıyorsa değiştirin. Ona ekleyin, ondan çıkarın, sizin ihtiyaçlarınızı karşılayacak şekilde değiştirin. Özellikle güvenlik konusunda endişelenmeniz gerekiyorsa, bunun için adımlar ekleyin.
Unutmayın, özellik her yeni işlevsellik eklemek veya soruları temizlemek için her değiştirildiğinde, tahmini tekrar gözden geçirmenin zamanı gelmiştir. O kadar çok değil ki, söylendiğimiz şey göz önüne alındığında orjinal tahminimiz kötü ama geri itmiyoruz ve daha fazla ayrıntı sunulduğunda buna ihtiyacımız yok. Eğer bir ev inşa eden bir müteahhit olsaydım ve bir lamiante tezgahı kullanarak maliyeti tahmin etsem ve bir ay sonra müşteri granit bir tane isterse, bahse girebilirsin onunla maliyet tahminini tekrar gözden geçiririm. Müşterilerimizin kalitesiz gereksinimlerden kurtulmasına izin veriyoruz ve ortaya çıktığında geri dönmüyoruz Başlangıçta öngörülenden çok daha fazla şey var.