>>> Ja lubie dokumentacje. Tylko nie lubie jej pisac.
>> Ja nieszczególnie lubię sytuację, kiedy:
>> a) jest dokumentacja, ale opisuje nie do końca to, jaki program
>> faktycznie jest,
>
> Ja tam wole miec niekompletna dokumentacje + zrodla niz tylko zrodla.

A ja lubię mieć wszystko tak jak trzeba, tylko że rzadko się to zdarza :-(

--
Mateusz Bogusz

do góry

On 10/12/2011 21:00, Roman W wrote:
> On Dec 10, 7:20 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>> On 10/12/2011 18:33, Roman W wrote:
>>> Ja lubie dokumentacje. Tylko nie lubie jej pisac.
>> Ja nieszczególnie lubię sytuację, kiedy:
>> a) jest dokumentacja, ale opisuje nie do końca to, jaki program
>> faktycznie jest,
>
> Ja tam wole miec niekompletna dokumentacje + zrodla niz tylko zrodla.

Jest trochę taki problem, że jak dokumentacja opisuje rzeczy niezgodne z
faktyczną rzeczywistością, to się na niej czas traci dwa razy: raz, jak
się ją pisze, drugi raz, jak się próbuje z niej skorzystać.

Poza tym ja się w ogóle zgodzę, że dokumentacja czasem jest potrzebna
lub przydatna. Z tym że w takiej sytuacji najlepiej ją stworzyć już po
napisaniu kodu. Dokumentacja wymagań lub projektu powstająca przed
napisaniem kodu - może być, ale nie jest to według mnie najbardziej
skuteczny sposób pracy (oczywiście to mocno zależy od tego, co się
robi). No i oczywiście rozwiązania agile nie polegają na tym, że nie
masz dokumentacji i tyle. Masz mniej dokumentacji niż w niektórych
innych rozwiązaniach, ale zamiast dokumentacji masz coś innego.

do góry

On 10/12/2011 20:48, n...@m...invalid wrote:
> W dniu 10.12.2011 r. 19:29, Andrzej Jarzabek pisze:
>>
>> Chodzi o to, że z tych "studies" niewiele wynika?
> Dokładnie. Choć, zauważmy, metodologia SD != język programowania.
> Choć przeglądałem pobieżnie, to znalazłem potem, że większość tych badań
> opiera się na formie ankietowania grup początkujących (lub studenckich).
> Nie wiem, czy zdołano całkowicie wyeliminować czynniki wynikające z
> płytkiej adopcji technik agile. Problem needs further research :P

Na pewno, ale wydaje mi się jednak, że potrzeba raczej na początek badań
jakościowych, żeby się zabrać za ilościowe. Problem jest mocno złożony,
samo XP można praktykować lub niby-praktykować na wiele różnych
sposobów, ścisła definicja czym dokładnie jest a czym nie jest XP nie
jest do końca oczywista (nie mówiąc już o tym, czym jest a czym nie jest
Agile), a o wynikach projektu decyduje bardzo wiele czynników.

> W każdym razie wniosek nasuwa się, że XP są co najmniej nie gorsze niż
> tradycyjne w kategorii quality. Zarzut jest do koherentności interfejsów
> użytkownika takich programów.

Nie wiem, czy jakiś wniosek w ogóle się nasuwa. Popatrz na rozdział 5.2:
"[...] Combining the four components of study design, study
quality, consistency, and directness, we find that the
strength of the evidence in the current review regarding
the benefits and limitations of agile methods, and for decisions
related to their adoption, is _very low_. Hence, any estimate
of effect that is based on evidence of agile software
development from current research is very uncertain."

Tu masz napisane, że całą tę pracę da się co najwyżej wykorzystać jako
zamiennik papieru toaletowego.

do góry

On Dec 10, 9:34 pm, Andrzej Jarzabek <a...@g...com>
wrote:
> On 10/12/2011 21:00, Roman W wrote:
>
> > On Dec 10, 7:20 pm, Andrzej Jarzabek<a...@g...com>
> > wrote:
> >> On 10/12/2011 18:33, Roman W wrote:
> >>> Ja lubie dokumentacje. Tylko nie lubie jej pisac.
> >> Ja nieszczególnie lubię sytuację, kiedy:
> >> a) jest dokumentacja, ale opisuje nie do końca to, jaki program
> >> faktycznie jest,
>
> > Ja tam wole miec niekompletna dokumentacje + zrodla niz tylko zrodla.
>
> Jest trochę taki problem, że jak dokumentacja opisuje rzeczy niezgodne z
> faktyczną rzeczywistością, to się na niej czas traci dwa razy: raz, jak
> się ją pisze, drugi raz, jak się próbuje z niej skorzystać.

