Jak stworzyć doskonałe oprogramowanie za pomocą zwinnych metod?

Kano model zadowolenia klienta określa różne klasy funkcji produktu. Wśród nich są

1. Niezbędne cechy: jeśli nie zostaną wdrożone, klient nie zaakceptuje produktu.

2. Atrakcyjne cechy (zachwycające): cechy, których klient często nawet nie oczekuje, ale wywołują emocje i radość, gdy zostaną odkryte.

Atrakcyjne cechy mają oczywiście dużą wartość biznesową. Sprawiają, że ludzie kupują Ferrari za 500.000, gdy używany Fiat za mniej niż 5.000 spełni wszystkie niezbędne wymagania.

Jednak wszystkie zwinne procesy, które znam, zdecydowanie sprzyjają wymaganiom, które należy spełnić. Zawsze mają najwyższy priorytet. Wydaje się, że nawet w zwinnym miejscu nie ma miejsca na atrakcyjne cechy.

Wierzę, że zwinne procesy są bardzo przydatne w tworzeniu oprogramowania. Ale jak można je zastosować, aby stworzyć zachwycające produkty wysokiej jakości, a nie tylko absolutne minimum, które ledwo spełnia niezbędne wymagania?

Dodatek: Jak wskazały dwie pierwsze odpowiedzi, sensowne jest nadanie obowiązkowym wymogom najwyższego priorytetu. Ale czy my (i klient) naprawdę zawsze wiemy z góry, jakie są niezbędne wymagania. Doświadczyłem już kilka razy, że wymagania, które na początku miały wysoki priorytet, okazały się o wiele mniej ważne, jeśli nie bezużyteczne, później. Dlatego uważam, że nie należy niewolniczo koncentrować się na obowiązkowych wymaganiach.

Formalna odpowiedź brzmi: źle zrozumiałeś zwinny, zwinny nie narzuca wymagań, robią to interesariusze. Istotą zwinności nie jest wyrzeźbienie twoich wymagań w kamieniu, ale raczej sprawienie, by pojawiły się one w trakcie podróży, w ścisłym kontakcie z klientem, korzystając z progresywnych informacji.

Ale to wszystko teoria. To, czego doświadczyłeś, jest w rzeczywistości wspólną cechą wielu linii produkcyjnych oprogramowania, które przyjęły zwinny sposób działania.

Problem polega na tym, że słuchanie klienta i szybkie reagowanie na jego potrzeby często kończy się czasem brakiem myślenia o produkcie lub projektowaniem. To, co kiedyś było proaktywnym procesem zasilanym przez wizję i wiedzę fachową, może i często przerodzi się w pasywny, całkowicie reaktywny proces zasilany przez życzenia klienta. Doprowadzi to do zrobienia absolutnie niezbędnych rzeczy, które „wykonają robotę”.

Samochód nigdy nie zostałby wynaleziony, gdyby producenci w tamtym czasie byli „zwinni”, ponieważ wszyscy klienci prosili o to, by był szybszym koniem.

Nie czyni to jednak zwinnym. To trochę jak komunizm. Świetny pomysł, który prawie nigdy nie działa dobrze, ponieważ ludzie są tylko ludźmi i robią ludziom rzeczy. A metoda / ideologia / religia uświadamia im, że dobrze sobie radzą, dopóki wykonują ruchy i / lub przestrzegają zasad.

[edytować]

Slebetman:

To ironiczne, że zwinny ewoluował z branży automatyki (mianowicie Toyota).

Pamiętasz złotą zasadę automatyzacji? „Najpierw zorganizuj, a następnie zautomatyzuj”. Jeśli zautomatyzujesz uszkodzony proces, najlepsze, co może się zdarzyć, to przyspieszenie wszystkiego, co pójdzie nie tak. Ludzie w Toyocie nie byli idiotami.

