Jak zgłosić postęp mojego projektu (Agile) mojemu pracodawcy (który nie jest programistą)?

Mam problem z raportowaniem postępów mojemu pracodawcy. Jestem programistą zatrudnionym w niepełnym wymiarze godzin, zajmującym się projektami oprogramowania dla wydziału (nietechnicznego) mojej szkoły.

Osoba kontaktowa:
1. Personel, który faktycznie korzysta z oprogramowania i zgłasza prośby o funkcje,
2. Mój szef (nie-programista), a ona nie jest użytkownikiem oprogramowania.

Charakter projektu:
jest to gotowe oprogramowanie, które zostało zakupione od strony trzeciej. Muszę zmodyfikować lub dodać funkcję / funkcję do tego oprogramowania, aby zaspokoić potrzeby działu. Jest to oprogramowanie, z którego należy korzystać przez cały semestr. Nie wszystkie funkcje muszą być używane na początku.

Dlatego używamy modelu zwinnego: gdy personel potrzebuje określonej funkcji, zgłasza żądanie, a ja wprowadzam zmiany. Pod koniec semestru przypuszczam, że wszystkie wymagane funkcje zostaną podniesione i wdrożone.

Problem:
Za każdym razem, gdy mój szef pytał mnie o postęp, nie mogę odpowiedzieć, ponieważ nie wiem, jak odpowiedzieć. Nie mam pełnej listy wszystkich wymaganych funkcji. Mimo że ukończyłem funkcje, które zostały podniesione w zeszłym tygodniu, nadal nie mogę powiedzieć mojemu szefowi, że „ukończyłem”, ponieważ pojawiają się też nowe funkcje i nie wiem, ile. Nie mogę powiedzieć „mamy ile% ukończeń” ani „zamierzamy to zrobić do xxx”. Kiedyś z 3 próśb, udaje mi się ukończyć 2, powiedziałbym mojemu szefowi „Skończyłem 2, ale jedna funkcja nie jest jeszcze ukończona”. Po długim czasie wydaje mi się, że „zawsze mam coś nieukończonego, po tak długim czasie”.

Brak możliwości zgłoszenia postępu sprawia, że ​​wyglądam naprawdę źle. Nie chodzi o to, ile zrobiłem, ale o to, jak dać ludziom znać. Gdybym był menadżerem, a mój personel przez wiele miesięcy nie zgłaszałby mi postępu, czuję, że ten facet też nie jest w stanie.

Czy macie jakiś pomysł na zgłoszenie lub odpowiedź na pytanie tak proste jak „jaki jest status / postęp modyfikacji oprogramowania”?

AKTUALIZACJA Mój szef nie bierze bezpośredniego udziału w pracach programistycznych, więc nie ma pojęcia, co robię ani jak działa program. Nie spotykamy się regularnie, ponieważ jest zajęta i uważam, że to strata czasu, ponieważ nie jest głównym użytkownikiem, nie zna szczegółów programu.

Spotykam się regularnie z personelem, który używa oprogramowania i wie o nim lepiej.

Trudno mi wytłumaczyć mojemu szefowi postępy.

Jest to powszechny problem, gdy jesteś programistą, który działa niezależnie i zgłaszasz się komuś, kto nie jest techniczny.

Tacy szefowie w większości chcą być w stanie dowiedzieć się kilku rzeczy:

• Jak zadowoleni są użytkownicy?
• Czy użytkownicy chcą robić rzeczy?
• Czy to, co robisz, jest warte pieniędzy, które otrzymujesz?

Zwinne spalanie lub coś w tym stylu byłoby okropnym pomysłem! Jak powiedziałeś, twój szef jest naprawdę zajęty, więc nie mieliby czasu się o nim dowiedzieć i prawdopodobnie i tak go nie interesuje.

Gdybym był tobą, raz w tygodniu wysyłałbym im e-mailem raport zawierający:

• „Podsumowanie” na początku: „Ukończyłem 3 funkcje w tym tygodniu i otrzymałem 2 nowe funkcje. Na początku tego tygodnia było 11 niedokończonych wniosków o funkcje, a na końcu było ich 10”.
• Lista statusu funkcji, z krótkimi zdaniami, w trzech grupach:
  1. Funkcje, które wykonałeś w ciągu tygodnia
  2. Żądania funkcji, które wpłynęły w ciągu tygodnia
  3. Inne funkcje w „zaległości”