Z regulay mozna wyodrebnic "rdzen" funkcjonalnosci, ktory sie raczej
nie zmieni, i przynajmniej ten udokumentowac.
Poza tym, jezeli np. ktos udokumentowal 4 parametry funckji, a potem
dodal piaty ktory nie jest udokumentowany, to i tak lepiej niz kiedy
zaden parametr nie jest.

>
> Poza tym ja się w ogóle zgodzę, że dokumentacja czasem jest potrzebna
> lub przydatna. Z tym że w takiej sytuacji najlepiej ją stworzyć już po
> napisaniu kodu. Dokumentacja wymagań lub projektu powstająca przed
> napisaniem kodu - może być, ale nie jest to według mnie najbardziej
> skuteczny sposób pracy (oczywiście to mocno zależy od tego, co się
> robi).

Oczywiscie. Np. teraz opracowuje i implementuje model do wyceny
pewnych instrumentow pochodnych. W miare jak wyprowadzam wzory i
opracowuje schematy kalibracji, wszystko sobie spisuje w pliku
texowym.
Mam w ten sposob dokumentacje "co kod powinien liczyc", ktora bedzie
podstawa pisania oficjalnej dokumentacji dla dzialu walidacji, oraz
moge pokazac zleceniodawcy (traderom) nad czym pracuje.

> No i oczywiście rozwiązania agile nie polegają na tym, że nie
> masz dokumentacji i tyle. Masz mniej dokumentacji niż w niektórych
> innych rozwiązaniach, ale zamiast dokumentacji masz coś innego.

Co? Testow jednostkowych nie uznaje za dokumentacje.

RW

do góry

On 10/12/2011 22:24, Roman W wrote:
> On Dec 10, 9:34 pm, Andrzej Jarzabek<a...@g...com>
>>
>> Jest trochę taki problem, że jak dokumentacja opisuje rzeczy niezgodne z
>> faktyczną rzeczywistością, to się na niej czas traci dwa razy: raz, jak
>> się ją pisze, drugi raz, jak się próbuje z niej skorzystać.
>
> Z regulay mozna wyodrebnic "rdzen" funkcjonalnosci, ktory sie raczej
> nie zmieni, i przynajmniej ten udokumentowac.

Niewątpliwie, jednak nie zawsze to jest potrzebne.

Oczywiście, że wiele rzeczy dokumentować trzeba. Dla produktu musi
powstać dokumentacja dla użytkownika końcowego, biblioteki czy inne
komponenty powinny mieć udokumentowane API, a wszystkie decyzje,
ustalenia i wnioski dotyczące funkcjonalności powinny być dokumentowane
na bieżąco. I przecież w Agile się tego nie kwestionuje. Przede
wszystkim odrzuca się tworzenie dokumentów, na podstawwie których
tworzony jest program: dokumentacji wymagań i "dokumentu projektowego"
czyli opisania całości struktury i jednostek kodu przed rozpoczęciem
implementacji. W dalszej kolejności odrzuca się w ogóle potrzebę
utrzymywania dokumentacji projektu kodu, nawet jeśli nie jest tworzony z
góry.

>> No i oczywiście rozwiązania agile nie polegają na tym, że nie
>> masz dokumentacji i tyle. Masz mniej dokumentacji niż w niektórych
>> innych rozwiązaniach, ale zamiast dokumentacji masz coś innego.
>
> Co? Testow jednostkowych nie uznaje za dokumentacje.

Dobrze napisane testy jednoostkowe mogą stanowić część dokumentacji
kodu, ale przede wszystkim robi się tak, że zamiast stworzenia na
początek dokumentu wymagań, masz w zespole ludzi, którzy rozumieją te
wymagania na tyle, że mogliby taki dokument napisać, i masz człowieka,
który na bieżąco może podejmować decyzje jak program ma działać, co ma w
nim być, czego być nie ma, co można uprościć i tak dalej.