Typowym powodem przyjęcia każdej nowej metodologii jest to, że nie wszystko idzie dobrze. Kierownictwo to uznaje, ale mogą nie rozumieć podstawowych problemów. Zatrudniają więc tego guru, który wygłasza mowę o Agile i Scrumie. I wszyscy to uwielbiają. Z ich własnych powodów.

Deweloperzy mogą myśleć: „Hej, to może zadziałać. Bylibyśmy bardziej zaangażowani w problemy biznesowe i moglibyśmy zapewnić wkład w wypełnienie tego zaległości. Może to być przeciwność, aby sprzedaż i obsługa klienta zrozumiały, co robimy, dlaczego jest to konieczne, i mielibyśmy je poza włosami, podczas gdy w przejrzysty sposób spalamy to, co uzgodniliśmy ”. Nigdy więcej „przestań robić to, co robisz, musisz to zrobić teraz”, jakiś koleś, którego nie chcesz odkładać, wyskakuje przy biurku.

Z drugiej strony dział sprzedaży, obsługi klienta lub właściciel może postrzegać to jako sposób na uzyskanie (wstecznej) kontroli nad tą czarną skrzynką działu, który prawdopodobnie wykonuje niezbędne czynności. Nie widzą, co się tam dzieje, ale są prawie pewni, że sedno problemu jest gdzieś tam zakopane. Wprowadzają więc Scruma, instalują wybranego przez siebie właściciela produktu i nagle mają pełną kontrolę, wszystkie struny są w ich rękach. Co teraz? Ehrr ...

Prawdziwym problemem jest często to, że sklep nie był dobrze zorganizowany i to się nie zmieniło. Ludzi przypisano obowiązki, z którymi nie mogą sobie poradzić, a może mogą, ale pan Boss nieustannie ingeruje i rujnuje to, co zrobili, lub (najczęściej z mojego doświadczenia), kluczowe obowiązki nie zostały w ogóle uznane ani przypisane nikomu.

Czasami z czasem pojawia się nieformalna organizacja między formalnymi liniami. Może to częściowo zrekompensować brak formalnej struktury. Niektórzy ludzie po prostu robią to, w czym są dobrzy, niezależnie od tego, czy mają wizytówkę, aby to udowodnić, czy nie. Tępe wprowadzenie Agile / Scrum może zepsuć to natychmiast. Ponieważ oczekuje się, że ludzie będą grać według zasad. Uważają, że to, co robili, nie jest doceniane, zamiast tego dostają małe żółte kartki z krótkimi historiami, wiadomość brzmi: „cokolwiek robiłeś, nikogo to nie obchodziło”. Nie trzeba dodawać, że nie będzie to szczególnie motywujące dla tych osób. W najlepszym razie zaczną czekać na zamówienia i nie podejmą już żadnej inicjatywy.

Więc sprawy się pogarszają i wniosek będzie taki, że Agile jest do bani.

Zwinne nie jest do bani, świetnie nadaje się do projektów konserwacyjnych, a nawet może być dobre dla nowych rozwiązań, jeśli jest stosowane ostrożnie, ale jeśli niewłaściwi ludzie go nie rozumieją lub przyjmują z niewłaściwych powodów, może być najbardziej destrukcyjny.

Wydaje się, że nawet w zwinnym miejscu nie ma miejsca na atrakcyjne cechy.

Porównujesz jabłka i pomarańcze. W tradycyjnym wodospadzie, jeśli twoje wymagania mówią, że potrzebujesz niezbędnych rzeczy, dostajesz Fiata. Jeśli wymagania mówią, że musi być na najwyższym poziomie, dostajesz Ferrari.

To samo dzieje się w Agile. Jeśli twoje wymagania zatrzymają się na liście życzeń, otrzymasz Fiata. Jeśli masz historie o doskonałości, dostajesz Ferrari. Wszystko, zwinny naprawdę wymusza to, że robisz bogatymi moszcz pierwszy . Nie buduj super fajnego spojlera przez dwa lata, a następnie nie dotrzymasz terminu na silnik.

