Wyślij zapytanie Dołącz do Sii

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.

Ocena:
Autor
Avatar
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.

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Może Cię również zainteresować

Pokaż więcej artykułów

Bądź na bieżąco

Zasubskrybuj naszego bloga i otrzymuj informacje o najnowszych wpisach.

Otrzymaj ofertę

Jeśli chcesz dowiedzieć się więcej na temat oferty Sii, skontaktuj się z nami.

Wyślij zapytanie Wyślij zapytanie

Natalia Competency Center Director

Get an offer

Dołącz do Sii

Znajdź idealną pracę – zapoznaj się z naszą ofertą rekrutacyjną i aplikuj.

Aplikuj Aplikuj

Paweł Process Owner

Join Sii

ZATWIERDŹ

This content is available only in one language version.
You will be redirected to home page.

Are you sure you want to leave this page?