Niektóre rzeczy po prostu działają i nie trzeba nikogo do nich przekonać. User Story to koncepcja, która nie jest związana ze Scrumem czy żadnym innym podejściem zwinnym. Jednak, gdzie nie rzucić kamieniem, tam trafiamy na wymagania pisane w ten sposób.
Czym Historyjka Użytkownika / User Story?
User Story to bardzo specyficzny i konkretny format zapisu wymagań. W tym zdaniu znajduje się bardzo dużo informacji. Po pierwsze, mamy do czynienia z wymaganiami, a nie z zadaniami. User Stories nie sprawdzą się, jeżeli chcemy opisywać w ten sposób konkretne „taski”, czyli zadania. Za to świetnie nadają się do zapisu wymagań czy potrzeb biznesowych.
Z User Story nieodłączne związane jest zdanie, po którym zawsze poznamy, że mamy do czynienia z „US-em”. W swojej konstrukcji zawiera ono trzy słowa: „jako”, „chcę”, „aby”. Do pełni szczęścia potrzebna jest nam jeszcze koncepcja kryteriów akceptacji. Te elementy, oraz jakaś nazwa i identyfikator, dają nam „podręcznikowe” User Story.
Konstrukcja User Story
User Story zwyczajowo składa się z czterech elementów: identyfikatora, nazwy, opisu i kryteriów akceptacji.
Identyfikator jest prosty, zwykle jest to jakiś numerek nadawany przez narzędzie, z którego korzystamy do zarządzania wymaganiami.
Nazwa to ten element, którego używamy w codziennych rozmowach i pracach nad wymaganiami. To kilka słów, które mówią nam o istocie samego wymagania. I tu od razu ogromna uwaga, bo niektórzy jako nazwę User Story wpisują jego opis, czyli „jako… chcę… aby…”. To duży błąd, ponieważ powoduje to problemy w przeglądaniu takiej listy wymagań oraz utrudnia nam komunikację. US „Jako klient #białko chcę mieć możliwość zapłacenia za szkolenie BLIKIEM” zapewne będzie po prostu nazywał się „Płatność BLIKIEM” albo „Płatność BLIKIEM za szkolenia”.
I tu dochodzimy do kluczowej kwestii, czyli zdania zawierającego słówka „jako… chcę… aby…”. To zdanie ma w kilku żołnierskich słowach opowiedzieć nam istotę potrzeby z punktu widzenia jakieś osoby. Czyli: mamy jedną konkretną osobę, która chce wykonać jedną konkretną (drobną) czynność. Takie User Story świetnie nadaje się do dalszych dyskusji i prac (np. refinementu).
Ale to oczywiście nie wszystko, takie zdanie nie wystarczy nam do tego, żebyśmy w najlepszym nawet zespole odpowiedzieli na potrzeby biznesu czy użytkowników. Potrzebujemy jeszcze kryteriów akceptacji. Jest to lista konkretów, które muszą się zadzia,ć żebyśmy mogli powiedzieć, że dana rzecz jest zrobiona.
Jak pisać User Stories?
Tematyka User Stories, ich pisania i dzielenia jest bardzo trudna do wytłumaczenia w tekście na blogu. Nasze szkolenie na którym zajmujemy się tylko i wyłącznie User Stories, trwa 2 dni, a większość z tego czasu uczestnicy piszą swoje własne historyjki, które potem omawiamy i poprawiamy.
Mogę za to udzielić kilku prostych porad. Przede wszystkim zadbajmy o to, żeby zdanie „jako… chcę… aby…” faktycznie odpowiadało potrzebom biznesowym. Nie silmy się na wydumane zdania w stylu „jako senior manager zespołu sprzedażowego, w celu zwiększenia efektywności kosztowej naszych działań, potrzebuję oglądać raporty sprzedażowe…” i tak dalej, bo jest to zupełna bzdura. Jeżeli chodzi nam o to, żeby kierownik sprzedaży przydzielał premię za sprzedaż kwartalną na podstawie wyników to po prostu to napiszmy. „Jako kierownik sprzedaży, chcę posiadać raport sprzedażowy w ujęciu kwartalnym dla wszystkich podległych miejsc sprzedawców, abym mógł na tej podstawie przydzielać premie za wyniki kwartalne”.
Pamiętajmy też, że w zdaniu „jako… chcę… aby…” nigdy nie będziemy używać nazw instytucji, działów, ani nie będziemy podstawiać maszyn czy serwerów. „Jako” to zawsze jest jakaś konkretna osoba bądź rola w naszej organizacji. Słówko „chcę”, sugeruje że ta osoba ma jakąś potrzebę. Maszyny, firmy, organizacje nie mają potrzeb. Mają je ludzie. Np. możemy zapytać po co przesyłamy zanonimizowane dane na inny serwer? Na pewno nie dlatego, że „serwer je potrzebuje” – one są do czegoś konkretnego używane i służa komuś. Znajdźmy tą osobę i ten powód. A jeśli się okaże, że jest to wiele osób, to powstanie wiele User Stories – o to właśnie w nich chodzi!
Jeżeli zaś chodzi o kryteria akceptacji, to mamy osobny tekst poświęcony temu jak je pisać, co się powinno w nich zabierać i w jakim powinny być formacie. Gorąco zachęcam do lektury, bo bez „jako… chcę… aby…” mogą powstać całkiem niezłe wymagania. Bez kryteriów akceptacji – nie.
Najważniejsze cechy User Story
User Story jest pretekstem do dalszych prac nad wymaganiem. Na początku dajemy sobie zapisany jakiś zestaw potrzeb i kryteriów, nad którymi będziemy dalej pracować i starać się dołożyć odpowiednio dużo szczegółów. Te szczegóły powodują, że wymagania będą nam rosły. A skoro tak, to będziemy je dzielić na mniejsze, które znowu będą rosły. Ten proces kontynuujemy „do skutku”, aż dostaniemy małe, atomowe wymaganie, możliwe do realizacji w jednym Sprincie.
W przypadku nieśmiertelnego przykładu pod tytułem „kantor walutowy”, dotrzemy do sytuacji, że osobne User Story będzie dotyczyło wyboru waluty, a inne podglądu bieżącego kursu czy przeliczeniu planowanej do wymiany kwoty.
User Story to tylko pretekst do tego żeby porozmawiać o wymaganiu i uszczegółowić kryteria akceptacji, a następnie podzielić zbyt duże wymagania na mniejsze. Dopiero w sytuacji, w której już bardziej podzielić się ich nie, da mamy do czynienia z faktycznym zapisem wymagań i potrzeb klienta w formacie User Story.
Niezależnie od poziomu szczegółowości User Story, zwykle mają one od kilku do maksymalnie kilkunastu kryteriów akceptacji. Jeżeli zaczynają mieć ich kilkadziesiąt, to po prostu dzielimy je na mniejsze. Albo mamy do czynienia z Epikiem, ale to temat na inny tekst.
Kryteria INVEST
Mówi się, że dobre User Story powinno spełniać kryteria INVEST, czyli z angielska Independent, Negotiable, Valuable, Estimable, Small and Testable.
W świetle kryteriów INVEST, że poszczególne User Story powinny być w miarę możliwości niezależne do wykonania od siebie. Czyli nie powinno mieć znaczenia czy do realizacji weźmiemy pierwsze siedem, czy może od piętnastego do dwudziestego. Z kolei sposób ich wykonania powinien móc podlegać negocjacjom. To znaczy, że ten format nie nadaje się do zapisu konkretnych zadań do realizacji, czyli „tasków”. Wspiera to także literka V, czyli wartość. Każde User Story, niezależnie od tego jak małe, musi spełniać jakąś potrzebę jakiegoś odbiorcy czy klienta. Po to właśnie jest nam potrzebne słówko „aby…”, żeby tę potrzebę czy mikrokorzyść wyrazić.
User Stories powinny być możliwe do oszacowania. Niekoniecznie mówimy tutaj o Story Pointach, ale o jakimkolwiek oszacowaniu. Chętnych zapraszamy do tekstu dotyczącego szacowania w Story Pointach i nie tylko. A skoro już o oszacowaniu mowa, to INVEST sugeruje także, że wymagania powinny być małe. Praktyka pokazuje, że powinny mieścić się w jednym Sprincie, który aktualnie najczęściej trwa dwa tygodnie. Oznacza to, że każde User Story powinno być możliwe do zaimplementowania od A do Z w jednym Sprincie przez jeden Scrum Team.
Na koniec pozostaje nam kwestia testowalności. Musimy potrafić pokazać, że US faktycznie jest zrealizowany i działa. Pomagają nam w tym oczywiście kryteria akceptacji, które przed jego zrealizowaniem są nieprawdziwe. Gdy jednak skończymy prace i ponownie zajrzymy do tych spisanych kryteriów, to okaże się, że teraz oto opisują one prawdę.
Czy User Story to dobry wybór dla wymagań?
User Story to świetny wybór dla wymagań w dużych i skomplikowanych projektach, gdzie działamy od ogółu do szczegółu. Na początku możemy zacząć od zdefiniowania Epików i ich kryteriów akceptacji, również używając formatu User Story. Następnie przez dekompozycję możemy schodzić niżej i dodawać kolejne szczegóły.
Format ten nie sprawdzi się, jeżeli nie mamy do czynienia z odkrywaniem naszych rozwiązań, tylko ze z góry zdefiniowaną listą rzeczy do wykonania. Na przykład w sytuacji w której robimy rzeczy czysto techniczne jak na przykład integracja między dwoma systemami, możemy się silić na pisanie User Stories opisujących potrzeby poszczególnych użytkowników, ale często nie jest to rozwiązanie optymalne. Tu wystarczy nam pewnie sama koncepcja kryteriów akceptacji.
Warto też wspomnieć, że format User Story zupełnie nie nadaje się do prowadzenia dokumentacji. Pojedynczy US opisuje jakąś konkretną potrzebę, jakiegoś typu użytkownika, umieszczoną w określonym czasie. De facto opisuje on deltę, czyli różnice, pomiędzy stanem „przed”, a stanem „po”. Taki sposób opisu wymagań nie daje nam całego obrazu, ani żadnych informacji o tym, jak np. wygląda cały proces. Tutaj zawsze dodaję, że jeżeli potrzebujemy dokumentować nasze procesy, to prawdopodobnie dokumentacja procesu jest osobnym artefaktem który jest utrzymywany gdzieś z boku i aktualizowany w trakcie realizacji kolejnych User Stories. US-y nie będą jednak dokumentacją systemu.
I na koniec małe wyjaśnienie User Story to tylko i wyłącznie nazwa formatu zapisu wymagań. W popularnych narzędziach do zarządzania projektami i wymaganiami znajdziecie obiekty o typie „Story”, które obrazują po prostu… wymagania. A to czy zapiszemy je konkretnie w formacie User Story, czy w jakimś innym to już kwestia wtórna.
Tematyką User Story zajmujemy się dogłębnie na naszym szkoleniu „Wymagania i User Stories„. Sprawdź nas!
Powinieneś dawać przykłady. Teoria teorią a przydałyby się 2 – 3 przykłady.
Cały dzień przykładów, pracy z backlogiem, tworzenia User Stories itd. można znaleźć tutaj: https://bialko.eu/wymagania-projekty-agile/, zapraszamy także na szkolenia otwarte! 🙂
Hi,
Tak ujawnia się paradoksalność metodyk:
„Negocjowalna – sposób realizacji wymagania nie może być narzucony i musi zostawić miejsce do negocjacji. To Zespół Deweloperski ma decydujący głos, w jaki sposób zrealizuje wymaganie i nikt, nawet Product Owner, nie powinien w to ingerować.”
Jeśli się nie odezwę jako PO, to Dev zrobi wg swojej wiedzy, a nie wg potrzeby rynku/interesariuszy.
Szczęście jeśli Dev jest klientem produktu i też zna potrzeby.. może zrobi „optymalnie”.
Odezwać to za mało, negocjować idzie w sprzeczności w interwencję.
Wydaje się, że założenia „knoweledge flow” są sprzeczne.
Podobne konflikty wynikają pomiędzy PO vs PDM vs PJM kiedy PO wie lepiej.
No skutki są wtedy dziwne.. produkt jest, ale rynek nie tego chce a PDM, PJM pokazuje features list for shareholders ( IR-part, investor relations part).
Najlepsze akcje są wtedy kiedy DevTeam/SofwareHouse jest wykonawcą jakiejś dużej firmy.. wtedy im absurdy nie przeszkadzają, ważne że jest 250zł/h * coders.
Podobnie jest z UStories.. i zostawianie wielu spraw dla DevTeam – to rozwadnianie roli PDM/PO tak, gdzie czas który mógłby poświęcić na rozpiskę, to traci na spotkania gdzie information flow jest 100% Dev -> PO, zamiast np.30%
Założenia UStories mają bardziej sens przy game development, a najbardziej gdy PO jest oderwany od reszty i ma być decydującym. No ale to słaby efekt gdy PO nie jest ekspertem i raczej fazy wczesno start-up’owe, gdzie szuka się „true” PO.
Co pozwoliła np. w Polsce scena Agile, Scrum itp.. ano możliwość sterowania poważnymi procesami osobom bez kompetencji decyzyjnych (a tak jest bez dziedzinowej wiedzy u siebie), rozwijając struktury na SME, itp. Wszystkiego wiedzieć nie można, ale to jest właśnie problem budowania struktur, często tak gdzie fachowcy są, ale bierze się certyfikaty..
Podobnie jest z SM vs PJM. Zanim te wszystkie metodyki narosły do formy religii i doktryn, to ciężar spoczywał na PJM. Nie da się wszystkiego negować co wymyślono. Rzecz w tym całym consultingu, który rozmija się z istotą biznesu. Dobrze jeśli inwestora stać na takie koszty „kultury” i „zabawy” (niejako demokratyczne, z iluzjami utożsamiającymi rzekomo team). Fakty są jednak takie, że np. Polski rynek różni się od tego zagranicznego i ciekawie wygląda to przycinanie. Chodzi o to, że interesariusz w całym agile/scrum team jest fikcyjny w większości. Nie ma udziału (w sensie korzyści kapitałowej na przyszłość), a udział w budowaniu to wyzysk. Taka to prawda jest, a cały coaching urabia tak i cementuje system. Można by to szerzej skomentować.. nurtują jednak te paradoksy w Polskiej przestrzeni i nie wiem… czy to z tłumaczenia tych dzieł się bierze, braku refleksji na tym jak to działa w praktyce w innych miejscach, czy w czym rzecz..
Jakkolwiek właśnie takie doktryny/ideologie pozwalają uśpić rozum, świadomość i analizę otoczenia. Niemniej nierzadko w korpo odgrywa się rolę, ulega coachingom, a myśli swoje, bo na chlebek trzeba : )
Ten komentarz jest baaardzo chaotyczny i trudno tu się odnieść do tego miksu myśli oraz losowo wrzucanych angielskich słów i określeń.
Największą uwagą, z tego co rozumiem, jest „Jeśli się nie odezwę jako PO, to Dev zrobi wg swojej wiedzy, a nie wg potrzeby rynku/interesariuszy.” I tu leży pies pogrzebany, bo właśnie rolą PO jest zapewnienie, żeby Dev Team rozumiał potrzeby rynku i interesariuszy. Zamiast za stać nad zespołem i przy każdym wymaganiu mówić mu, że „dla klienta istotne jest utrzymanie odpowiedniej kolorystyki rozwiązania” wystarczy raz opowiedzieć o kliencie i o tym, jak ważna jest dla niego identyfikacja wizualna i dlaczego tak jest.
Po drugie, w sformułowaniu „sposób rozwiązania” najbardziej istotne są „technikalia”. Z punktu widzenia PO i klienta najważniejsze są funkcjonalności i elementy niefunkcjonalne, aczkolwiek widoczne. Cała reszta pozostaje pod kontrolą Development Teamu. No bo co PO czy klienta obchodzi, jaka biblioteka zostanie użyta? I znów – jeśli z jakiegoś powodu obchodzi (bo np. nie chcemy używać biblioteki naszego największego rywala „bo tak”), to rolą PO jest zawarcie tego wymagania w elemencie Backlogu Produktu oraz – suprise, suprise – wytłumaczenie zespołom dlaczego to jest istotne. Dzięki temu pozwalamy sobie na uniknięcie takich problemów w przyszłości.
Tak jak pisałem w tekście https://bialko.eu/agile/wymagania-sposob-realizacji/ – „Dobry Product Owner doskonale wie, na jakim poziomie szczegółowości wymagania powinny trafiać do Backlogu Produktu. Zawrze on w nim minimum, które zapewni właściwy tok rozumowania. Jednocześnie unikał będzie stwierdzeń, które zasugerują coś Zespołowi Deweloperskiemu.”
1. Sorki, to było tak przytykiem do logiki. Patrzę z perspektywy big korpo. Może ktoś coś wyciągnie dla siebie.
” I tu leży pies pogrzebany, bo właśnie rolą PO jest zapewnienie, żeby Dev Team rozumiał potrzeby rynku i interesariuszy. ”
a) Nie ma szans na to w wielu przypadkach. Ja mam wrażenie, że zbyt często i zbyt lekko mówi się o produktach prostych typu jakiś serwis www, może rozbudowany, aplikacja funkcjonalna (GUI, itp. – może to wynika z młotka masłowa? Szybkie awanse serwisowców, albo designerów). Zarządzanie się przydaje, bo jest dużo ludzi i obieg szerokiej informacji.
b) Ale gdy do gry wchodzi coś zaawansowanego, specyficznego, unikalnego, to Dev Team zgubi się już podczas wyboru formatu pliku, rozszerzenia. Wyobraziłem sobie kilka przypadków próby zastosowania takiej myśli „nie wtrąca” itp. Uznałem, że warto zwrócić uwagę na ten problem oraz sprawę UStories. Przy takiej filozofii INVEST i US kończy się rola dla ew. widoków rozbudowanych formularzy. Problem się rozwija gdy taki PO z takim doświadczeniem próbuje replikować praktykę formularzy (widoków) gdzieś indziej by upraszczać pracę albo raczej robić, to co umie/robił (znowu młotek masłowa).
2. „No bo co PO czy klienta obchodzi, jaka biblioteka zostanie użyta? ”
a) No powinno obchodzić PO.. np. żeby móc zrealizować w przyszłości wizję, której cały DevT nie pozna (DevT nie jest w danej dziedzinie wyspecjalizowane i wszystkiego nie pozna – problem entropii) i nie wpaść w kanał niemożliwości technologicznej a obecnie często ma to miejsce (np. użycie Node.js albo html5, JS, technologii uniwersalnej/cross VM – .net java, wstawka w innej technologii np. python, itp.). To można powiedzieć są inne decyzje (w początkach), ale jednak.. w zróżnicowanych technologiach (co obserwuje się w topowych apkach komercyjnych stale – Adobe, MS, inne) jako moduły i komponenty panuje chaos (..a bo wykorzystaliśmy DevTeamNode, albo DevTeamPython).
W miarę przyrostu funkcji itp. te technologie sobie nie radzą, rośnie ew. wymaganie sprzętowe i obcina się dostęp do klientów. To jest przypadek, który obserwuję nonstop. Dev Team ma w nosie.. działa.. działa.. dostarczone? Dostarczone.. A w miarę złożeń, powstają komplikacje technologiczne (update, niekompatybilności, itd.)
Kwestia performance jest może skrajna. Ale przykłady z rozszerzeniami często się powtarzają. Często się mówi, że tak firmy tworzą własne standardy, itp. wyjaśnienia.. Wiele razy byłem zaskoczony informacją zwrotną, że po prostu tak coś wymyślono by zrobić krok dalej..
b) Dyskutujemy o konflikcie:
1) PO narzuca dla DEV
2) PO negocjuje z DEV
3) PO się nie wtrąca do DEV
Tylko balansowanie w absurdzie jest takie, że jeśli na takim etapie idziemy jak w pkt.3) to PO stwarza odrębne wymaganie i wychodzi na to samo. Czyli wchodzi się wtedy w precyzowanie (HLAC). Gra logik, ale istotna. Choć fakt z innego posta na blogu można by to wywnioskować. Ale kończy się w takich warunkach często przestrzeń techniczna i czasowa na kreatywność, autonomię, itp. a PO musi obchodzić „technologia”, „technikalia” itp. A nawyki są takie by się spotykać, dyskutować, a nie ma o czym.. a godziny są nabijane.
c) Czasem brakuje etyki w SoftwareHouse, a także u konsultantów. Ale te procesy .itd. potrafią usprawiedliwiać długi czas dostarczania produktów. Obserwowałem kilka dużych aplikacji i systemów, które powinny powstać w max 1-1.5 roku, a trwają 3-4. Tak.. przetargi, ale też zwykłe zlecenie do innej firmy wykonanie projektu lub rozwój produktu (rozwój powinien przypaść na 2 rok, a planuje się na 5).
d) Czemu to ciekawe? Bo jest przesadny nacisk na iteracje z metodyki, a nie w zakresie etapu wersji oprogramowania. Tuż obok stoi problem „przewidzieć wszystko”. Wg mnie i z obserwacji tam gdzie są user stories, tam są problemy, bo zwykle nie ma głębszych dyrektyw : )
3. Wracając do wątku 1.b), gdyby ktoś napotkał na taki problem, to uwaga – wg mnie trzeba odchodzić od INVEST i US na dyrektywy lub PS – problem/solution. A czy to już Agile, itd.?
Nie jestem wierny tym wszystkim manifestom. Zespoły są coraz większe, a klasyka zawodzi a ew. działa w początkach lub przy małych rzeczach, gdzie realnie nie potrzeba takich metodyk.
No krytyka musi być : )
Widziałem dobrych PO i dobre User Stories na projektach mocno technicznych, a nawet w zespołach scrumowych tworzących fizyczne urządzenia.
US to tylko narzędzie, które dobrze wykorzystywane – pomaga, źle wykorzystywane – przeszkadza.
Product Owner z kolei ma za zadanie przekazywać wizję o której mówisz, że „Dev Team nie pozna”. No skoro PO nie przekaże, to DevTeam nie będzie miał o niej bladego pojęcia. Jeżeli jedna osoba (PO) jest w stanie ogarnąć całość, to tę całość można też sprzedać zespołom tak, aby pracowały spójnie.
Jeśli DevTeam „ma w nosie”, to nie jest zmotywowany, nie rozumie na czym opierają się zwinne zespoły i tu następuje wymowne spojrzenie i na Scrum Mastera, i pośrednio na PO.
To nie jest tak, że na projektach zwinnych nie ma architekta, nie ma planowania długoterminowego i nie ma pracy w oparciu o wersje (release/wydania). Tu się nie biegnie ze Sprintu na Sprint dowożąc wymagania, które kupy się nie trzymają.
To nie jest tak, że na projektach zwinnych „nawyki są takie by się spotykać, dyskutować, a nie ma o czym.. a godziny są nabijane”. Zarówno timebox jak i „law of two feet” mówią właśnie, że nie marnujemy czasu bez sensu na spotkaniach.
To o czym piszesz, wygląda jak jakiś horror, gdzie ktoś znalazł trzy kartki wyrwane ze Scrum Guide oraz połowę Agile Manifesto i postanowił wdrożyć to w życie.
Z całym szacunkiem, ale moje doświadczenia z „polskim agilem” są zupełnie inne. I chociaż daleko jest do ideału, to nie wygląda to tak źle, jak opisujesz. Problemy są, ale w zupełnie innych miejscach. Same rezultaty i np. czas trwania projektów również są raczej po tej pozytywnej stronie. Cóż, chyba trafialiśmy po prostu na zupełnie inne firmy.
„No skoro PO nie przekaże, to DevTeam nie będzie miał o niej bladego pojęcia. Jeżeli jedna osoba (PO) jest w stanie ogarnąć całość, to tę całość można też sprzedać zespołom tak, aby pracowały spójnie.”
Nie da rady wg mnie.. są tematy gdzie PO mógł siedzieć 10,20,30 lat. To jest też tak, że SME może dużo za niego robić, ale.. to już inna sytuacja.
„Jeśli DevTeam “ma w nosie”, to nie jest zmotywowany..” no jest.. na kase : )
To jest stary problem wg mnie.. brać 100-200/h i zrobić w miesiąc, czy dogadać się z decydentami i robić 6 lub 12 mcy. Po 10 większych trudniejszych projektach wcale nie chce się więcej pracować, zwłaszcza jak są podobne („stary.. to tam część się skopiuje z tego co było”, .itp. argumenty na ścięcie kosztów).
„To o czym piszesz, wygląda jak jakiś horror, gdzie ktoś znalazł trzy kartki wyrwane ze Scrum Guide oraz połowę Agile Manifesto i postanowił wdrożyć to w życie.”
Hmm.. na serio.. osoby w przestrzeni z silnym PR w tematach, w top Polskich markach ; )
„Cóż, chyba trafialiśmy po prostu na zupełnie inne firmy.”
No może.. są i takie gdzie wszystko jest na zdrowo, ale rozglądnijmy się.. jaki jest rezultat powstaniach różnych produktów IT.
Jest problem.. taki, że na pewnym etapie przychodów jest machnięcie ręką na wszystko. Ale ciągle jest ten 2 medal rynku w PL w porównaniu np. do USA.. nieadekwatna motywacja, brak odpowiedniego modelu.
„Oglądam” i analizuję często outsorcingi oraz co leży/powstało w bazach. Akurat nie bardzo fizyczne urządzenia, bo to inna specyfika raczej.. pewnie warto by popytach Chińczyków od smartfonów i laptopów jak to robią : )
Od jakiegoś czasu obserwuję nowy trend polegający na zastępowaniu US poprzez Job Story (When…I want… so I can…). Czy jest jakiś polski odpowiednik nazwy Job Story? Co sądzicie o takim podejściu do zapisywania wymagań? Może jakiś wpis na blogu? 🙂
To jest zasadniczo to samo, zapisane w innej kolejności. Ale dzięki za inspirację do tekstu o różnych formatach US. 😉