Jak szybkie prototypowanie pasuje do zwinnej metodologii?

Pracuję dla dużej firmy, która dyktuje stosowanie zwinnych procesów. Na przykład w naszych projektach korzystamy z usług w chmurze, które są specjalnie ukierunkowane na zarządzanie sprawnym programowaniem.

Konkretna grupa inżynierów, dla której pracuję, nie opracowała tradycyjnie oprogramowania (zamiast tego pomagamy kierować projektami z dużo większej perspektywy), ale to się zmienia. Mamy szeroką gamę nadchodzących / planowanych projektów oprogramowania, które są głównie skoncentrowane na danych - np. Będziemy monitorować dane, gromadzić, agregować i niektóre raporty. Inne zadania obejmują automatyzację za pomocą specjalistycznego sprzętu i różnych rodzajów architektur klient / serwer (wielopłaszczyznowych). Mam pomagać w procesie zatrudniania kilku osób i formułować wiele naszych planów dotyczących rozwoju.

Moje pytanie brzmi: czy robienie szybkiego prototypowania (niepotrzebny kod) wpisuje się w zwinną filozofię. Na przykład uwielbiam Python i jego szeroką gamę pakietów. Widzę możliwość bardzo szybkiego wdrożenia wielu naszych pomysłów za pomocą przepływu pracy opartego na języku Python. Myślę jednak, że będzie wiele przekonań, że Python nie jest „jakości korporacyjnej” i wiele z tych prac wymaga przepisania w Javie, a może w C ++.

Jednak tworzenie prototypów w języku Python dałoby nam ogromną satysfakcję, umożliwiając nam szybkie dostarczanie rzeczywistych rezultatów.

Czy udało Ci się wdrożyć szybkie prototypowanie - mam nadzieję, że w Pythonie - w solidny, zwinny przepływ pracy w środowisku korporacyjnym?

Koncepcja „prototypowania”, zgodnie z zamierzeniami w RAD , jest nieco obca dla zwinnego rozwoju. Nie oznacza to, że nie można tego zrobić, ale jest to niezwykłe.

Istnieją różne przypadki, które należy zbadać:

1. Czy prototyp jest „pustą skorupą”, makietą lub wersją demonstracyjną, stworzoną, aby dać wyobrażenie o tym, jak mógłby wyglądać produkt? Z pewnością możesz to zrobić z jedną lub kilkoma opowieściami - jednak budujesz coś z własnej wyobraźni, a nie budujesz produkt z prawdziwej opinii. Ludzie nie oceniają wersji demo tak, jak oceniają produkt. Na przykład zobacz opinie na temat naszego prototypu górnego paska w porównaniu z naszą rzeczywistą implementacją górnego paska .

2. Czy prototyp jest czymś, co należy zbudować, aby lepiej zrozumieć przestrzeń problemu? Następnie powinien być zakryty jako skok , a tylko jego wyniki zachowane (kod źródłowy jest przejściowy).

3. Czy prototyp to wersja 0.x? Mininimum produkt opłacalne ? Następnie zastosuj do tego wybrany przez ciebie zwinny proces. Jeśli musisz go odbudować w innym języku, prawdopodobnie lepiej Ci będzie, jeśli potraktujesz inny produkt. Zauważ, że czasami jest to traktowane jako skrót do pisania specyfikacji („powinien zrobić to samo co prototyp!”). To naprawdę kiepski sposób dokumentowania produktu, ale prawdopodobnie lepiej to wyjaśnić jako osobne pytanie i odpowiedź :-)

Czy szybkie prototypowanie (tj. Iteracyjny i przyrostowy rozwój) nie jest czymś w rodzaju Agile?

Wygląda na to, że masz problemy z „postrzeganiem to rzeczywistość” w swojej organizacji. Możesz przypomnieć wszystkim, że zwinny nie oznacza „odrzucenia wszystkich planów”, podobnie jak rozwój oparty na testach oznacza „odrzucenie całej architektury”.

A Python nie jest (jeśli był) językiem zabawek. NASA i jej kontrahenci używają Pythona , a jeśli jest dla nich wystarczająco dobry, jest dla mnie wystarczająco dobry.

W Programowaniu ekstremalnym istnieje ustalona praktyka zwana Spike . Oznacza to, że jest to kod jednorazowy. Nie ma w tym nic specjalnego. Jest to tylko sprint, w którym oczekiwanym rezultatem jest znajomość kodu jednorazowego.

