Posty z kategorii: Metodyki

Dlaczego Nozbe a nie Todoist?

Cześć!

Prosiliście na Twitterze o wyjaśnienie w kilku słowach, dlaczego wybrałem Nozbe. Zatem śpieszę się z wyjaśnieniem 🙂

Jakie alternatywy?

Miałem do wyboru 2 programy: Nozbe i Todoist. O Todoist usłyszałem w jednym z vlogów Maćka Aniserowicza. Mówię spoko, spróbuję to wdrożyć, bo ilość rzeczy do zrobienia była przeogromna. To było w okolicach marca bodajże czy kwietnia. Nie wiem, nie ważne. No i sobie pobrałem, założyłem konto i w darmowej subskrypcji zacząłem korzystać. No co tu dużo mówić. W darmowej subskrypcji Todoist w skrócie ogranicza się do checklisty. No jest turbo ubogie. I tak jakoś odszedł ode mnie ten temat, dalej miałem wszystko w głowie, a w kryzysowych sytuacjach wypisywałem zadania na kartce. Jednak była ona mało elastyczna.

Minęły wakacje, troszkę w czasie nich się doedukowałem o GTD i postanowiłem wziąć byka za rogi. Do lutego mam bardzo dużo projektów do wykonania, największym z nich jest praca inżynierska. Temat jest bardzo ciekawy, ale swoje trzeba będzie odsiedzieć (swoją drogą na samą myśl już się jaram, że robię coś tak fajnego). Do tego wszystkiego potrzebuje czegoś, co pomoże mi ogarnąć tematy, a jest tego całkiem sporo.

No to które wybrać?

Przede wszystkim chciałem mieć jedno narzędzie. Rozważałem przez chwilę kwestie posiadania dwóch narzędzi, ale mówię nie. Coś czuję, że zrobiłbym sobie tylko większy bajzel. Ten projekt jest tu, ten jest tu. Przeglądasz jedno narzędzie, zapomnisz o drugim. Na początek jedno. Z czasem zobaczymy, przecież system produktywności buduje się latami 🙂 No to które z nich? I tutaj pojawił się kolejny mój problem – z szybkim podejmowaniem decyzji… No to zacząłem szukać i czytać/oglądać.

O Todoist Maciek Aniserowicz mówił przy okazji planowania tygodnia:

O Todoist pisał u siebie także Michał Chęciński. Post ten znajdziesz tutaj.

O Todoist pisała u siebie także Żaneta Jażdżyk. Post znajdziesz tu.

No i oczywiście blog Todoist.

O Nozbe pierwszy raz usłyszałem u Mirka Burnejki.

lub

Ponadto powstał Devtalk z Michałem Śliwinskim, który jest założycielem firmy Nozbe. Michał Szafrański z podcastu Więcej niż oszczędzanie pieniędzy, także dołożył swoją cegiełkę w tym temacie.

O Nozbe także pisała Żaneta m. in. tutaj lub tutaj.

No i oczywiście blog Nozbe.

Osz kurde i co wybrać…

No dokładnie. Głowiłem się nad tym ładnych kilka dni. Szukałem porównań. Zadałem pytanie na Twitterze, która z aplikacji jest lepsza i wywiązała się całkiem ciekawa dyskusja. Dziękuję wszystkim, którzy dołożyli do tego swoje 5 groszy. Znów Żaneta Jażdżyk pokusiła się o porównanie obu aplikacji.

No i wybrałem Nozbe

