Küçük ekipler için programlamayı planlamanın en iyi yolu? [kapalı]

Ben küçük bir başlangıç ​​organizasyonunun direktörüyüm. Şu anda bir web uygulama platformu oluşturan iki programcımız (biri deneyimli, biri daha az deneyimli) var.

Şimdiye kadarki en büyük zorluklardan biri planlama sürecidir. Programcılar genellikle kendi çalışmalarını planlamakla yükümlüdür, ancak kendi empoze edilen sürelerini aşmaya devam ediyoruz. Örneğin, tahmin ettikleri bir görev 2 gün sürecek, 8 gün sürecek.

Belirli bir görevin ne kadar süreceğini kesin olarak tahmin etmek için teknik bilgi birikimim olmadığından, bunları planlamada desteklemek benim için zor.

Herhangi bir fikrin var mı:

1. Bunun nedeni nedir, bu programcılar için yaygın mıdır?
2. Planlamada onları desteklemek için ne yapabilirim? Küçük ekiplerdeki programcılar için faydalı herhangi bir yöntem veya araç var mı?

Genel teknikler biraz sağduyudur, bilinmesi gereken önemli şey, çok fazla teknik uzmanlık gerektirmemesidir.

Planlamanın başlangıç ​​noktası, çözülmesi gereken kesin sorunu tanımlamak ve net ve açık bir gereksinime sahip olmaktır. Buna sahip değilseniz tahminleriniz yanlış olur. Herhangi birinin kod yazmaya başlamadan önce bunun bir tür özellik spesifikasyonunda belgelenmesi, kodlama başlamadan önce sorulması gereken soruların sorulacağı anlamına gelecektir. Bu şaşırtıcı derecede etkili bir zaman kazandırıcıdır. Geri dönmek ve gereksinimleri açıklığa kavuşturmak, bir programcı olarak akışını keser ve yanıt beklemek ilerlemeyi engelleyebilir.

Gereksinimi belirledikten sonra, çözüme dahil olan iş görevlerini tanımlamanız gerekir. Bu klasik bir bölünme ve fethetme egzersizidir - daha fazla parçalanabilecek herhangi bir görevin daha fazla parçalanması gerekir.

Daha büyük bir ekipte, ilgili herkesin deneyimine dayalı bir tahmin almak için tahmin pokerini kullanabilirsiniz. Bu, daha küçük bir ekipte işe yaramaz, ancak hem geliştiricilerinizden bağımsız bir tahmin almak hem de belki de kendinizden bir tane eklemek de yararlıdır - özel uzmanlık eksikliği burada yardımcı olabilir, çünkü size ne olduğunu açıklarken görev onların bakış açısından, geliştirme ekibi muhtemelen sorunu daha iyi kavrayacaktır.

Daha küçük bir ekiple, her görev için en iyi / beklenen / en kötü durum tahminini elde etmenize yardımcı olabilir, bu size bir dizi değer verir, ancak çok fazla taşma tahmini alıyorsanız, geliştiricilerinize kadar en kötü duruma doğru eğilebilirsiniz. daha doğru tahmin etmeyi öğrenir.

Küçük bir dükkanda, geliştiriciler genellikle sistem yöneticileri, destek ekibi ve hatta test uzmanları olarak ikiye katlanır (her ne pahasına olursa olsun, testler her ne pahasına olursa olsun kaçınmaya çalışmanız gerekir) bu yüzden bunu hesaba katmanız gerekir. Geliştiricilerinizin gerçekte ne kadar zaman harcadıklarını tahminlerinize dahil olan yeni özellikler ve faktörler üzerinde çalışarak anlayın. Bir görev 2 günde tahmin ediliyorsa, ancak geliştiricileriniz yalnızca% 60 oranında yeni geliştirme üzerinde çalışabiliyorsa, tamamlanması için 4 güne ihtiyacınız olacak. Acil olmayan yönetici veya destek görevlerinin geçici olarak ele alınmak yerine bir araya getirilebileceği şekilde, işlemek için ihtiyaç duydukları diğer görevlerin boru hattını kontrol ederek de bu konuda yardımcı olabilirsiniz. Bir çok programcı (kesinlikle buna kendim dahil) büyük zaman yöneticileri değil, bu nedenle bu konuda yardım etmek için yapabileceğiniz her şey yardımcı olacaktır. Tek görev, programcılar için her zaman çoklu görevden daha kolaydır. Gün içinde zamanın engellenmesi de bu konuda yardımcı olabilir.

