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


15

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?


1
@Sklivvz zaktualizowany ma większy sens?
Dave Hillier

1
Jako alternatywę dla scrum, spójrz na kanban. Oba są zwinne, ale kanban AFAIK jest lepszy dla rodzaju pracy, którą wykonujesz, podczas gdy scrum jest lepszy dla pracy, którą można podzielić na różne priorytety.
Izkata

@Izkata Kanban nadal oczekuje priorytetowej kolejki wejściowej, według wartości lub czasu przybycia. Propozycja wartości „wszystko albo nic” jest podstawowym blokerem przy rozważaniu dowolnego iteracyjnego modelu rozwoju.
CodeGnome

@CodeGnome Hm .. Przyznaję, że nie zrobiłem kanban, ale zrozumiałem, że dobrze jest mieć wiele nadrzędnych rzeczy, jak opisano w tym pytaniu: Jeśli pracujesz dla każdej karty we własnym oddziale, połącz się z pniem, gdy jest ukończone, to jedna „iteracja” / wydanie. Po prostu zachodzą na siebie, w przeciwieństwie do sprintu w scrum.
Izkata

2
Wymagania się nie zmienią. Po prostu nie możesz już w to uwierzyć.
JeffO

Odpowiedzi:


22

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!


1
Wymagania zawsze się zmieniają i myślenie, że nie zmieni się, dopóki kod nie zostanie napisany i zatwierdzony (zakładając, że osoby odpowiedzialne przestrzegają zasad) jest po prostu zaprzeczeniem.
JeffO

@JeffO Zgadzam się: zmieniające się wymagania są pożądaną cechą zwinności, na przykład dlatego mamy dema.
Sklivvz

1
@JeffO Jeśli chcesz nitpick, wymagania nie zawsze się zmieniają, prawie zawsze tak. Niezależnie od tego zmienię sformułowania.
vaughandroid

1
Uważam tę odpowiedź za niesmaczną. „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”. Ale zbudowanie frameworku może wymagać 6 miesięcy pracy, zanim zbuduje się nawet najmniejszy program! To nie jest realistyczna odpowiedź opisująca zastosowanie zwinnego podejścia do systemu backend.
Dan Nissenbaum,

10

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ć.


3
+1 dla „ To nie jest prawda. Możesz obsługiwać podzbiór języka i nadal mieć kompilator, który działa w określonych warunkach. Z pewnością mniej wartościowy niż pełny kompilator, ale nadal cenny. ” Ponieważ to tworzy jednostkę testowalną i użyteczną przed koniec rozwoju.
Ross Patterson

2
A także „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.” - Myślę, że ważne jest, aby móc wykazać postęp.
Dave Hillier

+1, choć brakuje mi tutaj jednego punktu, że wymagania dla kompilatora można również wycinać „poziomo” zamiast „obsługuje funkcję języka X”. Kompilator może wymagać optymalizacji (własne wymagania), może wyświetlać informacje debugowania (własne wymagania), może spełniać pewne wymagania dotyczące wydajności i tak dalej.
Doc Brown

Wymagania @DocBrown z pewnością mogą być horyzontalne, ale historie muszą być pionowe.
Sklivvz

„Jako użytkownik kompilatora chcę wejść DavesCompiler -O9 program.c, a wyjście powinno być wysoce zoptymalizowaną wersją programu. C (bardziej formalna definicja tego, co oznacza wysoce zoptymalizowany)” - brzmi dla mnie jak rozsądna historia użytkownika.
Doc Brown

4

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.


1
Nie twierdziłem, że jestem indywidualnym programistą.
Dave Hillier

@DaveHillier „Mam już język ... Prawdopodobnie spróbuję tego do ... Planuję podążać za Scrumem”. Nic z tego nie mówi o zespołach, innych ludziach ani o potrzebie formalnego zarządzania projektami. Nawet jeśli nad projektem pracuje 347 osób, odpowiedź jest nadal ważna, jeśli przesłanka jest prawidłowa. Jeśli nie, zaktualizuj swoje pytanie, a ja dołożę wszelkich starań, aby odpowiednio zaktualizować odpowiedź.
CodeGnome

1
Nikt inny nie przyjął takiego założenia. Zgadzam się z niektórymi z tego, co napisałeś.
Dave Hillier

4
@DaveHillier Przeczytałem twoje pytanie w taki sam sposób jak CodeGnome, że będziesz solowym programistą tego projektu. Nadużywanie Izamiast Wejest prawdopodobnie powodem.
Izkata

Niewłaściwe narzędzie, a nie zły młot. Młot jest młotkiem, nie wszystkie problemy są gwoździami :-)
Sklivvz

2

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).


0

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.


Scrum is not a set of strict rules to follow- Myślałem, że jest dokładnie odwrotnie. Czy to nie tak, że ma tylko kilka zasad, ale musisz się ich trzymać (np. Daily Standups, Definition of Done, Story Story)?
Uooo

Czy jesteś zwolennikiem ScrumBut ?
Dave Hillier

@Uooo tylko pierwszy z trzech, o których wspominasz, to Scrum, reszta to tylko dobre praktyki, ale nie ściśle fundamentalne.
Sklivvz

@ Sklivvz Czy to dlatego wielu kierowników projektów myśli „robimy codzienne awarie, więc robimy scrum” ? Scrum to coś więcej niż codzienne pojedynki.
Uooo

1
@Sklivvz dobrze, teraz rozumiem, co masz na myśli :-) Myślałem, że masz na myśli tylko robienie pojedynków, to już scrum.
Uooo
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.