• Krótka dyskusja na temat wszystkiego, co było skomplikowane lub niezwykłe, najlepiej przy użyciu nietechnicznego języka.

Gdybym był twoim szefem i nie otrzymywałem żadnych raportów, byłbym bardzo szczęśliwy, otrzymując to co tydzień. A gdybym chciał czegoś innego, poprosiłbym cię o to.

Wygląda na to, że nie masz możliwości dowiedzieć się, czy jesteś ukończony, ani jak daleko jesteś do ukończenia. W porządku.

Zachowaj listę żądanych funkcji, które zostały wykonane, są w toku lub nie zostały uruchomione. Śledź je jako wykres tygodniowy sumy w każdej kategorii. To da ci zestaw punktów, które możesz ekstrapolować do daty zakończenia. To znaczy (patrząc tylko na funkcje „zakończone” się liczy)

• Tydzień 1–2 zakończony
• Tydzień 2 - 5 ukończony (2 od tygodnia 1, 3 od tygodnia 2)
• Tydzień 3-8
• Tydzień 4-12

Jeśli masz 16 tygodni, możesz ukończyć około 48 funkcji (nie przejmuj się zbytnio niektórymi funkcjami, które są większe / mniejsze od innych, po 4-5 tygodniach ogólnie się uśrednia). Następnie możesz zgłosić wszystkim, że możesz obsłużyć tylko X funkcji. Pod koniec projektu absolutnie najważniejsze jest to, że dostarczyłeś potrzebne funkcje i nie zabiłeś się w ciągu ostatnich dwóch tygodni. Zgłaszając w ten sposób, możesz wyciągnąć najważniejsze wymagania tak szybko, jak to możliwe.

Inną rzeczą, którą chcesz zgłosić, jest to, ile masz pojemności. „Otrzymałem tylko 2 prośby o funkcje, ale mogłem obsłużyć 3 ... czy możesz poprosić personel o wcześniejsze zwiększenie liczby funkcji?”

nie jestem pewien, czy w pełni odpowiedziałem na twoje pytanie, więc możesz zadawać dalsze pytania ...

Trzy słowa ... spalić wykres.

Twój pracodawca, bez względu na to, czy jest uzależniony od zwinności, czy po prostu osobą odpowiedzialną za programistów, doceni schemat wypalenia .

Wszyscy uwielbiają rozumieć, kiedy projekt zostanie ukończony, a wykorzystanie wczorajszej pogody zapewni najdokładniejszy i najbardziej realistyczny sposób przewidywania zakończenia projektu.

Zakładam, że robisz jeden na jednego przynajmniej raz w tygodniu i mogę w tym momencie omawiać swoje priorytety ze swoim menedżerem - co jest ważne z jego punktu widzenia (taki i taki potrzebuje jego funkcji wcześniej inna osoba itp.) - i dlatego może raportować, ile rzeczy, które sprawiają, że Twój menedżer wygląda dobrze, zostało zrobionych w porównaniu z ilością rzeczy, które masz w sumie do zrobienia.

Twój menedżer prawdopodobnie nie szuka podziału z minuty na minutę; s / on tylko próbuje sprawdzić, czy praca jest wykonywana, czy ważne rzeczy zyskują większą uwagę i czy nie toniesz pod obciążeniem lub bezczynnie, ponieważ jesteś zablokowany przed kontynuowaniem.

Zauważ, że w prawdziwym zwinnym procesie rzeczywiście masz rzeczy przychodzące przez cały czas, ale ty i twój manager uzgadniacie, co jest najważniejsze / najbardziej potrzebne i ile z tego zmieści się w bieżącym okresie pracy (czy to tydzień, dwa tygodnie, miesiąc ...), w razie potrzeby dzieląc zadania na mniejsze części, aby pasowały do ​​okresu.

Poważny przegląd bazy danych, który może potrwać kilka tygodni, może być zepsuty w następujący sposób: tworzenie kopii zapasowych, sprawdzanie, czy kopie zapasowe są dobre, projektowanie nowego układu bazy danych, pisanie oprogramowania do konwersji i testowanie go, konfigurowanie wycofywania i testowanie go, próba konwersji maszyna przemieszczająca, próbująca wycofać to samo miejsce, a następnie w końcu dokonująca konwersji. Każdy z nich można prawdopodobnie podzielić na 1-tygodniowe (lub krótsze) fragmenty. Jeśli niektóre kroki mogą potrwać 2 lub 3 tygodnie, możesz zgłosić, jak daleko byłeś na następnym spotkaniu (celowanie w 50% na 2 tygodnie, 33% na 3 tygodnie itp.).