Kayıt tutun - her planlama oturumunuzda tahminleri ve gerçekleri kaydedin. Daha sonra bunu a) planlama sırasında tahminlerini ne kadar şişirmek için bir rehber olarak ve b) tahmin becerilerini geliştirmelerine yardımcı olmak için kullanabilirsiniz. Her bir yinelemenin sonunda (ya da eşdeğeri ne olursa olsun) tüm ekip yapılan işi gözden geçirmeli ve gelecekteki tahminlere dahil edilebilmesi için neden beklenenden daha uzun sürdüğünü bulmalıdır. Bunun suçsuz bir görev olması gerekiyor - burada doğru tutuma sahipsin ama bu cevap biraz zaman alabilir, bu yüzden gözlem yapacağım. Birisi "Burada bir hata yaptım" derse, bunu "daha iyi ne yapabilirdiniz?" Haline dönüştürebilirsiniz, ancak insanlara çok yavaş olduklarını veya yanlış şeyler yaptıklarını söylemek sadece işleri daha da kötüleştirecektir.

Bu tür bir sorun için gümüş mermi olmadığının farkındayım, ancak en büyük faktör, daha küçük bir ekiple aslında daha kolay olan iletişim ve kolektif becerilerinizi geliştirmek için geri bildirim kullanmaktır.

[8 gün süren 2 günlük tahminlerinin] sebebi nedir, bu programcılar için yaygın mıdır?

Öyleyse, eğer:

• Aslında ne yapmaları gerektiği net değil, bu yüzden doğru yapmak için daha fazla zaman alıyorlar (ve daha sonra söylemeliler, ne kadar süreceğini tahmin etmemeliler)
• Eldeki göreve aşina değiller (o zaman bundan bahsetmeli ve tahmine araştırmayı dahil etmelidirler)
• Bitmiş görevin daha büyük ürünle entegrasyonu beklenenden daha uzun sürer (bu, ürünün mimarisinin daha düşük olduğu anlamına gelebilir)
• Geliştirici tekerleği yeniden icat etmeyi sever ve başkaları tarafından çözülmüş, kütüphanede serbestçe bulunan problemler üzerinde tökezler
• Değişiklikler, görev uygulanırken ürün sahibi tarafından farklı bir yaklaşım ve daha önce yapılan işin yeniden yapılmasını gerektiriyor.
• Geliştiriciler üretken bir ortamda çalışmazlar (bu yüzden evde olduklarında iki gün süreceğini tahmin ederler, ancak iş yerinde tüm dikkat dağıtıcı şeyleri telafi etmek için sekiz tane gerekir)

Birkaç şey söylemek gerekirse.

Belki de geliştiricilere tahminlerinin neden kapalı olduğunu düşündüklerini sormak en iyisidir. :-)

Geliştirme zamanını planlamanın en iyi yolunu bulmaya çalışan uzun bir atışla ilk siz olmayacaksınız. Bu kısmen, aslında inşa edildiğini göremediğiniz bir şeyi ölçmenin zor olmasından kaynaklanmaktadır ve kısmen efsanevi adam ayı nedeniyle , bu da 2 programcıya sahipseniz, 1 programcıya göre iki kat daha hızlı gelişebilir.

Muhtemelen daha önce fark ettiğiniz gibi, bundan çok daha karmaşıktır. Geliştirme süresini tahmin etmeye yönelik bir yaklaşım, yazılım geliştirmeyle ilgili olan bir grup yüksek nitelikli kişiyi yuvarlamak ve onlardan bir projeyi bitirmek için gereken süreyi tahmin etmelerini istemek (mümkün olduğunca ayrıntılı olarak açıklamak). Tüm tahminlerin en yüksekini alıyorsunuz ve siz iki katına çıkarırsınız. Evet, doğru okudunuz. Sen ikisinen yüksek tahmininiz varsa ve makul bir kesinliğe sahip olursunuz. Biliyorum, çünkü zamanla, patronlarıma bir şey yapmamın ne kadar sürdüğünü doğru bir şekilde söyleyebildim. Program arkadaşlarımın ve kendiminkilerin görüşlerini topluyorum ve en yüksek tahminin iki katı. Bu çok yüksek bir değer gibi görünüyorsa, yeni işlevselliği test etmenin çok önemli olduğunu ve daha sonra olası hata düzeltmelerini dikkate alın ve daha makul bir rakam gibi görünecektir.

Bir programcı olarak kendi kişisel deneyimimde, projelerin dönüm noktalarına bölünmesinin yardımcı olduğunu söyleyebilirim. Kilometre taşı 1'e, sonra kilometre taşı 1'den kilometre taşı 2'ye, sonra kilometre taşı 2'ye kilometre taşı 3'e, vb. Ulaşmak ne kadar sürer? Bu şekilde ayrıldığında, cevap genellikle tüm projeyi bütünüyle tahmin etmeye çalışmaktan çok daha doğrudur. Garip bir şekilde, tüm bu kilometre taşlarının tahminlerini özetlerseniz, genellikle tüm projenin orijinal tahmininden daha büyük olacaktır (programcı yine de kendine dürüstse), bu sadece beni detayın anahtar olduğunu düşünmeye yönlendiriyor buraya.

