Yönetimi geliştirme sürecimizin dışında tutma

Yazılım geliştirme ekibinde yazılım mühendisiyim. Son 3 yılda dahili bir müşteri için yeni bir ürün üzerinde çalıştık. Şimdi bu ürün bittiğinde mevcut ürünler için önemli yeni özellikler üzerinde çalışacağız. Belirli bir özellik için ürün yönetimi, geliştirilmesinin 150 saat sürdüğünü tahmin etti. Proje yöneticimizle birlikte çok ayrıntılı bir plan hazırladık ve 300 saatlik bir çabaya başladık. Dün bunu tartıştık ve bir şeyleri çok fazla tahmin ettiğimizi düşünüyorlar.

Planlamamızda birim testleri yazmak için saatler tahmin ettik, onların fikri zaman kazanmak için onları boşaltmaktır. Karar henüz alınmadı ve gerekirse bu planlamayı ve birim testlerini savunacağım. Ama burada gerçekten sevmediğim şey, yönetimin gelişim sürecimize müdahale etmesi. Bunları geliştirme sürecimizden nasıl uzak tutarım? Ünite testini yerinde tutmak için hangi argümanları kullanabilirim (kalite ve uzun vadeli zaman tasarrufu dışında)?

Bir yan not olarak firmamızın 3 mühendislik ekibi var ve bulunduğum ekip yazılımlarını zamanında teslim ediyor (% 10 marj verin veya alın). Diğer takımlar her zaman geç teslim olurken, çoğunlukla planlamadaki hafife alınması nedeniyle. Sadece kodlamayı planlarlar, etrafındaki yönetim, test ve işlemeyi değil.

İlk olarak, konumunuza tamamen sempati duyduğumu söyleyeyim. İşin farklı bölümleri arasında bir anlayışınız veya iletişiminiz olmadığında sinir bozucu olabilir. Bunu söyledikten sonra, onları dışarıda tutmaya çalışacağını sanmıyorum. Bunun yerine, onlara bunun neden iyi bir fikir olduğunu gösteren sayıları göstermelisiniz. Ünite testini haklı çıkarmak için gösterdiğiniz çabaya değer nedir? Eğer herhangi bir şey yoksa, o zaman bu rakamları toplamaya başlamalı ya da iddialarını desteklemek için biraz araştırma göstermelisin .

Benzer senaryoları kendim ele almak zorunda kaldım ve bu soruyu benzer bir konuda cevapladım . Ayrıca burada nasıl ele aldığımı da blogladım:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Eğer link takip etmek istemiyorsanız, ilgili sorudan özetimi tekrarlayacağım:

Özetlemek gerekirse, proje için tahmini saatlerimizi gerçek saatler ile karşılaştırdım ve sonra hata oranımızı diğer ekiplerin kusur oranıyla karşılaştırdım. Bizim durumumuzda bu sayılar olumlu bir şekilde karşılaştırıldı ve daha fazla endişe yoktu.

Bu deneyime dayanarak elde ettiğim sonuç:

... herkesi bir şey yapma yaklaşımınızın pratik ve pragmatik olduğuna ikna etmenin en iyi yolu bunu yapmak ve diğer yaklaşımlara karşı ölçmektir. İnsanlar dogmayı veya neden bir şeyin en iyi yol olduğunu düşündüğünüzü umursamıyor. Sadece insanlara sayıları göstererek ve yaklaşımınızın etkinliğini ölçerek uygulamalarınızın etkili olduğunu gerçekten gösterebilirsiniz.

Yönetim ekibiniz gördüklerini birim test için 150 saat ek yatırım yapmayı kabul etmiyorsa, belki de onları ürünün küçük bir alanına yatırım yapmaya ikna edebilirsiniz (hatta bazı verileri sağlamak için saatleri kendiniz emmeyi kabul edebilirsiniz) ). Ürünün bir bölgesinde birim testi yapın, daha sonra ürünün o alanındaki kusur oranları ve ürünün diğer alanlarındaki kusur oranlarıyla karşılaştırıldığında bu hataları bulma ve düzeltme maliyeti hakkında veri toplayın. Umarız vakanızı yedeklemek için bazı veriler toplayacaksınız ve bu bir sonraki projeniz için bir sorun olmayacaktır.

