Niedawno dołączyłem do projektu rozwojowego i nagle dostałem pracę jako główny programista. Moim głównym obowiązkiem jest rozbicie części programistycznej projektu na zadania, przekazanie tych zadań innym programistom, a następnie upewnienie się, że elementy będą ze sobą współpracować.

Problem jednak polega na tym, że nie mam pojęcia, jak to zrobić. Spędziłem weekend z ołówkiem i papierem, próbując to rozgryźć, ale ciągle wymyślam listę zadań do wykonania sekwencyjnie zamiast równolegle. Pomyślałem, że może podzielę to na funkcje, ale wtedy skończysz z zadaniami, które wymagają edycji tych samych plików, co może wymagać całkowitego przepisania całego zadania ze względu na to, jak wcześnie jesteśmy w fazie rozwoju. Mógłbym poprosić niektórych programistów, aby program był nieco bardziej kompletny i łatwiejszy do tworzenia zadań, ale wtedy kazałbym ludziom siedzieć na rękach, kto wie, ile tygodni.

Rozmawiałem z moim szefem o moich kwalifikacjach, aby to zrobić i nie miałem wyboru w tej sprawie. Nie mam pojęcia, co robię, więc wszelkie wskazówki i wskazówki we właściwym kierunku byłyby bardzo mile widziane.

Prawidłowa odpowiedź na twoje pytanie wypełnia kilka książek . Wymyślę listę wypunktowanych słów, które przychodzą mi na myśl, Google i książki zrobią za ciebie resztę.

1. Podstawy

   • Nie idź sam . Spróbuj w jak największym stopniu zaangażować członków swojej drużyny.
   • Lekka podróż .
   • Demokracja, ale nie za dużo. Czasami nie chodzi o to, co zadowoli największą liczbę osób, ale o to, co boli najmniejszą liczbę osób.
   • Zachowaj to, co (należy zrobić) i jak (to jest zrobione) oddzielnie .
   • Dowiedz się o Scrum („co”), XP (programowanie ekstremalne, „jak”), Kanban („ile”), Lean („co nie”) i DevOps („z kim”).
   • Lean dotyczy także przepływu : Dla ogólnej wydajności wydajność przepływu jest zwykle ważniejsza niż wydajność indywidualna.
   • Dowiedz się więcej o kodzie oprogramowania , czystym kodzie i programowaniu pragmatycznym .
   • Dobra architektura polega na maksymalizacji liczby niepodejmowanych decyzji .
   • Scrum / XP / Lean / Agile polega na maksymalizacji ilości niewykonanej pracy : YAGNI .
   • Podstawowa Wartość oprogramowania jest to, że można łatwo zmienić go. To, że robi to, co powinien, jest ważne, ale to tylko jego wartość wtórna.
   • Preferuj podejście iteracyjne i przyrostowe , używaj ram czasowych na prawie wszystko, szczególnie na spotkania, uczyń Prawo Parkinsona swoim przyjacielem, ponieważ ma zastosowanie Prawo Hofstadtera .
   • Zrównoważyć strukturę zespołu ze zrozumieniem prawa Conwaya i etapów rozwoju zespołu Tuckmana .
   • Programowanie to czwórka, nauka , inżynieria , sztuka i rzemiosło jednocześnie, a te muszą być w równowadze.
   • To, że Scrum / XP / XYZ jest dobre dla kogoś (w tym dla mnie), niekoniecznie oznacza, że ​​jest dobre dla ciebie / pasuje do twojego środowiska. Nie ślepo podążaj za szumem, najpierw go zrozum.
   • Sprawdź i dostosuj! (Scrum Mantra)
   • Unikaj powielania - raz i tylko raz! (XP Mantra) aka DRY - Don't Repeat Yourself aka SPOT - Single Point of Truth

