5.8 KiB
Strona automatycznie zmigrowana z systemu Eduwiki z wykorzystaniem Pandoc s301651,s416079,s434736:read,write Known:read All:
Zespół
|| Imie i nazwisko || Numer indeksu || Zakres prac || Email || || Piotr Sienkiewicz || 301651 || TBA || ps68@st.amu.edu.pl || || Oskar Jabłoński || 416079 || TBA || oskjab@st.amu.edu.pl || || Damian Lasecki || 434736 || TBA || damlas@st.amu.edu.pl ||
Tytuł
Physical Progress Bar
Wprowadzenie
Dokument dotyczy projektu realizowanego w ramach przedmiotu Inżynierski Projekt zespołowy. Niniejszy dokument służy przedstawieniu przeznaczenia tworzonego systemu, jego głównych cech i przyjętych założeń
Cel
Celem projektu jest stworzenie urządzenia do wizualizacji postępu pracy zwanego dalej Physical ProgressBar.
Rynek
Tworzone przez nas urządzenie jest unikatowe i nie istnieje znaczący rynek systemów wizualizujących upływ pracy, mających na celu motywowanie pracowników. Jednocześnie system będzie pozwalał, w miarę możliwości technicznych, na import danych z innych serwisów.
Użytkownicy
Urządzenie Physical Progess Bar jest skierowane do użytkowników, których praca jest mierzalna, do tej grupy zaliczamy:
- Pracowników biurowych
<!-- -->
- Programistów
<!-- -->
- Osoby ćwiczące na siłowni
<!-- -->
- Czytelników e-booków
<!-- -->
- Szkoły
Opis
Do głównych funkcjonalności urządzenia zaliczamy:
- Prezentowanie postępu prac przy pomocy fizycznej struktury, która automatycznie zmienia swoje właściwości na podstawie otrzymanych danych
<!-- -->
- możliwość zwiększania wartości postępu przy pomocy fizycznych przycisków na urządzeniu
<!-- -->
- możliwość zwiększenia wartości postępu przy pomocy aplikacji mobilnej
<!-- -->
- integracja z
- serwisem IFTT https://ifttt.com/
- serwisem Microsoft Power Automate https://flow.microsoft.com/en-us/
<!-- -->
- wsparcie dla wielu urządzeń dla 1 użytkownika
<!-- -->
- udostępnienie publicznego API pozwalającego innym na własne integracje z naszym urządzeniem
Zakres i ograniczenia
Na pierwszy termin oddania projektu planujemy stworzyć działający prototyp urządzenia, który będzie zdolny do komunikacji z urządzeniem mobilnym lub serwerem.
Pewnym ograniczeniem postępu prac mogą być koszty i czas dostawy elementów elektronicznych. Niepokojąca jest też perspektywa braku spotkań zespołu.
Aktorzy
- Programista
- Pracownik biurowy
- Scrum master / lider zespołu
- Przedstawiciel marketingu
- Użytkownik todo-listy
- Zewnętrzny system
User stories
- Jako pracownik biurowy chciałbym widzieć postęp prac na fizycznym urządzeniu widocznym dla każdego członka zespołu.
- Jako scrumMaster/lider zespołu chciałbym aby członkowie zespólu widzieli postęp prac na fizycznym urządzeniu aby utrzymywać ich morale i motywacje na wysokim poziomie.
- Jako przedstawiciel marketingu chcę publikować stan progress bara w mediach społecznościowych.
- Jako użytkownik todo-listy, chcę widzieć postęp w realizacji dziennych zadań, aby czuć się lepiej zmotywowanym.
- Jako zewnętrzny system chcę poinformować konkretny progress bar o postępie, aby pracownik biurowy na bieżąco widział postęp.
- Jako programista chcę wywołać metodę publicznego api, aby widzieć postęp w swoim własnym projekcie.
Architektura
{{https://images.tinypic.pl/i/01010/f7emekb4w5c3.jpg}}
Technologie
- Azure devops:
- Product Backlog + Sprint Backlog
- Continuous Integration: Azure releases
- Continuous Deployment: Azure Deployment
- Wiki - głównie instrukcje, jak coś skonfigurować
- git
- digitalocean.com
- Hosting Kubernetes
- Canister.io
- hosting Docker container registry
- Visual Studio 2019 (wersje dla Windows i dla Mac)
- ARDUINO IDE
- Języki programowania: C#, yaml, c, planowane: javaScript + React
- PostreSQL
- mosquitto - broker MQTT (szyna danych)
Proces
Korzystamy ze procesu Scrum. Review, retro oraz planning mamy w poniedziałki o godzinie 19:00, a daily Scrum we wtorki, czwartki i soboty o godzinie 8:00 (rano). W trakcie sprintu robimy średnio zadania za 14-17 Story Pointów. Zadania wyceniamy korzystając z Planning Pokera.
Definition Of Done (na dzień 1 lipca 2020):
- PBI & Task:
- funkcjonalność musi zostać przetestowana na odpowiednim środowisku (Docker) przez osobę wykonującą zadanie
- code review wykonane przez przynajmniej jedną osobę (sprawdzenie standardów pisania kodu w konkretnym języku)
- commity muszą zostać podlinkowane do konkretnych PBI-ów i tasków
- nie wyłączamy już istniejących testów
- PBI:
- branch, na którym wykonywane jest zadanie musi zostać domergowany do brancha develop
- przynajmniej jeden test jednostkowy/integracyjny/automatyczny
- zaktualizować istniejącą dokumentację po dokonaniu zmian
Galeria
{{https://images.tinypic.pl/i/01009/kt15njd262dh.jpg}}
{{https://images.tinypic.pl/i/01009/vziwk0eox865.jpg}}
{{https://files.tinypic.pl/i/01009/5xbmsnlb4hlk.jpg}}
{{https://files.tinypic.pl/i/01009/7v0ah5crkza9.jpg}}
{{https://pics.tinypic.pl/i/01009/ryur6o52ijm1.jpg}}
{{https://images.tinypic.pl/i/01009/w4nwbfl176vq.png}}
{{https://files.tinypic.pl/i/01009/alip386n3a5x.jpg}}
{{https://files.tinypic.pl/i/01009/drvqwcf8u4v3.png}}