Czy Scrum ma sens przy wdrażaniu nowego zaplecza kompilatora?

Mam istniejący język, który muszę przenieść na nową platformę. Prawdopodobnie spróbuję tego, zmieniając zaplecze istniejącego kompilatora.

Ponowne napisanie backendu wymaga znacznej ilości pracy. Nie widzę sposobu na rozbicie tego na sensowne historie bez naruszenia kryteriów INVEST.

Nie widzę, jak każda historia może być negocjowalna - wszystkie są wymagane do działającego kompilatora. Wszystkie historie mają jednakowy priorytet i nie ma znaczenia, w jakiej kolejności je dostarczę. Muszę zrobić je wszystkie.

Niektóre wdrażane przeze mnie oprogramowanie ma niższy priorytet niż inne i widzę, że możemy dostarczać je stopniowo. Istnieje jednak znaczący rdzeń, jakim jest Must Have .

Mam zamiar próbować podążać za Scrumem, ale czy po prostu wykonuję te ruchy?

Czy istnieją zalecane praktyki dla tego rodzaju projektów?

Należy pamiętać, że głównym powodem, dla którego stworzono procesy Agile, było sprostanie zmieniającym się wymaganiom. Jeśli wymagania są ustalone w kamieniu (naprawdę ustalone wymagania są rzadkie, ale zabiorę cię za słowo!), Wówczas niektóre z najlepszych praktyk radzenia sobie ze zmieniającymi się wymaganiami - np. Historie do negocjacji - stają się nieco nieistotne. To powiedziawszy, po przepływie pracy Scrum nadal ma wiele potencjalnej wartości pod względem planowania i dostarczania rezultatów. Nawet jeśli twoje produkty nie będą przez jakiś czas produktem w pełni użytecznym, wciąż jest coś do powiedzenia za to, że jesteś w stanie wykazać postępy swojemu klientowi (i zespołowi!).

Weź pod uwagę, że wszystkie te „obowiązkowe” historie składają się z jednego eposu: „Być w stanie skompilować na platformie X”. W takim przypadku cała epopeja musi zostać ukończona, zanim jakaś wartość zostanie dostarczona użytkownikowi, ale często tak jest na początku dużych projektów. Zacznij od opowiadania, aby skompilować najprostszy możliwy program, a następnie utwórz kolejne opowiadania, aby obsługiwać coraz więcej funkcji językowych.

Przede wszystkim nie przejmuj się zbytnio próbowaniem zmuszenia każdej sytuacji do przyjęcia bardzo ogólnego podejścia. Zwinny powinien działać dla Ciebie, a nie na odwrót!

Oczywiście Scrum jest przydatny. To metodologia, która robi dla ciebie dwie rzeczy:

1. Pozwala twój projekt dostosować się do zmian i
2. Umożliwia śledzenie postępów i ustalenie, kiedy zostanie ukończony

Tak więc korzystanie z niego ma pewną wartość.

Myślę, że niektóre z twoich warunków wstępnych są nieprawidłowe i właśnie tam się gubisz.

Nie widzę, jak każda historia może być negocjowalna - wszystkie są wymagane do działającego kompilatora

To nie jest prawda. Możesz obsługiwać podzbiór języka i nadal mieć kompilator, który działa pod pewnymi warunkami. Z pewnością mniej wartościowy niż pełny kompilator, ale wciąż cenny.

Ponadto źle rozumiesz, co oznacza „do negocjacji”: niekoniecznie oznacza to „opcjonalne” i nie ma wymogu, aby opowiadania były opcjonalne w INVEST. Historia jest cennym celem, a negocjacje dotyczą tego, jak ją osiągnąć. Na pewno będzie więcej niż sposób implementacji backendu dla każdej funkcji języka. Tam potrzebujesz negocjacji.

Wszystkie historie mają jednakowy priorytet i nie ma znaczenia, w jakiej kolejności je dostarczę.

To nie jest poprawne, jak mówisz poniżej, że niektóre historie nie są „must have”, więc na pewno niektóre są mniej wartościowe. Ale nawet w kategorii „must have”: niektóre cechy językowe są znacznie bardziej fundamentalne niż inne, i wymiernie.

Jednym ze sposobów zmierzenia tego jest „o ile więcej wierszy kodu możemy skompilować na istniejącej bazie kodu” lub „o ile więcej testów przechodzi”, jeśli masz predefiniowany zestaw testów.

Istnieją również inne opcje. Jeśli zostały kompilacji C-jak język, ściśle mówiąc tylko potrzebują ifi gotopętlę mieć (prawie) Język funkcjonalny i można wdrożyć while, fora repeatjako makra. Zakładając, że napisanie użycia prekompilatora jest dość łatwe, możesz mieć tanie rozwiązanie stopgap (hej, negocjujemy? :-)

