Вхід і реєстрація
Про роботу · 13 вересня, 19:00 4762
Саша Уманець

Оцінка задач через сторі поінти

Скажу чесно, я доволі скептично ставлюся до оцінки задач через сторі поінти, тобто коли це абстрактна оцінка ( коли це розміри одягу, числа Фібоначчі ).

Я хочу щоб команда оцінювала задачі в годинах і практикував це у своїй команді. Це ближче до бізнесу, формує просту та зрозумілу усім метрику відповідальності.

Для мене абстрактна оцінка задач (крокодилами, розміром одягу) виглядає трохи по дитячому.

Але вчора на інтерв’ю зрозумів що є команди, які практикують сторі поінти (абстрактні оцінки). Не маю можливості уточнити у них, чому вони так роблять, тому запитаю вас.

Чи практикує хтось абстрактні оцінки? Чому не години?

Теми: story point, ефективність
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Nikola Utiuzhnikov 16.09.2024 09:57

Коли оцінюєш у годинах, виникає спокуса сприймати ці оцінки як абсолютно точні. Але в реальності, особливо в складних або нових проектах, передбачити точний час складно. Сторі поінти допомагають сфокусуватися на відносній складності, а не на кількості годин, які можуть сильно варіювати.

Ще години можуть створювати додатковий тиск, оскільки люди прагнуть досягти цих конкретних чисел. Сторі поінти дозволяють команді сфокусуватися на завершенні задач без надмірного тиску на точність оцінок.

Перейти до дискусії
Ihor Kozar 14.09.2024 20:04

Сторі поінти допомагають уникнути проблеми коли оцінював один розробник а робити буде інший. Оскільки вони оцінюють складність задачі, а не час виконання.

Якщо задачу оцінює сініор, а виконує джун, то оцінка в годинах буде неточною, бо джун витратить більше часу. Сторі поінти ж враховують цю проблему. Просто у джуна і сініора буде закрита різна кількість сторі поінтів за спринт.

Перейти до дискусії
Alexander Dyachenko 16.09.2024 12:52

оценка в часах это точная оценка какой-то маленькой и до конца понятной задачи
оценка в SP это приблизительная оценка сложности задачи в сравнении с другими задачами

Перейти до дискусії
Bot Bot 13.09.2024 20:10

А до чого тут оцінка роботи девелопера до загального часу попадання фічі у прод? Ну там девопси, тестувальники? Вони усі сидять і чекають коли Вася запушить і моментально це попаде у прод? Оцінка в година це безглузда маячня що все одно первторюється у абстрактні числа коєфіціенти. Бо те що у вас 5 прогерів по 80 година спрінт це не значить що ваша команда зробить комітмент у 400 годин. За 13+ років я ніколи не бачив щоб оцінка в годинах хоч якось корелювала із реалністью чи показувала велсоіті команди.

Взагалі ці години повна маячня, бо всі тільки і ломають голову куди їх потім списати щоб було 40 годин на тиждень.

Також там де жучать за години там токсична культура і замовник жлоб що не довіряє команді.

Також таск на дві години у пятницю увечорі ніхіба не робиться за дві години, чи у вас всі девелопери/ку/девопси/дизайнери як роботи стабільно перформлять 52 тижни на рік?

Працюю лідом/архітектом декілька років і мені взагалі нарсати скільки там годин, бо мені важливо делівері команда в цілому, а не якісь абстрактні дупогодини.

Щодо замовника, то якраз сторі поінти дають більш менш нормальне розуміння по велосіті. Чи ви оцінюєте задачі навіть на декілька спринтів вперед з точністю до години? Чи все ж таки з кєфіцієнтами?

Перейти до дискусії
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Aleksey Kolupaev CTO в eduki 23.09.2024 12:45

Оцінка в поінтах — вона про задачу, а години — про її виконання кимось. Відокремити складність задачі (відносну) і реальне виконання якимось конкретним девелопером. Наприклад, у джуна і у сеньора, хочеться вірити, одна і та ж задача займе різну кількість годин.

Відповісти
Підтримати
S M 19.09.2024 17:46

95% задач у девів — не є «ресерч», а доволі повсякденні, тобто можуть буть плюс мінус точно оцінені у годинах.
Важка задача типу Proof of Concept — декомпозиція з потенційними ризиками і беремо кожен пункт по песимістичному сценарію.
Сторі поінти — найдурніше що нетехнічні люди могли принести в ІТ. Якщо чую «ми працюємо по скраму з усіма церемоніями і сторі поінтами» — одразу закінчую інтервью.

Відповісти
Підтримати
Просто Анон 19.09.2024 18:15
Якщо чую «ми працюємо по скраму з усіма церемоніями і сторі поінтами» — одразу закінчую
інтервью

Чому? Якщо є сторі пойнти, то процеси ± поставлені, є якась прийнятна всіма «норма» для дева (типу 8 SP в спрінт на людину).
Зробив ті 8 SP за перший тиждень і другий тиждень займаєшся своїми справами (а статус на дейлі "рефакторю, дописую тести, ще щось).

Відповісти
Підтримати
S M
Beaver Green 19.09.2024 18:47
95% задач у девів — не є «ресерч», а доволі повсякденні, тобто можуть буть плюс мінус точно оцінені у годинах.

Запросив би тебе на мій попередній проєкт: багфікс у величезному легасі ентерпрайзі. Там перший тиждень ти тільки намагаєшся зарепродюсити баг. Потім коли «зловив» — скільки днів будеш дебажити ніякий Нострадамус не скаже. Як і те — де ще відвалиться після фікса.
Плюс-мінус точно оцінити я можу тільки у коді, який сам писав. А у чужому завжди можна очікувати сюрпризів.

Відповісти
Підтримати
S M
Taras Terletsky Python Backend Engineer в SoftServe 19.09.2024 19:15

Так само і в стартапах, котрі «змогли», оскільки багато коду написано (і потім розширено без рефакторингу) в стилі тяп-ляп з розрахунку на Time to Market, а інша частина заоверінженірена так, що за рік не факт, що зрозумієш. Також, якщо це все ще помножено на складний чи специфічний домен продукту, то результат ще неочевидніший.

Або в аутсорсних проектах, де замовник вимагав все на вчора, а команда писала як могла та через пів року половина від перегорання звільнилась, а ти доєднюєшся та задаєшся доволі цікавими питаннями.

Мав досвід в обох випадках і також доволі добре знаю, що таке 1-2 тижня лише на «ресерч» баги, та коли скрам переводять в канбан, бо жодного сенсу в ньому (в спринтах як такових) немає, бо і так завжди все переноситься в наступний спринт з попереднього, або приходять більш пріоритетні задачі і в спринті робиться рокіровочка. Взагалі ще не зустрічав проекта, де б працював скрам, завжди все йшло на дно :)

Оцінки в годинах в розробці працюють лише на простих задачах рівня добавити нове значення в Enum та написати чи розширити такий же тест. Сторіпойнти на моїй практиці також не несли жодного сенсу, мен-деї ±, проте крок вправо чи вліво і все сипалось. Єдине, що завжди працювало це PERT + додатковий % на багфікс.

Відповісти
Підтримати
Beaver Green
Mobile 04.10.2024 04:00

подожди, подожди как сразу дебажить ! ? а неделю на то что бы настроить инфраструктуру и версию проекта ?

Відповісти
Підтримати
Beaver Green
Pavlo Soia Android developer в Tallium 23.09.2024 10:06

з мого досвіду команди, які працювали по sp загалом давали вірні естімейти і вкладалися в дедлайни, а команди, які оцінювали в годинах, виходили з естімейтів іноді і в кілька разів. Про плюси sp можна почитати в книзі про скрам.

Відповісти
Підтримати
S M
Просто Анон 23.09.2024 11:10
які працювали по sp загалом давали вірні естімейти і вкладалися в дедлайни, а команди, які оцінювали в годинах, виходили з естімейтів іноді і в кілька разів.

Та бо це і є причина чого придумали ті SP.
Якщо інженеру скажуть оцінити таск в годинах, то він його оцінить, і досить точно, нехай 24 години. Менеджмент бере його естімейт, ділить на 6 (особливо обдаровані на 8) і має дату коли таск буде готовий (через 3-4 дні). Значить можна дати 2 таски на спрінт в 2 тижні (особливо обдаровані спробують запхати 3 таски і ще будуть розказувати що ще вільний день буде).
Але дев не врахував що з’явитися інша критична робота, захворіє інший дев, не буде світла, зміняться вимоги, якісь неочікувані технічні складності і т.п.

А коли йде оцінка в SP, то оцінюється «а наскільки цей таск складніший від того що робили місяць тому».
Дев каже 3SP, бо воно десь в 3 рази буде довше робити.
Тоді менеджер дивиться що той дев закриває в середньому 5 SP в спрінт, значить точно встигнеться 1 таск і швидше за все не встигнеться ще 1.

Тобто естіймейт в годинах це 2-3 таски за спрінт.
Естімейт в SP це 1 або 2 таски.

Бо SP юзають історичні дані де вже враховані всі специфічні для проекту фактори які впливають на роботу.

Відповісти
Підтримати
Pavlo Soia
Olena Sharovar Node.js/JS в Waverley 03.10.2024 02:45

Тому що в естімейт, даний в сторі-поінтах, неможливо НЕ вкластися.
Береш таску в два сторі поінта, робиш тиждень, і все одно вважається що ти __вклався__
Це ж не два дні, а два сторі поінта, а сторі поінти розтягуються дуже сильно.
Два сторі поінта за день? Вклався. Два сторі поінта за тиждень? Теж вклався.

Відповісти
Підтримати
Pavlo Soia
Mobile 04.10.2024 04:03

ну если таска заняла меньше времени — то ты просто берешь следующую таску. Количество тасков в спринте всегда немного больше чем нада

Відповісти
Підтримати
Olena Sharovar
Roman Parkhomets PrM/PM 18.09.2024 13:00

