крута підбірка! дякую!

Трішки підкорегую вас. В суті/цілі/визначенні скраму полягає ідея того, що БУДЬ-ЯКУ ЗАДАЧУ може виконати БУДЬ-ЯКИЙ ЧЛЕН ДЕВЕЛОПМЕНТ ТІМИ( немає ніяких фронт бек куа девопс мобайл і тд.). У скрамі є тільки 3 ролі — девелопер, скрам майстер та продакт овенр.
Можете ознайомитися з офіційним документом scrumguides.org/...​rum-guide.html#developers там в принципі все розписано про ролі і обовʼязки :) а також про те як відбувається планування ітерації та як розподілення задач відбувається. інакше ви отримуєте не чистий скрам, а його варіації-мутації(як хороші так і погані) :)

Цікаво було б побачити якісь приклади. Бо мені на думку спадає хіба що пиляння якогось MVP

абсолютно ні. Наприклад, розробка складного ембедед, розробка SDK-рішень, розробка бібліотек, розробка тулів по міграціям баз даних і т.д. в світі айті ДУЖЕ багато того де краще тестування віддати на роль розробника ніж залучати тестувальника котрий буде заважати :)
в тестуванні є навіть принцип , один з основних, що тестування залежить ВІД КОНТЕКСТУ. тому тестування повинно бути, АЛЕ НЕ ЗАВЖДИ тестувальник в теперішному розумінні повинен бути на проєкті.

як раз можна перевірити чи не обманює вас рекрутер :)

та Канера навіть не всі тестувальники читали :D :D :D

по лицю то ще в кращому випадку :D а там вже як повезе :D

ну так а в ідеальному скрамі ж і нема тестувальників. є фулстак девелопери які і бек і фронт і тести вміють.
але завжди все стопається в бюджет. бо фулстак який вміє і в кодінг і тести коштує як два дева і тестувальник разом :D

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

перше, це те , що тестувальник повинен бути ІНЖЕНЕРОМ. вміти програмувати, вміти розуміти архітектуру, алгоритми, та процеси.
а друге — гігієна розробки продукта повинна бути на всіх рівнях — вимог, кодування та тестування.

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

я би порадив після як тестують в гуглі почитати більш нову — Software Engineering at Google
www.oreilly.com/...​neering-at/9781492082781
там про все. і про розробку і про тестування. і взагалі про все))

звісно. тоді планування буде стосовно часу. Вася бек оцінює в 3 години, Петро в 6 годин фронт і Михайло в 3 години тестування. отже у нас 12 годин на завершення сторі. тут одразу і залежність видно шо коли можна буде робити і таймлайн повністью прогнозован.
а оцінювання у сторіпоінтах у «своїх» зусиллях — то є антипатерн. адже ці зусилля повинні бути для всіх однакові. бо в скрамі поняття девелопер — це ВСІ РІВНОЗНАЧНІ ЧЛЕНИ КОМАНДИ. тобто нема як такових тестувальників, розробників, девопсів і тд. і задача в 1 сторі поінт вона однакова для всіх. саме тоді можна планувати адекватно спринт.

ви прочитали статтю і не зрозуміли її. тут описується те, які проблеми можуть піти із того шо люди НЕ РОЗУМІЮТЬ як впроваджувати сторі поінти. і от одна з проблем, це те що люди часто починають естімейтити в них кожен для себе в ЗУСИЛЛЯХ СВОЇХ а не командних при чому все члени команди являються нерівнозамінними. це описано у другому пункті ВИСНОВКІВ. буд-ласка, будьте уважні коли читаєте, читайте те що написано ане те що хочете побачити та не займайтеся софістикою :)

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

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

це дійсно цінний комент для мене і для спільноти. дякую вам за ваше старання та труд. найулюбленіший та найкорисніший вид коментів саме такі :D

VisualBasic або Assembler

а потім ще й дивуються «а чого нічо не працює» :D

ну тут згоден)) заголовок трішки кричащий :D

перечитайте ще раз статтю уважно та без емоцій :)
там про те ЯКІ ПОМИЛКИ можуть допустити менеджери та команда.
ціль — показати типовіші помилки і САМЕ ТОДІ ВОНИ НЕ БУДУТЬ ПРАЦЮВАТИ.

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

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

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

так це будь-яка естмація для цього треба. тут по-барабану сторі поінти, години чи крокодили. це ВСЕ про планування.

так ціль статті, ще раз — це ЯКІ ПОТЕНЦІЙНІ ПОМИЛКИ команда та менеджер можуть допустити при впровадженні сторі поінтів :) там же так і написано «давайте поміркуємо які помилки можемо допустити» )))
ну і для того шоб люди розуміли шо сторіпоінти НЕ ДЛЯ ВСІХ і шо якшо не йде то треба вертатися на години якшо шо :)

все вірно :) заголовок для привернення уваги ))

сказала людина, 8 із 9 статтей котрої на доу — це просто копіпаста з публічних ресурсів)))

в два крокодили і одного алігатора :)

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

дякую за розгорнутий комент :) погоджуюся з кожним словом :)
щодо заголовку — треба було придумати щось клікбейтне що зверне увагу та спровокує до дискусій :D