Tak długa historia: dostajesz to, czego potrzebujesz. Jeśli planujesz samochód sportowy, otrzymasz samochód sportowy. Zwinny wcale tego nie zmienia. Jeśli Twój zwinny proces wymaga wymagań dla Fiata, nie obwiniaj zwinnego, obwiniaj facetów, którzy potrzebują tylko Fiata.

Jednak wszystkie zwinne procesy, które znam, zdecydowanie sprzyjają wymaganiom, które należy spełnić. Zawsze mają najwyższy priorytet.

Tak, jak powinny - spójrz ponownie na swój model Kano: jeśli niezbędne wymagania nie zostaną spełnione, klient nie zaakceptuje produktu. A potem twoi rozkosze nie mają znaczenia.

Wydaje się, że nawet w zwinnym miejscu nie ma miejsca na atrakcyjne cechy.

Nic nie może być dalej od prawdy.

Zwinne procesy zwykle podkreślają następujące punkty:

• Częsta dostawa działającego produktu, na temat którego można uzyskać informacje zwrotne.
• Podziel elementy na małe części, które można wykonać w krótkim czasie.
• Wykonaj te części w kolejności pierwszeństwa.

Nic nie stoi na przeszkodzie, aby nadać „zachwycającym” funkcjom wysoki priorytet. Zależy to całkowicie od osób odpowiedzialnych za określanie priorytetów.

Teraz prawdą jest, że wiele takich osób woli nie podejmować ryzyka i dlatego nie może nadawać wysokich priorytetów „zachwycającym”. Ale w przypadku projektu nie zwinnego nadal tak będzie.

Agile nie mówi nic o tym, co należy zrobić najpierw, tylko ten kod powinien być zapisywany przyrostowo i utrzymywany w możliwym do zwolnienia stanie tak często, jak to możliwe, zamiast planować, że będzie bezużyteczny przez miesiące do następnego możliwego do zwolnienia stanu.

Pracowałem zarówno w procesie Agile, jak i BDUF (Big Design Up Front) i chociaż zdecydowanie możesz uzyskać innowacyjne, atrakcyjne funkcje z obu procesów, w BDUF, co nie jest zaskoczeniem, musisz je zaplanować z góry. Oznacza to, że innowacje muszą być na ogół proponowane lub przynajmniej sponsorowane przez osoby mające duży wpływ na proces projektowania.

Wynika to z faktu, że masz sześć miesięcy (lub cokolwiek innego) do następnej wersji, a kierownicy projektów są zestresowani tym, co się wydarzy, ponieważ jeśli ich funkcja się nie pojawi, minie kolejne sześć miesięcy do następnej wersji. . Tak więc istnieje pełna lista zacięć funkcji w harmonogramie wypełnionym dżemem, a jeśli nisko oceniany plik zostanie przyłapany na pracy przez dwa lub trzy dni nad czymś fajnym, po prostu myślą, że klientowi się spodoba, i nie ma go lista, ryzykują cały harmonogram i będzie piekło do zapłaty.

W procesie zwinnym staramy się utrzymywać oprogramowanie w stanie umożliwiającym zwolnienie, a kierownicy projektów są mniej zestresowani, ponieważ jeśli ich funkcja spadnie, będą mogli go zdobyć w ciągu dwóch tygodni. Więc jeśli programista wróci z konferencji z fajnym pomysłem i poświęci kilka dni na coś, nie naraża na szwank sześciomiesięcznego harmonogramu wypisanego we krwi.

Zasadniczo zbierasz to, co siejesz. Jeśli zachęcisz innowacje i zapewnisz zespołom wystarczającą autonomię, by je realizować, dostaniesz je. Jeśli ciągle domagasz się skracania zakrętów w celu dotrzymania terminów, otrzymasz oprogramowanie do dopasowania, bez względu na twoją metodologię.