No i smaczek tego wpisu. Dlaczego Nozbe?

  1. Wokół Nozbe tworzy się bardzo fajna społeczność.
  2. Nozbe jeszcze nie spróbowałem.
  3. Produkt polski. Uważam, że warto promować i używać produkty tworzone przez Polaków tym bardziej, że widać, iż jest on tworzony przez pasjonatów.
  4. Nozbe stara się, aby użytkownik czuł się hmmm…. „dopieszczony”? Klient (np. taki ja, Waszek) czuje się indywidualnie traktowany, co jest widoczne po korespondencji emailowej, kursie 10 kroków do maksymalnej produktywności, czy aktywnego uczestnictwa w podjętej przeze mnie dyskusji na Twitterze. To ostatnie to mi szczena opadła, jak zobaczyłem komentarze.
  5. Ciekawy interfejs.
  6. Jedna warstwa projektów. Nie ma możliwości tworzenia podprojektów, co jest w sumie fajne. Według mnie projekt to projekt i nie ma sensu tworzyć drzewek jak w jakimś dziedziczeniu. Projekty można sobie zamiast tego oznaczać etykietami, które mogą zastąpić tworzenie ich jako podprojektów, a ponadto projekt może mieć więcej niż jedną etykietę. Poszczególne zadania możemy kategoryzować, np. jako telefon itd.
  7. Nawet jeśli nie zdecyduję się przedłużyć subskrypcji po darmowym miesiącu to i tak będę miał możliwość prowadzenia 5 projektów z pełną funkcjonalnością aplikacji, a nie dostanę takiego czegoś jak Todoist.
  8. Przypomniałem sobie jeden z vlogów Maćka Aniserowicza. W skrócie: nie rozwódź się nad decyzją. Można ją zmienić w każdej chwili. I tak mówię, trzeba spróbować tego narzędzia. Jeżeli mi się nie spodoba, to nawet po opłaceniu subskrypcji jeszcze przez miesiąc mogę poprosić o zwrot pieniędzy, więc w sumie mam 2 miesiące na dobre zapoznanie się z aplikacją.

Na razie (chociaż dopiero 2. dzień z Nozbe) minusem jest cena, po prostu jest droższy niż Todoist. Ale za jakość należy zapłacić 😉

A no jeszcze jedna rzecz – brak integracji z OneNote, ale tym się nie martwię, bo w czasie pisania tego wpisu Nozbe dodało komentarz na Twitterze, że planują to dodać 🙂

Podsumowanie

Mam nadzieję, że jeżeli będziesz się zastanawiał, to ten wpis pomoże Ci wybrać 🙂 Albo jedno albo drugie 🙂 Proszę Cię, nie odbierz tego wpisu jako jakąś reklamę. W kilku słowach postarałem się opisać, dlaczego Nozbe. Tak jak prosiliście na Twitterze 🙂 Jeżeli chcesz dorzuć coś do tego tematu to zapraszam do komentowania! Do zobaczenia!

MVP i MVC – wstęp, rozwinięcie, bez zakończenia

Siyakwamukela! (zulu)

Wracamy do rozważań nad modelowanie aplikacji. W ostatnim wpisie, gdzie wyciągaliśmy informacje ze scenariuszy przypadków użycia narzuciłem temat wzorców architektonicznych MVP i MVC. Wtedy o nich wspomniałem, podlinkowałem parę rzeczy, jednak dzisiaj mam nadzieję troszkę to rozwinąć 🙂

Wzorce projektowe i architektoniczne

Wzorzec projektowy jest narzędziem do rozwiązywania powtarzalnych problemów pojawiających się podczas implementacji oprogramowania. Co ważne, wzorzec mówi tylko, jak podejść do problemu, od której strony go ugryźć, daje schemat rozwiązania zagadnienia. O wzorcach projektowych powstała świetna książka, którą napisali Erich Gamma, Richard Helm, Ralph Johnson i John Vlissides, czyli grupa określana „Bandą czworga”. Mowa oczywiście o książce „Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku„. W dzisiejszym programowaniu bez wzorców projektowych nie ma sensownej pracy.

Wzorzec architektoniczny jest podobnym narzędziem do wzorca projektowego, jednak tutaj problemy implementacyjne nie dotyczą relacji klas, obiektów, zaś odnoszę się do struktury systemu, podziału na moduły i relacji pomiędzy nimi. MVP i MVC są właśnie takimi wzorcami.

Zacznijmy od MVC

