Minimum Viable Product (MVP)

Chciałem dzisiaj powiedzieć o podejściu które jeszcze nie wiem jak dobrze nazwać (może Lean, a może Agile, a może właśnie MVP, o którym to określeniu dowiedziałem się od mojego reviewera), a chodzi w nim żeby być minimalistą w implementowanych funkcjach i skupiać się na meritum (i dostarczyć to w miarę szybko).

Dobrym przykładem niech będzie logowanie do systemu.
Gdy mamy wszystko zaplanowane to wiemy jakie będzie logowanie, jak będziemy się łączyć z innymi systemami. Mamy już coś tam rozrysowane i mamy to zatwierdzone przez kogoś kto robił podobne systemy i się na nich zna. Można wtedy trzepać takie systemy jeden po drugim bez zastanawiania się (i zarabiać dobre pieniądze dla firmy). No i mamy ten dzień, deadline, na który dopiero wszystko ma działać. Dzisiaj nie będzie takiego podejścia.

Zdarza się jednak, że kolejny projekt to wykonania to jest właśnie coś nowego. Wtedy trzeba przenieść nacisk z podejścia top->down na bottom->up.

Podejście Lazy

Czas temu brałem udział w projektowaniu kolejnej części projektu programowanego w ramach poszerzania horyzontów. Taki projekcik po godzinach, żeby nie zanudzić się starymi technologiami. Dało mi to kopa i wiele do myślenia, bo dawno nikt się tak ze mną nie zgadzał 🙂

Trzeba też wtedy wyluzować odnośnie budowania abstrakcji (nie budować interfejsów „na przyszłość”). Podchodzić lazy do wszystkich rzeczy, które mogą się przydać.

Sam w jednym projekciku miałem następującą sytuację. Wiedzieałem, że encja User powinna mieć kolekcję encji Product‚ów (tak mi się wydawało). Jednak pierwszą funkcjonalność prościej było zbudować gdy to Product miał kolekcję User‚ów. Jako że caly czas jest to jakby prototyp to dane, które w nim umieszczam sa w rozmiarach ‚po kilka’ więc prosto odwrócić zależność, gdy już rzeczywiście jest taka potrzeba. A czasem okaże się, że zostaniemy z tym rozwiązaniem (tymczasowym) do końca. Nie zawsze musimy preferować rozwiązania, które nam sie zwrócą w przyszłości nad rozwiązania na już. Czasem przypomni o tym PM (i dobrze że jest taka osoba która sprawi, że programiści nie tworzą sztuki dla sztuki).

Bez skrajności w super kod

Nie ma tylko dwóch skrajnych podejść: „piszemy na teraz gówniany kod” vs „piszemy zawsze kod cudowny po wsze czasy”. W każdej sytuacji trzeba się zastanowić gdzie na „wykresie” jesteśmy i spróbować przewidzieć przyszłość.

Doświadczenie

Robienie dobrych założeń odnośnie niepewnej przyszłości i dostosowywanie aktualny development (ogólnie ludzkie działanie) to jest bardzo ważna część doświadczenia programisty.

„Doświadczenie” to dla mnie coś co może zawsze powinienem pisać w ciapkach. Dla mnie oznacza ono zrozumienie kontekstu. Można przeczytać książkę (i jak najbardziej należy), tylko trzeba to potem stosować. Jeśli w pracy piszesz ciągle projekty oparte na frameworku gdzie wszystko masz gotowe, to warto czasem napisać mały projekt gdzie wszystko jest od zera, żeby nie zapomnieć jak to jest.

Flow w mini projekcie (pet project)

hurra

Chciałbym żeby flow był taki:

Szybka istotna funkcjonalność którą ktoś widzi -> można pokazać ludziom że coś działa (uznanie dla własnej pracy) -> szybki feedback (użytkownik prawdę Ci powie) > szybki kop do następnej pracy.

a nie taki:

Utknęliśmy na logowaniu użytkownika (nie wszystko jest tak proste czasem jak się wydaje) -> aaa ten projekt nigdy nie będzie skończony, aaale mi się nie chce. Ten ogrom prac przed nami przerasta mnie.

Reklamy
Ten wpis został opublikowany w kategorii Programowanie i oznaczony tagami , . Dodaj zakładkę do bezpośredniego odnośnika.