дякую за топік та коменти, стало зрозуміліше.
а як замовнику давати естімейт в годинах/днях, якщо команда оцінює все в сторі поінтах?

Відповісти
Підтримати
Bogdan Shyiak SE or Dev 18.09.2024 14:10
дякую за топік та коменти, стало зрозуміліше.
а як замовнику давати естімейт в годинах/днях, якщо команда оцінює все в сторі поінтах?

1) Go to chatgpt.com
2) Type ’Act as a professional IT project manager’
3) Type ’How to prepare estimate in man-hours if team gives estimate in story points?’
4) Follow the steps

Відповісти
Підтримати
Roman Parkhomets
Volodimir Nazarenko Senior .Net Developer / Teamlead в Perfectial 18.09.2024 18:54

Сторі-поїнти працюють, якщо обидві сторони знають їх «ціну». Тобто з замовником має сенс говорити також в сторі поїнтах. Ось беклог, ось велосіті, ось сторі з поїнтами. В наступному спринті з вірогідністю 80% буде зроблено ось ці сторі (якщо ніхто не захворіє, не впаде прод, інші форс-мажори). Якщо тобі пріорітеніше щось інше — давай думати що викинути.
Для парадигми «я плачу, коли буде зроблено» — сторі поїнти не дуже працюють. Їх придумали, щоб менше часу проводити на естімації та ретро («чому таска ххх зайнялм 4 години, а ми думали 3»), а більше код писати.
Домашнє завдання на подумати: у девелопера Васі є три таски, 3, 3, 2 години. Сьогодні понеділок, 9 ранку. Коли три таски будуть готові?

Відповісти
Підтримати
Roman Parkhomets
Olena Sharovar Node.js/JS в Waverley 19.09.2024 00:01

У мене був прикол. ПМ захворіла і її не було на стендапі. Замовник мене питає «Коли ви це зарелізите?». Я дивлюся — залишилося 10 тасок по 2 поінта, а ми робимо якраз 20 поінтів в спринт. Думаю — мабуть, треба казати «через 2 тижні». А він як давай мене перевіряти — каже «А якшо хтось захворіє? А якщо ще баги знайдуться? А якшо те? А якщо се?» я так зрозуміла що треба казати 4-6 тижнів щоб точно не помилитися :D

Відповісти
Підтримати
Roman Parkhomets
Просто Анон 23.09.2024 11:13
а як замовнику давати естімейт в годинах/днях, якщо команда оцінює все в сторі поінтах?

І це питання ставить людина з тайтлом PrM/PM?

Те саме що техлід пішов б питати менеджера як селект написати

Відповісти
Підтримати
Roman Parkhomets
Саша Уманець 23.09.2024 11:22

Антон, давайте конструктивніше. Наприклад, розкажіть як ви це робите? Можливо вже випрацювали певну схему. Чи називаєте замовнику дату ще до того як зрозуміли як рухається команда?

Відповісти
Підтримати
Просто Анон
Просто Анон 23.09.2024 11:52

Як ті СП працюють я поверхнево описав тут dou.ua/...​rums/topic/50350/#2879530

Наприклад, розкажіть як ви це робите?

Це залежить від проекту, тобто є специфіка самої команди, клієнта, контракту.

Чи називаєте замовнику дату ще до того як зрозуміли як рухається команда?

Якщо це нова команда чи новий проект то звичайно що ні.
Можна сказати що от такі попередні оцінки скоупу в SP, а велосіті команди буде визначено протягом місяця-двох. Знову, тут все залежить від конкретного проекту, ніхто не буде чекати 2 місяці на оцінку якщо сам проект розрахований на пів року.

Якщо це «підпроект» чи велика фіча на існуючому проекті, або команда спрацьована і є довіра, то можна і казати дату, попередивши що це попередня оцінка.

І зазвичай замовник сам називає дату, а завдання менеджера чи ліда працювати з клієнтом щоб визначити яка функціональність є must, а що можна зробити пізніше (чи точніше чим можна пожертувавати якщо щось піде не так).
В результаті буде визначено як мінімум кілька версій (чи milestone) продукту (не обов’язково всі доступні користувачам).
А SP це буде валюта чи вартість функціональності.

Якось так, про те як планувати і деліверити є куча книжок, тому в один комент не влізе) і менеджери ті книжки мають читати.

Відповісти
Підтримати
Саша Уманець
Саша Уманець 23.09.2024 11:56

о це вже по ділу, хороший коментар, дякую

Відповісти
Підтримати
Просто Анон
Віталій Мартиник Senior Software Engineer в United Software 18.09.2024 08:37

Ніхто не практикує, це давно вийшло з моди

Відповісти
Підтримати
Nikola Utiuzhnikov Кодировщик 18.09.2024 09:34

Якби ніхто не практикував, не було б в цій темі 90 коментарів...

Відповісти
Підтримати
Віталій Мартиник
Beaver Green 18.09.2024 21:57
Ніхто не практикує, це давно вийшло з моди

Це ви про оцінку у годинах? Цілком може бути: мало хто з досвідчених менеджерів пообіцяє клієнту що щось буде зроблено через Х годин. Тим більше якщо зараз більшість працюють по Agile і це дозволяє більш гнучкий підхід до витрачених годин.

Відповісти
Підтримати
Віталій Мартиник
Віталій Мартиник Senior Software Engineer в United Software 18.09.2024 21:57

Бачу без смайла сарказм ніхто не оцінив🙃

Відповісти
Підтримати
Beaver Green
Артур Мудрик Software engineer 17.09.2024 22:34

Як я зрозумів половина випадків це щоб замовник не виставляв претензій до оцінки-швидкості виконання, години називають поінтами. А інша половина — щоб пояснити вищому керівництву чому у девелоперів є параметрів швидкість виконаних годин за годину (год/год) і він в усіх різний.

Відповісти
Підтримати
roman maschak Lead Systems Engineer в EPAM Systems, Inc. 17.09.2024 14:29

Часову оцінку задач зустрічав в 1st tier support.
Існував агрегатор моніторинга який створював тікети. Тікети, що повторювались мали класифікацію — 2 години, 48 годин, 3 місяці. Останній кейс — це якась фундаментальна проблема, що ескадюється в команду розробників.

Відповісти
Підтримати
Gremlin 17.09.2024 12:06

Колись давно, ще до скрама, я робив точні естімейти: вивчав задачу, планував, дизайнив. Перед виконанням вимагали design document для замовника, бо це була медична CMS.
Все вдавалось в зазначений срок.
Ну що? — не сподобався менеджменту такий підхід, і стали робити традиційно: бігом-бігом, все комом, через одне місце, через яке все потім і пішло в Індію, де дешевше.
Та система й зараз жива, але я не бачу, щоб вона росла, займала нові ринки. Таке собі, живе в режимі сапорта, як і багато інших систем, які вже не перепишеш.

Відповісти
Підтримати
Vic Programmer 17.09.2024 12:12

У попереднього способу — теж свої вади. Дуже часто гори паперу і жодного реального вихлопу, ніякого ПЗ. Я не кажу що не потрібна документація, прорахунки і т.д. інженерні практики — ще в як потрібні. Та що занадто, то не добре.

Відповісти
Підтримати
Gremlin
Gremlin 17.09.2024 12:51

Це правда, легко не було. Документація як болото, ще один код, який треба апдейтати, ревьюїти.

Відповісти
Підтримати
Vic
Oleg Korol POWER Ops, again 17.09.2024 11:46
Скажу чесно, я доволі скептично ставлюся до оцінки задач через сторі поінти, тобто коли це абстрактна оцінка
PM Stack:
— Scrum

довго сміявся

Відповісти
Підтримати
Саша Уманець 17.09.2024 10:01

друзі, я всім дякую, в темі розібрався, ви накидали дуже багато класних поінтів, тепер мені все зрозуміло

Відповісти
Підтримати
Oleksandr Suvorov https://spgr.org.ua/uk/ в Qualcomm Inc. 17.09.2024 08:58

Бо еджайл — про приблизні оцінки. Оцінка задачі в годинах прибирає цю приблизність. І додає нервозності виконавцям. І позбавляє еджал головної переваги — гнучкості в плануванні.
Якщо ви не нервуєте — це не знчить, що інші такі ж.

Відповісти
Підтримати
Olena Sharovar Node.js/JS в Waverley 17.09.2024 02:16

Працюю в проектах з сторіпоінтами вже десяток років, і все одно неясно: якщо для мене задача легка (1 поінт), а для джуна та ж сама задача важка (5 поінтів) то що треба ставити?

Відповісти
Підтримати
Олег Дорожко 17.09.2024 02:34

Залежить від того, хто працюватиме над завданням. Якщо ви — то 1 поінт. Якщо джун — 5 поінтів. Як на мене — сторіпоінти це геніально.

Відповісти
Підтримати
Olena Sharovar
Olena Sharovar Node.js/JS в Waverley 17.09.2024 02:49

Ніколи такого не було, завжди на плануванні скрам-мастер просив дати одну оцінку від команди, незважаючи на те що в команді люди від рівня «лід» до рівня «джун». Останнім часом просто ставиться максимальна з запропонованих, якщо спір між 2 і 3 поінта — ставиться 3, якщо між 3 і 5 — ставиться 5.

Відповісти
Підтримати
Олег Дорожко
Саша Уманець 17.09.2024 10:00

Олег, це ж не правильно, задача повинна мати одну оцінку в сторі поінтах не залежно від того хто її буде робити

Відповісти
Підтримати
Олег Дорожко
Vic Programmer 17.09.2024 02:51