Głównym zadaniem programisty nie jest wbrew pozorom zaimplementowanie fury kodu, która robi coś tam. Programista jest postawiony przed pewnym problemem, którego musi dokonać analizy i wykonać podział na mniejsze, dające się łatwo zaimplementować fragmenty. Implementacja jest procesem wtórnym.

We wzorcu MVC podchodzimy do analizowanego problemu rozbijając go na trzy składowe, od których bierze się nazwa wzorca:

  1. Warstwa Model – w tej warstwie zawieramy całą logikę biznesową aplikacji. Bardzo ważnym jest, aby nie mieszać warstw ze sobą i żeby rzeczywiście cała logika biznesowa została w tej warstwie.
  2. Warstwa View, czyli widoku – w tej warstwie zawierają się wszystkie klasy, których obiekty potem zmaterializują się w postaci interfejsu graficznego wyświetlanego użytkownikowi; poszczególne fragmenty widoku odpowiadają odpowiednim fragmentom modelu
  3. Warstwa Controller, czyli kontroler – przyjmuje akcje wywołane przez użytkownika, względem których odpowiednio zarządza aktualizowaniem modelu.

Taki podział systematyzuje sposób budowy tworzonego oprogramowania. Na poniższym diagramie można zaobserwować przebieg działania systemu zbudowanego w ten sposób.

Użytkownik systemu wciska przycisk, który jest elementem warstwy widoku. Zdarzenie to jest przekazywane do kontrolera. Kontroler wywołuje odpowiednie działania w warstwie modelu. Po wykonaniu operacji model wywołuje aktualizuje widoku, który to pobiera nowe dane w trybie odczytu z warstwy modelu, już bez uczestniczenia kontrolera.

A MVP?

We wzorcu Model-View-Presenter warstwy są tak samo podzielone. Tutaj zamiast warstwy kontrolera, mamy prezentera, który rozdziela warstwy widoku i modelu. Relacja pomiędzy warstwami wygląda jak na poniższym diagramie.

Znów widok wywołuje, tym razem w prezenterze, akcję wychwyconego zdarzenia. Prezenter zarządza aktualizację modelu. Kiedy to zostanie wykonane, model informuje prezentera, że jego stan uległ zmianie. Prezenter pobiera zaktualizowane dane z modelu, odpowiednio je formatuje i przesyła do warstwy widoku, która prezentuje je użytkownikowi.

Zastosowanie

Wzorce MVP i MVC są powszechnie stosowane w projektach. U mnie też będą zastosowane, tak jak już o tym pisałem. Na diagramach klas dla każdego scenariusza, które mam nadzieję niebawem się pojawią zobaczysz fizyczną realizację architektury systemu zgodnie ze wzorcem MVP. Taka struktura systemu jest elastyczna, łatwo można podmieniać poszczególne warstwy dlatego, że są rozdzielone od siebie.

Podsumowanie

Diagramy miały się już pojawić, ale niestety się nie ogarnąłem z tym. Jak się pali, to od razu cała wieś post ten powstał, ponieważ jeden z czytelników zasugerował mi dogłębniejsze pochylenie się nad tymi wzorcami, które de facto są bezpośrednio związane z moim projektem 🙂 Teraz niestety zaliczenia na dwóch kierunkach biorą górę i muszę się nad tym skupić, zatem na chwilkę wygaszamy pracę nad projektem. Co się odwlecze to nie uciecze 🙂 W zanadrzu mam jeszcze jeden post dla Was, ale musicie być cierpliwi 🙂

Oczywiście zachęcam do komentowania i udostępniania mojej twórczości. Każda interakcja jest na wagę złota, ponieważ pokazuje, że ktoś czyta moje wypociny 🙂 Tymczasem życzę Ci miłego dnia i do zobaczenia! 🙂

Zwinne testowanie

Welkom! (holenderski)

