Projemin ilerlemesini (Çevik) işverenime (programcı olmayan) nasıl rapor edebilirim?

İşverene ilerleme kaydetme konusunda bir sorunum var. Yarı zamanlı bir programcıyım ve okulumun teknik olmayan bölümü için bir yazılım projesi yürütüyorum.

İrtibat kurulacak kişi:
1. Yazılımı gerçekten kullanan ve özellik talep eden personel,
2. Patronum (programcı olmayan) ve o yazılımın kullanıcısı değil.

Projenin doğası:
Üçüncü şahıslardan satın alınan hazır bir yazılımdır. Bölümün ihtiyacını karşılamak için bu yazılımı değiştirmek veya özellik / işlev eklemek zorundayım. Bu dönem boyunca kullanmanız gereken bir yazılımdır. Başlangıçta tüm özelliklerin kullanılması gerekmez.

Bu nedenle Agile modelini kullanıyoruz: Personel belirli bir özelliğe ihtiyaç duyduğunda, bir talepte bulunurlar ve değişiklikleri yaparım. Dönem sonunda, gerekli tüm özelliklerin geliştirileceğini ve uygulanacağını düşünüyorum.

Sorun:
Patronum bana ilerlemenin nasıl olduğunu sorduğunda, cevaplayamıyorum, çünkü nasıl cevap vereceğimi bilmiyorum. Gerekli tüm özelliklerin tam listesine sahip değilim. Geçen hafta geliştirilen özellikleri tamamlamış olmama rağmen, patronuma "tamamlandığımı" söyleyemem, çünkü yeni özellikler de geliyor ve ne kadar olduğunu bilmiyorum. "Kaç% tamamlama var" veya "xxx ile tamamlayacağız" diyemiyorum. 3 istek arasından bazen 2 tamamlamayı başardım, patronuma "2 tamamladım, ancak henüz tamamlanmamış bir özellik var" diyebilirim. Uzun bir süre sonra, "Her zaman bitmeyen bir şeyim var, çok uzun zaman sonra" gibi geliyor.

İlerlemeyi rapor edememek beni gerçekten kötü gösteriyor. Ne kadar yaptığımla ilgili değil, insanların nasıl bilgilendirileceği ile ilgili. Eğer yönetici olsaydım ve personelim ilerlemeyi bana aylarca bildirmeyi sürdürmezse, bu adamın da aciz olduğunu hissedeceğim.

"Yazılım değişikliğinin durumu / ilerlemesi nedir?"

GÜNCELLEME Patronum doğrudan geliştirme görevine dahil değildir, bu yüzden ne yaptığım veya programın nasıl çalıştığı hakkında bir fikri yoktur. Meşgul olduğu için düzenli olarak görüşmüyoruz ve zamanın harcanacağını hissediyorum çünkü ana kullanıcı değil, programın detayını bilmiyor.

Yazılımı kullanan ve bu konuda daha iyi bilen personel ile düzenli olarak görüşürüm.

Gelişimi patronuma açıklamakta zorlanıyorum.

Bağımsız çalışan bir programcıysanız ve teknik olmayan birine rapor verirseniz bu yaygın bir sorundur.

Bunun gibi patronlar çoğunlukla birkaç şey bulabilmek ister:

• Kullanıcılar ne kadar mutlu?
• Kullanıcıların yapmak istediği şeyler var mı?
• Yaptığınız para size ödenen paraya değer mi?

Çevik bir yanma ya da bunun gibi başka bir şey korkunç bir fikir olurdu! Dediğiniz gibi, patronunuz gerçekten meşgul, bu yüzden bunu öğrenmek için zamanları olmayacak ve muhtemelen yine de ilgilenmiyorlar.

Eğer siz olsaydım, haftada bir kez onlara aşağıdakileri içeren bir rapor e-posta gönderirdim:

• Başlangıçta "yönetici özeti": "Bu hafta 3 özellik tamamlandı ve 2 yeni özellik isteği aldı. Bu haftanın başında 11 bitmemiş özellik isteği vardı ve sonunda 10 vardı."
• Üç grup halinde, her biri kısa bir cümleyle birlikte bir özellik durum listesi:
  1. Hafta boyunca yaptığınız özellikler
  2. Hafta boyunca gelen özellik istekleri
  3. "Biriktirme listesi" ndeki diğer özellikler