Kullandığınız yönteme bakılmaksızın izlenmesi gereken bir numaralı kural,

1. Geliştiriciler kendi çalışmalarını tahmin etme hakkına sahip olmalıdır.
2. Paydaşlar bu çalışma arasında öncelik verme hakkına sahip olmalıdır.

Tahmin ve önceliklendirme, her iki taraf da kendi sorumluluklarını kabul ettikten sonra birlikte çok iyi çalışan iki güçtür. Tartışmak için zaman harcamak yerine, bu konuda hemfikir olun ve her iki tarafın da işlerini en iyi şekilde yapacaklarına saygı gösterin.

Birim testlerinin zaman kazandıracağına dikkat çekebilirsiniz, bu yüzden onları düşürürseniz tahmin 500 saate kadardır.

Onlara teknik borç ve birim testin değeri hakkında bilgi verin

Bak bu yazı bazı güzel fikirden teknik borç var. Bu yazıyı takip ederek aşağıdaki pdf'e ulaşabilirsiniz.

Birim test değeri bu yazı gibi (muhtemelen bulmak için daha fazla var)

Umut, onları geliştirme sürecinizden çıkarmak değil, onları doğru şekilde dahil etmelerini sağlamaktır.

IMHO orijinal planınızı yazmanız, teknik borcu ve birim testin değerini açıkladığınız bölüm 1 ve 2'yi (ekte değil) eklemeniz gerekir. Onlara alternatifler verin:

