KORDIALNE

Pełna wersja: Techniki tworzenia oprogramowania
Aktualnie przeglądasz uproszczoną wersję forum. Kliknij tutaj, by zobaczyć wersję z pełnym formatowaniem.
1.UML
Cytat:Czym jest UML

UML to akronim pochodzący od angielskiego określenia Unified Modeling Language. W polskim tłumaczeniu znany jest jako zunifikowany język modelowania. UML to jasno wyspecyfikowany język składający się z kilkunastu diagramów. Diagramy te pozwalają na formalne opisywanie i modelowanie struktur czy procesów.
https://www.samouczekprogramisty.pl/podstawy-uml/


2.Agile


Cytat:Agile – zwinne podejście do pracy. Skąd się to wzięło?

O „agile” i „zwinnym” podejściu do prowadzenia projektów słyszeli już chyba wszyscy. Ale czy wszyscy mają świadomość historii jaka stoi za sformułowaniem zasad z tym związanych? Prawdopodobnie nie – dla tych osób krótko opiszemy, jak to wszystko wyglądało.

Idea „agile” została stworzona w 2001 roku przez grupę programistów, którzy spotkali się w kurorcie narciarskim, w górach Utah. Ich celem, oprócz rozrywki i dobrze spędzonego czasu, było przeprowadzenie dyskusji na temat zmiany podejścia do procesu tworzenia oprogramowania. Potrzeba była podyktowana tym, że biznes miał trudności z dogadaniem się ze specjalistami rzeźbiącymi w kodzie; czas tworzenia aplikacji był mocno rozciągnięty w czasie, zmiany w technologiach następowały bardzo szybko, frustracja rosła a projekty często nie dochodziły do skutku lub kończyły się dostarczeniem rozwiązania, które już było przestarzałe w porównaniu z produktami konkurencji. Konieczne stało się znalezienie sposobu na tworzenie oprogramowania, uwzględniającego wiele zmiennych oraz takiego, które pozwoliłoby na szybsze wyprowadzenie aplikacji na rynek.

Problem zdiagnozowano jako złe podejście do samego prowadzenia projektu – zmiany należało zacząć „od podstaw” czyli już na etapie planowania pracy. Do tej pory (czyli do pamiętnego wyjazdu w góry) tworzenie oprogramowania rozpisywano i prowadzono tak, jak np. budowanie domu czy wprowadzanie nowego jogurtu na rynek. Odgórnie rozpisywano harmonogram prac, dzieląc projekt na następujące po sobie etapy – bez realizacji jednego, nie można było przejść do kolejnego; od razu także szacowano koszty i przydzielano konkretny budżet do wykorzystania; klient musiał zatem przekazać wszystkie wymagania licząc się z tym, że dodatkowe zmiany wprowadzą chaos i będą trudne do zrealizowania. Takie podejście (nazywane kaskadowym, ang. Waterfall) w przypadku projektów o wielu zmiennych, które trudno przewidzieć po prostu się nie sprawdziło.

Luty 2001r. okazał się krokiem milowym prowadzącym do zmiany sposobu pracy zespołów developerskich. Po burzliwych rozmowach, 17stu programistów doszło do porozumienia, w wyniku którego powstał: Manifesto for Agile Software Development, czyli spis 12 zasad i ogólnej idei zwinnego podejścia do prowadzenia projektów programistycznych.

Od tamtej pory minęło już prawie 20 lat, w czasie których powstało mnóstwo publikacji na temat agile, aplikacje ułatwiające prowadzenie projektów tą metodyką, vlogi, podcasty, kursy, szkolenia, certyfikaty – idea została z powodzeniem wdrożona w wielu firmach ułatwiając realizację projektów; jej skuteczność i rosnącą popularność dobrze prezentują m.in dane z raportu z 2019 roku:
Twórcy idei agile wyróżnili 12 głównych zasad, które określają podstawowe założenia tego sposobu pracy. Poniżej umieszczamy najważniejsze założenia każdej z nich wraz z krótkim rozwinięciem:
 
[list=1]
[*]Najważniejsze jest zadowolenie klienta, który otrzymuje szybkie wdrożenie systematycznie udoskonalanego oprogramowania – zwinne podejście musi iść w parze z dostarczaniem wysokiej jakości usług i realizacją wymagań klienta; zmiana podejścia do prowadzenia projektu miała na celu lepsze porozumienie ze zleceniodawcą, sprawniejszą współpracę i jaśniejszą komunikację oraz możliwość szybkiego pokazania efektów pracy.
[*]Bądź otwarty na zmiany, nawet na późnym etapie projektu – branża technologiczna zmienia się bardzo dynamicznie, dlatego zmiany są konieczne do pozostania „up-to-date” jeśli chodzi o wymagania rynkowe; drugą kwestią jest to, że  klient często dopiero po zobaczeniu pierwszych efektów jest w stanie doprecyzować swoje oczekiwania. Metodyka agile została stworzona w opozycji do sztywnych ram podejścia kaskadowego (waterfall).
[*]Systematycznie dostarczaj kolejne części systemu; im częściej to robisz tym lepiej  – dzięki temu klient może szybko przekazać informacje, które posłużą do udoskonalenia aplikacji i usprawnią prace nad projektem.
[*]Biznes i zespoły programistów muszą ze sobą współpracować – i nie chodzi o sporadyczny kontakt, a o regularną, ścisłą współpracę dzięki czemu każda ze stron jest zaangażowana w projekt i wie o bieżących działaniach. Konieczne jest zniesienie podziałów między zespołami, ponieważ blokują one kreatywną współpracę specjalistów różnych dziedzin.
[*]Twórz projekty wokół zmotywowanych jednostek, wspieraj je, ufaj im i dostarczaj tego, czego potrzebują do realizacji projektu – każdy projekt, zwłaszcza długotrwały i wymagający dużego nakładu pracy (a właśnie takimi cechami charakteryzują się projekty deweloperskie), potrzebuje zaangażowanego kierownika; ktoś kto nie będzie „czuł” projektu, być może poprowadzi go poprawnie ale z pewnością nie wykorzysta w pełni możliwości i potencjału zespołu.
[*]Najlepszym sposobem na przekazywanie informacji jest rozmowa twarzą w twarz – trudno się nie zgodzić! Maile i komunikatory są wspaniałym udogodnieniem, jednak kontakt osobisty zawsze pozostawia najlepsze wrażenie i jest najbardziej owocny.
[*]Działające oprogramowanie to podstawowa miara postępu prac – efekty zawsze wyznaczają rezultaty, a nie sam proces. Metodyka agile, choć wyróżnia się elastycznym podejściem, kładzie równie duży nacisk na realizację zadań, co tradycyjne podejście.
[*]Procesy zwinne wspierają zrównoważony, trwały rozwój. Sponsorzy, programiści i użytkownicy powinni wypracować stałe tempo działania – ta zasada odnosi się do zespołów zaangażowanych w projekt; dzięki działaniu iteracyjnemu (iteracja to jeden cykl pracy obejmujący wprowadzenie, testowanie i ulepszanie jakiegoś fragmentu programu), zespół bardzo szybko i na wczesnych etapach uczy się na swoich błędach, wyciąga odpowiednie wnioski i sprawnie przechodzi do kolejnych elementów; nie jest zalecana zmiana obowiązków poszczególnych osób czy podzespołów, ponieważ wprowadza to dezorganizację i spowolnienie postępów.
[*]Nieustanne skupianie się na doskonałości rozwiązań pod kątem technicznym oraz na dobrym projekcie, wzmacnia zwinność – metodyka zwinna kładzie mocny nacisk na rozwój zespołu pracującego nad projektem, wymaga zaangażowania, poszukiwania nowych metod rozwiązywania problemów i udoskonalania oprogramowania; każda iteracja to kolejna, cenna lekcja i dążenie do dobrze działającego rezultatu końcowego.
[*]Prostota to sztuka minimalizowania koniecznej pracy, (po angielsku brzmi to znacznie lepiej) Chodzi o to, aby nie komplikować rozwiązań i nie kombinować za bardzo tam, gdzie nie jest to potrzebne; dana funkcjonalność ma działać – im prościej możemy ją wdrożyć, tym lepiej, szybciej i sprawniej.
[*]Najlepsze rozwiązania pochodzą od samoorganizujących się zespołów – ta zasada zwraca uwagę na sposób komunikacji z zespołami odpowiedzialnymi za poszczególne elementy; to zespoły mają być zaangażowanie w swoje zadania; mają samodzielnie szukać rozwiązań, wprowadzać zmiany konieczne do efektywniejszej pracy – kierownik projektu czuwa nad całością ale nie narzuca zespołom jak mają pracować.
[*]Dzięki regularności pracy, zespół stale się rozwija, staje się bardziej efektywny, dostosowuje się do zmieniających się wymagań; wyciąga wnioski i odpowiednio zmienia swoje podejście – rozwój, rozwój, rozwój!
[/list]Podstawy metodyki zwinnej wcale nie są tak łatwe, proste i przyjemne jak mogą się wydawać; mimo prostych założeń ich wdrożenie bywa bardzo trudne. Kluczową rolę odgrywa tu tzw. czynnik ludzki. Przypominanie sobie tych 12 wyznaczników będzie pomocne nie tylko na początku organizowania zespołów i pracy w podejściu zwinnym, ale także w każdym trudniejszym momencie współpracy.
https://ttpsc.com/pl/blog/agile-metodyka-zwinna/


