Przejdź do głównej zawartości

Posty

Wyświetlanie postów z grudzień, 2017

Klient dobrego analityka nie jest jego panem, a raczej pacjentem. Analiza Biznesowa. Praktyczne modelowanie organizacji.

Dziś kolejna (tak, mogę już napisać, że to kolejna) recenzja. Pomiędzy robieniem paznokci na sylwestra i szykowaniem ekstra kiecki udało mi się znaleźć czas na rzeczy ważne i poważne 😉 czyli czytanie literatury „branżowej”. Myślę, że ta recenzja będzie o tyle ciekawa, że książkę Analiza Biznesowa, Praktyczne modelowanie organizacji czytałam dwa razy w różnych warunkach. Postaram się opisać ją z dwóch perspektyw.      Przed „zakochaniem się” w analizie biznesowej i poznaniu blogowo/książkowego świata Analityków      Po „zakochaniu się” w analizie i poznaniu tego świata troszkę bliżej Ad1. Lektura jak każda inna, trochę teorii zebranej w przyjemnej formie krótkich felietonów, które prowadzą do wspólnych wniosków. Analiza jest potrzebna/ ważna i dzięki niej jesteśmy w stanie zaoszczędzić trochę gotówki 😉 Ad2. Zrozum zanim zaproponujesz rozwiązanie – to hasło przewodnie całej lektury i chyba całej działalności Pana Jarosława. Przed przeczytaniem po ra

Kurs Specjalistów Analizy – Analiza IT Recenzja

Jakiś czas temu na moim ulubionym blogu o Analizie IT pojawił się wpis dotyczący konferencji Request (więcej informacji na temat konferencji znajdziecie tutaj . Prócz standardowych informacji czyli, czego możemy się spodziewać po konferencji, gdzie się odbędzie, kto ją prowadzi itp., itd. pojawiła się informacja o konkursie, który Hania przygotowała dla swoich odbiorców. Wygraną była zniżka na konferencję oraz jeden z produktów, który można znaleźć na stronie Analiza IT . Postanowiłam pomóc szczęściu i wystartowałam w wyżej opisanym wydarzeniu 😊 .  Okazało się, że moja odpowiedź na pytanie konkursowe była na tyle dobra, że trafiłam do wygranej dwójki. Później dostałam maila od Hani, w którym prócz gratulacji, dowiedziałam się jak mogę wykorzystać swoją wygraną i wybrać najbardziej odpowiadającą mi nagrodę. Zdecydowałam się na Kurs Specjalistów Analizy IT. Nie bardzo wiedziałam czego mam się spodziewać, nigdy wcześniej nie uczestniczyłam w kursach e-learningowych, ciężko

Inżynieria Wymagań cz. 1

Dziś kolejna recenzja (no, kolejna to może zbyt szumnie powiedziane- druga recenzja na tym blogu 😉 ) Parę dni temu skończyłam czytać lekturę Pani Karoliny Zmitrowicz  „Analityk Systemów – przygotowanie do egzaminu z inżynierii wymagań” wydawnictwa PWN. We wszelkich opisach, które udało mi się przeczytać, zanim zaopatrzyłam się w książkę można było wysnuć wniosek, że książka będzie rozszerzeniem sylabusa, który znajduje się na oficjalnej stronie dotyczącej certyfikatu REQB Autorka obiecuje, że z książki dowiemy się: Czym jest inżynieria wymagań wg programu REQB i jakie czynności wchodzą w jej skład, Czym są wymagania, jak można je sklasyfikować i jakimi atrybutami powinny się cechować, Jakie miejsce w przedsięwzięciu informatycznym zajmuje inżynieria wymagań i jakie ma znaczenie dla sukcesu projektu, Jak pozyskiwać, analizować, dokumentować wymagania oraz w jaki sposób zapewnić, że są one odpowiedniej jakości, Jaki zakres wymagany jest na egzaminie certyfikowanym

User Stories i Przypadki Użycia na liście 99

Dziś połączymy odpowiedź do trzech pytań z listy 99 😊 Proszę napisać wymganie w formie user stories.  Proszę zapisać wymaganie w formie przypadku użycia. Czym są sytuacje wyjątkowe w opisie przypadków użycia ? No to może zanim zabierzemy się za konkretną odpowiedź, musimy wiedzieć (chociaż tak pokrótce), czym jest User Stories , a czym Use Case . User Stories (US) – inaczej historyjki użytkownika (po angielsku zawsze lepiej to brzmi), są krótką notatką z konwersacji/wywiadu na temat działania systemu. Dzięki User Stories doprecyzowujemy wymagania z rozmowy z klientem. Tylko pamiętajmy, że nie są one po to, aby szukać winnych w razie ewentualnych niedomówień i nie powinny stanowić dowodów w „kwitach” na naszych klientów 😉. [2] User Stories mają w sposób syntetyczny opisywać warunki, jakie powinny zostać spełnione z perspektywy użytkownika i cel, w jakim ta funkcja ma zostać przygotowana.  (definicję tę znalazłam w kursie Specjalistów Analizy )[3]. Ważne jest to,

Wdrażaj i testuj

Na czym polega model V ?   Nie wiem czy gdzieś wcześniej o tym pisałam, ale jestem słuchaczką na studiach „ Analityk, profesjonalista na styku IT i biznesu” gdzie uczę się o swoim wymarzonym zawodzie w super wyidealizowanym środowisku akademickim 😉  W programie przewidziany został przedmiot o wdzięcznej nazwie „Role Analityka” prowadzone przez pana Jerzego Leyka (cudowny człowiek, od którego czerpie mnóstwo inspiracji). To właśnie on ciągle nam kładzie do głowy, że te wszystkie BPMNy, UMLe to jest pikuś w porównaniu do zarządzania ludźmi i próby budowania z nim poprawnych relacji, ale dziś nie o tym 😉 Na dzisiejszym wykładzie omawialiśmy planowanie podejścia analizy biznesowej z wykorzystaniem „metodyk ciężkich”, ja wcześniej spotkałam się z nazwą „metodyki tradycyjne”, ale te „ciężkie” dużo bardziej do mnie przemawiają 😉 Czym, że jest ta „ciężka metodyka” ? A no niczym innym jak dobrze wszystkim znany wodospad, watterfall, kaskada czy jak tam chcecie ją sobie

Najlepszym miernikiem jakości produktu jest zadowolony klient.

Dziś kolejny post z cyklu, zaczytane w portalu zza wielkiej wody 😉 link do całej treści znajdziecie tutaj Artykuł dotyczy …. Empatycznego tworzenia nowych produktów… … tak tak, EMPATYCZNEGO 😊 I już widzę minę każdego programisty/osoby, która bardzo twardo i rzeczowo podchodzi do swoich zadań. Uniesiona brew, wykrzywione w grymas usta wyrażające superdezaprobatę i bajkowa chmura nad głową z wielkim znakiem zapytania i trzema bardzo znaczącymi literami WTF?!   I prawdę mówiąc, mimo, że nie jestem istotą twardo stąpającą po ziemi, to w pierwszej chwili pomyślałam no oni chyba nie mają już o czym pisać na tym „habeerze” 😊 Ale z babskiej ciekawości postanowiłam sprawdzić o co tak naprawdę chodzi i rozwiać to bajkowe chmurzysko 😊 Pomyślmy, czym tak naprawdę zajmuje się analityk ? Pisze opasłe dokumentacje, tworzy diagramy, uzgadnia harmonogramy, wdraża metodyki, organizuje spotkania, analizuje ryzyka, zmiany, zarządza backlogiem,itd., itp., ale to

"Nie musisz zarządzać ryzykiem. Przetrwanie nie jest obowiązkowe!"

Kolejny post z cyklu przygotowań do certyfikatu REQB Coś jest w tym tytułowym cytacie 😉 Czy warto jest analizować ryzyko ? czy w ogóle jest to komuś do czegoś potrzebne ? Mam nadzieje, że większość osób, która czyta to pytanie, odpowie sobie NO JASNE, ŻE TAK! 😉 a skoro już wiemy, że warto to zastanówmy się jak do podejść do tego tematu. Jeśli po raz kolejny w swoim projekcie usłyszysz stwierdzenie, że coś się wywaliło ze znanych wszystkim przyczyn albo czegoś można byłoby uniknąć gdyby… to oznacza, że ktoś nie odrobił poprawnie swoich zadań pracowych – ktoś, a konkretnie Ty Analityku! Ale tak szczerze, z ręką na sercu, pracując w nawale różnych projektów, zadań, zadanek czy ktokolwiek się przejmuje czymś takim jak „ryzyko”. Śmieszki powiedzą „jest ryzyko, jest zabawa” ale myślę, że Biznes nie będzie zadowolony jak przez błąd Pani Analityk (Pana Analityka) straci swoje pieniądze, reputację albo znaczną grupę klientów. Od czego należałoby zacząć? Od Ide

Chodzenie po wodzie i realizacja wymagań są proste tylko w jednym przypadku, jeśli jedno i drugie jest zamrożone!

Dziś trochę o przygotowaniach do certyfikatu z Inżynierii Wymagań REQB. Dlaczego Inżynieria Wymagań ?, bo od tych nieszczęsnych wymagań wszystko się zaczyna. 😉 Źle zdefiniowane wymaganie będzie się mścić przez cały okres trwania projektu, dlatego tak ważne jest, żeby znać i umieć stosować metodyki związane z poprawnym definiowaniem i zarządzaniem wymaganiami. Z pomocą biegnie Inżynieria Wymagań! Uznałam, ze skoro i tak dużo o tym czytam to poprzygotowywuje się do certyfikatu REQB. Egzamin REQB (Requirements Engineering Qualification Board) jest przeznaczony dla osób, które pracują z wymaganiami na systemy informatyczne. Wiedza, którą należy posiadać, aby móc podejść do egzaminu obejmuje  Sylabus znajdujący się na stronie reqb.pl Zagadnienia, z którymi możemy się „spotkać” w trakcie egzaminu to: Podstawy inżynierii wymagań Proces inżynierii wymagań Pozyskiwanie wymagań Analiza i modelowanie wymagań Specyfikacja i opis wymagań Walidacja wymagań Zarz