Сразу скажу, что QA не являюсь и богатого опыта самостоятельной оценки затрат времени на тестирование не имею. Возможно из-за этого вопросы и возник)
А можно хотя бы грубо раскладку по часам? Что сколько времени заняло? Тут грубо говоря получилось, что один-единственный тестировщик затащил разработку мобильного приложения с нуля (ну ок, при готовых требованиях) за три месяца, работая на 0.2 ставки 0_о
Немного подушню: сторипоинты - это не часть Скрама. И соглашусь: однажны абстрактные оценки должны соотнестись с реальными трудозатратами.
И вот эти два момента часто приводят к ситуации, когда люди теряют веру в Скрам да и в Аджайл в целом. На самом деле вы можете использовать голую астракцию или трекать всё до каждой минуты. Важно найти такой способ, который подходит вам и приближает вас к цели.
Сами сторипоинты к этому моменту тоже сильно искажены. Как уже отмечено выше, "замешивание" в оценку в сторипоинтах времени полностью рушит концепцию. В целом, то, что автор описывает в статье как своё достижение, это убийство сторипоинтов.
Что делать? Опять же, сказано выше: перестать называть свою оценку сторипоинтами. Отделить оценку реальных трудозатрат от оценки... эм... инженерной сложности задачи.
Зачем это делать? И вновь, сказано выше: сторипоинты помогают с оценкой в условиях высокой неопределённости. Даже опытная команда на стабильном проекте может ВНЕЗАПНО получить от заказчика такой фича-реквест, что всем дружно придётся чесать затылок. И тут поможет абстракция. Потом уже декомпозированные задачи можно будет оценить ещё раз, в реальных трудозатратах будь то фокус-часы или ещё что.
Авторы Скрама - хитрые и в то же время логичные жуки. Они не принимают на себя ответственность ни за какие адаптации и "на практике". С одной стороны, Скрам существует не в вакууме, нам нужно как-то вписывать его в реальную картину мира. С другой, как авторы могут предугадать всё разнообразие вариантов внедрения и ещё принимать ответственность за то, как и что мы подкрутим?
Поэтому, подчеркну ещё раз, чаще всего получается как в анекдоте: «Вот все говорят: «Карузо! Карузо!» А я послушал – так ничего особенного» – «Вы слышали Карузо?!» – «Нет. Мне Рабинович напел».
Заголовок статьи гласит "Реквием по SCRUM". Если смыть налёт кликбейта, то останется "Реквием по нашей адаптации SCRUM".
Чтобы "отказаться от Скрама" надо сначала полноценно внедрить Скрам.
"Скрам с некоторыми адаптациями" - это не Скрам.
Юзер стори, эпики, стори пойнты - всего этого нет в Скраме, это не его неотъемлемые части. Если эти приёмы вам не подходят, вы можете отказаться от них и заменить чем-то другим.
В Скраме нет проджект менеджера. И скрам мастер не может ничего "навязывать", он вообще не имеет никакой административной власти.
Перекладывать всю ответственность за "скрамность" команды на мастера - неправильно. Все члены команды должны постигать Скрам и действовать в соответствии с его ценностями и подходами.
Если в компании команда разработки внедрила Скрам, а вся остальная компания работает по совершенно другим лекалам - ждите нестыковок, конфликтов и битвы мировозрений. И дело тут не в самом Скраме, он при этом может прекрасно работать.
Скрам мастер действительно может быть не нужен команде... на фултайм. Также, роль скрам мастера может выполнять кто-то из разработчиков. Это норма. Если команда зрелая и устойчиво движется по рельсам Скрама, тратить деньги на выделенного фултайм скрам мастера нет нужды. Скрам лишь запрещает отказываться от роли целиком.
"Фокус на результате, а не на процессе". Любой фреймворк, любая методолгия - это процессы, ритуалы, артефакты. В Скраме не так много сущностей. Вы справитесь меньшим количеством? Попробуйте построить эффективную разработку на основе одного только "Делай хорошо, а плохо не делай".
"Минимизация бюрократии" - от создателей "документация не нужна". К сожалению, мы не получаем кристально ясные задачи из космоса. Документация, митинги внутри команды и с заказчиками это неизбежные фиксы в нашем неидеальном мире. Если в вашей команде не умеют проводить эффективные митинги - надо учиться. Сорян.
"Поддержка долгосрочного планирования" - вашему вниманию предлагается Product Goal. Если вашей команде, работающей по Скраму, не хватает глобальных целей, пните продакт оунера. Или он ранее от тоже казался ненужным?)
Такие дела. Очень часто Скрам становится жертвой либо карго культа, когда люди слепо верят в то, что толком не понимают, либо "адаптаций", когда под вывеской Скрама внедряется кое-что и кое-как, а итоговое фиаско списывают на недостатки "этих ваших Скрамов".
При этом я ни в коем случае не называю Скрам серебряной пулей. Да, он может не подойти. Да, какой-то другой подход может сработать лучше. Всем желаю найти свой путь и добиться успеха.
Мы живём в реальном мире и, к сожалению или к радости, используют эти самые часы. Сложно продать заказчику контракт на Х стори пойтов, если ты аутсорс и работаешь по T&M контракту. Сложно доказать эйчару, что тебе в команду нужен дополнительный разработчик, потому что тебе нужно увеличить производительность на Х стори пойнтов.
Безусловно, стори пойнты рабочий инструмент. Про то, что 1 SP должен быть равен 1 часу вообще речи не идёт. И любая оценка, хоть в стори пойнтах, хоть в часах, хоть в попугаях, должна оценивать риски, сложность и т.д.
Мой вопрос вытекает из того, что по мере того, как разработка перестаёт быть "вещью в себе" и должна быть вписана в другие процессы компании, кому-то и как-то придётся делать эту "бухгалтерию".
Спасибо за развёрнутую, но не перегруженную статью. Пара вопросов от меня:
1) Правильно ли я понял, что в Тикетленде сейчас несколько команд и один коуч? Который поочерёдно работает с отдельными командами? Или же коуч делит своё время между всеми командами?
2) В начале статьи говорилось, что старая организация команд была ориентирована на приложения, а сейчас команды кросс-функциональные - а в чём разница?
3) Переводятся ли в итоге строи поинты в человекочасы? Со временем производительность команды выравнивается и по итогу X дней спринта равны Y сторипойнтам. Перейти в мир "реальных" величин кажется логичным шагом. Или же вы продолжаете использовать строи пойнты?
Надо определиться, за что отвечает тимлид? Максимизация продуктивности команды? Ресурсные вопросы комплектации команды входят в его зону ответственности? И так далее. Это поможет сфокусироваться тимлиду на тех областях, где "кто, если не он?". Вопросы по другим областям нужно подсветить ответственным и дальше решать сообща.
Кто вообще сказал, что разработчик отвечает только за свой код? Это прописано в каких-то корпоративных политиках, гайдах для разработчиков и т.д.? Это дезинтеграция. Если разработчик приходит в КОМАНДУ с мыслью "моя хата с краю", то он не приходит в КОМАНДУ. Плёвые вопросы вроде "немного неточных" тикетов разработчик мог бы прояснить сам, всё остальное он отгружает человеку, которые отвечает за "понятные тикеты". Да, возможно будут одна-две волны митинг, уточнение критериев ясности - но потом всё должно стать красиво. Если не становится - это беда и не проблема митингов, а проблема менеджмента.
Использовать ретро для разборок "кто виноват" - это ещё более дезинтегрирующая идея. Никто не любит быть виноватым и как правило люди не стремятся стать виноватыми. А для исправления непреднамеренных ошибок публичные бичевания не очень подходят. Попробуйте внедрить культуру "blameless" ретро. Оперируйте такими понятиями как "улучшения", а не "исправление ошибок". Жизнь - это то, как мы к ней относимся. Если тимлид программирует команду на разборки на ретро, ждите срачей.
Если говорить про сами созвоны, то не стоит выносить их в какую-то супер-отдельную категорию. Вот есть созвоны. А групповые чаты? А разговоры у стола коллеги? А письма? Всё это инструменты и все они должны служить благим целям. Вопрос не в самих созвонах, а в их эффективности. Приносят ли они пользу? Эта польза получается максимальной именно в такой форме? Иногда тебе не нужен созвон, вопрос можно решить в чате. А иногда переписка заходит в тупик и проще созвониться и проговорить всё голосом. Начните с манагеров, обучите их пользоваться каждым инструментом коммуникации, выбирать подходящий в зависимости от ситуации.
Наверное, вкратце ситуацию можно было бы описать таким образом. Есть симптомы, а есть заболевания. Есть баг, а есть корневая причина. Бесполезные митинги - это симптом. Будет тимлид лечить симтом или само заболевание - вот, в чём вопрос.
Я бы сказал, что проблема несколько глубже: а каким образом удовлетворённость или состояние потока относятся к инженерным метрикам? В статье немного смешались метрики, подходы и сферические кони в вакууме. Читатель может потеряться.
Строго говоря, состояние потока - это вообще не метрика. Это "перспектива", с которой нужно смотреть на компанию и её процессы. Одна из осей координат, если угодно. Потому что DevEx сам по себе не методология (когда тебе дают чёткие инструменты), а фреймворк (когда акцент делается на практиках и образе мысли). В статье, кстати, DevEx как раз фреймворком и именуется.
Как это работает? Сначала вы выравниваетесь по тому, что для вашей компании или команды является состоянием потока и каким вы его хотите видеть. Потом выделяете факторы, которые влияют на него в лучшую и в худшую сторону. Затем уже эти факторы некоторым образор оцениваете. И это не обязательно числовые значения, это может быть и "хорошо"-"нормально"-"плохо" и т.п.
Далее, оценив своё текущее положение, вы стараетесь внедрить улучшения в тех областях, которые тянут состояние потока вниз.
Scrum, вероятно, самый известный Agile-фреймворк, включил Velocity как метрику для измерения объема работы
Вот тут ещё попрошу пруфы. В каком из изданий Scrum Guide упоминается Velocity как часть фреймворка? В скрам входит только то, что написано в гайде. Всё остальное, даже то, что создатели могу рассказывать на публичных выступлениях или писать в блогах, не является частями скрама.
Потом окажется, что презентацию по обратной связи делал условный Вася, который получит за этот скилл низкую оценку. И как после этого оценивать влияние его презентации на общий уровень в команде?
Как будто можно было сначала провести оценку, а потом поделить темы в зависимости от уровня навыка и критичности скилла.
Проблема этого подхода заключается в том, что собственно менторинга и оценки качества знаний (компетенции) нет. Один коллега что-то самостоятельно изучил, рассказал другим и... И получил галочку, заполнил ещё одну ячейку матрицы?
Трёх скоростей для путешествия априори мало, я про это говорил. Диапазон узкий, разница между передачами скорее всего значительная. С такой трансмиссией силы будут уходить быстрее.
Мягкое седло - синоним онемевшей промежности. На мягком седле приятно проехать 10км в городе по асфальту. Но даже вот так 100+ км проехать - сначала будет жопка побаливать. А потом по докторам ходить придётся.
Натирание происходит либо от неудобного седла, либо от неправильно подобраной одежды. Широкое седло "диван" и труханы+джинсы - залог натирания, например.
Я рад, что герои статьи успешно финишировали. При этом, скажем так, я бы не рекомендовал повторять их эксперимент один в один. Всё же лучше уделить больше времени изучению теоретической базы. Тогда глядишь и поездка дастся легче.
Искусственный интеллект, перелогинься, мы тебя узнали.
Сразу скажу, что QA не являюсь и богатого опыта самостоятельной оценки затрат времени на тестирование не имею. Возможно из-за этого вопросы и возник)
А можно хотя бы грубо раскладку по часам? Что сколько времени заняло? Тут грубо говоря получилось, что один-единственный тестировщик затащил разработку мобильного приложения с нуля (ну ок, при готовых требованиях) за три месяца, работая на 0.2 ставки 0_о
Вроде начинали за здравие, а в итоге... Просто перечисление практик и артефактов ITIL? С минимумов примеров реализации(
Немного подушню: сторипоинты - это не часть Скрама. И соглашусь: однажны абстрактные оценки должны соотнестись с реальными трудозатратами.
И вот эти два момента часто приводят к ситуации, когда люди теряют веру в Скрам да и в Аджайл в целом. На самом деле вы можете использовать голую астракцию или трекать всё до каждой минуты. Важно найти такой способ, который подходит вам и приближает вас к цели.
Сами сторипоинты к этому моменту тоже сильно искажены. Как уже отмечено выше, "замешивание" в оценку в сторипоинтах времени полностью рушит концепцию. В целом, то, что автор описывает в статье как своё достижение, это убийство сторипоинтов.
Что делать? Опять же, сказано выше: перестать называть свою оценку сторипоинтами. Отделить оценку реальных трудозатрат от оценки... эм... инженерной сложности задачи.
Зачем это делать? И вновь, сказано выше: сторипоинты помогают с оценкой в условиях высокой неопределённости. Даже опытная команда на стабильном проекте может ВНЕЗАПНО получить от заказчика такой фича-реквест, что всем дружно придётся чесать затылок. И тут поможет абстракция. Потом уже декомпозированные задачи можно будет оценить ещё раз, в реальных трудозатратах будь то фокус-часы или ещё что.
Я нигде не утверждал, что чистый Скрам работает и я знаю такие команды.
Я утверждаю, что вы делаете вывод "Скрам не работает" на основе ложных посылок.
Более того, что случится, если я назову команду, где чистый Скрам работает? Вы уверуете и удалите эту статью?
Меня привлекла аргументация "Почему Скрам не работает". Собственно, разбору этих аргументов и посвящены мои комментарии. Не более того.
Это не какой-то конкретный монстр. У каждого этот монстр свой.
Как видится мне, основная проблема во внедрении Скрама заключается в изначальном желании "адаптировать" Скрам, а не инициировать изменения в компании.
В итоге компания, которая недовольна текущей орагнизацией работы, протаскивает эту неэффективность в свою "адаптацию" Скрама.
Авторы Скрама - хитрые и в то же время логичные жуки. Они не принимают на себя ответственность ни за какие адаптации и "на практике". С одной стороны, Скрам существует не в вакууме, нам нужно как-то вписывать его в реальную картину мира. С другой, как авторы могут предугадать всё разнообразие вариантов внедрения и ещё принимать ответственность за то, как и что мы подкрутим?
Поэтому, подчеркну ещё раз, чаще всего получается как в анекдоте: «Вот все говорят: «Карузо! Карузо!» А я послушал – так ничего особенного» – «Вы слышали Карузо?!» – «Нет. Мне Рабинович напел».
Заголовок статьи гласит "Реквием по SCRUM". Если смыть налёт кликбейта, то останется "Реквием по нашей адаптации SCRUM".
Тезисами и по делу:
Скрам не методология.
Чтобы "отказаться от Скрама" надо сначала полноценно внедрить Скрам.
"Скрам с некоторыми адаптациями" - это не Скрам.
Юзер стори, эпики, стори пойнты - всего этого нет в Скраме, это не его неотъемлемые части. Если эти приёмы вам не подходят, вы можете отказаться от них и заменить чем-то другим.
В Скраме нет проджект менеджера. И скрам мастер не может ничего "навязывать", он вообще не имеет никакой административной власти.
Перекладывать всю ответственность за "скрамность" команды на мастера - неправильно. Все члены команды должны постигать Скрам и действовать в соответствии с его ценностями и подходами.
Если в компании команда разработки внедрила Скрам, а вся остальная компания работает по совершенно другим лекалам - ждите нестыковок, конфликтов и битвы мировозрений. И дело тут не в самом Скраме, он при этом может прекрасно работать.
Скрам мастер действительно может быть не нужен команде... на фултайм. Также, роль скрам мастера может выполнять кто-то из разработчиков. Это норма. Если команда зрелая и устойчиво движется по рельсам Скрама, тратить деньги на выделенного фултайм скрам мастера нет нужды. Скрам лишь запрещает отказываться от роли целиком.
"Фокус на результате, а не на процессе". Любой фреймворк, любая методолгия - это процессы, ритуалы, артефакты. В Скраме не так много сущностей. Вы справитесь меньшим количеством? Попробуйте построить эффективную разработку на основе одного только "Делай хорошо, а плохо не делай".
"Минимизация бюрократии" - от создателей "документация не нужна". К сожалению, мы не получаем кристально ясные задачи из космоса. Документация, митинги внутри команды и с заказчиками это неизбежные фиксы в нашем неидеальном мире. Если в вашей команде не умеют проводить эффективные митинги - надо учиться. Сорян.
"Поддержка долгосрочного планирования" - вашему вниманию предлагается Product Goal. Если вашей команде, работающей по Скраму, не хватает глобальных целей, пните продакт оунера. Или он ранее от тоже казался ненужным?)
Такие дела. Очень часто Скрам становится жертвой либо карго культа, когда люди слепо верят в то, что толком не понимают, либо "адаптаций", когда под вывеской Скрама внедряется кое-что и кое-как, а итоговое фиаско списывают на недостатки "этих ваших Скрамов".
При этом я ни в коем случае не называю Скрам серебряной пулей. Да, он может не подойти. Да, какой-то другой подход может сработать лучше. Всем желаю найти свой путь и добиться успеха.
Обнял.
По третьему пункту.
Мы живём в реальном мире и, к сожалению или к радости, используют эти самые часы. Сложно продать заказчику контракт на Х стори пойтов, если ты аутсорс и работаешь по T&M контракту. Сложно доказать эйчару, что тебе в команду нужен дополнительный разработчик, потому что тебе нужно увеличить производительность на Х стори пойнтов.
Безусловно, стори пойнты рабочий инструмент. Про то, что 1 SP должен быть равен 1 часу вообще речи не идёт. И любая оценка, хоть в стори пойнтах, хоть в часах, хоть в попугаях, должна оценивать риски, сложность и т.д.
Мой вопрос вытекает из того, что по мере того, как разработка перестаёт быть "вещью в себе" и должна быть вписана в другие процессы компании, кому-то и как-то придётся делать эту "бухгалтерию".
Спасибо за развёрнутую, но не перегруженную статью. Пара вопросов от меня:
1) Правильно ли я понял, что в Тикетленде сейчас несколько команд и один коуч? Который поочерёдно работает с отдельными командами? Или же коуч делит своё время между всеми командами?
2) В начале статьи говорилось, что старая организация команд была ориентирована на приложения, а сейчас команды кросс-функциональные - а в чём разница?
3) Переводятся ли в итоге строи поинты в человекочасы? Со временем производительность команды выравнивается и по итогу X дней спринта равны Y сторипойнтам. Перейти в мир "реальных" величин кажется логичным шагом. Или же вы продолжаете использовать строи пойнты?
Давайте по порядку.
Надо определиться, за что отвечает тимлид? Максимизация продуктивности команды? Ресурсные вопросы комплектации команды входят в его зону ответственности? И так далее. Это поможет сфокусироваться тимлиду на тех областях, где "кто, если не он?". Вопросы по другим областям нужно подсветить ответственным и дальше решать сообща.
Кто вообще сказал, что разработчик отвечает только за свой код? Это прописано в каких-то корпоративных политиках, гайдах для разработчиков и т.д.? Это дезинтеграция. Если разработчик приходит в КОМАНДУ с мыслью "моя хата с краю", то он не приходит в КОМАНДУ. Плёвые вопросы вроде "немного неточных" тикетов разработчик мог бы прояснить сам, всё остальное он отгружает человеку, которые отвечает за "понятные тикеты". Да, возможно будут одна-две волны митинг, уточнение критериев ясности - но потом всё должно стать красиво. Если не становится - это беда и не проблема митингов, а проблема менеджмента.
Использовать ретро для разборок "кто виноват" - это ещё более дезинтегрирующая идея. Никто не любит быть виноватым и как правило люди не стремятся стать виноватыми. А для исправления непреднамеренных ошибок публичные бичевания не очень подходят. Попробуйте внедрить культуру "blameless" ретро. Оперируйте такими понятиями как "улучшения", а не "исправление ошибок". Жизнь - это то, как мы к ней относимся. Если тимлид программирует команду на разборки на ретро, ждите срачей.
Если говорить про сами созвоны, то не стоит выносить их в какую-то супер-отдельную категорию. Вот есть созвоны. А групповые чаты? А разговоры у стола коллеги? А письма? Всё это инструменты и все они должны служить благим целям. Вопрос не в самих созвонах, а в их эффективности. Приносят ли они пользу? Эта польза получается максимальной именно в такой форме? Иногда тебе не нужен созвон, вопрос можно решить в чате. А иногда переписка заходит в тупик и проще созвониться и проговорить всё голосом. Начните с манагеров, обучите их пользоваться каждым инструментом коммуникации, выбирать подходящий в зависимости от ситуации.
Наверное, вкратце ситуацию можно было бы описать таким образом. Есть симптомы, а есть заболевания. Есть баг, а есть корневая причина. Бесполезные митинги - это симптом. Будет тимлид лечить симтом или само заболевание - вот, в чём вопрос.
Тезис о прогрессивной экономике поверх фотографии Минска - это та ещё ирония)
Ещё раз. Скрам эту метрику не включал. Велосити - не часть скрама. Тчк.
Я бы сказал, что проблема несколько глубже: а каким образом удовлетворённость или состояние потока относятся к инженерным метрикам? В статье немного смешались метрики, подходы и сферические кони в вакууме. Читатель может потеряться.
Строго говоря, состояние потока - это вообще не метрика. Это "перспектива", с которой нужно смотреть на компанию и её процессы. Одна из осей координат, если угодно. Потому что DevEx сам по себе не методология (когда тебе дают чёткие инструменты), а фреймворк (когда акцент делается на практиках и образе мысли). В статье, кстати, DevEx как раз фреймворком и именуется.
Как это работает? Сначала вы выравниваетесь по тому, что для вашей компании или команды является состоянием потока и каким вы его хотите видеть. Потом выделяете факторы, которые влияют на него в лучшую и в худшую сторону. Затем уже эти факторы некоторым образор оцениваете. И это не обязательно числовые значения, это может быть и "хорошо"-"нормально"-"плохо" и т.п.
Далее, оценив своё текущее положение, вы стараетесь внедрить улучшения в тех областях, которые тянут состояние потока вниз.
Такие дела.
Scrum, вероятно, самый известный Agile-фреймворк, включил Velocity как метрику для измерения объема работы
Вот тут ещё попрошу пруфы. В каком из изданий Scrum Guide упоминается Velocity как часть фреймворка? В скрам входит только то, что написано в гайде. Всё остальное, даже то, что создатели могу рассказывать на публичных выступлениях или писать в блогах, не является частями скрама.
Цель инженерных метрик
Цели использования инженерных метрик могут быть разнообразными.
Directed by Robert B. Weide
Потом окажется, что презентацию по обратной связи делал условный Вася, который получит за этот скилл низкую оценку. И как после этого оценивать влияние его презентации на общий уровень в команде?
Как будто можно было сначала провести оценку, а потом поделить темы в зависимости от уровня навыка и критичности скилла.
Проблема этого подхода заключается в том, что собственно менторинга и оценки качества знаний (компетенции) нет. Один коллега что-то самостоятельно изучил, рассказал другим и... И получил галочку, заполнил ещё одну ячейку матрицы?
Трёх скоростей для путешествия априори мало, я про это говорил. Диапазон узкий, разница между передачами скорее всего значительная. С такой трансмиссией силы будут уходить быстрее.
Мягкое седло - синоним онемевшей промежности. На мягком седле приятно проехать 10км в городе по асфальту. Но даже вот так 100+ км проехать - сначала будет жопка побаливать. А потом по докторам ходить придётся.
Натирание происходит либо от неудобного седла, либо от неправильно подобраной одежды. Широкое седло "диван" и труханы+джинсы - залог натирания, например.
Я рад, что герои статьи успешно финишировали. При этом, скажем так, я бы не рекомендовал повторять их эксперимент один в один. Всё же лучше уделить больше времени изучению теоретической базы. Тогда глядишь и поездка дастся легче.
Дя, с т.з. велосипедизма странноватая история. Планетарочка на три скорости для путешествия, "южноафриканская Мерида", мягкое седло на дальняк.
Но за само путешествие - однозначно лайк.