On 29/12/2012 15:43, boryspower wrote:
> W dniu sobota, 29 grudnia 2012 04:08:39 UTC+1 użytkownik Andrzej Jarzabek napisał:
>>
>> Jeśli jednak OP jest zainteresowany też takimi aspektami prowadzenia
>>
>> projektu, to mogę dodatkowo polecić (jeśli chodzi o agile):
>>
>> James Shore, Shane Warden "The Art od Agile Development"
>> Mike Cohn "User Stories Applied"
>
> Dzięki - zerknę na te książki :)

Nawiasem mówiąc, opisana m. in. w tych dwóch książkach powyżej technika
szacowania przez story points jest co prawda pomyślana pod kątem pracy w
zespole, jednak dałoby się ją chyba z powodzeniem zaadaptować do pracy solo.

No i być może właśnie jak sam sobie jesteś sterem, żeglarzem, okrętem,
to stosowanie user stories może mieć właśnie szczególny sens dlatego, że
niejako zmusza cię do przyjęcia optyki użytkownika programu.

do góry

Dnia 29.12.2012 firr kenobi <p...@g...com> napisał/a:
> W dniu sobota, 29 grudnia 2012 10:33:44 UTC+1 użytkownik Baranosiu napisał:
[...]
>> Kwestia złożoności projektu (i "pojemnosci" głowy) - proste rzeczy da
>> się ogarnąć w głowie, ale projekty które powstają przez kilka miesięcy
>> solidnej codziennej pracy to raczej bez planowania i dokumentowania
>> się nie da (zwłaszcza, jeśli tworzy się w zespole) :D Więc takiej
>> metodologii (olewanie dokumentowania i planowania) nie polecam nawet
>> na początku drogi z programowaniem (i dla prostych projektów), bo
>> wyrobi złe nawyki :D
>
> ja nie uzywam dokumentowania i nie mam z tym zadnego problemu

No to gratuluję, ja bez prowadzenia notatek i dokumentacji (i bez
projektowania) nie radzę sobie z projektami większymi niż 2-3 tysiące
linijek kodu (tzn. pół biedy jeszcze napisać gdy jestem we "flow" i
projekt jest w miare prosty, ale coś zmienić po kilku miesiącach to
już masakra :D)

> (problem mam z czyms innym
> - z czyms w rodzaju tweakowania, dostrajania
> aplikacji (tj staraniach aby tak poustawiac
> wyglad czy efekty by to jakos wygladalo) - jest to masakrycznie
> czaslochlonne, trufnouchwytne, frustrujace itd (to jest
> chyba najgorsze :-/)

"Bajerowanie" aplikacji to już inna sprawa (zwykle tego nie robię :D),
wystarcza mi przejrzystość i tzw. "intuicyjność" obsługi (no ale to
jest kwestia projektu a nie tuningu).

> Za to wazne jes myslenie nad kodem i to lubie robic, np ostatnio
> rozwazam podzielenie swojego domowego frameworka na cztery
> podsystemy: 1) wis, 2) dris, 3) cis i 4) oglis ;-)

Łamigłówki są cool :D
Co do dylematu "podzielić czy nie" - to nie jest kwestia
programistyczna (pod tym względem pewnie już wiesz, że podział byłby
korzystny, inaczej byś tego nie rozważał :D), to jest raczej kwestia
umiejętności podejmowania decyzji jako takich (i zaakceptowania ich
konsekwencji), a to już zupełnie inna bajka :D

do góry