2. Proces podziału pracy w „jakim świecie”

   • Zbieraj wymagania jako historie użytkowników / historie zadań do rejestru produktów .
   • Użytkownik (z historii użytkownika) podobny do aktora (w UML) podobny do Persona podobny do roli .
   • Udoskonalaj historie użytkowników, aż spełnią definicję gotowości zespołu w oparciu o INVEST (niezależna, negocjowalna, wartościowa, możliwa do oszacowania, mała, testowalna). (Spotkanie Scrumowe: Udoskonalanie zaległości )
   • Posortuj zaległości produktu według wartości biznesowej .
   • Nie rozpoczynaj pracy nad historią, dopóki nie będzie gotowa (gotowa zgodnie z definicją gotowej).
   • Skorzystaj z Planning Poker, aby oszacować wysiłek opowieści w punktach fabularnych . Użyj porównania triangulacji, aby zapewnić spójność szacunków.
   • Wczorajsza pogoda jest najlepsza, mam nadzieję, że najgorsza.
   • Podziel historie, jeśli są za duże.
   • Ulepsz kulturę dostaw dzięki Definicja Gotowości .
   • Nie akceptuj wdrożenie Story użytkownika przed jego Sporządzono Sporządzono (wykonanej zgodnie z definicją zrobione).
   • Wiele zespołów korzystających z tej samej bazy kodu powinno uzgodnić i udostępnić tę samą Definicję Wykonania (zwłaszcza Standardy Kodowania ).
   • Sprawdź swoje postępy dzięki wykresom Burndown .
   • Regularnie sprawdzaj z Interesariuszami, czy to, co zapewnia zespół, jest naprawdę potrzebne. (Spotkanie Scrumowe: Przegląd sprintu )

3. Podział historii

   • Lista i opis użytkowników / minimotywów / aktorów / ról (właściciel produktu)
   • Epicka -> Historie (historia użytkownika lub historia pracy) (właściciel produktu)
   • Historia -> Kryteria akceptacji (właściciel produktu)
   • Story -> Subtasks (Dev Team)
   • Kryteria akceptacji -> Testy akceptacji (Spec: Product Owner, Impl: Dev Team)
   • Zacznij od chodzącego szkieletu, który jest minimalistycznym End-to- (Half-End) .
   • Utwórz MVP - minimalny żywotny produkt .
   • Rozwiń MVP za pomocą SMURFS - szczególnie zbywalnych, użytecznych i zwalnianych zestawów funkcji .

4. Realizacja „Jak świat”

   • Używaj kart OOA / D , UML i CRC , ale unikaj dużego projektu z góry .
   • Wdrażaj obiektowe , ustrukturyzowane i funkcjonalne jednocześnie w jak największym stopniu, niezależnie od języka programowania.
   • Użyj kontroli wersji (najlepiej rozproszonej ).
   • Rozpocznij od testów akceptacyjnych .
   • Zastosuj TDD , pozwalając, aby Trzy Prawa TDD poprowadziły Cię przez Cykl Refaktora Czerwono-Zielonego , z Regułą Pojedynczego Potwierdzenia , 4 A , GWT (Podane Kiedy Następnie) z BDD .
   • „ Testy jednostkowe to testy, które działają szybko ”. - Michael Feathers
   • Zastosuj SOLID i zasady pakietu, aby zarządzać połączeniem i spójnością . Przykład: S w SOLID to SRP = Zasada pojedynczej odpowiedzialności, znacznie zmniejsza liczbę edycji. łączyć konflikty w zespołach.
   • Poznaj prawo Demeter / Tell, Don't Ask .
   • Użyj ciągłej integracji , jeśli to możliwe, nawet ciągłej dostawy (DevOps).
   • Użyj zbiorowego prawa własności do kodu na podstawie uzgodnionego wspólnego standardu kodowania (który powinien być częścią Definicji Gotowości ).
   • Zastosuj ciągłe doskonalenie projektu (fka Continuous Refactoring).
   • Kod źródłowy to projekt . Wcześniejsze myślenie jest niezbędne i nikt nie sprzeciwi się kilku dobrym, wyjaśniającym diagramom UML.
   • XP nie oznacza, że ​​dzień nie jest dniem architektury, oznacza to, że każdy dzień jest dniem architektury. Koncentruje się na architekturze, a nie na rozmyciu, a koncentruje się na kodzie.
   • Utrzymuj niskie zadłużenie techniczne , unikaj czterech zapachów zapachowych Kruchość , sztywność , bezruch i lepkość .
   • Architektura dotyczy logiki biznesowej, a nie mechanizmów trwałości i dostarczania.
   • Architektura to sport zespołowy ( w architekturze nie ma „ja” ).
   • Wzory projektowe , refaktoryzacja i przesłanka pierwszeństwa transformacji .
   • Kod projektu to ATP-Trinity z priorytetami: 1. Kod automatyzacji , 2. Kod testowy , 3. Kod produkcyjny .
   • Regularnie sprawdzaj z kolegami z zespołu, czy sposób, w jaki zespół dostarcza, można poprawić. (Spotkanie Scrumowe: Retrospektywa sprintu )
   • Testy powinny być PIERWSZE - szybkie, niezależne, powtarzalne, samooceny i terminowe.

