Przynajmniej raz w życiu, ale najprawdopodobniej więcej razy, trafialiście do nowego projektu. Macie nowych kolegów i koleżanki, nowego szefa i nowy nieznany wam projekt. Projekt trwa już jakiś czas i może okazać się, że sporo o nim trzeba się dowiedzieć, by w ogóle zacząć coś robić. Jeśli tak jak ja zajmujecie się zbieraniem i analizą wymagań to pewnie dostaniecie zadanie zebrania wymagań do jakiegoś nowego rozszerzenia projektu lub będziecie pomagać w rozwiązywaniu bieżących problemów. Czego byście nie robili, będziecie potrzebować wiedzy o projekcie, o celach biznesowych, o często pojawiających się problemach i tematach. Będziecie potrzebowali poznać kontekst tego, o czym rozmawia się w projekcie. Będzie do Was przychodzić szef pytając kiedy skończycie wykonywać powieżone Wam zadanie, będą przychodzić z pytaniami o to jak coś ma działać koledzy zajmujący się implementacją czy testowaniem. Musicie więc wiedzieć i to wiedzieć jak najszybciej. Tylko pytanie jak...? Jesteście najkrócej w projekcie, reszta kolegów pracuje tu rok, dwa czy dłużej. Być może ostatnio zajmowaliście się czymś z zupełnie innej beczki. Do tego często bywa tak, że musicie starać się o dostęp tu i tam, brakuje dokumentacji, a logika biznesowa i sposób działania obecnego projektu są zagmatwane.
Czy to wszystko brzmi znajomo? Jeśli tak to zapraszam do wypróbowania modelowania eksploracyjnego. Ponieważ jako odkrywca znaleźliście się na nowym niezbadanym terenie to czas zacząć szkicować mapę. W naszym przypadku, zbierania wymagań dla oprogramowania, mapą będą use case'y, task case'y, user stories, diagramy Warnier'a, model danych, słownik danych i inne używane przez Was metody modelowania. Chodzi o to, by zamiast zgłębiać wszystko na co natraficie zacząć pracować dla siebie i projektu.
Często rozproszenie informacji i brak adekwatnej dokumentacji powoduje, że człowiek czyta materiały które:
Zamiast studiować wszystko postawcie sobie cel stworzenia aktualnego modelu dla istniejących funkcjonalności. Najlepiej dla obszaru systemu, nad którym będziecie pracować. Poproście swojego szefa o wyznaczenie obszaru do przeanalizowania i spisania wymagań. Wasza nauka będzie polegała na pracy w projekcie a konkretnie na modelowaniu eksploracyjnym. Będziecie zgodnie ze swoją najlepszą wiedzą o projekcie i wymaganiach tworzyć use case'y czy task case'y dla konkretnej funkcjonalności systemu, a następnie weryfikować poprawność swojego myślenia z kolegami i koleżankami z projektu. Inaczej mówiąc będziecie musieli wszystkim dookoła pokazywać, co wiecie o projekcie. Wasza wiedza stanie się dobrze widoczna dla innych, a co za tym idzie, poprawi się znacznie jej jakość. Jednocześnie możecie okazać się pierwszym solidnym pracownikiem, który wiedzę plemienną scalił i zapisał. Pomoże to w przyszłości innym w szukaniu informacji.
Sam proces modelowania czy to przy pomocy use case'ów, task case'ów czy user stories ukierunkuje waszą naukę. Będziecie szukać konkretnych informacji i badać konkretny fragment systemu. Będziecie oczywiście popełniać błędy ale jak mówi ludowy optymizm: 'nie myli się tylko ten, który nic nie robi'. Pisząc use case'y macie możliwość obrania odpowiedniego poziomu szczegółowości. Dzięki temu poznacie i zapiszecie kontekst dla funkcjonalności jaką się zajmujecie. Znajomość kontekstu sprawi, że będziecie mogli komunikować się z kolegami w skrócony sposób (restricted communication), bez konieczności rozwijania w pełni każdej myśli (elaborated communication). Dzięki znajomości kontekstu będziecie wiedzieć czego dotyczą rozmowy w projekcie.
Pisząc use case'y będziecie zmuszeni do poznania ról (aktorów) odgrywanych przez użytkowników, a co za tym idzie lepiej zrozumiecie funkcjonujący system uprawnień w systemie. Pisząc use case'y czy task case'y zrozumiecie cele i zadania jakie mają użytkownicy oprogramowania. Natomiast, jeśli natraficie na zagmatwaną logikę, która jest chyba zawsze obecna w większości systemów informatycznych, to możecie ją łatwiej opanować i jednocześnie być może uprościć rysując dla niej diagram Warnier'a (patrz wcześniejszy wpis).
Modelowanie ma tą cudowną właściwość, że potęguje możliwości ludzkiego umysłu, a w szczególności pozwala na uniknięcie problemów z pamięcią krótkotrwałą, która pozwala na jednoczesne przechowanie około siedmiu informacji. Modelowanie pozwala na komunikację z innymi ludźmi na temat złożonych zagadnień. Pokazując komuś model zagadniania, dajemy mu możliwość odniesienia się do naszego rozumienia tego zagadnienia. Można następnie włączyć poprawki w oparciu o inną niż nasza perspektywę. Modelowanie pozwala na znajdowanie dróg na skróty i tworzenie eleganckich rozwiązań. Tak więc nauka poprzez modelowanie pozwoli Wam na wzbogacanie Waszego rozumienia o sposób rozumienia innych.
Jeżeli będziecie mieć konkretny problem do omówienia, to koledzy będą mogli łatwiej Wam pomóc. Dzięki temu zintegrujecie się szybciej z zespołem i dowiecie kto się czym zajmuje i w czym jest ekspertem. Zrobicie też coś pożytecznego, co pozwoli się Wam wykazać. Więcej znajdziecie w internecie pod hasłem 'exploratory modeling'.
Czy to wszystko brzmi znajomo? Jeśli tak to zapraszam do wypróbowania modelowania eksploracyjnego. Ponieważ jako odkrywca znaleźliście się na nowym niezbadanym terenie to czas zacząć szkicować mapę. W naszym przypadku, zbierania wymagań dla oprogramowania, mapą będą use case'y, task case'y, user stories, diagramy Warnier'a, model danych, słownik danych i inne używane przez Was metody modelowania. Chodzi o to, by zamiast zgłębiać wszystko na co natraficie zacząć pracować dla siebie i projektu.
Często rozproszenie informacji i brak adekwatnej dokumentacji powoduje, że człowiek czyta materiały które:
- nie są już prawdziwe
- są wyrwane z kontekstu
- są niekompletne
- odnoszą się do części systemu nad którą nie będziecie pracować
Zamiast studiować wszystko postawcie sobie cel stworzenia aktualnego modelu dla istniejących funkcjonalności. Najlepiej dla obszaru systemu, nad którym będziecie pracować. Poproście swojego szefa o wyznaczenie obszaru do przeanalizowania i spisania wymagań. Wasza nauka będzie polegała na pracy w projekcie a konkretnie na modelowaniu eksploracyjnym. Będziecie zgodnie ze swoją najlepszą wiedzą o projekcie i wymaganiach tworzyć use case'y czy task case'y dla konkretnej funkcjonalności systemu, a następnie weryfikować poprawność swojego myślenia z kolegami i koleżankami z projektu. Inaczej mówiąc będziecie musieli wszystkim dookoła pokazywać, co wiecie o projekcie. Wasza wiedza stanie się dobrze widoczna dla innych, a co za tym idzie, poprawi się znacznie jej jakość. Jednocześnie możecie okazać się pierwszym solidnym pracownikiem, który wiedzę plemienną scalił i zapisał. Pomoże to w przyszłości innym w szukaniu informacji.
Sam proces modelowania czy to przy pomocy use case'ów, task case'ów czy user stories ukierunkuje waszą naukę. Będziecie szukać konkretnych informacji i badać konkretny fragment systemu. Będziecie oczywiście popełniać błędy ale jak mówi ludowy optymizm: 'nie myli się tylko ten, który nic nie robi'. Pisząc use case'y macie możliwość obrania odpowiedniego poziomu szczegółowości. Dzięki temu poznacie i zapiszecie kontekst dla funkcjonalności jaką się zajmujecie. Znajomość kontekstu sprawi, że będziecie mogli komunikować się z kolegami w skrócony sposób (restricted communication), bez konieczności rozwijania w pełni każdej myśli (elaborated communication). Dzięki znajomości kontekstu będziecie wiedzieć czego dotyczą rozmowy w projekcie.
Pisząc use case'y będziecie zmuszeni do poznania ról (aktorów) odgrywanych przez użytkowników, a co za tym idzie lepiej zrozumiecie funkcjonujący system uprawnień w systemie. Pisząc use case'y czy task case'y zrozumiecie cele i zadania jakie mają użytkownicy oprogramowania. Natomiast, jeśli natraficie na zagmatwaną logikę, która jest chyba zawsze obecna w większości systemów informatycznych, to możecie ją łatwiej opanować i jednocześnie być może uprościć rysując dla niej diagram Warnier'a (patrz wcześniejszy wpis).
Modelowanie ma tą cudowną właściwość, że potęguje możliwości ludzkiego umysłu, a w szczególności pozwala na uniknięcie problemów z pamięcią krótkotrwałą, która pozwala na jednoczesne przechowanie około siedmiu informacji. Modelowanie pozwala na komunikację z innymi ludźmi na temat złożonych zagadnień. Pokazując komuś model zagadniania, dajemy mu możliwość odniesienia się do naszego rozumienia tego zagadnienia. Można następnie włączyć poprawki w oparciu o inną niż nasza perspektywę. Modelowanie pozwala na znajdowanie dróg na skróty i tworzenie eleganckich rozwiązań. Tak więc nauka poprzez modelowanie pozwoli Wam na wzbogacanie Waszego rozumienia o sposób rozumienia innych.
Jeżeli będziecie mieć konkretny problem do omówienia, to koledzy będą mogli łatwiej Wam pomóc. Dzięki temu zintegrujecie się szybciej z zespołem i dowiecie kto się czym zajmuje i w czym jest ekspertem. Zrobicie też coś pożytecznego, co pozwoli się Wam wykazać. Więcej znajdziecie w internecie pod hasłem 'exploratory modeling'.