Powyższy link zawiera wystarczającą ilość informacji o dobrych praktykach, pułapkach skoków.

Twój konkretny przypadek użycia wydaje się dobrym przykładem: pomocne może być zaprojektowanie interfejsu, sprawdzenie poprawności narzędzia i pokazanie go niektórym użytkownikom.

Wyrzucisz kod i nie wprowadzisz go do produkcji (wyjaśnij to KAŻDEMU), więc zwinność czy nie ma tak naprawdę znaczenia. Wszelkie zwinne praktyki są całkowicie opcjonalne w przypadku prototypów: sprinty, wypalenia, testy, programowanie par lub cokolwiek innego, co planujesz użyć.

Jeśli zamierzasz głównie budować modele funkcjonalne w Pythonie, aby pomóc właścicielom produktów i innym decydentom w konceptualizacji projektu, nie musisz być gotowy na przedsięwzięcia. Jeśli jednak tworzysz dowód koncepcji lub próbujesz sprawdzić, czy poradzisz sobie z pewnymi poziomami wydajności, prawdopodobnie powinieneś trzymać się języka produkcyjnego. To nie znaczy, że nie możesz tego wypróbować w Pythonie.

Niezależnie od tego, wyrzucisz kod, ale wiedz, że możesz sprawić, by działało to wraz z lepszym wyczuciem tego, czego chcą właściciele. Teraz możesz użyć dowolnej wybranej metody.

Dodam, że prototypy są kluczowe dla nauki, a także w duchu zwinnym. Jeśli prototyp pozwala ci się uczyć, szczególnie w ramach szybszych cykli sprzężenia zwrotnego, to idź do niego. Chodzi o maksymalizację uczenia się i dzielenie się nim z zespołem.

Jeśli chodzi o naukę, dodam, że prototypowanie pozwala szybciej się uczyć. W ten sposób możesz sprawdzić, czy ludzie w ogóle dbają o problem, który próbujesz rozwiązać - i czy rozwiązanie, o którym myślisz, w ogóle jest tym, czego szukają - bez marnowania dużo czasu na budowanie pełnego rozwiązania, które może , w końcu nie rozwiąż wystarczająco bolesnego problemu lub nie rozwiąż go we właściwy sposób.

Prawdziwy duch Agile polega na interakcji i komunikacji. Powiedziałbym, że jeśli prototyp działa dobrze jako narzędzie ułatwiające komunikację, nie ma nic złego w używaniu go w świecie zwinnym. W naszym zespole (ćwiczymy Agile od ponad 5 lat) korzystaliśmy z niego od czasu do czasu. I widzę z tego pewne korzyści

1) Wspomaganie komunikacji

2) Zaproś użytkowników na wywiady dotyczące rozwiązań i uzyskaj wczesną informację zwrotną

Zastrzeżenie:

Bezpośredniej komunikacji między UX a inżynierami NIGDY nie należy NIGDY zastępować żadnymi artefaktami prototypowania. Jeśli to możliwe, parowanie z inżynierem działa znacznie lepiej niż komunikacja za pośrednictwem mediatora (prototypu).

Inni wspominali już o celu uczenia się skoków. Brakuje podstawowej zasady zwinności, która szybko zawiedzie .

Jednym z filarów zwinnego rozwoju jest rozpoznawanie trudnych części i szukanie dowodu koncepcji, czy w ogóle możesz to zrobić. Klasyczny sposób radzenia sobie ze wszystkimi zadaniami w jakiejś „logicznej” kolejności może okazać się bardzo drogi, jeśli okaże się, że nie możesz zrobić czegoś późno w projekcie. Wszystko, co do tej pory zrobiono, może być stratą.

Jeśli to musi skończyć w ten sposób, chcesz wiedzieć jak najszybciej. Następnie interesariusze mogą albo po prostu przestać palić pieniądze, dopóki niewiele nie zostało jeszcze spalone, i zaakceptować to, czego chcą, nie jest wykonalne, lub spróbować radykalnie odmiennego podejścia do problemu, który będzie miał nową szansę na odniesienie sukcesu. Jeśli twoje prototypy służą temu celowi, są rzeczywiście najbardziej zwinne.