Zapobieganie pożarom – czyli jak lepiej tworzyć oprogramowanie z użyciem metodyki programowania zwinnego

By | 18 listopada 2017

Gdy zaczyna się pożar…

Najgorszym momentem podczas tworzenia oprogramowania jest chwila w której dowiadujemy się że końcowy produkt nie jest zgodny z oczekiwaniami klienta i prawdopodobnie czas doprowadzenia produktu do stanu oczekiwanego będzie dużo dłuższy niż zakładaliśmy.

Jak daleko trzeba się cofnąć jeżeli dopiero podczas testowania znajdziemy błąd analizy oczekiwań klienta źródło: Wikipedia.org

Zwykle nie jest to wina tylko jednej strony, ale wynika ze złożenia braku zrozumienia klienta, a z drugiej strony klient też nie do końca potrafi określić czego potrzebuje. Jednak zwykle wina pozostanie jednak po naszej stronie, ponieważ to my zgodziliśmy się na warunki klienta. Następnie trwa gaszenie pożaru, czyli łatanie oprogramowania lub kary umowne i utrata klienta, co nie jest zbyt optymistyczną perspektywą.

Jednak okazuje się że jest sposób na to żeby się uchronić przed niektórymi błędami. A sposobem na to jest metodyka programowania zwinnego (nie jest to panaceum na problemy ale na pewno pomoże). Oczywiście dla każdego to określenie może znaczyć co innego, ważne żeby jej fundamenty były oparte na wzajemnym sprawdzaniu się klienta i wykonawcy.

Samych metodyk zwinnych jest wiele i trzeba się zastanowić jaką chcemy wdrożyć i jak dużo chcemy z niej czerpać. Może nawet ktoś skusi się wykorzystać kilka pomysłów z jednej a kilka z innej i też może się to okazać poprawne, ważne żeby to robić z głową.

Jak się to u mnie robi?

  1. Projekt jest dzielony na sprinty, czyli okres czasu (1 do max 2 tygodnie) w którym zakładamy wykonanie zaplanowanych zadań,
  2. Każdego dnia odbywa się daily, na którym zespół zbiera się żeby wymienić się wykonaną pracą z poprzedniego dnia i przekazuje informację na temat aktualnych prac (punkt dla większego zespołu powyżej 3-4 osób i ważne jest żeby nie przekroczyć 15 – 20 min na takie spotkanie, ponieważ gdy jest dłużej to spada efektywność pracy w danym dniu),
  3. Ostatniego dnia każdego sprintu odbywa się demo, czyli prezentacja wykonanych zadań przed klientem (bardzo ważny punkt),
  4. Oraz ostatni punkt – planowanie zadań na następny sprint.

Oprócz sprintów określane są jeszcze kamienie milowe, czyli momenty w których ma zostać wdrożona jakaś większa funkcjonalność, przy czym ważne jest żeby każdy znał cel i datę w której powinien zostać osiągnięty.

Dlaczego demo w sprincie jest takie ważne? ponieważ jest to ten moment w którym klient dowiaduje się co w ciągu tego sprintu udało się nam zrobić i w jaki sposób to działa. Jeżeli się okaże że minęliśmy się z założeniami klienta lub zostały one źle sformułowane, to ostatecznie tracimy jedynie jeden sprint i możemy gasić malutki płomień zamiast wielomiesięcznego pożaru. Swoją drogą porównanie do pożaru jest bardzo dobre, ponieważ mały płomień zwykle da się ugasić i nie powinien poczynić wielkich strat, ale jeżeli stracimy nad nim panowanie lub nie będziemy wiedzieć że się rozprzestrzenia to może pochłonąć cały nasz dobytek, czyli projekt nad którym długo pracowaliśmy.

Ale pamiętaj że nie tylko demo jest ważne i w zasadzie te 4 (ewentualnie przy mniejszym zespole 3) punkty które napisałem to jest taki plan minimum, które warto wdrożyć, a ponieważ przeszedłem przez różne firmy i różne sposoby zarządzania projektem, mogę powiedzieć że ten sposób jest dla mnie najbardziej odpowiedni i daje pojęcie na temat tego ile pozostało jeszcze pracy.

