How corporation can run a project without budget :)
1.
Jak wszyscy zarobilidzięki Agile?
czyli jak zrobić projekt Agile z multinarodową korporacją…
Wersja 1 / Kraków, data 12.02 2015
Jak zrobić projekt nie
mając budżetu? ;)
Napisz do nas:
JakubTabędzki jakub.tabedzki@redexperts.net
Zadzwoń do nas:
+48 501 444 478
Znajdź nas w Internecie:
www.redexperts.net
www.facebook.com/Redexperts
Odwiedź nas:
ul. Rzepińska 21, 60 – 176 Poznań
Editor's Notes
#8 Dużo doprecyzowań, zebranie wszystkich wymagań (warsztaty na początku)
Powstał backlog
#9 Podglad punktow handlowych i analiza plus filtry
#10 - grafika plus ux design bardzo dużo dała, klient poczuł sie spokojny
#11 Konferencja, aproval, budżet, feedback od przedstawicieli co by w tej aplikacji chcieli w detalach. Kpi sa w pełni konfigurowalne (my oznaczamy je cyframi, a tam mozna zmienić nazwę i wartości). Powstała wersja angielska.
#12 Drugi przyrost - na bazie feedbacku powstał zakres drugiego etapu.
Planowanie wg dni i częstotliwości plus kalendarz
#13 Po drugim etapie poszły testy wewnętrzne na małej liczbie handlowców (ok. Półtora miesiąca)
#14 Trzecia fala - dorabianie funkcjonalności na podstawie feedbacku (planowanie wizyt na dany dzien, sposoby przeliczania wizyt) - uwzględniliśmy zmianę potrzeb.
#15 wizualizacja danych zamiast ciężkich tabel;
aktualne dane u handlowca
Raporty dla konkretnego punktu handlowego -> dwustronna komunikacja
- możliwość wybory kpi przez handlowca i sprawdzenia gdzie powinien sie udać ze względu na kpi (kolory pinow pokazują, że dane miejsce wymaga wiecej pracy)
- obsluzenie logiki z centrali (geolokalizacja).
#17 Zalety pracy w falach
1. Możliwość wydania niewielkich pieniędzy i sprawdzenie czy narzędzie zadziała.
2. Duża elastyczność dziek pracy w sprintsch
3. time and materials (nieoficjalnego - czasem mieliśmy jakieś dni nadrobki, ktore prostował kolejnym większym zamówieniem) klient rozumiał, ze jesli na etapie realizacji wychodziły rzeczy niedogadane, to klient rozumiał, ze trzeba za nie zapłacić.
#18 - zrozumienie klienta, ze zmiana zakresu wiąże sie ze zmianą kosztów
- dodawanie klocków po kolei pozwalało na uzmyslowienie klienta ze aplikacja sie komplikuje i ograniczanie funkcjonalności ktore klient dodawał (samoświadomość)
- klient zaufał naszej wiedzy technologicznej i KONSULTOWAŁ swoje pomysły a nie wrzucal je do robienia
- klient dostarczył sprzęt 1:1 nie było zgadywania czy na ich urządzeniach bedzie działało, bo wiedzieliśmy dokładnie jakie urządzenia ma klient.
#19 - lepsza komunikacja
- zaplanować uruchomienie wersji pod telefon na początku (dodatkowy koszt przeprojektowania oraz obniżona użyteczność).
#20 Ciekawostki
1. Korporacja nie pozwalała na publikacje w play - dystrybucja poza marketem
Synchronizacja danych w sieci firmowej (vpny zasilane danymi i kodem aplikacji z centrali)
2. Klient chciał mieć dane offline - aplikacja nie musi mieć dostępu do internetu calu czas tylko moze sie synchronizowac np raz dziennie.
3 Po deployu nie było ŻADNEJ poprawki! Nie ma crashow (wiekszosc dni mamy 100% poprawności działania aplikacji - bez żadnych crashow)
4.Liczba użytkowników - docelowo 300 osób (chociaż nie wszyscy używają codziennie).
5. Wszystko chodzi na Bazie sqlite, klient ftp pobiera z serwera bazę na dany dzien. Nie ma żadnego backendu!