Przyjęło się, że gdy podzielimy problem na mniejsze fragmenty będzie on prostszy w realizacji. Z logicznego punktu widzenia nie powinno mieć to znaczenia – dekompozycja projektu na małe kawałki nie zmniejsza poziomu skomplikowania, ani nie redukuje zakresu – to tylko logiczny podział. Więc jak to jest z rozmiarem zadania? „Czy rozmiar ma znaczenie? ;)”

Pamiętam gdy byłem młodszy, myślałem sobie że taki PM to co najmniej darmozjad. Siedzi na dupsku i czyta internet. Czasem zajrzy do pokoju gdzie krew, pot, łzy. Gdzie bohaterowie oddają swoje życie na froncie. Gdzie dzieje się prawdziwa praca, a komputery piszczą z rozkoszy kompilacji. I zamarudzi taki, czemu to jeszcze nie działa, a czemu wolno, a miało być, a jak tu kliknę to źle się dzieje, godzin nie zaraportowaliście, źle je zaraportowaliście i tak marudzi, a potem idzie z in...

Luźny wpis, w którym poruszę temat raportowania stanu projektu. Zachęcam do przeczytania wszystkich, którzy takie raporty piszą, a przede wszystkim tych, którzy je czytają :). Odpowiem dlaczego pytanie „ile procent projektu mamy ukończone?” może zakłamywać rzeczywistość i dawać złudne poczucie bezpieczeństwa. Pokażę również bardziej skuteczną metodę raportowania stanu projektu. Gdy stawiałem pi...

W tym wpisie poruszę temat tego jak bufory „bezpieczeństwa” (cudzysłów nie jest przypadkowy) w taskach wpływają na przedłużenia projektu. Opiszę również jak „kary” za nie wykonywanie zadań w terminie przez developerów przyczyniają się do opóźnień. Zrozumienie istoty problemu jest pierwszym krokiem do ich eliminacji i zwi...

Odpowiednie rozbicie historii na taski ma kluczowy czynnik w powodzeniu projektu. Jeśli ta czynność jest źle wykonana – czas realizacji projektu się wydłuża, a w zespole rośnie frustracja bo nikt nie wie gdzie leży problem. Developerzy pracują w pocie czoła, PM skrupulatnie trzyma się metodologii prowadzenia projektu, a mimo to są opóźnienia (które niestety najczę...

Estymowanie projektów IT to trudne zadanie. Najczęściej w estymowaniu chodzi o to, by trafić jak najbliżej faktycznej ceny projektu, by popełnić jak najmniejszy błąd. Okrągłe liczby kłamią! Znakomicie widać to podczas wyceny projektów, kiedy projekt jest oszacowany na 10, 50, 100, 200 tysięcy to najprawdopodobniej mamy do czynienia z niedoszacowaną lub przeszacowaną wyceną. Opiszę bł...

Let’s be agile! We are a team; we are winners - thought manager of the project like many others on the IT market. Therefore, since we are a group that has a common goal, we focus on success, and do everything to meet clients’ needs - why do we fail? It is time to take things into our hands, let’s organize our work, let’s implement agile projects. Let’s be agile! That was the idea of our main character. The question is, how to be agile? How to introduce agile methodologies to our project? Ho...