W dzisiejszych czasach każdy chce być zwinny. W każdym zespole, z którym pracowałem, kształt zwinnego był inny. Niektóre rzeczy są powszechne - jak codzienne wstawki lub planowanie, ale inne części znacznie się różnią.
W moim obecnym zespole jest jeden szczegół, który mnie niepokoi. To brak wymagań funkcjonalnych. Nie tylko nie ma pisemnej formy oczekiwań, ale także w zadaniach niejasno określono, co należy zrobić.
Celem projektu jest przepisanie starego systemu przy użyciu nowych technologii. Stary system również nie ma żadnej rozsądnej dokumentacji. Na pewno jeden nie istnieje. Opis wymagań właścicieli firm brzmi - zróbmy to w nowej implementacji w taki sam sposób, jak stary. Wydaje się rozsądne, ale tak nie jest. Stary system jest rodzajem kodu spaghetti, a wyodrębnianie z niego wymagań biznesowych jest kosztowne. Wydaje się, że sytuacja wpływa negatywnie na planowanie. Na pewno jest podatna na błędy i błędy w nowej implementacji (pomijając niektóre szczegóły).
Dlatego myślę - czy naprawdę zwinne jest brak wymagań biznesowych w przypadku przepisywania starego systemu?
źródło
Odpowiedzi:
Niezależnie od tego, czy brak wymagań funkcjonalnych jest sprawny, jest to przepis na katastrofę. Nie możesz odbudować systemu, jeśli nie wiesz, jak on działa.
Musisz powiedzieć właścicielowi firmy, że nie masz pojęcia, jak działa stary system.
Najlepszą opcją jest współpraca z właścicielem firmy lub kilkoma doświadczonymi użytkownikami, aby zrozumieć procesy biznesowe w grze i opracować własne testy akceptacyjne. Jeśli możesz pracować z niektórymi użytkownikami końcowymi, możesz uzyskać więcej opinii na temat działania starego systemu.
W przeciwnym razie musisz przeprowadzić testy eksploracyjne w środowisku nieprodukcyjnym, aby poznać własne wymagania. Wiele razy, gdy właściciel firmy mówi „spraw, aby działał jak stary”, są ograniczeni na czas i nie są w stanie ci pomóc, tak jak powinien. Potrzebujesz wiedzy niektórych doświadczonych użytkowników lub wielu ręcznych testów z twojej strony, aby zrozumieć, jak działa stary system.
Poinformuj właściciela firmy, że brak wymagań i zrozumienie starego systemu znacznie wydłuży czas potrzebny na jego odbudowę - około trzykrotnie lub dłużej. W obliczu zwiększonego harmonogramu i kosztów, właściciel firmy albo udzieli Ci wiedzy specjalistycznej niezbędnej do szybszego zebrania wymagań, albo zdecyduje, że przepisywanie nie jest obecnie ekonomicznie wykonalne.
Otrzymasz jedną z następujących czynności:
źródło
Zwinne nie zmienia potrzeby wymagań funkcjonalnych, ale ogólnie zmienia sposób ich gromadzenia . Nie zwinny sposób polega na tym, że ktoś przejdzie długi proces, a następnie dostarczy jakiś dokument zawierający wszystkie wymagania dla systemu.
Zwinny sposób zbierania wymagań polega na współpracy w celu określenia wymagań dotyczących małego przyrostu systemu, zbudowania go, a następnie uzyskania informacji zwrotnej i wykonania następnego przyrostu. W twojej sytuacji, w której masz problemy z zainicjowaniem procesu przez właścicieli firm, zacznę od spędzenia około pół dnia na badaniu części starego systemu, nad którą chcesz dalej pracować, i wygenerowaniu listy pytań dotyczących wymagań.
Następnie usiądź z właścicielami firmy i zadaj im pytania. Na niektóre pytania będą mogli łatwo odpowiedzieć, na niektóre łatwiej odpowiedzieć, patrząc na kod, a na niektóre trudno odpowiedzieć w obu przypadkach. Podziel trudne pytania na coraz mniejsze części, aż dojdziesz do czegoś, na co można odpowiedzieć.
Celem jest uzyskanie wystarczającej ilości odpowiedzi na pytania w celu zbudowania czegoś, uzyskania opinii i ponownego uruchomienia procesu. Pamiętaj, że im mniejsze zmiany i krótszy cykl sprzężenia zwrotnego, tym mniejsza sprawa, jeśli zbudujesz niewłaściwą rzecz.
źródło
Przechwytywanie wymagań jest istotną częścią każdego (udanego) projektu oprogramowania. Ale pisanie specyfikacji wymagań nie jest.
Podejście zorientowane na dokumentację może skończyć się jak gra chińskich szeptów: ekspert tematyczny wyraża wymóg, analityk zapisuje to, deweloper próbuje napisać coś, co jest zgodne z opisem analityka, użytkownik końcowy jest zdezorientowany, ponieważ oprogramowanie nie nie rozwiążą ich problemu.
Techniki zwinne sugerują, że programiści powinni zbierać wymagania bezpośrednio od ekspertów merytorycznych, zwykle użytkowników końcowych. Można to zrobić na wiele różnych sposobów, na przykład rozmawiając o przykładowym scenariuszu z MŚP. Deweloperzy są dobrzy w wykrywaniu przypadkowych przypadków i proszeniu MŚP o wyjaśnienie, w jaki sposób oprogramowanie powinno zachowywać się w tym przypadku.
Zamiast zbierać wszystkie wymagania z góry (ryzykując w ten sposób duże nieporozumienia), zwinne zespoły prawdopodobnie zaczną od niewielkiego wycinka wymagań, zbudują prototyp i użyją go do zebrania opinii na następną iterację.
Ponieważ zrozumienie wymagań zmienia się w czasie, specyfikacja wymagań statycznych przestanie być aktualna. Jak można temu zapobiec?
Wyrażając wymagania jako uruchamialne testy. Okazuje się, że „czytelna specyfikacja” i „uruchamialne testy” nie są koncepcjami wyłącznymi, ale mogą być jednym i tym samym dokumentem. Np. Ogórek i inne pomysły z przestrzeni BDD mogą być tutaj bardzo pomocne.
W przypadku przepisywania starego systemu oryginalny system może być doskonałym źródłem wymagań. Ale które aspekty są istotne? Czy w ogóle wykorzystywane są jego funkcje niszowe? Jakie błędy należy ponownie zaimplementować w celu zapewnienia zgodności? Zwykle nie ma obejścia dla rozmowy z użytkownikami końcowymi.
Posiadanie działającego systemu może być również bardzo pomocne w testowaniu nowego oprogramowania, ale nie ma to związku z żadnymi sprawami zwinnymi.
Zwróć uwagę, że projekty o ustalonym zakresie i czasie z nadchodzącymi terminami są przeciwieństwem zwinności. Normalne podejście zwinne polega na wybraniu fragmentu funkcjonalności i dostarczeniu go, a następnie iteracji. Najważniejsze rzeczy są wykonywane najpierw, mniej ważne później (lub nigdy). Jeśli wszystko jest ważne i MUSI być zrobione JAK NAJSZYBCIEJ, to nic nie jest ważne, a projekt prawdopodobnie niczego nie dostarczy.
W twojej sytuacji brak wymagań nie jest sprawną cechą, ale raczej przeciętnym przypadkiem dysfunkcji organizacyjnej. Jeśli chcesz, aby projekt się powiódł, musisz znaleźć sposób na przezwyciężenie tej dysfunkcji. Np. Wezwij właściciela firmy, aby nie pisał kompletnego dokumentu wymagań, ale spróbuj zorganizować spotkanie, w którym wyjaśni swoje wymagania dotyczące najważniejszej funkcji. Szczegółowe informacje można znaleźć w starym systemie. Następnie zaimplementuj tę funkcję i iteruj.
źródło
Oto jak to zrobiliśmy. Rozmawialiśmy z właścicielami. Rozmawialiśmy z kierownikami. Rozmawialiśmy z użytkownikami wykonującymi pracę. To, co znaleźliśmy, siedząc przy biurku użytkownika i obserwując (i zadając pytania) było niezwykle przydatne. Menedżerowie wiedzieli, z którymi użytkownikami powinniśmy usiąść.
Odkryliśmy, że niektóre części systemu rzeczywiście działały bardzo dobrze i mogliśmy łatwo napisać wystarczające wymagania, aby rozpocząć projektowanie i kodowanie oraz przypadki testowe i tak dalej, ale inne części miały pewne nieprzyjemne obejścia, których używali użytkownicy na podłodze, czego nie byli świadomi zarządcy i właściciele. W przypadku tych części starego systemu wróciliśmy do biznesu i trochę rozmawialiśmy o przepływie pracy i procesach, zanim zdołaliśmy ustalić, jakie powinny być mniejsze zadania, i tym samym podzielić je na jednostki, które wymagały naszej zwinnej metody.
Podczas gdy Agile mógł szybko wystartować w niektórych częściach systemu, inne musiały mieć trochę więcej myślenia i dokumentacji, zanim moglibyśmy zacząć.
źródło
Zbierasz wymagania w zwinnym frameworku i nikt nie wspominał historii użytkowników? Historia użytkownika jest zasadniczo definicją wysokiego poziomu tego, co oprogramowanie powinno być w stanie zrobić. Zazwyczaj wszelkie opinie lub prośby od firmy lub użytkownika końcowego mogą być napisane jako historia użytkownika. ... Możesz zaakceptować kryteria akceptacji jako wymagania funkcjonalne, które wspierają historię użytkownika.
źródło
To pytanie wskazuje, co poszło nie tak z ruchem zwinnym. To nie wina osoby zadającej pytanie; Cały czas wpadam w tę pułapkę, ponieważ nauczyły mnie lata życia korporacyjnego.
Pułapka, o której mówię, polega na tym, że istnieje przepisany i poprawny zwinny sposób działania. Może to być spowodowane tym, że ludzie myślą, że zwinny istnieje. Nie można zrobić Agile więcej niż można zrobić pragmatyczne.
Brak „specyfikacji funkcjonalnych” lub czegokolwiek, brzmi niepokojąco, ale może nie być. Ile szczegółów potrzebujesz, aby zacząć? Bezpieczeństwo i wydajność są oczywiste i znane od samego początku. W przeciwnym razie, czy jest to silnik wyceny opcji, czy aplikacja zegara?
Czy będzie ciągłe wydawanie, dyskusja, nauka, cofanie się i zmiana oprogramowania? Czy budujecie miękkiej towar lub sprzętu?
Programiści pracujący w procesie wodospadu często nie angażują się do późniejszego etapu, co stanowi problem. Zaangażowanie ich wcześniej lub od samego początku oznacza, że są wtajemniczeni w rzeczy niejasne, niezdefiniowane i na wpół upieczone, co wydaje się denerwować długoletnich programistów, podczas gdy w rzeczywistości częścią ich pracy jest zadawanie pytań, takich jak „jakie są wymagania funkcjonalne dla tej rzeczy, którą zbudujemy? ”
Identyfikacja dziur w planie nie polega na znalezieniu usterki, to tylko rozwój oprogramowania.
Z tego powodu uwielbiam odpowiedź Guya.
źródło