Sii Polska

SII UKRAINE

SII SWEDEN

  • Szkolenia
  • Kariera
Dołącz do nas Kontakt
Wstecz

Sii Polska

SII UKRAINE

SII SWEDEN

Wstecz

22.02.2016

Twórzmy na konkretach cz.2

22.02.2016

Twórzmy na konkretach cz.2

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
Avatar

O autorze

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.

Wszystkie artykuły autora

Zostaw komentarz

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

Może Cię również zainteresować

Dołącz do nas

Sprawdź oferty pracy

Pokaż wyniki
Dołącz do nas Kontakt

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?