Belki de teknik bilgi birikiminden yoksundur, ancak yine de daha genel bir düzeyde takip etmeye çalışmalısınız. Programcıların tekrarlamada bir problemi yoktur. Bir program geliştirirken her zaman işgal eden bükülmeler ve dönüşler. Büyük olasılıkla, eklemek istediğiniz daha fazla işlevsellik, program ne kadar karmaşık hale gelecek ve bu yeni işlevin kodun daha önce uygulanmış bölümleri üzerinde hiçbir etkisi olmadığı varsayılarak, geliştirme, işin miktarına göre doğrusal olacaktır. yapıldı. Büyük olasılıkla, yeni işlevsellik, daha önce uygulanmış bölümleri büyük ölçüde etkiler ve bu nedenle geliştirme, yalnızca yeni işlevselliğin uygulanmasını değil, eski kodun düzeltilmesini ve geliştirme süresini katlanarak yapılmasını içerir.

Size tavsiyem, programcılara işlerini nasıl yapacaklarını söylemeden, programın genel düzeyde nasıl çalıştığını ele almaya çalışmanız ve yakında yeni işlevselliğin bu davranışı nasıl değiştireceğini ve böylece bunun ne kadar süreceği konusunda makul bir tahmin. Bunu tahminleriyle birleştirin (en yüksek iki katı) ve geliştirme süresini nasıl tahmin edeceğiniz konusunda daha iyi bir fikir edinmeye başlarsınız.

Umarım bu yardımcı olur!

Tahminlerin genellikle devre dışı kalmasının nedenlerinden biri, tahminin aslında oldukça zor olması ve sistem hakkında deneyim ve bilgi değişiminin gerekli olmasıdır. Çoğu zaman büyük adımların daha küçük adımlara bölünmesi faydalıdır.

Şimdi bunlardan birçoğuna değineceğim.

• Poker Planlama
• PERT (Program Değerlendirme ve Gözden Geçirme Tekniği)

Poker Planlama

Bu, küçük çevik takımlarda oldukça iyi çalışır.

Vikipedi'den alıntı:

• Toplantıya katılmayacak bir Moderatör başkanlık eder.
• Ürün Yöneticisi kısa bir genel bakış sunar. Ekibe, soru sorma ve varsayımları ve riskleri netleştirmek için tartışma fırsatı verilir. Tartışmanın bir özeti Proje Yöneticisi tarafından kaydedilir.
• Her birey tahminlerini temsil eden bir kart kapalı olarak bırakır. Kullanılan birimler değişir - gün süresi, ideal günler veya hikaye noktaları olabilir. Tartışma sırasında, sabitlemeyi önlemek için özellik boyutuyla ilgili olarak numaralardan hiç bahsedilmemelidir.
• Herkes kartlarını çevirerek aynı anda arar.
• Yüksek tahminleri ve düşük tahminleri olan kişilere, tahminleri için gerekçelerini sunmaları için bir sabun kutusu verilir ve tartışma devam eder.
• Bir fikir birliğine varılana kadar tahmin sürecini tekrarlayın. Çıktı sahibi olması muhtemel geliştiricinin "oy birliği" nin büyük bir kısmı vardır, ancak Moderatör oy birliği ile görüşebilir.
• Tartışmanın yapılandırılmasını sağlamak için bir yumurta zamanlayıcısı kullanılır; Moderatör veya Proje Yöneticisi herhangi bir noktada yumurta zamanlayıcısını ters çevirebilir ve bittiğinde tüm tartışmalar durmalı ve başka bir poker turu oynanmalıdır. Konuşmadaki yapı sabun kutuları tarafından yeniden tanıtıldı.

Buradaki önemli bitler, önyargı getirilmediği için aynı anda tahmini çağıran açıklama, tartışma ve fikir birliğidir.

PERT

Kesin bir tahmin vermek genellikle zordur. Daha kolay olan bir olasılık vermektir. PERT tahmin için 3 değer kullanır:

• bitirmek için en iyimser zaman (beklenenden daha az sorun ortaya çıkarsa)
• bitirmek için en kötümser zaman (her şey ters giderse - büyük felaketler hariç)
• büyük olasılıkla bitirmek için zaman (her şey beklendiği gibi giderse)

Bu üç tahmini ağırlıklandırarak daha güvenilir bir tahmin elde edersiniz.

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