• her bir değişikliğin (geliştirme aşamasında ve bakım sırasında) ortalama olarak alacağı daha az saat (150'nin tamamı değil, saçma geliyor):
  • küçük 4 saat
  • orta 16 saat
  • büyük 40 saat
• her değişikliğin (geliştirme aşaması ve bakım sırasında) ortalama olarak alacağı tahmini saatleriniz:
  • küçük 2 saat
  • orta 8 saat
  • büyük 20 saat

(Saatler sadece gösterge niteliğindedir. Doğru tahminler vermek için çok daha donanımlısınız.)

Zamanında bütçe içi teslimatlar için geçmiş performansınızı eklemeyi unutmayın.

Bunu yazın ve onlarla tartışın. Şu anda ihtiyaç duymayan özelliklerde veya zamanında teslim etmek için almaya istedikleri bazı teknik borçlara sahip olabilirler. Bunların bilinçli seçimler olduğundan emin olun.

Umarım bu yardımcı olur ve iyi şanslar.

Her şeyden önce, "yazma birimi testlerini" tahmin edilecek, planlanacak ve potansiyel olarak kesilecek ayrı bir görev olarak ayırmayın. Tahminleriniz "XYZ - 18 saat uygulayın" özellik düzeyinde olmalıdır. Bu 18 saat, "yazma birimi testleri" de dahil olmak üzere bu özelliği "YAPILDI" seçeneğine getirmek için işleminizde ne gerekiyorsa içermelidir.

Teknik olmayan gelişmeyi "geliştirme sürecinizden" çıkarmanın iyi bir yolu budur. Geliştirme sürecinizi onlara verdiğiniz görev listesine veya proje çizelgesine dahil etmeyin!

İkincisi, takımınız zaten onlara ve zamanında iyi ürünler teslim ediyor gibi görünüyor, ancak diğer takımlar değil. Belki de bu yönetim grubu bu ekipleri mikro yönetmeye alışkındır. Güçlü yönlerinizle oynayın - çalışma özellikleriyle haftalık veya iki haftalık güncellemeleri göstermeyi teklif edin ve "geliştirme süreci" ile ilgili geri çekileceksiniz.

Bir zamanlar çok iyi bir durumda bir kod tabanı ile çalıştığım bir durumdaydım; çok kısa bir zaman dilimi içinde zorlayıcı yeni bir özelliğe ihtiyaç duyuldu ve bu özelliği çok kısa sürede sunmayı başardım. Bu noktada kod tabanı çok daha kötü bir durumdaydı. Bu yüzden özellik sunuldu, ancak işim yapılmadı: Her şeyi eşit derecede iyi bir duruma geri koymak zorunda kaldım.

Yöneticiye şöyle iki seviye açıkladım: Evinizde bir boya işi yapmak gibi. Tüm aletler ait oldukları yerde ve iyi durumdalarsa, tüm fırçalar temizlenir vb., Çok hızlı bir şekilde boya işi yapabilirsiniz. Ama sonra tüm araçlarınızı sıraya koymak için zaman harcamanız gerekiyor. Bunu yapmazsanız, bir sonraki boya işiniz çok daha uzun sürecektir. Aslında, aletlerinizin nerede olduğunu hatırlamayacaksınız, boya fırçalarınız artık kurtarılamıyor ve temizlik işini hemen yapmış gibi size daha fazla zaman ve para harcıyor.

Programlama işimde de aynı şey: Temizleyerek, kod tabanını bir dahaki sefere ihtiyaç duyulduğunda çok hızlı bir şekilde bir şey gönderebileceğim bir duruma getiriyorum. Değilse, bir dahaki sefere çok daha uzun sürecek.

Bunları işleminizden tamamen uzak tutamazsınız, sonuçta ücretlerinizi öderler ve ürününüzü kullanırlar (doğrudan değilse, muhtemelen şirketinizdeki bir kişi son kullanıcıdır).

Devleri aşırı tahmin etmekle suçlayan yöneticiler benim deneyimimde çok yaygın bir senaryodur ve eğer ele alınmazsa, patronların onları yarıya indireceğini bildiğiniz için bir sonraki tahminlerin iki katına çıktığı oldukça aptal bir silahlanma yarışına yol açabilir. onlar çeyrek onları, bu yüzden onları dörtlü vb. vb. mümkünse bu kısır döngü önlemek gerekir.

Son başvuru tarihi için "ölü ölü" nedeni olmadığını varsayarsak, 2 şey öneririm.

1. Mevcut yüksek kaliteli iş yaklaşımınıza bağlı kalarak 150 saat içinde neler yapabileceğinizi düşündüğünüze dair ayrıntılı bir plan sunun. Bu zaman diliminde neler yayınlanabileceğini tam olarak numaralandırın. KeesDijk gelen cevabı ince taneli düzeyde planlama bazı çok iyi bağlantıları vardır.
2. Tüm özellikleri kapsayacak şekilde aynı detaylı planlama tarzında devam edin ve nasıl 300 saat süreceğini (veya rakam ne olursa olsun) gösterin.

Ardından çalışmaya devam edin ve ilerleme hakkında düzenli olarak rapor verin ve mümkünse düzenli aralıklarla bazı çıktılar alın. Bu, yönetime tahmin becerilerinize ve sunma yeteneğinize güven vermelidir.

Tahminlerine dayanarak onlardan isteyin. Sadece tutarsızlıkları tartışmak adil olur. Damping ünitesi testleri yanlış bir ekonomidir, daha sonra (ve daha uzun bir süre) bir hata ayıklayıcıda harcayacağınız birim testleri yazmak için harcadığınız şey değildir. Esasen, tamamladığınız işi test etmeyi planladığınız gerçeğini belgelediniz. Onlar testin demekle olan hiç . İster projeyi geliştirirken birim testleri ister ad hoc test kullanarak test yapın, o zaman hesaba katmanız gerekir. Birim testi için ayrılan sürenin kaldırılması, geçici sınama için ayrılan süreyi de kaldırır.

Alt satır: tahmininizle silahlarınıza sadık kalın. Geçmiş performansınız, neden bahsettiğinizi bildiğinizi gösterir ve tahmininizin temeline (varsayımlar, beklentiler, geçmiş performans vb.) Makul bir cevap verebilir. Üst yönetiminiz makul bir tahmin oluşturmak için ihtiyaç duydukları görünüme sahip değil gibi görünüyor. Toplantılara ara vermeden 8 saat varsayıyorlar mı? Tahminlerinde sistem testi için bütçe oluşturuyorlar mı? Geçmiş performansınızı göz önünde bulundurarak, yarınızın yarısı olan sayıyı nasıl buldular?

300 saat süreceğini tahmin ediyorum ve eğer 150 bütçe onlara seçenek vermek buggy acele iş ya da teslim edilecek geç olacak. Proje tamamlandığında ve tahmin ettiğiniz gibi olduğunda, onlara istediğiniz şeyi söyleyebilirsiniz.

Wally ne yapardı?

Yönetimin sizden ne istediğini yorumlamanın birçok yolu vardır, bunlardan biri zamanında teslim etmenizi istememesidir.

Saçma görünüyor mu? Evet, ama fazla tahmin etmediğinizi başka nasıl bilebilirler? İşleri zamanında teslim etmeyin emin bakmak edilmesi zamanında bir şeyler sunmak yanlışlıkla kayma ve gerektiği, (gerekirse tembellik) gerçekten o parkta yürüyüş olduğu izlenimi vermemek için olduğu gibi yorgun.

Turşu içindesin. Silahlarınıza bağlı kalırsanız ve birim testlerine bağlı kalmak istiyorsanız ve 300 saati talep etmek istiyorsanız, düşmanlar yapacaksınız.

150 saate düştüğünde ve mandren ünitesi testlerinde daha hızlı bir hata ayıklama ürünü sunabilirsiniz, ancak daha yüksek bakım maliyeti ile yolda keder yaratacaktır.

Her iki durumda da kaybedersiniz.

Ya da öyle görünüyor.

Görüyorsunuz, bir üniversitede bilim laboratuvarı işletmiyorsunuz. Bir şirket ekosistemindeki müşterilere hizmet sağlayan bir şirketteki bir iş birimine iş hizmeti veriyorsunuz. Şirketinizin müşterilerine daha hızlı ve daha iyi hizmet sunmaya başlaması ve böylece gerekli gelirleri artırması için ürününüze ihtiyacı olabilir.

Görüyorsunuz, ihtiyacınız olan şey bir yatırım getirisi analizi ve bu analizi yapacak tüm verileriniz yok. Maliyet kısmının sadece bir kısmına sahipsiniz (herkesin bordro numaralarını bilmiyorsunuz) ve kesinlikle gelir bölümlerine sahip değilsiniz, özellikle de gelir projeksiyonlarına değil.

Yönetiminiz, ister inanın ister inanmayın, yatırım getirisi projeksiyonları yapmak konusunda yeterlidir (iş okulunda öğrettikleri şey budur) ve birden fazla yatırım getirisi projeksiyonu gerçekleştirmiş olabilir ve "şimdi hareket edersek çok daha fazla para kazanacağız BT'deki bozosun şikayet ettiği yazılımın bakımı için üç kat ödeme. "

Eğer ortak çalıştırmak istiyorsanız, kendi şirket kurmak. Göreceksin, o kadar kolay değil.

Başka bir deyişle: size söylediklerinizi yapın. Yönetim ne yaptığını biliyorsa, öne çıkacaksınız. Değilse, iş dışındasınız, birim testleri veya değil.

İstediğiniz YG nedir? Yatırım getirisi. Yine de kötü bir isim. Zamanında Yatırım Getirisi (ROTI) olmalıdır, çünkü zamanlama yatırımdaki her şeydir.