Comments on: Harmonogram najważniejszy? http://www.agilers.com/teamblog/harmonogram-najwazniejszy/ Metody agile w realiach polskiego IT Fri, 18 May 2012 18:38:24 +0000 http://wordpress.org/?v=2.0.4 by: Marcin Niebudek http://www.agilers.com/teamblog/harmonogram-najwazniejszy/#comment-6706 Wed, 18 Jun 2008 20:48:07 +0000 http://www.agilers.com/teamblog/harmonogram-najwazniejszy/#comment-6706 Z jednym się nie zgodzę... jeśli agile ma w projekcie zadziałać, to klient musi wziąć w tym udział, musi być świadomy co zamierzamy mu uczynić tymi niecnymi awangardowymi procesami :-) I wreszcie musi wiedzieć co go czeka - nie wystarczy podpisać umowę a potem już tylko czekać na efekty i śledzić termin realizacji. Klient przychodząc do nas firm softwarowych zwykle nie ma pojęcia jak tak faktycznie wygląda wytwarzanie oprogramowania. To nasze zadanie, aby go choć trochę próbować uświadomić. Na umowie projekt się nie kończy... no chyba, że nieudany projekt :-( Z jednym się nie zgodzę… jeśli agile ma w projekcie zadziałać, to klient musi wziąć w tym udział, musi być świadomy co zamierzamy mu uczynić tymi niecnymi awangardowymi procesami :-) I wreszcie musi wiedzieć co go czeka - nie wystarczy podpisać umowę a potem już tylko czekać na efekty i śledzić termin realizacji.

Klient przychodząc do nas firm softwarowych zwykle nie ma pojęcia jak tak faktycznie wygląda wytwarzanie oprogramowania. To nasze zadanie, aby go choć trochę próbować uświadomić. Na umowie projekt się nie kończy… no chyba, że nieudany projekt :-(

]]> by: comma http://www.agilers.com/teamblog/harmonogram-najwazniejszy/#comment-6493 Fri, 13 Jun 2008 10:48:15 +0000 http://www.agilers.com/teamblog/harmonogram-najwazniejszy/#comment-6493 To o czym piszesz ma duże podłoże w kontaktach z klientem. Teoretycznie niedopuszczalne jest aby wystartować projekt bez wszystkich danych wymaganych od klienta - bez nich występuje brak wyobrażenia co tak naprawdę chcemy uzyskać i jakie są prawdziwe problemy systemu który tworzysz. Tak, to jest wiązanie sobie pętli na szyi. Twój apel powinien być tak naprawdę nie powinien być skierowany do klientów - oni mają prawa wymagać tylko efektów i działać wg. warunków umowy. Powinni go posłuchać ludzie którzy definiują zasady umowy wykonania. A dobrze sformułowana umowa jest podstawą aby części problemu z pogonią i błędnym planowaniem po prostu nie było :) A odnośnie reszty - zgadzam się z tym aby najpierw wykonywać te user stories które tak naprawdę umodelują (i może przyczynią się do refaktoryzacji :) cały projekt. To o czym piszesz ma duże podłoże w kontaktach z klientem. Teoretycznie niedopuszczalne jest aby wystartować projekt bez wszystkich danych wymaganych od klienta - bez nich występuje brak wyobrażenia co tak naprawdę chcemy uzyskać i jakie są prawdziwe problemy systemu który tworzysz. Tak, to jest wiązanie sobie pętli na szyi.
Twój apel powinien być tak naprawdę nie powinien być skierowany do klientów - oni mają prawa wymagać tylko efektów i działać wg. warunków umowy. Powinni go posłuchać ludzie którzy definiują zasady umowy wykonania. A dobrze sformułowana umowa jest podstawą aby części problemu z pogonią i błędnym planowaniem po prostu nie było :)
A odnośnie reszty - zgadzam się z tym aby najpierw wykonywać te user stories które tak naprawdę umodelują (i może przyczynią się do refaktoryzacji :) cały projekt.

]]>