Bir geliştirici Excel makrosu tarafından yapılan bir iş yükü tahminini kabul etmeli mi?

Yeni bir projede, bir arkadaş, bunları yazmak için gereken sürenin geliştirici olmayan yöneticisi tarafından yazılmış bir Excel makrosu tarafından hesaplandığı yerlerde testler yazmak zorunda kaldı.

Bu gibi durumlarda, bir geliştirici testleri hesaplanan sürede yazma ve çalıştırma sorumluluğunu kabul etmeli mi? Bu testlerin sonuçları güvenilir midir?

Bilgi için, arkadaşım yapmadığı tahminlerden sorumlu olmayı reddetti, başka bir proje üzerinde çalışmayı başarmayı istedi ve yerine okul dışı tecrübesiz bir okul adamı geldi.

Geliştiriciye ne kadar duyarlı göründüklerine ve hangi verilere / mantığa dayandıklarına bağlıdır. (bunlar olabilir ne kadar zaman gerekli hakkında birkaç yılda toplanan istatistiki verilere dayanmalıdır - Bu geliştirici kendisi ve / veya başkaları tarafından tarafından - geçmişte benzer görevleri çözmek için ... ya da belki tamamen onun menajeri en dayanmalıdır - doğru veya yanlış - varsayımlar.)

İdeal olarak, yöneticisiyle, bir başkasının tahmin ettiği bir görevi üstlenmesinin ve sorumluluk almasının makul bir şekilde beklenemeyeceğini tartışmalıdır.

Tahminlere bağlı kalmayı açıkça reddetmek, onun derhal değiştirilmesine neden olabilir, bu nedenle daha yumuşak bir yaklaşıma sahip olmak ve mümkünse doğrudan karşı karşıya gelmekten kaçınmak daha iyidir.

Muhtemelen makro bir çeşit giriş verisi üzerinde çalışıyor, sadece rastgele bir sayı üreticisi değil mi? Bu nedenle, sorunuzu cevaplamak için giriş verilerinin ne olduğunu ve makronun ne yaptığını bilmemiz gerekir. Bu olmadan herhangi bir cevap oldukça anlamsızdır.

Yoksa sorunuz gerçekten ilgili deneyime sahip olmayan bir yönetici tarafından üretilen tahminleri kabul etmekle mi ilgili? Bu durumda cevap hayırdır, siz (veya arkadaşınız) kendi tahminlerini yapmalı ve bunları yöneticiye sunmalısınız. 2 rakam eşleşmiyorsa, en iyi yolu bulmak için birlikte çalışmaları gerekir - belki daha az test yazmayı kabul etmek veya belki de hepsini yazmak daha uzun sürebilir.

Nokta boş reddetme kimseye yardım etmeyecek ve buluşamayacağınız bir zaman ölçeğinde çalışmak da eğlenceli değil, çözüm profesyonel bir yaklaşım benimsemek ve işin devam etmesine izin veren bir uzlaşmaya varmaktır.

Kesinlikle HAYIR.

Küçük bir program, büyük ve karmaşık bir program bile, herhangi bir programlama işinin ne kadar süreceğini tahmin edemez. Nedeni için Yazılım Tahmininde Matematiksel Sınırlar bölümüne bakınız . Daha uzun, hakemli bir makale olan Yazılım Tahmininde Büyük Sınırlar da mevcuttur.

Ayrıca, söz konusu yöneticiyle ilgili fikrimi tekrar gözden geçiririm: geçmişte yazılım görev süresini tahmin etmeye çalışılan her şey göz önüne alındığında, neden bir elektronik tablo makrosunun geçmişte denenmediğine inanıyor.

Ihh!

Bu devasa bir "iş kokusu" dur. Bu inanılmaz bir mikro yönetim.

Eğer bir tahminde bulunmak için çalışanlarına güvenemezlerse, size başka ne güvenmezler?

Kesinlikle hayır.

Size söz veriyorum ki yönetici, Excel makrosunun tahminleri doğru bir şekilde tahmin edebileceğini düşünmekten pek memnun değil. Bir algoritmada böyle bir şeyi doğru bir şekilde tahmin etmek için çok fazla değişkenin olduğu iyi bilinen bir gerçeğin ne olması gerektiğini bile tartışmıyorum. Eğer böyle bir algoritma icat etmişse, patentini almalı ve bence milyonlar yapmalı.

Burada gerçekten olan şey, yönetici bu sözde Excel makrosunu, gerçekçi olmayan beklentileri ve geliştiricileri üzerinde aşırı baskıyı zorladığı gerçeğini gizlemek için ince örtülü bir kılık olarak kullanıyor.