Idealnie byłoby, gdybyś miał wykres, który zawiera rzeczy, które musisz zrobić, w porównaniu z rzeczami, które będziesz robić teraz, i sprawdzałbyś elementy „rób teraz” w miarę postępów. To pozwala twojemu menedżerowi po prostu przejść obok i zobaczyć, ile rzeczy jest zaznaczonych w porównaniu do rzeczy, które są na liście do zrobienia.

Raz w tygodniu (zakładam, że długość iteracji / sprintu w twoim zwinnym procesie wynosi jeden tydzień dla przykładu), wykonaj następujące czynności :

• przedstawić pracownikom nową pracę, aby upewnić się, że ich prośby zostały spełnione
• zgłoś szefowi liczbę wniosków zrealizowanych w ciągu tygodnia i zidentyfikuj / opisz te wnioski. Zrób krótkie podsumowanie
• zgłoś szefowi liczbę nowych żądań dodanych do twojego zaległości / kolejki w ciągu tygodnia oraz całkowitą liczbę żądań
• powiedz szefowi, jakie (które prośby) planujesz pracować w przyszłym tygodniu; innymi słowy, obecne priorytety. Oto okazja, by je potwierdzić lub zmienić, a was oboje jasno o tym powiedzieć
• powiedz szefowi, jaki jest plan na 1-2 tygodnie po tym.

Wyczuwam, że twój szef nie jest wystarczająco techniczny, aby dbać o zwinne terminy, takie jak prędkość , właściciel produktu lub wykres wypalenia . Powyższy szablon unika takiego żargonu, używa prostszych słów, takich jak „zaległości” i „kolejka” w ich zdrowym znaczeniu, a zatem powinien ułatwić komunikację z szefem.

Użyłbym swojej prędkości jako podstawowej statystyki dla niego / niej. To pokaże, ile zadań / funkcji „zgodziłem się” porozmawiać w danym tygodniu (lub innym okresie) i ile wykonałem. Na tej podstawie wspomnę o niektórych ważniejszych implementacjach i dlaczego zmieniło się to w porównaniu do poprzednich wersji. Możesz również wspomnieć o wszelkich przeszkodach, które napotkałeś i przekroczyłeś oraz o tym, jak wpłynęło to na twoją prędkość.

Inne statystyki, o których szef może chcieć wiedzieć, mogą obejmować liczbę podniesionych nowych raportów o błędach, zamkniętych raportów o błędach i przesłanych nowych żądań funkcji. Będziesz musiał albo zapytać bezpośrednio, albo skorzystać z najlepszej oceny, aby ustalić, które z nich są najważniejsze. Na koniec przedstawię podstawowy zarys postępu i zapytam, czy jest coś jeszcze, o czym on lub ona chcieliby wiedzieć. Szef chce tylko wiedzieć, że robisz postępy i czy jest coś, czego potrzebujesz, aby jak najlepiej pracować.

Zaproponuj cotygodniowe zgłoszenie: wymień wymagane funkcje. Zapisz zmienione funkcje. Zgłoś, co zrobiłeś.

Staram się podsumować w sposób zrozumiały dla menedżerów.

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

Tylko dlatego, że twój menedżer nie jest programistą, nie sądzę, że oznacza to, że oczekujesz dokładnej daty zakończenia. Przedstaw swoje liczby. Po tym, jak menedżer zobaczy liczbę otrzymanych i zakończonych wniosków, przejście do góry spowoduje, że zobaczy postęp. Jeśli liczby żądań wymykają się spod kontroli, menedżer może pomóc i pomóc, ustalając priorytety przed przeładowaniem. A jeśli zabraknie ci pracy, mogą znaleźć dla ciebie mały projekt poboczny. W końcu zawsze miło jest zrobić sobie przerwę w projekcie, kiedy wydaje się, że nie ma końca, a dni pracy mija szybciej i są bardziej satysfakcjonujące, gdy jesteś zajęty.