Jeśli chodzi o adaptację, obsługa języka jest dość statycznym zestawem wymagań, ale języki również się zmieniają, a także zmienia się twoja wiedza na temat twoich potrzeb . Potrzebujesz wszystko zaimplementować? Czy są rzeczy, których nie potrzebujesz specjalnie do swoich celów? Jednym z podstawowych najemców zwinnych jest wiedza o niepełnej wiedzy, czy możesz ją wykorzystać?

Podsumowując, aby bardziej bezpośrednio odpowiedzieć na twoje pytanie: czy potrzebujesz zwinnych procesów, gdy twoje wymagania są niezmienne? Absolutnie nie! Czy są użyteczne? Prawdopodobnie tak! Czy są warte twojego czasu? Prawdopodobnie nie - ale czy twoje wymagania są niezmienne? Z moich wcześniejszych doświadczeń „niezmienne wymagania” => „leniwy właściciel produktu” - nie jest regułą, ale warto o tym pamiętać.

TL; DR

Wszystkie mechanizmy zarządzania projektami zwiększają koszty. Nie dodawaj narzutu, którego nie potrzebujesz.

Scrum jest tutaj niewłaściwym młotem (Don't Be a Nail)

Scrum to struktura zarządzania projektami, a nie zestaw praktyk programistycznych odpowiednich dla poszczególnych programistów. O ile nie zajmujesz się zarządzaniem projektami, Scrum jest prawdopodobnie złym wyborem.

Ponadto, gdy mówisz:

Wszystkie historie mają jednakowy priorytet i nie ma znaczenia, w jakiej kolejności je dostarczę. Muszę zrobić je wszystkie.

sugerujesz kilka rzeczy:

1. Projekt ma zerową wartość, chyba że wszystkie historie są w 100% kompletne.
2. Historie nie są od siebie zależne.

Jeśli oba te stwierdzenia są prawdziwe, to naprawdę nie ma sensu używać ram lub praktyki zaprojektowanej w celu nadania priorytetu pracy według wartości lub kolejności zależności.

Sugerowane alternatywy

Każdy projekt programistyczny może potencjalnie skorzystać z niektórych zwinnych praktyk. W szczególności w twoim konkretnym przypadku poleciłbym:

1. Upewnij się, że wszystkie twoje historie mają „definicję ukończenia” obejmującą testy jednostkowe i akceptacyjne.
2. Często integruj i refaktoryzuj; nie pozostawiaj sobie wielkiego zadania integracyjnego na końcu projektu.

Dodatkowo, nawet jeśli twój produkt naprawdę ma zerową wartość, chyba że wszystkie historie są skończone, poświęciłbym trochę czasu na grupowanie historii w tematy, które można traktować jako ukończone kamienie milowe. Możliwość powiedzenia „Ukończyłem funkcję foo” jest często bardziej przydatna niż powiedzenie „Mam ukończone 23/117 losowych historii”. YMMV.

Rozumiem twoje obawy, ale uważam, że korzystanie z scrum nadal ma dla ciebie wartość.

Trzeba przyznać, że historie użytkowników są znacznie bardziej ustalone niż w przypadku aplikacji dla konsumentów. Ten aspekt scrum zapewni mniejszą wartość.

Myślę, że zyskasz na wartości w iteracyjnych i częstych wydaniach . Posiadanie potencjalnie wydawanego produktu na końcu każdego sprintu zmusza do utrzymania wysokiej jakości kodu i niskiego zadłużenia technicznego. To także świetny sposób na wczesne wykrycie wad.

Myślę, że przydałaby ci się również znajomość swojej prędkości . Po kilku sprintach możesz zobaczyć, ile punktów wysiłkowych Twoja drużyna kończy na każdym sprincie. To daje obiektywne dane, które pomogą ustalić datę wysyłki.

Przede wszystkim pamiętaj, że zwinny jest przymiotnikiem . Pod koniec każdego sprintu powinieneś odbyć spotkanie retrospektywne, a następnie dostosować swój proces do swoich potrzeb. Jeśli istnieje część procesu scrum, która nie dotyczy rozwoju kompilatora, usuń go. Jeśli istnieje inny element procesu, który byłby dla Ciebie korzystny, dodaj go. Moim zdaniem najważniejszą częścią zwinności jest bycie świadomym swojego procesu i ciągłe doskonalenie się w konkretnej sytuacji.

(Uwaga: nigdy nie robiłem scrum na projekcie kompilatora; posłuchaj mojej rady z odrobiną soli).

Tak, o ile pamiętasz, że Scrum nie jest zbiorem ścisłych zasad, których należy przestrzegać. Możesz dostosować go do swojego projektu. Sprinty, standupy, cotygodniowe scrumy nadal będą przydatne w celu wspierania lepszej komunikacji między członkami zespołu i zapewnienia, że ​​projekt będzie kontynuowany w zamierzonym kierunku.

Wszystkie historie mogą wydawać się mieć jednakowy priorytet, ale musisz wziąć pod uwagę względną trudność ich wdrożenia. Nie chcesz zatrzymać najtrudniejszych przedmiotów do końca projektu. Będziesz chciał zacząć nad nimi pracować jak najszybciej.