W dniu niedziela, 30 grudnia 2012 09:55:49 UTC+1 użytkownik Baranosiu napisał:
> Dnia 29.12.2012 firr kenobi <p...@g...com> napisał/a:
>
> > W dniu sobota, 29 grudnia 2012 10:33:44 UTC+1 użytkownik Baranosiu napisał:
>
> [...]
>
> >> Kwestia złożoności projektu (i "pojemnosci" głowy) - proste rzeczy da
>
> >> się ogarnąć w głowie, ale projekty które powstają przez kilka miesięcy
>
> >> solidnej codziennej pracy to raczej bez planowania i dokumentowania
>
> >> się nie da (zwłaszcza, jeśli tworzy się w zespole) :D Więc takiej
>
> >> metodologii (olewanie dokumentowania i planowania) nie polecam nawet
>
> >> na początku drogi z programowaniem (i dla prostych projektów), bo
>
> >> wyrobi złe nawyki :D
>
> >
>
> > ja nie uzywam dokumentowania i nie mam z tym zadnego problemu
>
>
>
> No to gratuluję, ja bez prowadzenia notatek i dokumentacji (i bez
>
> projektowania) nie radzę sobie z projektami większymi niż 2-3 tysiące
>
> linijek kodu (tzn. pół biedy jeszcze napisać gdy jestem we "flow" i
>
> projekt jest w miare prosty, ale coś zmienić po kilku miesiącach to
>
> już masakra :D)
>
>
>
> > (problem mam z czyms innym
>
> > - z czyms w rodzaju tweakowania, dostrajania
>
> > aplikacji (tj staraniach aby tak poustawiac
>
> > wyglad czy efekty by to jakos wygladalo) - jest to masakrycznie
>
> > czaslochlonne, trufnouchwytne, frustrujace itd (to jest
>
> > chyba najgorsze :-/)
>
>
>
> "Bajerowanie" aplikacji to już inna sprawa (zwykle tego nie robię :D),
>
> wystarcza mi przejrzystość i tzw. "intuicyjność" obsługi (no ale to
>
> jest kwestia projektu a nie tuningu).
>
>
>
> > Za to wazne jes myslenie nad kodem i to lubie robic, np ostatnio
>
> > rozwazam podzielenie swojego domowego frameworka na cztery
>
> > podsystemy: 1) wis, 2) dris, 3) cis i 4) oglis ;-)
>
>
>
> Łamigłówki są cool :D
>
> Co do dylematu "podzielić czy nie" - to nie jest kwestia
>
> programistyczna (pod tym względem pewnie już wiesz, że podział byłby
>
> korzystny, inaczej byś tego nie rozważał :D), to jest raczej kwestia
>
> umiejętności podejmowania decyzji jako takich (i zaakceptowania ich
>
> konsekwencji), a to już zupełnie inna bajka :D


dla mnie ta designerska strona (czyli glownie
klecenie grafy/efektow) jest nieporownanie
trudniejsza niz samo programowanie, mozna sie
pochlastac wykonujac 900-t prób i czasem cos ładnie wychodzi ale zwykle nie bardzo

(zeby cos zaprogramowac wystarczy zaprogramowac a zeby cos ladnie wygladalo
czeba to czasem programowac 15 razy nim sie trafi na cos co wyglada a i tak
posniej efekt sie moze posypac przy kolejnych dobudowach)

np tutaj

https://dl.dropbox.com/u/42887985/ma_ex_d.zip

(skalowanie F3/F4 fullscr pageup, ew rozdzialaka control+3)

cholerstwo nie wychodzilo az wpadlem na pomysl zrobienia malej rameczki wokolo
postaci i wtedy wyglad gwałtownie skoczył