Doskonałe oprogramowanie wynika z dwóch rzeczy:

• Dając klientowi to, czego potrzebuje

• Być profesjonalistą

Podczas opracowywania oprogramowania należy przestrzegać różnych zasad. SUCHY, czytelny, SOLIDNY ​​itp., Które nie mają nic wspólnego z wymaganiami klienta. Klient poprosił o samochód sportowy. Gdyby klient zrozumiał, co trzeba zrobić, aby samochód sportowy był niesamowity, nie potrzebowałby cię. Od Ciebie zależy, co jeszcze jest ważne.

Częścią naszej pracy jest utrzymywanie standardów, których klient nigdy nie doświadcza, chyba że coś pójdzie wyjątkowo źle.

Jeśli robisz to dobrze, zwinność zmierza w kierunku fiat tylko wtedy, gdy tego naprawdę chce klient. Nie wtedy, gdy według nich muszą się zadowolić.

Wodospad jest inny, ponieważ gdy raz ustąpi nieporozumienie na temat wymogu wysokiej klasy samochodów sportowych, zwykle się utrzymuje. Zwinny potrafi poradzić sobie z nowymi informacjami i dostosować się, jeśli okaże się, że tak naprawdę potrzebują motocykla.

Wodospad jest nadal używany w wielu sklepach do dziś. Sklepy te odnoszą sukcesy, ponieważ ich wymagania zmieniają się o mniej niż 2% w ciągu roku.

Twoim zadaniem nie jest po prostu dawanie klientowi tego, czego chce. Ma również na celu zadbanie o rzeczy, o których wiesz, że w ogóle nie dostaniesz żadnych kredytów. Rzeczy, których klient nigdy nie przyniesie, chyba że pozwolisz, aby sprawy potoczyły się bardzo źle. Te rzeczy powinny być dobrze wybrane, bo w przeciwnym razie zmarnujesz na to dużo badziewia.

Każdy idiota może zbudować most z nieograniczonym budżetem. Profesjonalista buduje most, który prawie nigdy nie upada.

Dlatego uważam, że nie należy niewolniczo koncentrować się na obowiązkowych wymaganiach.

Jasne, że powinieneś. Z wyjątkiem szacowania czasu. Ponieważ te obowiązkowe wymagania nie są jedynym czynnikiem.

Dobrze,

W Agile programista może tworzyć oprogramowanie, ale ostatecznie to produkt jest właścicielem produktu. (za pomocą programistów).

Jeśli chodzi o „atrakcyjne cechy”, to zależy od właściciela produktu.

Jeśli właściciel produktu nakazuje „seksowny design”, może to być wymagane. Deweloper nie powinien martwić się o te wybory.

Ponadto oprogramowanie tak różni się od rzeczywistych produktów fizycznych, że myślę, że wiele modeli Kano nie ma zastosowania. Na przykład dlaczego mam facebooka? Jedyny powód: ponieważ moi przyjaciele tak. Jak umieścić to w następnym sprincie ........ Jedną z najbardziej atrakcyjnych cech oprogramowania jest to, że faktycznie robi to, co powinien. (I tam bardzo zwinny pomaga: P)

Moje doświadczenie zgadza się z powyższymi komentarzami - w Agile nie ma nic nieodłącznego, co wykluczałoby rozwój doskonałego oprogramowania - jest jednak kilka aspektów tego, jak często Agile jest (źle) praktykowane, co prowadzi do oprogramowania, które jest „wystarczająco dobre” . ”