Planowanie, jak to robić?

Nie jest to proste i przez pierwsze sprinty w których miałem sam szacować czas pracy na wykonanie określonych zadań wszystko mi się rozjechało i nie domknąłem sprintu. Dlatego dam Wam kilka pomysłów na to jak to robić trochę łatwiej.

  1. Wszystkie zadania jakie są do zrobienia w ramach projektu powinny zostać rozdzielone na moduły, grupy i kolejne mniejsze jednostki w zależności od złożoności projektu (lepiej zadanie na tydzień rozłożyć na dwa zadania po 2,5 dnia bo to już tak nie przeraża, a dodatkowo łatwiej jest oszacować czas) i umieszczone w pliku dostępnym dla całego zespołu,
  2. Jeżeli zadanie wydaje się zbyt ogólne, to rozpisz w kilku punktach co powinno zostać zrobione w takim zadaniu (łatwiej oszacować czas pisania małej funkcji niż dużego modułu),
  3. Wybierz i oszacuj czas wykonania zadań w sprincie a następnie w zespole skonsultuj czy oszacowany przez ciebie czas jest odpowiedni (być może ktoś podsunie ci pomysł jak to zadanie wykonać szybciej lub wyprowadzi cię z błędu i wyjaśni dlaczego w takim czasie się nie da tego zrobić),
  4. Staraj się nie przekraczać 2 godzin na planowanie, ponieważ wiem że w większości wypadków da się zaplanować pracę w zespole ok 5 osób w takim czasie, a ludzie i tak już będą coraz gorzej myśleć.

Nie rozumiem dlaczego mam to wdrażać, przecież to trwa tyle czasu

Na początku ja też tak myślałem i strasznie demotywowało mnie to że muszę znów oszacować swój czas (co szło mi słabo) i pewnie się nie wyrobię, a tracę czas na głupoty, które i tak mi nic nie dają. I tak było przez kilka sprintów, po czym nagle zacząłem mimowolnie wsiąkać w to. Okazało się po dłuższym czasie że nawet to zrozumiałem 🙂 a teraz nie mogę inaczej pracować. Okazuje się że teraz nie dość że potrafię zaplanować sobie sprint i z dużą dozą prawdopodobieństwa dobrze oszacować czas zadań (o ile nie będzie dużo wrzutek, czyli dodatkowych zadań, które trzeba zrobić w czasie sprintu) i coraz rzadziej zdarza mi się że przed deadline muszę się spinać i siedzieć po nocach. Właśnie idea programowania zwinnego również chroni przed tym, ponieważ na każdym małym etapie widzisz ile jeszcze zostało ci do końca projektu.

Taki pro-tip dla firm, które jeszcze nie wdrożyły metodyki zwinnej a chciałyby: jest wiele warsztatów i szkoleniowców, którzy przekonają i pokażą jak to robić dobrze. Ważne jest żeby zespół lub jego manager tego chciał bo po chwili męki będą z tego same korzyści.

Czy ta metodyka sprawdza się tylko w programowaniu?

Sądzę że nie, zwłaszcza że w coraz większej ilości firm jest ona wdrażane, tylko nikt jej tak nie nazywa. Wg. mnie każda praca twórcza powinna być dzielona na mniejsze kawałeczki dzięki czemu łatwiej to w jakiś sposób ogarnąć rozumem, a przecież nikt nie będzie mówił że tego się używa w programowaniu więc nie możesz używać gdzie indziej. W każdej firmie można znaleźć jakieś fajne pomysły, tylko warto sprawdzić czy są one dobre dla naszej firmy i jeżeli tak to się nie zniechęcać, bo gdybym się zniechęcił to nie poznałbym tak dobrego sposobu zarządzania projektem.

2 thoughts on “Zapobieganie pożarom – czyli jak lepiej tworzyć oprogramowanie z użyciem metodyki programowania zwinnego

  1. Grzegorz

    Drobna uwaga:
    Metodologia to nauka o metodykach.
    Agile to zbiór metodyk.
    G.

    Reply

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *