Siema, każdy tak ostatnio zachwyca się, jaki ten agile jest świetny i w ogóle. A ja mam inne pytanie. Jak to wygląda w praktyce. Tzn. zaczynając od początku. Sprinty powinny być krótkie - tydzień do miesiąca. Ale zaczynając nowy system, rzadko kiedy jest szansa, że nawet w miesiąc stworzy się jakąś działającą wersję. Jak to powinno wyglądać?
0
1
Nie tworzy się całego systemu na raz, tylko dzieli na zadania, a tych w miesiąc już można trochę napisać. Przynajmniej tyle, by jakąś pierwszą wersję jakiegoś ekranu pokazać użytkownikowi.
A zachwycają się wielbiciele buzzwordów i management, nikt inny.
0
Zależy co robisz. Jeśli system bankowy to może być ciężko.
Ale idealnie by było, żeby oddawać coś po tygodniu. Jak napisano wyżej - podzielić na kawałki i oddawać kawałki.
To już abstrahując od Agile - klient zawsze lepiej patrzy na produkt który może używać już po tygodniu.
Agile to nie jest coś ostatnio modnego. Ta koncepcja ma już 16 lat! Prawie tyle co C#.
To jaki jest najmojszy Agile to już inna rzecz. Może być taki że "wrzućmy kod na svn i zobaczmy ile testów się wysypie", może być taki że klientowi oddajemy co x dni kolejne funkcjonalności (działające). Ja jestem bardziej za tą drugą koncepcją, niezależnie jak to się nazwie.
0
Ja również się zachwycam Agilem :)
Celem sprintu wcale nie musi być działająca aplikacja którą można komuś pokazać.
Agile kompletnie zmienił podejście do wytwarzania oprogramowania, aczkolwiek wielu programistów sobie z tego nie zdaje sprawy i utożsamia jedynie Agile ze Scrumem, przez co możesz spotkać sporą ignorancję w tym temacie :P
0
Czyli wystarczy, jak np. po tygodniu pokażę klientowi jakieś okienko np. do wprowadzania danych? Ale faktycznie to będzie tylko samo gui bez warstwy biznesowej ani danych?
1
Jak to już zauważono - Agile != Scrum.
Samo słowo Agile oznacza metodyki lekkie, tj. takie które kładą nacisk na iteracyjność procesu wytwórczego i minimalizację okładu na komunikację. Co samo w sobie jest całkiem OK.
Problemy się zaczynają gdy dojdziesz do Scruma i jego korporacyjnych mutacji. Jeśli o mnie chodzi to jedyną zaletą Scruma jest daily. Cała reszta, czyli bzdety w stylu "cały zespół jest odpowiedzialny za całość", "samoorganizacja zespołu", "Scrum master to nie PM" itp. to korporacyjne hasełka, które bardziej przeszkadzają niż pomagają.
0
OK, to w takim razie jak to jest z tym scrumem?
3
neves napisał(a):
Agile kompletnie zmienił podejście do wytwarzania oprogramowania, aczkolwiek wielu programistów sobie z tego nie zdaje sprawy i utożsamia jedynie Agile ze Scrumem, przez co możesz spotkać sporą ignorancję w tym temacie :P
Nie programistów tylko managerów, scrum masterów, agile coachy i innych tasiemców. Oraz oczywiście klientów, bo jak ktoś im rzuci hasło, że wszystko trzeba robić "agile", bo to rozwiąże problemy z nieudanymi projektami, to wszyscy w to wierzą. W efekcie jest wzajemnie nakręcająca się spirala głupoty, na której zarabiają jedynie firmy szkoleniowe.
Programiści są agile sami z siebie i nie potrzebują do tego żadnych korporacyjnych procesów ani nadzorców.
Juhas napisał(a):
Czyli wystarczy, jak np. po tygodniu pokażę klientowi jakieś okienko np. do wprowadzania danych? Ale faktycznie to będzie tylko samo gui bez warstwy biznesowej ani danych?
W ekstremalnym przypadku, jeśli nie wyrobisz się z ukończeniem całości, to będzie musiało wystarczyć
Ogólnie chodzi o to, żeby nie zamykać się z projektem na 5 lat, a po tym czasie pokazać klientowi gotowe coś, co w ogóle nie jest zgodne z jego zamysłem. Agile ma na celu ciągłą współpracę z klientem, zbieranie jego opinii (dlatego często trzeba coś dostarczać, żeby móc tą opinię zwrotną dostać) i poprawianie softu na bieżąco.
Tylko, że agile jest jak komunizm - teoretyczna utopia, która w praktyce nie ma prawa działać. Po pierwsze dlatego, że nie jest to zgodne ze sposobem pracy waterfallowych klientów obarczonych ciężką biurokracją, a po drugie dlatego, że firmy programistyczne, które zamiast dobrać narzędzia do projektu, dopasowują projekt do narzędzi sprawiają, że żadnej zwinności w tym nie ma.
0
somekind napisał(a):
neves napisał(a):
Agile kompletnie zmienił podejście do wytwarzania oprogramowania, aczkolwiek wielu programistów sobie z tego nie zdaje sprawy i utożsamia jedynie Agile ze Scrumem, przez co możesz spotkać sporą ignorancję w tym temacie :P
Nie programistów tylko managerów, scrum masterów, agile coachy i innych tasiemców. Oraz oczywiście klientów, bo jak ktoś im rzuci hasło, że wszystko trzeba robić "agile", bo to rozwiąże problemy z nieudanymi projektami, to wszyscy w to wierzą. W efekcie jest wzajemnie nakręcająca się spirala głupoty, na której zarabiają jedynie firmy szkoleniowe.
Programiści są agile sami z siebie i nie potrzebują do tego żadnych korporacyjnych procesów ani nadzorców.
I to jest właśnie przykład ignorancji osoby która utożsamia Agile wyłącznie z zarządzaniem procesem wytwarzania oprogramowania jakim jest chociażby scrum.
Agile powstał jako odpowiedź na największy problem wytwarzania oprogramowania w modelu kaskadowym : zmiany. Agile akceptuje to że "zmiana" jest nieodłącznym elementem w świecie IT i wysuwa ją na pierwszy plan, oferując wiele różnych rzeczy które mają tę idee wzmocnić.
Jednymi z tych rzeczy są rozmaite praktyki programistyczne, które zostały swego czasu przez Becka zebrane i nazwane jako "programowanie ekstremalne", a których zbiegiem czasu pojawiło się coraz więcej. Więc to że teraz w naszej codziennej pracy piszemy testy jednostkowe, programujemy w parach, mamy ciągłe integracje i wiele innych rzeczy to zasługa właśnie popularyzacji idei Agile. Więc jak najbardziej my programiści czerpiemy z tej idei pełnymi garściami!
Scrum natomiast jest jedynie szczegółem implantacyjnym Agilu w odniesieniu do zarządzania procesem wytwarzania oprogramowania. I, tak, głównie, dotyczy mangmentu, ale proces wytwarzania oprogramowania to gra zespołowa, w której bierze udział znacznie więcej osób niż tylko programiści.
1
Jest takie powiedzenie - w teorii teria działa. Podbnie jest z Agile/Scrum/XP... W teorii wszystko fajnie. W praktyce sprowadza sie to czesto do DDD - Demo Driven Development, czy SDD - Stand Up Driven Development, czyli myslenie dlugoterminonowe zostaje poswiecone po to by miec szybka, widoczna zmiane. Co z tego ze kosztem jakosci?
Chociaz z punktu widzenia klienta jest to czesto dobre bo moze szybko modyfikowac system. Sa modele biznesowe gdzie wystarczy ze system z grubsza dziala, jesli 95% przypadkow jest ok, to zamiast naprawiac pozostale 5 czassami bardziej sie oplaci dolozyc cos co zwiekszy dochod. Do tego kontakt bezposrednio z klientem pomimo ze potrafi byc stresujacy, dziala dobrze na zrozumienie tego co jest dla klienta wazna i co tak naprawde jest potrzebne. Dla managementu tez jest dobre ze szybko widac jak ktos slabo pracuje.
A dolozmy do tego jeszcze AgileFalla (Agile nalozony na waterfalla, czyli pracujemy w waterfallu tyle ze zamiast rozliczac sie co milestone robimy to codziennie/co tydzien i mamy czestsze wrzutki bo w koncu Agile jest po to bysmy byli dynamiczni).
Testy automatyczne, CI itp. Super. Tylko jest sporo projektow gdzie tego nie ma i nie bedzie (bo trzeba by bylo charytatywnie po nocach siedziec).
A juz w ogole koszmarem jest robienie testow integracyjnych dla kilkunastu zespolow agilowych (zwlaszcza majac AgileFalla). Sporo ludzi uwaza ze w Agile dokumentacja jest opcjonalana...
Prawda jest to co @somekind napisal. Jak jest dobry zmotywowany zespol to sie sam zorganizuje, komunikacja bedzie dzialac projekt pojdzie do przodu. Nie trzeba ani biczownika do poganiania ani niczego narzucac.
Oczywiscie podbno istnieje gdzies mityczny, dzialajacy idealny Agile... Ale to co sie spotyka bardziej przypomina mi Frankensteina.