Witam Cię w poniedziałkowy wieczór znów na mojej stronie. Tak szybko kolejny wpis? Tak! Nadrabiamy zaległości, poza tym dzisiejszy temat jest kontynuacją wczorajszego, więc idę za ciosem. Dzisiejszy dzień jest bardzo ważny dla mnie z różnych powodów i zwieńczenie go wpisem, będzie wisienką na torcie. Może zastanawiasz się, co z projektem? Te posty są bezpośrednio z nim związane. Otóż jak pisałem, bodajże w opisie projektu na stronie konkursu, wybrałem stosunkowo prosty projekt po to, żeby móc pokazać troszkę wiedzy i poglądów na pewne tematy oraz nauczyć się nowych technologii na jakimś żywym przykładzie. Także w projekcie dzieje się cały czas! No ale już nie przedłużając, jedziemy z dzisiejszym tematem.

Dzisiaj chcę z Tobą, drogi czytelniku, pociągnąć temat zwinności i metodyk z nią związanych. Jeżeli widziałeś ten szkic specyfikacji, który powstał i leży sobie spokojnie na GitHub, to może zwróciłeś uwagę na końcowe zdanie. Do budowy aplikacji zostanie wykorzystana metodyka Test-Driven Development. Ale co to tak naprawdę jest?

TDD

TDD, czyli Test-Driven Development jest uważana za metodykę zwinną głównie ze względu na spełnienie manifestu: „Działające oprogramowanie ponad obszerną dokumentację”. Testowanie oprogramowania ogranicza (nie eliminuje!!!) występowanie błędów, a dobrze napisane testy mogą usprawnić dokumentowanie kodu, możemy potraktować je jako formę specyfikacji. Wróćmy do początku i zdefiniujmy sobie dokładnie hasło TDD. Za tym pojęciem kryje się cykliczne wykonywanie kilku kroków (za Wikipedią):

  1. Projektujemy test
  2. Implementujemy funkcjonalność
  3. Refaktoryzujemy kod

Brzmi to jednak bardzo pobieżnie i enigmatycznie, jednak kryje się za tym bardzo duża siła (czym jestem ostatnio zafascynowany i dlatego teraz, razem z Wami poznaję tę tematykę).

Co w trawie (TDD) piszczy?

Sednem TDD nie jest tak naprawdę pisanie oprogramowania niejako od tyłu, no bo w sumie po co i czemu tak, a w ogóle to te całe testy to nie wiadomo po co są, szkoda klawiatury. Pozwól jednak, że udowodnię Ci nieprawdziwość takiego podejścia!

Z definicji test jednostkowy ma przetestować pojedynczy element programu, jego zachowanie w różnych, mniej lub bardziej sprzyjających warunkach. Rozpoczynanie tworzenia aplikacji od zdefiniowania testów, które nawet się nie skompilują ze względu na brak reszty szkieletu zmusi do myślenia i wyciągnięcia z odchłani mózgu, co tak naprawdę chcemy uzyskać. Wychodzimy ze sztywnych więzów implementacyjnych na rzecz interfejsu i funkcjonalności, co w sumie jest zgodne z Agile (znów).

W kolejnym kroku następuje implementacja brakującego szkieletu (z tego co się orientuję to VS i Eclipse udostępniają automatyczne narzędzia, trzeba się będzie przekonać :), ponadto w tym kroku solucja się skompiluje ale uruchomienie wywoła test, które siłą rzeczy nie przejdą) i wypełnienie tego szkieletu logiką (o i działa :D). W tym miejscu zaczynają przechodzić testy. Przechodzimy zatem do punktu 3., czyli refaktoryzujemy kod. Ta wstępna implementacja jest pisana tak z marszu, po to, żeby testy przeszły. Osiągamy przez to jeden cel działającej funkcjonalności spełniającej nasze oczekiwania. Refaktoryzacja jest bardzo ważnym krokiem. Otóż kod powinien być sporządzony w taki sposób, aby testy zawsze kończyły się wynikiem pozytywnym, zatem refaktoryzacja kodu nie ma prawa wpływać na wynik testu. Jeżeli tak jest, to należy się zastanowić, czy sam test został sporządzony poprawnie (znaczyłoby to, że funkcjonalność jako taka nie została dobrze określona). W przeciwnym razie popełniliśmy błąd w przebudowie kodu i należy przeprowadzić ten proces jeszcze raz.

