Obecnie współpracuję z profesorem na moim uniwersytecie, aby opracować nowe programy nauczania dla kursów inżynierii oprogramowania i projektowania Capstone oferowanych na mojej uczelni.
Do niedawna oba kursy korzystały wyłącznie z modelu wodospadu, dlatego uczniowie spędzali większość czasu na pisaniu długich raportów. Po mojej dużej presji mój profesor postanowił włączyć Scrum do programu inżynierii oprogramowania w ostatnim semestrze.
Pierwsza połowa semestru była wciąż wodospadem, a studenci pisali 40-stronicowe raporty projektowe i dokumenty specyfikacji oprogramowania. W połowie semestru wszystkie zespoły były zobowiązane do wydania wersji demo swoich aplikacji. W tym momencie kurs przeszedł na Scrum, z dwoma 3-tygodniowymi sprintami. Teraz próbujemy dowiedzieć się, jak całkowicie wyeliminować wodospad i stworzyć program oparty wyłącznie na Scrumie.
Niestety napotkaliśmy kilka niezgodności między Scrumem a uczniami:
- Codzienne spotkania Scruma są prawie niemożliwe dla studentów. Nawet podczas samej klasy uczniowie nie są w stanie odbywać spotkań Scruma, ponieważ profesor zazwyczaj wykłada.
- Szacowanie punktów / godzin jest trudne, ponieważ studenci są niedoświadczeni i dlatego nie mogą dokładnie przewidzieć, ile czasu to zajmie.
- Scrum najlepiej współpracuje z programistami pracującymi w pełnym wymiarze godzin, ale studenci też nie. Co najwyżej studenci przeznaczają 15-20 godzin tygodniowo na kurs, a organizowanie spotkań roboczych może być niezwykle trudne. Zespoły mogą mieć do 10 uczniów (i zawsze jest jeden lub dwa zwolenników).
- Profesorowie pragną dokumentacji! Nie słyszałem o żadnych raportach Scruma - tylko o zaległościach i wykresach wypalenia (które nie jestem pewien, czy wystarczą, by uspokoić naukowców).
- Studenci często zakładają, że zwinny oznacza „Wskocz od razu i zacznij kodować, nie oglądając się za siebie”. Prowadzi to do jednego z najstraszniejszych kodów, jakie można sobie wyobrazić. Dlatego szukam sposobu na wymuszenie prawidłowego projektu bez wymagania 50-stronicowego dokumentu lub stosu diagramów UML.
Biorąc pod uwagę te problemy, jak myślisz, jak mój profesor i ja możemy dostosować Scruma do funkcjonowania w środowisku akademickim (i czy powinniśmy w ogóle zawracać sobie głowę Scrumem)? Czy nadal warto uczyć modelu wodospadu?
Z góry dziękuję za wszelkie opinie!
Odpowiedzi:
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.
źródło
Kiedy ukończyłem inżynierię oprogramowania, odbyłem kurs o nazwie Software Process, który dotyczył XP, Scrum i innych zwinnych podejść. Zasadniczo cała klasa założyła hipotetyczną firmę produkującą oprogramowanie i poinstruowano ją, aby opracowała kawałek dość skomplikowanego oprogramowania w czasie trwania kursu. Wykłady dotyczyły takich rzeczy, jak praktyki XP, spotkania stand-up itp.
Większość studentów słyszała o tych technikach i zwykle chętnie je stosuje. Oczywiście nie ma sposobu, aby zmusić zespół do pracy iteracyjnej itp. Ale o to właśnie chodziło: samemu stać się motywacją do organizowania wielu krótkich spotkań, pracy iteracyjnej, ciągłych kompilacji itp., Ponieważ szybko odkrywasz jest to po prostu najłatwiejszy i najbardziej niezawodny sposób na wytworzenie czegoś wartościowego z grupą ludzi i niewielką ilością czasu.
Jedną rzecz do zapamiętania: upewnij się, że dobrze grasz z klientem i zmienisz niektóre kluczowe wymagania w połowie. Lub „zapomnij” wspomnieć o nich na początku.
źródło
Czy celem jest ułatwienie rozwoju, nauka Scruma lub - jak sądzę - jedno i drugie? Rozważę krótsze sprinty, aby przyspieszyć proces uczenia się.
Być może możesz zastąpić codzienne stójki mniej rygorystyczną formą, gdy najlepiej sprawdza się dla studentów. Ponadto nie każdy musi uczestniczyć w każdym spotkaniu.
Oszacowanie czasu kalendarzowego jest jeszcze trudniejsze, z tych samych powodów :-) W punktach fabularnych nie oceniasz, ile czasu zajmie: szacujesz jego względny rozmiar. Czas trwania jest wyprowadzany.
Może spróbuj z mniejszymi zespołami? 10 jest w górnej skali dla zespołu Scrum. Myślę, że możesz odnieść sukces także w zespołach rozproszonych w pełnym wymiarze godzin, ale oczywiście jest trudniej! Niech to będzie lekcja sama w sobie.
Scrum nie określa, jaka dokumentacja jest wymagana. W rzeczywistości nawet wykresy wypalenia nie są obowiązkowe. Nie oznacza to, że dokumentacja jest zabroniona: zespół powinien przedstawić niezbędną dokumentację, w tym raporty, które profesorowie uznają za konieczne.
Nie tylko studenci :-) Większość zespołów Scrumowych stosuje praktyki XP, takie jak TDD (Test Driven Development) i refaktoryzacja: Proponuję włączyć to do programów nauczania.
Tak, przynajmniej z dwóch powodów: po pierwsze, nie jest pewne, czy uczniowie będą używać Scruma w życiu zawodowym, a po drugie, wyobrażam sobie, że łatwiej jest zrozumieć istotę zwinnego rozwoju, jeśli masz coś do porównania.
źródło
Brzmi trochę podobnie do tematu, który podjąłem raz.
Kilka myśli:
źródło
Radzę oddzielić i odizolować to, czego próbujesz uczyć. Jeśli jest to kurs projektowania oprogramowania lub inny przedmiot inżynierii oprogramowania (algorytmy lub coś w tym rodzaju), skoncentruj się na tym. Jeśli zaangażowanie SCRUM staje się przeszkodą (jak sugerujesz), nie przejmuj się nim.
Jak to zrobiliśmy, kiedy byłem na studiach, miałam specjalny kurs dla zwinnych metodologii. Kurs obejmował projekt programistyczny, który miał zostać uruchomiony zgodnie z SCRUM lub XP. Rzeczywiste oprogramowanie, które miało zostać dostarczone, było trywialne, ponieważ celem kursu nie było programowanie ani projektowanie, ale proces. Rozumowanie tutaj jest takie samo, dlaczego nie należy mieszać „twardego rdzenia” tematów rozwoju oprogramowania z przedmiotami metodologicznymi, ponieważ jedno ma tendencję do zaćmienia drugiego, a studenci w większości nie są gotowi ani wystarczająco wykwalifikowani, aby poradzić sobie z nimi na tym etapie.
Rezultaty kursów to między innymi raporty z planowania sprintu, cotygodniowe raporty z postępów, retrospektywy, raporty z wypalenia oraz co tydzień co najmniej dwie sesje, które obejmowały grupowe spotkanie stand-up / scrum, podczas którego pracownicy pomocy technicznej mogliby rozesłać i nasłuchiwać.
Kurs obejmował także TDD (Test Driven Development) i działał naprawdę dobrze.
Z pewnością tak jest. Wiele firm używa wersji tego modelu do swoich projektów (PPS, RUP, PROPS itp.). Wielu uważa (słusznie, moim zdaniem), że „czysty” SCRUM lepiej nadaje się do bieżącej konserwacji niż do projektów. SCRUM (i ogólnie Agile) wymaga pewnej elastyczności w zakresie oraz możliwości negocjowania wymagań i dostawy po drodze. Nie wszystkie projekty działają w ten sposób, są binarne: dostarczaj X w punkcie czasu Y, wszystko inne jest błędem.
źródło
Celem akademickiego kursu inżynierii oprogramowania jest nauczenie podstawowych etapów cyklu życia oprogramowania - analizy, projektowania, wdrażania, testowania wraz z wykorzystaniem rzeczywistych standardów jakości oprogramowania zamiast zwykłego kodu jakości pracy domowej.
Wykazanie, że praktyka odbywa się za pomocą procesu niepochodnego ma wartość , jednak z powodów, o których wspominałeś, SCRUM nie jest odpowiednim procesem - studenci biorą wiele kursów w semestrze, wielu ma również prawdziwą pracę podczas nauki, dlatego nie możesz mieć 100 % oddanych członków zespołu lub prowadzą codzienne spotkania.
Zastanów się nad zastosowaniem mniej zwinnego procesu iteracyjnego, takiego jak UP (RUP).
Aby pokazać wartość w porównaniu z procesem kaskadowym, zmień wymagania między iteracjami. To pokaże różnicę między UP a wodospadem oraz podpowiedź do wartości zastosowania zwinnych procesów.
Demonstracja wodospadu po tym stanie się zbędna, ponieważ UP obejmuje wszystkie etapy wodospadu.
Ponieważ semestry są stosunkowo krótkie, 2 małe iteracje byłyby realistyczne.
Zapewnij uczniom szerokie ramy, ponieważ nacisk ten nie powinien kłaść się na głębokość wdrożenia, są do tego inne kursy, zamiast tego powinny kłaść nacisk na standardy kodowania i testy jednostkowe.
Podczas zajęć wykłady uczą teorii kilku procesów, np. Wodospadu, UP, XP, SCRUM i Kanban (wraz z innymi tematami, np. Wymaganiami pisania, UML, testowaniem itp.).
Dla studentów, którzy ukończyli powyższy kurs, rozważ oddzielne warsztaty SCRUM jako fakultatywne, które trwają dwa tygodnie w pełnym wymiarze godzin w semestrze letnim.
źródło
Scrum działa, jeśli masz projekt semestralny / semestralny, a klasa jest podzielona na 6 do 10 osób. Następnie możesz poświęcić ostatnie 10 minut zajęć na spotkanie na scrum.
źródło