Powyższa lista jest z pewnością niekompletna, a niektóre części mogą być nawet sporne!

Jeśli to wszystko Cię przeraża - nie martw się, bo powinno cię przestraszyć! Realizacja projektów tworzenia oprogramowania w zespołach nie jest łatwym zadaniem i rzadko ludzie są odpowiednio przeszkoleni i wykształceni w tej dziedzinie. Jeśli cię to przeraża, twoja intuicja działa poprawnie, posłuchaj jej. Chcesz być przygotowany Porozmawiaj z szefem, poświęć trochę czasu i trenuj.

Zobacz też

• Kto pisze techniczne „historie użytkowników” w scrumie

Dalsza lektura (online)

• Portland Pattern Repository autorstwa Warda Cunninghama i in
• Zasady OOD Roberta „Wujka Boba” C. Martina
• Pragmatyczne wskazówki dla programistów

Dalsze czytanie (książki)

• Clean Code autorstwa Roberta C. Martina
• Zwinne tworzenie oprogramowania: zasady, wzorce i praktyki autorstwa Roberta C. Martina
• Pragmatyczny programista - Od czeladnika do mistrza - Andrew Hunt i David Thomas
• Skutecznie współpracuje ze starszym kodem Michaela Feathersa
• Refaktoryzacja - Poprawa projektu istniejącego kodu autorstwa Martina Fowlera
• Refaktoryzacja do wzorów autorstwa Joshua Kerievsky
• The Ten Day MBA Stevena Silbigera (sic!)
• Projekt oparty na domenie Eric Evans
• Historie użytkowników Stosowane przez Mike'a Cohna
• Analiza i projektowanie obiektowe z aplikacjami Gray Booch i in
• Projektuj wzory według Gang of Four
• Test Driven Development autorstwa Kent Beck
• Programowanie ekstremalne przez Kent Beck
• [if Java] Effective Java autorstwa Joshua Bloch

Zyskaj zwinność

Sugerowałbym następujące:

Edycja tych samych plików

Najpierw użyj Git (lub podobnego współbieżnego systemu wersjonowania). Tak długo, jak edytujesz różne części tych samych plików, nie będziesz mieć konfliktów. Jeśli wystąpią konflikty, zostaną one wyraźnie oznaczone jako takie.

Próba zarządzania projektem z wieloma programistami bez Git jest jak próba zrobienia puddingu bez puddingowej miski. Jest to możliwe, ale szybko stanie się dość niechlujny.

Jak zauważono w komentarzach, Git nie jest panaceum, ale w połączeniu z automatycznymi testami z pewnością bardzo pomaga.

Wymień wszystkie funkcje

Po drugie, podziel projekt na widoczne dla użytkownika funkcje. Na przykład „gdy użytkownik się zarejestruje, powinien otrzymać wiadomość e-mail” lub „Użytkownik może dodać element”. Zaangażuj tutaj wszystkich interesariuszy. Zaproś wszystkich do pokoju i niech wszyscy wykrzyczą swoje funkcje.

Powinny to być funkcje widoczne dla użytkownika, możesz później porozmawiać o strategii wdrażania.

Zapisz wszystkie sugestie na kartach indeksowych, nawet te głupie. Szybko zracjonalizuj listę, aby usunąć duplikaty, i ułóż wszystkie karty na dużym stole, a nawet na podłodze.

Dodaj wszystkie potrzebne karty. Powiedz, że Twoja aplikacja wyśle ​​powiadomienia SMS. Być może nie wiesz, jak to zrobić, więc masz pytanie. Napisz „Zbadaj portale SMS” na karcie. Podobnie w przypadku innych wielkich niewiadomych. Będziesz musiał rozpakować je później. Te funkcje prawdopodobnie nie dadzą rady do pierwszego sprintu.

