Goal / non goal w specyfikacji

któryś prelegent javowski, prawie na pewno Jarek Pałka "Bare metal Java", ale nie ma czasu powtórnie słuchać, z zachwytem podkreślił, ze każde JSR ma sekcję "goal" ale i "non goal"

We mnie to jak przełom kopernikański albo jabłko Newtona. Od bardzo dawna, ale nieśmiało i w sposób nie nazwany takie coś mi się pojawiało we własnych notatkach w/s założeń, ale nie było to utrwalone.

Właśnie zbudowałem założenia dla endusera z sekcjami "jest celem" i "nie jest celem" - pierwszy raz do tego stopnia świadomie, i wiem,że będę powtarzał.

To nie tak, że JSR były mi obce, a od czasów demokratycznej Javy czytam regularnie, ale mnie to nie oświeciło

Pytanie: jak miejsce w Waszym mysleniu, spisywaniu załozeń, ma część "negatywna" ?

Masz na myśli "out of scope"?

Ja trochę nie rozumiem części "out of scope" w wymaganiach. Może myślę zbyt wąsko, ale dla mnie wymagania mają określać co ma zostać zrobione, a nie co nie ma być zrobione. Dla mnie coś w tym stylu:

Benefit hupothesis:
Jako biedne dziecko po zjedzeniu śniadania będę mógł się skoncentrować na przekazywanym w szkole materiale i osiągnąć więcej w życiu.

Acceptance criteria
Jaś Kowalski dostaje w szkole śniadanie w ciągu całego roku szkolnego 2023/2024

Out of scope
- obiady dla Jasia
- kolacje dla Jasia
- dożywianie dzieci w Afryce
- dożywianie dzieci w Indiach
- dzieci w Wietnamie też nie dożywiamy
....

Nie ma sensu. Ale chętnie poznam inne zdanie.

@piotrpo:

Akurat w JSR pojawiają się nie tematy dożywiania na wyspach Fidżi, tylko takie tematy, jakie 75% oczekujących ficzeru by myślowo włączyło w zakres, i to do nich jest adresowane

Tu jeden z ładniejszych przykładów

https://openjdk.org/jeps/368

a szczególnie trzeci podpunkt w "non goals", o interpolacji, dla mnie jest ważny. Wielu by tego domniemywało, czy to kierując się równoległymi elementami innych języków, czy z innych powodów itd.

@ZrobieDobrze: Ja rozumiem jak to ma działać. W moim przekonaniu wymagania powinny być pisane na minimalnym poziomie pozwalającym na ich akceptację. Kompletna lista "ale nie ..." jest niemożliwa do stworzenia i dość ciężko przewidzieć, jak nieznana nam osoba zinterpretuje jakieś wymaganie. Oczywiście wyłączenia nie szkodzą, ale nie jestem pewien, czy bardzo pomagają

piotrpo napisał(a):

@ZrobieDobrze: Ja rozumiem jak to ma działać. W moim przekonaniu wymagania powinny być pisane na minimalnym poziomie pozwalającym na ich akceptację. Kompletna lista "ale nie ..." jest niemożliwa do stworzenia i dość ciężko przewidzieć, jak nieznana nam osoba zinterpretuje jakieś wymaganie. Oczywiście wyłączenia nie szkodzą, ale nie jestem pewien, czy bardzo pomagają

Oczywiście, że nie da się zrobić PEŁNEJ listy negatywnej. Ale odpowiedź na to, czym community żyje, o czym ewentualnie chodzą pogłoski, co konkurencyjny język już ma itd, zwłaszcza ten trzeci punkt robi coś ważnego ...
W mojej obecnej realizacji, było to wymienienie elementów, które krążyły na stoliku - ale NIE wchodzą w specyfikację , nie negując, że może wejdą w jakąś następną.

Tu ;) przypomniało mi się, chyba Marka Twaina "wierzę tylko w pogłoski, które otrzymały zdecydowane dementi"

Myślę, że warto mieć takie rozwiązanie w swoim arselane. W końcu chodzi o podzielenie przestrzeni rozwiązań różnymi goals/non goals w taki sposób, żeby czytelnik zrozumiał to co autor miał na myśli. Im więcej sposobów na taki podział tym lepszy przekaz przy mniejszej liczbie argumentów.

Z drugiej strony nie widzę sensu na pakowanie non goals do każdego możliwego przypadku

piotrpo napisał(a):

@ZrobieDobrze: Ja rozumiem jak to ma działać. W moim przekonaniu wymagania powinny być pisane na minimalnym poziomie pozwalającym na ich akceptację. Kompletna lista "ale nie ..." jest niemożliwa do stworzenia i dość ciężko przewidzieć, jak nieznana nam osoba zinterpretuje jakieś wymaganie. Oczywiście wyłączenia nie szkodzą, ale nie jestem pewien, czy bardzo pomagają

Nie wiem, czy bardzo, ale sprawiają, że człowiek się mniej zastanawia nad tym, co jest do zrobienia, a więc np. nad tym, czy może wziąć się za zadanie z marszu, czy musi się czegoś douczyć.
I nie chodzi o listę wszystkich możliwych kombinacji czasowników i rzeczowników, ale o rzeczy, które mają sens w danym kontekście. Np. w zadaniu dotyczącym implementacji endpointa służącego do tworzenia nowego zasobu w out-of-scope mogą być takie rzeczy jak: walidacja, uwierzytelnianie, publikacja eventu, perzystencja. Wszystko zależy od kontekstu, i od tego, z czym typowo wiążą się tego typu zadania w danym projekcie.