Project management 101

Публикувано / posted 2014-01-06 в категория / in category: Некои съображения
  

По дебелите книги за меринджейство пишело, че съвременните agile методи позволявали проектите да се разработват на хоризонтални slice-ове, т.е. user story след user story, т.е. така:

p1

Правите си user story 1, после минавате на user story 2 и така докато приключите.

Реалността обаче е такава, че в мнозинството от случаите нещата изглеждат в най-добрия (и най-опростен) вид така:

p2

т.е. щем-не-щем си имамe най-малко още две фази:

  • "project setup"  -- създаване и настройване на проекта, външните библиотеки, зависимостите и т.н.
  • "preparing base" -- създаване на базовите класове, структура на DB и т.н.

Проблемът е, че project manager-а е чел дебелата книга за меринджейство и там пише, че трябва да се разработва  като на първата картинка и се опитва да го наложи. В крайна сметка програмистите нямат особен избор освен да се съгласят с него и привидно работят по неговата схема, но тъй като тези две фази са неизбежни, просто ги "скриват" в sprint/user story 1-2-3, съответно те отнемат повече време от очакваното и за project manager-a нещата изглеждат така:

p3

Това е проблем. Разгледано хронологично във времето нещата за project manager-а изглеждат сякаш user story 1 отнема много повече време от предвиденото и обикновено реакцията е да се паникьоса и да накара developer–ите да работят извънредно, за да наваксат. Криво-ляво успяват да завършат User story 1.

User story 2 е малко по-добре -- по-голямата част от основата е изградена и вече се работи почти само по user story-то, а не по "странични" неща. User story 2 бива приключено за по-дълго време от предвиденото, но закъснението далеч не е чак толкова голямо като преди.

User story 3 разполага с почти цялата необходима база и съответно се работи само по неговите неща. То отнема съвсем малко повече време, отколкото е било предвидено. Project manager-a се поуспокоява. Нещата изглеждат сякаш проектът е под контрол.

User story 4 вече разполага с абсолютно цялата необходима база. Разработката му отнема точно толкова време, колкото е било предвидено (в идеалния случай).

В крайна сметка проектът е завършен, но всички са се преработили и/или са си скъсали нервите. Всеки си прави изводите и има свое мнение, какво може да се направи по-добре.

Project manager-a прави следния извод: "Проблемът е, че estimate-а на developer-ите не беше добър и добре, че бях аз, да ги накарам да работят извънредно иначе щяхме да закъснеем още повече."

Идва Проект 2 (който да приемем, че е много подобен на първия) и project manager-a прави следния план (сравнен с първия):

p4

 

… защото по дебелите меринджейски книги пише, че трябва да се разработва на вертикални slice-ове…

Иронията е, че този проект ще завърши навреме, защото просто са раздути сроковете за всяко story. Project manager-a си прави извода "Прав бях" и вече до края на кариерата си ще планира така…

 


8 Responses to “Project management 101”

  1. Светльо says:

    Друг е въпроса защо се слага project manager на ИТ компания, който не е на "ти" с ИТ …
    Ако преди това е бил програмист ще знае как стават нещата, но толкова ли често се наемат такива куци project manager-и ?

  2. Огнян says:

    @Светльо

    Въпросът ти е риторичен, нали? :-)
    В интерес на истината е много по-евтино да се назначи за project manager някой, който не е бил програмист. Това програмистите сме алчни хора :-)

  3. Светльо says:

    Ами работил съм до сега в 2 фирми. В едната нямаше project manager, в другата има и е бил програмист преди това. Така че не е много риторичен :) .
    А всъщност ако подготовката на проекта се направи, като user story и е преди останалите пак ще е хоризонтална диаграмата и пак всичко ще е нормално.
    Иначе интересна гледна точка, не се бях замислял.

  4. Anton Staykov says:

    Абе, в днешните "дебели книги" не пише ли че такова нещо кат' "Project Manager" няма? В днешно време им викат "Product Owner" и "Scrum Master" и е са подобни функции, ама следва да са по-запознати с фазите на софтуерния проект …

  5. Огнян says:

    Дай да не повдигаме темата за PO и SM, че там вече нещата са пълен ташак… Особено този scrum -- хванали са се за него все едно е панацея и го ползват сляпо за всякакви проекти, независимо дали е подходящ или не….

  6. Anton Staykov says:

    Аааа да, напълно съм съгласен :) особено интересно става като се "прилага" от чули и недочули …

  7. Dian says:

    Клиента не плаща за Project Setup/Preparing base време :)
    На него трябва да му се отчитат резултатите ….
    Това сигурно също го пише в дебелите книги :)

  8. Огнян says:

    @Dian
    Как се представят нещата пред клиента май е съвсем отделна тема…

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Внимание: Моля, въведете само ПЪРВИТЕ ТРИ цифри от картинката
Important: Please enter just the first three digits from the image