Chociaż istnieje wiele różnych podejść do zarządzania projektami, poniższe najlepsze praktyki sprawdziły się dla mnie, moich zespołów i klientów w ciągu ostatnich 15 lat w branży IT. Chętnie się nimi podzielę.

Jako kierownik techniczny prawdopodobnie znasz wiele technik zarządzania projektami. Być może już używasz niektórych z nich w swoich projektach, ale posiadanie listy kontrolnej może być przydatne. Nie będę omawiał SCRUM ani Kanban, ponieważ prawdopodobnie dobrze je znasz. Zamiast tego podzielę się kilkoma ważnymi technikami zarządzania projektami, które mogą pomóc w utrzymaniu motywacji i koncentracji zespołu programistów.

Ważne jest, aby pamiętać, że każdy projekt (i zespół) jest inny, a coś , co działa w jednym, niekoniecznie będzie działać w innych. Dlatego nazywam je najlepszymi praktykami, a nie procesem. Zwykle wybieramy to, co sprawdza się w danym zadaniu i budujemy na tym.

Opracowanie szczegółowej mapy drogowej w celu zapewnienia powodzenia projektu

Punktem wyjścia jest uświadomienie całemu zespołowi celów i planów na najbliższą przyszłość, ale także długoterminowego kierunku.

  • Przygotuj i udostępnij mapę drogową, aby każdy członek zespołu wiedział, co i kiedy ma się wydarzyć.
  • Mapa drogowa powinna zawierać szczegółowe informacje na następny kwartał z góry. Wszelkie zadania i daty w dalszej przyszłości mogą mieć niższy priorytet, ale nadal powinny być naszkicowane.

Wykorzystanie JIRA do skutecznego przepływu pracy w projekcie

Jako kierownik projektu, jednym z najważniejszych obowiązków jest upewnienie się, że wszyscy w zespole są na tej samej stronie procesu pracy. Używamy do tego JIRA, z prawie (ale regulowanym) tym samym przepływem w każdym projekcie.

Niezależnie od wybranego sposobu zarządzania projektem, ważne jest, aby upewnić się, że wszyscy wiedzą, co się dzieje i postępują zgodnie z planem. Zazwyczaj wybieramy SCRUM lub Kanban.

Przykładowe statusy przepływu mogą wyglądać następująco:

Przykładowe statusy przepływu dla zarządzania projektami
  • Backlog - lista zidentyfikowanych zadań. Tutaj opis zadań nie musi być szczegółowy - wystarczy informacyjny, aby zrozumieć, co to jest.
  • Gotowe do wdrożenia - zadania wybrane do wdrożenia. Po wybraniu zadania do wdrożenia jego opis musi być bardziej szczegółowy. Tak, aby deweloper mógł je wdrożyć bez lub przy minimalnej interakcji ze strony Właściciela Produktu. Ponadto powinien być wystarczająco szczegółowy, aby QA mogli przeprowadzić testy. Tworzenie list jako "Definicja wykonania" i/lub "Kryteria akceptacji" bardzo tu pomaga.
  • QA Rejected - zgłoszenia, które nie przeszły testów QA. Zostały one zwrócone z powrotem w przepływie i mogą zostać podjęte przez programistów w celu poprawienia.
  • Blocked Dev - zgłoszenia, które są blokowane przez inne zgłoszenia. Pokazuje to blokady zamiast utrzymywania wszystkich na "W toku" - w tym przypadku PM może wyraźnie zobaczyć, że ktoś jest zablokowany i zmienić priorytety.
  • W toku - bilety do wdrożenia.
  • Zaimplementowane - zgłoszenia zaimplementowane przez programistę, pull request jest gotowy do przeglądu kodu.
  • Code Review - zgłoszenie przenosi się tutaj, gdy ktoś weźmie je do sprawdzenia (również w celu sprawdzenia, ile czasu zajmuje sprawdzenie).
  • QA - zgłoszenia, które pomyślnie przeszły weryfikację kodu - mogą zostać przejęte przez QA do testów.
  • Zablokowane QA - QA umieszczają zgłoszenia, które nie mogą być testowane w danym momencie.
  • Zamknięte - zgłoszenia, które przeszły wszystkie testy i są gotowe do następnego wdrożenia.