Для цього ви обираєте еталон — тобто така користувацька історія яка є мінімальною, тобто узгоджуєте усією командою. І від цього вже йдете. Справа в тому — що естімейт це не тільки про розробку, це ще про и тестування розгортання і т.д. Є навіть більш продвинуті техніки — з таблицями еталонних історій і т.д.
Далі для того щоби узгодити по сторям якраз проводиться планіг покер — де йде обговорення естімейту, скажімо ви сказали 1 а джуніор 5, скрам майстер питає по черзі у вас і у джуніора чому. Таки ви вже розказуєте що усе розумієте і по пунктам кажете, що тут наприклад треба додати кому десь в span і закомітити.

Відповісти
Підтримати
Olena Sharovar
Mobile 04.10.2024 04:06

спочатку иде обговорення таску, потим иде планинг покер, потим обговорюють чому хтось сказав 1 а хтось 5 и записують в план остаточну оцинку

Відповісти
Підтримати
Vic
Oleksandr Suvorov https://spgr.org.ua/uk/ в Qualcomm Inc. 17.09.2024 08:53

Так це вирішується на грумінгу. Береться компроміс. Може, джун не знає, що ця задача легка. І на грумінгу йому сіньори пояснять, в чому там суть і вже буде не 5, а 2 пойнти.

Відповісти
Підтримати
Olena Sharovar
Olena Sharovar Node.js/JS в Waverley 17.09.2024 18:14

А якщо та задача реально важка для джунів, і проста для сеньорів? Або важка для новачка на проекті, але легка для старичка? Я ж не можу нову людину переконувати, що «тут роботи на 15 хвилин, я голосую за 1 поінт» бо я бачу цей код 100500й раз в своєму житті, а він — перший.

Відповісти
Підтримати
Oleksandr Suvorov
Mobile 04.10.2024 04:08

тому що задача синьойра — це анблок усих других членив команди. Або через онбордниг на таску, аби через виконання найбильш сладних тасок самому або через пушинг сусидних команд, етс

Відповісти
Підтримати
Olena Sharovar
Bogdan Shyiak SE or Dev 17.09.2024 13:10
якщо для мене задача легка (1 поінт), а для джуна та ж сама задача важка (5 поінтів) то що треба ставити?

Ставити треба двійку і відправляти на навчання :)
Складність задачі не має залежати від досвідченості виконавця. Тобто в вашому випадку ви маєте пояснити джуну як робити ту задачу, а він має пояснити чому він вважає її складною, потім ви оцінюєте повторно цю задачу. Якщо після переоцінки розбіжність в сусідніх значеннях (3 і 5 наприклад), то беремо більшу. Якщо оцінки не змінюються, то треба працювати над комунікацією в команді.

Між іншим оцінка в годинах буде себе поводити для вас так само: ви робите за 1 годину, джун за 5. Що ставити в естімейт? Але тут маємо недолік, що в такій системі ви не завжди можете пояснити джуну, як зробити задачу в 5 разів швидше

Відповісти
Підтримати
Olena Sharovar
Olena Sharovar Node.js/JS в Waverley 17.09.2024 18:18

Приклад. Пише мені вчора наш сейлз — баг на продакшені, пошукай в чому причина. Я створюю тікет, але за 15 хвилин знахожу в чому причина, ставлю 0.25 поінта — закриваю.

Людина, яка нова на проекті або пагано знайома з кодом — шукала би причину тиждень (причина була дуже неочікувана). Тобто, в задачах, де не просто «роби це, потім те, буде результат» а в задачах, в яких є якийсь дослідницький елемент (шось шукати, ресерчити, думати, пробувати варіанти) — там дуже сильно впливає попередній досвід людини.

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 17.09.2024 19:20
Приклад. Пише мені вчора наш сейлз — баг на продакшені, пошукай в чому причина. Я створюю тікет, але за 15 хвилин знахожу в чому причина, ставлю 0.25 поінта — закриваю.
там дуже сильно впливає попередній досвід людини.

Чудовий приклад (без сарказму).
Сторіпоінти (СП) — це засіб оцінки складності задачі при плануванні ітерації. Оцінка тут мала б сенс, якби цей баг, а точніше його розслідування, ви як команда мали б брати в наступний спрінт. І власне під час планування ви б поставили 1 СП, новачок 20 СП; як результат ви б поділились досвідом з новачком; як результат задача була б переглянута на 1-3 СП, які б реально відображали складність інвестігейту, а не затраченй на нього час.

Ваш приклад, ще чудовий бо показує, що у кожного інструменту (в нашому випадку СП) є своя область застосування. І саппорт задачі (саме критичні запити з проду) є не найкращим полем для їх застосування. Як в принципі і скрам, тому часто використовують канбан і оцінку в годинах (якщо за Х годин не розібрались, то маємо проблему, потенційно порушили СЛО) для такого.

Далі ще цікавіше: ви порушили чи не найважливіший принцип скраму — незмінність спринта, що воже негативно вплинути на процес планування. І ще негативно на точність оцінок впливає те, що ви внесли цю зміну без обговорення, як результат схожі задачі __можуть__ тепер сприйматись з вашою оцінкою, а як ви сказали, для когось іншого ця оцінка буде іншою.

Відповісти
Підтримати
Olena Sharovar
Olena Sharovar Node.js/JS в Waverley 17.09.2024 22:14

Я би не змогла під час планування за 5 хвилин (і навіть за 50 не передам) весь свій досвід, тому я би просто погодилася що якщо шукати причину багу буде нова для проекта людина — то для такої людини можна виділити на пошук 10-20 поінтів.

Тобто, вимога «дати один естимейт на всих» вона якось ігнорує, що в команді люди дуже різні, хтось круто розбирається в БД і напише якийсь складний SQL за три хвилини, а хтось буде два дні його робити, ітп

Відповісти
Підтримати
Bogdan Shyiak
Beaver Green 18.09.2024 22:08
Тобто, вимога «дати один естимейт на всих» вона якось ігнорує, що в команді люди дуже різні, хтось круто розбирається в БД і напише якийсь складний SQL за три хвилини, а хтось буде два дні його робити, ітп

Стандартний спринт — 2 тижні. Що якщо синьйор, який мав зробити «за 5 хвилин» раптом захворів на тиждень і не встиг передали знання? А є тільки джун, який буде робити тиждень?
Я розумію це так: естімейт в сторі-поінтах один на всіх (бо не обов’язково буде робити саме та людина, яка його давала) і він узгоджується усіма. Просто для джуна 1 сторі поінт — це 8 годин, я для синьйора — 1 година. Відповідно у них різне велосіті і скоп роботи (у сторі-поінтах) на спринт.

Відповісти
Підтримати
Olena Sharovar
Olena Sharovar Node.js/JS в Waverley 19.09.2024 00:04

Якщо для джуна 1 поінт — це 1 день, а для сеньора 1 поінт — це пару годин, то сеньор робить 4 поінта в день = 40 поінтів в тиждень, а джун робить 5 поінтів в тиждень.

Ви наплануєте роботи на 45 поінтів на спринт (40 сеньору і 5 джуну) а сеньор захворів — упс. Навіть якщо сеньор робить 2 поінта в день, а джун робить 1 поінт в день — якщо ви наплануєте на спринт 15 поінтів а сеньор захворів — у вас проблема.

Відповісти
Підтримати
Beaver Green
Саша Уманець 19.09.2024 02:05

Не дуже розумію, що ви хочете сказати, якщо ми запланували людину, а вона випала, зрозуміло що у нас проблеми і ми зробимо менше і тут вже не важливо як були оцінені задачі в годинах чи поінтах.

Відповісти
Підтримати
Olena Sharovar
Olena Sharovar Node.js/JS в Waverley 17.09.2024 23:43

Спитала чатжпт — якщо для джуна таска буде 20-поінтовою (якщо він буде робити сам), а для сеньора 1-о-поінтовою (якщо він буде робити) то він рекомендує робити pair programming і естимейтити скільки займе цей «pair programming»

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 17.09.2024 23:56
Спитала чатжпт

Ви ж в курсі, як він працює? Він оперує не логічними послідовностями, а послідовностями байтів.

якщо для джуна таска буде 20-поінтовою (якщо він буде робити сам), а для сеньора 1-о-поінтовою (якщо він буде робити) то він рекомендує робити pair programming і естимейтити скільки займе цей «pair programming»

Блін, уявив ефективного менеджера, який впроваджує ШІ в свою роботу :)
Це безкоштовна версія? Чи якась з нових моделей?

Відповісти
Підтримати
Olena Sharovar
Olena Sharovar Node.js/JS в Waverley 18.09.2024 00:23

платна, GPT-4o.

Він оперує не логічними послідовностями

Ну про pair programming начебто гОдна ідея. Правда робити всі таски в режимі pair programming я би не змогла.

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 18.09.2024 12:05
Ну про pair programming начебто гОдна ідея.

Парне програмування != досвідчени робить (витрачає свій час), а новачок дивиться (теж витрачає таку саму кількість свого часу).
Навіть в контексті навчання просто дивитись не так гарно працює, як самому допустити помилку та просити допомогу __коли вона потрібна__

Відповісти
Підтримати
Olena Sharovar
Дмитрий Корбаницкий Python Developer 19.09.2024 10:46

1. таска має бути нормально описана тех лідом, включаючи можливі підводні камені та неявні залежності. Тобто, прочитавши Tech Details, що синьйор, що джун однаково розуміють суть того, що і де треба зробити.
2. В нас було правило, що задачі більше 8 сторіпоінтів в спринт не брати, а віддавати їх на дослідження тех ліду. 8 сторіпонтів — це прям потолок, що означає «взагалі неясно як робити, щось треба придумати». Зазвичай таски, яким ставили 12-15 сторіпоінтів досліджувались тех лідом і розбивались на менші атомарні і простіші задачі з чітким планом і описом. І тоді вже проводилось планування і обговорення між командою.
Коли я перейшов з типової галєри, де «негайно зробити оцю задачу, всі інші — на паузу» до нормальнох системи планування спринтів, то теж було незвично і здавалось, що воно не спрацює, але за пів року звик і потім вже було досить зручно. У цього підходу є плюси і мінуси, але він працює )