BS olduğunu biliyor ve umursamıyor, kaynaklara çifte rezervasyon yapmak ve tüm "değersiz" geliştiricilerini sürekli "GEÇ" geçerek işleri daha hızlı yapmaya çalışmak için bir bahane.

Bu yönetici sömürücü bir pislik gibi geliyor.

Yeni bir projede, bir arkadaş, bunları yazmak için gereken sürenin geliştirici olmayan yöneticisi tarafından yazılmış bir Excel makrosu tarafından hesaplandığı yerlerde testler yazmak zorunda kaldı.

Yazılım projeleri de dahil olmak üzere projelerin tamamlanma süresini tahmin etmek için parametrik tahmin modelleri bulunmaktadır. Genellikle, tahmin üretim kodu içindir, ancak test kodu yazmanın ne kadar süreceğini tahmin etmenin neden tahmin edilemediğini anlamıyorum. Bu tahminler, ancak bunlara beslenen veriler kadar iyidir.

Kullanılan yöntemin geçerli bir tahmin modeli olduğunu ve verilerin doğru ve geçerli olduğunu varsayarsak, geliştirici olmayan bir yönetici tarafından yazılmış bir Excel makrosundan iyi bir tahminin gelmemesinin bir nedeni yoktur.

Bu gibi durumlarda, bir geliştirici testleri hesaplanan sürede yazma ve çalıştırma sorumluluğunu kabul etmeli mi?

Hiçbir koşul, hiçbir koşulda körü körüne kabul edilmemelidir. Nasıl üretildiğine bakılmaksızın hiçbir tahmin mükemmel değildir. Tahminleri gözden geçirmek, olası sorunları tespit etmek, etkilerini değerlendirmek ve tahmini gerektiği şekilde tartışmak ve düzeltmek mühendise bağlıdır.

Bu testlerin sonuçları güvenilir midir?

Testler sadece onları tasarlamak ve uygulamak için harcanan çaba kadar iyidir. Bir test cihazı düşük kaliteli testler üretirse, kusurlar testlerden geçerek projenin daha sonraki bir aşamasına geçecektir. Program basıncının düşük kaliteli testlere yol açmasının nedeni, bu nedenle uygun test senaryolarını tasarlamak ve sonra bu vakaları uygulamak için yeterli zaman yoksa, testler o kadar yararlı olmaz.

İki farklı soru soruyormuşsunuz gibi geliyor:

Bu testlerin sonuçları güvenilir midir?

Excel, üzerinde çalıştığımız herhangi bir araç gibi ve hesaplamaların yazıldığı şey, algoritmanın sonuçları üzerinde gerçekten bir etkisi olmamalıdır. Tahminin bir Excel makrosundan gelmesi, hesaplama sonuçlarının (yani tahminin geçerliliği) geçerli olup olmadığı ile ilgisizdir. Temel alınan modelde kötü varsayımlarınız varsa, temel varsayımların yanlış olması nedeniyle hesaplamayı yapmak için ne kullandığınız önemli değildir.

Bu gibi durumlarda, bir geliştirici testleri hesaplanan sürede yazma ve çalıştırma sorumluluğunu kabul etmeli mi?

Geliştiricinin belirtilen süre içinde işi yapması şartı temas halinde ise, tahminler makul olduğu sürece onunla tartışmak için yapabilecekleri çok şey yoktur. Bu da bir sonraki noktaya götürür: eğer hesaplamalar makul bir süre veriyorsa ve geliştiricinin kendilerine vereceği tahminlere benziyorsa, verilen zaman çizelgelerine itiraz etmemek için bir neden yoktur. Aslında, keyfi bir zaman çizelgesi verildiklerinde, modülde kullanılan varsayımları aksine etkileyebilecekleri için geliştiricilerin avantajına çalışabilir.

Zaman çizelgeleri gerekli iş miktarı için mümkün görünmüyorsa, o zaman bu endişeyi dile getirmeli ve daha gerçekçi zaman çizelgeleri elde etmek için yöneticiyle çalışmalı ve çalışmalıdır, ancak zaman çizelgesi uygulanabilirse, onlara itiraz etmekte zorlanacaklardır.

