Analiza biznesowa / Zespół radzi Analitykowi

Twórzmy na konkretach cz.2

Luty 22, 2016 0
Podziel się:

W poprzednim wpisie opisałem 2 projekty, które nie sprzyjały pracy programisty. Pozwalały one na istnienie niedomówień, dość szeroką interpretację wymagań czy szczątkowe informacje na ich temat. Można by uciec od nich z rękami w górze i krzykiem na ustach. Na szczęście nie od każdego projektu wieje taką grozą. Zdarzają się też projekty zorganizowane, ułożone i przejrzyste. Tak po ludzku, “ogarnięte”.

AKT III

Trzeci projekt, o którym chciałem napisać, jest wisienką na torcie. Pokazaniem, że można. Że nie każda aplikacja robiona jest metodą częściowo partyzancką. Tak jak w poprzednim przypadku, jest to aplikacja tworzona dla klienta oraz tworzona jest wyłącznie w technologii webowej. Różnica jest o tyle istotna, że przetwarzane są dane finansowe, a generowane dane są dość istotne (prawdopodobnie dotyczy to większości takich projektów, ale udajmy przez chwilę, że ten był jednym z kilku wyjątkowych 🙂 )

Co daje ta wyjątkowość? Konkrety! Została wypracowana solidna i w większości przypadków nienaruszalna metodyka bazująca na SCRUMie. Skupmy się na części związanej z User Stories, jakie mają zostać zaimplementowane. Zespół składał się z 6 programistów oraz Team Leadera. Aby US mógł wejść do sprintu, musiał zostać oszacowany czas potrzebny na jego implementację. Odbywało się to na spotkaniach nazywanych planning poker i brał w nich udział cały zespół. Aby było to możliwe nikt z zespołu deweloperskiego, nie powinien mieć wątpliwości, co należy zrobić, ani jak powinien wyglądać wynik końcowy (jeżeli US dotykał kwestii interfejsu). Jeżeli pojawiały się jakieś pytania to US wracał do biznesu w celu uzupełnienia opisu o brakujące informacje. Ot, cała filozofia.

KURTYNA

Czym są te konkrety, na których powinniśmy tworzyć? Jasno zdefiniowane wymagania. Dokładnie wiedząc, co należy zrobić, wykonujemy swoją pracę lepiej. Zadanie opisane w stylu “tu jest mockup, zrób tak, aby było dobrze” dają dużo możliwości dla osoby, która będzie je wykonywać. Duże możliwości zarówno do twórczej pracy, ale też i bardzo duże pole do wygenerowania potencjalnych błędów. Tego ostatniego zawsze chcemy uniknąć. Dlatego uważam tę kwestię za ważną. Niezależnie od tego do kogo takie zadanie zostanie przypisane, osoba ta powinna wiedzieć co należy zrobić a wynik jej pracy powinien zgadzać się z wcześniejszymi oczekiwaniami.

Oceń ten post
Jacek Nakonieczny
Autor: Jacek Nakonieczny
Programista Salesforce oraz Ruby on Rails odpowiedzialny za implementację dedykowanych systemów klasy CRM czy SFA/FFM. W wolnym czasie odwiedza konwenty fantastyki, robi zdjęcia, jeździ rowerem oraz lata quadcopterem. Pomagał przy organizacji Lubelskich Dni Informatyki w latach 2012-2014, a obecnie udziela się w lokalnej społeczności Makerspace/Hackerespace.

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

Zostaw komentarz