Відповісти
Підтримати
Olena Sharovar
Olena Sharovar Node.js/JS в Waverley 19.09.2024 14:24

А тепер підвох: в скрамі-то нема техлідів! Є продукт овнер, скрам мастер і команда. Де там техлід? Є складна задача — хто робить дослідження? Хтось з команди. А в команді можуть бути люди з 20-річним досвідом і з 2-х-річним.

Я вже питала чатжпт “чим відрізняється скрам від комунізму” бо починаю пагано розуміти різницю — і там і там “власть народа” , і там і там партсобранія 😂

От:

Here’s a list of what Scrum and communism have in common:

Equality: Both promote the idea that everyone is equal, whether it’s in a team or in society.

Collective Ownership: Scrum encourages collective ownership of tasks, much like communism emphasizes collective ownership of resources and means of production.

Shared Responsibility: Both systems advocate for shared responsibility, with no individual being more accountable than others.

Lack of Hierarchy: Scrum minimizes hierarchy within teams, similar to communism’s goal of abolishing class distinctions.

Collective Decision-Making: Scrum promotes decisions made by the whole team (as in retrospectives or sprint planning), just as communism encourages collective decision-making in governance.

Idealistic Vision: Both Scrum and communism are based on an idealistic vision of how things should work when everyone participates equally and for the common good.

Focus on Community/Team: Both put the group (whether the community in communism or the Scrum team) above individual interests.

Resistance to Leadership Dominance: Scrum downplays the role of traditional leadership (like a manager), while communism resists dominant leadership and seeks to distribute power.

Utopian Appeal: Both Scrum and communism often promise an ideal or utopian environment, though in practice, achieving this can be very difficult.

Accountability by the Group: Scrum teams hold each other accountable just as communism relies on collective accountability rather than individual oversight.

Відповісти
Підтримати
Дмитрий Корбаницкий
Valerdos 19.09.2024 14:51

Нет тут подвоха. Техлид или джун это не роль в методологии разработки ПО. Замените на «опытный участник команды разработки», если так проще представить. Он и возьмет задачу в анализ. В спринте или, ох, даже вне спринта, если так удобнее.

Відповісти
Підтримати
Olena Sharovar
Olena Sharovar Node.js/JS в Waverley 19.09.2024 15:53
даже вне спринта

Як це вне спринта? Він у вас овертаймить чи по вихідних працює?

Замените на «опытный участник команды разработки»

Цей тред почався з того, що дуже складно дати одну спільну оцінку в поінтах, коли в команді є досвічені і недосвічені люди. От у нас зараз в беклозі задача налаштувати VPN/VPC на проекті. Як можуть дати одну спільну оцінку наприклад девопс (який 20 раз це робив на інших проектах) і фронтенд-джаваскрипт-інженер який взагалі не здогадується що це і де його включати. І таких задач багато буває, вона ж не одна така.

Відповісти
Підтримати
Valerdos
Valerdos 19.09.2024 16:17

Да просто — не включаете задачу/можно даже человека в спринт, если она туда не ложится. Делает ее как удобнее — с канбан-доской, «к понедельнику», под честное пионерское и т.п.
И не надо стремиться давать общую оценку командой специфическим задачам, которые могут оценить существующие эксперты. Не надо BE-спецам оценивать FE-задачи, которые они не будут делать и в которых не смыслят и наоборот. Важнее включение задач в спринт под ресурсы в наличии — больше вероятность закрыть спринт.

Відповісти
Підтримати
Olena Sharovar
Дмитрий Корбаницкий Python Developer 19.09.2024 17:47

я як раз і виконував роль тех ліда, тому можу відповісти ) «Поза спринтом» — мається на увазі, що моє капасіті враховується частково в загальному капасіті команди (ми брали половину від звичного капасіті senior developer).
Доречі, у прикладі з багом, який ви описали, то баг можна не естімейтити, оскільки його треба робити тут і зараз.

Відповісти
Підтримати
Olena Sharovar
Дмитрий Корбаницкий Python Developer 19.09.2024 17:54
От у нас зараз в беклозі задача налаштувати VPN/VPC на проекті. Як можуть дати одну спільну оцінку наприклад девопс (який 20 раз це робив на інших проектах) і фронтенд-джаваскрипт-інженер який взагалі не здогадується що це і де його включати.

Тому спочатку проводиться командне рев’ю задач, і якщо один учасник дає 1 сторіпоінт, а інший — 20, то маємо чіткий сигнал, що точно один з двох задачу не зрозумів. Тоді кожен пояснює свою позицію і думають над компромісом. Компроміс може заключатися в тому, що задача описана погано і треба переписати технічні деталі задачі. Ну і девопс з фронтенд не повинні мати один пул задач. Тут на перший план виходить якість технічного опису задачі. На багатьох проектах на це забивається болт, тому кожен тримає шматок своїх знань в голові і тільки цей розробник придумує як робити цю задачу. Плюс залежить від самих задач. Якщо одну велику задачу «зробити АПІ для юзера» розбити на маленькі підзадачі, то вони доволі прості і зрозумілі навіть для новачків.

Відповісти
Підтримати
Olena Sharovar
Просто Анон 19.09.2024 18:17
таска має бути нормально описана тех лідом, включаючи можливі підводні камені та неявні залежності. Тобто, прочитавши Tech Details, що синьйор, що джун однаково розуміють суть того, що і де треба зробити.

Це не можливо.
Щоб ці всі неявні залежності і підводні камені знати, треба ту роботу зробити.
Смисл з того дева, якщо йому треба все розжувати (а значить зробити більшу половину роботи)

Відповісти
Підтримати
Дмитрий Корбаницкий
Beaver Green 19.09.2024 18:50
Смисл з того дева, якщо йому треба все розжувати (а значить зробити більшу половину роботи)

Тому і існують «спайки»: синьйор робить половину роботи аби розібратися де що і як треба зробити — а потім віддає джуну коли залишається тільки код написати.
Можливо з часом джуна — кодера замінить ШІ: синьйор просто словами надиктує де що треба змінити — ШІ нагенерує код, синьйор перевірить.

Відповісти
Підтримати
Просто Анон
Mobile 04.10.2024 04:12

то якщо неясно як робити то траба добавити таску на 5 поинтив — ресеч шо и як робити, а потим вже нормальну таску чи декилька

Відповісти
Підтримати
Дмитрий Корбаницкий
Vitalii D Frontend Engineer в Tide.co 19.09.2024 15:02
Я створюю тікет, але за 15 хвилин знахожу в чому причина, ставлю 0.25 поінта — закриваю.

схоже потрібен Agile тренінг...
баги не потрібно єстімейтити
не треба єстімейтити задачу яку ви вже зробили
беремо в роботу тільки заєстімейчині задачі
і чисто моє імхо — оцінки 0.25 поінта теж не повинно існувати, числел фібоначчі достатньо

Відповісти
Підтримати
Olena Sharovar
Anastasiia Skorobohata JavaScript developer 16.09.2024 23:52

Чому сторіпоінти не розуміють навіть після 10 тренінгів то це проблема тренінгів. З досвіду виявила такі моменти, сподіваюсь допоможуть:
1. В правильно налаштованих процесах сторіпоінти мають нижчий поріг і найвищий для оцінювання задачі — все що вилазить за цей поріг це епік.
2. Це можуть бути хоч фібоначчі хоч від 1 до 10 кому як зручно.
3. Коли оцінюєте якусь задачу ви як би вимірюєте кількість болю яку вам доведеться витерпіти виконуючи її. Припустимо:
— на проекті нижча величина прийнята 1, найвижча 10 стп де 1 це неболяче, 10 — це задача головний біль або руку відрізають, прийміть аналогію болю для себе
— задача: зробити інпут поле в UI і додати стилі, без action listener — 1-2 сторіпонта
— або: додати і інпут і обробник — 2-3стп
— якщо казати про сервер: вам потрібен контроллер ендпоінта який дістає з ассет менеджера картинку по урлу і повернути ії клієнту, з валідацією і обробкою помилки, але в проекті вже існує схожий контроллер який повертає не картинку а наприклад текст зі сховища локалізацій по ключу — 5стп
— якщо ж взяти попередню задачу і додати до неї факт що схожого контроллера немає, і система налаштована тільки на зʼєднання з сєрвером, то вам потрібно ще подумати куди структурно цей ендпоінт правильно покласти, використати всі імпорти і правильні анотації, зайти в документацію і згадати як синтаксично пишеться контроллєр якщо ви не кожен день тільки цим займаєтесь то додаєте ще +2-3 сміливо > 7ст.п це достатньо боляче
— якщо ж вам потрібно і конекшн в базу і орм налаштувати, і підключити апі валідації, то тут 10 і більше стп, бо це по болю як руку відрізати (не всім) але задача з якою музику в навушниках не послухаєш, доведеться відкривати час від часу доку і читати, а також вірогідно розділити на декілька задач ( бо більше 10стп не вкладається)
4. чому на практиці це підходить для нових команд які тільки формуються, і те що турбує багатьох — як вкладатись в спрінт? Відповідь — ніяк. В гарно налаштованих проектах на перші 2-4 спрінти якщо всі люди набрані задачі які б хотілося зробити оцінюються і сторі поінти сумуються і все що не встигли зробити переноситься на наступний спрінт, так менеджери знають що в спрінт команда зробила наприклад з 200 стп всього 120, далі таски на наступний спрінт обираються, тут знову немає лімітів по сумі стп на спрінт оцінюються і на наступний спрінт команнда робить тасок на 140 сторі поінтів, коли утворюється плато — тобто сумарна величина стп за спрінт протягом декількох спрінтів приблизно однакова тоді робляться ліміти тасок на спрінт і починаються питання конкретних дат релізів.

