Комментарии 21
Как сферический конь в вакууме — это прекрасно. Непонятно только что отвечать бизнесу "когда будет готов проект/фича", особенно в больших проектах.
На практике, не получается такого понятия, как "скорость команды" в действительно больших проектах. По одной простой причине — разные члены команды обладают разной крутостью своих скиллов. Для одних задач бывают нужны soft skills, чтобы добиться чего-то от других команд, для других hard skills. В больших проектах большой разброс подсистем с которыми приходится взаимодейтствовать и у разных учатсников команды совершенно разный опыт работы с ними.
В итоге, мы имеем два выхода из ситуации:
1) Заставлять всех работать со всеми частями проекта. Так мы заранее соглашаемся со снижением максимальной продуктивности, ибо переключения контекста, да и в целом, заниматься тем, что тебе не оч нравится (иначе почему ты в этом еще не хорош?) — это дело довольно унылое и ведет к выгоранию. Но в целом, бонусы есть — в среднем компетенция у команды выравнивается: опыт показывает, что те кто были экспертами, снижают свой уровень экспертизы, ибо нет времени поддерживать тот же уровень, остальные да, что-то новое узнают. Всех выгоревших/недовольных можно уволить нафиг, но тогда не стоит рассказывать мне в статье о том, что все эти методы оценки — это вот они для счастья команды.
2) Позволить людям заниматься тем, чем они занимаются лучше всего не перебрасывая их с одной части проекта на другую. Но тогда у нас появляются риски с передачей знаний, магическими подсистемами и всем сопуствующим. Они неизбежно срабатывают и вся "скорость команды" имеет непредсказуемое значение, а потому все эти оценки в SP в целом ничего не значат. Зато разработчики довольны, ибо занимаются тем, что нравится :)
P.S.
Хватит уже, пожалуйства, впаривать работникам чудные сказки о том, что все могут быть счастливы: и работники, и бизнес. Все эти управленческие свистоперделки — они только и только про потребности бизнеса, потребности разработчика в них никто и не пытается запихнуть. Я не говорю, что это плохо. Мне не нравятся только сам факт подмены понятий.
да и в целом, заниматься тем, что тебе не оч нравится (иначе почему ты в этом еще не хорош?)
Потому что это скучная монотонная работа (формочка или другая задача, которая занимает кучу времени чисто из-за ее нудности или копание в легаси-части проекта? Потому что вам идеологически не нравится задача? Вариантов на самом деле очень много. Ну и да, причем тут "нравится или нет", если тут скорее вопрос "есть ли компетенция в этой части проекта или нет"? Получается немного подмена понятий.
Зато разработчики довольны, ибо занимаются тем, что нравится :)
Почему-то, обычно разработчики страдают от серьезной нагрузки, потому что их модуль никто другой не знает и задачи в нем может пилить только он, а так же от отсутствия отпуска, потому что даже если он в него пошел — баг в его модуле тоже только он может починить. Вообще не знаю никого, кто был бы доволен ситуацией в пункте 2.
Особенно ситуация в пункте 2 выглядит классно, когда разработчик внезапно заболевает, критически важная задача для бизнеса не сделана или критически важная бага не исправлена, а вы понимаете, что заменить разработчика за вменяемый срок (условно, до месяца) вообще некем. В итоге просто все ждут разработчика и страдают.
Все эти управленческие свистоперделки — они только и только про потребности бизнеса, потребности разработчика в них никто и не пытается запихнут
Вы отрицаете потребность бизнеса в лояльных сотрудниках? Учитывая что лояльность часто формировать дешевле, чем поднимать ЗП, что бы компенсировать ее отсутствие.
Вы отрицаете потребность бизнеса в лояльных сотрудниках? Учитывая что лояльность часто формировать дешевле, чем поднимать ЗП, что бы компенсировать ее отсутствие.
Я не отрицаю потребность бизнеса в управляемых болванчиках. Я не люблю когда мне вливают в уши, что я должен это любить.
В итоге просто все ждут разработчика и страдают.
Страдает только бизнес. Работникам, в основном, плюс/минус наплевать.
Ну и да, причем тут "нравится или нет", если тут скорее вопрос "есть ли компетенция в этой части проекта или нет"? Получается немного подмена понятий
Притом, что я разработчик :) Если задача рутинная, скучная и монотонная и я не хочу её делать, я конечно пойду её делать из под палки, но лояльность моя снизится. Вот соббсно и вся история. Все эти agile штуки ведут к уменьшению моей… ну, эффективность не то слово, скорее производительности. Я буду пилить говёную задачу "лишь бы отстали", что в последующем выльется в проблемы.
а так же от отсутствия отпуска, потому что даже если он в него пошел — баг в его модуле тоже только он может починить
Он страдает, потому что хочет страдать, очевидно. Если бы меня не отпускали в отпуск на регулярной основе, я бы просто уволился и разбирайтесь со своей проблемой как хотите.
Страдает только бизнес. Работникам, в основном, плюс/минус наплевать.
Это прям в крупных компаниях. В средних обычно страдания бизнеса выливаются, например, в сокращении расходов на офис (был кулер? Ну, теперь будет фильтр), задержке зарплаты и уменьшение лояльности бизнеса к разработчикам. Потому что цикл обратной связи от владельца бизнеса 2-3 человека и докадывается до всех. Причем самое приятное в этой ситуации то, что как бы вам нужно просто ее перестрадать.
Он страдает, потому что хочет страдать, очевидно. Если бы меня не отпускали в отпуск на регулярной основе, я бы просто уволился и разбирайтесь со своей проблемой как хотите.
Есть такая штука, называется ответственность. Бывает она, например, перед коллегами или начальством. На словах обычно все как Львы Толстые, а когда доходит до дела, то вспоминаешь, что модуль пилил только ты, он тебе как родной, а задачи на него все приходят и приходят.
Притом, что я разработчик :) Если задача рутинная, скучная и монотонная и я не хочу её делать, я конечно пойду её делать из под палки, но лояльность моя снизится. Вот соббсно и вся история. Все эти agile штуки ведут к уменьшению моей… ну, эффективность не то слово, скорее производительности. Я буду пилить говёную задачу "лишь бы отстали", что в последующем выльется в проблемы.
А кто же тогда будет делать рутинные задачи? Бедняга, который более уступчивый и в итоге потом тихо уволится? И вот тогда все эти прекрасные задачи свялятся на вас полным скопом и не уверен, что те выиграши в продуктивности, которые были получены окупятся.
Я не отрицаю потребность бизнеса в управляемых болванчиках. Я не люблю когда мне вливают в уши, что я должен это любить.
Мне интересно, почему как лояльность, так сразу болванчики? Для вас лояльность это что в духе "люби компанию и делай для нее все" или, например, то что начальник более лояльно относится к вашему графику, а вы взамен иногда по 1-2 часа на выходных уделяете работе?
Это прям в крупных компаниях. В средних обычно страдания бизнеса выливаются, например, в сокращении расходов на офис (был кулер? Ну, теперь будет фильтр
Это лишь ещё раз подчеркивает, что мы с бизнесом в разных лодках :) Чуть что не так — страдают сотрудники :) Думаете фильтр для воды, вместо кулера, будет поставлен в кабинет гендира. То-то и оно. Мы плывём может и в одной лодке, но при любой мелкой качке — вылетом с неё мы первыми, стоит об этом всегда помнить. Работодатель — не друг. И не враг. Просто способ обменять время на деньги, или удовлетворить свои амбиции и хотелки за счёт чужих денег) В конечном итоге, тот у кого ты их берешь все равно заработает на тебе много больше — и это справедливо, с учётом рисков, но это не значит, что я должен сопереживать его проблемам.
А кто же тогда будет делать рутинные задачи?
Что для кого-то рутина, для другого новый интересный мир :) Будьте честны на счёт задач при найме и будем всем счастье. К тому же, есть же люди работающие на конвейерах? Скорее всего они его ненавидят или просто равнодушны к работе. Таких много. Но никого не нужно заставлять любить рутину и говорить "смотри как классно, теперь твоя работа на половину состоит из задач, которые тебе не упёрлись, как классно, не правда ли?"
Для вас лояльность это что в духе "люби компанию и делай для нее все" или, например, то что начальник более лояльно относится к вашему графику, а вы взамен иногда по 1-2 часа на выходных уделяете работе
Причем, тут соббсно лояльность?) Мои договоренности с начальством, agile и переработки — дело мне кажется немного другого толка. К тому же, начальник в сущности тот же работник, но с другими задачами. Его бизнес интересует тоже постольку поскольку по сути, но чуть больше, чем меня, ессно.
Есть такая штука, называется ответственность
Именно. И не только меня перед работодателем, но и работодателя передо мной. Отпуск и отдых — как раз из этих вещей :) Хочет меня дергать каждый раз — будь добр переработки оплачивай и вот это всё.
Непонятно только что отвечать бизнесу "когда будет готов проект/фича".
Если фича важна, и она стоит в текущем спринте, либо в планах на ближайшие 1-2 спринта, то ответ очевиден. Если она важна, но в планах не стоит, то ответом будет предложение переопределить приоритет этой фичи в отношении других фич, которые стоят в планах. Всё это настолько просто, что уже не помню, когда наш бизнес задавал такой вопрос. Ведь планы и приоритеты у них всегда перед глазами.
не получается такого понятия, как "скорость команды" в действительно больших проектах
Работаю в действительно большом проекте: много кода, очень много интеграций с другими проектами. По-моему, чем крупнее проект, тем стабильнее общая скорость разработки. Да и на уровне команд 6-10 человек она тоже достаточно стабильна. Главное – не гонять людей между командами.
Заставлять всех работать со всеми частями проекта
Почему обязательно "заставлять". Здесь же всё логично. Надо просто объяснить. Согласен с SirEdvin – при ближайшем рассмотрении вариант 2 мало кому понравится.
впаривать работникам чудные сказки о том, что все могут быть счастливы: и работники, и бизнес
Бизнес – это тоже работники. Мы все в одной лодке. Кому-то может казаться, что если он уел коллегу, то вырос профессионально. Но это не так. Профессиональный рост – это когда мы вместе с бизнесом достигаем поставленных целей, компания растет и приносит пользу всё большему числу клиентов.
Соглашусь, что во многих крупных компаниях о целях или клиентах компании мало кто беспокоится. Решения принимаются по политическим мотивам – люди взвешивают, какое впечатление произведут на начальство, коллег и пр. Работать в таких компаниях тоскливо. Да и настоящего Agile у них быть не может.
Почему обязательно "заставлять". Здесь же всё логично. Надо просто объяснить.
Не, объяснить-то можно, желания заниматься у меня от этого не появится :)
Бизнес – это тоже работники. Мы все в одной лодке.
Не согласен. До тех пор пока бизнес может по желанию левой пятки уволить сотрудника, пока у сотрудника нет доли в бизнесе — ничего общего, кроме трудового договора у них нет.
Кому-то может казаться, что если он уел коллегу, то вырос профессионально. Но это не так. Профессиональный рост – это когда мы вместе с бизнесом достигаем поставленных целей, компания растет и приносит пользу всё большему числу клиентов.
Чем там измеряют профессиональный рост менеджеры я не знаю. Программисты обычно измеряют профессиональный рост сложностью технических задач, которые они стали способны решать. Тот факт, что способность создать стабильное, хорошо спроектировннае высоконагруженное приложение будут использовать миллионы людей, крут не потому что "смотри сколько людей это используют", а потому, что "смотри как я заставил эту железку работать!". Вот и вся история.
Решения принимаются по политическим мотивам – люди взвешивают, какое впечатление произведут на начальство
Эта история хоть и грустная, но в целом все мои сотрясения воздуха не об этом.
Я просто о том, что попытки что-то измерять в сторипоинтах на моей памяти проваливались, точно так же, как и попытки оценить что-то в часах.
Пассаж про запудривание мозгов — он вообще параллелен сторипоинтам. Это просто заметка о том, что в каждой статье как мантру повторяют, что все эти алжайлы и прочее — это ведь не только бизнесу, это нужно больше всего мне самому. Я так не считаю.
Не согласен. До тех пор пока бизнес может по желанию левой пятки уволить сотрудника, пока у сотрудника нет доли в бизнесе — ничего общего, кроме трудового договора у них нет.
По желанию левой пятки уволить сотрудника, а потом опять выходить на рынок и несколько месяцев искать нового человека, терпя убытки от нереализованных задач. Какой-то странный бизнес.
Программисты обычно измеряют профессиональный рост сложностью технических задач, которые они стали способны решать. Тот факт, что способность создать стабильное, хорошо спроектировннае высоконагруженное приложение будут использовать миллионы людей, крут не потому что "смотри сколько людей это используют", а потому, что "смотри как я заставил эту железку работать!"
Эм… а что не так то с "смотри сколько людей это используют"? Мне вот, как программисту такое тоже нравится.
Пассаж про запудривание мозгов — он вообще параллелен сторипоинтам. Это просто заметка о том, что в каждой статье как мантру повторяют, что все эти алжайлы и прочее — это ведь не только бизнесу, это нужно больше всего мне самому. Я так не считаю.
А как бы вы хотели вести разработку, в духе "Просто пиши код"? Когда все просто пилят, пилят, пилят без конца и края?)
Так, мне ща в самолёт, так что нет времени ответить полностью.
Я не против, в целом, организованной работы. Бардак явно хуже. Не против и agile, наверное, в целом (хотя в этом не уверен). Я просто против того, чтобы меня заставляли любить кнут в том или ином виде.
Аgile в некотором смысле, самый худший из всех кнутов. Его задача выжать меня как лимон и выбросить :) А т.к. знания в среднем распределены по команде, теперь надо просто взять следующий лимон. Может я просто не хочу быть эффективнее, чем я есть, меня лично все устраивает.
Заставлять всех работать со всеми частями проекта.
Для этого нынче придумано еще одно модное слово — кроссфункциональность. Его пришлось придумать потому, что «и жнец, и швец и на дуде игрец» имеет четкие негативные коннотации, и продвигать его, как благо для разработчика, которому он должен радоваться, почему-то не получается.
Кроссфункциональной должна быть команда, а не разработчик. Т.е. включать всех специалистов, необходимых для того, чтобы довести задачу до конца.
Говоря о "жнеце", Вы, наверное имели в виду понятие Т-специалиста, т.е. человека, у которого есть основная специализация, в которой он работает бОльшую часть времени, но он не отказывается при реальной необходимости выполнить и другую работу, которую знает, как делать. Например, Java-программист не отказывается написать простой SQL-запрос, если у разработчика БД перегруз или он заболел. Понятие Т-специалиста часто извращают, говоря о том, что тестировщики будут программировать, а программисты вместо них тестировать. На самом деле речь идет лишь о том, что все болеют за общее дело и выручают друг-друга при необходимости.
Ни первое, ни второе понятие не имеют отношения к обсуждаемой в данной ветке темы о том, что все программисты работают над всеми частями проекта.
Здесь речь скорее о таком аджайл-понятии как совместное владение кодом. Оно подразумевает, что любой разработчик может вносить изменения куда угодно. Нет строгого закрепления кода за разработчиками. Что не отменяет, однако, существования "владельцев" отдельных компонент, которые должны помогать новичкам погрузиться в компоненту, за которую ответственны, ревьювить код для неё от других разработчиков, следить за целостностью, соблюдением внутренней архитектуры и т.п.
но на Story Point'ах план проекта не построишь. Часто у руководителя проекта возникает вопрос: „Как перевести SP в часы?“.
Короткий ответ на этот вопрос: „Никак“.
Так в чём же суть статьи, если кратко? Чем надо пользоваться? Я, как разработчик и начальник отдела — не понял, где улучшение ситуации.
Срок выполнения задачи устанавливает либо заказчик (это плохо, но можно договориться), либо он ставится исполнителем, исходя из своего опыта, и не оспаривается. три недели — значит три недели.
- Считаем историческую скорость (velocity) разработки команды в стори-поинтах за спринт. Если состав команды не менять (и его лучше не менять), то цифра со временем станет достаточно стабильной.
- Оцениваем предстоящий объем работ в тех же стори-поинтах.
- Делим второе на первое – получаем количество спринтов, за которое объем предположительно будет выполнен.
На ближайшие 1-3 спринта план получается весьма реалистичный, но по окончании каждого спринта его надо перерасчитывать, адаптировать, следить за динамикой, при необходимости либо сдвигать сроки, либо договариваться с заказчиком о сокращении объема работ.
Так как начинаем с наиболее важных задач, под гонец остаются неважные, ими легче пожертвовать, если не уложились в срок.
А вы не могли бы пояснить вот это?
Как перевести SP в часы?“.
Короткий ответ на этот вопрос: „Никак“.
…
Что действительно важно, так это сколько SP команда разработки может „закрыть“ за спринт (итерацию, релиз).
Разве это не одно и то же? Ну, перевели SP не в часы, а в спринты фиксированной продолжительности. В чем разница?
Ведь время, затраченное на задачу в 3 SP не всегда и не обязательно будет в три раза больше времени, затраченного на задачу в 1 SP. Да, группировка задач в итерации отчасти помогает взаимно нивелировать эти перекосы, но все равно оценки разных команд могут и будут отличаться. Это может быть очевидно Вам, но совсем не очевидно другим.
Что важно, так это наладить общее понимание того, как происходит процесс оценки и что является итоговым результатом этого процесса между командой разработки и менеджерами. Это и было целью статьи, которая изначально была создана в виде интерактивного урока и используется внутри компании в курсе онбординга новых руководителей проектов и разработчиков.
Посмотрите вот эту ветку обсуждения о разбивке фич на стори и дальнейшем дроблении сторей так, чтобы они влезали в спринт.
Строго говоря, нельзя брать в спринт сторю, которая заведомо в нее не влезает. Надо дробить. А по мере дробления появляется и ясность, и приемлемая точность оценки.
Большие фичи желательно обсуждать и дробить заранее, а не на планировании спринта. Команда (или её часть) может собираться на так называемые PBR (product backlog refinement) митинги, где обсуждает и прорабатывает верхушку беклога, проясняет требования, дробит задачи, создает новые, реприоритезирует старые и т.п.
Утверждение 1:
Часто у руководителя проекта возникает вопрос: „Как перевести SP в часы?“.
Короткий ответ на этот вопрос: „Никак“.
Утверждение 2:
Что действительно важно, так это сколько SP команда разработки может „закрыть“ за спринт (итерацию, релиз).
Мы не можем перевести сторипоинты в часы, но может перевести в 40-часовую рабочую неделю. Т.е. в итоге переводим в часы.
Оценка задач в Story Points