Na daily pada zdanie: „Dorzucimy jeszcze ten ficzer”, ale w ticketach nie wiadomo, czy chodzi o nową opcję, poprawkę czy cały większy kawałek produktu. Ficzer to potoczne określenie funkcji lub możliwości programu, choć w zespole może oznaczać zadanie o różnej skali.
Ficzer oznacza funkcję produktu, ale jego skala zależy od kontekstu
- Znaczenie: ficzer to spolszczone, potoczne angielskie feature, czyli funkcja lub możliwość programu.
- W backlogu: ficzer może oznaczać większy element produktu, złożony z kilku historyjek, albo po prostu nową funkcję.
- W rozmowie: samo słowo nie wyznacza zakresu pracy. Doprecyzuj użytkownika, efekt i kryteria akceptacji.
- W kodzie: ficzer to funkcja produktu, a feature flag to mechanizm, który pozwala ją włączać lub wyłączać.
Ficzer to funkcja programu, ale słowo jest potoczne
Gdy ktoś mówi o ficzerze, zwykle ma na myśli funkcję, opcję albo możliwość, którą daje aplikacja. Przykładem może być filtrowanie zamówień, eksport raportu do CSV czy logowanie za pomocą klucza dostępu.
To spolszczona wymowa angielskiego feature. W rozmowie zespołowej brzmi naturalnie, ale w specyfikacji, umowie albo opisie dla klienta lepiej użyć precyzyjniejszego słowa, takiego jak „funkcja” lub „funkcjonalność”.
Uważam, że „ficzer” jest użyteczny w rozmowie, dopóki wszyscy rozumieją, o jakim efekcie dla użytkownika mowa. Problem zaczyna się wtedy, gdy etykieta zastępuje opis zakresu pracy.
W backlogu ficzer może obejmować kilka historyjek
W jednym zespole „ficzer” oznacza drobną opcję, w innym większy element planu produktu. W typowej hierarchii Azure DevOps epik dzieli się na ficzery, ficzer na historyjki użytkownika, a historyjka może być rozpisana na zadania. Microsoft Learn zaznacza zarazem, że nazwy i poziomy takiej taksonomii można dostosować do organizacji.
Wyobraź sobie epik „Ułatwić obsługę płatności”. Jednym z ficzerów może być „Zapamiętywanie metody płatności”, a jego częścią historyjka: „Jako klient chcę wybrać zapisaną kartę, aby szybciej opłacić zamówienie”. Dla programisty konkretna implementacja może rozpaść się jeszcze na zadania dotyczące API, interfejsu i testów.
Skala zależy więc od tego, jak zespół planuje pracę. Według dokumentacji Azure Boards ficzer może grupować powiązane elementy backlogu i opisywać możliwość, którą da się dostarczyć użytkownikom. Nie wynika z tego jednak, że każda firma używa tego słowa dokładnie tak samo.
Feature i historyjka użytkownika nie zawsze znaczą to samo
Tu łatwo o nieporozumienie: angielskie feature bywa nazwą większego elementu produktu, ale w innych praktykach może opisywać funkcjonalność z perspektywy użytkownika. Cucumber opisuje historyjkę jako mały fragment wartościowej funkcjonalności, który powinien dać się zademonstrować i mieć testowalne kryteria akceptacji.
Inny podział znajdziesz w Scaled Agile Framework: tam ficzer ma zwięźle nazywać funkcję i wiązać ją z oczekiwaną korzyścią, a format historyjki użytkownika nie jest zalecany do opisywania każdego ficzera. Wniosek jest praktyczny: nie zakładaj hierarchii na podstawie samej nazwy, tylko sprawdź, jak zespół definiuje elementy backlogu.
Podobna pułapka dotyczy plików Gherkin. Słowo Feature na początku takiego pliku jest nagłówkiem opisującym obszar funkcji i grupującym scenariusze testowe. Referencja Gherkin pokazuje więc użycie terminu w konkretnym formacie testów, a nie uniwersalny rozmiar zadania w każdym backlogu.
Po opisie ticketu poznasz, czy chodzi o ficzer, błąd czy zadanie
Sam przymiotnik „nowy” niczego nie rozstrzyga. Jeśli element dostarcza użytkownikowi nową możliwość, zwykle mowa o ficzerze; jeśli naprawia niezgodne z oczekiwaniem działanie, chodzi o błąd; jeśli opisuje pracę techniczną potrzebną do innego elementu, to zadanie.
| Sytuacja w ticketach | Co prawdopodobnie oznacza | Jak doprecyzować |
|---|---|---|
| Użytkownik może filtrować historię zakupów po dacie | Nowa funkcja, czyli ficzer | Opisz, kto jej używa i jaki wynik ma zobaczyć. |
| Filtr daty pokazuje zamówienia spoza wybranego zakresu | Błąd, bo istniejąca funkcja działa nieprawidłowo | Podaj kroki odtworzenia i oczekiwany wynik. |
| Dodanie indeksu do tabeli przyspiesza wyszukiwanie | Zadanie techniczne, jeśli użytkownik nie dostaje nowej opcji | Powiąż je z funkcją lub problemem, który ma obsłużyć. |
| Zmiana koloru przycisku bez uzasadnienia funkcjonalnego | Może być poprawką UX albo zadaniem, niekoniecznie ficzerem | Wyjaśnij, jak zmiana poprawi wykonanie konkretnej czynności. |
Przy opisie zgłoszenia odpowiedz na trzy pytania: kto korzysta, co może zrobić i po czym poznać, że działa. Jeśli odpowiedź wymaga kilku niezależnych efektów, rozbij element na mniejsze historyjki lub zadania, zamiast zostawiać w backlogu hasło „dodać ficzer”.
Feature flag steruje dostępnością ficzera
W rozmowach o wdrożeniu możesz usłyszeć, że nowy ficzer „jest za flagą”. Chodzi o feature flag, czyli mechanizm pozwalający włączać lub wyłączać daną ścieżkę działania bez zmiany samej definicji funkcji. Martin Fowler opisuje tę technikę jako sposób kontrolowania zachowania systemu, na przykład stopniowego udostępniania nowej funkcji.
W przykładzie z eksportem raportu zespół może wdrożyć kod wcześniej, ale udostępnić opcję najpierw tylko pracownikom firmy. Ficzer jest wtedy funkcją produktu, a flaga narzędziem do zarządzania jej dostępnością. Pomieszanie tych pojęć utrudnia rozmowę o tym, co faktycznie trzeba zbudować, a co tylko włączyć.
Najbezpieczniej dopisać do słowa „ficzer” oczekiwany efekt
Jeśli podczas spotkania pada „zróbmy ficzer”, dopytaj, jaką czynność użytkownik ma dzięki niemu wykonać i czy rozmowa dotyczy nowej funkcji, poprawki czy technicznej pracy w tle. Taki krótki dopisek zamienia branżowy skrót w opis, który można zaplanować, przetestować i odebrać.
