Wahałbym się tak szybko odrzucić Wodospad na całej planszy.
Chociaż jest to wadliwy model do faktycznego budowania systemów oprogramowania, nie jest złym modelem nauczania instruowanie dobrych praktyk na każdym etapie cyklu życia. Niezależnie od modelu procesu, który zastosujesz do projektu, nadal wykonujesz inżynierię wymagań, architekturę i projekt systemu, wdrażanie, testowanie, wydawanie i konserwację (w tym refaktoryzację i ulepszanie). Różnica polega na tym, w jaki sposób fazy te są zorganizowane i prowadzone, ale wszystkie działania nadal się odbywają.
Twierdzę, że przejście z Waterfall do Scrum w środku projektu nie jest najlepszym pomysłem. Kluczem do sukcesu Scrum jest długofalowy projekt. Pierwsze trzy do pięciu sprintów to zespół, który dostosowuje się do prędkości, uczy się procesu i rozwija zespół. Chociaż wykonujesz ruchy, w tym momencie tak naprawdę nie jest to Scrum. Ponadto próba stworzenia programu opartego wyłącznie na Scrumie jest prawdopodobnie złym pomysłem, ponieważ Scrum nie jest srebrną kulą - lepiej jest uczyć najlepszych praktyk niż jednej metody. W przypadku siły roboczej nie wszystkie projekty będą wykorzystywać Scrum. W rzeczywistości w niektórych środowiskach Scrum byłby szkodliwy dla powodzenia projektu.
Znalazłeś już problemy ze Scrumem w środowisku akademickim, a niektóre z nich są trudne do odpowiedniego rozwiązania.
Brak problemu na liście niezgodności polega na tym, że oszacowanie jest trudne. Tak to jest. Ale jedynym sposobem na lepsze oszacowanie jest oszacowanie i porównanie wartości rzeczywistych z oszacowaniami. Uczniowie powinni szacować wielkość, czas i wysiłek przy użyciu różnych środków (punkty historii, wiersze kodu, godziny, strony, osobogodziny) wcześniej, aby byli bardziej przygotowani do tego po ukończeniu studiów i przyjęciu siły roboczej.
Potrzebę dokumentacji można rozwiązać zarówno z perspektywy profesora, jak i studentów. Podejścia Lean mówią nam, że dokumentacja, która nie dodaje wartości ani zespołowi, ani klientowi, jest marnotrawstwem (pod względem czasu i kosztów). Jednak potrzebna jest dokumentacja, aby osiągnąć różne cele zarówno studentów, jak i profesora (klienta / klienta) do różnych celów. Ogólnie rzecz biorąc, wydaje się to okazją do nauczenia dostosowywania procesów i ilościowego zarządzania projektami (co ma znaczenie nawet w zwinnych metodach).
Jeśli chodzi o spotkania i harmonogramy Scruma, przychodzą mi na myśl dwa pomysły. Po pierwsze, oznacza to, że Scrum może nie być najlepszym procesem do zastosowania w środowisku akademickim. Nie ma jednego „najlepszego modelu procesu” dla projektów oprogramowania, z takimi czynnikami, jak harmonogram, personel, widoczność i doświadczenie zespołu programistów (między innymi).
Ogólnie sugeruję podkreślanie dobrych praktyk, dostosowywania procesów i doskonalenia procesów w porównaniu z pojedynczymi metodologiami. Dzięki temu będziesz najbardziej skuteczny dla wszystkich biorących udział w kursach i udostępnisz je różnorodnym metodologiom procesu oraz zrozumiesz, jakie są najlepsze praktyki dla danego zestawu warunków.
Ponieważ pracujesz nad stworzeniem programu uniwersyteckiego, przedstawię ogólny przegląd tego, w jaki sposób program inżynierii oprogramowania na uniwersytecie, na którym studiowałem, pasował do siebie.
Wstępna inżynieria oprogramowania przeszła przez projekt w modelu wodospadu, a wykłady podczas każdej fazy odpowiadały różnym sposobom prowadzenia działań w tej fazie. Zespoły przechodziły przez kolejne fazy w tym samym tempie. Dopasowanie tych jasno określonych granic dobrze wpisało się w model nauczania dla grupy osób bez doświadczenia w pracy z zespołami przy tworzeniu oprogramowania. W trakcie kursu odwoływano się do innych metodologii - różnych metod zwinnych (Scrum, XP), Rational Unified Process, Spiral Model - w odniesieniu do ich zalet i wad.
Pod względem działań odbyły się specjalne kursy poświęcone inżynierii wymagań, architekturze i projektowaniu (dwa kursy - jeden koncentrujący się na szczegółowym projektowaniu z wykorzystaniem metod obiektowych, drugi koncentrujący się na architekturze systemu), szereg kursów koncentrujących się na projektowaniu i wdrażaniu różnych klasy systemów (systemy czasu rzeczywistego i wbudowane, systemy korporacyjne, systemy współbieżne, systemy rozproszone itp.) oraz testowanie oprogramowania.
Istnieją również trzy kursy poświęcone procesowi oprogramowania. Zarządzanie procesami inżynierii oprogramowania i zarządzanie projektami, które koncentrują się na najlepszych praktykach zarządzania projektem oprogramowania w odniesieniu do wielu metod. Drugi kurs procesu uczy pomiarów, metryk i doskonalenia procesów (podkreślając CMMI, Six Sigma i Lean). Wreszcie, istnieje kurs procesowy, który uczy zwinnego tworzenia oprogramowania (Scrum, Extreme Programming, Crystal, DSDM omówione) przy użyciu projektu przeprowadzonego przy użyciu metodologii Scrum.
Projekt „capstone” był dwumeczowym projektem, który został zrealizowany dla firmy sponsorującej i prowadzony w całości przez studencki zespół projektowy, pod przewodnictwem sponsorów i doradcy wydziału. Każdy aspekt prowadzenia projektu należy do studentów, w ramach jakichkolwiek ograniczeń określonych przez sponsorów. Jedynymi terminami wyznaczonymi przez uniwersytet były tymczasowa prezentacja w połowie (10 tygodni) projektu, końcowa prezentacja na końcu i prezentacja plakatu quad na krótko przed końcem. Wszystko inne zależało od sponsora i zespołu.