Refleksja

Czy warto jest stosować TDD? Tak! Jednak jak ze wszystkim musimy być rozważni. Już tłumaczę w czym rzecz. Takie podejście do stworzenia oprogramowania pozwala na minimalizację liczby błędów występujących w tworzonym oprogramowaniu. Nigdy nie jesteśmy w stanie wyeliminować ich w 100%, ale minimum jest zawsze najlepszą opcją 🙂 Ponadto testy stanowią dokumentację funkcjonalności dostarczanych przez pakiet oraz mają w sobie przykłady użycia – zatem bezsensowne staje się pisanie zewnętrznego manuala jako dokumentu, jeżeli śledząc kod testu możemy tego dotknąć na żywca.

Oczywiście też jest druga strona medalu. Testy są oczywiście kodem do utrzymywania – dla części osób może to stanowić poważny problem, bo jak wiemy programista to z natury leniwe coś. Samo podejście od tej strony nie jest łatwe, jednak wszystko się da. Materiałów jest cała masa, czy to właśnie podobnych dywagacji czy tutoriali. Pod postem coś tam podlinkujemy fajnego 🙂 To chyba tyle, pamiętaj też, drogi czytelniku, że to tylko narzędzie i trzeba z niego odpowiednio korzystać 🙂

Nie samym TDD człowiek żyje

To co, tak zachwalał i tłumaczył i teraz ucieka? Nic z tych rzeczy 🙂 Ale przy tak świetnej okazji trzeba wspomnieć o ewolucji narzędzia TDD, znanej jako Behavior-Driven Development, w skrócie BDD. Szukając w internecie informacji na ten temat przygotowując się do tworzenia tego posta, często spotkałem się ze stwierdzeniem, że BDD to TDD a TDD to BDD. W istocie rzeczywiście tak jest. Rozszerzenie BDD względem TDD polega na wykorzystywaniu narzędzi do definiowania funkcjonalności oraz przygotowywaniu tzw. user scenarios, które to opisują przebieg krok po kroku konkretnej funkcjonalności. Świetny przykład formowania user scenarios znajduje się pod tym linkiem. User scenarios zapisuje się np. za pomocą języka Gherkin, który współpracuje z narzędziami wspierającymi BDD, np. Cucumber, z którego ja będę korzystał, ale to już w kolejnym poście. BDD też można określić jako metodykę nie będącą tak bardzo restrykcyjną jak TDD. Jednak ta różnica jest jak mówiłem bardzo nikła. Wikipedia angielska mówi: „Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.”. Myślę, że lepszej konkluzji się nie znajdzie 🙂

Podsumowanie

I tak o to po raz kolejny z wieczora zrobiła się już w sumie noc. Znów post zamiast krótkiego, będzie miał ok. 1000 słów. Mam nadzieję, że w takim telegraficznym skrócie opisałem Ci, co to jest TDD i BDD oraz dlaczego są one takie przyjemne. W kolejnym poście już popracujemy bezpośrednio nad aplikacją, ale musiałem zrobić ten wstęp, by zachować jakiś porządek logiczny 🙂 Mam nadzieję, że Ci się podobało! Zachęcam do komentowania i poprawiania mnie, jeżeli się mylę 🙂 Chciałem także podziękować mojemu koledze Michałowi, który podesłał mi parę linków i zainspirował do pogrzebania na ten temat 🙂 Dziękuję! 🙂 Tymczasem mówię Ci do zobaczenia, ale przewiń stronę dalej, by poklikać w przydatne linki 🙂 Miłego czytania! 🙂

Przydatne linki

TDD Wikipedia: https://pl.wikipedia.org/wiki/Test-driven_development

O testach na Devstyle.pl: http://devstyle.pl/category/tech/tests/

