Najlepszy sposób na zaplanowanie programowania dla małych zespołów? [Zamknięte]

Jestem dyrektorem małej organizacji startupowej. Obecnie mamy dwóch programistów (jeden doświadczony, jeden mniej doświadczony), którzy tworzą platformę aplikacji internetowych.

Jednym z największych dotychczasowych wyzwań jest proces planowania. Programiści zwykle odpowiadają za planowanie własnej pracy, ale wciąż przekraczamy ich narzucone terminy. Na przykład zadanie, które według nich zajmie 2 dni, w końcu 8 dni.

Trudno mi wesprzeć ich w planowaniu, ponieważ brakuje mi technicznej wiedzy, aby precyzyjnie oszacować, jak długo będzie trwać określone zadanie.

Masz jakiś pomysł:

1. Jaki jest tego powód, czy jest to wspólne dla programistów?
2. Co mogę zrobić, aby wesprzeć ich w planowaniu? Czy są jakieś metody lub narzędzia przydatne dla programistów w małych zespołach?

Ogólne techniki są dość rozsądne, ważne jest, aby wiedzieć, że nie wymagają dużej wiedzy technicznej.

Punktem wyjścia przy planowaniu jest określenie dokładnego problemu, który musi zostać rozwiązany, oraz określenie jasnych i jednoznacznych wymagań. Jeśli tego nie masz, twoje prognozy będą niepoprawne. Udokumentowanie tego w jakiejś specyfikacji funkcji, zanim ktokolwiek zacznie pisać kod, oznacza, że ​​wszelkie pytania, które należy zadać, zostaną zadane przed rozpoczęciem kodowania. Jest to zaskakująco skuteczna oszczędność czasu. Cofanie się i wyjaśnianie wymagań przerywa przepływ pracy jako programista, a oczekiwanie na odpowiedzi może blokować postęp.

Po zidentyfikowaniu wymagania należy zidentyfikować zadania związane z jego rozwiązaniem. Jest to klasyczne ćwiczenie typu dziel i zwyciężaj - każde zadanie, które można dalej rozbić, wymaga dalszego rozbicia.

W większym zespole możesz skorzystać z pokera szacunkowego, aby uzyskać oszacowanie oparte na doświadczeniu wszystkich zaangażowanych osób. To nie działa tak dobrze w mniejszym zespole, ale nadal przydatne jest uzyskanie niezależnego oszacowania od obu deweloperów, a być może także uwzględnienie jednego od ciebie - twój brak specjalistycznej wiedzy może być pomocny tutaj, ponieważ wyjaśniając ci, co zadanie polega z ich punktu widzenia, zespół programistów prawdopodobnie lepiej zrozumie problem.

Mniejszy zespół może pomóc w uzyskaniu najlepszego / oczekiwanego / najgorszego oszacowania przypadku dla każdego zadania, co daje zakres wartości, ale jeśli otrzymujesz dużo przekroczeń, możesz skłaniać się w kierunku najgorszego przypadku, aż do momentu, gdy twoi deweloperzy naucz się szacować dokładniej.

W małym sklepie programiści często stają się podwajani jako sysadmini, zespół wsparcia, a nawet testerzy (chociaż ze wszystkich rzeczy, które mogą robić, testowanie jest tym, którego powinieneś unikać za wszelką cenę), więc musisz wziąć to pod uwagę. Dowiedz się, ile czasu faktycznie spędzają programiści pracując nad nowymi funkcjami, i uwzględnij to w swoich szacunkach. Jeśli zadanie jest szacowane na 2 dni, ale Twoi twórcy są w stanie pracować nad nowym rozwojem tylko w 60% przypadków, będziesz potrzebował 4 dni na jego ukończenie. Możesz także pomóc w tym, kontrolując szereg innych zadań, z którymi muszą sobie poradzić, dzięki czemu zadania administracyjne lub pomocnicze, które nie są pilne, mogą być zestawiane razem, a nie wykonywane doraźnie. Wielu programistów (z pewnością włączając w to mnie) nie jest świetnymi menedżerami czasu, więc wszystko, co możesz zrobić, aby pomóc w tym względzie, pomoże. Jednozadaniowość jest zawsze łatwiejsza dla programistów niż wielozadaniowość. Pomocne może być również zablokowanie czasu w ciągu dnia.

Rejestruj - za każdym razem, gdy masz sesję planowania, rejestruj szacunki i wartości rzeczywiste. Następnie możesz użyć tego a) jako przewodnika, o ile należy zwiększyć swoje prognozy podczas planowania i b), aby pomóc im udoskonalić swoje umiejętności szacowania. Na koniec każdej iteracji (lub jakiejkolwiek równoważnej masz) cały zespół powinien dokonać przeglądu wykonanej pracy i dowiedzieć się, dlaczego zajęło to więcej niż oczekiwano, aby można ją było uwzględnić w przyszłych szacunkach. To musi być nienaganne zadanie - wydaje się, że masz tutaj właściwe podejście, ale odpowiedź może być za jakiś czas, więc dokonam obserwacji. Jeśli ktoś powie „popełniłem tutaj błąd”, możesz zmienić to w „co mogłeś zrobić lepiej”, ale powiedzenie ludziom, że byli zbyt powolni lub źle postępowali, tylko pogorszy sprawę.

Nie zdaję sobie sprawy z tego, że nie ma srebrnej kuli dla tego rodzaju problemów, ale najważniejszym czynnikiem jest komunikacja - co w rzeczywistości jest łatwiejsze w mniejszym zespole - i wykorzystanie informacji zwrotnych w celu udoskonalenia twoich wspólnych umiejętności.

Jaki jest powód [ich szacunek 2 dni zajmuje 8 dni], czy jest to wspólne dla programistów?

Jest tak, jeśli:

• W rzeczywistości nie jest jasne, co mają zrobić, więc poświęcenie im czasu zajmuje więcej czasu (a więc powinni to powiedzieć, nie zgadując, ile to zajmie)
• Nie są zaznajomieni z danym zadaniem (powinni o tym wspomnieć i uwzględnić szacunki)
• Integracja gotowego zadania z większym produktem trwa dłużej niż oczekiwano (co może oznaczać, że architektura produktu jest gorsza)
• Deweloper lubi wymyślać koło na nowo, a tym samym potknie się o problemy, które zostały rozwiązane przez innych, bezpłatnie dostępne w bibliotece
• Zmiany są wprowadzane przez właściciela produktu podczas realizacji zadania, co wymaga innego podejścia i ponownej pracy
• Deweloperzy nie pracują w produktywnym środowisku (więc w domu sądzą, że zajęłoby to dwa dni, ale w pracy będą potrzebować ośmiu, aby zrekompensować wszelkie zakłócenia)

Aby wymienić kilka rzeczy.

Być może najlepiej zapytać programistów, dlaczego uważają, że ich prognozy są dalekie. :-)

Z pewnością nie będziesz pierwszym, który spróbuje znaleźć najlepszy sposób na zaplanowanie czasu rozwoju. Wynika to częściowo z faktu, że trudno jest określić ilościowo coś, czego nie można zobaczyć podczas budowy, a częściowo z powodu mitycznego miesiąca człowieka , co jest bezpośrednim przeciwieństwem intuicyjnej idei, że jeśli masz 2 programistów, powinieneś móc rozwijać się dwa razy szybciej niż gdybyś miał 1 programistę.

Jak zapewne już sobie uświadomiłeś, jest to o wiele bardziej skomplikowane. Jedno podejście do szacowania czasu programowania jako zaokrąglenia grupy wysoko wykwalifikowanych osób do tego, co dotyczy opracowywania oprogramowania, i poproś ich o oszacowanie czasu potrzebnego na ukończenie projektu (wyjaśnienie tak szczegółowe, jak to możliwe). Bierzesz najwyższy ze wszystkich szacunków i podwajasz go. Tak, czytasz poprawnie. Ci podwoićnajwyższy kosztorys, a będziesz miał dość dokładny kosztorys. Wiem, ponieważ z czasem w ten sposób mogłem dokładnie powiedzieć moim szefom, ile czasu zajmuje mi zrobienie czegoś. Zbieram opinie innych programistów i własne i podwajam najwyższe szacunki. Jeśli wydaje się to zbyt wysoką wartością, zastanów się, że testowanie nowej funkcjonalności ma kluczowe znaczenie, a następnie rozważ potencjalne poprawki błędów i będzie to wyglądać bardziej rozsądnie.

Z własnego doświadczenia jako programisty mogę powiedzieć, że pomaga to w podziale projektów na kamienie milowe. Jak długo trwa osiągnięcie kamienia milowego 1, a następnie od kamienia milowego 1 do kamienia milowego 2, a następnie kamienia milowego 2 do kamienia milowego 3 itd.? W przypadku takiego podziału odpowiedź jest zwykle o wiele bardziej dokładna niż próba oszacowania całego projektu w całości. O dziwo, jeśli podsumujesz szacunki wszystkich tych kamieni milowych, zwykle będą one większe niż pierwotne szacunki dla całego projektu (jeśli programista i tak jest szczery ze sobą), co tylko prowadzi mnie do przekonania, że ​​szczegół jest kluczem tutaj.

