Dlaczego warto i jak rozbijać zadania na mniejsze

Dzisiaj będzie nietechnicznie. Za to będzie produktywnie 🙂

Ważna dla programisty (i nie tylko) jest umiejętność rozbijania sobie zadań – bądź celów na mniejsze. Dlaczego?

Kiedy mam przed sobą wielkie zadanie typu „posprzątać mieszkanie” to nie wiem jak Tobie, mnie się po prostu nie chce. To jest duże i nieokreślone, nie wiem ile mi zajmie… nie wiem od czego zacząć… I tutaj lista wymówek które pojawiają się w mojej głowie, co prawda okazyjnie i nie wszystkie na raz, mogła by być znacznie dłuższa. Podobnie zaczyna się dziać, gdy zadanie jest typowo programistyczne, „duże” i/lub nieokreślone. Wiele oczywiście zależy od tego jak pracuje Twój zespół, ja lubię mieć zadanie zdefiniowane jako cel, a nie rozpisane przez kogoś innego krok po kroku co trzeba zrobić. Dzięki temu czuje i mam większy wpływ na zadanie jak i odpowiedzialność za nie. Samo duże lub nieokreślone też zmienia się u mnie wraz z doświadczeniem, gdy zaczynałem, wszystko wydawało się być nieokreślone, teraz wraz z napływem doświadczenia, moje postrzeganie tego się zmienia. Ciągle jednak dużo zalet daje rozbicie zadania na mniejsze i zapisanie gdzieś tego, nawet jak w głowie mam obraz tego co i jak powinienem zrobić.

Rozbicie zadania na mniejsze prowadzi do kilku ciekawych efektów:

• Łatwiej Ci będzie oszacować czas trwania kilku, czy kilkunastu małych zadań, niż jednego wielkiego.
• Kiedy masz listę zadań, które są ładnie porozkładane, od razu widać, od czego zacząć.
• A to działa dość motywująco – wiesz co zrobisz, jak zrobisz… To aż chce się to po prostu zacząć robić. 😉
• Nie zapomnisz o czymś ważnym, jeśli zapiszesz to coś ważnego jako zadanie lub podpunkt w nim.
• Ze względu na to, masz większy spokój, nie musisz „pamiętać, żeby pamiętać o X”. Masz to zapisane. Masz spokój.
• Możesz się podzielić zadaniami z innymi. Zrównoleglenie nie zawsze jest możliwe (albo sensowne), jednak w większości wypadków daje to w efekcie szybsze zrealizowanie zadania, jeśli będzie taka potrzeba. Dla przykładu, jeśli się nCie wyrabiam, ktoś może mi pomóc, lub mogę oddać zadanie do „eksperta” w temacie. A także, mogę dać coś czego nie lubię robić komuś kto to lubi. Obaj będziemy szczęśliwsi ;-). U iebie może to wyglądać podobnie.

Ważna uwaga: nie musisz rozbijać i zapisywać zadań w systemie jaki stosuje Twoja firma czy zespół. Równie dobrze, jeśli Ci się to sprawdza możesz używać własnego narzędzia tylko dla siebie, choćby nawet notatnika.

Czasem więc, najlepszym zadaniem numer jeden może być – rozbić zadanie na mniejsze. Może się wtedy okazać, że tak naprawdę pierwszym krokiem jest: zdobyć więcej informacji. Czy to „pogooglać”, „zapytać Łukasza”, „skontaktować się z klientem” czy coś jeszcze innego. Tak postawione zadanie, nie wyda Ci się ani wielkie i skomplikowane, ani trudne, ani czasochłonne.

Mając wszystkie informacje potrzebne do podzielenia zadania, możesz już je podzielić na rozsądne kawałki. Oczywiście, przesadzanie nie ma sensu. Rozbijanie zadania na napisanie każdej poszczególnej linijki kodu nie ma sensu, bo zabierze Ci więcej czasu niż samo zrobienie tego (chyba, że napisanie tej linijki kodu miało by być okupione 2 dniowym researchem i pisaniem testów dla niej).

Do tego, później może się okazać, że chcesz poszczególne zadanie podzielić jeszcze bardziej – będziesz mieć lepsze spojrzenie na to co trzeba zrobić i czy ma sens podzielenie tego. Przykładem może być: „zrobić funkcjonalność X” i na początku nie wiele wiesz o tym w ogóle. Więc możesz sobie zrobić, choćby „w głowie” zadanie, „dowiedzieć się więcej od/z”… a kiedy już się dowiesz, zaczynasz planować, np tak:

• zmiany na bazie
• zmiany we frontendzie
• zmiany w backendzie
• UI testy.

To z kolei możesz rozbijać na jeszcze mniejsze kawałki, albo od razu, albo wraz z postępem prac. Ja czasem, nie wiem, że będę potrzebował zrobić coś w dany sposób w jednym miejscu, np w backendzie, bo jest to wymuszone przez to jak zrobię to w innym – jakie będę miał zmiany we froncie, lub w innej częsci. Albo odwrotnie. Często jedno zadanie wpływa na drugie i po pierwszej ogólnej analizie wydawało się być inne niż po zrobieniu go, gdy już mocno zagłębiłem się w szczegóły.

Co do samego postępu prac – jakkolwiek byś nie zaczynał, dobrym podejściem jest próba zrobienia sobie działającego proof of concept idącego przez wszystkie warstwy, zamiast robienia zmian w jednej po drugiej. Od razu dostarczy to informacji o tym, co będzie trzeba trzeba zrobić w poszczególnych częściach – oraz czy warto i jeśli tak, to jak rozbić zadania z poszczególnych części. Albo je doprecyzuje. Np efektem tego może być takie rozbicie:

• Dodanie na bazie do tabeli X pola Y. (doprecyzowane zadanie, od razu też brzmi lepiej od poprzedniej wersji, jasne czytelne aż chce się robić)
• Dodanie widoku/strony z wichajstrem (można rozbić na podzadania jeśli ma sens, lub opisać sobie to gdzieś, np jak ostylować stronę, jakie zmiany w css/scss powinniśmy zrobić – to ma pomóc nam, a nie koniecznie lądować w systemie tasków firmy/zespołu).
• Dodanie drugiego widoku z panelem admina dla wichajstra
• Dodanie „na szybko” kodu obsługującego jako tako funkcjonalność, nawet mockującego większość rzeczy.
• Kontakt z klientem i pokazanie zmian. Dopytanie czy o to mu chodziło.
• Dodanie nowej akcji kontrolera (zrobione w poprzednim zadaniu, teraz tylko posprzątać)
• Dodanie nowego serwisu
• Dodanie nowego handlera
• Zmiany w kodzie modułu dotyczące foo i bar – refactoring możliwy po skończeniu zadania, uwspólnienie kodu.
• UI testy (szczegóły tego, co chcemy przetestować, jakieś scenariusze, żeby o nich nie zapomnieć)

Cześć tych rzeczy może być już gotowa dzięki proof of concept, lub cała ta lista może powstawać kawałek po kawałku w trakcie realizacji, przyrostowo rozbijając zadania, a nie od razu wszystkie.

Warto też uporządkować te zadania w kolejności, w jakiej trzeba je zrobić. Choć czasem może nie mieć to sensu bo robi się kilka na raz, tak małe i łatwe są, bądź powiązane ze sobą. Oczywiście, to tylko przykład a każdy rzeczywisty przypadek może być zupełnie inny i wymagać innego podejścia. Ale to przychodzi z czasem, doświadczeniem i wiedzą na temat tego co i jak będziesz robić. Ja sam mam z tym problem i często tworze najpierw zadania pośrednie, które dopiero później okazują się być kandydatami na lepsze rozbicie. Pracuje nad tym, żeby to ulepszyć, ze względu na wymienione wcześniej korzyści za tym idące.

Należy też wspomnieć, że rozbijanie zadań na mniejsze, nie dotyczy tylko „tasków programistycznych”, ale pomaga też na co dzień. Pamiętasz przykład z początku „posprzątać mieszkanie”? A znacznie lepiej wygląda rozbity na mniejsze, np per pomieszczenie czy jeszcze dokładniejsze zadania. Sama zmiana w myśleniu o zadaniu jako kilku zadaniach zmienia postrzeganie, chęć i motywacje do jego wykonania. Ciężko nam objąć i wyobrażać sobie rzeczy duże, nasze mózgi nie są do tego stworzone. Za to obejmowanie mniejszych kawałków, dla naszego mózgu jest znacznie łatwiejsze.