Każdy członek zespołu musi znać ten przepływ i mieć świadomość, za który status jest odpowiedzialny.

Zautomatyzuj procesy, aby zaoszczędzić czas na projekcie

Wszystkie powtarzalne zadania powinny być zautomatyzowane tak szybko, jak to możliwe. Może to spowolnić rozpoczęcie projektu, ale szybko się opłaci (zwłaszcza przy większym zespole). Zautomatyzuj każde pole.

  • Infrastruktura
  • Kompilacje, wydania i wdrożenia (Ciągła integracja i wdrażanie)
    np. Po Pull Request narzędzie CI/CD uruchamia zadanie, które weryfikuje jego kompletność, uruchamia testy automatyczne, sprawdza statyczne walidacje kodu. Jeśli wszystko pójdzie dobrze, zmiana jest oznaczana jako gotowa do Code Review, Testy.
  • Kopie zapasowe/odtwarzanie
  • Zadania porządkowe
  • Tworzenie nowych baz danych, użytkowników, przykładowych danych itp.

Aby zaoszczędzić czas, należy automatyzować na serwerach dedykowanych/zdalnych. Jeśli masz automatyczne procesy budowania, ale tylko na swojej lokalnej maszynie, marnujesz czas. Dlaczego? Złożone kompilacje projektów mogą trwać 20-30 minut i zajmować większość procesora. W tym czasie deweloper nie jest w stanie pracować wydajnie, więc jest to czas stracony.

Właściwe zdefiniowanie środowiska i zarządzanie nim pomoże w realizacji projektu

Zdefiniowanie środowisk, ich celu i przepływu między nimi. Ważne jest, aby skonfigurować różne środowiska dla różnych etapów procesu tworzenia oprogramowania. Zazwyczaj jest to wystarczające:

  • DEV
  • TEST
  • PRE-PROD
  • PROD

Pomoże to zapewnić, że oprogramowanie będzie działać poprawnie po uruchomieniu. Ważne jest również, aby wszystkie środowiska były jak najbardziej podobne do środowiska produkcyjnego. Minimalizuje to potencjalne problemy napotkane podczas uruchamiania.

Utrzymuj wszystkie środowiska stabilne i gotowe do użycia przez cały czas.

Podejście oparte na architekturze

Wybierz architekturę dla projektu, a nie odwrotnie. Znajdź sterowniki architektoniczne dla danego projektu, a następnie wybierz odpowiednie narzędzia i frameworki. Nie idź w kierunku rozwoju opartego na modnych słowach. Nie ma jednej architektury, która pasowałaby do wszystkich projektów.

  • Podziel projekt na rozsądnej wielkości i niezależne moduły (nie za mało, nie za dużo). Zyskasz na tym na każdym etapie (np. lokalna kompilacja pojedynczego modułu zajmie mniej czasu).
  • Błędy w architekturze spowolnią pracę w całym projekcie i spowodują wiele problemów. Przy złej architekturze, nawet małe rzeczy mogą być bolesne do zmiany.
  • Pomyśl o możliwościach budowania i uruchamiania. Jeśli zbudowanie i uruchomienie projektu do testów zajmuje 5 minut, to każdy programista traci co najmniej 1 godzinę dziennie czekając na kompilacje.
  • Pomyśl o doświadczeniu użytkownika. Pierwsze wrażenie powinno być najważniejsze, użytkownik nie powinien czekać na ekran ładowania. Pomyśl o wydajności, ale przedwczesna optymalizacja jest źródłem wszelkiego zła.