Teraz posortuj swoje karty na grupy, przetasuj je, poczuj ich smak. To jest zakres twojego projektu.

Planowanie pokera

Spróbuj planowania pokera. Nadal ze wszystkimi razem, daj wszystkim kartom programistów, które mówią „1 punkt”, „2 punkty” itd., Aż do „4 punktów”. Również karta „więcej”. Punkt jest w przybliżeniu równy godzinie.

Przejrzyj listę funkcji jeden po drugim. Podczas czytania funkcji każdy musi zagrać kartę. Jeśli jedna osoba gra 1, a inna gra 4, oznacza to problem z komunikacją. Jedna osoba rozumie tę funkcję jako coś innego niż druga osoba. Porozmawiaj i ustal, co naprawdę oznaczało, i zanotuj to na karcie.

Jeśli zgadzasz się, że funkcja jest „większa”, jest ona zbyt duża. Musisz rozbić tę funkcję. Zrób to w taki sam sposób jak poprzednio.

Zgodnie z umową napisz cyfry na kartach pisakiem w innym kolorze.

Punkty są lepsze niż godziny

Używanie punktów zamiast godzin odbiera macho „patrz, jak szybko mogę kodować”, w co często programiści się angażują. To subtelna różnica, ale przekonałem się, że działa całkiem dobrze.

Teraz skomponuj sprint

Sprint to szybki wybuch w kierunku bramki. Zdecyduj o długości sprintu, być może 5 lub 10 dni. Pomnóż liczbę dni przez liczbę programistów przez liczbę punktów dziennie.

Początkowo zakładaj 6 punktów dziennie na programistę. Jest to liczba osiągalna. Jeśli masz 5 osób, to 5 * 5 * 6 = 150 punktów. W połączeniu ze wszystkimi programistami i zarządem wybierz funkcje z listy do 150 punktów. To twój sprint.

Nigdy nie daj się skusić, aby wcisnąć więcej, niż zmieści się. Nadmiernie obiecujące boli wszystkich na dłuższą metę, w tym ciebie.

Musisz tutaj wziąć pod uwagę zależności. Na przykład konfiguracja środowiska oczywiście musi zostać uwzględniona w pierwszym sprincie. W rzeczywistości jest to stosunkowo łatwe, gdy wszyscy są obecni. W pokoju jest 6 mózgów, wszyscy mówią „to zależy od tego” itp. Następnie możesz potasować karty, aby pokazać zależności.

Po zakończeniu sprintu nie można do niego nic dodać, jest on zablokowany na 5 dni. Pełzanie funkcji będzie stresować drużynę, morale obrażeń i spowolni wszystkich. Ostatecznie pełzanie opóźni projekt. Jako lider zespołu musisz chronić swój zespół przed pełzaniem funkcji. Jeśli pojawi się nowe żądanie funkcji, należy je dodać do następnego sprintu. JEŚLI następny sprint jest już pełny, należy coś jeszcze wyjąć.

Nigdy nie ulegaj pokusie wyciskania dodatków. Nadmiernie obiecujące daje około jednego dnia zadowolonego klienta, po którym następuje 4 dni stresu w zespole, a ostatecznie, najprawdopodobniej, kilku niezadowolonych klientów, gdy zespół nie może dostarczyć na czas.

Teraz idź do tego.

Rozdaj karty, zapytaj, kto chce co robić. Masz pełną widoczność tego, co się robi, i możesz policzyć zaznaczone punkty do zera. Przygotuj się na starcie każdego dnia, aby wszyscy wiedzieli, kto nad czym pracuje i co zostało zrobione.

5 lub 6 dobrze zmotywowanych programistów pracujących razem jako jednostka nad jasno określonymi celami, które można zrealizować, może osiągnąć całkiem sporą ilość rzeczy podczas 5-dniowego sprintu.

Zachowaj widoczność

Upewnij się, że wszyscy mogą zobaczyć status projektu. Bluetack wszystkie karty do ściany. Po lewej stronie są karty, które nie zostały jeszcze opracowane. Po prawej stronie są gotowe karty.

Gdy programista pracuje nad kartą, zdejmuje ją ze ściany i kładzie na biurku. Utrzymuje to widoczność i powstrzymuje ludzi od nadmiernego stąpania po sobie.

Istnieją technologiczne alternatywy dla kart indeksowych, ale nic nie przebije ogromnego papierowego wyświetlacza statusu projektu na ścianie.

Jeśli to możliwe, przechowuj wszystkich w tym samym pokoju na czas trwania projektu. Poproś interesariuszy o jak najwięcej, najlepiej codziennie.

Spalić

Możesz wykreślić swoje punkty idące w kierunku zera na wykresie wypalenia. Jeśli linia najlepszego dopasowania przekroczy zero, zanim osiągniesz limit czasu, prawdopodobnie jesteś na dobrej drodze. Jeśli nie, być może będziesz musiał powiadomić swojego klienta teraz, zanim zbliżysz się do terminu.

Jeśli zawiedziesz, zawiodłeś wcześnie.

Możesz zrobić wypalenie za pomocą oprogramowania, ale ja wolę tylko duży kawałek papieru na ścianie. Rysuj i pisz po całym nim.

Zautomatyzowane testowanie

Kiedy wielu programistów pracuje nad tymi samymi rzeczami w tym samym czasie, prawdopodobnie od czasu do czasu łamią sobie nawzajem swój kod. Pomaga w tym komunikacja i widoczność, ale prawdopodobnie będziesz chciał wprowadzić technologię, która pomoże znaleźć problemy.

Testowanie jednostkowe to proces pisania testów dla każdej części bazy kodu (najlepiej każdej metody). Testy jednostkowe powinny być przeprowadzane często, z każdym zapisem, jeśli to możliwe. Istnieje wiele narzędzi, które mogą w tym pomóc, na przykład Karma lub Rspec.

Kompleksowe testy obejmują testowanie całego projektu, traktując elementy wewnętrzne jako czarną skrzynkę. Oprzyj te testy na wysokich wymaganiach biznesowych, na przykład: „Użytkownik może się zarejestrować” lub „Użytkownik może zobaczyć listę elementów”. Kątomierz jest dobrym przykładem kompleksowego środowiska testowego opartego na sieci.

Na temat testowania napisano całe książki, ale przeprowadzenie przynajmniej testów akceptacyjnych może pomóc upewnić się, że nic nie zostanie zepsute podczas pracy nad projektem.

Unikanie długów technicznych i załatwianie spraw

Dług techniczny to koncepcja opisująca rzeczy, które będą musiały zostać później uporządkowane. Powszechnym źródłem długu są cechy, które zostały oznaczone jako wykonane, ale nigdy nie zostały „wykonane”. Wykonana funkcja jest sprawdzana w Git, została zatwierdzona przez interesariusza i ma test.

Nie wyłączaj swoich funkcji, dopóki nie zostaną zakończone. Nigdy nie masuj wykresu. Ponownie boli to wszystkich na dłuższą metę, w tym ciebie.

Jest to jeden z powodów, dla których początkowo podajemy tylko 6 punktów na programistę dziennie. Wykonanie wymaga dodatkowej pracy, ale czuje się świetnie i daje impuls zespołowi.

Edycja tych samych plików sama w sobie nie stanowi problemu. Problem stanowi jedynie edycja tej samej funkcji w celu wykonania dwóch różnych czynności.

Zasadniczo chciałbym podzielić projekt na osobne „funkcje”. Jedna może być związana z obsługą protokołu sieciowego, inna z plikiem konfiguracyjnym, a jeszcze inna z obsługą DB. Funkcje to wielkie rzeczy.

Następnie chcesz podzielić te funkcje na zadania (historie). Powinny to być proste rzeczy, takie jak „gdy użytkownik kliknie przycisk, program załaduje plik”, „gdy program się uruchomi, załaduje plik konfiguracyjny” itp.

Niektóre zadania będą musiały być wykonywane sekwencyjnie („program przeanalizuje wszystkie pola w pliku konfiguracyjnym” będzie musiał nadejść po „program załaduje plik konfiguracyjny”). Inni nie będą (możesz jednocześnie pracować z DB i siecią).

Ale najprawdopodobniej zrobisz to źle i tam właśnie pojawia się doświadczenie. Nie uda ci się ani trochę (lub dużo), błędnie oszacujesz czas, a Twój projekt zajmie trochę więcej czasu, niż powinien. Następnym razem będziesz lepszy.

Sugerowałbym również przeczytanie „Extreme Programming” autorstwa Kenta Becka. Świetna książka, która pomogła mi, gdy miałem zostać kierownikiem projektu.

Sprowadza się to do tego, że musisz rozbić aplikację na moduły funkcjonalne, a następnie wprowadzić umowy (interfejsy i umowy danych) między różnymi modułami. Każdy moduł można następnie przekazać innemu deweloperowi. Po ponownym złożeniu wszystkiego umowy zapewnią, że moduły te poprawnie się ze sobą komunikują.

Upewnij się, że wymuszasz TDD na programistach, aby zagwarantować, że wszystkie moduły działają indywidualnie.

Aby dać przykład, co mam na myśli:

Załóżmy, że chcesz, aby jeden z programistów zbudował program rejestrujący SQL.

Definiujesz interfejs i pytasz jednego ze swoich programistów ( lub tworzysz historię, jeśli korzystasz z Agile ), że chcesz logger specyficzny dla SQL zgodnie z następującą specyfikacją:

interface ILogger
{
    void Log(string message, int level);
}

Następnie oczekuję od dewelopera:

1. Implementacja specyficzna dla SQL dla programu rejestrującego

   class SqlLogger : ILogger
   {
       private readonly SqlLogRepository _logRepository;
   
       public SqlLogger(SqlLogRepository _logRepository)
       {
           this._logRepository = _logRepository;
       }
   
       public void Log(string message, int level)
       {
           _logRepository.CreateLog(message,level);
       }
   }
   

2. Dowolny kod zależny, na przykład implementacja dla SqlLogRepository

3. Testy jednostkowe lub próbne w zależności od potrzeb. Test próbny w powyższym przypadku (gdzie mamy inne zależności zewnętrzne) lub jeśli jest to np. Prosta funkcja użyteczności, taka jak String.ReverseCharacters(string input), to po prostu chciałbym zobaczyć testy jednostkowe, które testują kilka różnych scenariuszy.

To znaczy że:

Ty i Twój zespół możecie teraz kontynuować rozwój za pomocą tego interfejsu. na przykład

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

a jeśli musisz uruchomić kod przed jego SqlLoggerwprowadzeniem, możesz po prostu utworzyć NullLogger:

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

I w międzyczasie możesz to przetestować (sugeruję, aby spojrzeć na ICO w celu wstrzyknięcia zależności)

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

Podsumowanie

Nie mam pojęcia o wielkości twojego projektu, ale może to być dość zniechęcające zadanie, a jeśli nigdy wcześniej nie prowadziłeś prac rozwojowych, sugeruję, abyś potraktował to zadanie bardzo poważnie i spędził kilka następnych tygodni czytając tyle samo, co Ty potrafi na projektowaniu oprogramowania i architekturze. I bądź bardzo przejrzysty w swojej pracy ( jakość oprogramowania itp. ), W przeciwnym razie szybko znajdziesz się w głębokim bałaganie, z którego nie wiesz, jak się wydostać.

Gorąco sugeruję również zapoznanie się z projektem i paradygmatem obiektowym. Będziesz w dużym stopniu polegać na OOP w tym projekcie.

Inne odpowiedzi mówiły o aspektach programowania, ale chciałem tylko wspomnieć o aspekcie zarządzania programem. Zacznę od zrzeczenia się odpowiedzialności: nie jestem menedżerem programu. Wziąłem jeden kurs na poziomie magisterskim w zakresie zarządzania programem, a moje doświadczenie zawodowe polega na licytowaniu godzin dla małych projektów, które zwykle trwają krócej niż 500 godzin i nigdy nie przekraczają 1000 godzin.