Чому не оцінювати в годинах — нижче відповіли — у менеджера виникає спокуса прийти хвилина в хвилину і попросити з тебе готову таску, але факт того що таска може бути не прийнята на тестуванні часто не враховується і готовність цієї таски не залежить тільки від твого часу. Ти не знаєш чи сяде тестувальник одразу ж за перевірку твоєї таски у першу хвилину того як ти її віддав, а так не можеш навіть при комунфкації з куа її точно оцінити, а люди (менеджер) чекають

Відповісти
Підтримати
diany unworthy 18.09.2024 11:41

проблема в тому що реальним клієнтам важливо коли буде результат а не сферичні сторі поінти в вакуумі які ніякого зв’язку з реальністю не мають. любителям сторі поінтів потрібноі зарплату плати в сторі поінтах:)

Відповісти
Підтримати
Anastasiia Skorobohata
Саша Уманець 18.09.2024 11:45

я думаю що реальним клієнтам і називають реальні дати, але саме команда розробки оцінює все в сторі поінтах і рухається через сторі поінти, і вже в залежності від цього руху менеджмент і називає справжню оцінку для замовника, хіба не так ?

Відповісти
Підтримати
diany unworthy
Beaver Green 18.09.2024 22:19

Коли замовник приходить, наприклад, пошити костюм — його виміряють, усе вираховують, показують йому як це буде виглядати — і далі він тільки чекає готового.
В ІТ це майже ніколи так не працює: замовник сам повністю не розуміє як саме має працювати те, що він замовив! Саме тому замість «водоспаду» перейшли на «гнучкі» методи. І «сферичні сторі поінти в вакуумі» якими дають естімейт цілком відповідають «забаранке з одного речення», яким замовник описав задачу. Ця «абстрактність» у процесі роботи поступово перетворюється на щось реальне: після купи питань, демо, змін і переробок.
Назвати замовнику естімейт у годинах — це назвати ціну. А потім усі зміни, переробки, додаткові забаганки доведеться робити для замовника безкоштовно поки він не заплатить.

любителям сторі поінтів потрібноі зарплату плати в сторі поінтах

Я вважаю що краще оплата і справді була б за досягнуті результати. Оплата за гепа-часи просто вбиває будь-яку ефективність в ІТ.

Відповісти
Підтримати
diany unworthy
Андрей Кузнецов Release Train Engineer в Thermo Fisher Scientific 16.09.2024 16:00

чогось спам’ятав анекдот про собаку: «...Собаку? Та хвилини б за три.»

Відповісти
Підтримати
Vitalii D Frontend Engineer в Tide.co 16.09.2024 15:00

Що таке метрика відповідальності і як вона залежить від способів оцінки задач?

Cторіпоінти як і розміри футболок це відносна міра а не абстрактна, відносно інших подібних задач. А не відносно «міфічної людино-години», «абстрактного коня в вакуумі» чи чогось ще...

Що саме ви оцінюєте задежить від того що це за команди і що вони роблять. У саппорта і R&D різні задачі і KPI.

Як розробник я би все таки оцінював в відносних величинах щоб убезпечитись від факапів з проваленими дедлайнами.

Не можливо вгадати хто і скільки буде виконувати «8 годинну задачу» і в яких умовах(залежності і тд)...
Це може бути як лід (4 години) так і джун або мідл-новачок в команді який витратить 4 дні.
Хто буде винен в провалах термінів виконання? джун, менеджер, вся команда?

Відповісти
Підтримати
Olena Sharovar Node.js/JS в Waverley 17.09.2024 02:22
Хто буде винен в провалах термінів виконання? джун, менеджер, вся команда?

Тому вводим сторіпоінти, щоб уникнути відповідальності? От вам би стоматолог чи бригада по ремонту квартир видала естимейт в сторіпоінтах. І робила б потім...

Відповісти
Підтримати
Vitalii D
Vitalii D Frontend Engineer в Tide.co 17.09.2024 08:20

а ви робили ремонт? я ще не чув що б бригада кладалася в свої ж естімейти по часу і по бюджету) якщо це щось складніше ні ж якась одноманітна частина роботи.

щось примітивне легко точно оцінити, будинки будують по шаблонам.
спроектувати і побудувати не типовий проект в складній місцевості або з нетиповими вимогами (з бункером) — як оцінити коли ніколи такого не було ще?

Відповісти
Підтримати
Olena Sharovar
Volodymyr Torkalo 19.09.2024 01:22
я ще не чув що б бригада кладалася в свої ж естімейти по часу і по бюджету)

Ну таки рідко ремонти промахуються в рази чи на порядки (як в ІТ)

Відповісти
Підтримати
Vitalii D
Vitalii D Frontend Engineer в Tide.co 07.10.2024 15:22

інфрастуктурні об’єкти які замовляє держава — там на порядки і по вартості і по срокам :)

Відповісти
Підтримати
Volodymyr Torkalo
Alexander Dyachenko Senior C++ Developer в RingCentral 16.09.2024 12:52

оценка в часах это точная оценка какой-то маленькой и до конца понятной задачи
оценка в SP это приблизительная оценка сложности задачи в сравнении с другими задачами

Відповісти
Підтримати
Ангуляров Реактин 16.09.2024 11:18

обычно жопочасы любят на фрилансе, где заказчик считает каждый доллар, потраченный на час и бюджета проекта хватает на несколько человек. При этом дев принудительно ставит себя под прессинг, т.к. некоторые баги долго колупаются, и всегда выходит за рамки выставленного времени, даже примитивная работа верстальщика и то требует разброса по времени. В часах вы можете оценивать работу бариста по приготовлению чашек или количество ударов кувалдой

Відповісти
Підтримати
Nikola Utiuzhnikov Кодировщик 16.09.2024 09:57

Коли оцінюєш у годинах, виникає спокуса сприймати ці оцінки як абсолютно точні. Але в реальності, особливо в складних або нових проектах, передбачити точний час складно. Сторі поінти допомагають сфокусуватися на відносній складності, а не на кількості годин, які можуть сильно варіювати.

Ще години можуть створювати додатковий тиск, оскільки люди прагнуть досягти цих конкретних чисел. Сторі поінти дозволяють команді сфокусуватися на завершенні задач без надмірного тиску на точність оцінок.

Відповісти
Підтримати
Otak 15.09.2024 21:04

Одна з причин — години це комiтмент та стрес
Тодi виходить що набирати задач на спринт треба на 40 рiвно за мiнусом мiтингiв?
СП трошки зайобнiше але вони знiмають стрес

Відповісти
Підтримати
Beaver Green 15.09.2024 21:28
Тодi виходить що набирати задач на спринт треба на 40 рiвно за мiнусом мiтингiв?

Без урахування мітингів — бо клієнт платить за таски, а не за мітинги.

Одна з причин — години це комiтмент та стрес

На таких проєктах тобі кидають на день тасок на 8 годин, які естімейтив менеджер (на скільки зміг вмовити клієнта). А девелопер по-факту буде їх закривати 12 годин з перервою на мітинги. Джуни на таких проєктах взагалі працюють по 80 годин на тиждень аби було що зарепортити на 40 годин. А якщо ще й трекери і репортинг кожних 30 хвилин — то це справжня варварська галера.

Відповісти
Підтримати
Otak
Ангуляров Реактин 15.09.2024 22:28

на фрилансе, где до сих пор обитают мелкие шлюпки, трекер делает скриншоты примерно раз в 10 минут ±5минут чтоб дев четко не знал когда будет делаться скрин и % времени в активных процессах. Вышел на унитаз −10минут времени

Відповісти
Підтримати
Beaver Green
Melnyczenko Mel 16.09.2024 12:13

Зате є купа способів працювати з таким лайном) Декілька років пожив «під трекером» — потім ще з рік була звичка: сижу за столом, втикаю в телефон, а рука час від часу переставляє мишку по столу :D

Ще памʼятаю була утиліта, яка генерує рандомні рухи мишкою та посилає команди клавіатури. Потрібно було лише час від часу переключати екрани, щоб скріншоти не виглядали дивно

Відповісти
Підтримати
Ангуляров Реактин
Karina Kosenko PHP developer в IT Craft 16.09.2024 10:44

У нас кантрі менеджерка дає якусь задачу і хоче, щоб вона була виконана якнайшвидше (бажано сьогодні, а то реальні юзери не проживуть пару днів без нової нотифікації), а новий продакт менеджер ходить до тебе кожні дві години і питає, коли буде готово)) Тут хоч в яких одиницях оцінюй — стрес гарантований. Так, я знаю, що планування у нас фігове і взагалі у замовника багато red flags, але продовжую з ними працювати через не найкращу ситуацію на ринку.

Відповісти
Підтримати
Otak
Otak 16.09.2024 11:06

Якоби ви знали флаттерок то я б може міг щось запропонувати краще)

Відповісти
Підтримати
Karina Kosenko
Andriy andriy 16.09.2024 15:27
У нас кантрі менеджерка дає якусь задачу і хоче, щоб вона була виконана якнайшвидше (бажано сьогодні, а то реальні юзери не проживуть пару днів без нової нотифікації), а новий продакт менеджер ходить до тебе кожні дві години і питає, коли буде готово

Никакие деньги не стоят, чтобы работать в такой параше. Да и денег как правило в таком нет.

Відповісти
Підтримати
Karina Kosenko
Beaver Green 15.09.2024 20:55
Чому не години?

Тому що години в усіх асоціюються ... саме з годинами!
Але ж насправді ми хочемо оцінити СКЛАДНІСТЬ задачі — а це дещо інше, яке не виміряється у годинах. Я думаю багато хто зі школи пам’ятає підручник Сканаві. От спробуйте узяти якесь рівняння і оцінити наскільки воно складне. Аби щось виміряти — треба з чимось порівнювати (в папугах). Я напевно можу сказати дивлячись на два рівняння що одне складніше за інше. Але спробуйте оцінити їх в годинах. Це мені нагадує «Вгадай Мелодію»:

— Я вирішу ці рівняння за 2 години.
— А я за півтори.
— Вирішуй!

Насправді я не можу сказати скільки годин займе у мене рішення. Може відразу спливе у пам’яті як такі рішати — а може доведеться два дні по довідниках копатися.
Навіть фізичну роботу дужа важко оцінити в годинах, а розумову — просто нема сенсу.

— Я напишу вірш за 10 хвилин
— А я за 5
— Пиши
— «Пакля — рвакля». Готово!

Ось банальний приклад: є чотири однакові по складності задачі оцінені у 2 години кожна. Скільки один девелопер виконає за 8 робочих годин? Кажете усі чотири? А за скільки 9 жінок народять дитину?
Сторі поінти допомагають трекати велосіті. Тобто реальну продуктивність і команди і кожного двелопера. І це як раз дає менеджеру змогу прикинуті якісь реалістичні строки, які можна обіцяти клієнту. А якщо ви вже усе оцінили в годинах — то клієнт буде очікувати що усе буде готове через, скажімо, 200 годин.
І це гірша проблема — що замовник також розуміє години як години (пригадую «Міфічний людино-місяць»). Які це проблеми викликає — раджу почитати тут, аби не повторюватись:

По факту вийде що тільки 50% часу команда витрачає аби робити корисну (тобто заєстімейчену) роботу!

dou.ua/...​rums/topic/49957/#2866677
А ще гірша проблема — що замовник часто платить саме за години. Пам’ятаєте трикутник: час — обсяг — гроші (Time + money + scope). Якщо у нас час = гроші, і усі естімейти (обсяг) також у годинах — то взагалі не залишається чим керувати! Окрім, звичайно, якості — яка має бути у центрі. Але в аутсорсі саме нею доводиться поступатися коли вже наобіцяли клієнту усе у годинах і нема можливості для маневру.

Відповісти
Підтримати
Ангуляров Реактин 15.09.2024 19:20

оценка в жопочасах — это микроменеджмент, я какую-то мелкую багу в 1 строку исправил и совесть не позволяла поставить даже 0.5 стори поинта, поставил 0.01, пм исправила на 0.5, вот отношение к девелоперам, а не когда заставляют оценивать в жопочасах. Часть команды в юсе, часто у них бывает надо узнать или уточнить и эти часы вообще неуместны. ПМ видит сколько сторипоинтов затратила команда и может оценить факап — или тасок нехватило или перегружена команда, либо когда дали оценку 2 поинта, а она стала 5 или мигрировала в следующий спринт, потому что реквайрменты долго выясняются

Відповісти
Підтримати
Ihor Kozar Flutter Developer в Anadea 14.09.2024 20:04

Сторі поінти допомагають уникнути проблеми коли оцінював один розробник а робити буде інший. Оскільки вони оцінюють складність задачі, а не час виконання.

Якщо задачу оцінює сініор, а виконує джун, то оцінка в годинах буде неточною, бо джун витратить більше часу. Сторі поінти ж враховують цю проблему. Просто у джуна і сініора буде закрита різна кількість сторі поінтів за спринт.

Відповісти
Підтримати
Trip Trip 17.09.2024 05:54
Сторі поінти ж враховують цю проблему.

А по факту може бути так що одну задачу на 2 SP джун закриє за 16 годин, а іншу на 5 SP за 10, а потім ще одну на 3 SP за 5. Тому що є якісь пробіли в знаннях або в розумінні архітектури проекту:)

Відповісти
Підтримати
Ihor Kozar
Ihor Kozar Flutter Developer в Anadea 03.10.2024 00:20

Може бути, що джун виявиться генієм і закриє більше sp ніж сініор. Все в цьому житті можливо, але ж ми розмовляємо про більш ймовірний сценарій :)

Відповісти
Підтримати
Trip Trip
Віталій Мартиник Senior Software Engineer в United Software 18.09.2024 08:39
Сторі поінти допомагають уникнути проблеми коли оцінював один розробник а робити буде інший. Оскільки вони оцінюють складність задачі, а не час виконання.

І як це допомагає? Якщо у спринт закладають середні сторіпоінти на людину?

Відповісти
Підтримати
Ihor Kozar
Ihor Kozar Flutter Developer в Anadea 03.10.2024 00:18

Коли я працював по сторіпоінтам то кількість сторіпоінтів закладалася індивідуально на кожну людину в залежно від її минулого перфомансу

Відповісти
Підтримати
Віталій Мартиник
Рахіт Срінавасович Кумар 14.09.2024 17:26

І взагалі канбае до деяких ролей краще підходить

Смішно коли спринт тулять наприклад супопту

Відповісти
Підтримати
Рахіт Срінавасович Кумар 14.09.2024 17:25

А ці всі мірки щоб скільки годин в день працювати?
А для різних по членів команди?
Хтось швидше робить хтось довше

Відповісти
Підтримати
Vic Programmer 14.09.2024 16:35

Чому сторі пойнти, чи функціональні одиниці діють значно краще за безпосередньо час ?
Справа тут не стільки в самих числах Фібоначі — а в методиці оцінки.
В чому найбільша проблема оцінки трудомісткості роботи англійською estimation ? В тому що вона часто є заниженою в комерційних конкурентних цілях under estimate, або навпаки занадто завищеною overestimate. І те і інше впливає драматично на : строки, бюджет і ділову репутацію. Тобто має безпосередній вплив на бізнес і прибуток — а таким чином і на більшу частину людського життя.
Методика оцінки в функціональних одиницях — має походження від Японської системи менеджменту Kaidzen, яка знайшла своє практичне застосування в ІТ в Британії і була названа Scrum.
Суть її полягає в тому — що трудомісткість оцінює не окремо взятий спеціаліст — «експерт», а декілька, кожний з яких виконує якусь конкретно взяту професійну функцію тому оцінка робіт виходе значно кращою і більш точною.
Для того щоб успішно проводити оцінку трудомісткості необхідно і достатньо наступне.
Усі спеціалісти задіяні в процесі чітко розуміють задачу (саме складне). За для цього має бути зрозуміло — що є ціллю робіт, хто з задіяних осіб має проблему і в чому вона полягає та що потрібно зробити поетапно для того щоб вирішити проблему (дискретизація задачі in scope of the task), а також що не потрібно робити (out of scope — часто розробка ядер, фреймерків бібліотек і т.п. замість існуючих на ринку рішень, перевинайдкння колеса та велосипеда і т.д.) бо це не входить в ціль яку вирішують.
В ІТ є 4 типи задач — розробка нової функціональності — feature зазвичай описується в форматі користувацької історії з критеріями оцінки якості (так само окрема техніка метода персон потягне на книгу), виправлення дефектів — defect/bag де відомі : очікувана поведінка програмно-апаратної системи, існуюча поведінка та шаги для для отримання результату. Науково дослідні роботи — research/spike де відомо існуюча проблема та шляхи пошуку її усунення — оцінюється час необхідний задля отримання результату.
Усі методики відомі як : planing pocker, capacity/velocity та перерахунок отриманих оцінок в реальний час та бюджети, коректування якості оцінки і таке інше — усе це відомо професійним менеджерам з підготовкою та використовується. З цього є гори літератури — та тренінгів на будь який смак та бюджет.
Описувати можна довго і довго пояснювати чому це дієво, інколи дуже дієво. Разом з тим дуже багато кому такі методики не подобаються бо віддають перевагу або іншим процесам — наприклад Спіраль або Waterflow, або улюбленому 80 % індустрії процесу експериментальному програмуванню, також відомому як «Х...як, Х...як і в продакшн» — де нема взагалі жодних гарантій успіху роботи.

Відповісти
Підтримати
Vic Programmer 14.09.2024 17:27

Пропустив 4 тип задач — це задача з обслуговування, Task. Зазвичай коли йдеться про DevOps

Відповісти
Підтримати
Vic
Рахіт Срінавасович Кумар 14.09.2024 19:35

Ну от як девопс підрозділ ефективний менеджер має на уоннус, ой спринт

Відповісти
Підтримати
Vic
Rostyslav Myronenko Solutions architect в Booking.com 14.09.2024 00:19

Оцінка в Story points та через інші шкали це теорія Agile, і існує безліч матеріалів, які пояснюють коли це має сенс та перевагу над оцінкою в кількості часу, і навпаки. Всі підходи мають право на існування, абсолютно правильного немає. В інших коментарях підкреслюється, що однією з переваг SP є абстрактна оцінка ефорту, яка виключає форс-мажори та похибку в кілька разів при оцінці в кількості часу. Оцінки в сторі пойнтах просто складніше зрозуміти, бо необхідно знати методологію побудування цих оцінок та планування капасіті спринта.

Відповісти
Підтримати
Karina Kosenko PHP developer в IT Craft 13.09.2024 22:32

На початку року нам прилетіла задача оцінювати таски не тільки в годинах, а й в сторі поінтах. Чесно кажучи, я ніколи з ними не працювала — я можу оцінити, скільки годин витрачу на задачу, все інше хз. Коротше, наш досвідчений ПМ дав нам табличку, згідно якої години конвертувалися в ці сторі поінти — наприклад, 1 година — 1 поінт, 4 години — 2 поінти, 1 день — 3, задача на 2-3 дні — 5 поінтів, і т.д. Проставляємо ці поінти ми, деви — тобто, якщо я знаю, що зроблю задачу за 2 дні, то ставлю 5 поінтів, і готово. Чесно кажучи, досі не розумію такого підходу, але підозрюю, що ми просто робимо щось не так — просто конвертуємо години в іншу одиницю виміру.

Відповісти
Підтримати
Bot Bot 14.09.2024 14:09

Сторі поінти НЕ для програмістів а для менджменту щоб розуміти велосіті, перформанс та єстимації делівері. Усі програмісти/куа/девопс/дизайнери працюють 40 годин на тиждень, там нічого міряти не потрібно.

