Teksty związane ze zwinnym modelowaniem (agile modeling)
Ostatnio zaniedbałem wpisy dot. moich działań szkoleniowych i konsultingowych. Stało się to przede wszystkim przez produkty: MANEA (MANEA – Mantis Bug Trucker i Enterprise Architect) oraz TORMIGO (Tormigo wersja beta), oraz brak czasu związany ze wspomnianymi działaniami. Zacznę od ostatnich większych projektów, których wspólnym mianownikiem jest branża ubezpieczeniowa. W jednej firm zajmowałem się przygotowaniem a […]
Wakacyjne działania Czytaj dalej »
Kilka dni temu w tekście: Zwinne modelowanie w Visual Studio 2010 pisałem o możliwości modelowanie za pomocą UML w VS 2010. Teraz czas na drugą z mojego punktu widzenia ważna zmianę. Otóż w MSF for Agile Software Development v5.0 jaki towarzyszy VS 2010 uwzględniono zwinne modele a proces wytwórczy kodu oparto o SCRUM. Więcej informacji
MSF for Agile Software Development v5.0 Czytaj dalej »
Jest rewolucja. I to nie mała. Otóż firma Microsoft w ramach Visual Studio z premedytacją omijała aspekt wizualnego projektowania sytemu przy użyciu UML. Aż do teraz. W nowej wersji VS 2010 jest VS2010 Visualization and Modeling Feature Pack (http://msdn.microsoft.com/en-gb/vstudio/ff655021.aspx), dzięki któremu można wytwarzać modele na różnym poziomie abstrakcji i w konsekwencji synchronizować je z kodem
Zwinne modelowanie w Visual Studio 2010 Czytaj dalej »
Iteracyjny model wytwarzania oprogramowania by był bardziej skuteczny wymaga kilku zabiegów. Chodzi oto by w ujęciu agile być rozważnym i skutecznym. Stosuję je podczas zwinnego modelowania. Oto kilka z nich: Krócej znaczy lepiej. Iteracja nie powinna być dłuższa niż 4 tygodnie, w przeciwnym wypadku możesz wpaść w styl tworzenia oprogramowania mini-waterfall. Osobiście preferuję jedno lub
Iteracje w Agile Modeling Czytaj dalej »
Zwinny model to taki który jest: Wystarczający dla Odbiorców czyli w zależności od odbiorców ogólny gdy rozmawiasz z biznesem lub bardziej techniczny gdy rozmawiasz z IT Wystarczająco dobry, aby przekazać sens. Model nie musi być dokładny. Gdy pojawia się niezgodność zastanów się co z tym zrobić. Może wystarczy dekompozycja może notka. Zawsze poproś odbiorcę diagramu
Zwinne modele – charakterystyka Czytaj dalej »
Co zrobić w sytuacji gdy do wykonania danej funkcji, opisanej przez przypadek użycia, potrzeba w tym samym momencie więcej niż jednego aktora? Czy można pokazać to na diagramie przypadków użycia? Otóż nie. Diagram przypadków użycia nie definiuje nam tego kto w jakiej sytuacji, w jakim momencie korzysta z danej funkcji. Relacja aktor – przypadek użycia
Przypadek użycia i działanie aktorów w tym samym czasie Czytaj dalej »
Właściwym podejściem do definiowania przypadków użycia dla tworzenia oprogramowania przy użyciu metody agile to zacząć od definicji zakresu. Definicje zakresu można opisać za pomocą diagramów WPA (Wysokiego Poziomu Abstrakcji) Kiedy już zakres zostanie zdefiniowany należy zdefiniować nazwy przypadków użycia a następnie stopniowo nadawać priorytety i definiować bardziej szczegółowo przypadki użycia podczas gdy są one włączane
Agile a tworzenie przypadków użycia Czytaj dalej »
Z racji tego, że publikacja odnośnie zwinnego podejścia w zakresie modelowania procesów biznesowych (WMB) ?pisałem o tym kilka dni temu w tekście pt ?Krajowa Konferencja Inżynierii Oprogramowania?- ukazała się w limitowanej edycji 150 egzemplarzy pozwalam sobie na publikację skanu tego tekstu. W M B View more documents from Michał Wolski. Podobne wpisy Zintegrowane środowisko wytwarzania
KKIO 2009 – tekst Czytaj dalej »
User story to opis celów zorientowanych na użytkownika, jakie jedna lub więcej osób osiągnie za pomocą Twojego produktu. User stories używa się do osiągnięcia celu zawsze wtedy, kiedy jest osoba obsługująca interfejs . User story pisze się w formacie Jako [osoba odgrywająca daną rolę] chcę [wykonać jakąś czynność] aby [osiągnąć jakiś cel]. W ten sam
Pisanie user story i scenariuszy przypadków użycia Czytaj dalej »
Długość iteracji i jej wielkości pod względem zasobów musi być skorelowana z celami i pracą, które ma być wykonana. Moje wytyczne: Wielkość zespołu – większe zespoły wprowadzają większe koszty stałe i tym samym prowadzą do dłuższej iteracji. Następujące wytyczne zapewniają przydatny punkt wyjścia: 2 – 15 osób: iteracja 2-4 tygodniowa 16 – 30 osób: iteracja
Wielkość i długość iteracji Czytaj dalej »