teraz pytania (1) jak jasno oznaczac pola nieprzechodnie (tutaj drzewa) bo jak sie
chodzi przy drzewach to nie widac na ktore pole mozna wejsc na ktore nie - to psuje
filing
(2) jak ozbaczac przedmioty (tutaj oznaczane malym kwadracikiem
- wiekszosc pomyslow okrutnie nie harmonizuje
np proba wstawienia kwadratem przekreslonym w X
albo kolka jest wogole nie do przyjecia itd
- np wydaje sie ze nie harmonizuje dowolna forma ukosnej kreski (nie do przyjecia
jest prawie nic - i tak 3 dni sie meczylem (i omalo sie ze 100 razy 'nie
pochlastalem') z tweakowaniem 'formy prezentacji' zeby dobrac obecna w miare wygledna
forme)

fir

do góry

W dniu niedziela, 30 grudnia 2012 09:55:49 UTC+1 użytkownik Baranosiu napisał:
> Dnia 29.12.2012 firr kenobi <p...@g...com> napisał/a:
> >> Kwestia złożoności projektu (i "pojemnosci" głowy) - proste rzeczy da
> >> się ogarnąć w głowie, ale projekty które powstają przez kilka miesięcy
> >> solidnej codziennej pracy to raczej bez planowania i dokumentowania
> >> się nie da (zwłaszcza, jeśli tworzy się w zespole) :D Więc takiej
> >> metodologii (olewanie dokumentowania i planowania) nie polecam nawet
> >> na początku drogi z programowaniem (i dla prostych projektów), bo
> >> wyrobi złe nawyki :D
> >
> > ja nie uzywam dokumentowania i nie mam z tym zadnego problemu
> No to gratuluję, ja bez prowadzenia notatek i dokumentacji (i bez
> projektowania) nie radzę sobie z projektami większymi niż 2-3 tysiące
> linijek kodu (tzn. pół biedy jeszcze napisać gdy jestem we "flow" i
> projekt jest w miare prosty, ale coś zmienić po kilku miesiącach to
> już masakra :D)

Dużo zależy od tego jak używać określenia: "nie mam z tym problemu vs
mam z tym problem". Po pierwsze duża część osób, która miałyby mniejsze problemy
(gdyby tak pracowała), otwarcie przyzna, że ma z tym problemy. I na odwrót,
duża cześć tych osób, które mają problemy, może nawet ich nie dostrzegać.

Wiele razy zdarzało mi się pisać duży ( duży jak na 2-4 osobowy zespół i
3-12 miesięcy pracy ) program zupełnie bez dokumentacji, projektu, a nawet
głębszego przemyślenia. Mam prawie pewność, że tak było najlepiej, ale
to były bardzo specyficzne warunki - dużo by pisać.

Pytanie czy po czasie "mieliśmy problemy czy nie". Nie uważam się za osobę o
jakiejś nadzwyczajnej pojemności głowy, ale pomimo tego że programy był
znacznie większy niż 2-3 tys linii, to myślę, że nie miałem żadnych
problemów - jednak do pewnego momentu. Ten moment to chwila gdy główny
projekt odstawiłem i np. na 2tyg zaangażowałem się w jakiś inny, mały
programik. Gdy wracałem do głównego projektu, to czułem jakbym
miał wyprany mózg. Poruszałem się przez dłuższy czas jak nieporadne
niemowlę i musiałem się wdrażać w kod napisany w dużej części przez
samego siebie.

Nie uczestniczyłem nigdy w ogromnych projektach, gdzie pracuje np. 50
programistów przez 10 lat. Trudno mi jest powiedzieć, jaką dokładnie rolę
odgrywa projekt. Domniemam że dobry projekt ma znaczenie kluczowe, ale na
podstawie swojego doświadczenia nie mogę nic powiedzieć na ten temat.

Natomiast jeśli chodzi o projekty rzędu 3-12 miesięcy i zespół rzędu 2-4
osoby, to kluczową rolę projektu widzę na poziomie negocjacji z klientem.
Jeśli sam nie muszę od głównego projektu odrywać się do jakiś
małych, pobocznych zadań, jeśli mam zaufanie do współpracowników,
to ja osobiście nie czuję jakiegoś specjalnego dyskomfortu z powodu
braku projektu.

Projekt wielokrotnie pomagał mi w rozmowach z pewną kategorią klientów.
Mogłem rozmowy prowadzić na zasadzie: tak było w projekcie, projekt został
zaakceptowany, tak wykonaliśmy... a jeśli coś nie odpowiada, to robimy nową
umowę i nowy projekt.

Niestety powyższy przykład klienta nie jest moim
statystycznym klientem. Zwykle mam odpowiedzialność za to, że oprogramowanie
będzie przynosiło konkretne rezultaty, jakieś zyski, jakieś oszczędności,
jakieś usprawnienia, jakieś przewidywania... Rzadko mogę zasłonić się
punktem w projekcie czy umowie. Zwykle pracuję w takich warunkach, że jeśli coś
nie odpowiada klientowi, to jest moja wina. Oczywiście to jest rekompensowane
odpowiednimi warunkami płatności, itd, itd. Ciężko zebrać w jednym poście
wszystko na ten temat :)

Pozdrawiam

do góry

W dniu niedziela, 30 grudnia 2012 20:42:52 UTC+1 użytkownik firr kenobi napisał:
>(zeby cos zaprogramowac wystarczy zaprogramowac a zeby cos ladnie wygladalo
>czeba to czasem programowac 15 razy nim sie trafi na cos co wyglada a i tak
>posniej efekt sie moze posypac przy kolejnych dobudowach)
Powiedzmy umownie, ze sa dwa rodzaje aplikacji.

Jedne po prostu sie pisze, maja dzialac, a szczegoly typu: szybkosc
dzialania, ilosc pamieci, rodzaj wykorzystanych technik programistycznych -
mozna z jakis powodow calkowicie, albo prawie calkowicie pominac.

Drugi rodzaj to taki, w których rzeźbi się tygodniami, żeby przyspieszyć o
kilka milisekund, albo myśli się miesiącami, żeby opracować lepszy algorytm.
Czasami trzeba udowodnić czy dany algorytm w ogóle może rozwiązywać jakieś
zadanie. Do tego drugiego rodzaju można by jeszcze sporo dorzucić, Ty np.
dorzucasz dopracowanie grafiki, efektów, itd.


Wszystko wskazywałoby na to, że ten drugi rodzaj aplikacji jest dużo
trudniejszy, bardziej ambitny, czy wymagający większych umiejętności. Okazuje
się jednak, że ten pierwszy typ aplikacji, może po pierwsze znacznie
się rozrosnąć - zgranie dużej ilości rożnych elementów programu powoduje,
że staje się on równie trudny jak te z drugiego rodzaju. Po drugie, może
być bardzo mały budżet na ich wykonanie, wtedy trzeba taką aplikację szybko
zrealizować żeby wyjść na jakiś minimalny plus.

Pozdrawiam

do góry

On 28/12/2012 02:30, Wojciech Muła wrote:
> W dniu czwartek, 27 grudnia 2012 19:14:27 UTC+1 użytkownik e...@g...com
napisał:
>> Zaleznie od tego, czy kupisz ksiazke nt. Prince2, Agile czy o starym dobrym
>> Waterfall szczegoly moga sie nieco roznic w tym ostatnim punkcie, techniki
>> przewiduja rozne reakcje na zle dobrany Wspolczynnik Project Manadzera.
>
> Agile radzę omijać z daleka.

A skoro już mamy nowy rok, to dla podtrzemania dyskusji napiszesz może
dlaczego?

do góry

W dniu wtorek, 1 stycznia 2013 18:13:48 UTC+1 użytkownik Andrzej Jarzabek napisał:
> > Agile radzę omijać z daleka.
>
> A skoro już mamy nowy rok, to dla podtrzemania dyskusji napiszesz może
> dlaczego?

Agile skupia się na tworzeniu działającego produktu, nie dostarcza żadnych
narzędzi dla zespołu w celu tworzenia utrzymywalnego programu. Celem jest
działający produkt i zadowolenie klienta (tu i teraz).

Mam okazję uczestniczyć w procesie SCRUMowym i nie potrafię dostrzec żadnych
pozytywnych cech takiego postępowania. Najbardziej irytujące jest właśnie
skupienie się na dostarczeniu "inkrementu" na review, przez co odkładane
są prace na później. W konsekwencji kod wymaga refaktoringu w kolejnej
iteracji/iteracjach, więc i straty czasu.

Precyzyjne planowanie prac jest wykonywane w perspektywie jednego sprintu,
przez co mamy do czynienia z podejściem "koduj najpierw, myśl później".

w.

do góry

On 01/01/2013 20:12, Wojciech Muła wrote:
> W dniu wtorek, 1 stycznia 2013 18:13:48 UTC+1 użytkownik Andrzej Jarzabek napisał:
>>> Agile radzę omijać z daleka.
>>
>> A skoro już mamy nowy rok, to dla podtrzemania dyskusji napiszesz może
>> dlaczego?
>
> Agile skupia się na tworzeniu działającego produktu, nie dostarcza żadnych
> narzędzi dla zespołu w celu tworzenia utrzymywalnego programu. Celem jest
> działający produkt i zadowolenie klienta (tu i teraz).
>
> Mam okazję uczestniczyć w procesie SCRUMowym i nie potrafię dostrzec żadnych
> pozytywnych cech takiego postępowania. Najbardziej irytujące jest właśnie
> skupienie się na dostarczeniu "inkrementu" na review, przez co odkładane
> są prace na później. W konsekwencji kod wymaga refaktoringu w kolejnej
> iteracji/iteracjach, więc i straty czasu.
>
> Precyzyjne planowanie prac jest wykonywane w perspektywie jednego sprintu,
> przez co mamy do czynienia z podejściem "koduj najpierw, myśl później".

Trudno mi się wypowiedzieć na temat tego procesu, w którym miałeś
okazjęę uczestniczyć, ale ogólnie jeśli chodzi o techniki Agile to się
przykłada _bardzo_ dużą wagę do utrzymywalności kodu i w ramach Agile
jest całkiem sporo narzędzi do tego celu. Paradoksalnie, właśnie
wspomniana przez ciebie refaktoryzacja jest jednym z tych narzędzi.

Może ci się wydawać, że metoda "do the simplest thing" a potem
refaktoryzowania jest mniej wydajna od BDUF. Częscią problemu z takim
założeniem jest to, że często się okazuje, że to, co początkowo wydawało
się potrzebne, w końcu okazuje się niepotrzebne lub niewiele warte i
wypada z release. Drugą częścią jest to, że jeśli potrzebne okaże się
coś, czego twój projekt nie przewidział, to to wszystko, co
przewidziałeś i pod co "ugeneryczniłeś" swój projekt staje się balastem,
nawet jeśli z tej elastyczności nie korzystasz.

Tak więc jeden argument jest taki, że czas można w ten sposób nie
stracić, a zyskać. W rzeczywistości być może jest tak i tak.

Drugi argument natomiast jest psychologiczny i jako taki subiektywny,
ale wielu ludziom się w ten sposób po prostu lepiej pracuje. Działa to
chyba trochę na tej samej zasadzie co zrozumienie złożonego problemu
przez ograniczenie go do prostszego, i potem dokładanie kolejnych
komplikacji. Jeśli release'owa postać programu jest takim złożonym
problemem, to uważam, że uzyskanie działającego programu dla
uproszczonych wariantów (wraz z baterią testów oczywiście) daje znacznie
lepszą szanse na rzeczywiste zrozumienie problemu niż napisanie
dokumentu czy narysowanie diagramu - nawet jeśli trochę więcej czasu
trzeba na to poświęcić. A mój większy komfort w tym względzie przekłada
się na pozytywny wpływ na wydajność pracy, która z naddatkiem kompensuje
tę stratę.

do góry

Użytkownik "Wojciech Muła" <w...@g...com> napisał :

> Agile skupia się na tworzeniu działającego produktu, nie dostarcza
> żadnych narzędzi dla zespołu w celu tworzenia utrzymywalnego programu
^^^^^^^^^^^^^^^

To (i calosc posta Wojtka) to dla mnie sedno tzw. Agile.

AK

do góry

On 02/01/2013 17:28, AK wrote:
> Użytkownik "Wojciech Muła" <w...@g...com> napisał :
>
>> Agile skupia się na tworzeniu działającego produktu, nie dostarcza
>> żadnych narzędzi dla zespołu w celu tworzenia utrzymywalnego programu
> ^^^^^^^^^^^^^^^
>
> To (i calosc posta Wojtka) to dla mnie sedno tzw. Agile.

Jest dokładnie przeciwnie - to Agile wprowadziło skuteczne narzędzia do
tworzenia utrzymywalnego programu. Przedtem było tak, że się tworzyło
program, a potem w ramach utrzymywania jego utrzymywalność się stopniowo
degradowała, aż dochodziło do tego, że taniej było zrobić rewrite niż
zmieniać istniejący kod.

Właśnie zakończyłem udział w projekcie, który był wdrażany przez dwa
lata zanim do niego przystąpiłem. Przez to, że projekt nie korzystał z
narzędzi Agile wyszło na to, że efektem dwóch lat pracy był
niedziałający nieutrzymywalny kod i ileś tam sron bezużytecznej
dokumentacji, plus bardzo wkurzony klient. Dopiero zastosowanie narzędzi
typowych dla Agile (jeden z wdrożeniowców wciągniętych do projektu ma w
tym spore doświadczenie) pozwoliło na to, że stopniowo zaczęliśmy
opanowywać sytuację.

Sam produkt, który był w tym projekcie wdrażany, jest również tworzony
metodami tradycyjnymi (nie Agile). Rezultatem jest nie tylko niska
niezawodnośc produktu (dużo bugów), ale też właśnie kod trudny w
utrzymaniu (niektóre moduły mają po kilkanaście tysięcy linii kodu,
niektóre funkcje po kilka tysięcy). Jedno z drugim oczywiście się ściśle
wiąże - niska czytelność kodu powoduje, że łatwo wprowadzić bugi, niski
test coverage powoduje bugi z jednej strony i ryzykowność refaktoryzacji
z drugiej.

Brak "agility" był również bezpośrednią przyczyną zawalenia się bardzzo
lukratywnego kontraktu na dostarczenie klientowi specjalnej wersji owego
produktu: klient widział żonglerkę wymaganiami, a nie widział
działającego oprogramowania, więc pomimo wpakowania w projekt milionów
dolarów wolał zrezygnować i zrobić sobie wszystko samemu, niż wpakować
kolejne miliony w coś co, jak uznał, nie ma wystarczająco dużej szansy
na satysfakcjonujące rezultaty.

Dla porównania miałem okazję zaobserwować zespół tworzący podobny
produkt w tej samej firmie (dlaczego ta samam firma produkuje dwa bardzo
podobne produkty to osobny temat) i ten zespół stosuje Scrum i praktyki
inżynieryjne Agile. Nie tylko mają przez to mniejsze problemy z
niezawodnością, ale też właśnie ich kod jest znacznie łatwiejszy w
utrzymaniu.

Na koniec jeszcze napiszę o małym projekciku, który przejąłem po innym
programiście. Teoretycznie utrzymywalność nie była taka istotna, bo z
założenia był to "throwaway code" do wykonania raz. Programista, od
którego przejąłem projekt pisał go od mniej-więcej roku i nie potrafił
doprowadzić go do postaci nadającej się do odpalenia w produkcji. Z
różnych względów pełny proces Agile nie miał zastosowania, przede
wszystkim dlatego, że był tylko jedcen programista, ale też np. uznałem,
że ze względu na specyfikę kodu pełny TDD byłby nieco overkill, ale
jednak udało mi się opanować i zakończyć projekt przed terminem dzięki
zastosowaniu narzędzi Agile, głównie związanych z komunikacją z
klientami, ale w ramach utrzymywalności kodu (która okazała się nie taka
jednak znowu nieistotna) bardzo przydatnym narzędziem był na przykład
"merciless refactoring" (co może się wydawać ryzykowne bez TDD, ale
dzięki specyfice kodu i narzędziom do automatycznej refaktoryzacji byłem
w stanie utrzymać ryzyko na akceptowalnym poziomie).

do góry