Być może brakuje ci technicznej wiedzy, ale nadal powinieneś starać się podążać na bardziej ogólnym poziomie. Programiści nie mają problemów z powtarzaniem. Cały czas w rozwoju programu zajmują się zwroty akcji. Najprawdopodobniej im więcej funkcji chcesz włączyć, tym bardziej skomplikowany będzie program, a przy założeniu, że ta nowa funkcjonalność nie ma wpływu na wcześniej zaimplementowane sekcje kodu, rozwój będzie przebiegał liniowo zgodnie z ilością pracy do będzie zrobione. Najprawdopodobniej nowa funkcjonalność w dużym stopniu wpływa na wcześniej zaimplementowane sekcje, a zatem rozwój obejmuje nie tylko implementację nowej funkcjonalności, ale także naprawienie starego kodu, co powoduje, że czas programowania jest wykładniczy.

Radzę ci, aby bez informowania programistów, jak mają wykonywać swoją pracę, postaraj się zrozumieć, jak program działa na poziomie ogólnym, i wkrótce powinieneś zobaczyć, jak nowa funkcjonalność zmodyfikuje to zachowanie, a tym samym zapewni rozsądne oszacowanie, ile czasu to zajmie. Połącz to z ich szacunkami (dwukrotnie najwyższą), a zaczniesz uzyskiwać lepsze pojęcie o tym, jak oszacować czas rozwoju.

Mam nadzieję że to pomogło!

Jednym z powodów, dla których oszacowania są często dalekie, jest to, że oszacowanie jest w rzeczywistości dość trudne i wymaga zmiany doświadczenia i wiedzy o systemie. Najczęściej pomocne jest dzielenie dużych kroków na mniejsze.

Teraz masz wiele możliwości tych, o których wspomnę dwie:

• Planowanie pokera
• PERT (technika oceny i przeglądu programu)

Planowanie pokera

Działa to całkiem dobrze w małych zwinnych zespołach.

Fragment z wikipedii:

• Moderator, który nie będzie grał, przewodniczy spotkaniu.
• Menedżer produktu zapewnia krótki przegląd. Zespół ma możliwość zadawania pytań i dyskusji w celu wyjaśnienia założeń i ryzyka. Podsumowanie dyskusji jest rejestrowane przez kierownika projektu.
• Każda osoba kładzie zakrytą kartę przedstawiającą ich oszacowanie. Używane jednostki różnią się - mogą to być dni trwania, dni idealne lub punkty historii. Podczas dyskusji nie można w ogóle podawać liczb w odniesieniu do rozmiaru elementu, aby uniknąć zakotwiczenia.
• Wszyscy dzwonią do swoich kart jednocześnie, odwracając je.
• Ludzie z wysokimi i niskimi szacunkami otrzymują mydelniczkę, aby uzasadnić swoje szacunki, a następnie dyskusja trwa.
• Powtarzaj proces szacowania, aż do osiągnięcia konsensusu. Deweloper, który prawdopodobnie był właścicielem rezultatu, ma dużą część „konsensusu”, chociaż moderator może negocjować konsensus.
• Timer jajeczny służy do zapewnienia odpowiedniej struktury dyskusji; Moderator lub Kierownik Projektu mogą w dowolnym momencie obrócić wyłącznik czasowy jajka, a kiedy skończy się, wszystkie dyskusje muszą zostać zakończone i rozpoczyna się kolejna runda pokera. Struktura rozmowy jest ponownie wprowadzana przez skrzynki na mydła.

Ważnymi częściami są wyjaśnienie, dyskusja, jednoczesne wywołanie oszacowania, aby nie wprowadzać uprzedzeń i konsensus.

ZUCHWAŁY

Często trudno jest podać jedną dokładną ocenę. Łatwiej jest podać prawdopodobieństwo. PERT wykorzystuje 3 wartości do oszacowania:

• najbardziej optymistyczny czas na zakończenie (jeśli pojawi się mniej problemów niż oczekiwano)
• najbardziej pesymistyczny czas na zakończenie (jeśli wszystko pójdzie nie tak - z wyjątkiem poważnych katastrof)
• najprawdopodobniej czas na ukończenie (jeśli wszystko pójdzie zgodnie z oczekiwaniami) <- właśnie to szacują Twoi programiści w tej chwili

Ważąc te trzy szacunki, otrzymujesz bardziej wiarygodne oszacowanie.

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

