Zwinne wytwarzanie oprogramowania Scrum i Kanban

Zwinne wytwarzanie oprogramowania (Agile Software Development) na dobre zagościło w polskich firmach. Obecnie mało, w której nie stosuje się jakiegoś “zwinnego” procesu  wytwarzania oprogramowania. Dlaczego tak się dzieje? Dlaczego firmy odchodzą od tradycyjnych metod prowadzenia projektów na rzecz bardziej elastycznych lub je łączą? Powodów jest wiele. A więc od początku.

W 2001 roku powstał manifest zwinności, który obecnie brzmi “Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywamy lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkładamy:

  • Ludzi i interakcje ponad procesy i narzędzia.
  • Działające oprogramowanie ponad obszerną dokumentację.
  • Współpracę z klientem ponad formalne ustalenia.
  • Reagowanie na zmiany ponad podążanie za planem.

Doceniamy to, co wymieniono po prawej stronie, jednak bardziej cenimy to, co po lewej.

Od tego się zaczęło. Od tamtego czasu powstało wiele odmian metodyk zwinnych takich jak XP (Extreme programming), Crystal Clear, Scrum i inne. Jednakże dopiero Scrum został tak szeroko przyjęty przez programistów i organizacje. Tzw. “wdrożenie” Scruma nie jest łatwe, gdyż zmienia on sposób myślenia i funkcjonowania nie tylko samego działu deweloperskiego, ale i całej organizacji. Scruma możemy wykorzystywać stale w procesie wytwarzania oprogramowania lub w przypadku wyjątkowo ważnych projektów, które charakteryzują się dużą zmiennością, ograniczonym czasem i obarczonych dużym ryzykiem.

Zacznijmy od najważniejszego: ludzi. Scrum składa z trzech ról: właściciela produktu (Product Owner), zespołu oraz Scrum Mastera. Właściciel produktu reprezentuje osoby zainteresowane produktem np. sponsor, zarząd, dział sprzedaży, itd. Ustala on priorytety i odbiera wytworzone produkty. Zespół deweloperski jest odpowiedzialny za wykonanie zadań i ponosi grupową odpowiedzialność za ich realizację. Zespoły budujemy w zależności od czekających nas zadań tak, aby znaleźli się w nim specjaliści o kompetencjach umożliwiających wykonanie zleconych im zadań. Scrum Master jest rolą odpowiedzialną za realizowanie całego procesu scrumowego i “ochronę” jego przed próbami łamania zasad. Ta rola nie jest ani Team Leaderem ani Project Managerem.

Zobaczmy jak wygląda proces wytwarzania oprogramowania w Scrumie:

  • Planowanie (Sprint Planning), spotkanie inicjujące, które składa się z dwóch części. Pierwsza część to prezentacja przez product ownerów zadań do wykonania, celów, priorytetów, itd. Druga część to analiza przez zespół programistyczny czasochłonności, trudności wykonania, możliwej do zastosowania technologii lub architektury. Wynikiem tego jest Sprint Backlog – lista zadań wybrana na jeden sprint z Product Backloga.
  • Codzienne spotkania (Daily Scrum lub Daily Standup), krótkie kilkuminutowe spotkania członków zespołu, zazwyczaj w godzinach porannych. Każdy z zespołu odpowiada na 3 pytania, co zrobił wczoraj, co zrobi dzisiaj i czy są tematy, które blokują jego pracę.
  • Przegląd sprintu (Sprint Review) to spotkanie pod koniec każdego sprintu, gdzie zespół oddaje wykonaną pracę w postaci działającego produktu.
  • Analiza sprintu (Sprint Retrospective) to spotkanie, na którym możemy omówić, co się nie udało podczas tego sprintu, co należy poprawić, itd. Bardzo ważne spotkanie, które często jest pomijane ze względu na brak czasu (spotkanie można realizować np., co drugi lub trzeci sprint, ale nie wolno pomijać jego zgodnie z procesem samodoskonalenia).

Zatem jak “wdrożyć” Scruma w kilku krokach:

  • Podziel ludzi na małe zespoły (kilku osobowe w zależności od skali organizacji i projektów) posiadających w sobie różne kompetencje.
  • Wyznacz rolę właściciela projektów lub zadań (Produkt Owner) oraz Scrum Mastera.
  • Podziel zadania lub projekty na mniejsze zadania, ustal z Product Ownerami ich priorytety i oszacuj potencjalny czas ich realizacji, zrób z tego kolejkę lub listę zadań (Product Backlog).
  • Wyznacz czas jednego sprintu (czas, w którym będziemy pracowali a na koniec jego oddawali zlecone zadania) zależnie od skali zadań od jednego do kilku tygodni.
  • Rozpocznij sprint zgodnie z procesem opisanym wyżej.

Co daje nam Scrum? W teorii są to: łatwość reagowania na zmiany i łatwość realizacji zadań, zwiększona produktywność i jakość, szybsze reagowanie na pojawiające się ryzyka, wcześniejsze uzyskiwanie półproduktów, poprawę komunikacji pomiędzy biznesem a działami IT, większe zaangażowanie całej organizacji w prace rozwojowe, zmniejszenie kosztów realizacji projektów i jeszcze kilka innych. Oczywiście jest to tylko teoria i wszystko zależy od ludzi i chęci zmiany aktualnej rzeczywistości w organizacji.

Czym jest Kanban i w czym może nam pomóc? Kanban wywodzi się z systemów produkcyjnych, głównie z branży motoryzacyjnej. Pozwala śledzić postępy prac nad poszczególnymi produktami na liniach montażowych. Kanban należy do tzw. systemów “ciągnionych” (pull), które różnią się od systemów “pchanych” (push) realnym zapotrzebowaniem na wytwarzanie niż z góry wytyczoną polityką produkcji. Proces wytwarzania oprogramowania może zostać porównany z linią montażową w hali produkcyjnej, dlatego Kanban idealnie nadaje się, jako technika sygnalizacyjna przy zarządzaniu realizacją zadań czy projektów.

Wszystkie zadania poruszają się zgodnie z przepływem (flowem) w jednym kierunku (np. z lewa do prawa) i przechodzą przez kolejne etapy (np. analiza, implementacja, testowanie, wdrożenie, itd.) . Każdy z etapów posiada określone zasoby (pracownicy o odpowiednich umiejętnościach) oraz możliwość przerobu (ilość możliwej do wykonania pracy w tej samej jednostce czasu). Dzięki takiemu podejściu szybko widzimy, na jakim etapie znajdują się zadania, gdzie mamy ograniczenia oraz co musimy zrobić, aby zwiększyć przerób, czyli produkcję oprogramowania.

Kanban posiada kilka podstawowych zasad:

  • Wizualizacja – stworzenie i rozrysowanie (na tablicy lub za pomocą oprogramowania) procesu wytwarzania oprogramowania ze statusami działań np. analiza, wytwarzanie, testowanie, wdrażanie, zadania skończone.
  • Limit pracy w toku (WIP – Work in Progress) – nie możemy pracować nad większą liczbą zadań niż jesteśmy w stanie wykonać w tej samej jednostce czasu oraz jeśli nie dostaliśmy zlecenia na wykonanie pracy przez jednostkę zlecającą. Jest to zasada wywodząca się z systemów “ciągnionych” (pull).
  • Zarządzanie strumieniem – monitorowanie i raportowanie o etapach wykonywania zadań, prędkości i płynności wykonywania zadań. Idealny proces charakteryzuje się dużą prędkością wykonywania zadań i płynnością oraz przewidywalnością.


Jak zacząć? Zastosowanie Kanbana jest bardzo proste. Poniżej kilka kroków, jakie należy uczynić, aby móc sprawnie zarządzać zadaniami w procesie wytwarzania oprogramowania.

  • Rozrysuj aktualny proces wytwarzania oprogramowania np. na tablicy lub dużej powieszonej na ścianie kartce papieru. Kolumny będą oznaczały kolejne elementy procesu.
  • W pierwszej kolumnie (np. nazwanej listą zadań, backlog-iem lub wish listą) umieść karteczki z zadaniami. Powstanie kolejka zadań. Nadaj im priorytety. Podziel zadania na kategorie zadań np. błędy, zadania, poprawki, itd.
  • Nazwij kolejne kolumny np. analiza, programowanie, testowanie, wdrażanie i zadania skończone.
  • Określ możliwy przerób na każdym etapie (tzw. WIP) np., jeśli posiadamy jednego testera to możemy przyjąć, że na etapie testowania będziemy mogli równocześnie testować tylko jedno zadanie.
  • Podziel oznaczone już etapy (kolumny) na dwa statusy: w trakcie, skończone.
  • Zacznij działać. Pobieraj zadania z kolejki zgodnie z możliwościami przerobu (WIP). Przesuwaj zadania zgodnie ze zmianami statusów do lewa do prawa, aż do kolumny zadania skończone (wdrożone).

Co dalej? Kanban pozwala na analizę czasu potrzebnego na wykonania zadań. Dzięki takiej wiedzy i grupowaniu zadań nie musimy szacować czasochłonności wykonania zadań a określać wielkość zadań za pomocą prostych miar np. duże, małe, średnie. Zaoszczędzi to nam bardzo dużo czasu na estymację, która i tak będzie błędna. A co w przypadku pisania oprogramowania dla klienta zewnętrznego? Tutaj warto przyjrzeć się połączeniu Scruma i Kanbana, co zrobimy w dalszej części. Kanban pozwala wykrywać wąskie gardła w procesie od pojawienia się pomysłu, aż do wdrożenia oprogramowania. Często wąskie gardła znajdują się poza procesem wytwarzania oprogramowania np. w dziale biznesowym, który jest odpowiedzialny za testy akceptacyjne wytworzonych produktów.

Kanban pozwala zmniejszyć skutki wielozadaniowości poprzez stosowanie limitów WIP. Pozwala to na zajmowanie się zadaniami, które w rzeczywistości mają wysoki priorytet i które możemy rzeczywiście wykonać w jednej jednostce czasu.

Proces wytwarzania powinien charakteryzować się też płynnością wykonywania zadań. Monitorujmy zatem  i udoskonalajmy wszystkie elementy procesu. Pozwoli to w przyszłości do osiągnięcia dużej prędkości wytwarzania oprogramowania, unikania wąskich gardeł i nie tracenia cennego czasu.

Kolejne kroki? Mamy już działający Scrum. Widzimy także tablicę Kanbana. Jak to teraz połączyć i co dzięki temu zyskamy? Scrum działa w określonych okresach czasu tzw. iteracjach. Kanban to zmienia mówiąc, że zasoby są wolne i domagają się otrzymania kolejnych zadań. Praca w Scrumbanie zaczyna przypominać taśmociąg, który pracuje niezależnie od okresu czasu. Dzięki takiemu podejściu możemy wykonać więcej zadań niż w typowym sprincie. Możemy także mniej uwagi przywiązywać do estymacji czasu wykonania a bardziej bazować na priorytetach i kolejce. W praktyce w niedługim czasie zobaczymy, że wykonujemy więcej zadań niż pracując w typowym Scrumie.

Jakie są różnice pomiędzy Scrumem a Scrumbanem? Nie ograniczamy się do sprintu. Bierzemy pierwsze zadanie z kolejki. Tablica Kanbana może być stosowana dla wielu zespołów a także dla całych firm. W przypadku tablicy Scruma, korzysta z niej tylko zespół scrumowy. Jak widzimy tablica Kanbana poprawia komunikację i poszerza wiedzę o innych zadaniach i projektach wykonywanych przez inne zespoły, niekoniecznie informatyczne. W Scrumbanie nie patrzymy na wykres spalania (burndown chart) a bardziej na czas wykonania zadania. A co z codziennymi spotkaniami, sprint planningiem czy sprint review? Polecam kontynuowanie codziennych stand-upów, planowanie tylko wtedy, kiedy jest to potrzebne, a przeglądy regularnie, co kilka tygodni w z góry ustalonym terminie. Zachęcam do eksperymentowania i procesu ciągłego doskonalenia. Jestem też zwolennikiem adoptowania najlepszych elementów z różnych metodologii do istniejącej organizacji np. elementów Scruma, Princa2, PMI, CCPM lub Kanbana.

Zobacz naszą ofertę doradczą:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Metodyka rozwoju oprogramowania DevOps

Nazwa DevOps pochodzi od słów „development” czyli wytwarzanie oprogramowania i „operations” czyli operacje, eksploatacji systemów. Metodyka DevOps ma połączyć światy wytwarzania, testowania, wdrażania, administrowania i utrzymania, często inne, o innych celach i kompetencjach. Kładzie ona nacisk na komunikację pomiędzy działem utrzymania (administratorami systemów) oraz programistów i testerów oprogramowania.

Włączenie administratorów do rozwoju oprogramowania ma ewidentne zalety:

  • Pozwala na szybsze wdrażanie zmian „na produkcję” dzięki czemu biznes osiąga więcej korzyści np. częstsze wdrożenia zmian w platformie eCommerce (sklep internetowy) lub na platformie SaaS
  • Pozwala na lepsze wykorzystaniu posiadanych zasobów serwerowych i obniżeniu kosztów
  • Zwiększa wydajność i bezpieczeństwo systemów obniżając koszty utrzymania.

Metoda DevOps wykorzystuje szeroko zdalne narzędzia do komunikacji pomiędzy członkami zespołu jak wiki, wideokonferencje, czaty, itd. Dlatego bardzo dobrze sprawdza się w okresie pandemii wirusa corona Covid-19.

Metodyka i inżynierowie DevOps lubą pracować ze zwinnymi metodykami wytwarzania oprogramowania (Agile np. Scrum) czy z środowiskami chmurowymi (np. Microsoft Azure, Google GCP, Amazon AWS).

Metodyka DevOps pozwala na lepsze zarządzania cyklem życia aplikacji (oprogramowania), gdzie już w fazie planowania przewidujemy przyszłość i rozwój systemu w kolejnych latach.

Zobacz także:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Metody rozliczeń za projekty z dostawcami (Software House)

Usługi informatyczne można podzielić na usługi łatwo wycenialne jak np. na sprzęt komputerowy, licencje czy usługi SLA oraz usługi trudniej wycenialne jak tworzenie aplikacji czy integracji.

Dlaczego tak trudno wycenić fix stworzenie aplikacji? Ponieważ zespół wykonawczy (programiści, project manager, itd. ) nie otrzymują „książki” z opisanymi szczegółowo wymaganiami. Proces zbierania wymagań i ulepszenia produktu jest tworzony w trakcie kodowania (developmentu) i jest obecnie jego częścią. Dlatego dużo zależy od zespołu biznesowego, który jest odpowiedzialny za odpowiedni „wsad” dla zespoły wykonawczego.

Metody rozliczeń z dostawcami (dział wewnętrzny, Software House, itd.):

  • Wycena Fix Price – wycena z góry ustalona za wykonanie usługi. Dobra metoda i tania, jeśli mamy dobrze zdefiniowany zakres zrozumiały dla dostawcy oraz klienta. Ważne jeśli ta usługa jest wykonywana przez dostawce wielokrotnie, więc może też poprzez porównanie być wyceniana. Metoda Fix Price jest wykorzystywana w tradycyjnych metodach zarządzania projektami tzw. Waterfall.
  • Wycena Time & Material – wycena z ustaloną stawką godzinową lub dzienną, kiedy zakres nie jest ustalony szczegółowo. Płacimy do momentu kiedy dostawca zrealizuje usługę. Wycena Time & Material jest podstawą zarządzania projektami z metodykach zwinnych Agile np. w Scrum.
  • Capped Time & Material – metoda pracy jak w Time & Material jednakże z górnym ograniczeniem budżetu narzuconym przez klienta. W przypadku jego przekroczenia dostawca zrealizuje resztę usług w ramach zadeklarowanego budżetu bez konieczności dopłat (chyba, że zakres się zwiększa i jest ustalony i zaakceptowany przez kienta).

Zobacz naszą ofertę na Project Management – wsparcie klientów w kluczowych projektach.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Audyt procesów zarządzania projektami

Cel audytu procesów zarządzania projektami: ocena dojrzałości oraz rekomendacje optymalizujące w obszarze zarządzania projektami (portfelem projektów) lub zarządzania Biurem Projektów.

Zakres audytu procesów zarządzania projektami:

  • Audyt procesów zarządzania pojedynczym projektem
  • Audyt metodyk i technik zarządzania projektami
  • Audyt obszarów ryzyk zarządzania projektami
  • Audyt rozliczania projektów
  • Audyt procesów zarządzania portfelem projektów
  • Audyt systemów informatycznych i narzędzi wspierających projekty
  • Audyt lesson learned
  • Audyt posiadanych kompetencji zespołu zarządzania projektami
  • Audyt kosztów zarządzania projektami
  • Audyt wykonawców oraz umów z nimi
  • Audyt Biura Projektów – organizacji, procesów, procedur, dokumentacji, systemów IT, monitorowania i raportowania
  • Audyt przykładowych projektów
  • itd.

Zobacz naszą ofertę na:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 150-ciu zadowolonych klientów

Konferencje, szkolenia, warsztaty – Startupy, Business, Przemysł 2014-2020

Od 2013 roku wspieramy biznes w doradztwie także poprzez organizację warsztatów, szkoleń czy organizowaniu lub współtworzeniu konferencji. Poniżej podsumowanie naszych szkoleń i konferencji. Zapraszamy do kontaktu w przypadku zainteresowania.

Nasze szkolenia i konferencje dla Startupów, Biznesu i Przemysłu 2014 – 2020

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Project Management kluczowych projektów

Jak nadzorować kluczowe projekty tele-informatyczne? Co zrobić aby zminimalizować ryzyko dodatkowych kosztów oraz przesunięć czasowych?

Projekty można podzielić na kilka kategorii. W tym wpisie podzielimy je na kluczowe z punktu widzenia biznesu, bez których nie da się zrealizować strategii biznesowej i pozostałe pomocnicze. Kluczowe projekty są związane głównie z ambitnymi planami i strategią. Muszą być skutecznie zrealizowane aby firma mogła się rozwijać, aby była przed konkurencją, itd.

Kluczowe elementy powodzenia strategicznych projektów

  • Precyzyjnie określony cel i zakres projektu
  • Zdefiniowane procesy biznesowe
  • Znajomość architektury technologicznej, wymiany danych, integracji, etc.
  • Budżet projektu
  • Umocowanie osób prowadzących projekt w strukturze organizacyjnej (np. raportowanie Project Managera do Członka Zarządu)
  • Wypracowana metodyka projektowa i raportowania np. Scrum
  • Odpowiednio dobrany dostawcy
  • Odpowiednio skonstruowane umowy z dostawcą także w zakresie utrzymania systemu
  • Stały tygodniowy nadzór nad projektem, raportowanie odchyleń od planu, wprowadzanie zmian, usuwanie ograniczeń, etc.
  • Zespół testowy zarówno biznesowy jak i techniczny

GoTechnologies wspiera klientów w kluczowych projektach w następujących zakresach:

  • Analiza procesów biznesowych
  • Wybór systemów klasy CRM, EPR, MES, SCADA, Marketing Automation, eCommerce, TLS, WMS, etc.
  • Wsparcie przy analizie przedwdrożeniowej
  • Definiowanie zapytań ofertowych na systemy
  • Doradztwo architektoniczne i wymiany danych pomiędzy systemami
  • Interim Project Manager – osoba wspierająca wewnętrzny zespół projektowy raportująca i odpowiadająca za realizację projektu
  • Rekomendacje dostawców i rozwiązań tele-informatycznych
  • Doradztwo przy tworzeniu umów z dostawcami oraz negocjacje.

Zobacz naszą ofertę wsparcia w Zarządzaniu Projektami oraz wyboru systemów i dostawców klas ERP, CRM, etc.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 150-ciu zadowolonych klientów

Jaką wybrać metodykę do prowadzenia projektu?

Co to jest metodyka projektowa i czym ona różni się od metodologii? Metodyka jest to ustandaryzowane podejście stosowane do rozwiązywania problemów lub prowadzenia projektów. Metodyka skupia się na metodach realizacji zadań szczególnie na metodach zarządzania. Przykładem może być metodyka zarządzania projektami Prince2. Metodyka w odróżnieniu od metodologii odpowiada na pytanie „Jak to należy zrobić”, metodologia natomiast „Co należy zrobić”.

Jakie metodyki, frameworki czy techniki możemy zastosować przy prowadzeniu projektu? W przypadku zarządzania projektami (Projekt Management) możemy skorzystać z najpopularniejszych, czyli Prince2, PMBOK (PMI) lub ze Scruma. W przypadku zarządzania portfelami projektów (Project Portfolio Management) możemy skorzystać z P3O (Portfolio, Programme and Project Offices) lub PMO (Project Management Office).

Zacznijmy zatem od Prince2. Prince2 jest wyśmienitą metodyka zarządzającą na poziomie strategicznym np. przy wykonywaniu projektów dla administracji rządowej lub dużych projektów budowlanych. Metodyka ta kładzie silny nacisk na procesy zarządzania takie jak zarządzanie ryzykiem, jakością, konfiguracją produktów oraz na planowanie przez produkty. Prince2 definiuje 8 procesów:
• Strategiczne zarządzanie projektem (Directing a project).
• Planowanie (Planning).
• Uruchamianie Projektu / Przygotowanie Założeń Projektu (Starting up a project)
• Inicjowanie projektu (Initiating a project)
• Sterowanie Etapem (Controlling a stage)
• Zarządzanie Wytwarzaniem Produktów (Managing product delivery)
• Zarządzanie Zakresem Etapu (Managing stage boundaries)
• Zamykanie Projektu (Closing a project)

Z uwagi na to, że Prince2 koncentruje się na poziomie strategicznym należy go stosować z innymi metodykami lub procesami operacyjnymi np. w etapie wytwarzania oprogramowania np. ze Scrumem lub z wykorzystaniem analizy ścieżki krytycznej.

PMBOK (A Guide to the Project Management Body of Knowledge) jest zbiorem najlepszych praktyk wykorzystywanych razem z innymi metodykami lub frameworkami. Posiada szerszy zakres niż Prince2 i rozszerza zarządzanie projektami m.in. o obszary operacyjne. PMBOK opisuje najlepsze praktyki w 9 obszarach:

• Zarządzanie integracją projektu (Project Integration Management)
• Zarządzanie zakresem projektu (Project Scope Management)
• Zarządzanie czasem w projekcie (Project Time Management)
• Zarządzanie kosztem projektu (Project Cost Management)
• Zarządzanie jakością w projekcie (Project Quality Management)
• Zarządzanie zasobami ludzkimi w projekcie (Project Human Resource Management)
• Zarządzanie komunikacją w projekcie (Project Communications Management)
• Zarządzanie ryzykiem w projekcie (Project Risk Management)
• Zarządzanie zamówieniami w projekcie (Project Procurement Management)

PMBok jest wielką skarbnicą wiedzy na temat zarządzania projektami, a opisane w nim techniki mogą być stosowane zarówno z Prince2 jak i w połączeniu z metodami zwinnymi np. Scrumem. Warto przeanalizować opisane lub zasygnalizowane tam metody lub techniki takie jak łańcuch krytyczny (Critical Path Method) czy analiza PERT. Warto także przeanalizować inne techniki zasygnalizowane w PMBOK-u takie jak metoda Zarządzania Łańcuchem Krytycznym (Critical Chain Project Management – CCPM). Jest to dość ciekawa technika wywodząca się z Teorii Ograniczeń (Theory of Constraints). Charakteryzuje się obcinaniem czasu projektu o połowę w zamian za tworzenie bufora całościowego.

Kolejnymi metodami, które warto zastosować w praktyce są tzw. metodyki zwinne. Metodyki te lub frameworki są stosowane już bezpośrednio w procesie wytwarzania oprogramowania. Idealnie nadają się w tym etapie i dlatego mogą być stosowane razem z metodykami „wyższego rzędu” np. z Princem2 lub technikami opisanymi w PMBOK-u. Do najpopularniejszych metodyk zwinnych należy Scrum. Został on szerzej opisany w rozdziale 1.6. Jaką zatem metodykę najlepiej stosować? Odpowiedz jest zależna od naszej wiedzy, od dojrzałości projektowej organizacji i od typu projektu. Warto jednak zastanowić się nad stosowaniem elementów Prince2, technik PMBOK w obszarze strategicznym (grupy projektowe, raportowanie, budżetowanie, kontrola jakości, zarządzanie ryzykiem, itd.) oraz w obszarze operacyjnym nad zastosowaniem Scruma. Połączenie technik z tych metodyk daje nam idealny proces zarządzania projektami oraz wytwarzaniem oprogramowania dostosowanym do projektu i organizacji. Warto eksperymentować i stosować techniki najlepiej pasujące do naszej organizacji i rodzaju projektu.

Jeśli potrzebujesz wsparcia w kluczowych projektach, poszukujesz zewnętrznych project managerów (Interim Project Manager, Outsourcing Project Managerów) skontaktuj się z nami. Wspieramy duże przedsiębiorstwa  oraz małe startupy w prowadzeniu projektów, wykładamy zarządzanie projektami m.in. na Akademii Leona Koźmińskiego.

Zobacz także: Doradztwo IT / Consulting Digital Transformation:

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 150-ciu zadowolonych klientów

Zarządzanie projektami: Jak skutecznie zebrać wymagania biznesowe?

Wymagania biznesowe wraz z  wymaganiami systemowymi  tworzą kompleksowe wymagania końcowego produktu. Zbieranie wymagań biznesowych jest jednym z najważniejszych i zarazem najtrudniejszych etapów projektu. Może decydować o sukcesie lub porażce każdego projektu.

Co to jest zarządzanie wymaganiami? Zarządzanie wymaganiami jest niezbędne podczas prowadzenia każdego projektu. Proces może składać się z kilku etapów w zależności od etapów projektu. Pierwszy etap jest odpowiedzialny za zebranie wymagań biznesowych oraz systemowych. Daje nam to szkic wymagań odnośnie docelowego systemu. Dzięki temu możemy stworzyć listę wymagań funkcjonalnych opisanych w specyfikacji wymagań. Taki dokument zaakceptowany przez wszystkie strony uczestniczące w analizie jest podstawą do dalszych prac nad szczegółowymi funkcjonalnościami. Proces zbierania wymagań nazywany jest Analizą Wymagań.

Jak wygląda kompleksowy proces zbierania wymagań dla każdego produktu? Pierwszym krokiem jest zebranie wymagań biznesowych. Drugim krokiem jest zebranie wymagań od użytkowników, którzy będą korzystać z danego produktu. Tutaj bardzo częstą metodą zbierania wymagań są przypadki użycia (use case). Kolejnym krokiem jest sporządzenie szczegółowej listy wymagań funkcjonalnych, wymagań jakościowych lub niefunkcjonalnych (np. odnośnie bezpieczeństwa, bezawaryjności, dostępności, itd. ) . To wszystko tworzy dokument wymagań względem oprogramowania często określany, jako SRS (Software Requirements Specification).

              Jak wykonać analizę wymagań biznesowych? Przy analizie wymagań możemy skorzystać z wielu technik lub metod np. z Business Analysis Body of Knowledge stworzonej przez International Institute of Business Analysis. Najbardziej popularnymi technikami analizy są burze mózgów, analizy aktualnej dokumentacji lub procesów biznesowych, wywiady, obserwacja, prototypowanie czy warsztaty. Wybór techniki lub ich łączenie zależy od projektu, skomplikowania, czasu, itd.

              Jak dokumentować wymagania biznesowe podczas analizy? Przy spisywaniu wymagań biznesowych warto skorzystać z takich narzędzi jak mapy myśli (mind maps), diagramy przypadków użycia użycia (use case), czy narzędzi do modelowania procesów biznesowych (Business proces modelling).

              Jakie są najczęstsze błędy analiz biznesowych? Dobra analiza może decydować o porażce lub sukcesie projektu. Zawarte w niej informacje muszą jednoznacznie opisywać wymagania oraz co się oczekuje od wykonawcy. W większości przypadków wymagania są niejednoznaczne a możliwości interpretacji dość duże. Przypomnijmy wymagania powinny być kompletne i spójne oraz powinny jednoznacznie opisywać, co chcemy osiągnąć.

              Jak priorytetyzować wymagania? Możemy posłużyć się prostą skalą opisową np. Wysoki, Średni, Niski, skalą liczbową np. od 1 do 5 lub w oparciu o metodę MoSCoW charakteryzującą się skalą Must (musi być), Should (powinien być), Could (może być), Would lub Won’t (może być lub nie musi być). Priorytet najwyższy powinny mieć wymagania wdrażane w pierwszej kolejności, najważniejsze z punktu widzenia biznesu, najniższy wymagania, bez których system może istnieć i bez których możemy skończyć projekt w założonym czasie.

             Jak zarządzać wymaganiami podczas trwania projektu? Należy posiadać proces zarządzania zmianami w projekcie (Change Management) zarówno jak stosujemy metodyki typu Prince2 czy techniki zwinne. Proces zarządzania zmianami w projektach informatycznych zostanie opisany w kolejnych cyklach artykułów o zarządzaniu projektami.

Zobacz naszą ofertę wsparcia w Zarządzaniu Projektami oraz wyboru systemów i dostawców klas ERP, CRM, etc.

Zapraszamy do kontaktu:

pfederowicz@gotechnologies.pl

Ponad 200 zadowolonych klientów

Projekty internetowe po raz 3 na Akademii Leona Koźmińskiego

Jak co roku zapraszamy na Handel Elektroniczny na Akademii Leona Koźmińskiego. Po raz 3 wraz z partnerami opowiemy jak skutecznie realizować projekty internetowe.

Więcej szczegółów można znaleźć na stronie Akademii Leona Koźmińskiego.

Zapraszamy na praktyczne 8 h z projektami internetowymi.

Agenda ostatnich zajęć:

  • Wprowadzenie do zarządzania projektami
  • Planowanie projektu
  • Zespół i zasoby
  • Harmonogramowanie projektów
  • Budżetowanie projektów
  • Zarządzanie ryzykiem
  • Zarządzanie zmianami
  • Skuteczne zarządzanie wieloma projektami (porftelem/programem projektów)
  • Rozpoczęcie i zakończenie projektu
  • Kontrola i monitorowanie
  • Metody i techniki
  • Narzędzia

„LEAN, AGILE IT – wsparcie biznesu i produkcji, widziane oczyma praktyków” już za nami….

LEAN, AGILE IT – wsparcie biznesu i produkcji, widziane oczyma praktyków” już za nami….

Konferencja poświęcona była najnowszym rozwiązaniom IT z zakresu:

  • ERP
  • Standaryzacja przetwarzania i zabezpieczania danych
  • Profesjonalne centrum danych
  • IT w procesie zaopatrzeniowym
  • Wielokanałowa komunikacja z Klientem
  • CRM i HCM

oraz zagadnieniom z zakresu Project Managementu i Lean. Celem prelekcji było uświadomienie słuchaczom ważności dobrania odpowiedniego rozwiązania informatycznego, poznanie i sprawdzenie jego możliwości oraz odpowiedni Project Management w odnoszeniu sukcesu w biznesie. Konferencja współorganizowana była przez GoTechnologies, Opolskie Centrum Rozwoju Gospodarki, Park Naukowo – Technologiczny w Opolu, Centrum Wystawienniczo-Kongresowym oraz CompuTec.

Uroczystego otwarcia dokonał Łukasz Neuman – partner zarządzający GoTechnologies Sp. z o.o.. Prelegenci, a byli to:

  • Łukasz Chomin, CEO CompuTec SA
  • Przemysław Janczewski, Administrator systemu ERP, Copal Sp. z o.o.
  • Cezary Wysocki, Architekt Systemowy, Betacom S.A.
  • Robert Bonat, Członek Zarządu w Marketplanet
  • Jacek Chylak, starszy kierownik ds. kluczowych klientów, 3S Data Center
  • Adam Nowakowski, FOCUS TELECOM
  • Magdalena Kobla-Ziętek, CSO w Coreware

przedstawili bardzo interesujące, a jednocześnie inspirujące studia przypadków. Konferencję eksperymentem projektowym zakończył Łukasz Neuman, pokazując, że rzeczy na pozór niemożliwe, przy dobrym zaplanowaniu mogą się udać…