Відповісти
Підтримати
Karina Kosenko
Саша Уманець 14.09.2024 16:12

Сторі поінти для менеджменту, але оцінку в сторі поінтах повинен назвати розробник?

Відповісти
Підтримати
Bot Bot
Bot Bot 14.09.2024 17:47

Так, в першу чергу це в інтересах розробника давати єстімацію. По друге саме викноваець знає наскілки складна задача, бо це його робота розуміти що треба зробити. Що робити з єстімацією, велосіті та іншим то вже задача менджменту та іншого керівництва що планує спрінти, квартали та річні бюджети плани та інше.

Меджмент робить квартальний, спрінтовий план для команди на основі її велосіті, та пороєстимованому беклозі. Коли після формування команди пройде десь 4+ спринти ви отримаєте середнье по вашій команді і зможете накидати план навіть на рік. Потім робите регулярно ревью велосіті, і дивитесь чи вписуєтесь в план чи ні. Далі вже думаєте чого просів велосіті, чи може потрібні додаткові інженери, чи може треба порізати фічей, чи щось не так з процесами.

В цілому метрик та кпі вистачає, головне з дуру не переборщити. Головне вибудувати стабільне делівері з задовільною якістью і щоб замовник вам та вашій команді довіряв, далі вже можете додавати джунів у шедоу а сеньорів перекидувати на інший проєкт що горить)))))

Відповісти
Підтримати
Саша Уманець
Vic Programmer 14.09.2024 17:22

І так і ні, може статись так, що під пресингом і значно більше ніж по 40 годин на годину працюють і при чому безкоштовно. Бо хтось один щоби підписати контракта навмисно занизив строки, бо як не підпише — від не продаючих продавців здихуються. А інший змушений під це знаходити методики закриття такого контракту, бо менеджерів які не вкладаються в узгоджені із замовником строки та бюджет здихуються. Треті мають конкуренцію на ринку та психологічний пресинг, погрози, штейкбрехери в разі страйків і таке інше та починають жити в режимі в кращому випадку 996.
Особливо в «червоних проектах» — головна проблема це битва за естімейт . В ІТ ще довго існував страйк ісходу (від ісходу євреї з Моісеєм з Єгипту) — тобто команда розбігалась в різні сторони.

Відповісти
Підтримати
Bot Bot
Bot Bot 14.09.2024 17:49
під пресингом і значно більше ніж по 40 годин на годину працюють

Не мамонти не вимруть. На початку всі отримують цей досвід, потім вже дорослішають і говорять що Х2 за овертайм або " у пічку матері", ну або не дорослішають і займаються мазохізмом. Але це вже зовсім інша іторія, сторі поінти тут ні до чого.

Відповісти
Підтримати
Vic
Vic Programmer 14.09.2024 18:26

Забуваєш про ситуацію на ринку — ринок ще і прив’язаний до конкретного місця у людей ще кредити, сім’ї родичі і т.д. Конфлікти на цій посаді стаються насправді мало не завжди.
Один із методів хоч якось розрулити у Win-Win — це намагатись акуратно естімейтити. Нікому не хочеться потрапляти в таку ситуацію на правді бо це ділова репутація в першу чергу, або на ринку замовників — або на ринку праці.
Звісно є ділки які так роблять навмисно, потім усеодно йдуть наприклад в Узбекистан — де маржинальнісиь вища і можна пропонувати ціну конкурентну Індії. Той ринок що був в Україні активно намагаються мувати в країни латинської Америки.

Відповісти
Підтримати
Bot Bot
Bogdan Shyiak SE or Dev 14.09.2024 19:28
Один із методів хоч якось розрулити у Win-Win — це намагатись акуратно естімейтити.

Естімейти не пов’язані з овертаймати в більшості випадків і у всіх випадках не є їх причиною.

Овертайми — це завжди пройоб менеджменту. Навіть коли цей пройоб трапляється, бо менеджмент легковірно приймає естімейт, є купа способів як про такий ризик дізнатись на ранніх етапах. Але значно частіше тут ситуація, коли менеджменту треба певний результат і естімейт їх цікавить лише з метою закидати ресурсами проблему (а це не завжди можливо).

Відповісти
Підтримати
Vic
Gremlin 17.09.2024 12:00

Ні
Овертайми — це завжди комплекс проблем, від замовника до виконавця, який наробив багів.

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 17.09.2024 13:13
Ні
Овертайми — це завжди комплекс проблем, від замовника до виконавця, який наробив багів.

І хто відповідає за вирішення комплексів проблем? Менеджмент :) У нього є купа практик, як працювати з замовником, як метігувати кількість багів і тд. Суть менеджменту (чи не основна причина появи окремого шару таких працівників) — це досягнення стабільного результату незалежно від якості того чи іншого виконавця та інших ризиків.

Відповісти
Підтримати
Gremlin
Gremlin 17.09.2024 13:34

пройоб менеджменту <> проблема менеджменту

я казав за пройоб, який може статися на будь-якому рівні виконання і потягнути за собою овертайми.

Відповісти
Підтримати
Bogdan Shyiak
Gremlin 17.09.2024 11:57
потім вже дорослішають і говорять що Х2 за овертайм

це правда: одна з причин овертаймів це БЕЗКОШТОВНІ овертайми — якщо вони можливі, то вони будуть.

Відповісти
Підтримати
Bot Bot
Karina Kosenko PHP developer в IT Craft 14.09.2024 20:36

Ну от щоб ви розуміли, у нас їх повинен також виставити розробник 🤦‍♀️ Я чесно не знаю, що наш ПМ (сініор рівня, до речі, зі сторони замовника) потім з ними робить. Той самий момент, коли вирішили ввести якийсь процес, а як з ним працювати — ніхто не знає.

Відповісти
Підтримати
Bot Bot
Bot Bot 14.09.2024 20:53

Вище писав, що ставить розробник, сторі поінти дуже проста штука і золзуміла всім технарям як коефіцієнт. Там достатньо 15 хвилин приділити щоб почитати чи пояснити це.

Відповісти
Підтримати
Karina Kosenko
Vic Programmer 14.09.2024 17:07

Те що вам дам дав PM — це нажаль імітація діяльності. Еталонну сторі, чи навіть таблицю еталонних сторі — команда зазвичай формує самостійно. Це потрібно для того щоби можна було порівнювати задачі одна до одної. Задачі на лічені години — це напевно про виключно Frontend, що вже каже що менеджмент використовує інший процесс і імітує гнучкий тобто Fragile.
В дійсності оцінку хтось вже зробив з гори, напевно ще при укладенні контракту — проробив архітектуру, розділив на задачі оцінив спеціалістам якого рівня кваліфікації їх потрібно віддати і роздав. Тобто це конструктивно водопадний процесс — Waterflow. Відповідно у менеджів програми та портфелю є плани графіки робіт — Діаграми Ганта, оцінки критичних шляхів кількості задіяних спеціалістів, потрібне обладнання : оцінена собівартість, прибутковість і таке інше. В цілому теж дієва система насправді і підходить для контрактів за фіксованою ціною або якихось інших проектів з заздалегідь відомими та проробленими вимогами яки не міняються під час розробки. Наприклад, софт для керування ракети для польоту на Марс чи Місяць, або комп’ютеру який керує атомним реактором підводного човна. Там усе зрозуміло, так динамічно як на ринку — ситуація не мінятиметься, усі параметри описані у відповідних кресленнях та документах перевірені різними спеціалістами та узгоджені. Усі зміни фіксуються у відповідних документах. Тим не менше, навіть Пентагон зараз вимагає від підрядників — гнучких процесів, щоби можна було вносити свої хотілки в продукт який розробляють,для того щоби мати можливість виправляти помилки у самих вимогах, зокрема. Для бізнесу з офшорної розробки — гнучкі підходи вимагають методики оцінки ризиків та пріоретизації задач.

Відповісти
Підтримати
Karina Kosenko
Andre 16.09.2024 18:39

Це точно не досвідчений ПМ 🤣.

Відповісти
Підтримати
Karina Kosenko
Gremlin 17.09.2024 11:51

На цьому прикладі ми бачимо, що сторі поінти НЕ відображають velocity, тобто, 3 легких задачі, які дадуть 3 сп можна зробити за день, а складну задачу на 3 сп дев буде робити кілька днів.
Інша справа, що на цю математику трохи забивають, якщо дев робить справу та веде себе адекватно, комунікує.
Гадаю, в усіх було таке, що зависали над таскою надовго, і нічого, не звільняли, не били.

Відповісти
Підтримати
Karina Kosenko
Bot Bot 13.09.2024 20:10

А до чого тут оцінка роботи девелопера до загального часу попадання фічі у прод? Ну там девопси, тестувальники? Вони усі сидять і чекають коли Вася запушить і моментально це попаде у прод? Оцінка в година це безглузда маячня що все одно первторюється у абстрактні числа коєфіціенти. Бо те що у вас 5 прогерів по 80 година спрінт це не значить що ваша команда зробить комітмент у 400 годин. За 13+ років я ніколи не бачив щоб оцінка в годинах хоч якось корелювала із реалністью чи показувала велсоіті команди.

Взагалі ці години повна маячня, бо всі тільки і ломають голову куди їх потім списати щоб було 40 годин на тиждень.

Також там де жучать за години там токсична культура і замовник жлоб що не довіряє команді.

Також таск на дві години у пятницю увечорі ніхіба не робиться за дві години, чи у вас всі девелопери/ку/девопси/дизайнери як роботи стабільно перформлять 52 тижни на рік?

Працюю лідом/архітектом декілька років і мені взагалі нарсати скільки там годин, бо мені важливо делівері команда в цілому, а не якісь абстрактні дупогодини.

Щодо замовника, то якраз сторі поінти дають більш менш нормальне розуміння по велосіті. Чи ви оцінюєте задачі навіть на декілька спринтів вперед з точністю до години? Чи все ж таки з кєфіцієнтами?