3.Scrum


Cytat:Co to jest scrum? Jak pracuje się w metodyce scrum? Definicja scrum.

Scrum to metodologia projektowa określająca zasady działania zespołów tworzących nowy produkt. Scrum powiązany jest z Agile, gdyż daje on narzędzia do zwinnej pracy. Podejście to ma swój początek w IT, więc często produktem, który jest tworzony przy pomocy metodyki scrum jest oprogramowanie. Produktami mogą być tak naprawdę dowolne rzeczy, które wytwarzane są zespołowo. Scrum skupia się na samoorganizacji zespołu oraz dostarczaniu coraz to lepiej dopracowanych projektów.
Cytat:Czym jest scrum team, jakie są role w scrum?
Metodyka scrum oparta jest na pracy zespołu, w którym każda osoba ma różne kompetencje uzupełniane przez innych. 
Product owner
Osobą, która zna produkt najlepiej i odpowiada za niego, jest product owner. Zbiera on informacje na temat wymagań i oczekiwań, aby utworzyć product backlog. Jest to nic innego jak zbiór zadań, elementów, które zawiera nasz produkt. Lista ta uporządkowana jest od zadań najważniejszych do zadań najmniej ważnych. Hierarchia zadań ustalana jest przez product ownera. Lista zawiera tzw. cel produktu, który określa najważniejszą rzecz.
Deweloperzy, scrum sprint
Następną grupą są deweloperzy, którzy odpowiadają za projektowanie, programowanie, analitykę oraz wytwarzanie produktu. Zespół spotyka się na tzw. spotkaniu planowania sprintu (sprint planning), na którym z listy wybierają zadania, które są w stanie zrobić w ciągu kolejnego cyklu pracy. W efekcie powstaje sprint backlog, który jest zbiorem zadań, które dostarczymy w trakcie trwania danego sprintu. Sprint to cykl czasowy, który ustalamy na wykonanie naszych zadań. Zazwyczaj jest to okres od 1 do 4 tygodni. Sprint daje product ownerowi gwarancję, że wie co dzieje się z produktem. Sprint posiada także swój cel (sprint goal), który określa, co product owner chce osiągnąć w danym sprincie. Wszystkie zadania sprintu powinny zostać ukończone zgodnie z definicją ukończenia, aby uniknąć niezgodności. 
Daily standup
Podczas wykonywania zadań ważne jest, aby miał miejsce daily standup. Jest to spotkanie pod koniec każdego dnia, na którym omawiany jest postęp prac, jaki jest plan, nad czym pracujemy oraz jakie problemy ewentualnie napotkaliśmy. Jest to bardzo ważna część pracy nad projektem – robiąc codziennie spotkania unikniemy opóźnienia. Podczas sprintów obydwa się także porządkowanie backlogu produktu, na który zespół poświęca 5-10% czasu sprintu. 
Scrum master – kto to tak naprawdę jest? Obowiązki i zadania scrum mastera
W każdej pracy potrzebny jest ktoś, kto będzie odpowiedzialny za pilnowanie zasad oraz członków zespołu, aby ci pracowali w konkretny, zaplanowany wcześniej sposób. Odpowiedzialny za to jest scrum master, czuwa on nad backlogiem, sprintami oraz daily standupami. Pomaga on zespołowi pracować według nowej metody, kształtując nawyki.
Przegląd sprintu
Każdy sprint kończy się przeglądem sprintu, podczas którego zespół pokazuje, co stworzył podczas danego sprintu oraz zbiera feedback od klienta. Na podstawie tych informacji product owner decyduje o dalszym przebiegu prac, aktualizując backlog. Końcowym punktem jest retrospekcja sprintu, czyli wyciąganie wniosków. W spotkaniu biorą udział product owner, deweloperzy oraz scrum master, podsumowując co poszło dobrze, co źle, a nad czym warto byłoby popracować w kolejnym sprincie. Celem tego spotkania jest to, aby kolejny sprint był wydajniejszy, lepszy oraz żeby zespół pracował lepiej.
https://leanpartner.pl/scrum/