TWOJA ENERGIA

PWC Case Study

Cele projektu
Firma Twoja Energia instalująca panele
fotowoltaiczne poszukuje firmy do wdrożenia
systemu CRM. Cele:
● Integracja SAP (faktury/zamówienia) z CRM.
● Integracja Workday ( informacje o
pracownikach) z systemem CRM.
● Ewentualne dodatkowe integracje jeśli
wymagania klienta się zmienią.
Zespół po stronie klienta
Pan Marian Zespół 5 osób
Szef IT (zajęty) Utrzymanie SAP I Workday

Product Owner Pani Kasia / Pan Rafał

PO SAP Key acc. Manager I acc.
Manager

Product Owner Justyna

PO Workday CEO
Zaproponowane ROLE
Client Project Manager
Osoba odpowiedzialna za
koordynację działań po stronie
klienta, akceptację
dostarczanych rozwiązań i
dbanie o zgodność z celami
biznesowymi.
Business Area Manager
Osoba z odpowiednim
doświadczeniem w dziedzinie
fotowoltaiki, która będzie
przedstawicielem interesów
biznesowych firmy i wskaże
kluczowe wymagania systemu
CRM.
Reprezentacja firmy
takie jak Kasia - Key Account
Manager, Rafał - Account
Mamy już
Manager, Justyna - CEO, będą
uczestniczyć w procesie zbierania
wymagań i akceptacji końcowych
rozwiązań.
*** Solution Architect lub
Enterprise Architect
(opcjonalnie)
osoba która scali I zaplanuje
wszystkie element wymagające
wdrożenia I synchronizację
oprogramowań SAP/Workday i
CRM, określi wymagania i
potrzeby klienta w tym zakresie.
Szef IT (Marian)
Szef IT, zależnie od dostępności
i złożoności projektu mógłby
zostać Client Project Managerem
lub wyznaczyć na tą pozycję
kogoś innego.
Product Ownerzy i
utrzymanie (5 osób)
Product Ownerzy: 2 osoby
odpowiedzialne za systemy
SAP i Workday oraz 5 osób
odpowiedzialnych za ich
utrzymanie.
 Potrzeba zatrudnienia
dodatkowych osób?

• Według mnie Nie ma wyraźnej potrzeby zatrudnienia

nowej osoby po stronie klienta na tym etapie (chyba że
Solution Architect jeśli projekt jest złożony). Firma posiada
już osoby odpowiedzialne za kluczowe systemy oraz
kluczowych przedstawicieli biznesowych.

• Warto zadbać o to, aby osoby te miały odpowiednią

dostępność czasową i były zaangażowane w projekcie na
odpowiednim poziomie.

• Ostateczna decyzja o potrzebie zatrudnienia nowej osoby

powinna być podjęta po dokładnym przeanalizowaniu
zasobów i wymagań projektu.
 Sposoby zbierania wymagań
Warsztaty wymagań
Spotkanie z udziałem kluczowych
przedstawicieli klienta i interesariuszy
biznesowych, takich jak Kasia - Key
Account Manager, Pan Rafał - Account
Manager, Justyna - CEO oraz z osobami
odpowiedzialnymi za systemy.
Wywiady z interesariuszami
Przeprowadzenie indywidualnych
wywiadów z kluczowymi osobami,
takimi jak Pani Kasia, Pan Rafał i Pani
Justyna, aby lepiej zrozumieć ich
indywidualne potrzeby i oczekiwania
wobec nowego systemu CRM.
Analiza dokumentów I
procesów
Przegląd istniejących dokumentów i
analiza obecnych procesów biznesowych,
które zostaną objęte wdrożeniem CRM co
pozwoli na identyfikację szczegółowych
wymagań dotyczących integracji,
funkcjonalności i interfejsu systemu.
Ankiety I Konsultacje
Rozważenie przeprowadzenia ankiety
wśród użytkowników, aby uzyskać ich
opinie i sugestie dotyczące funkcji,
których oczekują w nowym systemie.
 Sposoby zbierania wymagań
Prototypowanie
Tworzenie prototypów funkcjonalności
kluczowych obszarów systemu CRM i
prezentacja ich przedstawicielom
biznesowym, co umożliwi szybkie
zrozumienie, czy system spełnia ich
oczekiwania i potrzeby.
Wymagania oparte o User
Story
Wykorzystanie techniki user story, która
opisuje wymaganie w kontekście
użytkownika i jego celów biznesowych.
Analiza Konkurencji
Przeglądanie rozwiązań CRM
oferowanych przez konkurencyjne firmy w
branży fotowoltaicznej może dostarczyć
cennych wskazówek dotyczących funkcji i
rozwiązań, które warto uwzględnić w
projekcie.
Kreatywne techniki
Zastosowanie różnorodnych technik,
takich jak burza mózgów, mind
mapping, czy story mapping, może
pomóc w identyfikacji ukrytych
wymagań i oczekiwań klienta .
 Należy pamiętać
Zbieranie wymagań to proces ciągły i
interakcyjny.

Warto zaangażować klienta i interesariuszy

biznesowych na każdym etapie projektu,
aby upewnić się, że wszystkie potrzeby i
wymagania zostaną odpowiednio
zidentyfikowane i uwzględnione w
systemie CRM.
Flow historyjek
Historyjka użytkownika: funkcjonalność, ogólne objaśnienie
funkcji oprogramowania napisane z perspektywy użytkownika
końcowego.
Cel: Objaśnienie w jaki sposób dana funkcja oprogramowania
przyniesie klientowi korzyści.

Flow historyjek w JIRA to sposób zarządzania i śledzenia pracy

nad różnymi zadaniami, w tym nad wymaganiami, zadaniami
programistycznymi, testami itp. W przypadku wdrożenia
systemu CRM dla Firmy Twoja Energia, można wykorzystać
JIRA do monitorowania postępu realizacji historyjek
użytkownika (User Stories) i innych zadań związanych z
projektem.
 Flow historyjek
1. Draft (szkic) (główni zaangażowani Product Ownerzy):
• Kierownik Projektu It: Monitoruje proces tworzenia szkiców

DRAFT •
historyjek i zapewnia, że są one odpowiednio zrozumiane
przez zespół wdrożeniowy.
Na tym etapie zespoły analizują i definiują wymagania
dotyczące systemu CRM.
• Historyjki użytkownika są tworzone jako szkice (drafts), ale
jeszcze nie są zaakceptowane przez zespół wdrożeniowy.
• Product Ownerzy oraz przedstawiciele biznesowi uczestniczą
w tworzeniu i dostarczaniu historyjek jako szkiców.
 Flow historyjek
2. To Do (główni zaangażowani Product Ownerzy):
• Historyjki, które zostały zaakceptowane przez zespół

TO DO •
wdrożeniowy jako potencjalne do realizacji, przechodzą do
etapu "To Do".
W tym etapie zespołowi programistycznemu i testerom
przypisywane są zadania do realizacji.
• Product Ownerzy nadzorują i planują, które historyjki zostaną
przeniesione do realizacji.
• Dodatkowo Product Ownerzy Przenoszą zaakceptowane
szkice historyjek do etapu "To Do", aby zespół
programistyczny mógł je zrealizować.
• Zespół programistyczny: Zadania programistyczne związane z
historyjkami są przydzielane i przenoszone do etapu "In
Progress".
 Flow historyjek
3. In Progress (w trakcie realizacji) – zespół deweloperski:
• Zespół programistyczny: Realizuje zadania programistyczne

IN PROGRESS związane z historyjkami, implementuje funkcjonalności

systemu CRM.

• Testerzy: Przeprowadzają testy jednostkowe (sprawdzają

pojedyncze części kodów) i/lub testy integracyjne, aby
zweryfikować poprawność zaimplementowanych rozwiązań.
 Flow historyjek
4. In Review (do przeglądu) (główni zaangażowani Product
Ownerzy):

IN REVIEW • Po zakończeniu prac programistycznych i testów, historyjki

przechodzą do etapu "In Review".

• Product Ownerzy ze strony klienta oraz Product Ownerzy

zespołu wdrożeniowego przeglądają zrealizowane historyjki
w celu zaakceptowania albo zgłaszania uwag.
 Flow historyjek
5. Done (zakończone):
• Kierownik Projektu IT: Nadzoruje zakończone historyjki i

DONE •
sprawdza, czy są gotowe do wdrożenia.
Po zaakceptowaniu przez klienta i zespół wdrożeniowy,
historyjki przechodzą do etapu "Done".
• Historyjki w tym etapie są w pełni zaimplementowane,
przetestowane i gotowe do wdrożenia w środowisku
produkcyjnym.
• Zespół programistyczny i testerzy: Historyjki są uznawane za
zakończone, jeśli zostały zaakceptowane przez klienta i zespół
wdrożeniowy.
 Flow historyjek
6. Rejected (odrzucone):
• Jeśli historyjka zostaje odrzucona przez klienta lub zespół

REJECTED •
wdrożeniowy, przechodzi do etapu "Rejected".
Powód odrzucenia jest opisany, a historyjka może zostać
ponownie dostosowana i wrócić do etapu "Draft" lub może
zostać całkowicie odrzucona.
• Product Ownerzy ze strony klienta: Decydują o odrzuceniu
historyjki, jeśli nie spełnia ona oczekiwań lub potrzeb klienta.
• Product Ownerzy zespołu wdrożeniowego: Mogą również
odrzucić historyjkę, jeśli uzna się, że nie jest możliwe jej
zaimplementowanie zgodnie z wymaganiami.
Flow historyjek

W JIRA, każdą historyjkę użytkownika powinno być łatwo

śledzić, jej status, historię zmian, komentarze i osoby
odpowiedzialne za daną historyjkę. Dzięki temu można w
pełni kontrolować postęp pracy nad projektem i zapewnić
przejrzystość w całym procesie realizacji wdrożenia systemu
CRM.

Żeby historyjki były zatwierdzone to Product Owner musi je odebrać.

 Eventy I skład osobowy
Sprint Planning
i. Kierownik Projektu IT : Prowadzi
ceremonię i zapewnia zgodność z Daily Scrum
celami projektu.
ii. Product Ownerzy ze strony klienta:
Przedstawiają priorytety historyjek I. Kierownik Projektu IT:
użytkownika do realizacji. Nadzoruje spotkanie i zapewnia
iii. Zespół programistyczny i testerzy: przestrzeganie ustalonych zasad.
Oceniają, ile zadań i historyjek II. Zespół programistyczny i
mogą zostać zrealizowanych w testerzy: Raportują postępy i
danym sprincie. ewentualne bariery w pracy.
 Eventy I skład osobowy
Sprint Review
I. Kierownik Projektu IT: Prowadzi
przegląd sprintu i zapewnia, że
cele zostały spełnione.
II. Product Ownerzy ze strony klienta:
Odbierają prezentację
zrealizowanych funkcjonalności i
decydują, czy zaakceptować je w
ich obecnej formie lub zgłosić
uwagi do dalszej poprawki.
III. Zespół programistyczny i testerzy:
Prezentują zrealizowane
funkcjonalności.
Sprint Retrospective
I. Kierownik Projektu IT: Prowadzi
retrospective i pomaga w
identyfikacji obszarów do poprawy.
II. Zespół programistyczny i testerzy:
Współuczestniczą w dyskusji i
dzielą się swoimi obserwacjami.
III. Product Ownerzy ze strony klienta:
Uczestniczą w retrospekcji i mogą
przedstawiać swoje uwagi i
sugestie.
Eventy I skład osobowy
 Opis: Ceremonia, która odbywa się
Skład osobowy na ceremoniach
może być dostosowany w zależności
od wielkości zespołu i projektu
oraz zaleceń Agile.
I.
Regularne ceremonie (eventy) 
efektywna współpraca i komunikacja
II.
między zespołem wdrożeniowym a
klientem.
III.
Sprint Demo
na końcu sprintu, podczas której
zespół prezentuje działający system
CRM klientowi i interesariuszom.
Kierownik Projektu IT: Prowadzi
demo systemu i zapewnia, że
wszystkie funkcjonalności są
odpowiednio przedstawione.
Product Ownerzy ze strony klienta:
Odbierają prezentację i dają swoje
opinie i uwagi odnośnie
działającego systemu.
Zespół programistyczny i testerzy:
Prezentują działający system i
odpowiadają na pytania.
 Zestaw środowisk
Deweloperskie
Opis: Środowisko dla zespołu
developerskiego do tworzenia i
testowania nowych funkcji i zmian.
Co będzie na nim realizowane:
Programiści będą rozwijać
funkcjonalności systemu CRM, testować
kod i dostosowywać go do wymagań
projektu.
Testowe (QA/Test)
Opis: Środowisko, które służy do
przeprowadzania testów np. integracyjnych,
testów jednostkowych, testów wydajności.
Co będzie na nim realizowane: Zespół
testerów będzie przeprowadzał różnego
rodzaju testy, aby zweryfikować, czy system
CRM spełnia określone wymagania i działa
poprawnie.
Staging (przed prod.)
Opis: Środowisko, które jest odwzorowaniem
środowiska produkcyjnego i służy do
finalnego testowania i akceptacji przez
klienta.
Co będzie na nim realizowane:
Przedstawiciele klienta i interesariusze będą
przeprowadzać testy akceptacyjne, aby
upewnić się, że system działa zgodnie z
oczekiwaniami i wymaganiami.
Produkcyjne
Opis: Ostateczne środowisko, na którym
zostanie uruchomiony system CRM po
pomyślnym przejściu testów akceptacyjnych.
Co będzie na nim realizowane: System CRM
będzie działał na tym środowisku i będzie
dostępny dla użytkowników w celu
prowadzenia codziennej działalności firmy.
Integracje
CRM-SAP
aby możliwe było wspólne korzystanie z danych dotyczących
zamówień i faktur.

CRM-Workday
aby umożliwić zarządzanie danymi dotyczącymi zatrudniania
pracowników i czasu pracy.

CRM- Inne Systemy

W zależności od istniejących rozwiązań, może być konieczne
przeprowadzenie integracji z innymi systemami
wykorzystywanymi w firmie, aby zapewnić spójność i wymianę
danych między nimi.
Testy I quality gates

Wprowadzenie quality gate'ów pozwoli na

skuteczne monitorowanie jakości
systemu na różnych etapach projektu i
zapewni, że tylko systemy spełniające
określone kryteria przechodzą do
kolejnych faz projektu lub zostaną
wdrożone w środowisku produkcyjnym.
Testy jednostkowe
• Opis: Testy jednostkowe są przeprowadzane na poziomie
pojedynczych komponentów (np. funkcji, klas) i służą do
weryfikacji, czy poszczególne części systemu działają
poprawnie.

• Skład osobowy: Programiści są odpowiedzialni za tworzenie i

wykonywanie testów jednostkowych.

Quality gate po testach jednostkowych:

• Kryterium: Wszystkie testy jednostkowe muszą zostać

pomyślnie zakończone bez żadnych błędów.

• Skład osobowy: Programiści, zespół testerów i Product

Ownerzy zespołu wdrożeniowego.
Testy integracyjne
• Opis: Testy integracyjne koncentrują się na weryfikacji
poprawności działania interfejsów i integracji między różnymi
modułami systemu oraz z systemami zewnętrznymi (np. SAP,
Workday).

• Skład osobowy: Zespół testerów i programistów pracują

wspólnie nad przeprowadzeniem testów integracyjnych.

Quality gate po testach integracyjnych:

• Kryterium: Wszystkie testy integracyjne muszą być

zakończone pomyślnie, a integracje między modułami i
systemami zewnętrznymi muszą działać poprawnie.

• Skład osobowy: Programiści, zespół testerów i Product

Ownerzy zespołu wdrożeniowego.
Testy funkcjonalne
• Opis: Testy funkcjonalne sprawdzają, czy system spełnia
określone wymagania i czy funkcje działają zgodnie z
oczekiwaniami klienta.
• Skład osobowy: Zespół testerów przeprowadza testy
funkcjonalne, a Product Ownerzy ze strony klienta
uczestniczą w akceptacji wyników testów.

Quality gate po testach funkcjonalnych:

 Kryterium: Wszystkie testy funkcjonalne muszą zostać

zakończone pomyślnie, a system musi spełniać określone
wymagania biznesowe.

 Skład osobowy: Zespół testerów, Product Ownerzy zespołu

wdrożeniowego i przedstawiciele klienta.
Testy wydajności
• Opis: Testy wydajności oceniają, jak system zachowuje się
pod obciążeniem, w szczególności w przypadku dużej liczby
użytkowników lub transakcji.
• Skład osobowy: Zespół testerów specjalizujących się w
testach wydajności przeprowadza te testy.

Quality gate po testach wydajności:

 Kryterium: System musi wykazać odpowiednią wydajność i nie

wykazywać krytycznych problemów podczas testów
obciążeniowych.
 Skład osobowy: Zespół testerów specjalizujących się w testach
wydajności, programiści i przedstawiciele klienta.
Testy akceptacyjne

• Opis: Testy akceptacyjne są przeprowadzane przez

przedstawicieli klienta, aby upewnić się, że system
spełnia założone wymagania biznesowe i jest gotowy do
wdrożenia w produkcji.

• Skład osobowy: Przedstawiciele klienta (np. Kasia, Rafał,

Justyna) współpracują z zespołem testerów w celu
przeprowadzenia testów akceptacyjnych.
 Potencjalne ryzyka
Harmonogram
Opóźnienia w realizacji projektu z
powodu trudności w integracji
różnych systemów.
Niedostateczne zasoby ludzkie lub
techniczne mogą prowadzić do
opóźnień.
Techniczne
Problemy związane z integracją systemu
CRM z istniejącymi systemami SAP i
Workday.
Konieczność dostosowania systemu CRM
do specyficznych wymagań i procesów
firmy, co może być technicznie
wymagające – Solution Architect.
Jakościowe
Błędy i wady w systemie CRM,
które mogą wpływać na jego
funkcjonalność i użyteczność.
Wymagania biznesowe nie są
odpowiednio zrozumiane i nie
spełniają rzeczywistych potrzeb
klienta.
Akceptacja
Odmowa zaakceptowania systemu
CRM przez przedstawicieli klienta na
etapie testów akceptacyjnych.
Brak aktywnego zaangażowania
przedstawicieli klienta w procesie
wdrożenia, co może utrudnić uzyskanie
pełnej akceptacji.
Finansowe
Przekroczenie budżetu projektu z
powodu niespodziewanych kosztów
lub zwiększenia zasięgu projektu.
Koszty szkoleń i wdrożenia mogą
być wyższe niż początkowo
zakładano.
Szkoleniowe
Pracownicy Firmy Twoja Energia mogą
napotkać trudności w opanowaniu
nowego systemu CRM.
Brak odpowiedniego szkolenia i
wsparcia dla użytkowników może
wpłynąć na efektywność i efektywność
korzystania z systemu.
 Potencjalne ryzyka
Jak skutecznie zarządzać ryzykiem?
• Dokładnie zbadać i zrozumieć potrzeby klienta.
• Ustalić plan działań na wypadek wystąpienia ryzyk.

Zmiana wymagań • Zapewnić regularne monitorowanie i komunikację w celu wczesnego

wykrywania potencjalnych problemów.
Wymagania klienta mogą ulec zmianie
• Angażować kluczowych interesariuszy, w tym użytkowników, w proces
w trakcie realizacji projektu, co może
wpływać na harmonogram i koszty. wdrożenia.
Brak odpowiedniego zarządzania
• Realizować testy weryfikacyjne i walidacyjne, aby upewnić się, że
zmianami może prowadzić do
chaotycznych zmian w projekcie. system CRM spełnia wymagania i oczekiwania klienta.
• Posiadać elastyczny i adaptacyjny plan, aby dostosować się do
zmieniających się warunków i wymagań.
Harmonogram projektu
Agile
Harmonogram uwzględnia niektóre zasady Scrum, takie jak
pracę w sprintach i iteracyjny rozwój, ale jednocześnie zapewnia
Hybryda wyraźnie zdefiniowane fazy i terminy (bardziej tradycyjne
podejście do zarządzania projektami).

Ważna jest elastyczność projektu i gotowość do dostosowywania

się do zmian, a jednocześnie spełnić oczekiwania co do
określonych etapów projektu.

*** Scrum jest metodyką, która nie definiuje określonego

harmonogramu z góry, a raczej dostosowuje się do potrzeb
projektu podczas trwania prac. Scrum promuje elastyczność i
dostosowywanie się do zmian, co oznacza, że nie można z góry
ustalić, ile dokładnie czasu zajmie każda faza projektu.
Harmonogram projektu
Inicjacja (2 tygodnie)

Faza • Przygotowanie i zatwierdzenie projektu, w tym

ustalenie celów i zaakceptowanie zakresu projektu.

• Ustalenie ról i odpowiedzialności w zespole

1 projektowym.
Harmonogram projektu
Planowanie I zbieranie wymagań
(3 tygodnie)
Faza • Określenie wymagań projektu w oparciu o
spotkania z interesariuszami (KAM, account
2 manager, CEO).

• Przygotowanie backlogu produktu i sprecyzowanie

epik oraz user stories.

• Określenie harmonogramu projektu i alokacja

zasobów.
Harmonogram projektu
Implementacja I testy
8 tygodni (4 sprinty po 2 tygodnie)
Faza • Realizacja sprintów, w których rozwijane są kolejne
funkcje systemu CRM.

3 • Testy jednostkowe i integracyjne.

• Ocena jakości i dostarczonych funkcji na każdym

zakończonym sprincie.
Harmonogram projektu
Integracja i Akceptacja
4 tygodnie
Faza • Przygotowanie i testy integracji systemu CRM z
SAPem i Workday.

4 • Przegląd systemu z klientem (KAM, CEO) i

dostosowania.

• Testy akceptacyjne i poprawki.

Harmonogram projektu
Wdrożenie i Szkolenie
3 tygodnie
Faza • Przygotowanie środowiska produkcyjnego.
• Wdrożenie systemu CRM w środowisku
produkcyjnym.
5 • Przeszkolenie użytkowników systemu CRM.
• Przygotowanie dokumentacji.
Harmonogram projektu
Odbiór końcowy i zamknięcie projektu

Faza 2 tygodnie

• Przegląd końcowy z klientem i zespołem.

• Ostateczne dostosowania i poprawki.
6 • Ocena projektu i retrospektywa.
• Przekazanie projektu do utrzymania i wsparcia
(Product Ownerzy).
Harmonogram projektu

To ogólny harmonogram, który zakłada, że każdy sprint

trwa 2 tygodnie. Można dostosować liczbę sprintów w
Agile zależności od potrzeb i tempa pracy zespołu.

Ważne jest, aby stale komunikować się z klientem i

dostosowywać harmonogram do jego oczekiwań i
zmieniających się priorytetów.
 Pojęcia
Klasa Interface
W kontekście programowania, Interface to kontrakt, który Atrybuty Klasy I Metody
klasa jest szablonem, który definiuje zestaw metod, które klasa Atrybuty to metadane, które
definiuje cechy i zachowanie musi dostarczyć. dostarczają informacje o klasie lub
obiektów. metodzie.

Metoda Unit Test Konstruktor

Metoda to funkcja lub procedura, która Test jednostkowy to testowanie Kto specjalna metoda, która inicjalizuje
wykonuje określone działania dla danej pojedynczych komponentów (np. Klas, nowo utworzony obiekt.
klasy. metod) w izolacji, aby sprawdzić, czy
działają poprawnie.
 Ciekawostki Szwajcaria
Opis
Ten prosty program Python to
kalkulator, który losowo wybiera i
wyświetla ciekawostki o Szwajcarii.
Program jest napisany w języku Python
i umożliwia użytkownikowi pozyskanie
ciekawych informacji o tym kraju.
Jak używać?
• Uruchom plik ciekawostki.py w
swoim środowisku Python.
• Program losowo wybierze jedną z
ciekawostek o Szwajcarii.
• Wyświetli wybraną ciekawostkę na
ekranie.
1. `import random`: Importuje moduł
`random` do generowania losowych liczb
i wyboru losowych elementów z listy.
2.`facts`: Lista ciekawostek o Szwajcarii,
gdzie każdy element to ciąg znaków z
jedną ciekawostką (klasa).
3.`random_fact`: Zmienna
przechowująca losową ciekawostkę
wybraną z listy `facts` za pomocą funkcji
`random.choice` (metoda).
4. `print ("Ciekawostka o Szwajcarii:")`:
Wyświetla komunikat informujący o
wyświetleniu ciekawostki o Szwajcarii.
5. `print(random_fact)`: Wyświetla
wybraną losowo ciekawostkę o Szwajcarii
na ekranie.
Download Repozytorium
 Review kodu
1. Ogólny Cel:
Kod spełnia swoje podstawowe zadanie - wybiera losową ciekawostkę z dostępnej listy i wyświetla ją na ekranie. Jest to proste i
zrozumiałe zadanie.
2. Czytelność i Konwencje:
Kod jest napisany w sposób czytelny i przestrzega konwencji nazewniczych. Wcięcia i formatowanie są poprawne, co ułatwia
zrozumienie kodu.
3. Brak Dokumentacji:
Jednym z obszarów, który wymaga uwagi, jest brak dokumentacji w kodzie. Brakuje komentarzy lub docstringów, które
opisywałyby działanie kodu i jego składniki. Dodanie dokumentacji znacznie ułatwiłoby zrozumienie kodu dla innych
programistów.
4. Testy Jednostkowe:
W kodzie brakuje testów jednostkowych. Dodanie testów byłoby korzystne, aby sprawdzić, czy funkcje działają zgodnie z
oczekiwaniami. Testy pomogłyby również w zachowaniu jakości kodu podczas ewentualnych zmian.
5. Elastyczność i Rozwój:
Kod jest prosty i spełnia obecne wymagania, ale warto rozważyć, jak można go rozwinąć w przyszłości. Na przykład, można by
dodać funkcje do dodawania nowych ciekawostek do listy lub udostępniania ciekawostek w inny sposób.
Podsumowanie:
Ten kod stanowi solidną podstawę do prezentacji ciekawostek o Szwajcarii. Jest czytelny i spełnia swoje podstawowe zadanie.
Warto dodać dokumentację oraz napisać testy jednostkowe, co zwiększy jakość kodu. To także dobry punkt wyjścia do
ewentualnych rozszerzeń i rozwinięć w przyszłości.