Відповісти
Підтримати
Саша Уманець 13.09.2024 23:02

За години ніхто нікого не жучить, всі розуміють що можемо промахнутися з оцінкою

Відповісти
Підтримати
Bot Bot
Bogdan Shyiak SE or Dev 13.09.2024 23:11
За години ніхто нікого не жучить, всі розуміють що можемо промахнутися з оцінкою

Питання в тому на скільки промахнутись.
І що ви будете робити, якщо в команді є люди, що постійно промахуються на 20%? Порівняєте їх годину до до 1.2 години? Тоді ваша година так само віртуальна як і сторіпоінти

Відповісти
Підтримати
Саша Уманець
Bot Bot 14.09.2024 17:57

Богдан дуже влучно пояснив.

ваша година так само віртуальна як і сторіпоінти
Відповісти
Підтримати
Саша Уманець
Beaver Green 15.09.2024 21:08

От тільки чи замовник розуміє що то «віртуальна» година, або краще «міфічний людино-місяць». І що естімейт у годинах не означає що саме за стільки годин треба буде заплатити і не більше?

Відповісти
Підтримати
Bot Bot
Beaver Green 15.09.2024 21:17

І які висновки ви зможете з цього зробити?
Якщо оцінка у сторі-поінтах то це оцінка саме складності. А от скільки реально потрачено часу — це має бути у годинах.
І це потім дає можливість аналізувати і робити висновки. Наприклад: дві однакові за сторі-поінтами задачі у результаті мають велику різницю у реальному часі. Чому? Може одну робив джун, а іншу — синьор. Може в одному випадку зміни робив автор у коді який до цього писав — а у іншому довелося міняти код, який писала команда з Китаю. Може усе було готове — але через конфлікт з іншим девелопментом довелося пів-дня мержити бренчі у Гіті.
Тобто одна справа коли неправильно оцінили складність задачі — і тоді пере-оцінка впливає на велосіті команди. А зовсім інша — якщо задача була проста, але через якісь затримки зайняла багато часу — але це не через погане велосіті команди.
Сторі-поінти відв’язують оцінку від реального часу — і тим самим забезпечують ту саму гнучкість (Agile).

Відповісти
Підтримати
Саша Уманець
Volodymyr Stolyarchuk Staff Backend Engineer в Cloudbeds 17.09.2024 09:08

Оці два твердження

За години ніхто нікого не жучить, всі розуміють що можемо промахнутися з оцінкою

і

Я хочу щоб команда оцінювала задачі в годинах і практикував це у своїй команді. Це ближче до бізнесу, формує просту та зрозумілу усім метрику відповідальності.

разом викликають посмішку) якщо не жучать, то яка відповідальність за те, що не вписуються в задекларовані години)

А якщо по темі, то для мене планування по годинах ніколи не працювало і навіть не можу уявити як воно може працювати в розробці і який це має бути продукт щоб це дійсно працювало і ти міг спланувати роботу на квартал.
Якщо ти оцінюєш роботу годинами, то у тебе це працює і ви регулярно вписуєтесь в задекларовані години?

Оцінка в СП має свої проблеми, але тут в коментарях накидали досить багато рекомендацій як це можна заставити працювати у тебе.

Також цікаво виглядає методика Shape Up від basecamp (чесно признаюсь я ще не пробував, тому виглядає цікаво в теорії)

Відповісти
Підтримати
Саша Уманець
Bogdan Shyiak SE or Dev 13.09.2024 19:55
Скажу чесно, я доволі скептично ставлюся до оцінки задач через сторі поінти,
Чи практикує хтось абстрактні оцінки? Чому не години?

Дуже цікаво чути таке від «a project manager with 10 years of experience».

Для початку розберіться, що оцінюють. Оцінюють складність задачі. Як ви це оціните в годинах? Що будете робити коли не попадете в оцінку на 10 годин при оцінці в 40 годин? Власне проблема тут зводить до «нечіткої логіки» і шкали в ній. Чим точніше шкала тим складніше її підібрати. Години — це дуже гранульована шкала. А тижні вас як ПМа не влаштують?

Далі йде пропрацьованість задачі, кількість невідомих при оцінці. Якщо їх багато, то навіть ПЕРТ вам не допоможе, все одно буде велике відхилення. Сторіпоінти тут знову ж оптимальна шкала, але є купа випадків де використовують той самий «розмір одягу». Занадто по дитячому? Придумайте свою шкалу на 3-5 елементів.

Сторіпоінти ще круто, бо в умовах незмінної команди і фіксованого по часу спрінта, дають можливість мапити їх на реальний час, переводити в естімет по людино-годинам. Хоча такий фокус має свої недоліки.

Власне візьміть якусь книжку по скраму і ПМству почитайте.

Відповісти
Підтримати
Саша Уманець 13.09.2024 23:00

Ви як Сергій Ребров на чолі збірної України

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 13.09.2024 23:03
Ви як Сергій Ребров на чолі збірної України

Не маю, жодного уявлення, що це означає. Але все ж почитайте хоч щось по спеціальності якою займаєтесь 10 років, можливо замість слідкування за футболом

Відповісти
Підтримати
Саша Уманець
Vic Programmer 15.09.2024 17:42

На галері вимоги до менеджменту зовсім інші. Бізнес галери — це «Deploy massive team and make them billable». Тобто ключові навички це навички продажів, перемов і хайрингу. Менеджер на галері — це набагато більше Sales.
А тому і когнітивний дисонанс, коли ви ведете бізнес перемовини — вам рахувати, малювати якісь роадмапи чи діаграми Ганта, оцінювати критичні шляхи і т.д. і т.п. не треба. Вам треба час в годинах і перелік конкретних спеціалістів з погодинним рейтом.
Тому дивного мало. Головні питання які задають на співбесіді на галерного PM-а. «Які документи висилаються на замовника», і ви маєте обов’язково знати що таке Bit, Propose та Estimate це як про LinkedList та ArrayList. Таким чином головні навички галерного ПМ-а це торгівля, теж має дуже велике значення.

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 15.09.2024 19:00
На галері вимоги до менеджменту зовсім інші. Бізнес галери — це «Deploy massive team and make them billable»

Не розумію до чого ця фраза, і яку частину мого коментаря вона має адресувати.

Тому дивного мало. Головні питання які задають на співбесіді на галерного PM-а. «Які документи висилаються на замовника», і ви маєте обов’язково знати що таке Bit, Propose та Estimate

Знову ж, галерний ПМ (може посада буде типу Скрам майстер) має знати принципи роботи сторіпоінтів і оцінки в годинах. В продуктових командах так само можуть використовувати різні інструменти — години, сторіпоінти, т-шорт сайзінг, адже це просто інструменти. І «торгівля» тут нідочого.

Відповісти
Підтримати
Vic
Vic Programmer 15.09.2024 19:29

Навіщо про це знати взагалі якщо ви займаєтесь посередництвом та перепродажем роботи людей з ринку ? Аутстаівнговому бізнесу це зовсім не потрібно, крім того це взагалі не проектна модель бізнесу, це посередництво і як себе позиціонують — надання послуг. Відповідно для успішного заробітку грошей — усі ці навички зовсім не потрібні. А от вміння торгувати — маркетинг, перемовини, укладення угод, юридичні аспекти це ключове. Просто геть інша спеціальність, між іншим коштує дешевше навіть за програмістів.
Те що існують і реально саме управлінці і в Україні також — звісно існують, бо не усе аутстафінг є офшорні розробки на фіксовану ціну і продуктовий бізнес і т.д. Крім того самі менеджери так само можуть працювати, за контрактом.

Відповісти
Підтримати
Bogdan Shyiak
Bogdan Shyiak SE or Dev 15.09.2024 19:41
Навіщо про це знати взагалі якщо ви займаєтесь посередництвом та перепродажем роботи людей з ринку ? Аутстаівнговому бізнесу це зовсім не потрібно, крім того це взагалі не проектна модель бізнесу,

Так тоді там і не буде ПМа. Якщо мова про аутстаф у сенсі «розробник повністю менеджиться замовником». То там немає ПМа, там скоріше роль акаунт менеджера, яку може виконувати хтось з ПМім.
Все ще не ясно для чого ви це тут пишете.
ТС (по лінкедіну і доу профайлу) — проектний менеджер з досвідом БА/продуктного менеджменту навіть в продуктовій конторі, у нього в скілах вказаний «Scrum, Agile Methodologies». Як така людина за 10 років не розібралась з тим що таке і як користуватись сторі поінтами, не ясно. Такий топік норм би був для джуна-мідла девелопера, ну може сеньйор девелопер міг би понакидувати (на скрам).

Відповісти
Підтримати
Vic
Pavlo Vasylchenko Team Lead / Tech Lead / Engineering Manager в - 13.09.2024 19:37

Плюс стори поисков если нужно оценивать наперед.

Пример:
Задача сложностью 10 сп в начале проекта может быть сделана за 20 дней, а конце проекта за 5 дней. Скорость команды может измениться.
В случае стори поинтов они просто будут умножены на велосити.
В случае дней нужно постоянно переоценивать чтоб данные были актуальны.

Если работать с маленьким беклогом, оценивать и тут же брать в работу то разницы не много.

Відповісти
Підтримати
Саша Уманець 13.09.2024 22:59

Скажіть будь ласка у вас не було такого що потрібно було переоцінювати сторі поінти?

Відповісти
Підтримати
Pavlo Vasylchenko
Pavlo Vasylchenko Team Lead / Tech Lead / Engineering Manager в - 14.09.2024 00:06

Разве что если это начало проекта и оценки даны очень приблизительные. Потом обычно разделение больших задач на части и возможна переоценка.
Но если задачи понятны и оценены и просто лежат в беклоге, то не переоценивал обычно. А зачем?

Відповісти
Підтримати
Саша Уманець

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.