O TDD u Arkadiusza Benedykta: http://www.benedykt.net/2010/11/07/tdd-czyli-test-driven-development/

BDD Wikipedia: https://en.wikipedia.org/wiki/Behavior-driven_development

Narzędzie Cucumber: https://cucumber.io/

Inne:

http://softwareengineering.stackexchange.com/questions/135218/what-is-the-difference-between-writing-test-cases-for-bdd-and-tdd

http://softwareengineering.stackexchange.com/questions/111837/relation-between-bdd-and-tdd

Zwinnie pracujemy – Agile, Scrum i wszystkie takie dziwne słowa

Oi! (port.)

Witam Cię w tę właściwie już poniedziałkową noc. Zeszły tydzień upłynął pod znakiem targów pracy i innych rewolucji życiowych, dlatego też pojawił się tylko wpis o Inżynierskich Targach Pracy. Ale nadrabiamy zaległości i w tym tygodniu może się uda wypuścić 3 posty, żeby nadrobić zaległości w DSP, a tematów jest cała masa! 🙂 Zaczynamy!

Żeby móc z Wami rozmawiać (tutaj te słowa kieruję do osób, które gdzieś tam zaczynają swoją przygodę z programowaniem, bo ludzie „z branży” na pewno to znają, ale może powstanie jakaś ciekawa dyskusja, do czego zachęcam!) musimy porozmawiać o tzw. zwinnym programowaniu.

Słowo wstępne

Na początku projektu zdefiniowaliśmy sobie pojęcie inżynierii oprogramowania oraz modeli, w jaki sposób można rozwijać oprogramowanie. Założyłem, że na czas trwania konkursu, przyjmę model wodospadowy (ang. waterfall) z możliwością przejścia w model spiralny realizowany przyrostowo. Dlatego też zaczynam od zdefiniowania wymagań i funkcjonalności, które system ma zapewniać oraz zebranie tego w odpowiednich dokumentach. Dla wielu pasjonatów bariera tworzenia dokumentacji jest nie do przejścia (kto by to pisał, sic!), jednak ja uważam, że warto jest to tworzyć, bo życie potem staje się prostsze. Ale tworzyć w sposób mądry.

Oczywiście to o czym będziemy mówili, nie tyczy się tylko tworzenia dokumentacji ale życia całego projektu.

Programowanie zwinne

Z czym kojarzy się słowo zwinny? Słowo zwinny według słownika języka polskiego oznacza skoczny, zwrotny, zręczny, poruszający się sprawnie. A jak odnosi się to do tworzenia oprogramowania? Zwinność ta odnosi się do obserwacji zachowań klienta. Wymagania klienta, funkcjonalności, jakie system ma dostarczać, często ewoluują zmieniają się w czasie trwania samego projektu. Dlatego należy często dokonywać przeglądu wymagań klienta i dynamicznie modyfikować dostarczane oprogramowanie. Programowanie zwinne, z ang. agile software development to zbiór metodyk umożliwiających realizację częstych przeglądów. Metodyki te opierają się na modelu spiralnym i realizacji przyrostowej.

Agile

W 2001 roku zdefiniowano tzw. manifest agile, który zbiera najważniejsze zasady będące sednem idei programowania zwinnego. Są one następujące:

  1. Ludzie i interakcje ponad procesy i narzędzia
  2. Działające oprogramowanie ponad obszerną dokumentację
  3. Współpracę z klientem ponad formalne ustalenia
  4. Reagowanie na zmiany ponad podążanie za planem

Jak można wywnioskować, zwinność polega na złagodzeniu sztywnych więz narzuconych przez określone modele. Lepiej rozmawiać ze sobą, niż wypełniać formularze, lepiej być elastycznym w stosunku do zmieniających wymagań, niż sztywno trzymać się zapisów. Jednak należy zauważyć, że słowo ponad nie znaczy zamiast. Dobry przykład? Działające oprogramowanie ponad obszerną dokumentację – niestety zdarzają się zespoły, które interpretują to jako nie tworzenie dokumentacji w ogóle, co jest oczywistym błędem! Jest to główne nieporozumienie związane z zastosowaniem agile w pracy zespołu. Ten punkt znaczy tyle, że dokumentacja nie ma być książką o 5000 stron, tylko ma zawierać punkty odniesienia, filary projektu, nie dające się wyczytać bezpośrednio z kodu. Zapewnia to jej elastyczność, łatwo się utrzymuje i będzie ona aktualna.