W kwestii opisu projektu kodu, pierwszą zasadą jest czytelność. Ogólnie
jeśli coś jest nieoczywiste tak, że należałoby to udokumentować, to w
pierwszej kolejności rozważa się, czy nie możnaby tego jednak uczynić
oczywistym. Tak, owszem, czasem się nie da, i od tego masz różne inne
techniki, jak asercje, design by contract czy właśnie różne testy.
Odnośnie tego, unit testy mogą i powinny być dokumentacją projektu kodu,
ale muszą w tym celu być odpowiednio napisane - nie tylko tak, żeby
rzeczywiście testować daną funkcjonalność, ale też tak, żeby w
maksymalnie czytelny sposób wyrażać to, co mają testować. Często
wprowadza się deklaratywny styl kodu testującego, nawet tworząc sweg
rodzaju "domain specific languages" do tego. Jest niezła książka
"Growing Object Oriented Software Guided By Tests" Freemana i Pryce'a,
która pokazuje jak można to zrobić w Javie.

Te same zasady można też rozciągnąć na część dokumentacji wymagań,
stosując tzw. Acceptance Test Driven Development. Tam nie dokumentuje
się jednostek kodu, ale cały system, poprzez tworzenie testów
operujących na zewnętrznych interfejsach. Tu wręcz wymaga się tego, żeby
te testy były wyrażony w sposób jak najbardziej zbliżony do domeny
biznesowej, tak żeby nie-programista (np. przedstawiciel klienta) mógł
czytać taki kod i potwierdzić, że warunki i oczekiwane zachowanie
systemu wyrażone są prawidłowo.

Oczywiście to wszystko nie wyczerpuje sytuacji, gdzie potrzebna jest
dokumentacja w klasycznej postaci (dokumentu), i przecież z agile i
dokumentacją nie chodzi o zaprzeczenie tego faktu, czy o religijne nie
tworzenie dokumentacji tam, gdzie trzeba ją stworzyć, tylko w tym
przypadku o konstatację, że zazwyczaj te alternatywne sposoby sprawdzają
się lepiej od tworzenia z góry i potem utrzymywania dokumentu.

do góry

On Sat, 10 Dec 2011 21:34:49 +0000, Andrzej Jarzabek
<a...@g...com> wrote:

>On 10/12/2011 21:00, Roman W wrote:
>> On Dec 10, 7:20 pm, Andrzej Jarzabek<a...@g...com>
>> wrote:
>>> On 10/12/2011 18:33, Roman W wrote:
>>>> Ja lubie dokumentacje. Tylko nie lubie jej pisac.
>>> Ja nieszczególnie lubię sytuację, kiedy:
>>> a) jest dokumentacja, ale opisuje nie do końca to, jaki program
>>> faktycznie jest,
>>
>> Ja tam wole miec niekompletna dokumentacje + zrodla niz tylko zrodla.
>
>Jest trochę taki problem, że jak dokumentacja opisuje rzeczy niezgodne z
>faktyczną rzeczywistością, to się na niej czas traci dwa razy: raz, jak
>się ją pisze, drugi raz, jak się próbuje z niej skorzystać.
>
>Poza tym ja się w ogóle zgodzę, że dokumentacja czasem jest potrzebna
>lub przydatna.

Naprawde?.... Takie ustepstwa Kolega czyni?...

A.L.

do góry

W dniu 2011-12-10 13:54, Roman W pisze:
> Moje osobiste obserwacje z systemami uzywanymi w duzych bankach (na
> przykladzie Murex) sa takie, ze one sie rozwijaja organicznie i nowe
> funkcjonalnosci sa czesto wrecz dopychane kolanem. Nikt nie ma czasu
> porzadkowac kodu, bo klienci (wewnetrzni badz zewnetrzni) naciskaja na
> nowe produkty. Grupa rozwijajaca dany kawalek kodu musi miec spory
> autorytet zeby przeforsowac decyzje "nie dodajemy nowych
> funkcjonalnosci przez pare miesiecy tylko refaktoryzujemy" bez
> spotkania sie z wielkim oporem. A programisci w bankach sa dobrze
> platni, ale na ogol nie maja wielkiego autorytetu.

Nie tylko klienci - nie wiem jak obecnie, ale początek tego wieku to 90%
zmian w takich systemach to zmiany związane z ciągle zmieniającym się
prawem...


--
Kaczus
http://kaczus.republika.pl

