Funkcja a funkcja [zamknięte]

Często słyszę, jak szefowie projektów (Project Manager) mówią o funkcji i funkcji. Jestem tak zaskoczony, aby je odróżnić. Czasami myślę, że funkcja jest równoważna historii użytkownika. Coś w rodzaju „Jako użytkownik Bob powinien widzieć listę swoich płatności” i nazywają to funkcją. Czasami staje się tak duży jak podsystem, coś w rodzaju „możliwości wysyłania wiadomości SMS za pośrednictwem aplikacji internetowej”. Z drugiej strony funkcja czasami staje się tak mała jak zadanie, „wdrażanie grupowania cyfr dla wprowadzania liczb”, podczas gdy zdarzają się przypadki, gdy staje się tak duża jak cała operacja CRUD.

Moje pytanie brzmi: jak możemy odróżnić funkcję od funkcji?

Funkcje są tym, co sprzedają ludzie.
Funkcje rozwijają programiści.

Funkcje nie pasują dobrze do kontekstu historii użytkownika i są w większości przejrzyste dla użytkownika. Mogą to być proces zaplecza lub pewnego rodzaju unikalna lub wspólna funkcja aplikacji, która umożliwia odpowiednie zaimplementowanie innych funkcji lub ewentualnie innych funkcji.

Z drugiej strony zadania to indywidualne jednostki pracy, które należy wykonać, aby dostarczyć cechę lub funkcję.

W moich projektach zwykle nie rozróżniam Funkcji od Funkcji i piszę historie użytkowników dla funkcji i dodam funkcje lub wysiłki refaktoryzacyjne jako Zadania, aby ukończyć jedną funkcję.

Czasami sprawia to, że niektóre funkcje wydają się niepotrzebnie rozdęte na planie projektu, ale jest to w porządku, ponieważ jeśli potrzebuję Refaktoryzacji Funkcji 1 i 2 oraz Funkcji 3, aby poprawnie dostarczyć Funkcję 1, to być może moim jedynym dostarczeniem do tego sprintu będzie Cecha 1 lub być może nie ma w ogóle żadnych produktów.

Dopóki pod koniec sprintu nadal mam działające oprogramowanie, mój projekt jest zwinny.

Funkcje są tym, co potrafi Twój program. Funkcje są bezpośrednim wynikiem wymagań użytkowników i celów biznesowych. Dlatego funkcje programu istnieją głównie po to, aby spełnić wymagania użytkowników .

Z drugiej strony funkcjonalność polega na tym, jak wyżej wspomniane funkcje są faktycznie realizowane .

Dla PM „Funkcja” jest celem, a „Funkcja” to zachowanie produktu, z którym użytkownik może wchodzić w interakcje. Jednak ludzie często odbierają te dwie rzeczy wstecz (co moim zdaniem ma miejsce w twoim pytaniu).

Przeniesienie mnie z miejsca A do miejsca B jest kluczową funkcją samochodu. Jest to powód (cel) istnienia. Cechą charakterystyczną jest kierownica, podobnie jak drążek zmiany biegów. Sterownik wchodzi w interakcje z wieloma funkcjami, aby osiągnąć funkcję dotarcia gdzieś.

„Funkcji” nie należy tutaj mylić z funkcją (metodą) języka programowania, która mówi o implementacji oprogramowania funkcji. To najprawdopodobniej nie to, o czym mówiłby premier, odnosząc się do „Funkcje i funkcje”.

Nie ma ładnej hierarchii funkcji i funkcji, ponieważ jedną funkcję można wykorzystać do obsługi wielu funkcji produktu.

Uważam, że należy wprowadzić właściwe rozróżnienie dla konkretnej metodologii lub kultury wymagań. Oto moja własna interpretacja.

Funkcja: Podstawowy wymóg, który ma ogromny wpływ na wartość oprogramowania, który użytkownik musi mieć w konkretnej wersji. Przykład: funkcja Zapisz w edytorze tekstu.

Cecha: miło mieć możliwości oprogramowania, które zwiększają wartość oprogramowania, ale nie jest absolutną koniecznością, aby oprogramowanie działało poprawnie i spełniało swoje funkcje. Na przykład skorzystaj z funkcji cofania w formularzu wprowadzania danych lub zapisz dokument jako plik gif dla edytora tekstu (przewodowego!).

Za każdą funkcją kryje się funkcjonalność potrzebna do zapewnienia użytkownikowi zamierzonego celu tej funkcji.

Przykład: system rejestracji uniwersytetu miałby funkcję „rejestracja studentów na zajęcia”. To zadanie wymaga sporo funkcjonalności, a także dostępu do bazy danych. Projekt tej funkcji wymagałby zrozumienia faktycznego zadania użytkownika - rejestracji na zajęcia. Byłoby to warunkiem wstępnym do „projektu interakcji” niezbędnego do ułatwienia zadania użytkownika. Funkcjonalność zostanie zaprojektowana w celu wdrożenia wymagań dotyczących interakcji.

Programiści szukają funkcji do kodowania. Projektanci interakcji szukają najlepszego sposobu na dostarczenie tej potrzebnej funkcjonalności poprzez zaprojektowanie interakcji oprogramowania z użytkownikiem. Najważniejsze jest zrozumienie, w jaki sposób użytkownik może najlepiej osiągnąć swój cel. Następuje identyfikacja potrzebnej funkcjonalności.

Powyższe nie jest naukowe, to tylko moja opinia.

Ważne jest, aby pamiętać o rozróżnieniu między funkcjami i cechami produktu. Funkcje to „odpowiedź produktu na zestaw zadań użytkownika”; funkcje to „narzędzia użytkownika” związane z produktem używanym do wykonywania funkcji. Nawiązywanie połączenia telefonicznego jest funkcją; Sygnał wybierania i klawiatura wybierania tonowego to funkcje używane do wykonania tej funkcji.

Zgadzam się, że nie warto się nad tym zastanawiać, ponieważ terminy są często używane zamiennie w niektórych kontekstach. Myślę jednak, że w szerszym kontekście zarządzania są pewne ważne punkty. Po pierwsze, PM może również oznaczać menedżera produktu. Ktoś musi wziąć odpowiedzialność za decyzję, co rynek będzie obsługiwał pod względem ceny, terminu dostawy i funkcji. Ogólnie uważam, że ta funkcja jest preferowana, gdy jesteś w kontekście marketingowym. Rolą kierownika projektu jest takie zarządzanie projektem, aby pożądany produkt był dostarczany na czas i w ramach budżetu. Architektowi i projektantom podano tę funkcję i można ją traktować jako dostarczone funkcje w organizacji ludzkiej oferującej transformację i przechowywanie danych, ale należy ją aktualizować, dopóki projekt nie zostanie zredukowany do jednostek pracy, które można delegować, które można przypisać programistom . Często zdarza się, że funkcja nie mapuje czysto zestawu funkcji w systemie maszyny. Na przykład szybkie i bezpieczne są funkcje pożądane przez konsumentów, ale nie można ich segregować w kodzie. Te nowe właściwości sprawiają, że wymagania niefunkcjonalne są tak trudne do spełnienia.