• Tercihen teknik olmayan bir dil kullanılarak karmaşık veya olağandışı herhangi bir şeyin kısa bir tartışması.

Patronunuz olsaydım ve hiç rapor almamış olsaydım, bunu her hafta almaktan çok mutlu olurdum. Ve farklı bir şey isteseydim, senden bunu isterdim.

Kulağa tamamlanıp tamamlanmadığınızı veya tamamlanmanız için ne kadar uzakta olduğunuzu bilmenin hiçbir yolu olmadığı anlaşılıyor. Sorun yok.

İstenen, devam eden veya başlatılmayan özelliklerin bir listesini tutun. Bunları her kategorideki toplamın haftadan haftaya grafiği olarak izleyin. Bu size bitiş tarihini tahmin edebileceğiniz bir dizi puan verecektir. Yani (yalnızca "tamamlanmış" özellik sayılarına bakıldığında)

• Hafta 1 - 2 tamamlandı
• Hafta 2 - 5 tamamlandı (1. haftadan 2, 2. haftadan 3)
• Hafta 3-8
• Hafta 4 - 12

16 haftanız varsa, yaklaşık 48 özelliği tamamlayabilirsiniz (bazı özelliklerin diğerlerinden daha büyük / daha küçük olması konusunda endişelenmeyin, 4-5 hafta sonra genellikle ortalama olacaktır. Daha sonra herkese yalnızca X sayıda özelliği ele alabileceğinizi bildirebilirsiniz. Projenin sonunda, kesinlikle en önemli şey, gerekli özellikleri sağlamanız ve son iki haftada kendinizi öldürmemeniz. Bu şekilde bildirimde bulunarak, en kısa sürede temel gereksinimleri ortaya çıkarabilirsiniz.

Bildirmek isteyeceğiniz diğer bir şey, ne kadar kapasiteniz olduğu. "Sadece 2 özellik isteği aldım, ancak 3'ü halledebilirdim ... personelden daha fazla özellik yükseltmesini isteyebilir misin?"

Sorunuzu tamamen yanıtladığımdan emin değilim, bu yüzden takip soruları sormaktan çekinmeyin ...

Üç kelime ... grafiği yak.

Çevik bağımlılar olsun ya da olmasın, işvereniniz ya da sadece geliştiricilerden sorumlu bir kişi olsun, bir yakma şemasını takdir edecektir .

Herkes bir projenin ne zaman tamamlanacağını anlamayı sever ve dünkü hava koşullarından yararlanmak , bir projenin tamamlanmasını tahmin etmenin en doğru ve en gerçekçi yolunu sağlayacaktır.

Haftada en az bir kez bire bir yaptığınızı ve bu noktada önceliklerinizi yöneticinizle tartışabileceğinizi varsayıyorum - onun bakış açısından önemli olan şey (yani daha önce onun özelliğine ihtiyacı var) diğer kişi vb.) - ve yöneticinizin iyi görünmesini sağlayan şeylerin ne kadarının yapıldığını ve toplamda sahip olduğunuz şeylerin miktarını rapor edebilir.

Yöneticiniz büyük olasılıkla dakika dakika döküm aramıyor; işin yapılıp yapılmadığını, önemli şeylerin daha fazla dikkat çekip çekmediğini ve ilerlemenin engellendiği için yükün altında mı yoksa boşta mı olduğunuzu görmeye çalışıyor.

Gerçek bir çevik süreçte, her zaman gelen şeylerin olduğunu unutmayın, ancak siz ve yöneticiniz, en önemli / en çok ihtiyaç duyulan şey ve mevcut çalışma süresine ne kadar sığacağına karar veriyorsunuz (bu bir hafta, iki hafta, bir ay ...), gerektiğinde işleri daha küçük parçalara ayırın, böylece parçalar döneme sığar.

Birkaç hafta süren büyük bir veritabanı revizyonu şu şekilde bozulabilir: yedek oluşturma, yedeklemelerin iyi olduğunu doğrulama, yeni veritabanı düzenini tasarlama, dönüştürme yazılımını yazma ve test etme, geri dönüşü ayarlama ve test etme, dönüştürmeyi deneme evreleme makinesi, geri dönüşü aynı yerde deniyor ve sonunda dönüşümü yapıyor. Bunların her biri muhtemelen 1 haftalık (veya daha az) parçalara bölünebilir. Bazı adımlar 2 veya 3 hafta sürebilirse, bir sonraki toplantıda ne kadar ilerlediğinizi bildirirsiniz (2 haftalık% 50, 3 haftalık% 33 vb.).