• Agile kładzie nacisk na uzyskanie czegoś pracę ASAP; oznacza to jednak uproszczenie założeń i zmniejszenie narożników, szczególnie w infrastrukturze niewidocznej dla użytkownika. Nie ma w tym nic złego, jeśli koszty korekty uproszczeń są niskie; jednak zbyt często ten „dług techniczny” nie jest usuwany, zanim produkt wejdzie do produkcji;
• Zwinne naucza, że ​​pod koniec sprintu zawsze powinieneś mieć coś, co jest tak blisko dostawy, jak to tylko możliwe, aby interesariusze i kierownicy projektów mogli zdecydować, że „to, co mają”, jest wystarczająco dobre, aby wcisnąć się w produkcja. Znowu nic z tego nie jest w porządku, jeślispłaciłeś wszystkie swoje „zadłużenie techniczne” (lub pogodziłeś się z tym, ile masz i gdzie to jest). Jednak z mojego doświadczenia wynika, że ​​zbyt wiele długów technicznych wchodzi w produkcję z obietnicą kierownika, że ​​„my „Oczyszczę to, gdy presja na wysyłkę zniknie”, co szybko zamienia się w „jest w produkcji, musimy bardzo uważać na to, co teraz zmieniamy”, co ostatecznie zamienia się w „Nigdy nie powiedziałeś mi, że mieliśmy taką ekspozycję! Następnym razem musimy wykonać lepszą robotę! ” Lekcji Bena Frankina o „Gorycz niskiej jakości pozostaje długo po zapomnieniu o słodyczy niskiej ceny” wydaje się nigdy nie zostać wyuczony;
• Jednak nawet z ufających menedżerów i zdyscyplinowany programistów, jest częstym problemem, który po prostu zbyt mało właściwej analizy, projektowania i przegląd projektu następuje przed rozpoczęciem sprint, w którym oczekuje się, że wdrożenie powinno być rozpoczęte i zakończone. Brak rozważnego rozważenia alternatywyMetafory i projekty interfejsu użytkownika są duże - zwykle jest to zbyt kosztowne, aby znacznie to zmienić po rozpoczęciu projektu; niepowodzenie młodszych zespołów w dokładnym przestudiowaniu produktów konkurencji lub nadaniu priorytetu definicji i wdrożeniu technologii infrastrukturalnych, takich jak I18N, ram powiadomień, rejestrowania, bezpieczeństwa i strategii wersjonowania API (na przykład) oznacza, że ​​ostatecznie będą miały więcej błędów, niższą produktywność i narosną większe zadłużenie techniczne, niż gdyby wcześniej spędzili pierwsze 2-5 sprintów z góry, wykonując wymagane szkolenie, analizy, projektowanie i prototypowanie. Krótko mówiąc, zespoły zwinne muszą opierać się licencji, aby się włamać;
• Miałem menedżera drugiego poziomu (z ponad 100 programistów), który zniechęcił jego programistów do zapisywania planowanych projektów, nawet na najbardziej podstawowym poziomie. Jego rozumowanie - „Chcę, żeby ludzie ze sobą rozmawiali” - było ironiczne, ponieważ znajdowali się w 5 różnych strefach czasowych i 3 krajach. Nie trzeba dodawać, że wiele osób wskazywało, który zespół będzie musiał pracować dużo nocy i weekendów późno w projekcie, gdy tylko zorientowali się, że wszyscy myśleli, że ten drugi facet był odpowiedzialny za wdrożenie jakiejś funkcjonalności (lub ponowna implementacja, ponieważ projekty dostawcy i konsumenta po prostu się nie zazębiły).

Wszystko sprowadza się do tego, czy kierownik projektu i interesariusze chcą dostarczyć produkt wysokiej jakości. Jeśli są do tego zobowiązani, Agile włączy to. OTOH, ponieważ Agile przekazuje decyzje dotyczące harmonogramu wyłącznie w ręce interesariusza i kierownika projektu, Agile utrudnia zespołowi programistycznemu dostarczenie doskonałego projektu bez tego wsparcia. W skrócie: odpowiedzialność za jakość produktu spoczywa prawie wyłącznie na kierownikach projektów.

TL; DR

W rzeczywistości sprawny rozwój pomaga podnieść jakość oprogramowania, zadowolić klienta i dostarczyć bardzo cenny produkt.

Zwinne projektowanie zostało wprowadzone przez kilku inteligentnych facetów, aby rozwiązać problemy, z którymi boryka się wiele projektów oprogramowania w tradycyjnych procesach.

Kluczowymi wartościami zwinnego rozwoju zdefiniowanymi w manifestie zwinnym (1) są:

• Osoby i interakcje dotyczące procesów i narzędzi
• Oprogramowanie robocze nad obszerną dokumentacją
• Współpraca z klientami w zakresie negocjacji umów
• Odpowiadanie na zmiany w związku z realizacją planu

Dlatego zwinny rozwój nie uniemożliwia tworzenia wysokiej jakości oprogramowania. Zwinne programowanie wspiera dostarczanie wysokiej jakości oprogramowania.

Ale czy my (i klient) naprawdę zawsze wiemy z góry, jakie są niezbędne wymagania.

To o to chodzi. Koncentrując się na osobach, klient, działające oprogramowanie i zmiany wymagań zwinne opracowywanie pomaga Ci dowiedzieć się, czego oczekują klienci przed dostarczeniem produktu końcowego.

To jest powód, dla którego zwinne frameworki, takie jak Scrum, mają krótkie cykle iteracji, których wyniki są skutecznymi produktami. Możesz już sprawdzić swoją pracę na wczesnym etapie pod kątem oczekiwań klienta i dostosować cele / wymagania na żądanie. Zwinny rozwój pomaga upewnić się, że jakość produktu jest niezbędna.

Dawno temu - nadal tak jest do dzisiaj - wiele projektów oprogramowania opracowanych w tradycyjny sposób nie powiodło się, nie powiodło się lub spowodowało niezadowolenie klientów, ponieważ nie osiągnięto wymaganej jakości .

Ponadto zwinny rozwój pomaga również osiągnąć atrakcyjną jakość . Odzwierciedlanie produktu po każdej iteracji uwypukla nowe wymagania, których klient nie obawiał się na początku projektu (atrakcyjne cechy). Dzięki temu klient jest zadowolony.

Chciałbym również wspomnieć o jakości odwróconej - atrybutach prowadzących do niezadowolenia - modelu Kano.

W każdym projekcie są wymagania, które wydają się być dobrymi pomysłami na początku projektu. Po chwili zmieniają się na przeciwne i powodują rozczarowania.

W tradycyjnym procesie tworzenia oprogramowania rozpoznasz takie wymagania w produkcie końcowym po długim okresie realizacji projektu. Zbyt późno, aby uniknąć rozczarowań klientów i je zmienić, konieczny jest projekt kontrolny.

Zwinne programowanie pomaga wcześnie identyfikować niedziałające lub niezadowalające wymagania i zmieniać je podczas projektu.

Jak powiedziałem, zwinny rozwój pomaga podnieść jakość oprogramowania, zadowolić klienta i dostarczyć bardzo cenny produkt.

Jestem spóźniony na tę imprezę, ale chciałbym podzielić się innym spojrzeniem na ten temat:

Ale jak można je zastosować, aby stworzyć zachwycające produkty wysokiej jakości, a nie tylko absolutne minimum, które ledwo spełnia niezbędne wymagania?

W zwinnym opracowywaniu oprogramowania istnieje aspekt czasowy, który wynika z iteracyjnego podejścia i analizy opinii klientów , które są dwoma ważnymi elementami metodyki zwinnej. Przykład: cechy, które w iteracji t zostaną zidentyfikowane jako atrakcyjna jakość, w następnej iteracji t + 1 mogą stać się koniecznością .

Stosowanie zwinnych metod może dynamicznie zmieniać kategorię jakości obiektu. Jeśli porównasz planowane funkcje iteracji t z gotowymi funkcjami późniejszej iteracji t + n, doświadczysz dokładnie tego, o czym wspomniałeś:

Doświadczyłem już kilka razy, że wymagania, które na początku miały wysoki priorytet, okazały się o wiele mniej ważne, jeśli nie bezużyteczne, później.

Mając na uwadze ten aspekt czasowy, prawdopodobne jest, że zwinne metody mogą tworzyć zachwycające, wysokiej jakości oprogramowanie , koncentrując się na absolutnym minimum . Iteracyjne podejście w połączeniu z opinii klientów zmienia zasady gry w czasie.

Wniosek

Jak stworzyć doskonałe oprogramowanie za pomocą zwinnych metod?

Zastosuj iteracyjne podejście i wysłuchaj opinii klientów . Porzuć jeden z tych elementów, a otrzymasz mniej udaną formę zwinnego tworzenia oprogramowania.

   > How to develop excellent software with agile methods?

• Podczas tworzenia indywidualnego oprogramowania dla konkretnego klienta :
  • znajdź klienta, w którym koszt nie ma znaczenia, ponieważ „zachwycająca” funkcja kosztuje dodatkowe pieniądze, a klient musi zdecydować, czy chce za to zapłacić.
• Podczas produkcji oprogramowania :
  • „zachwycające” funkcje są dobre, aby przyciągnąć nowych klientów, a koszt wdrożenia „zachwycającej” funkcji nie jest tak ważny, jeśli produkt jest sprzedawany ponad 1000 razy.
• W środowisku, w którym „wystarczająco dobry (najtańszy) jest najlepszy”), nie dostaniesz pieniędzy na wdrożenie „zachwycających” funkcji

W zespole Scrum właściciel produktu jest odpowiedzialny za wybór funkcji do wdrożenia. Zatem do niego (i jego budżetu) należy określenie „wystarczająco dobrego” lub „doskonałego” oprogramowania

Podnosisz dobre punkty. Ale nie wierzę, że te problemy są ograniczone do zwinnych procesów / metodologii.

Istnieją różne opinie na temat tego, co jest istotne, a co nieistotne. Na przykład ktoś kupujący auto może uznać przyciąganie uwagi za istotną cechę, dlatego też uważa Fiata za niespełniający tego niezbędnego wymogu.
Bardziej realistycznie, oprogramowanie może wymagać pewnych funkcji, aby zaspokoić potrzeby rzeczywistych użytkowników końcowych ... ale może także wymagać pewnych innych funkcji, aby zostać sprzedanym. Ponieważ osoba autoryzująca zakup często nie jest użytkownikiem końcowym.
Tak więc funkcja, która jest „nieistotna” dla użytkownika końcowego (użytkowników końcowych), może być niezbędna do sprzedaży produktu ... a zatem także niezbędna dla firmy tworzącej produkt.

Wszystko to sprowadza się do tego, że kluczowe znaczenie ma dobry zespół ds. Rozwoju produktu, który odpowiednio określa wymagania i priorytety. Dotyczy to nie tylko sprawnych sklepów.

Ważne jest również, aby właściciele / interesariusze produktu byli uprawnieni do podejmowania decyzji. Jeśli decyzje właściciela Twojego produktu są ciągle uchylane przez kogoś innego, jako pierwszy zgodzę się, że to problem, ale znowu nie jest to problem ze sprawnością.

Są jeszcze inne rzeczy, których oczekujesz od właściciela (-ów) produktu ... jeden opis, który słyszałem to „CRACK” (współpraca, przedstawiciel, autoryzacja, zaangażowanie i wiedza). Brak produktu w którymkolwiek z tych obszarów może oznaczać problemy w projekcie. Ale po raz pierwszy usłyszałem ten akronim w środowisku wodospadu, więc wyraźnie ból złych klientów / właścicieli produktów nie ogranicza się do zwinnych sklepów.

To, co potrafi zwinna (pomoc), to ujawnienie niektórych z tych problemów.