Proje yönetimi ve zaman çizelgelerinin hesaplanması açısından, evet, yapılabilir ancak büyük ölçüde yapılan işin doğasına bağlıdır. Muhtemelen birim test kodu yazmak için gereken süre (geliştiricinin çerçeveyi anladığını ve daha önce yazmış olduğunu varsayarak) verilen test kodunun yazıldığı kullanım durumlarına karşı yeni kod yazmaktan daha doğru tahminler göreceksiniz. için.

Yazma testlerini aşağı oynamak istemiyorum, ancak projede muhtemelen birkaç geliştirici daha önce bunları yazdı. Tahminler bu verilere dayanıyorsa, arkadaşınızın sandığından daha doğru olabilir. Arkadaşınız projeden ayrıldığından, karşıt tahminler yaratmaya ya da tahmin edildiği gibi tamamlanıp tamamlanamayacağına bakma girişiminde bulunmadığından asla bilemeyiz.

Tek yapması gereken, tahminin ne kadar doğru olduğunu görmek için bir veya iki testi tamamlamak ve meşru bir tartışma ile yöneticiye geri dönmekti. Tahminlerin güvenilirliği veya geride kalmanın sonuçları hakkında geri bildirimde bulunabilecek başka ekip üyeleri olabilir. Bazen bir yönetici, herkesi mutlu etmek için patronuna 'bir şey' vermek zorundadır. Geliştiriciler bunu sahte bir güvenlik duygusu olarak görüyor. Belki de geliştiricilerin tahminlerde bulunma ve bir şeyler yapma istekliliği gösterme hareketi olsaydı, yönetim daha fazla güven geliştirebilir.

Tahmin ettiğim şey, eğer testleri daha kısa sürede tamamlayabilseydi, bu konuda hiçbir şey söylemezdi. Sonra tekrar, inanmadığı bir uygulamadan kendini dışlamak, yüksek düzeyde bir bütünlüğe işaret edebilir.

Kolay ve kısa cevap:

Tahminin nereden geldiğini umursamazsınız.

Aslında umursadığınız şey tahminin kendisidir. Bunu katılıp katılmadığını katılmıyorum ve neden ve ne kadar açıklamak sen tahmin ediyorum. En önemlisi budur.

Teorik olarak, bir geliştirici, nasıl gelirse gelsin, başka herhangi bir kişi tarafından yapılan bir tahmini asla kabul etmemelidir. Bunun bir nedeni, yöneticinizden daha uzun bir tahmin vermenin potansiyel bir program problemini veya belki de yapılacak işin kapsamı hakkında bir yanlış anlama ortaya çıkarmasıdır.

İnsanlar genellikle programlama zamanı tahminini programlamanın kendisinden bile daha zor bulurlar, bu nedenle yöneticiniz bir Excel makrosu yazabilirse bu sorunu çözebilir , muhtemelen kodu yazmak için bir makro oluşturabilir (olası değildir).

Şimdi, pratikte , işi anlar ve tahminler makul görünüyorsa, geçerken metodoloji hakkında bazı endişeleri ifade etmek mantıklıdır, ancak daha sonra onlarla tanışıp karşılaşamayacağınızı geçici olarak kabul edin. Daha sonra, iş sizi tahminlerden daha uzun sürüyorsa, bunu mümkün olan en kısa zamanda yöneticilerinizin dikkatine sunmalısınız. Gerçek uygulama deneyiminize dayanarak kesin nedenleri tartışmaya hazır olun. Umarım bu noktada yöneticiniz mantıksız olmayacak ve mekanik olarak oluşturulan tahminlerde çalışmanız konusunda ısrar etmeye devam edecektir.

En yeni yazılım geliştirme yöntemlerinden biri çeviktir ve iyi bilinen çevik çerçevelerden biri scrum'dur . Ancak bu yöntemde, geliştiriciler (scrum ekibi) bir görev yapmak veya bir kullanıcı hikayesi uygulamak için gerekli süreyi hesaplamaktan sorumludur.

Kesinlikle HAYIR diyorum . Çünkü:

1. Geliştirici olmayan bir yönetici iş yapmak için gereken zamanı tahmin edemez
2. Herhangi bir işi yapmak için gereken zamanı tahmin etmek için Excel'in sahip olmadığı bir insan zekası gerekir.
3. Bu tür çalışma uygulamalarını kabul ederek yönetici, tahmini sürelerde geliştiricilerin yerine geçmeye alışmaktadır. Bu felaketle sonuçlanabilir. Yöneticinizin söylediği bu senaryoyu düşünün:

Çevrimiçi bisiklet satışı için yeni bir projeye başlamak istiyorum ve John ile sizin bunu başarmanızın 3 hafta sürdüğünü biliyorum.