Ve / veya bu üç değeri, gerçek dünyanın belirsizliğini daha da yansıtabilecek bir olasılık dağılımı oluşturmak için kullanabilirsiniz. Beta dağılımı ve Üçgen dağılımı önemli seçimlerdir. Bunu kullanarak "güncel tahminler verildiğinde x tarihinde bitirme olasılığı ne kadar" ya da "% 95 kesinlik istiyorsanız, hangi zamanda bitecek" gibi istatistikleri uygulayabilirsiniz.

Aslında PERT, kısaca uğruna atladığım, burada belirtilen bu yönlerden daha fazlasını içeriyor.

Tarihsel metrikleri tutmuyorsanız, makul tahminlerde makul bir doğrulukla bile yaklaşamayacağınız bir gerçektir. Ve başka bir şirkete / kişiye ne kadar süreceğini sormak da yardımcı olmaz. Sorun şu ki, her şirket ve geliştirici bir şeyler yapma yoluna sahip. Böylece, her şirketin aynı görevi yerine getirmesi için farklı süreleri olacaktır. Her geliştiricinin aynı görevi yerine getirmesi için farklı süreleri olacaktır.

En iyi eylem yolunuz zamanı takip etmeye başlamak ve bir şekilde görev için zorluk derecesini nasıl sınıflandıracağınızı bulmaktır. Bazı şirketler kod satırları kullanır, bazıları kullanım özellikleri, bazıları sadece bağırsak hissi ile gider. Ayrıca, bu, geliştiricilerin zaten inşa ettikleri bir şeye veya yeni teknoloji, ekip tarafından daha önce hiç inşa edilmemiş yeni özellik vb. zaman sistemi karmaşıklığı genellikle biraz artar.

Gerçek veri toplamazsanız, geliştiricileriniz kaç kez tahmin ederlerse versinler, onlara her sorduğunuzda gerçekten arkalarından rakamlar çekeceklerdir. Evet, gerçek veri toplamak acı vericidir ve başlangıçta çok fazla yararlı bilgi sağlamaz, ancak zamanla gerçekten makul tahminler sağlamaya başlar.

Ayrıca, tahminlerin genel olarak sadece büyük resim üzerinde iyi olduğunu ve kısa vadeli ölçümler için iyi olmadığını belirtmek isterim. Örneğin, geliştirici 2 gün tahmin eder, ancak 8 sürer. Eh, geliştirici bir test ortamı kurmak ve bir simülatör geliştirmek zorunda olduğunu ya da öğrenmek zorunda oldukları tamamen yeni bir teknoloji olduğunu ya da bir hataya takıldığını hesaba katmadı. çözemediler veya işlevsellik mevcut sistemin yeniden düzenlenmesi gerektiğini belirtti. Bu tür şeyleri her zaman küçük görevler için tahmin edemezsiniz. Bununla birlikte, tüm bir proje boyunca bu ekstra 6 gün, 6 gün daha kısa süren diğer görevler tarafından yıkanabilir.

Kendi başıma birkaç küçük projede tek geliştirici oldum ve büyük bir ekiple çalışırken endüstriyel deneyime sahibim. Büyük bir şirketin kullandığı tekniklerin küçük bir ekip için işe yaramadığını fark ettim. Bir noktada kod yazmak yerine daha fazla planlama ve dokümantasyon yapıyordum. Farklı teknikler (diğer cevaplar büyük bir içgörü sağlar) ve araçları deneyerek ilk önce iyi bir çalışma yöntemi bulmaya çalışmanızı öneririm, bu size biraz zaman ve çabaya mal olacak, ancak daha sonra bundan yararlanacaksınız. Yararlı bulduğum bazı araçlar / teknikler:

-Pivotal Tracker - Hikayeleri takip etmek ve yıkımları teşvik etmek için harika bir program, ödevleri hızlı bir şekilde aydınlatır ve hızları otomatik olarak azaltır. https://www.pivotaltracker.com/ .

-Belge için birden fazla kullanıcının aynı anda düzenleme ve tartışma yapması kolaydır.

-Çalıştığım bir şirkette, başlattığımız her hikaye için bir toplantı yapıyorduk, bu toplantıda bir görevin ne kadar süreceğini yargılama konusunda daha iyi olacağı için kıdemli bir programcı içermesi gerekiyordu. Ayrıca bir görevdeki zor kısmın ne olabileceğini yargılamada daha iyi olur.

Özetle, küçük ekiplerde çalışmanın anahtarının hızlı ve akıcı bir planlama rejimine sahip olmak olduğuna inanıyorum. Ayrıca hikaye ile ilgili herhangi bir zorluk erken tespit edilebilir, böylece bir görev planlamak bunu akılda tutacaktır (bu farklı bir şey inşa etmeye yol açabilir).

Bu yardımcı olur umarım