Na przykład, literatura XP jest IIRC dość wyraźna, że ​​„klient” jest kompetentny, dostępny dla zespołu i upoważniony do podejmowania decyzji. Termin „właściciel produktu” oznacza pewną wiedzę, zaangażowanie i autorytet.

Jeśli znajdziesz się w sytuacji, w której większość dostarczanych funkcji składa się z rozkoszów zamiast z funkcji, które musisz mieć, o wiele łatwiej jest poruszyć ten problem (i znacznie łatwiej ustalić przyczynę), gdy dostarczasz działające lub prawie działające oprogramowanie co 2-3 tygodnie niż w przypadku dostaw w odstępach miesięcy lub lat.

Jeśli pracujesz w małych iteracjach - i często przeglądasz zaległości (w tym sprawdzanie priorytetów) - daje to zespołowi możliwość uczenia się na podstawie wcześniejszych błędów. „Wydaje się, że jest to teraz naprawdę ważne, ale pamiętasz dynamiczną nawigację, której byliśmy pewni, że nie potrzebowaliśmy?” Jak zauważyli inni, dyskusje te są znacznie mniej prawdopodobne, jeśli wszystko zostało zaplanowane z góry.

Natomiast metodologia projektowania z góry zakłada (domyślnie), że zrozumienie produktu i funkcji jest statyczne. To nie było moje doświadczenie: posiadanie czegoś namacalnego do pracy prawie zawsze zmienia zrozumienie problemu przez ludzi biznesu. Stąd nacisk na szybką informację zwrotną. (Zmienia się również zrozumienie programistów, ale nie wpłynie to na priorytety).

Odroczenie części planowania pozwala również reagować na zmiany potrzeb biznesowych. „Znasz tę stronę internetową, którą tworzysz? Naprawdę potrzebujemy, aby była to aplikacja mobilna, zdolna do odłączania się”. Nie o to pytano konkretnie ... ale czy nie chciałbyś, aby Twój proces był w stanie reagować na zmiany w otoczeniu biznesowym (przynajmniej teoretycznie)?

Zwinny nie mówi „nie buduj zbędnych funkcji”. Mówi „pozwól firmie zdecydować, które funkcje (nie) zbudować”.
... i (równie ważne) „pozwalają technikom powiedzieć, jak długo zajmie zbudowanie funkcji”.

1. Must-be qualitiessą często trudne do ustalenia. Ludzie mają je w podświadomości. Zwinne iteracje i uczestnictwo klientów pomagają znaleźć większość niezbędnych elementów. To jest siła zwinna i głupotą jest zaniedbywanie jej .
2. One-dimensional qualitiesoznacza to, że obietnice, które muszą zostać spełnione, są wspierane przez wodospad OK, dopóki się nie zmieniają. Tutaj zwinność pomaga tylko, ale nie tak mocno.
3. Attractive qualitiessą fajnymi funkcjami. Mogą stać się obowiązkowymi w następnym pokoleniu. Ale w obecnym pokoleniu nie są nawet w umowie - inaczej byłyby to cechy Jednowymiarowe. Te zwinne metody, które zakładają udział przedstawiciela klienta, bardzo dobrze wspierają te cechy. Ponieważ możemy nieznacznie zmienić zakres podczas pracy. Możemy wynegocjować ulepszenie jednego miejsca za pewną rekompensatę w innym. W wodospadzie jest to praktycznie niemożliwe. Bez wielkiego opóźnienia organizacyjnego moglibyśmy dodawać funkcje tylko za darmo. Jest to możliwe, jeśli wcześniej przeznaczono dodatkowy czas na budżet.

Zatem zwinne procesy mogą obsługiwać model Kano, niektóre z nich robią to znacznie i zdecydowanie znacznie lepiej niż najlepsze projekty wodospadów.

Aby to zrobić bardzo dobrze, powinieneś ustawić sprawne procesy z uczestnikiem odpowiedzialnego przedstawiciela klienta.