Użytkownik <e...@g...com> napisał:

> a potem zastosuj Wspolczynnik (pi razy drzwi 200% - 1000%)

Srednio 400%

AK

do góry

Dnia 28-12-2012 o 16:23:47 AK <n...@n...com> napisał(a):

> Użytkownik <e...@g...com> napisał:
>
>> a potem zastosuj Wspolczynnik (pi razy drzwi 200% - 1000%)
>
> Srednio 400%
>
> AK

http://www.joelonsoftware.com/items/2007/10/26.html ?

--
Jordan Szubert

do góry

W dniu 2012-12-27 12:32, boryspower pisze:
> Witam,
>
> Hobbystycznie programuję od dawna, ale na zasadzie "mam pomysł -> koduję" co jest
raczej mało dojrzałym podejściem... i chciałbym to zmienić. Kilka razy próbowałem
rozpisywać projekty "po swojemu" opisując funkcjonalność do której dążę itp, ale
doszedłem do wniosku, że nie ma sensu wymyślać czegoś co już istnieje i przydałoby
się skorzystać z osiągnięć innych, bardziej doświadczonych osób w tej dziedzinie...
Pomysłów (moim zdaniem dobrych) mam sporo, ale żaden nie jest udokumentowany, więc
też ciężko się sensownie zabrać za ich realizację.
>
> I tu pytanie do Was - od czego powinienem zacząć chcąc nauczyć się porządnego
prowadzenia/dokumentowania projektów? W szczególności chodzi mi o sytuację gdzie ja
sam jestem project managerem i programistą, czasami też klientem. Znacie jakieś
książki/tutoriale/kursy?
>
> Pozdrawiam!
>

UML

do góry

W dniu piątek, 28 grudnia 2012 16:23:47 UTC+1 użytkownik AK napisał:
> Użytkownik <e...@g...com> napisał:
> > a potem zastosuj Wspolczynnik (pi razy drzwi 200% - 1000%)
> Srednio 400%
Moj max około 300%.

do góry

Użytkownik "M.M." <m...@g...com> napisał:

> Moj max około 300%.

* 2

do góry

W dniu piątek, 28 grudnia 2012 20:28:08 UTC+1 użytkownik AK napisał:
> > Moj max około 300%.
> * 2

Dużo zależy od projektu. Im projekt prostszy, tym mniejszym
nakładem (albo w ogole) można dokładniej ocenić pracochłonność.

Zastanawiam się jakie mam minimum i chyba wynosi ono 33%. To co
było oszacowane na 9miesięcy dla dwóch osób wklepaliśmy w 3 miesiące.

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 ja wręcz przeciwnie. BTW dobra książka dla OP w temacie to Robert C.
Martin "Agile Software Development: Principles, Patterns and Practices",
w tym sensie że koncentruje się właśnie na "engineering pracitices"
raczej niż na koordynowaniu zespołu czy współpracy z klientem. Dodatkowo
Steve Freeman i Nat Pryce "rowing Object-Oriented Software Guided By
Tests" jest całkiem dobrą książką o TDD.

Nawiasem mówiąc nie od rzeczy jest według mnie spostrzeżenie, że jeśli
się robi samemu i dla siebie, to stosowanie praktyk czy metod
przeznaczonych do pracy w zespole i dla klienta jest bez sensu -
powiedzmy nawet to całe mnożenie szacunków przez 300%, klaryfikacja
wymagań i tak dalej. Sam siebie będziesz okłamywał i sam sobie będziesz
tłumaczył co program ma robić?

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"
Gojko Adzic "Specification by Example"

do góry

Dnia 28.12.2012 firr kenobi <p...@g...com> napisał/a:
> ja 'dokumentowania' nie uzywam wogole, miałem
> jedna linijke TODO ale mnie denerwowała wiec ja
> skasowałem :O

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

do góry

W dniu sobota, 29 grudnia 2012 04:08:39 UTC+1 użytkownik Andrzej Jarzabek napisał:
> 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 ja wręcz przeciwnie. BTW dobra książka dla OP w temacie to Robert C.
>
> Martin "Agile Software Development: Principles, Patterns and Practices",
>
> w tym sensie że koncentruje się właśnie na "engineering pracitices"
>
> raczej niż na koordynowaniu zespołu czy współpracy z klientem. Dodatkowo
>
> Steve Freeman i Nat Pryce "rowing Object-Oriented Software Guided By
>
> Tests" jest całkiem dobrą książką o TDD.
>
>
>
> Nawiasem mówiąc nie od rzeczy jest według mnie spostrzeżenie, że jeśli
>
> się robi samemu i dla siebie, to stosowanie praktyk czy metod
>
> przeznaczonych do pracy w zespole i dla klienta jest bez sensu -
>
> powiedzmy nawet to całe mnożenie szacunków przez 300%, klaryfikacja
>
> wymagań i tak dalej. Sam siebie będziesz okłamywał i sam sobie będziesz
>
> tłumaczył co program ma robić?
>
>
>
> 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"
>
> Gojko Adzic "Specification by Example"

Dzięki - zerknę na te książki :)

Przemek

do góry

W dniu sobota, 29 grudnia 2012 10:33:44 UTC+1 użytkownik Baranosiu napisał:
> Dnia 28.12.2012 firr kenobi <p...@g...com> napisał/a:
>
> > ja 'dokumentowania' nie uzywam wogole, miałem
>
> > jedna linijke TODO ale mnie denerwowała wiec ja
>
> > skasowałem :O
>
>
>
> 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 (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 :-/)
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 ;-)

do góry