Ale musiałem pomóc w zdefiniowaniu zadania dla laboratorium, w którym musiałem utrzymywać 2-3 osoby zajęte przez 2-4 miesiące (pół etatu i pełny etat). Jedną z rzeczy, która naprawdę mi pomogła, było korzystanie z oprogramowania do zarządzania projektami, takiego jak Microsoft Project (nie jestem pewien, czy dostępna jest tam wersja bezpłatna, ale twój pracodawca prawdopodobnie ma coś takiego ... zapytaj swojego przełożonego, jakie oprogramowanie do zarządzania programem jest używane w twojej firmie). W szczególności dość często korzystam z wykresów Gantta, co jest domyślnym widokiem w Microsoft Project. Określając wszystkie zadania i czas ich trwania, możesz uzyskać wizualizację do zabawy.

Wykres Gantta najbardziej mi pomaga ze względu na jego wizualizację. Widzenie zadań na papierze niewiele mi pomaga, ale z pewnością ładne zdjęcia i wykresy. Microsoft Project pozwala również na ustawienie poprzedników i dat rozpoczęcia, przy czym głównym założeniem jest „Znajdź minimalną liczbę zadań wymaganych do uruchomienia, aby zadanie X mogło się rozpocząć”. Przynajmniej w moich małych projektach liczba „prawdziwych” poprzedników jest dość niewielka. W rzeczywistości przy jednym projekcie miałem problem, że prawie wszystko można zrobić jednocześnie, i musiałem zsyntetyzować dwie współbieżne ścieżki, które były dość spójne. Np. Starałem się upewnić, że jeśli programista A dotknie GUI, pracują również nad zadaniami, które są zbliżone do GUI.

Wygląda na to, że robiłeś już dużo tego, jeśli chodzi o papier i długopis, ale zawsze uważam, że naprawdę pomocne jest zobaczenie wykresów Gantta. Patrzenie na kolejno ustawione zadania naprawdę sprawia, że ​​myślę: „Czekaj, czy zadanie X naprawdę musi zostać wykonane przed zadaniem Y? (Z mojego dotychczasowego doświadczenia byłem zaskoczony, jak często odpowiedź brzmi„ nie ”)”

Wygląda na to, że ukończyłeś programistę i zostałeś inżynierem oprogramowania. Zdaj sobie sprawę, że zarządzanie pracą nie jest ćwiczeniem projektowym, ale oba idą w parze. Musisz zarządzać wykonywaną pracą, a to zależy od rozwoju Twojej firmy. Jeśli masz czas i zasoby, przyjrzyj się zwinnej metodologii - w Internecie jest mnóstwo materiałów pisemnych. Znajdź taki, który Ci odpowiada, ale pamiętaj, że podobnie jak wszystko inne, nie jest bezpłatny. Zastosowanie wszelkich technik obejmuje szkolenie, naukę i porażkę, zanim odniesiesz sukces. Jeśli nie masz wystarczającej przepustowości, aby poradzić sobie z przyjęciem bardziej kompleksowej techniki, wówczas planowanie kamienia milowego może być dla Ciebie odpowiedzią. Jeśli masz listę zadań sekwencyjnych, być może nie znalazłeś sekwencji, które mogąbyć zrównoleglony. Może się zdarzyć, że chcesz podzielić swój rozwój na bardziej ogólne zadania, takie jak testowanie i implementacja. To samo w sobie nie rozwiązuje problemu z raportowaniem, ale zarządzasz jakością. Twój postęp może być sekwencyjną listą, ale twoje role są równoległe. Tylko sugestia. Projekt odwzorowujący pracę wykonaną przez ludzi nazywany jest strukturą podziału pracy.

Istnieje wiele dobrych sugestii, które zaoferowały inne osoby, ale pamiętaj, że zarządzasz pracą. Czasami możesz mapować koncepcje pracy do projektu / architektury, czasem nie możesz tego zrobić tak łatwo. Zawsze istnieje sposób na uporządkowanie pracy, aby można ją było śledzić. Proponuję wrócić do swojego kierownika i zapytać go, co jest dla niego ważne, jeśli chodzi o komunikację o stanie projektu. To zacznie mówić, jak podejść do tego, co robisz. Jeśli jest to harmonogram, warto skupić się na raportowaniu postępów. Jeśli jest to jakość, chcesz zgłosić zestaw wskaźników, które musisz wymyślić. Jeśli to kosztuje, prawdopodobnie będziesz chciał spojrzeć na wysiłek. Wszystkie te rzeczy można również przypisać do zadań lub z zadań.