zwinne modelowanie

Teksty związane ze zwinnym modelowaniem (agile modeling)

SCRUM a SCRUM z modelowaniem – koszty

Moim zdaniem wszystkie metodyki zwinne mają tą zaletę, że są tańsze od tradycyjnego ?ciężkiego? podejścia choćby dlatego, że nie traci się czasu na modelowanie. Jest tylko jedno ale. A mianowicie klient musi dokładnie wiedzieć czego chce. Co w sytuacji gdy klient jest grymaśny, zmienia wymagania lub tylko je odrobinę modyfikuje bo jak widzi gotowy produkt […]

SCRUM a SCRUM z modelowaniem – koszty Czytaj dalej »

Wartość modelowania

Budowanie modeli ma ogromną wartość. Zastanawia mnie dlaczego budując dom wymagana jest dokumentacja projektowa a do budowy systemu informatycznego to sprawa opcjonalna. Dokumentacja nie zawsze jest wykonywana a jej potrzeba wynika bardziej ze świadomości zamawiającego produkt niż z wymogów prawa. Ciekawe jest to, że koszt budowy domu jest wielokrotnie niższy niż niejednego systemu informatycznego. Co

Wartość modelowania Czytaj dalej »

Specyfikacja oparta na scenariuszu

Zwinne modelowanie polega miedzy innymi na tym, że budowana dokumentacja do projektu nie jest nadwymiarowa. Innymi słowy jest jej tyle ile potrzeba i nie mniej ani nie więcej. Jak na tym zapanować. Ja osobiście lubię stosować scenariusze (w SCRUM opowiadania klienta), które pozwalają mi na zbudowanie zwinnych przypadków użycia. Natomiast przypadki użycia pomagają mi efektywnie:

Specyfikacja oparta na scenariuszu Czytaj dalej »

Zwinne modelowanie w SCRUM

Scrum to jedna ze zwinnych metodyk w nurcie Agile, stosowaną w procesie wytwórczym oprogramowania. SCRUM jest ukierunkowany na budowę gotowego kodu. Powstaje jednak pytanie co zrobić, gdy potrzebny jest model, lub specyfikacja projektu? Jest na to sposób. Można budować modele zgodnie z  metodyką SCRUM. Na stronie: Modelowanie w SCRUM opisałem zarys SCRUM wraz z kilkoma

Zwinne modelowanie w SCRUM Czytaj dalej »

Zarys Scrum

Zasadnicze cechy SCRUM, w bardzo dużym uproszczeniu, to: iteracyjnie przyrosty wartości samoorganizujące się zespoły klient, bądź Właściciel Produktu, który dostarcza zespołowi listę pożądanych cech W przypadku Scrum projekt postępuje seriami miesięcznych iteracji, które zwane są sprintami. Scrum pasuje idealnie do projektów z szybko zmieniającymi się lub pojawiającymi się wymogami Praca, która ma być wykonana w

Zarys Scrum Czytaj dalej »

Rola: Właściciel produktu (Product Owner)

Właściciel Produktu (ang. Product Owner) reprezentuje interesy wszystkich interesariuszy, określa cechy produktu i ustala hierarchię Product Backloga ? zaległości produktu. Właściciel Produktu ma następujące obowiązki: Określa cechy produktu; Podejmuje decyzje co do daty i zawartości; Jest odpowiedzialny za rentowność produktu (ROI); Ustala hierarchię cech wg wartości rynkowej; Koryguje cechy i priorytety co 30 dni, jeśli

Rola: Właściciel produktu (Product Owner) Czytaj dalej »

Rola: Mistrz Scrum (Scrum Master)

Mistrz Scrum (ang. Scrum Master) odpowiada za zapewnienie tego, aby Zespół Scrum żył wartościami i praktykami Scrum czyli innymi słowy on nadzoruje sposób wykorzystania metodyki. Mistrz Scrum chroni zespół poprzez zapewnienie tego, że nie podejmą oni zbyt wielkich zobowiązań w stosunku do tego, co mogą osiągnąć podczas sprintu. Mistrz Scrum ułatwia Codzienny Scrum i staje

Rola: Mistrz Scrum (Scrum Master) Czytaj dalej »

Rola: Zespół Scrum (Scrum Team)

Zespół Scrum (ang. Scrum Team) buduje produkt, który zostanie wykorzystany przez klienta: przykładowo, oprogramowanie lub witrynę. Zespół w Scrum jest „międzyfunkcyjny” – obejmuje całą wiedzę niezbędną dla dostarczenia w każdym Sprincie produktu będącego potencjalnym wynikiem sprintu – jest „samoorganizujący się” oraz posiada bardzo duży stopień autonomii i odpowiedzialności. Zespół Scrum: Jest międzyfunkcyjny, z mniej więcej

Rola: Zespół Scrum (Scrum Team) Czytaj dalej »

Artefakt: Potencjalnie Wykonalny Przyrost Produktu (Potentially Shippable Product Incremement)

Rezultatem każdego sprintu jest potencjalnie wykonalny przyrost produktu (ang. Potentially Shippable Product Incremement). Za wykonanie tego artefaktu odpowiada Zespół Scrum. Dużo mówi się na temat różnicy między „potencjalnie wykonalnym (zrobionym)” oraz „wykonalnym”. Mike Cohn stwiedza: .. „potencjalnie wykonalne” oraz „wykonalne” to nie to samo. Niektóre duże lub złożone projekty będą wymagać zastosowania „sprintu hartującego” lub

Artefakt: Potencjalnie Wykonalny Przyrost Produktu (Potentially Shippable Product Incremement) Czytaj dalej »

Artefakt: Zaległości produktu (Product Backlog)

Zaległości produktu (ang. Product Backlog) to główny wykaz wszystkich funkcjonalności pożądanych w produkcie. Za dostarczenie zaległości produktu odpowiedzialny jest Właściciel Produktu. Gdy projekt jest inicjowany nie ma wszechstronnego, czasochłonnego wysiłku, aby zapisać wszystkie dające się przewidzieć zadania lub wymogi. Zazwyczaj, projekt zapisuje to, co jest oczywiste, co niemal zawsze wystarcza do pierwszego sprintu. Product Backlog

Artefakt: Zaległości produktu (Product Backlog) Czytaj dalej »

Scroll to Top