İdeal olarak, şimdi yapacağınız şeylere karşı yapmanız gereken şeylere sahip bir grafiğiniz olur ve ilerlerken "şimdi yap" öğelerini işaretlersiniz. Bu, yöneticinizin sadece yanınızda kaç şey işaretlendiğini ve yapılacaklar listesindeki şeyleri görmesini sağlar.

Haftada bir kez (çevik işleminizdeki yineleme / sprint uzunluğunun örnek uğruna bir hafta olduğunu varsayıyorum), aşağıdakileri yapın :

• taleplerinin tamamlandığından emin olmak için yeni çalışmayı personele tanıtın
• hafta içinde tamamladığınız taleplerin sayısını patrona bildirin ve bu talepleri tanımlayın / tanımlayın. Kısa bir özet yapın
• hafta içinde birikiminize / kuyruğunuza eklenen yeni isteklerin sayısını ve toplam istek sayısını patronunuza bildirin
• patrona gelecek hafta hangi (hangi istekleri) çalışmayı planladığınızı söyleyin; diğer bir deyişle, mevcut öncelikler. İşte onun onaylaması veya değiştirmesi için bir fırsat ve ikinizin de bu konuda net olması için
• bundan sonra 1-2 hafta boyunca planın ne olduğunu patronunuza söyleyin.

Patronunuzun hız , ürün sahibi veya burdown çizelgesi gibi çevik terimleri dikkate alacak veya anlayacak kadar teknik olmadığını düşünüyorum . Yukarıdaki şablon bu jargondan kaçınır, sağduyuları içinde "biriktirme listesi" ve "kuyruk" gibi daha basit kelimeler kullanır ve bu nedenle patronunuzla iletişim kurmayı kolaylaştırır.

Hızımı onun için birincil istatistik olarak kullanırdım. Bu, belirli bir hafta (veya başka bir zaman aralığı) için kaç görev / özellik "kabul ettiğimi" ve kaç tane tamamladığımı gösterecektir. Bundan, bazı daha önemli özelliklerden ve bunun neden geçmiş iterasyonlardan değiştiğinden bahsedeceğim. Ayrıca karşılaştığınız ve aştığınız engellerden ve bunun hızınızı nasıl etkilediğinden de bahsedebilirsiniz.

Patronunuzun bilmek isteyebileceği diğer istatistikler, yeni hata raporlarının sayısını, hata raporlarını kapatmayı ve gönderilen yeni özellik isteklerini içerebilir. Hangisinin en önemli olduğunu belirlemek için doğrudan sormanız veya en iyi muhakemenizi kullanmanız gerekecektir. Sonunda, ilerlemenin temel bir taslağını verir ve onun ya da onun bilmek istediği başka bir şey olup olmadığını sorarım. Patronun bilmek istediği tek şey ilerleme kaydettiğinizdir ve en iyi şekilde çalışmak için ihtiyacınız olan her şey var mıdır.

Haftalık rapor hazırlamanızı öneririz: İstenen özellikleri listeleyin. Değiştirilen özellikleri kaydedin. Yaptıklarınızı bildirin.

Bunu, yöneticilerin anlayacağı bir şekilde sonuçlandırmayı denerdim.

Total Recieved Feature Requests:
Requests Completed:
Requests since last Update:
Estimated Time to required to complete remaining Requests:

Yöneticiniz bir programcı olmadığı için bunun tam bir tamamlanma tarihi bilmenizi bekledikleri anlamına gelmez. Sahip olduğunuz sayıları gösterin. Yönetici alınan ve tamamlanan isteklerin sayısını gördükten sonra yönetici ilerleme kaydeder. Talep numaralarınız kontrolden çıkarsa, yönetici aşırı yüklenmeden önce öncelik vererek size adım atabilir ve size yardımcı olabilir. Ve eğer işiniz biterse, size küçük bir yan proje bulabilirler. Sonuçta, bir projenin bitmesi ve iş günlerinin daha hızlı gitmesi ve meşgul olduğunuzda daha ödüllendirici görünmesi durumunda bir projeye biraz mola vermek her zaman güzeldir.