do góry

Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał w
wiadomości grup dyskusyjnych:jc0qek$gis$...@i...gazeta.pl...
> Dobrze napisane testy jednoostkowe mogą stanowić część dokumentacji kodu,
> ale przede wszystkim robi się tak, że zamiast stworzenia na początek
> dokumentu wymagań, masz w zespole ludzi, którzy rozumieją te wymagania na
> tyle, że mogliby taki dokument napisać, i masz człowieka, który na bieżąco
> może podejmować decyzje jak program ma działać, co ma w nim być, czego być
> nie ma, co można uprościć i tak dalej.

Człowiek od podejmowania decyzji może zwyczajnie umrzeć, zwłaszcza jeżeli to
jest człowiek z dużym doświadczeniem (czyli np. 50+).

do góry

On Sat, 10 Dec 2011 23:36:51 +0000, Andrzej Jarzabek
<a...@g...com> wrote:

>On 10/12/2011 22:24, Roman W wrote:
>> On Dec 10, 9:34 pm, Andrzej Jarzabek<a...@g...com>
>>>
>>> Jest trochę taki problem, że jak dokumentacja opisuje rzeczy niezgodne z
>>> faktyczną rzeczywistością, to się na niej czas traci dwa razy: raz, jak
>>> się ją pisze, drugi raz, jak się próbuje z niej skorzystać.
>>
>> Z regulay mozna wyodrebnic "rdzen" funkcjonalnosci, ktory sie raczej
>> nie zmieni, i przynajmniej ten udokumentowac.
>
>Niewątpliwie, jednak nie zawsze to jest potrzebne.
>
>Oczywiście, że wiele rzeczy dokumentować trzeba. Dla produktu musi
>powstać dokumentacja dla użytkownika końcowego, biblioteki czy inne
>komponenty powinny mieć udokumentowane API, a wszystkie decyzje,
>ustalenia i wnioski dotyczące funkcjonalności powinny być dokumentowane
>na bieżąco. I przecież w Agile się tego nie kwestionuje. Przede
>wszystkim odrzuca się tworzenie dokumentów, na podstawwie których
>tworzony jest program: dokumentacji wymagań i "dokumentu projektowego"
>czyli opisania całości struktury i jednostek kodu przed rozpoczęciem
>implementacji. W dalszej kolejności odrzuca się w ogóle potrzebę
>utrzymywania dokumentacji projektu kodu, nawet jeśli nie jest tworzony z
>góry.

Zwlaszcza dobrze sie to sprawdza przy pisaniu oprogramowania do
sterowania statecznikami poziomymi samolotu F-16, albo zeby byc blizej
ziemii, sterowania kolumna destylacyjna w Pertochemii Plockiej. Dobrze
tez taka metode zatosowac przy pisaniu oprogramwoania stuerujacego
kompresorami gazociagu magistralnego Jaroslaw-Wloclawek. Nie mowiac o
zwyklym, prostym komputerku sterujacym silnikiem samochodowym

Cale wasze doswiadczenie, Panowie, pochodzi z "pierdykniecia bazki
danych szlauchow i kaloszy dla Miejskiego Przedsiebiorstwa
Kanalizacyjnego". Software bywa ze obsluguje inne problemy tez. Duzo
bardziej skomplikowane. I takie ze jak sie pusci buga, to cos moze
wybuchnac albo ktos moze zostac zabity

A.L.

do góry

On Dec 15, 11:54 pm, "slawek" <s...@h...pl> wrote:
>
> > Dobrze napisane testy jednoostkowe mogą stanowić część dokumentacji kodu,
> > ale przede wszystkim robi się tak, że zamiast stworzenia na początek
> > dokumentu wymagań, masz w zespole ludzi, którzy rozumieją te wymagania na
> > tyle, że mogliby taki dokument napisać, i masz człowieka, który na bieżąco
> > może podejmować decyzje jak program ma działać, co ma w nim być, czego być
> > nie ma, co można uprościć i tak dalej.
>
> Człowiek od podejmowania decyzji może zwyczajnie umrzeć, zwłaszcza jeżeli to
> jest człowiek z dużym doświadczeniem (czyli np. 50+).

A ponieważ jest jedynym człowiekiem na Ziemi, który się zna na
temacie, to należy go nakłonić do jak najszybszego spisania jak
największego kawałka swojej wiedzy.

do góry