Dlaczego definiowanie standardów kodowania jest ważne dla zarządzania projektami?

  • Zdefiniowanie standardów kodowania i formatów dla czystszego, bardziej spójnego i czytelnego kodu. Zdefiniuj go tak, aby był łatwo dostępny dla całego zespołu (np. Confluence/Wiki/repozytorium projektu).
  • Zalecam posiadanie przykładów użycia, np. linków do dobrze napisanych modułów.
  • Jeśli Twój starszy kod nie pasuje do zdefiniowanych standardów - napraw go przy pierwszej okazji (np. podczas zmian w tym module).
  • Wszystkie nowe funkcjonalności powinny być zgodne ze zdefiniowanymi standardami - do sprawdzenia podczas Code Reviews.
  • Skróci to proces dodawania nowych członków zespołu i wdrażania ich do pracy. Łatwiejsza będzie również konserwacja i rozszerzanie zakresu prac.

Przejrzyj kod

Robione przez wszystkich i dla wszystkich - to świetna okazja do nauki i utrzymania standardów.

  • Młodszy recenzent może wyciągnąć wnioski z komentarza starszego kolegi.
  • Młodszy recenzent może uczyć się poprzez studiowanie kodu starszego kolegi.

Upewnij się, że przetestowałeś oprogramowanie

Testy jednostkowe są obowiązkowe dla długotrwałych projektów. Bez nich wszelkie przyszłe zmiany zajmą znacznie więcej czasu i mogą być podatne na błędy. Programiści potrzebują tych informacji, aby mieć pewność, że nie wpłynęły one na inne aspekty projektu. Testy jednostkowe są również bardzo dobrą dokumentacją, wyjaśniającą, co powinno zostać osiągnięte w danej logice.

  • Zautomatyzowane testy integracyjne/E2E - przynajmniej dla głównych przepływów (przepływów, które generują biznes).
  • Testy ręczne dla miejsc, w których automatyzacja jest niemożliwa lub ekonomicznie nieuzasadniona.
  • Wszystkie testy powinny być spójne i napisane w określonych standardach.

Znaczenie audytu i przejścia na nową architekturę

Ponadto, gdy przejmujemy istniejące projekty, na początku musimy wykonać dodatkową pracę:

  • Audyt istniejącego stanu i architektury projektu.
  • Określenie najlepszej architektury dla danego projektu i osi czasu, kiedy chcemy tam być.
  • Wprowadzenie minimalnych obowiązkowych zmian architektonicznych podczas przechodzenia na nową architekturę. Zwykle łączy to każdą część projektu, więc rozwój nowych funkcji jest zamrożony na jakiś czas, aby je wprowadzić. Dlatego spróbuj podzielić to na minimalne kroki.
  • Wprowadzanie nowych zmian w normalnym procesie rozwoju:
    • Aktualizacja do nowej architektury podczas dodawania zmian w danych modułach
    • Podział zespołu: część zajmuje się migracją systemu do nowej architektury, druga część pracuje nad nowymi funkcjami i poprawkami, aby utrzymać działalność.

W rezultacie migrujemy do pożądanej architektury w dłuższym procesie, ale bez zamrażania projektu.

Znaczenie zarządzania projektami w motywacji zespołu

Z mojego doświadczenia wynika, że utrzymanie motywacji zespołu programistów jest kluczowym czynnikiem sukcesu każdego projektu. Dzięki wieloletniemu doświadczeniu i praktyce odkryłem, że wdrożenie tych technik zarządzania projektami konsekwentnie prowadzi do wysokiego poziomu zaangażowania i produktywności zespołu programistów. Mam nadzieję, że okażą się one przydatne również w przypadku twoich projektów. Należy jednak pamiętać, że każdy projekt i zespół jest wyjątkowy i to, co sprawdza się w jednym przypadku, może nie działać w innym. Musisz zidentyfikować to, co działa dla Ciebie i zachować to. Dostosuj i popraw to, co nie działa. Bądź elastyczny. Bądź zwinny.

4/5 - (20 głosów)