I / lub jesteś w stanie wykorzystać te trzy wartości do skonstruowania rozkładu prawdopodobieństwa, który może jeszcze bardziej odzwierciedlać niepewność realnego świata. Dystrybucja beta i dystrybucja trójkątna to wybitne wybory. Za pomocą tego możesz teraz zastosować statystyki, takie jak: „jak prawdopodobne jest zakończenie w dniu x przy obecnych bieżących szacunkach” lub „jeśli chcę 95% pewności, w którym momencie to się skończy”.

W rzeczywistości PERT składa się z więcej niż wymienionych tu aspektów, które pominąłem ze względu na zwięzłość.

Faktem jest, że jeśli nie trzymasz wskaźników historycznych, nie możesz nawet zbliżyć się do podania rozsądnych szacunków z rozsądnym stopniem dokładności. Zapytanie innej firmy / osoby, jak długo to zajmie, również nie pomaga. Problem polega na tym, że każda firma i programista mają swój własny sposób działania. Dlatego każda firma będzie miała inny czas na wykonanie dokładnie tego samego zadania. Każdy programista będzie miał inny czas na wykonanie dokładnie tego samego zadania.

Najlepszym sposobem, aby zacząć śledzić czas i dowiedzieć się, jak sklasyfikować stopień trudności zadania. Niektóre firmy używają wierszy kodu, niektóre używają funkcji, niektóre po prostu przeczuwają. Ponadto należy również wziąć pod uwagę, jeśli jest to podobne do czegoś, co deweloperzy już zbudowali, lub czegoś nowego, takiego jak nowa technologia, nowa funkcja, której nigdy wcześniej nie zbudował zespół itp. ... Ponadto, jeśli jest to osadzone lub prawdziwe system czasu, a następnie złożoność ogólnie znacznie wzrasta.

O ile nie zbierzesz prawdziwych danych, bez względu na to, ile razy programiści podadzą Ci szacunki, tak naprawdę będą wyciągać od siebie za każdym razem, gdy ich o to poprosisz. Tak, gromadzenie prawdziwych danych jest uciążliwe i na początku nie dostarcza wielu użytecznych informacji, ale z czasem naprawdę zaczyna dostarczać dość dokładne szacunki.

Chciałbym również zauważyć, że szacunki są ogólnie dobre tylko w odniesieniu do ogólnego obrazu, a nie w przypadku pomiarów krótkoterminowych. Na przykład programista szacuje 2 dni, ale zajmuje to 8. Cóż, programista nie wziął pod uwagę konieczności skonfigurowania środowiska testowego i opracowania symulatora, ani że była zupełnie nowa technologia, której musieli się nauczyć, lub utknął na błędzie nie mogli się zorientować lub funkcjonalność wymagała refaktoryzacji istniejącego systemu. Nie zawsze można przewidzieć tego rodzaju rzeczy dla małych zadań. Jednak w trakcie całego projektu te dodatkowe 6 dni mogą zostać zmyte przez inne zadania trwające o 6 dni krócej.

Byłem wyłącznym programistą w kilku małych projektach i mam doświadczenie w pracy z dużym zespołem. Zauważyłem, że techniki stosowane w dużej firmie niekoniecznie działają w małym zespole. W pewnym momencie robiłem więcej planowania i dokumentacji niż pisałem kod. Sugeruję, abyś najpierw spróbował znaleźć dobry sposób pracy, wypróbowując różne techniki (inne odpowiedzi dają świetny wgląd) i narzędzia, będzie to kosztowało trochę czasu i wysiłku, ale później skorzystasz z tego. Niektóre narzędzia / techniki, które uznałem za przydatne, to:

-Pivotal Tracker - Świetny program do śledzenia historii i zachęca do rozbijania zadań, błyskawicznie wkracza do historii i automatycznie dedukuje prędkość. https://www.pivotaltracker.com/ .

-Dokumenty do dokumentacji, ponieważ wielu użytkowników może jednocześnie edytować i dyskutować.

- W firmie, w której kiedyś pracowałem, mieliśmy spotkanie dla każdej zainicjowanej przez nas historii, w spotkaniu tym musiał uczestniczyć starszy programista, ponieważ byłby lepszy w ocenie, jak długo zajmie to zadanie. Byłby także lepszy w ocenie trudnej części zadania.

Podsumowując, uważam, że kluczem do pracy w małych zespołach jest posiadanie solidnego systemu planowania, który jest szybki i płynny. Również wszelkie trudności z historią można wcześnie zidentyfikować, więc planowanie zadania będzie o tym pamiętać (może to prowadzić do zbudowania czegoś innego).

Mam nadzieję że to pomoże