5 wskazówek dla analizy w ujęciu AGILE

Scrott Ambler kilkanaście miesięcy temu opublikował 5 wskazówek, które powinny usprawnić analizę w ujęciu AGILE Oto one:

1. Aktywny udział osób zainteresowanych jest najbardziej istotny
Musisz ściśle współpracować z osobami zainteresowanymi w celu szczegółowego zgłębienia domeny biznesowej. Osoby zainteresowane powinny dostarczać informacji, modelować wraz z Tobą, dostarczać opinie i w odpowiedniej chwili podejmować decyzje.

2. Tworzenie oprogramowania zgodnie z metodą agile to proces ewolucyjny

Kiedy modelujesz analitycznie podczas projektu agile, zazwyczaj skupiasz się na małym podzestawie wymogów naraz. Na przykład, w przypadku projektu XP, Ty i Twój partner od programowania możecie pracować razem z udziałowcem projektu w celu przeanalizowania pojedynczej user story, jednej z setek, a następnie przejść do jej zaprojektowania i wdrożenia. Taka analiza zazwyczaj zabiera kilka minut, w zależności od natury user story, tyle samo zabiera projektowanie. Następnie spędzasz klika godzin na wdrażaniu wymogu tylko po to, aby móc zacząć od nowa z nową user story. Inne podejścia agile, jak np. Feature-Driven Development  mogą wymagać nieco więcej czasu dla analizy i projektowania, ale i tak będą działać w ten sam, ewolucyjny sposób.

3. Analiza nie jest etapem

Analiza to coś, co musisz robić codziennie jako programista agile, ponieważ pracujesz w sposób ewolucyjny. Wymaga to pracy wraz z osobami zainteresowanymi, a także z innymi programistami, co pozwala na zrozumienie istoty problemu zawsze, kiedy tego potrzebujesz. Analizą może być tak prosta czynność jak zapytanie udziałowca „Co miałeś tutaj na myśli?” lub tak skomplikowana, jak narysowanie kilku diagramów z celu zbadania aspektów tego, co budujesz. Jest to o wiele bardziej nieformalne niż proces formalny wymagający otwartej i szczerej komunikacji.

4. Liczne modele
Efektywni programiści zdają sobie sprawę z tego, że każdy rodzaj modelu ma swoje mocne i słabe strony; dlatego też muszą od razu zastosować odpowiedni model(e) do danego zadania. Ponieważ tworzenie oprogramowania jest sprawą złożoną, szybko zdasz sobie sprawę z tego, że potrzebna Ci wiedza na temat szerokiego zakresu modeli, abyś mógł być wydajny.

5. Zazwyczaj potrzeba jedynie podzestawu modeli

Pomimo tego, że dostępnych jest wiele technik modelowania, faktem jest, że każdy zespół ds. projektu będzie potrzebował jedynie podzestawu. Pomyśl o tym w ten sposób: W domu, w swojej skrzynce na narzędzia, masz duży zbiór śrubokrętów, kluczy francuskich, kombinerek, itp. Na potrzeby dokonania danej naprawy będziesz potrzebował jedynie kilku z tych narzędzi – różne prace, różne narzędzia. Nigdy nie potrzebujesz wszystkich narzędzi naraz, ale z czasem użyjesz ich wszystkich na różne sposoby.

Technorati Tagi: agile,agile modeling,modelowanie,UML,Unified Modeling Language
Podobne wpisy
UML – zastosowanie w biznesie

Po raz kolejny Centrum Promocji Informatyki zorganizowało seminarium związane z wykorzystaniem języka UML w biznesie. W tym przedsięwzięciu miałem swój więcej

Software Project Management GigaCon

Trzecia edycja konferencji Software Project Management GigaCon (25-26 września) to kolejna okazja na wymianę w szerszym gronie zagadnień związanych z więcej

Rational Unified Process – Wstęp

Rational Unified Process jest zunifikowanym procesem wytwórczym oprogramowania dostarczającym praktycznych wskazówek, wzorców dokumentów i narzędzi, szablonów dokumentów oraz przykładów postępowania więcej

Modelowanie systemów informatycznych w języku UML 2.1

Włodzimierz Dąbrowski, Andrzej Stasiak, Michał Wolski Seria: W praktyce Wydawnictwo Naukowe PWN Warszawa, 2007 r. ISBN: 978-83-01-15251-2 Wydanie: pierwsze Objętość: więcej

Reklama
MODESTO - licencje Enterprise Architect
Scroll to Top