Podstawą do pracowania w ten sposób, jest praca w niewielkich, łatwozarządzalnych grupach ludzi.

Scrum

Scrum jest jedną z metodyk zgodnych z manifestem Agile. Polega na podzieleniu docelowego produktu na mniejsze partie, tak by można było je wykonać w krótkich okresach czasu, tzw. sprintach. Każdy sprint kończy się wydaniem działającej wersji oprogramowania, która może być oddana do użytku, zatem zmiany wprowadzone w każdym sprincie muszą być „klikalne”.

Sprint jest przygotowywany: planowana jest lista wymagań użytkownika, która ma zostać w danym etapie wprowadzona, szacowany jest czas (należy w tym uwzględnić „pożary” na produkcji), planowany jest przebieg sprintu. Ważna jest ciągła współpraca z klientem, co pozwala na rozwój oprogramowania zgodnie z oczekiwaniem. Dobrą praktyką podczas pracy w Scrumie są retrospekcje na koniec sprintu. Dzięki temu programista jest w stanie przemyśleć, co było fajne, co było złe, nad czym trzeba popracować. Ponadto podział projektu na podprojekty realizowane jako sprinty dobrze wpływa na myślenie człowieka – wolimy wykonywać drobniejsze zadania i szybciej się z nich „czyścić”. Ponadto po każdym sprincie zebrany feedback od klienta umożliwia dopracowywanie aplikacji w każdym calu. I w tym momencie możemy zacząć mówić o zarządzaniu zmianą.

Dla klienta ważny jest widoczny rozwój aplikacji, której na początku został wykreślony tylko ogólny kształt. Może on zacząć korzystać z jakiejś części funkcjonalności.

Narzędzia

Ciekawym i bardzo przydatnym narzędziem w pracy z metodyką Scrum są tak zwane daily stand-up meettings. Są to spotkania krótkie, „na stojaka”, trwające 15 – 20 minut, w których każdy członek zespołu opowiada, co udało mu się zrobić dnia poprzedniego, jakie problemy napotkał. Przy czym staramy się opowiadać o funkcjonalnościach, jakie zrealizowaliśmy a nie, że napisałem 3 klasy i 4 interfejsy, bo to nie ma żadnej wartości dla pozostałych członków zespołu i nie pokazuje wymiaru pracy, jaki został ukończony.

Jeżeli chodzi o jakieś narzędzia typowo przeznaczone do wspomagania pracy programistów oraz kierowników zespołów, są to narzędzia klasy ALM (Application Lifecycle Management). Ułatwiają zarządzanie całym cyklem życia oprogramowania: projektowaniem, implementowaniem i utrzymaniem. Przykładami takich narzędzi są Team Foundation Server od Microsoftu albo Jira.

Podsumowanie

Dwa często wymawiane pojęcia, niebywale ważne w dzisiejszym świecie developmentu. Wprowadzenie metodyk zwinnych zmieniło diametralnie podejście do tworzenia oprogramowania. Dzisiaj znakomita większość zespołów pracuje wykorzystując metodyki tego rodzaju, sam pracowałem w zespole Scrumowym (pozdrawiam zespół oprogramowania w dziale badawczo-rozwojowym w Trumpf Huettinger w Zielonce!), co było mega fajnym i uczącym doświadczeniem.

I to chyba tyle wstępu do kolejnego, mega ciekawego w mojej ocenie wpisu, który już się przygotowuje w mojej głowie i mam nadzieję pojawi się bardzo szybko! 🙂 Miłego czytania i zapraszam do komentowania! Dobranoc 🙂