Comments for Battle for Agility

Comment on tinyPM 1.2 by Marcin Niebudek

Mon, 03 Nov 2008 10:02:46 +0000

:-) ech wiedzialem ze dwa newsy obok siebie to nie jest dobry pomysł… oczywiście, że wrócimy… nawet w kolejce mam dwa tematy: planowanie budżetu projektu do fixed price oraz śledzenie budżetu… tylko czasu mało… mało mało.

Obiecuję się poprawić i napisać o tych dwóch rzeczach zanim rzuce tu znowu coś o tinyPM :-)

Comment on tinyPM 1.2 by 2mind.pl

Mon, 03 Nov 2008 09:52:55 +0000

Ten blog od teraz będzie przeznaczony do opisów TinyPM czy wrócicie do starej formy ? :)

Comment on Jest już tinyPM v1.1 by Marcin Niebudek

Mon, 21 Jul 2008 20:35:22 +0000

Hmm… w związku z tym, że jestem jednym z współautorów tinyPM, to wszystko co powiem może być wykorzystane przeciwko mnie :-)

Generalnie funkcje tinyPM i XPlannera w obszarze podstawowego procesu zarządzania projektem agile są podobne. Kwestia dotyczy bardziej realizacji. Tworząc tinyPM chcieliśmy położyć większy nacisk na prostocie. XPlanner wydawał mi się mało przejrzysty. tinyPM jest wg mnie w działaniu bliższy tradycyjnym tablicom (zwłaszcza taskboard, z którym sam pracuję na codzień w wielu projektach).

Ciekaw jestem natomiast twoich wrażeń? Próbowałeś w swoich poszukiwaniach tinyPM? Jeśli nie to zachęcam do instalacji lub zajrzenia do DEMO.

Comment on Jest już tinyPM v1.1 by urs

Mon, 21 Jul 2008 12:57:13 +0000

Jak oceniasz jego funkcjonalność np. w porównaniu z XPlannerem ?
Szukałem ostatnio alternatywy dla XPlannera, ale nie udało mi się znaleźć nic sensownego.

Comment on Agile w Nokia Siemens Networks by Michał Ostruszka

Thu, 19 Jun 2008 07:08:40 +0000

Hmmm… Skoro testowanie napisanych w sprincie funkcjonalności odbywa się po tym sprincie w innym zespole, to czy to przypadkiem nie jest klasyczny przykład 2 ostatnich etapów waterfall’a? Estymaty robione przez pojedynczych programistów - wg mnie kompletnie mija się to z celem scruma, zespołu jako całości, odpwoiedzialnego za wszystkie zadania itp. Wydaje mi się, że oni poprostu zaadaptowali do swojego waterfalla ze scruma codzienne spotkania i burndown i nazwali to scrumem w NSN.

Comment on Harmonogram najważniejszy? by Marcin Niebudek

Wed, 18 Jun 2008 20:48:07 +0000

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 :-(

Comment on Harmonogram najważniejszy? by comma

Fri, 13 Jun 2008 10:48:15 +0000

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.

Comment on Agile w Nokia Siemens Networks by PanJaBu

Sat, 24 May 2008 22:05:24 +0000

Czytając ten opis zastosowania SCRUM w MSN mam wątpliwości czy nie powinni spróbować z MSF lub RUPem.
Z opisu wynika, że wymagania klienta są mglistę i raczej nie zmieniają się podczas kolejnych iteracji.
Jeśli tak jest to nie istnieje rola właściciela produktu to nie ma komu stwierdzić które z wymagań zapewni jak najszybszy zwrot z inwestycji (ROI).
Wykorzystanie CI oraz TDD może być elementem procesu wytwórczego także w innej metodologii niż Agile/Scrum.

Comment on Agile w Nokia Siemens Networks by Marcin Niebudek

Mon, 28 Apr 2008 07:24:45 +0000

No takich refleksji zabrakło… To tak wyglada trochę, jakby Scrum miał być zalecony odgórnie, ale bez jakiegoś większego przekonania. Tzn. “góra” każe developerom wdrożyć Scrum bo to podniesie przecież wydajność i jakość, ale poza tym, to nie chce mieć z tym wiele wspólnego. No ale może oddolnie zaimplementowana metoda da się z czasem radę przebić wyżej.

Co do tych 500 SMów to podejrzewam, że chodzi o liczbę w skali globalnej i pewnie większość z nich to ludzie pracujący w NSN w Finlandii lub innych zakątkach Europy.

Comment on Agile w Nokia Siemens Networks by Bartosz Kramek

Mon, 28 Apr 2008 00:25:01 +0000

Brakuje mi informacji jakie były “przesłanki zastnienia problemu”, innymi słowy: co ich skłoniło do wprowadzenia agile? Moda?

Ponadto: jakie są ich refleksje? W czym pomógł im scrum i czy są z niego zadowoleni?

Czy docelowo będą zmierzali do “pure scrum” ?

Ta liczba… 500 SM - wcześniej jest mowa o czterech zespołach scrumowych…