У каждого тимлида есть своё кладбище сотрудников управленческих ошибок. Каждый день публикуются новые статьи «5 ошибок начинающего разработчика», «7 примеров того, как не надо управлять процессами», «100 и 1 способ укладываться в сроки». И это круто!
Чужие грабли экономят ваше время, делают вас смелыми, похлопывают по плечу и наглядно дают понять, что не один вы такой «я сделяль», и все это проходили.
Ошибка по Ожегову – это неправильность в мыслях или действиях, а, возможно, и одновременно. А как же обойтись без них новичку с новым кругом обязанностей? Пожалуй, никак, но можно постараться смягчить удары. На своем примере я расскажу о тех ошибках, которых мне не удалось избежать в процессе становления меня как лида. Надеюсь каждая история тебя либо улыбнет, ведь ты вспомнишь себя в детстве начале своего пути, или же заставит задуматься над тем, а как же не наступить на подобные грабли самому.
Предыстория
Последние 6 лет я посвятила тестированию, сменив несколько компаний, команд с целью получить актуальные и уверенные знания о том, как создавать качественный продукт, и какую роль в этом процессе могут играть тестировщики-инженеры. Иногда причиной ухода становилось отсутствие возможности обучаться у сильных коллег тестировщиков (а это необходимо в самом начале пути), ведь их просто не было. Опробовала свои силы как в ручном, так и в автоматизированном тестировании. И именно после того, как я прокачалась в автоматизации, мне представилась возможность попробовать себя в роли лида тестировщиков с опытным Agile-коучем.
Для меня словно мир перевернулся в тот момент. Привычка предлагать решения и самостоятельно их реализовывать окрепла и не хотела меня покидать. Оказалось, что стиль работы инженера-автоматизатора никак не вяжется с новой ролью руководителя небольшой группы людей. Перейдем к деталям.
Ошибки
№1 Менеджер «Здесь и сейчас»
У меня лучше получалось решать точечные вопросы «здесь и сейчас», но это не всегда приближает команду к заявленной цели.
Рассмотрим пример. В самом начале становления нового формата QA в Dodo, познакомившись с тем как устроено тестирование и желанием всех начать автоматизацию еще вчера, я решила, что ее нужно начать в ближайшее время. (О том как мы меняли процессы можно узнать из доклада «Алиса в стране QA») Нам всем очень хотелось избавить ребят от ежедневной рутины ручного регрессионного тестирования на 9 странах.
Следуя принципу «решаю проблемы здесь и сейчас», мы организовали встречу с тестировщиками, составили карту действий, расставили приоритеты, выделили каждому тестировщику время на автоматизацию и приступили к реализации задач с карты. Первым делом определились с инструментом и представили свой план ускорения регресса на общем собрании ИТ. Тестировщики радовались появившимся тестам и верили в скорое избавление от ручной рутины.
Однако, оказалось, что мы покрыли тестами то, что съедало много времени тестировщика, но при этом практически никогда не менялось разработчиками и слабо влияло на процессы бизнеса.
Что делать? Советы Кэпа
Глубже разбираться в проблеме, искать причины, а не следствия. Велика вероятность, что ваши ожидания того, что именно тестировщики – это основной кладезь знаний о системе с точки зрения пользователя, сильно завышены. Стоит позвать на первые собрания разных представителей ИТ компании, попросить помощи с фасилитацией встречи у scrum-мастера, предварительно обговорив с ним, какой результат ты хотел бы получить.
№2 Менеджер «Опытный инженер»
Второй мой фейл – это «шапка» опытного инженера. Все самые сложные задачи попадали ко мне.
Формирование PageObject, реализация базового набора методов для работы с нашей системой, скрипты запуска в CI/CD – всё это я по привычке решила взвалить на себя. Не стала я делегировать и коммуникацию с продуктовыми командами, инженерами инфраструктуры, и собеседования, и тексты вакансий. По словам наставника, наша QA команда была «зеленой» (новички) во всех смыслах. Разумеется, я решила сначала обучить ребят тому, что знаю сама, наблюдая за их работой, чтобы со временем делиться своими задачами.
Проблема в том, что с тем количеством встреч (общие встречи, командные встречи, внутреннее обучение, 1&1, собеседования, тестовые дни), что свалились на мои плечи, я перестала укладываться в рабочее время со своими задачами. Восьми часов в день не хватало, и я начала это компенсировать свободным временем, которое тратила на кодинг, тексты, подготовку к собеседованиям с кандидатами. Остатки драгоценных часиков я проводила с ребятами в паре с целью обучения и постепенного развития проекта с автотестами. Мое переключение контекста каждый час-два замедляло нас по всем фронтам: автоматизация, коммуникации QA c командами и прочее. Низкие темпы становления крутых QA-инженеров и автоматизации процессов приводили к тому, что и на выходных я работала, чтобы сделать пятилетку за пару месяцев.
Что делать? Советы Кэпа
Не бойтесь делегировать задачи. У всех есть право на ошибку и не стоит его отбирать, как бы тебя ни гипнотизировали лиды других команд или наставник, не ведись. Твои ребята должны сами захотеть доверять тебе и следовать за тобой, всегда экспериментируй. Соберитесь вместе, определите то, какие из процессов можно улучшить, кто из ребят готов их продвигать, а возможно некоторые из них можно передать за пределы вашей команды. Опытный фасилитатор поможет сделать так, чтобы выбранные совместно решения не остались только на бумаге. Самостоятельная эффективная команда – это то, к чему должен стремиться каждый руководитель.
№3 Менеджер «Обратная сторона микроменеджмента»
Еще одной из ошибок часто является микроменеджмент. Мне пришлось столкнуться с ее обратной стороной – неявный жесткий контроль.
Стараясь избегать слежки за каждым шагом ребят и ограничения фронта работ, я начала «навязывать» ребятам их «безграничные» возможности: планы развития, исследовательские задачи, выступления, курсы, организация митапов, походы в гости к другим компаниям и прочие активности. Намерения благие – обучение, прокачка и оттачивание навыков, расширение кругозора, новые знакомства в профессиональной сфере. Это же все то, чего мне так не хватало, когда я начинала работу тестировщиком. Проблема в том, что команда хочет право выбора: выступать или нет, смотреть или нет, а я же загнала их в жесткие рамки.
– Ребята, мы делаем митап. Нам нужны следующие роли, подарки, будут вот такие докладчики. Без вашей помощи мы не сможем сделать запоминающееся мероприятие.
– Ребята, в декабре будет Heisenbug. Я уже заказала онлайн-трансляцию для нас, забронировала переговорку, а в субботу транслирую с домашнего компьютера. Все за?
– Ребята, мы на этой неделе идем в гости в компанию «Одноклассники» знакомиться с тем, как у них построена автоматизация.
Данные возможности воспринимались как рамки-ограничения, которые все так не любят. Моя инициатива выглядела безальтернативной, а главное она была не настолько эффективной, как ожидалось.
Что делать? Советы Кэпа
Излишняя забота о ребенке приводит к тому, что он вырастает инфантильным или начинает делать все наоборот назло родителям. Похоже, так можно сказать и о заботе руководителя о своей команде. Мотивируй, а не заставляй, собери встречку на тему «Как нам расширять свой кругозор в IT?» и внимательно слушай коллег, не начинай с порога называть все способы, что тебе известны. А главное не бегай за своими коллегами с предложением выступить на конференции и попасть на интереснейший мастер-класс. Объяви о возможности – этого будет достаточно.
№4 Менеджер «Везде так делали»
Возможно, какие-то из решений, сработавших у тебя раньше в другой команде/компании, не найдут поддержки в новых условиях и реализована будет идея коллеги, далекого от области тестирования ПО, но крутого в разработке. Аргументация, что твое решение поддержали и продолжают активно развивать уже на базе сообщества, вряд ли убедит кого-то сделать также, но на местном стеке технологий.
Что делать? Советы Кэпа
Главное не начать себя угнетать тем, что твои профессиональные навыки и знания ставятся под сомнение и никак не учитываются при принятии решений. Либо ищи достойные аргументы, которые найдут поддержку у команды, либо согласись с командой.
№5 Менеджер «Истеричка»
Важную роль в процессе становления тебя как профессионала/мастера своего дела играет наставник. Но есть один нюанс, твое восприятие помощи наставника. Если между вами недоверие друг другу, то эффект от совместной деятельности вряд ли порадует и команду, и всех вокруг.
Советы, рекомендации, подчеркивание сильных и слабых сторон принятых решений – это основная ценность работы с учителем для меня. Однако, часто коучи используют другой формат обучения: они без предупреждения организуют тебе сложную ситуацию, например, конфликт в команде на почве выбора технологий, умывают руки и наблюдают за твоими действиями. Для меня все закончилось тем, что проект с автотестами стал ответственностью команд разработки из-за высокого порога вхождения, на котором настаивал коуч. Данный расклад всех устраивает, и продолжать битву за простоту было бы бессмысленно.
Что делать? Советы Кэпа
Важно будет усвоить такой момент: крики, бросание бумаг, удаление кода друг друга, презентация тобой и наставником разных видений стратегии и тактических шагов, слезы – не помогут. Так вы лишь затянете процесс приближения к цели, а возможно будете постоянно откатываться назад, ведь с вами будут бояться иметь дело, сидеть на одном этаже, сомневаться в здравости ваших идей. Попробуй не принимать быстрых решений, разберись, зачем коучу нужен был этот конфликт, в чем ты слаб и как разрулить ситуацию не взрываясь по пустякам.
Подведем итоги
Выше я описала 5 моментов слабого менеджмента от опытного инженера-автоматизатора. С трудностями, описанными выше, можете столкнуться и вы, и лишь от вашей подготовленности, характера зависит то, насколько успешной будет твоя битва и насколько сплоченной и сильной станет твоя команда. Моя же история завершилась достижением поставленной цели.
Тестировщики сейчас являются частью Dev-команд, ребята весьма самостоятельны и способны сами принимать решения по технической реализации, сотрудничеству с другими командами. Они самостоятельно пишут скрипты, отбирают новых ребят-тестировщиков, проводят митапы и многое-многое другое. Да, мы шли к этому больше года, но никто не обещал, что управление людьми – это легко.
Комментарии (272)
to_climb
14.06.2019 19:46+1Однако, оказалось, что мы покрыли тестами то, что съедало много времени тестировщика, но при этом практически никогда не менялось разработчиками и слабо влияло на процессы бизнеса.
И где тут ошибка?
Тестировщиков освободили от рутины — профит (больше времени на полезные задачи, выше мотивация). Регрессионные тесты они как раз про то, чтобы не сломать случайно в будущем что-то давно и хорошо работающее и не терять деньги от простоя — профит для бизнеса.
Am0ralist
15.06.2019 10:53Вот да, когда нам разработчики (сторонние) присылали на тест новую версию программы моделирования мебели вторым делом (после проверки заявленных изменений и исправлений) я начинал строить обычную модель стремясь найти моменты, которые они могли поломать там, и от проверки этого было никуда не деться, так как это программисты могут считать, что ничего не затронули из старого, а мой опыт говорит обратное)
И да, я не был тестировщиком в полном смысле этого слова.
taliban
16.06.2019 16:15Выгодней покрывать тестами смежные задачи, они чаще ломаются при добавлении нового функционала. Это не исключает того что не надо покрывать все остальное, но выбор время/функционал надо четко прогнозировать. Шанс поламать смежный функционал выше, значит его чаще будут проверять, шанс поламать какой-то отдельный функционал ниже, значит его будут реже проверять.
balexa
14.06.2019 20:11+3Тестировщики у вас тоже работают день бесплатно, а в случае трудоустройства две недели должны мыть туалеты в Сывтывкаре? Или этот опыт только для разработчиков?
JuliaYuka Автор
15.06.2019 15:22Откуда у вас такая странная информация? У нас действительно есть стажировка на базе пиццерии или учебного центра. Однакээ
JuliaYuka Автор
15.06.2019 15:29Однако стажировка состоит из разных этапов реальной работы сотрудников пиццерий. Про гембу и её пользу мы уже ни один раз писали.
Jeen99
16.06.2019 12:22Это шутка такая или действительно жизненный опыт?
balexa
17.06.2019 10:52-2Это обязательное требование для всех разработчиков, придуманная неадекватным создателем додопиццы. Дескать вы не сможете писать правильный код, если вначаре не поработали в сывтывкаре мойщиком туалетов, кассиром и тестомесом.
додо-пицца в свое время преподносила это как большой бонус, рнассказывали про гембу, ее пользу, кайдзен, дао и прочую ахинею. Сейчас это уже перестали афишировать, но пока все еще рассказывают почему вначале надо работать бесплатно на них, а потом ехать в сывтывкар месить тесто и убирать мусор со столов, и какая от этого большая польза.
MooNDeaR
14.06.2019 21:33+4Господи, как я вас всех ненавижу :) Тимлиды с аджайл-коучами и фасилитаторами. Да пропади вы все пропадом!
Я пришел в программирование, чтобы решать технические задачи и радовать пользователя новыми фичами, а сейчас трачу 30% времени рабочего на то, чтобы играть в передвижение гребанных квадратиков по доске, митинги, и прочую дичь. А самое главное — все самые важные проблемы решались просто разговором с нужным человеком, живым ли или перепиской — не важно. Без необходимости отвлекать остальную команду от их дел.
Как достала уже вся эта эффективность вокруг. Все кругом эффективные. Все вокруг полезные. Только софт всё хуже и хуже, а мир все бесчеловечнее.
teemour
14.06.2019 23:38+1дело в том что это твоё представление и, возможно, «нужного» человека, а создание продукта это коллективный труд
понятно что каждый специалист хочет делать то что сочтёт нужным за деньги работодателя, но, слава богу, аджайл-коучи нашли решение против этого хаоса
Apathetic
14.06.2019 23:54+1Подобное "решение технических задач" и "радование пользователя новыми фичами" может быть действительно успешным, только если вы работаете в одиночку. Когда в процессе участвует больше одного человека — людям нужно уметь организовываться (или уметь помогать их организовывать), иначе есть большой риск зафейлить выпуск продукта — как по качеству, так и по срокам.
Как бы вам ни хотелось жить в своём розовом мире, в котором "тимлиды с айджайл-коучами и фасилитаторами" не нужны, факты остаются фактами — люди в большинстве своём самоорганизовываться не умеют, и им нужно помогать.MooNDeaR
14.06.2019 23:59-2Я и не отрицал необходимость руководства. Просто конкретно двиганье квадратиков по канбан-доске и ежедневные митинги — это полнейшая херня, а ее руководство. А именно этим занимаются 90% менеджеров, что я видел, а сотрудники уж вынуждены коммуникации выстраивать как-то сами. А те, что не страдали херней — не страдали бы ею и без аджайла. Классический waterfall, к слову, не так уж и плох для подавляющего большинства проектов с конечным сроком жизни. Тем не менее, аджайл модно, поэтому каждый божий день приходится сидеть и страдать какой-то и считать сторипоинты в попугаях...
Apathetic
15.06.2019 00:10+2"Двиганье квадратиков" и "сторипойнты в попугаях" (кстати, в попугаях, то есть неких абстрактных единицах — это гораздо правильнее, чем в часах, например) позволяют планировать и прогнозировать, то есть делать то, с чем, скажем так, "традиционные" методы разработки, типа того же waterfall, не справляются от слова никак.
MooNDeaR
15.06.2019 00:18То, что у waterfall нет терминологии для описания скоростей и проблем, а также для процесса перепланирования не означает, что эти процессы и оценки невозможны :) Ну, вот видишь ты, что никак не успеваете по плану, приходишь и говоришь о проблеме — и начнется абсолютно тот же процесс, что и при великом аджайле.
По поводу сторипоинтов в попугаях — полная чушь. Просто невероятный идиотизм. Никогда не видел, чтобы хоть кто-то оценил этих попугаев правильно. Реально, обычно каждый разработчик вырабатывает для себя некий способ конвертации часов в попугаи и просто им пользуется. Например, считает, что 16 рабочих часов == 1 попугай. Так и живем :)
Apathetic
15.06.2019 00:33+2не означает, что эти процессы и оценки невозможны
Дело не в терминологии вовсе. Дело в отсутствии физической способности корректно, достоверно и надежно распланировать проект на месяцы вперед.
Просто невероятный идиотизм
Трудно спорить с подобным attitude, поэтому даже пытаться не буду. Попробуйте самостоятельно разобраться с тем, что такое стори-пойнты (хороший старт даст это видео — https://www.youtube.com/watch?v=Gxf76eGyG5c&list=PLngnoZX8cAn-9tWYxyQQPGoHW7DETBCjK&index=5), а главное — зачем они нужны.
MooNDeaR
15.06.2019 00:41корректно, достоверно и надежно
Будто бы аджайл может сделать это. Дай бог там прогнозы на месяц сбываются.
Трудно спорить с подобным attitude
Вы правда считаете, что если употребить английское слово, вместо прямого и однозначного перевода вы будете выглядеть умнее?
Попробуйте самостоятельно разобраться с тем, что такое стори-пойнты
Я в курсе, что это такое. А еще в курсе, что абсолютно все известные мне программисты ложили болт на это и используют конвертацию в часы работы.
Apathetic
15.06.2019 01:10+1Будто бы аджайл может сделать это.
Я разве это утверждал?
вы будете выглядеть умнее?
Зачем вы додумываете за меня?
Я в курсе, что это такое.
Что?
абсолютно все известные мне программисты
Абсолютно все известные мне программисты, понимающие, что такое SP, и зачем они нужны, умеют ими грамотно пользоваться, не занимаясь абсурдным переводом в часы.
Говнокод, приложения, жрущие ОЗУ гигабайтами
Странно, что Вы вините в этом руководство. Код же пишете Вы, а не менеджеры? Или не Вы? В таком случае вопросов нет.
Эффективность — это не просто слово. Эффективность — это доставка фичи до клиента в сроки, за которые эта фича не теряет актуальности и позволяет бизнесу заработать персонально Вам на зарплату. Если Вам плевать на эффективность и хочется просто "получать удовольствие" — вероятно, Вы зря занимаетесь коммерческой разработкой.
MooNDeaR
15.06.2019 01:33Я разве это утверждал?
Если нет, тогда я не понял, к чему вообще была фраза про наличие инструментов для предсказания сроков.
Зачем вы додумываете за меня?
Затем, что никаких предпосылок не сделать этого я не нашел? Если есть объяснение получше, я бы выслушал.
Абсолютно все известные мне программисты, понимающие, что такое SP, и зачем они нужны, умеют ими грамотно пользоваться, не занимаясь абсурдным переводом в часы.
Абсурдны сами сторипоинты :) Даже если взять ваше же видео. В нём п.2 говорит "используйте объективные оценки". Дело в том, что время объективно. Если задача не сформирована по принцицу "оцените время, когда всё будет хорошо?", а по принципу "сколько времени вам понадобится для добавление кнопки в меню выбора языка", то все сторипоинты нафиг не нужны.
Забавно также, насколько абсурден ключ №3 предлагаемый авторов видео, который приводит в пример тот факт, что расстояние между двумя городами можно оценить как "2 раза проехать до города посередине". Это порождает логичную проблему "а сколько ехать до города посередине?" и в итоге всё снова сводится к часам. Так зачем заниматься этой попугайщиной, если можно просто правильно формулировать вопросы?
Странно, что Вы вините в этом руководство. Код же пишете Вы, а не менеджеры? Или не Вы? В таком случае вопросов нет.
А почему мы его так пишем? Не потому ли. что такой код дешевле и тупо нет времени подумать над более оптимальным решением?
Я еще раз повторюсь, я отлично понимаю как работает бизнес и почему всё так, как есть. Почему дешевые решения лучше хороших, почему существуют все эти методики повышения этой самой эффективности. В конце концов, я ж не тупой) Просто это совсем не отменяет того факта, что всё это дерьмо убило всю прелесть профессии, сделав из настоящих инженеров обезъянок по набору эффективного говнокода.
Если Вам плевать на эффективность и хочется просто "получать удовольствие" — вероятно, Вы зря занимаетесь коммерческой разработкой.
К большому несчастью, выбора-то нет. Или быть эффективным, или просить милостыню. Поэтому я эффективен до усрачки, не помню, чтобы хоть раз кто-то выражал недовольство моей работой. Просто не обязан любить всё это дерьмо.
Apathetic
15.06.2019 01:43+1Я прошу прощения, что приходится разжевывать азы, но нет, ничего не сводится к часам, потому что сторипойнты нужны не для того, чтобы понять, сколько будет делаться одна конкретная задача. Сторипойнты в скраме нужны для того, чтобы понимать скорость работы команды, и, уж простите, но очевидно, что Вы этого НЕ понимаете.
Если Вы будете измерять задачи часами, то Вы, во-первых, будете делать это некорректно, потому что временные затраты — это только часть оценки. Во-вторых, Вы не сможете понять, сколько задач в действительности может сделать команда за один спринт. Следовательно, Вы не можете прогнозировать.
Что касается Вашей персональной эффективности, кто я такой, чтобы в ней сомневаться. Но позволю себе спросить — в чем именно Вы её измеряете? Как Вы понимаете, что Вы эффективны? Почему Вы думаете, что не можете быть еще эффективнее?
MooNDeaR
15.06.2019 02:19+1Сторипойнты в скраме нужны для того, чтобы понимать скорость работы команды
А как понимать скорость работы команды в сторипоинтах? Какая разница между "ну, мы можем сделать эту задачу за 3 дня" и "это займет 3 сторипоинта"?
что Вы этого НЕ понимаете.
Признаться, я действительно вас не понимаю, потому что пояснения к своей точке зрения даю только я. Если вы объясните мне в чем я конкретно не прав, быть может это будет более продуктивно.
временные затраты — это только часть оценки.
Что-то я не очень понимаю, что является другими частями оценки в вопросе "когда будет готова фича?"
Во-вторых, Вы не сможете понять, сколько задач в действительности может сделать команда за один спринт.
Сторипоинты не проясняют ситуацию ни на йоту. Я не помню ни одного случая, чтобы это работало. Понятные задачи, которые легко оценить в часах, делаются в срок. Задачи, которые невозможно оценить в часах — никогда не делаются в срок. Вот и вся история. Дайте мне какой-нибудь живой пример, который убедит меня в обратном.
Как Вы понимаете, что Вы эффективны?
Достаточно просто — меня не увольняют и не собираются, насколько мне известно. Мне платят выше рынка, в конце концов. Не помню ни одного плохого отзыва о своей работе в анонимной оценке, проходящей в компании раз в год.
Почему Вы думаете, что не можете быть еще эффективнее?
Почему не могу? Могу :) Но я уже несколько раз упомянул, что мне вся эта эффективность поперёк горла, т.к. она измеряется в вещах, которые интересны бизнесу. Персонально мне нет никакого резона быть эффективнее))) Забавно то, что "эффективность" и заработок вещи хоть и коррелирующие между собой, однако зависимость у них далеко не линейная, а скорее логарифмическая)
GrigorGri
15.06.2019 04:14Сторипоинты выглядят логичнее на уровне члена команда. Пусть джун делает 0.5 поинта в часа, синиор 2 поинта.
Считать что синиор делает 2 часа в одном звучит странно.Druu
15.06.2019 04:25Пусть джун делает 0.5 поинта в часа, синиор 2 поинта.
Считать что синиор делает 2 часа в одном звучит странно.На уровне членов команды каждый член команды дает свою собственную оценку в часах и тогда все ок.
Стори поинты проблему никак не решают, т.к. то, что Вася делает задачу Х вдвое быстрее Пети, не значит совсем, что он вдвое быстрее делает все задачи. Просто (в подавляющем большинстве случаев) у него выше экспертиза как раз в этой области Х. А в области Y будет другая ситуация.
Вообще, к слову, сторипоинты могут иметь смысл — но как оценка полезности задач. То есть, оценивают пользователи, в процессе кардиналистского голосования, а не разработчики.
0xd34df00d
15.06.2019 23:27Лол, у нас в приступе самого аджайло-ада решили играть в кросскомпетентную команду, и типа оценки более не привязаны к людям (равно как и задачи). После того, как я оценил что-то на плюсовых темплейтах в один SP, а задача досталась человеку, который хорошо строит модели, но не умеет в плюсы, получилось, ну… короче, решили больше так не делать.
Но я не понимаю, что вообще должно быть в голове, чтобы такая идея даже в голову пришла.
Druu
16.06.2019 04:47После того, как я оценил что-то на плюсовых темплейтах в один SP, а задача досталась человеку, который хорошо строит модели, но не умеет в плюсы, получилось,
Ну это вообще откровенная наркомания, когда задача с оценкой Х достается человеку, несогласному с этой оценкой.
MooNDeaR
15.06.2019 09:47+1Что значит это сторипоинт, кроме как маркер отображающий что сеньор в 4 раза круче джуна? Как это поможет в планировании?
Возьмем ситуацию: в команде есть сеньор (2 СП/спринт), миддл (1 СП/спринт) и 2 джуна (0,5 + 0.5 = 1 СП/спринт).
Прилетает задача реализовать новую фичу, скажем, поддержку формирования графиков в системе отчетности, в которой этих графиков отродясь не было.
Её сложность нужно оценить в стопипоинтах. Приведите мне в пример порядок действий и порядок мыслей, как мне оценить задачу не в часах, а сразу в СП.
akryukov
15.06.2019 11:18Что значит это сторипоинт, кроме как маркер отображающий что сеньор в 4 раза круче джуна?
Что значит молоток, кроме как инструмент для забивания гвоздей?
Как это поможет в планировании?
Это поможет примерно оценить сколько времени займет выполнение задачи конкретным сотрудником. Задача в 1 стори пойнт джуном со скоростью 1 СП/спринт будет пилиться 2 спринта. Хотя обычно 1 СП ~ 1 час мидла.
Приведите мне в пример порядок действий и порядок мыслей, как мне оценить задачу не в часах, а сразу в СП.
Чтобы так оценивать, нужна эталонная известная задача. Сторипойнтами удобно оценивать типовые фичи.
Если же задача совершенно новая и аналогов не имеет, то оценивается ее предполагаемая сложность.
Например для тех же графиков можно посмотреть в документацию инструмента. Если используете какую-то платформу отчетности, то наверняка есть возможность делать графики.
Если пилите свой велосипед, то оцениваете сложность как для другого похожего велосипеда когда вам нужно было что-то на фронте изобразить.MooNDeaR
15.06.2019 11:36Хотя обычно 1 СП ~ 1 час мидла
Мне тут только что втирали про то, что переводить СП в часы — это неправильно. Без часов пожалуйста.
Это поможет примерно оценить сколько времени займет выполнение задачи конкретным сотрудником.
Ни разу не помогало, при условии, что оценку сложности делал один, а исполняет совершенно другой человек.
Задача в 1 стори пойнт джуном со скоростью 1 СП/спринт будет пилиться 2 спринта
У нас новую арифметику завезли? Иначе где логика?)
Чтобы так оценивать, нужна эталонная известная задача.
Что такое "эталонная известная задача". Неужели такое существует? Эталонная известная задача — это задача которую каждый из сотрудников решал в одинаковых условиях независимо от своих коллег, а вы в это время сидели с таймером рядом и измеряли (лол) за сколько часов её сделал каждый из них. В итоге снова всё конвертируются в часы и зачем мне тогда сторипоинты?
akryukov
15.06.2019 12:17Мне тут только что втирали про то, что переводить СП в часы — это неправильно. Без часов пожалуйста.
Я был не прав. В часах действительно неправильно считать. Но 1 СП/спринт тоже нереально. 1 СП это какая-то типичная простейшая эталонная задача. Где вы видели, чтобы простейшие задачи по 2 недели только разрабатывали?
Ни разу не помогало, при условии, что оценку сложности делал один, а исполняет совершенно другой человек.
Потому и не помогало, что оценивал один а делал другой. Оценку сложности делают совместно. При этом договариваются до какой-то одной оценки путем обоснования минимального и максимального. Что то вроде:
- Почему ты 5 СП, когда все сказали 3?
- Потому что тут вылезет вот такая проблема, про которую все забыли.
- Коллеги, ваша оценка изменится от этого факта?
- Да, если это учитывать, то 5 СП.
У нас новую арифметику завезли? Иначе где логика?)
Действительно опечатался. Имел в виду скорость джуна 0,5 СП/спринт.
Что такое "эталонная известная задача". Неужели такое существует?
Когда вы на поддержке какого-то определенного набора похожих продуктов, то существует. Допустим заказчики захотели фичу в продукте 1, вы ее сделали. Потом они ее просят в продукте 2-5 и вы знаете сколько времени ее делать. Причем знаете индивидуальное время каждого специалиста.
В итоге снова всё конвертируются в часы и зачем мне тогда сторипоинты?
В итоге получаются не просто часы, а часы конкретного сотрудника. Как вы с оценкой часами опишете ситуацию, когда опытный может делать за 2 часа, а неопытный за 4?
Druu
15.06.2019 14:14В итоге получаются не просто часы, а часы конкретного сотрудника. Как вы с оценкой часами опишете ситуацию, когда опытный может делать за 2 часа, а неопытный за 4?
Так у каждого сотрудника в любом случае своя оценка (хоть в часах хоть в SP). Просто не надо среднюю оценку брать, а так и оставлять, списком оценок.
Apathetic
15.06.2019 19:37Нет, потому что оценивающий не оценивает задачу саму по себе, а сравнивает её с уже выполненными и оцененными. Мало кто может навскидку сказать, сколько весит слон, но определить, во сколько примерно раз он больше бегемота, способен практически любой.
Druu
16.06.2019 04:52Мало кто может навскидку сказать, сколько весит слон, но определить, во сколько примерно раз он больше бегемота, способен практически любой.
Но вес — это вполне понятная числовая характеристика. Штука в том, что вы не можете сравнивать сложность, не переведя ее в какую-то числовую характеристику, мозг так не работает.
Так что, на самом деле, абсолютно все при оценке сторипоинтов делают такой перевод. Это не обязательно часы — могут быть строки кода или другие единицы, но главное, что они те, которые поддаются измерению. А сложность неизмерима, по-этому сложность задач саму по себе нельзя сравнить численно. Можно сказать что "задача Х сложнее, чем Y", но нельзя сказать, что она сложнее в 2.5 раза.Apathetic
16.06.2019 09:23+1абсолютно все при оценке сторипоинтов делают такой перевод
Это абсолютная неправда. Если лично Вы не понимаете, как обходиться без этого, это не значит, что остальные, да еще и все, тоже не понимают.
Druu
17.06.2019 05:03Это абсолютная неправда.
Это правда, потому что мозг иначе не может получать численные оценки.
Скажите пожалуйста, когда вы говорите, что одна задача 2 сторипоинта, а дургая — 6, то чего именно в этой второй задаче втрое больше и почему именно втрое, а не в 2.5 раз? То есть — как и что вы измерили?
Apathetic
17.06.2019 18:52Говорите за себя оО
Когда я говорю, что одна задача 2 сторипойнта, а вторая 6 (хотя мы, как правило, пользуемся рядом фибоначчи, но это не суть), это значит, что первая задача очень похожа на множество задач, оцененных в 2сп, а вторая — на множество задач, оцененных в 6сп. Мы не измеряем, мы сравниваем. Как только вы перестанете пытаться измерять задачу, что действительно невозможно, и начнете сравнивать — у вас всё получится.
Druu
18.06.2019 04:24это значит, что первая задача очень похожа на множество задач, оцененных в 2сп, а вторая — на множество задач, оцененных в 6сп.
А откуда берется множество задач, оцененных в 6? Каким образом в 6сп была оценена первая задача, оцененная в 6сп?
То, о чем вы говорите сейчас — это ординалистский подход, то есть вы просто берете пул задач, потом упорядочиваете по сложности (x сложнее y а y сложнее z), выбираете к какой из задач ближе ваша конкретная, и устанавливаете ей сложность. С этим подходом, однако, есть одна проблема — вы не имеете права переводить одни задачи в другие. Иными словами у вас есть задача "малого размера" и есть задача "не очень малого размера" и при этом вы не имеете права переводить n задач малого в k задач не очень малого, т.к. это не количественная оценка. То есть, сложить все задачи и получить какую-то сумму в сп вы в данном случае не можете (т.е. у вас получится в конце спринта не "выполнили задач на 100сп", а "выполнили 5 задач по 10сп, 1 задачу 20сп, 5 задач по 5сп, 5 задач по 1сп", и никаких эти сп теперь не сложить). Чтобы это сделать — вам нужна именно количественная оценка.
Ваши сп при таком подходе не могут складываться, это просто названия. То есть 4сп не факт что вдвое (или хотя бы примерно вдвое) больше, чем 2сп. Она может быть больше на 10% или в сто раз.
Понятное дело, что при таких оценках никакого планирования невозможно.
VolCh
17.06.2019 22:36Даже если говорить только о времени чтобы оценить что одна задача займёт в три раза болльше не нужно оценивать одну задачу в часах, другую и смотреть соотношение. То есть временем оперируем, но в часах его не меряем. Это тупо не практично даже: каждый раз по оценке одной задачи давать оценку эталонной.
Мозгу не обязательно знать точные величины сравниваемых метрик, чтобы решить во сколько раз они различаются. Вот стоит у меня на столе сейчас наполовину пустой стакан лимонада. Я не знаю сколько мл стакан, не знаю сколько лимонада, но могу сказать, что это половина.
Druu
18.06.2019 04:32То есть временем оперируем, но в часах его не меряем.
Ну да, так и делаем. Берем известную задачу, время выполнения которой известно из практики, т.к. мы его пронаблюдали и сравниваем данную задачу с этой известной.
Только, обратите внимание — в данном случае мы можем измерить время выполнения эталонной задачи. Мы знаем, сколько она у нас заняла (ну, точнее мы говорим не о конкретной задаче, а о пуле задач определенного типа, и о том, статистически, сколько времени, исходя из реальной практики, занимает выполнение задач такого рода). СП эталонной задачи измерить нельзя, СП вообще измерить нельзя — в этом проблема СП.
И, повторяю, когда вы оцениваете в СП, вы тоже интуитивно используете некий измеримый показатель для эталонной задачи, пусть и не отдавая себе в этом отчета. Мозг просто не может работать по-другому.
Чтобы сравнить что-то с эталоном, необходима измеримость эталона. Вы не можете сравнивать, например, отризок х с отрезком y, если длина отрезка y не может быть измерена. Если вы не можете измерить эталон — то вы можете только ординалистски заявить: "х больше" или "х меньше". Но вы не сможете сказать, что "х больше в 2.5 раза". Для подобной оценки нужно иметь возможность промерять оригинал.VolCh
18.06.2019 12:54Проблема оценки типовой задачи в часах в том, что это величина не статическая. Сегодня эталонную сделали за 1 час, а через месяц она будет занимать 43 минуты, но этого точно мы не знаем.
А чтобы сравнивать что-то с эталоном не нужно знать метрику эталона. Измерение отрезка X в метрах мы производим путём подсчёта сколько во сколько раз эталонный отрезок больше или меньше измеряемого. Все наши единицы измерения по сути произвольны и измеряя что-то в них мы считаем во сколько раз что-то больше или меньше эталона. Эталон метра мы не можем измерить в метрах, мы создаём аксиому, что этот эталон имеет длину в 1 метр и измеряем остльное сравнивая длины с эталоном.
Если нас не интересует сколько времени занимает задача, а интересует какой набор задач мы сделаем за 2 недели и планируем мы путём сравнения с эталонной,
знаяпредполгая, что за 2 недели мы сделаем 100 таких задач, то какой смысл сравнивать длительность эталонной задачи с оценваемой, а потом приводит это к эталону часов (не суть, 1/24 суток или сколько-ко там каких-то периодов в микромире), если часы нас не интересуют? Более того, повторюсь, длительность эталонной задачи не константа в часах.Am0ralist
18.06.2019 13:21Проблема оценки типовой задачи в часах в том, что это величина не статическая. Сегодня эталонную сделали за 1 час, а через месяц она будет занимать 43 минуты, но этого точно мы не знаем.
Если нас не интересует сколько времени занимает задача, а интересует какой набор задач мы сделаем за 2 недели и планируем мы путём сравнения с эталонной, зная предполгая, что за 2 недели мы сделаем 100 таких задач
Но при этом вы всё равно сравниваете эталонную с временем, закладываясь на 100 эталонок в 2 недели. И выше сами утверждаете, что решение эталонной — величина не статическая. Так в чем разница — мерить в часах сравнивая с эталоном, или мерить в эталоне, который не статический?VolCh
18.06.2019 14:04Исходим из гипотезы, что время на эталонную задачу изменяется плюс-минус пропорционально со временем на оцениваемые задачи, то есть растёт или падает скорость команды в эталонных задачах/спринт. Нам не нужны оценки в часах ни эталонной. ни оцениваемых, чтобы сказать сколько мы сделаем за спринт. Это просто лишняя информация. Да, можно посчитать сп/час, но зачем?
VolCh
15.06.2019 11:57Например, оценивают задачу в своих в 1 сп. Неизвестно кто будет задачу делать, но понятно, что команда может сделать четыре таких задачи за спринт. А когда джуны до миддл дорастут сможет команда 5 делать. Собственно привязка к сторипоинтам позволяет отслеживать рост проищводительности
Apathetic
15.06.2019 11:47Скорость работы в SP понимается очень просто. Ретроспективно мы видим, сколько SP делает команда за спринт. Это позволяет нам понять, сколько SP команда сможет сделать в следующем спринте. Это и есть скорость работы.
Когда мы оцениваем задачу в SP, мы не пытаемся ответить на вопрос "за какое время можно её выполнить", потому что на этот вопрос корректно ответить крайне сложно, и чем больше задача — тем сложнее (см. феномен ошибки планирования). SP — это совокупная оценка трех факторов:
- предполагаемая сложность задачи
- предполагаемое время выполнения задачи
- предполагаемые риски, которые могут повлиять на выполнение задачи (например, плохая постановка, или зависимость от внешних систем).
Оценка в SP является объективной, потому что не ставится от балды, а оценивается в сравнении с другими, уже оцененными задачами.
Вы говорите, что задачи, которые невозможно оценить в часах, никогда не делаются в срок. А задачи, которые типа возможно — разве делаются? Снова отсылаю к феномену ошибки планирования. Ну и я повторюсь, SP нужны не для оценки конкретной задачи, SP служат оценке скорости работы команды в целом. Вам нужен живой пример? Любая компания, грамотно прошедшая agile-трансформацию. Пообщайтесь с Avito, например. Я слышал, у них всё довольно-таки здорово.
Есть agile и без сторипойнтов. Например, Канбан. Но и там мы не пытаемся оценивать задачи в часах. Вместо этого мы, условно говоря, причисляем задачи к разным категориям (например, "маленькая", "средняя" и "большая"; в идеале такая категория должна быть одна, но, разумеется, в IT это практически невозможно), опять же сравнивая её с уже выполненными. После этого, зная за какое время у нас обычно выполняются задачи аналогичной категории, мы можем оценить вероятности выполнения этой задачи в определенные сроки.
Теперь про эффективность. Вы называете критерием эффективности ваше "не увольнение". Тогда как Вы поймете, что стали более эффективны? Вас еще более "не уволят"? Очевидно, это не самая лучшая метрика. 360 тоже сомнительный критерий — оценки субъективны. Выходит, что криитериев эффективности у Вас нет. Как же Вас умудрилось задолбать то, что вы даже не можете измерить?
Druu
15.06.2019 14:08Ретроспективно мы видим, сколько SP делает команда за спринт. Это позволяет нам понять, сколько SP команда сможет сделать в следующем спринте.
А зачем? Ну вот мы знаем, допустим, что команда делает 100SP за спринт, это что дает? Что с этой информацией потом можно сделать полезного?
С точки зрения бизнеса, оценка скорости команды — это вообще один из следующих вариантов: "успели во время", "почти успели", "что-то не успели", "совсем нихрена не успели".
После того, как вы ко мне пришли и отчитались, что ваша команда за спринт делает 100SP, как мне это перевести в понятные и полезные для бизнеса показатели (те, что выше указаны)?
SP — это совокупная оценка трех факторов:
Вы не поверите, но при оценке в часах тоже учитываются все эти факторы. Причем гораздо более естественным и очевидным образом, чем в SP. Потому что как учесть все это в часах — достаточно очевидно, а вот логика вывода SP у каждого своя и не формализуется.
VolCh
15.06.2019 14:14Берёте уже оценённые в сторипоинтам задачи на 100 sp и говорите делать их в следующем спринте, имея малые риски, что вовремя сделано не будет.
Druu
15.06.2019 14:37Берёте уже оценённые в сторипоинтам задачи на 100 sp и говорите делать их в следующем спринте, имея малые риски, что вовремя сделано не будет.
А в чем проблема так же взять и делать в следующем спринте задачи, оцененные в часах?
При этом сколько человекочасов команда делает, я и так знаю, мне считать не надо, а вот оценка задач должна быть проведена в обоих случаях. В итоге при оценке в часах получаем тот же результат, но проще, разве нет?VolCh
15.06.2019 15:33При оценке в часах обычно нельзя просто посчитать, один задачу 4 часа делать будет, а другой 8 часов. Какую оценку ставить, 4, 6, 8?
0xd34df00d
15.06.2019 23:33А со сторипоинтами не то же самое будет?
Вообще если немного подумать, то очевидно, что эта проблема будет всегда, потому что в рабочей неделе у вас 40 (или сколько там) часов, а не N сторипоинтов. И вообще вы время в часах измеряете, а не в сторипоинтах. Время первично.
И, в частности, даже если задача оценена в 6 сторипоинтов, то время её выполнения зависит от того, кто её будет выполнять.
Druu
16.06.2019 04:57При оценке в часах обычно нельзя просто посчитать, один задачу 4 часа делать будет, а другой 8 часов.
Так с СП то же самое будет. Даже если принять, что все понимают сторипоинты одинаково, все равно каждый поставит свою оценку (если мы предполагаем, что команда "неровная"). Только на самом деле под сторипоинтами еще и подразумевают все что-то свое, т.к., я уже упоминал — сторипоинты неформализуемы и неизмеримы. Серьезно, как вы можете топить за метрику с подобными свойствами?
Какую оценку ставить, 4, 6, 8?
Так и ставите: "Вася — 4ч, Петя — 8ч".
И нет никакого перевода в сп, есть оценивании в сп и знание сколько команда может делать сп за спринт. Нет никакой двойной конвертации. Две единицы измерения — спринт и сп.
Вы так и не объяснили в чем проблема с часами. Точно так же — оцениваете в часах и знаете, сколько команда может сделать часов за спринт. При этом вот этот второй показатель вам даже измерять не надо, он заранее известен. С-но, неопределенность становится ниже.
Кроме того, оценки в часах просто содержат больше информации для анализа, т.к. вы потом можете измерить — сколько задача выполнялась и сколько планировалась. Т.о., можно определить, что задача была оценена неверно. В случае сторипоинтов вы никогда не узнаете, что оценка была неверной.
Andreyika
15.06.2019 15:18Ну а какой в этом смысл? Если стратегически оценить для клиента, что вот этот вот набор фич будет стоить вам примерно X спринтов денег — тут можно хотя бы понять.
А какой смысл переводить задачи в sp, чтобы по факту вместить их в 10 дней?
Неизвестно кто будет задачу делать, но понятно, что команда может сделать четыре таких задачи за спринт
Совершенно не факт. Если у вас 4 клона сидят, то может. Но ведь может получиться, что чей-то уровень не позволит реализовать задачу даже за удвоенные сторипоинты, а если отдать её более опытному — ему не хватит часов. Может быть на длинном пути какие-то задачи окажутся проще и разница нивелируется. Но в чем тогда смысл двойной конвертации на коротких отрезках?
VolCh
15.06.2019 18:16Ну так и есть. Прежде всего "за эти две недели мы сделаем вот этот набор фич". И нет никакого перевода в сп, есть оценивании в сп и знание сколько команда может делать сп за спринт. Нет никакой двойной конвертации. Две единицы измерения — спринт и сп. Если хотите переводите спринт в часы и получите скорость команды сп/час. Если оценивать задачи в часах, то скорость получится час/час и равной 1 при точной оценке. Ну и анализ будет типа работы за 300 часов мы сделали работы на 250 часов, а обещали на 300. Что с этим анализом делать? Давайте в следующий раз на 300 часов пообешаем сделать работы на 250 часов, чтоб не краснеть, что не выполняем обещания?
akryukov
15.06.2019 14:20Ну вот мы знаем, допустим, что команда делает 100SP за спринт, это что дает? Что с этой информацией потом можно сделать полезного?
У вас же еще должен быть список желаемых задач. Та же самая команда их оценивает в SP. Бизнес потом может выбрать столько задач на следующую итерацию, сколько успевает сделать команда.
"успели во время", "почти успели", "что-то не успели", "совсем нихрена не успели".
…
понятные и полезные для бизнеса показатели (те, что выше указаны)?Почему вдруг эти показатели понятны и полезны для бизнеса?
Бизнесу как раз важно знать сколько денег он потратит и что за это получит. "что-то не успели" это сколько тугриков?Druu
15.06.2019 14:43У вас же еще должен быть список желаемых задач. Та же самая команда их оценивает в SP. Бизнес потом может выбрать столько задач на следующую итерацию, сколько успевает сделать команда.
А почему бизнес так же не может выбирать в часах, а не в СП? Смотрите, вы сейчас называете преимущества оценки в СП над отсутствием оценки в принципе. Ну да, лучше в СП, чем никак. Но мы же сравниваем с часами? И по факту, СП, как метрика — это говно. Потому что СП неформулизуемы, субъективны и неизмеримы. С другой стороны — часы это метрика прекрасная, т.к. это вполне определенная физическая величина, которую можно объективно измерить.
Почему вдруг эти показатели понятны и полезны для бизнеса?
Потому что доставка фич в рамках заданных затрат — это единственное, что бизнес волнует. Будет доставлено, или не будет.
"что-то не успели" это сколько тугриков?
Это уже не задача лида такие тугрики считать, у него нет соответствующей информации для расчетов. Вот тот, кому лид отчитывался, потом по "успели это не успели то" сможет посчитать тугрики. А по "планировали 100сп, но сделали 80сп" он ничего посчитать не сможет.
akryukov
15.06.2019 15:02А почему бизнес так же не может выбирать в часах, а не в СП?
Потому что в часах все очень сильно зависит от того, кто будет делать. СП это абстракция с целью нивелировать различие между разными членами команды. Можно конечно взять другую абстракцию и назвать ее "часами среднего миддла", а потом делать поправки вроде "джун делает 2 раза медленнее миддла" или "сеньор делает в 2 раза быстрее миддла". Разница будет только в том, что простейшая типовая задача не будет единицей СП.
часы это метрика прекрасная, т.к. это вполне определенная физическая величина, которую можно объективно измерить.
Часы можно измерить постфактум. А на этапе планирования их никак нельзя измерить.
Потому что СП неформулизуемы, субъективны и неизмеримы.
СП это гипотеза, которая статистически проверяется (обычно) каждые две недели. Чем дольше работает команда, тем точнее оценка в СП. У опытной команды ситуация "планировали 100 СП, сделали 80" говорит о серьезной недооценке задач.
Apathetic
15.06.2019 19:34-1Потому что оценка в часах не учитывает:
- кто будет делать задачу
- риски, возникающие при выполнении задачи
Рекомендую почитать про феномен ошибки планирования.
Потому что доставка фич в рамках заданных затрат — это единственное, что бизнес волнует.
Agile позволяет делать эти прогнозы с большей точностью, чем традиционные подходы. Статистический факт =)
0xd34df00d
15.06.2019 23:42+1кто будет делать задачу
Оценка в СП этого тоже не учитывает. Или предполагается, что если я не успеваю по СП, то я буду сидеть допоздна?
А вообще я не понимаю, в чём проблема планировать задачи так:
- Я спец по C++, многопоточке и отладке. Я набираю себе задач на 10 рабочих дней на следующий спринт по этой тематике.
- Васян спец по построению рекуррентных моделей. Он набирает себе задач на 10 рабочих дней на следующий спринт по этой тематике.
- Ну и так далее.
риски, возникающие при выполнении задачи
В чём принципиальная разница между «эта задача имеет риски, поэтому я оценю её в 5 СП» и «эта задача имеет риски, в лучшем случае я сделаю её за день, в худшем — за 5 дней»?
Чем оба эти подхода лучше, чем «на этой неделе я трачу на эту задачу не больше трёх дней»?
Apathetic
15.06.2019 23:47По СП не требуется "успевать", потому что СП не оценивает сроки. Ей-богу, уже начинает надоедать снова и снова повторять в тредах к этому посту — СП != часы, это не связанные друг с другом единицы.
Каким образом вы собираетесь набирать себе задач на 10 рабочих дней, если оцениваете задачи в виде "в лучшем случае я сделаю её за день, в худшем — за 5 дней"? Сколько таких задач вы возьмете? 2? Или 10?
0xd34df00d
15.06.2019 23:52По СП не требуется "успевать", потому что СП не оценивает сроки.
Теперь я совсем ничего не понимаю. Нафиг они нужны тогда?
Каким образом вы собираетесь набирать себе задач на 10 рабочих дней, если оцениваете задачи в виде "в лучшем случае я сделаю её за день, в худшем — за 5 дней"? Сколько таких задач вы возьмете? 2? Или 10?
Два варианта:
- Минимизирующий latency: я работаю по механизму «я выделяю на эту задачу N дней на этой неделе». Тогда очевидно, как набирать задачи?
- Максимизирующий throughput: передо мной просто есть список задач с приоритетами, я сажусь и фигачу, не думая о спринтах, велосити и сторипоинтах. Я даю свои оценки, в процессе выполнения я их уточняю, а сроки, коммуникация с бизнесом и тому подобная — это задача этих ваших фасилитаторов (всё равно переговорки букать и груминги устраивать больше не надо). Если вдруг приоритеты проектов меняются — пишите письма, я с радостью обновлю приоритеты задач.
Apathetic
15.06.2019 23:59На ваш вопрос уже отвечено тут: https://habr.com/ru/company/dodopizzaio/blog/456068/#comment_20283998
Почему не подходят часы: потому что предполагаемое время выполнения задачи — это только часть оценки, и если оценивать только время, существует измеримый риск недооценить задачу (см. феномен ошибки планирования, на который я уже устал ссылаться).
Оба ваших варианта существенно увеличивают риски недооценки задач и неправильного прогноза их выполнения.
0xd34df00d
16.06.2019 00:02«Берёте уже оцененые» — это, конечно, отличный ответ на вопрос о том, как оценивать задачи.
Оба ваших варианта существенно увеличивают риски недооценки задач и неправильного прогноза их выполнения.
В первом варианте я не оцениваю риски вообще, я только говорю, сколько времени я трачу на задачу в неделю (и мне достаточно оценить, что время выполнения не меньше этого времени, хотя на самом деле и это не обязательно).
Во втором варианте вопрос оценок тоже, тащем, не стоит.
Apathetic
16.06.2019 00:04Да, разумеется, с чего-то нужно начинать. Обычно за основу берутся какие-то общепринятые шкалы, коих в интернетах полно. В процессе работы, как правило, принятая шкала корректируется и адаптируется под проект.
0xd34df00d
16.06.2019 00:08Как эти шкалы выглядят? И что, это задачи не из вашего беклога? Я-то при первом прочтении думал, что задач на 100 сп уже из беклога, и сравнивается это с уже выполненными ранее задачами из вашего же проекта.
Apathetic
16.06.2019 00:13Вы всё правильно подумали. Тогда в чем вопрос? Да, для оценки новых задач нужно брать уже оцененные, потому что задачи нужно оценивать не сами по себе, а сравнивая с уже выполненными и оцененными.
Если таковых в проекте еще нет — существуют методики для того, чтобы начать оценку.
0xd34df00d
16.06.2019 00:15В комментарии, на котором вы сослались, нет ничего про оценку задач в сторипоинтах. Есть только про оценку того, сколько уже оцененных задач взять на следующий спринт.
Мы ведь согласны, я надеюсь, что это немного разные вещи?
Apathetic
16.06.2019 00:16Вопрос в том, как именно оценивать конкретную задачу?
0xd34df00d
16.06.2019 00:19«Берёте уже оцененые» — это, конечно, отличный ответ на вопрос о том, как оценивать задачи.
Оценка в СП этого тоже не учитывает.Дальше по треду мне было лень подниматься.
Ну, то есть, если перестать иронизировать (а это мне сложно, прошу простить, от аджайла у меня очень плохие впечатления, максимум, что может как-то работать для тех проектов, что мне интересны — канбан, но все внедряют скрам), то да, вопрос именно в этом.
Apathetic
16.06.2019 00:32Но я уже отвечал на этот вопрос. Оценка задачи проводится путем сравнения её с уже выполненными и оцененными. Несколько первых собраний по оценке разработчику, разумеется, потребуется обращаться к какой-то шпаргалке, но постепенно это становится проще. Причем гораздо проще, чем пытаться оценивать в часах.
Важный момент — оценка проводится коллегиально, как правило, путем голосования. Оценку не ставит один человек.
Пару слов о вышеупомянутой шпаргалке — в наших командах она выглядит, как правило, как таблица, строки которой представляют собой ряд "N SP" — "примерное описание типовых задач" — "примеры задач, оцененных в N SP".
0xd34df00d
16.06.2019 00:36Оценка задачи проводится путем сравнения её с уже выполненными и оцененными.
А кто мешает так же делать, ну, для оценки в часах?
Важный момент — оценка проводится коллегиально, как правило, путем голосования. Оценку не ставит один человек.
А смысл, если я спец по плюсам, Васян спец по рекуррентным нейросетям для NLP, Колян спец по питону, и время выполнения для нас может отличаться на порядок в лучшем случае?
Apathetic
16.06.2019 00:48-1А кто мешает так же делать, ну, для оценки в часах?
Извините, но я больше не хочу говорить про часы. В обсуждении к этому посту примерно миллиард раз было сказано, чем плоха оценка в часах, и я не хочу повторяться.
А смысл, если я спец по плюсам, Васян спец по рекуррентным нейросетям для NLP, Колян спец по питону
Это какой-то абстрактный набор слов, или у Вас действительно есть некий проект, в котором работает ровно три человека с настолько разными наборами компетенций?
0xd34df00d
16.06.2019 00:52Извините, но я больше не хочу говорить про часы. В обсуждении к этому посту примерно миллиард раз было сказано, чем плоха оценка в часах, и я не хочу повторяться.
Потому что занижаются оценки, не учитываются риски, и так далее. А сторипоинты от этого спасают, наверное, магией. Ну ок.
Это какой-то абстрактный набор слов, или у Вас действительно есть некий проект, в котором работает ровно три человека с настолько разными наборами компетенций?
Это чуть экстремальный пример, но да, как раз тот проект из соседнего треда был таким. Над ним работало трое: спец по NLP, спец по C++ и всякой более инженерной ерунде и чувак-всего-понемножку только из вуза, опыта набирался.
Apathetic
16.06.2019 01:11-1Нет, никакой магии.
Сторипойнт — это объективная (за счет коллегиальной оценки) и относительная (за счет сравнения с другими задачами) единица измерения. Да, ретроспективно можно посчитать вероятность, с которой задача, оцененная в N сторипойнтов будет выполнена за определенное количество часов, но зачем? Оценка нужна для того, чтобы решить, брать задачу в спринт или не брать. Да, в конкретной задаче можно ошибиться с оценкой, но задач в спринте много, и ошибки нивелируют друг друга.
Разумеется, вы можете попытаться использовать такую шкалу, в которой 1 сторипойнт будет соответствовать, например 85% вероятности успеть сделать задачу за 1 час, ради бога (хотя на больших задачах начнутся проблемы). Вы даже можете называть эти сторипойнты часами. Но для того, чтобы корректно выстроить такую шкалу, понадобится сделать кучу работы и ради чего? Ради того, чтобы научиться точно оценивать задачу в часах? Но ведь это и не требуется. Оценка в SP проще, чем оценка в часах, при этом она объективнее и позволяет достоверно планировать.
Мне кажется, в этом основная ошибка всех, кто доблестно сражается со сторипойнтами — непонимание, что оценивать в SP проще, чем в часах.
0xd34df00d
16.06.2019 01:20Сторипойнт — это объективная (за счет коллегиальной оценки) и относительная (за счет сравнения с другими задачами) единица измерения.
Часы — это объективная (за счет коллегиальной оценки) и относительная (за счет сравнения с другими задачами) единица измерения.
Почему это высказывание неверно, а то — верно?
Понятно, что это можно сделать верным при некоторых дополнительных предположениях на структуру команды и задач, но эти же предположения сделают верными возможность оценивать в часах.
Apathetic
16.06.2019 01:35-1Потому что с оценкой в часах люди чаще ошибаются.
Давайте я попробую продать Вам идею сторипойнтов под соусом, которым закончил предыдущий комментарий.
Смотрите, когда Вы пытаетесь оценить задачу в часах, у вас есть огромная шкала от 1 до N часов. В процессе оценки Вам понадобится оценить задачу максимально точно, иначе смысл оценивать её в часах (ведь эту оценку мы потом хотим использовать для понимания, какие задачи брать в итерацию). Для этого Вам нужно будет сравнивать каждую задачу с довольно-таки большим числом других задач — и всё равно это будет неточно, и каждый раз будут возникать сомнения, а три это часа или четыре, семь или девять и так далее, и в итоге вы всё равно ошибетесь — и чем больше задача, тем больше вероятность ошибки.
Каноничная оценка в SP проводится на гораздо меньшей шкале. Самая часто используемая шкала — ряд Фибоначчи из 4-5 чисел. У вас есть 1, 2, 3 и 5 сторипойнтов (ну и, допустим, 8 для особо крупных задач, которые не удалось декомпозировать). Разница между 3 и 5 сторипойнтами, как правило, весьма прозрачна (хотя это тема для отдельного обсуждения).
Мой пойнт в том, что оценка в сторипойнтах проще и объективнее. Она менее точна, но для планирования спринтов это и не требуется.
0xd34df00d
16.06.2019 01:44Смотрите, когда Вы пытаетесь оценить задачу в часах, у вас есть огромная шкала от 1 до N часов.
А вот и нет!
Я оцениваю задачу в количестве часов, кратных 8. Иначе говоря, я оцениваю задачу в днях, а не в часах (и 0 — корректная оценка для некоторых задач).
И брать для дней ряд Фибоначчи тоже никто не мешает, тащем.
Apathetic
16.06.2019 01:46Скажите, задачу, которую Вы оцениваете в 3 дня, Вы действительно делаете ровно три дня?
0xd34df00d
16.06.2019 01:48Зависит. Если я работаю в режиме минимизации латентности (и максимизации предсказуемости), то если она начинает жрать больше трёх дней, я её откладываю. Если она жрёт меньше трёх дней, то я радуюсь и беру следующую задачу (ну или хабр читаю, чего уж).
Если я работаю в режиме «быстрее сделать весь проект», то я просто делаю задачу независимо от оценок.
Apathetic
16.06.2019 01:52-1Если вы откладываете задачу, которую делали три дня — вы не просто НЕ максимизируете предсказуемость, вы совершаете одно из страшнейших преступлений против эффективности — копите незавершенную работу, но это отдельная тема...
Ладно, как бы то ни было, получается, что вы, во-первых, не стремитесь к точной оценке, во-вторых, пытаетесь учитывать все факторы, влияющие на время выполнения задачи, и, в-третьих, оцениваете задачу, сравнивая её с предыдущими. Поздравляю, Вы уже используете сторипойнты, правда мне решительно непонятно, зачем Вы называете их часами, если это не часы.
0xd34df00d
16.06.2019 01:55+1копите незавершенную работу, но это отдельная тема...
Ну чего коплю сразу? Откладываю на следующий спринт, а в этом спринте делаю другие таски.
Поздравляю, Вы уже используете сторипойнты, правда мне решительно непонятно, зачем Вы называете их часами, если это не часы.
Правильно, это не часы, это дни :)
вы, во-первых, не стремитесь к точной оценке
Мне делать нечего, что ли? Достаточно оценивать со стабильной и не сильно большой дисперсией отклонения, а там ЗБЧ вывезет.
во-вторых, пытаетесь учитывать все факторы, влияющие на время выполнения задачи
Нет, я оцениваю что-то типа среднего случая и пессимистичного случая. А иногда вообще говорю «да хз».
оцениваете задачу, сравнивая её с предыдущими
Я сравниваю её со всем опытом, а не с какой-то конкретной эталонной задачей или набором задач.
Apathetic
16.06.2019 02:08Я сравниваю её со всем опытом, а не с какой-то конкретной эталонной задачей или набором задач.
Да, в конечном счете к этому и приходят. Оценка появляется в голове "сама собой".
Достаточно оценивать со стабильной и не сильно большой дисперсией отклонения, а там ЗБЧ вывезет.
Да, так работает емкость спринта.
В общем-то, чуть-чуть добавить осмысленности и коллегиальности — и будут полноценные сторипойнты. Непонятно, почему Вы с ними воюете ?_(?)_/?
Если вы работаете над потоком задач не командой — то тут уже другой вопрос. Аджайл всё-таки для команд, а не для одиночек.
0xd34df00d
16.06.2019 02:10Ну, почему коллегиальность не работает, я уже писал выше. Почему воюю — потому что первый (и часто единственный) вопрос, который я себе задаю — «сколько дней у меня это займёт?».
mva
16.06.2019 04:36по-моему, все противники часов в треде забывают про уже давно существующие "сторипоинты" ещё со времён мануфактур и заводов…
Называются они "человекочасы".
И вы не поверите… К хронологическим часам они привязаны весьма и весьма относительно.
// и мне уже полтреда так и хочется попросить рассказать как же сисадминам/инженерам/техподдержке и т.п. оценивать абсолютно разные каждый раз задачи (появляющиеся в процессе спринта, а не заранее) в сторипоинтах?
TL;DR версия описанного ниже: смысл оценки в сторипоинтах, если постоянно всплывают такие задачи, что за планируй-не-планируй, а за спринт, в который пытаются упихнуть — не взлетит.
Плюс, ладно в компаниях где я консультирую существует такой человек как я, который при обсуждении любого вопроса всегда прикидывает максимально возможное количество трудностей, которые помешают реализации (хотя и я, порой, недооцениваю степень их влияния). Но ведь такие "пессимисты" как я есть далеко не везде, и "привет продалбывание спринтов". А ещё есть менеджеры, штрафующие команду за продолбанные спринты.
Так вот...
Ну да, задачи "настроить NginX" на одном на другом сервере, казалось бы, можно друг относительно друга посчитать.
Хотя, ведь, даже тут "заказчики" любят постоянно чего-то недоговаривать в задаче: то у них ОС окажется слишком старая, то окажется, что проект не умеет в современный php/python/whatever, и php/… надо древнючий из глубин ада достать, то вообще nodejs из bleeding edge воткнуть.
То от апстрима неожиданные сюрпризы...
А что делать с потоком задач которые банально невозможно оценить без предварительного погружения в стек технологий?
Например, всю жизнь жили на парке железок, вдруг высокое начальство ставит задачу "переезжаем в амазон", под которую нанимает внешнего специалиста.
Потом начальство задалбывается от срывов сроков (возникших из-за недооценки, произошедшей из-за постоянных недоговорок об особенностях, ну и, может от особенностей компетенции нанятого специалиста в конкретных используемых стеках внутренностей проектов), и когда всё уже готово оно принимает решение вернуться на железки.
А потом вдруг приходит решение "строим всё на докере".
При этом докер все только "слегка щупали", и, за годы работы на голом железе не особо двигались дальше.
И знания о докерной кластеризации есть только теоретические.
Что, строим планирование исходя из теоретических знаний, которые позволят "примерно" прикинуть?
Нуок. Построили.
Посреди работы выясняем:
вот тут вот докер не может работать с glusterfs, так что надо потратить ещё два дня на перенастройку всех кластеров гластера на NFS, а так же прогнать изменения в файрволлах, чтобы кто попало не шарился по нашим вольюмам (потому что гластер, как оказывается, по NFS игнорирует выставленные ограничения доступа).
А вот тут выясняется, что Elasticsearch чтобы работать с больше чем 16 ГБ оперативки надо выставлять параметры ядра, а докер такое умеет только когда вне кластера. А в кластере — not implemeted yet.
А ещё внезапно оказывается что в java завезли баг, из-за которого она ложно предполагает что не может создавать лок-файлы на многослойных ФС, один из слоёв которой — сетевой.
И встреваем ещё на полспринта, пока строим костыли.
Потом ещё какая-нибудь внезапная херня типа бага стабильном релизе Sentry, который делает нормальную работу с ним вообще невозможной.
И так проект "на полгода" просрачивается ещё месяца на три.
А тут ещё начальство вдруг "что-то мы бюджет превышаем, давайте-ка срежем пучок серверов"...
И как в таких условиях стори-поинты помогут в прогнозах хотя бы на йоту?
mva
16.06.2019 04:54А, и да, забыл самое главное:
Если сторипоинты, по итогу, "Нарекаем этой задаче 5 сторипоинтов", то почему так же нельзя наречь ей "5 человекочасов"? Зачем было придумывать сторипоинты?
Zoomerman
16.06.2019 02:20и в итоге вы всё равно ошибетесь — и чем больше задача, тем больше вероятность ошибки.
оценка в сторипойнтах проще и объективнее. Она менее точна, но для планирования спринтов это и не требуется.
То есть в часах больше вероятности ошибиться, а сторипоинты сами по себе не очень точные, поэтому ошибиться сложнее?
Вы говорите о создании продукта или о прикрытии зада перед начальством?
Мой спринт такой:
— если работал и помнишь код, где нужно поменять и знаешь как это поменять, то 0,5 часа
— если не работал с кодом, но понимаешь, что поменять нужно чуть — 1 час
— если понимаешь, что поменять чуть, но с кодом не работал, в архитектуру вникать нет смысла и нужно обсуждать с заказчиком нюансы — 2 часа
— создание новой фичи на знакомом коде без архитектурных изменений — 4 часа
— любые работы, вызывающие изменение бизнес-логики или архитектуры решения — 6 часов на старте, затем по итогам этих 6ти часов
— отсутствие точных требований к задаче — плюс 1 час к расчетному времени
— ввод в работу нового проекта (подготовка рабочего окружения, изучение архитектуры) — 3-4 часа в зависимости от стека
По этой сетке можно разложить любую задачу на подзадачи и вывести расчетное время готовности проекта.
Но это, конечно, если хватает знаний для декомпозиции. А если нет — берешь паузу и в свободное от работы время учишься там, где не хватает.
Продуктивный день разработчика 6 часов. За 20 лет работы не видел ни одного уникума, способного кодить 8 часов с перерывом на обед. Чай/кофе/перекуры легко съедают 2 часа рабочего времени. Да и санитарные нормы 45/15 в час не на пустом месте придуманы были.
Без морали.Apathetic
16.06.2019 02:28То есть в часах больше вероятности ошибиться, а сторипоинты сами по себе не очень точные, поэтому ошибиться сложнее?
Абсолютно так.
Мой спринт
Вы работаете в одиночку?
Zoomerman
16.06.2019 02:44То есть в часах больше вероятности ошибиться, а сторипоинты сами по себе не очень точные, поэтому ошибиться сложнее?
Абсолютно так.
Это фиаско
Есть красное русское слово для этого случая — «очковтирательство». Кажется, оно как нельзя лучше подходит для иллюстрации смысла планирования в сторипоинтах.
Вы работаете в одиночку?
Отнюдь. «Мой» означает, что я использую эти критерии в работе. Вне зависимости мою или чужую работу планирую.
Критерии «известен-код, известно-что-делать, есть-все-требования» значительно точнее, чем «джун-мидл-сеньор» в вашем способе планирования. Вкупе с более точным инструментом измерения дают вообще фантастическую точность относительно спринтов через сторипоинты.Apathetic
16.06.2019 09:24+1Это не фиаско, потому что главная задача SP и всего подхода в целом — не конкретную задачу оценить, а скорость работы команды.
Druu
16.06.2019 05:09Смотрите, когда Вы пытаетесь оценить задачу в часах, у вас есть огромная шкала от 1 до N часов. В процессе оценки Вам понадобится оценить задачу максимально точно, иначе смысл оценивать её в часах (ведь эту оценку мы потом хотим использовать для понимания, какие задачи брать в итерацию).
Вы чушь сейчас говорите, на практике оценка в часах идет так же как в СП, потому что по факту в часах никто не меряет, а меряют скорее так: "надо полдня" или "два дня" или "ну это на полспринта/на весь спринт таска, надо побить, вообще говоря". Ну и потом ставят полдня*длина_рабочего_дня часов, например.
То есть в итоге идет оценка путем сравнения как раз с некоторой задачей, которая решается за полдня-день, и человек виртуально представляет, насколько дольше/быстрее он сделает оцениваемую задачу по сравнению с эталонной. Это все то же самое что и с СП, только в данном случае сравнивается конкретный и четкий показатель (ожидаемая продолжительность выполнения) а не абстракцию, которую численно и оценить-то никто не может, на самом деле.Apathetic
16.06.2019 09:25Вы переходите на личности. Извините, но с Вами я больше не буду дискутировать.
Druu
17.06.2019 05:14Вы переходите на личности.
Никакого перехода на личности не было. Вы это выдумали и обвинили меня в том, чего я не делал.
Теперь я жду извинений за ваше хамское поведение.
eboyko
17.06.2019 16:58> Вы переходите на личности. Извините, но с Вами я больше не буду дискутировать.
Так бы и писали — ой, все.
Druu
16.06.2019 05:04Потому что оценка в часах не учитывает:
Кто будет делать учитывается ровно так же, как и в случае СП — если вы не выбирали среднее. Риски учитываются заведомо, т.к. при оценке вам всегда дают квантиль. Т.е., когда вы спрашиваете у человека "за сколько выполнишь задачу?" то он отвечает на самом деле на какой-то вопрос вроде: "сколько нужно часов, чтобы уложиться в вероятностью 9/10" (это так мозн работает при интуитивных стат. оценках). С-но, чем выше дисперсия для требуемого времени (т.е. риски) тем дальше будет смещен квантиль и выше оценка.
Agile позволяет делать эти прогнозы с большей точностью, чем традиционные подходы.
Оценка в часах будет всегда в среднем точнее. Математический факт.
Просто в силу того, что оценки в СП очень неточны — вы, в отличии от оценки в часах, не можете их проверить.
Ну то есть с часами вам сразу понятно — оценили как 10, делали 15, вот вам ошибка в 5 часов. А в СП наличие ошибки в оценке доказать вообще сложно, можете давать любую оценку, хоть рандомайзером, и по итогу она окажется "точной".
Рекомендую почитать про феномен ошибки планирования.
СП этим ошибкам точно так же подвержены.
Apathetic
15.06.2019 19:39-1Логика вывода SP у всех должна быть общая — для этого достаточно провести 15-минутную лекцию с объяснением, что это и как работает. Проверено личным опытом =)
Пожалуйста, хватит говорить про часы. Оценка в часах не работает. Это тоже статистический факт.
eboyko
17.06.2019 17:021 спринт = N сторипойнтов. 1 спринт = M недель. M недель = L часов (скрам подразумевает неукоснительное соблюдение сроков). Следовательно, 1 спринт = L часов.
Любой процесс в этой вселенной завязан на время. Ваши сторипойнты лишь производная.Apathetic
17.06.2019 18:53Да, часы можно вывести из СП. Обратная конвертация не работает, и оценить задачу корректно в часах невозможно.
eboyko
17.06.2019 19:10Неужели? Чтобы написать этот комментарий мне потребуется две минуты.
Если такая конвертация невозможна, то сторипойнты вообще ничего не значат — это просто случайные числа, непригодные для планирования.
UPD: Ну вот, справился за плоторы. Один сторипойнт позволил бы мне пинать хер остаток дня.Apathetic
17.06.2019 19:26Чтобы написать этот комментарий мне потребуется две минуты.
Вы серьезно аргументируете этим Вашу способность оценивать задачи, требующие несколько часов а то и дней работы?
Такая конвертация не нужна, и сторипойнты не имеют особого смысла применительно к одной задаче. Они имеют смысл в масштабе нескольких спринтов. В отличие от часов, в которых ошибка планирования имеет тенденцию накапливаться, сторипойнты благодаря механизму их проставления отображают производительность команды гораздо корректнее и точнее. Именно поэтому они позволяют планировать, а часы — нет.
Один сторипойнт позволил бы мне пинать хер остаток дня.
Если Вам действительно хочется нести подобный бред — предупредите сразу, я не буду мешать.
Druu
18.06.2019 04:39В отличие от часов, в которых ошибка планирования имеет тенденцию накапливаться, сторипойнты благодаря механизму их проставления отображают производительность команды гораздо корректнее и точнее. Именно поэтому они позволяют планировать, а часы — нет.
Не, вы уж говорите как есть — в отличии от часов, для которых ошибка планирования очевидна и измерима, в сторипоинтах можно давать любые оценки, и они всегда будут заведомо "правильными", т.к. для того чтобы они были "правильными" их достаточно таковыми объявить. И обратного (что оценка в сп была плохой) доказать нельзя.
VolCh
17.06.2019 23:42Следовательно, 1 спринт = L часов.
Мы в ретроспективе можем посчитать, сколько часов заняла доставка одного сторипоинта в среднем. Но это будет вычислением корреляции сторипоинтов и часов. На длительных отрезках (множестве спринтов) будет наблюдаться корреляция. На планировании спринта мы не можем достоверно предсказать сколько часов займёт один сторипоинт.
Druu
18.06.2019 04:44Но это будет вычислением корреляции сторипоинтов и часов.
А вот ответьте на такой вопрос — если бы сторипоинты не коррелировали никак с часами, то в них был бы какой-то смысл и какая-то польза? Если да — раскройте, пожалуйста, какой смысл и какая польза.
VolCh
18.06.2019 12:58Они не могут не коррелировать по определению. Но как комплексная оценка, где время лишь один из параметров, они приносят больше пользы, чем чистые часы.
0xd34df00d
15.06.2019 23:28Во-вторых, Вы не сможете понять, сколько задач в действительности может сделать команда за один спринт.
Чем это отличается от количества часов в неделю, помноженных на количество людей в команде?
Druu
15.06.2019 04:07Абсолютно все известные мне программисты, понимающие, что такое SP, и зачем они нужны, умеют ими грамотно пользоваться, не занимаясь абсурдным переводом в часы.
Скажите, а зачем-таки нужна оценка в SP, если планирование ведется все равно в часах?
Ну то есть, если SP нельзя перевести в часы — оценка автоматом становится бесполезной, т.к. ее нельзя использовать для планирования.
Если же ее можно перевести в часы — то можно использовать часы. Что на счет этого?
Сторипойнты в скраме нужны для того, чтобы понимать скорость работы команды, и, уж простите, но очевидно, что Вы этого НЕ понимаете.
Так ведь скорость — это, по определению, количество В ЧАС. То есть, чтобы оценить скорость работы команды — надо оценить задачу в часах.
VolCh
15.06.2019 12:04+1Скорость команды — количество типовых задач за период. Оценка задачи в часах тут лишняя.
Druu
15.06.2019 13:58Скорость команды — количество типовых задач за период. Оценка задачи в часах тут лишняя.
Ну так типовая задача — это в итоге все равно Х часов. Зачем промежуточный показатель, если можно сразу измерить в часах? 2 недели спринт = 10 дней, каждый день пусть по 6 часов, с-но 60 часов на человека. В итоге производительность команды можно сразу узнать, просто умножив количество человек в команде на 60.
VolCh
15.06.2019 14:10Нет, X часов не константа даже в пределах одного спринта: разработчики разные.
Druu
15.06.2019 14:27Нет, X часов не константа даже в пределах одного спринта: разработчики разные.
Так в этом случае SP использовать нельзя. Они должны переводиться в часы, это необходимое условие, т.к. часы это единственная измеримая метрика. В противном случае знание SP не дает вам никакой информации, с-но вы при оценке просто зря потратили время. Можно просто рандомом SP устанавливать и все тогда.
VolCh
16.06.2019 13:05У нас есть статистика сколько SP поставила команда за прошлые спринты и результаты ретроспектив непопадания. Естественно, предполагается, что оценки были нерандомные. А часы как раз могут плавать в зависимости от того, кто делал. У нас всё же не строительство, где нормируется на задачи человеко-часы разных специалистов разных разрядов. Можно, наверное оценивать задачи типа "тут требуются 2 часа сеньор фронта, 3 часа миддла бэка, 5 часов джуна фронта" а потом как-то композировать задачи, чтобы на каждого выходило условных 60 часов за 2 недели. Но субъективно непопадания в планы будут гораздо чаще, хотя бы потому что сеньор сеньору рознь.
eboyko
16.06.2019 15:39Звучит так, что SP это некая временнaя оценка, умноженная на некий коэффициент неопределенности (непопадания, если угодно). Любой опытный разработчик выполняет эту нехитрую калькуляцию, оглашая предполагаемый срок.
Можете называть итоговую цифру сторипойнтами, если угодно, но ее природа от этого не изменится.Am0ralist
16.06.2019 15:56Да вообще странно. Когда просят указать в чем четко разница и как её четко просчитывать — люди отвечают в духе «это потому что вы не понимаете, а те кто понимают, они умеют».
Но четкую формулу, что характерно, не приводят.
Это примерно как обсуждать вред ГМО, информационную структуру воды и алюминий из прививок. Все те, кто противники противников данных вещей — просто ничего не понимают. Но механизм четко никто из сторонников таких теорий объяснить не может.
Я уже второй день пытаюсь понять, как же именно я, как IT специалист должен считать эти стори, дабы улучшить взаимодействие с другими IT и программистами — и не понимаю…
PS. Ну хоть кто-нибудь как для дебила бы написал пошаговость расчёта этого параметра.Apathetic
17.06.2019 18:56Здесь уже несколько раз отвечалось на этот вопрос — оценка производится сравнением с уже выполненными и оцененными задачами.
Am0ralist
17.06.2019 20:49В времени мы оцениваем так же. Дальше?
Apathetic
17.06.2019 21:45Скажите, вот оценили вы задачу, например, в 16 часов — как часто случается, что она действительно делается ровно за 16 часов?
Am0ralist
17.06.2019 22:14С тех пор, как мы начали общаться напрямую с программистом, то его слова сделаю до завтра, это мне надо часик сейчас посидеть, это примерно на неделю — укладывается. Ну, потом ещё ошибки править приходится часто, но это вообще быстро получается, если в новом коде.
А до этого у нас вообще информации никакой не было, ибо она терялся на этапе инженеры внедрения-программист да с учетом ещё висения над ними начальства. И задачи решались месяцами и годами.
собственно, одну задачу, к которой они год приступить не могли, мы смогли решить в течении пары недель-месяца.
Если же по админству, то либо задачи изначально для нас новые (поднять кластер, когда ни разу не делали), либо стандартные которые так же по времени оценить не проблема и оно так и идёт (если только баг в информационной системе не всплывет, тогда добавляется время работы программиста из первого абзаца). Но в общем да, если говорим два рабочих дня, то тот кто говорит — укладывается. Другой может не уложиться, ибо у него другие наборы навыков тренируются.
Итааак, дальше?Apathetic
17.06.2019 22:16Нет, вы не поняли. Под "делается" я имею ввиду весь процесс — от начала работы до перевода в статус "готово". И речь не про "укладывается". Можно назвать срок в три дня, сделать за час — и формально это будет "уложился".
Am0ralist
17.06.2019 22:25А программист сидит дома и кодит по ночам. Вообще без понятия сколько часов в реале уходит. Нам то что, если при этом он говорит завтра к утру сделаю на тест — значит сделает.
Если говорит неделю, то за это время будет несколько тестовых сборок для поиска ошибок. Плюс ещё в основной версии ошибки будет править.
Да, на сложных задачах вида исправить информационную систему с обычной на версионную сразу четко срок конечный не даст (ибо там не только базу, но и половину приложений изменять надо было). Но промежуточные задачи четко делал.
Если есть задачи кроме нас — он так и говорит, что столько то часов будет занят.
Но, собственно, задачу на час он до трех дней не растягивает. Хотя бы потому, что мы не поймём такого финта, хоть и не программисты.
Но если говорит в течении часа, завтра к утру и т.п. — значит сделает.Apathetic
17.06.2019 22:29Он у вас один?
А программист сидит дома и кодит по ночам
Извините, я не очень в сарказм сейчас, это шутка или действительно так?
Am0ralist
17.06.2019 22:37Во-первых, он не у нас)
Во-вторых, никаких шуток.
Два админа, один программист внешний. Но он не только по ночам, да.Apathetic
17.06.2019 22:39Тогда это ужасно. Нет, это его выбор, разумеется, но на мой взгляд это ужасно.
Возвращаясь к делу — скрам в целом и стори-пойнты в частности не особо применимы к, скажем так, одиночным забегам. В Вашем случае это действительно было бы бессмысленным оверхедом.
Am0ralist
17.06.2019 22:42Тогда это ужасно. Нет, это его выбор, разумеется, но на мой взгляд это ужасно.
Ну, возраст такой — не спится ему по ночам…
Am0ralist
18.06.2019 09:58Возвращаясь к делу — скрам в целом и стори-пойнты в частности не особо применимы к, скажем так, одиночным забегам.
Эм… Итак, то есть вы утверждаете, что скрам не применим к ситуации, когда несколько специалистов в связке решают задачи бизнеса путем постоянного изменения информационной системы, полностью обеспечивающую как раз таки функционирование этого бизнеса? И не имеющих конкретной цели завершения проекта (то есть цель — долговременное функционирование системы и своевременное её изменение под новые требования)Apathetic
18.06.2019 12:32Итак, то есть вы утверждаете
Нигде, ни разу, ни одним своим словом я даже не пытался намекнуть на такой вывод. Я написал ровно то, что написал — скрам для команд, а не для одиночек.
Am0ralist
18.06.2019 13:23Я написал ровно то, что написал — скрам для команд, а не для одиночек.
Я вам описал команду из трех человек. Но по вашему это не команда, а одиночки? Ясно, понятно.Apathetic
18.06.2019 13:32Вы мне сказали, что у Вас задачи ставятся на одного программиста, я Вам ответил, что скрам не для таких кейсов. Остальное — Ваши домыслы и демагогия.
Если будет желание обсудить что-то по делу — прошу в личку.
Am0ralist
18.06.2019 13:39Остальное — Ваши домыслы и демагогия.
Это вы про то, что не умеете читать других? Цитирую:
Я уже второй день пытаюсь понять, как же именно я, как IT специалист должен считать эти стори, дабы улучшить взаимодействие с другими IT и программистами
Если же по админству, то либо задачи изначально для нас новые (поднять кластер, когда ни разу не делали), либо стандартные которые так же по времени оценить не проблема и оно так и идёт (если только баг в информационной системе не всплывет, тогда добавляется время работы программиста из первого абзаца).
Два админа, один программист внешний.
вы утверждаете, что скрам не применим к ситуации, когда несколько специалистов в связке решают задачи бизнеса путем постоянного изменения информационной системы, полностью обеспечивающую как раз таки функционирование этого бизнеса?
Так кто после этого в домыслы и демагогию уходит? Зеркало вам показать?
Собственно, конкретно вы в этой теме постоянно отвечаете демагогически, не зря именно ваши тексты у меня прочно ассоциируются с текстами, выдаваемыми людьми, верующими в шарлатанский бред — схожестью приемов.
Почему VolCh может нормально ответить в комменте ниже, почему скрам не катит, а вы всё время скатываетесь на то, что общающимся с вами недостает тайных знаний и озарений от рептилоидов?Apathetic
18.06.2019 13:43когда несколько специалистов в связке решают задачи бизнеса путем постоянного изменения информационной системы,
Вы мне это сообщили уже после того, как я сказал вам про то, что скрам для команд, нет?
Am0ralist
18.06.2019 13:54Возьмите не Мск а маленький город.
То есть остальные вы не читали, так и запишем. Или понимали что-то своё.
VolCh
18.06.2019 13:07Скрам слабо применим в ситуации, когда практически невозможно зафиксировать планируемый объём работ на 1-4 недели, когда с вероятностью близкой к 100% кто-прибежит и скажет бросать все задачи и делать новую, очень важную, с одной стороны, а с другой, сложно вообще сказать будет ли что делать через это время.
Am0ralist
18.06.2019 13:26а с другой, сложно вообще сказать будет ли что делать через это время.
Ну вот задачу игры в герои 3 мы еженедельно проваливаем по причинам того, что делать есть практически всегда)
Хотя заранее спрогнозировать поступление и класс новых задач — да, невозможно.VolCh
18.06.2019 14:08Ну скрам заточен под ситуации когда подавляющее большинство поступающих задач может ждать минимум эти две недели или сколько там спринт устнаовлен. Максимум во время текущего спринта можно сделать оценку поступивших, чтобы бизнес на следующий спринт планировал что включать или не включать в бэклог спринта.
Druu
18.06.2019 04:49Скажите, вот оценили вы задачу, например, в 16 часов — как часто случается, что она действительно делается ровно за 16 часов?
Если вы оценили задачу в 5сп, то как часто оказывается, что она действительно 5сп?
VolCh
17.06.2019 23:50И накапливается ошибка из-за изменений условий. Год назад вы сделали эталонную задачу за час, а теперь она потребует полчаса, из-за роста квалификации, новой инфраструктуры и т. п. Или, наоборот, теперь потребует 2 часа, потому что надо писать тесты, проводить кодревью, уговаривать админов дать сервер вне очереди и т. д.
VolCh
17.06.2019 23:47Очень просто считать для начала: вашу оценку времени делите на вашу оценку эталонной задачи в 1 сторипоинт. Важно: оценки должны происходить одновременно, а не так, что год назад засекли за сколько сделали эталонную задачу, а теперт делим на это число.
Druu
18.06.2019 05:02Очень просто считать для начала: вашу оценку времени делите на вашу оценку эталонной задачи в 1 сторипоинт.
А в чем проблема не делить а так и оставить в часах? Зачем огород городить? :hz:
Я старался, чтобы звучало так, что SP это некая комплексная оценка
Вы не поверите, но оценка в часах — это тоже комплексная оценка, в которую, по определению, входят все факторы, которые могут повлиять на время выполнения задачи.
И что дальше с этим делаем? Увольняем? Игнорируем его мнение при следующих оценках?
А это уже менеджмент решает, что делать. Важно, что информация есть. И когда информация етсь — это всегда лучше, чем ее нет. Или смысл СП как раз в том и состоит, чтобы скрывать от менеджмента важную информацию?
А если только Вася будет делать? Или только Петя? Или Петя час поделает, а потом критикал баг прилетит и он отдаст доделвать Васе?
Не понял, в чем вопрос. Уточните. И сразу скажите, как СП проблему решает.
СП как раз решает, а оценивание в часах — нет.
Как решает, если не решает? Я вам уже укзаал конкретный кейс, в котором с СП те же проблемы. Более того — на самом деле с СП еще все и хуже, ведь легко оказывается, что, решая задачу Х, Вася за спринт делает 10сп, а решая задачу Y — он делает 20сп.
При этом если в часах вы это легко оттрекаете — т.к. увидите, что Вася оценивал Y в часах занижено по сравнению с остальными, то в случае СП вы никак эту информацию извлечь не сможете. Вы просто увидите что у вас производительность Васи по каким-то причинам прыгает туда-сюда. Почему? Да хз, оценок Васи в часах ведь нет, а оценка в СП одинаковая.
С оценкой в СП понятно что делать на проваленном спринте
С оценкой СП как раз непонятно что делать, потому что оценка СП не содержит никакой информации о характере проблемы. Возможно проблемы и нет, а возможно — она есть, и если есть — анализ оценок СП никак не поможет определить, в чем проблема.
В случае часов у вас полно полезной информации, которая позволяет определить, в чем дело. Например — зачем-то дали Васе задачу X вместо задачи Y, зачем? Ну и т.д.
Это информация, которую можно использовать при планировании.
Субъективно, очень скоро понадобится человек, который будет назначать какие задачи кому делать и будет вводить поправочные коэффициенты. Самоорганизованной команды не будет больше.
Какие поправочные коэффициенты? Они как раз для СП нужны, т.к. у вас у каждого своя производительность в СП. Причем она еще и от задач зависит, с-но нужен отдельный человек, который будет все это менеджить — следить за тем, у кого на каком классе задач какой коэффициент производительности и, исходя из этого, по диаграмме Ганта планировать спринт.
В случае часов все и так очевидно, и команда сама без каких-либо проблем (и непонятных зачем-то выдуманных вами поправочных коэффициентов, зачем они нужны, если у вас есть часы — в которые все коэффициенты уже входят сами собой?) быстро и эффективно может распределить на спринт задачи из беклога. При этом все совершенно наглядно и не надо собирать гигантские объемы стат. данных для того, чтобы планирование было точнее, чем рандомом.VolCh
18.06.2019 13:59А в чем проблема не делить а так и оставить в часах? Зачем огород городить?
Это просто "лайфхак" для тех, кто не может не измерять задачи в часах.
в которую, по определению, входят все факторы, которые могут повлиять на время выполнения задачи.
Не согласен с таким определением. Вернее по моему глубокому убеждению оценка разработчика не может быть такой.
Или смысл СП как раз в том и состоит, чтобы скрывать от менеджмента важную информацию?
Можно и так сказать в какой-то мере. Но с поправкой: в скраме, где обычно и применяются сторипоинты, это особо не относится к важной для менеджмента информации. Важно для менеджмента сколько от запланированного объёма команда делает за спринт.
С оценкой СП как раз непонятно что делать, потому что оценка СП не содержит никакой информации о характере проблемы. Возможно проблемы и нет, а возможно — она есть, и если есть — анализ оценок СП никак не поможет определить, в чем проблема.
В случае часов у вас полно полезной информации, которая позволяет определить, в чем дело. Например — зачем-то дали Васе задачу X вместо задачи Y, зачем? Ну и т.д.
Это информация, которую можно использовать при планировании.Оценка в часах так же не содержит никакой информации о характере проблемы. Точнее не так же, а ещё меньше содержит информации. Как раз отдельный человек нужен, чтобы следить за оценкой в часах.
А вообще у меня стойкое ощущение, что мы о разных вещах говорим и про оценку в сп, и про в часах. Для меня в сп — это комплексная, а в часах базовая, не учитывающая ничего кроме собственно оценки на задчу, никаких рисков, никаикх ошибок
VolCh
17.06.2019 23:44Я старался, чтобы звучало так, что SP это некая комплексная оценка, в которую входит классическая оценка времени завершения задачи.
eboyko
18.06.2019 00:47+1SP это некая комплексная оценка
Именно! Сторипойнт — это произведение:
а) непосредственные временные затраты;
б) индивидуальный коэффициент исполнителя (общий опыт, опыт решения идентичных задач, коммуникативные навыки etc);
в) коэффициент факторов среды (задержки на получение API-ключей, железа etc);
г) коэффициент непредсказуемости (болезни, климат etc).
Список неполный, каждая команда дополняет его самостоятельно.
Наиболее важно тут, что командная оценка задачи не может быть усреднена (а потому бесполезна). В большинстве случаев если двое оценивают в 5, а непосредственный исполнитель — 8, то закладывать придется 8.Druu
18.06.2019 05:09б) индивидуальный коэффициент исполнителя (общий опыт, опыт решения идентичных задач, коммуникативные навыки etc);
Ахахах, вобще-то, сп — это оценка объема работы. Она не зависит от исполнителя, она для всех одинакова, просто у вас один исполнитель сделает эти сп быстро, а другой — медленнее. А вот в часовой оценке как раз описанные факторы оказываются учтены, т.к. человек, давая оценку, конечно же, учитывает свои компетенции.
Все остальные описанные факторы, конечно, в оценке часов тоже учитываются — как и абсолютно любые другие факторы, оказывающие влияние на время выполнения задачи.
Druu
17.06.2019 05:19У нас есть статистика сколько SP поставила команда за прошлые спринты и результаты ретроспектив непопадания.
И что дальше вы с ней сделаете? Еще раз — с часами вы просто смотрите на результат и видите на сколько кто ошибся. В случае с СП как получить ту же самую информацию? У вас вместо одной измеримой величины несколько связанных между собой достаточно сложным образом случайных. Чтобы получить какой-то сколько-нибудь значимый статистический результат в таких условиях, вам надо набирать статистику по команде сотни лет. Да и то не факт, что что-то выгорит.
А часы как раз могут плавать в зависимости от того, кто делал.
Так у нас всегда есть оценка того, кто делал. С-но мы всегда можем оценить оценку конкретного человека с его затратами на конкретную задачу.
Можно, наверное оценивать задачи типа "тут требуются 2 часа сеньор фронта, 3 часа миддла бэка, 5 часов джуна фронта"
А может лучше оценивать "нам надо 5 часов работы Васи и 2 часа работы Пети"?
Вы уже который раз повторяете этот тезис что сп удобнее т.к. сеньор работает быстрее джуна. Но я вам еще раз отвечаю — это не устраняет проблемы, т.к. основной разброс в скорости разработки между членами команды идет не из-за того, что Вася — сеньор, а Петя — джун, а из-за того, что Вася в силу специфичного опыта знает, как работать с задачей Х, а Петя — не знает. При этом они оба могут быть вполне себе мидлами и уже на другой задаче соотношение в скорости будет обратным. И СП эту проблему никак не решает, а вот оценивание в часах — решает прекрасно, т.к. вы видите кто на сколько задачу оценил и за сколько ее в итоге сделал исполнитель. Никакой этой информации в случае СП просто нет.
VolCh
18.06.2019 00:46Еще раз — с часами вы просто смотрите на результат и видите на сколько кто ошибся.
И что дальше с этим делаем? Увольняем? Игнорируем его мнение при следующих оценках?
С-но мы всегда можем оценить оценку конкретного человека с его затратами на конкретную задачу.
Так и что делаем?
А может лучше оценивать "нам надо 5 часов работы Васи и 2 часа работы Пети"?
А если только Вася будет делать? Или только Петя? Или Петя час поделает, а потом критикал баг прилетит и он отдаст доделвать Васе?
И СП эту проблему никак не решает, а вот оценивание в часах — решает прекрасно
СП как раз решает, а оценивание в часах — нет.
вы видите кто на сколько задачу оценил и за сколько ее в итоге сделал исполнитель.
Ну видим, и что? Вводим для него поправочный коэффициент? Просим его вводить такой коэффциент самостоятельно? С оценкой в СП понятно что делать на проваленном спринте: на ретроспективе смотрим мы оптимистично оценили скорость команды в целом или сработал какой-то риск — это простая информация, которую легко учесть в будущих планированиях или просто надо забыть. При оценке в часах всё гораздо сложнее получается. Субъективно, очень скоро понадобится человек, который будет назначать какие задачи кому делать и будет вводить поправочные коэффициенты. Самоорганизованной команды не будет больше.
VolCh
15.06.2019 11:20Вотерфол и ко позволяют достоверно и корректно планировать на годы вперёд. И итеративность в них есть, хотя циклы обычно больше.
Главное их отличие от аджайл подходов — они плохо работают с часто изменяющимися требованиями или когда требования до конца не ясны в принципе.
Apathetic
15.06.2019 11:24Главное их отличие...
Верно. А теперь скажите, насколько часто в наше время встречается возможность делать продукт без оперативного изменения требований?
MooNDeaR
15.06.2019 11:42Довольно часто, если подумать. Если вы делаете что-то сложнее интернет магазина, то требования к софту обычно долго прорабатывают аналитики, формируют вполне конкретные требования, которые не меняются кардинально на протяжении месяцев.
Apathetic
15.06.2019 11:48-1обычно долго прорабатывают аналитики
Компания, которая создает продукт, придерживаясь этой стратегии, нежизнеспособна. Не в современном мире.
Вы думаете, agile просто так что ли придумали? Чтобы персонально Вас позлить?
MooNDeaR
15.06.2019 11:50Ну, что я могу сказать на это. Или я работаю в вымирающих компаниях или вы неправы :) Время покажет :)
Apathetic
15.06.2019 11:53Я что-то не пойму — Вы то жалуетесь на agile и задалбывающую Вас эффективность, то говорите, что работаете в компаниях, работающих по устаревшим моделям. Мне нужно пояснение.
MooNDeaR
15.06.2019 11:55А мне не нужно :) Я устал тут уже отвечать в комментариях, быть может часов через 40-60 напишу вам ответ, потому что сейчас мне ваще не до этого :)
eboyko
16.06.2019 02:10+2Зарезервируем под это восемь сторипойнтов, а пока пофасилитируем команду, обсудим вэлью со стейкхолдерами, заполним гуглоформочку для ретроспективы, проведем дейли, оценим базфактор, соберёмся на груминг, выслушаем мысли техписателя о новом дизайне, и запишемся в собственную школу скрам-мастеров
В соседней статье был перевод: англ. scrum «схватка вокруг мяча». Но я никак не могу понять кто с кем схватывается, что в этой метафоре есть мяч, и зачем эта бурная деятельность в принципе нужна.
Не забываем также, что фасилитатор стоит компании каких-то невменяемых денег, распределив которые между членами команды можно неплохо улучшить коммуникацию; даже на психотерапевта останется.
zloy_stas
16.06.2019 00:04На самом деле оценки в сторипоинтах — это траты. Результат планирования должен ответить на один простой вопрос «А сколько задач команда сможет сделать в текущем спринте? И каков план по достижению этой цели?». Сможешь это сделать без сторипоинтов — молодец, не сможешь — тоже молодец. No estimates, все дела.
Apathetic
15.06.2019 00:37+1Повторюсь, вы можете не верить в это всё, можете всё это ненавидеть, как угодно. Факт останется фактом — научный подход повышает эффективность работы команды в разы, что доказывается опытом буквально десятков тысяч команд в самых разных областях.
MooNDeaR
15.06.2019 01:02Дело в этой самой "эффективности". Я вижу результат этой эффективности. Говнокод, приложения, жрущие ОЗУ гигабайтами и тонны бесполезной для технического специалиста терминологии. Это эффективность измеряется только для бизнеса.
Я могу понять это. Я за деньги бизнеса делаю вещи для бизнеса. Это совершенно не обязывает меня любить это дерьмо, что породил подобный подход к организации труда. Я делаю это потому, что нужны деньги, но как человек я стал несчастнее от деятельности, которая раньше приносила мне удовольствие. Отсюда и мой гнев.
Druu
15.06.2019 04:20+2научный подход повышает эффективность работы команды в разы, что доказывается опытом буквально десятков тысяч команд в самых разных областях.
Да вы о чем вообще? О каком научном подходе речь, если подавляющее большинство лидов не знакомы с курсом матстатистики достаточно, чтобы этот подход использовать?
ЗЫ: Мы ведь об одном и том же научном подходе говорим, правда? Построение математической модели рабочего процесса и оценка его параметров, формулирование стат. гипотез и их проверка — вот это вот все, да? Или вы стори поинты с фасилитацией научным подходом называете? :)
mad_nazgul
15.06.2019 06:55Да ладно вам. Не мешайте менеджерам и лидам грумиться. Уж лучше пусть грумиться чем доминируют (выясняют кто тут главный альфа-самец). Им приятно, а работу программисты все равно как-нибудь сделают.
Apathetic
15.06.2019 13:34Научным я называю подход, построенный на сборе метрик, их анализе и осмыслении. Построение гипотез и их проверка — тоже часть метода, разумеется.
Не очень понятен ваш сарказм, я разве что-то говорил о том, что знают или не знают "подавляющее большинство лидов"? Мы говорим об agile, или о вашем личном опыте наблюдения?Druu
15.06.2019 14:03Научным я называю подход, построенный на сборе метрик, их анализе и осмыслении. Построение гипотез и их проверка — тоже часть метода, разумеется.
А конкретно можно, на примере?
Мы говорим об agile, или о вашем личном опыте наблюдения?
Если исходить из контекста — вроде как об agile, но, с другой стороны, общеизвестно, что agile методы традиционно противопоставляют себя научным методам управления.
Так что, о чем конкретно вы говорите — мне ясно не совсем, вам это следует уточнить.
Что конкретно за методы, в каком смысле "научный подход", вот это вот все. Чтобы понимать друг друга.Apathetic
15.06.2019 19:31общеизвестно, что agile методы традиционно противопоставляют себя научным методам управления
У нас с Вами весьма разные представления о значении слова "общеизвестно", потому что я впервые об этом слышу. Впрочем, если хотите развлекаться демагогией — я не буду мешать.
VolCh
15.06.2019 14:08+1Ну так скрам так и работает по сути :) Ставится гипотеза, что команда сделает за спринт задач на N сторипоинтов, проверяется, смотрится результат, смотрится что было не так, выдвигает я следующая, проверяется…
Druu
15.06.2019 14:32Ну так скрам так и работает по сути :) Ставится гипотеза, что команда сделает за спринт задач на N сторипоинтов, проверяется, смотрится результат, смотрится что было не так, выдвигает я следующая, проверяется…
Статистическая гипотеза — это "с вероятностью 90% команда справится". А "или справится или нет" — это блондика и динозавр, а не статистика :)
Но вот то, что именно так скрам и работает — это вы в яблочко попали, действительно :)akryukov
15.06.2019 15:05+1Статистической гипотезой может быть и "команда справится с 90% объема".
Все очень зависит от бизнеса, но по моим наблюдениям, далеко не у всех фич есть объективный дедлайн (вроде отчетного периода бухгалтеров). Работу наваливают в духе "мы хотим чтобы еще вот это было" и приоритезируют в духе "фича А нам нужна быстрее фичи Б".Druu
16.06.2019 05:18Статистической гипотезой может быть и "команда справится с 90% объема".
С какой вероятностью? :)
Без указания вероятностной оценки это не стат гипотеза, а "или справится с 90% объема или нет". Стат. гипотеза — это гипотеза о свойствах случайной величины (ну если математически). А "справится или нет" — это не св-ва случайной величины.
Смысл вероятностной оценки здесь в том, чтобы потом определить степень достоверности отклонений. Ну, то есть — команда не справилась в силу каких-то причин (и надо делать ревью и разбираться) или то, что она не справилась — это просто стат. флуктуация, с-но ничего предпринимать не следует?
VolCh
15.06.2019 15:30Только первые несколько спринтов это "или справимся или нет". Потом набирается статистика, анализируюся тренды и делаются гипотезы вероятностные
0xd34df00d
15.06.2019 23:23Я участвовал в одном ресерч-проекте, в котором люди просто писали код
, бли строили модели.
Потом компания решила волей топ-менеджмента переходить на аджайл. Наняли скрам-мастершу, стали устраивать спринты и стенд-апы. Так как это ресёрч-проект, в беклоге было задач только на следующий спринт, а последующие задачи добавлялись по результатам спринта. Так вот, как этот цирк и карго-культ помогает оценивать, планировать и прогнозировать хоть что-то? Очевидно, что такой проект может занять как три спринта, так и тридцать, смотря сколько задач добавляется.
То есть, понятно, как это помогает планировать для проектов, где весь беклог известен вот прямо с первого дня. Но не все проекты же такие! К счастью.
И понятно, как это помогает бороться с безработицей: скрам-мастерше деньги есть за что платить, ПМ подтянулся, команда стала работать на 30% менее эффективно. Но цель же, наверное, не в этом.
Дико извиняюсь, если ответы на эти вопросы уже есть ниже, просто тыкните меня в соответствующий коммент тогда, пожалуйста.
Apathetic
15.06.2019 23:32Как Вы определили, что команда стала работать на 30% менее эффективно?
0xd34df00d
15.06.2019 23:37По личным оценкам времени на оверхед от всех этих планнигов, грумингов, спринт демо (мне особенно с работой над инфраструктурой на демо клёво было, ага) и по разговорам с коллегами.
Теперь-то вы ответите на мой вопрос о том, как аджайл помогает планировать и прогнозировать?
Apathetic
15.06.2019 23:43Нет, погодите, давайте разберемся. Вы стали тратить время на что-то помимо разработки, и на основании этого делаете вывод о том, что команда стала работать менее эффективно? Причем не просто менее эффективно, а аж на треть?
Прежде, чем задавать вопрос, как аджайл помог (или не помог) конкретно в вашем проекте планировать и прогнозировать, неплохо бы понять, возможно ли было планирование и прогнозирование до начала внедрения этого самого аджайла. Возможно, бизнес не имел никакого представления о том, что происходит на вашем рисерч-проекте, и насколько он близок к завершению?
0xd34df00d
15.06.2019 23:56Нет, стоп. Давайте с другой стороны, мухи отдельно, котлеты отдельно.
Вы утверждали, что аджайл помогает планировать и прогнозировать. Я привёл пример, как оно работало на практике, и конкретная эффективность там вообще боком (я понимаю, что для бизнеса в долгосрочной перспективе разработчики, работающие даже на 50%, но стабильно и предсказуемо, выгоднее разрабов, работающих на 100%, но с хрен пойми какими сроками).
Apathetic
16.06.2019 00:02Нет, Вы не привели пример, Вы привели собственное видение ситуации (напомню — без каких-либо объективных метрик Вы утверждаете о снижении эффективности команды на 30%). Я не ставлю под сомнение Ваш личный опыт, но я осмелюсь утверждать, что Ваше видение эффективности сильно разнится с видением владельца продукта.
0xd34df00d
16.06.2019 00:06Ладно, давайте попробуем ещё раз.
Я участвовал в одном ресерч-проекте, в котором люди просто писали код, бл и строили модели.
Потом компания решила волей топ-менеджмента переходить на аджайл. Наняли скрам-мастершу, стали устраивать спринты и стенд-апы. Так как это ресёрч-проект, в беклоге было задач только на следующий спринт, а последующие задачи добавлялись по результатам спринта. Так вот, как этот цирк и карго-культ помогает оценивать, планировать и прогнозировать хоть что-то? Очевидно, что такой проект может занять как три спринта, так и тридцать, смотря сколько задач добавляется.
Всё. Нет разговора ни о каком снижении продуктивности. Предположим даже, что она повысилась в 4 раза. Как с учётом такого стиля ведения списка задач это как-то помогает планировать, когда проект будет выполнен? Или аджайл позволяет планировать и прогнозировать только для тех проектов, где это было возможно и до его внедрения?
Apathetic
16.06.2019 00:14Я не могу ответить на Ваш вопрос, потому что я не знаю деталей Вашего проекта.
0xd34df00d
16.06.2019 00:16То есть, утверждение, что аджайл позволяет планировать и прогнозировать, неверно?
Ну, раз, как мы видим, это применимо не ко всем проектам (и почти все остальные проекты, в которых я участвовал, были аналогичными).
Apathetic
16.06.2019 00:26Аджайл в том или ином виде применим к любым проектам и областям, связанным с задачами, или, если хотите, неким дискретным потоком единиц работы. IT, производство, продажи — да, да и снова да.
Если Ваш проект из таких (а он, видимо из таких), то да, аджайл применим и к нему.
Но Вы как-то незаметно трансформировали вопрос "как аджайл помогает планировать" в вопрос "когда проект будет выполнен". А между тем, это два разных вопроса, и на второй аджайл редко пытается дать ответ. В чем он действительно помогает — так это в понимании, когда конкретная задача будет выполнена. Возможно, с этим в Вашем проекте были проблемы?
0xd34df00d
16.06.2019 00:28А бизнесу разве это важно? Ему важно, когда что-то новое выкатится на прод, и когда он сможет, например, разослать об этой новой фиче письмо клиентам. Не во всех проектах можно раз в две недели что-то выкатывать.
Бизнесу ж важен результат, а не задачи какие-то.
Apathetic
16.06.2019 00:39Если бизнес не понимает скорость работы команды — как он вообще может предполагать о том, "когда что-то новое выкатится на прод"?
0xd34df00d
16.06.2019 00:41Никак. Точно так же, как он не может этого предполагать, не имея полного беклога задач, но пусть даже зная скорость работы команды.
Apathetic
16.06.2019 00:44Вы что-нибудь слышали об итеративной разработке?
0xd34df00d
16.06.2019 00:46Именно поэтому задачи добавлялись в беклог по мере выполнения других задач.
Только как это поможет бизнесу?
Apathetic
16.06.2019 00:49Аджайл позволяет уверенне планировать итерацию, и понимать, какие фичи будут за неё сделаны. Следовательно, дает ответ на вопрос, "когда что-то новое выкатится на прод".
0xd34df00d
16.06.2019 00:53Опять же, не во всех проектах что-то можно выкатывать в прод за две недели разработки. Я про это специально написал три комментария назад выше по треду.
Apathetic
16.06.2019 01:11Я нигде не утверждал, что итеративная разработка требует релиза по итогам каждой итерации.
0xd34df00d
16.06.2019 01:21Тогда каким образом даётся ответ на вопрос о том, когда что-то выкатится на прод?
Apathetic
16.06.2019 01:36Если мы знаем, какую фичу хотим доставить, и примерно представляем, как её делать, то мы можем достоверно запланировать её разработку. Но понимаю, в чем затруднение.
0xd34df00d
16.06.2019 01:41и примерно представляем, как её делать
В том-то и дело, в ресёрч-проектах мы этого не представляем.
Apathetic
16.06.2019 01:48Приведите пример такой фичи, пожалуйста. Фичи, которая соответствует всем условиям:
а) должна быть поставлена пользователю
б) пользователь заранее должен быть оповещен о сроке
в) неизвестно, каким образом реализовывать эту фичу0xd34df00d
16.06.2019 01:50В (б) вы имеете в виду оповещение до начала работ над фичей или ближе к середине?
Apathetic
16.06.2019 01:53До момента, когда становится в точности понятно, каким образом реализуется фича.
0xd34df00d
16.06.2019 01:58Ну, так как очень часто это становится в точности понятно где-то незадолго до завершения всего проекта и на оценке в 80-90% готовности, когда остаётся подобрать хвосты, отплатить техдолг, и всё такое, и вообще уже на самом деле можно выкатывать...
- Оценка влияния новостей на фондовые рынки.
- Предсказание количества прочтений новостей.
- Компилятор для стороннего предметного языка, на который нет доков, кроме user guide. Этот проект я вообще в одну морду делал, неопределённостями там я с вами с радостью поделюсь.
Ну это вот просто так, сходу.
И, думается мне, нельзя все эти вещи выкатывать «по частям».
Apathetic
16.06.2019 02:20Первые две задачи не выглядят как задачи для разработчика оО
Третья действительно выглядит особенной, но и для работы с такими задачами есть методики, позволяющие более-менее контролировать процесс.0xd34df00d
16.06.2019 02:24Не понял, как не выглядят? Ну вот там как раз сидят всякие дейта сайентисты (а они не разрабы разве, аджайл к DS-проектам неприменим?), фигачат свои модели на тензорфлоу (я правда не зря NLP часто вспоминал), а я рядом приткнулся, делаю систему распределённой, надёжной, профилирую реализацию на плюсах, да мало ли.
Вторую задачу на самом деле тоже я делал, её тоже могу обсудить (но ML я люблю меньше, так что с меньшей радостью).
А чего за методики? Это ещё аджайл будет или уже нет? Ту задачу я-то делал в одиночку и поэтому тупо фигачил код, иногда репортя своему манагеру прогресс и, если есть какие-то проблемы, где они возникли и насколько они важны для целевых пользователей (может, какая-то сложнореализуемая фича языка и не нужна вовсе, например).
VolCh
16.06.2019 04:14Пока идёт чистый рисерч, если есть что продемонстрировать (прототип, обработки, бенчмарки и т. п.) — оно демонстрирует ся без выкатывания на прод и выдачи даже примерный сроков. Когда рисерч закончен, бэклог для мвп заполнен, тогда и начинаются сроки
0xd34df00d
16.06.2019 16:48Бизнесу там нечего демонстрировать. Вообще. Совсем.
Или в случае компилятора из списка выше, например, вы будете демонстрировать код парсера и построенное AST? Код оптимизатора? Зачем это бизнесу?
VolCh
18.06.2019 00:50AST и результаты бенчмарков с оптимизатором и без него.
Раз бизнес решил, что одна рисерч задача важнее другой и поэтому её делать надо первой или даже просто смог выделить что-то в задачу с конкретными ожидаемыми результатами, то результаты и надо демонстрировать, даже если результат "после двух недель сравнения разных доступных библиотек мы решили написать свою". Хотя бы вот так дословно, а лучше отчёт о сравнении.
0xd34df00d
18.06.2019 01:06А нафига эти бенчмарки бизнесу?
Есть обусловленные внешними условиями ограничения: скомпилированный код на характерном входе должен отрабатывать за 10 мс в 99% случаев, например. Как я это сделаю — буду пытаться оптимизировать тяжёлые AST, буду играться с JIT'ом, если первое не получится, упорюсь и начну писать под FPGA, если предыдущее не получится — это мои личные половые трудности.
В крайнем случае бизнесу интересно услышать «малой кровью я смог достичь только 50 мс в 95% случаев, чтобы оценить, могу ли я лучше, мне надо почитать про FPGA, про prior art по похожим задачам, на что у меня уйдёт неделя, и если это будет выглядеть реализуемым, то на реализацию уйдёт как минимум полгода; вам точно 10 мс нужно, или 50 сойдёт?»
VolCh
18.06.2019 01:19Я не знаю вашей специфики, потому привожу примеры исходя из своего опыта. Но в общем случае я стараюсь не то чтобы избегать задач "за месяц найти способ сделать что-то", а дробить их на задачи типа "попробовать такой способ, другой, третий" с конкретным критериями завершения и результатами которые можно показать типа "вот графики, так получилось добиться 50 мс в 90% случаев, продолжение работ по этой теме считаю перспективным только в увеличении процента"
0xd34df00d
18.06.2019 01:38Даже в вашей формулировке, обратите внимание, показывается не код оптимизатора, а бенчмарки с ним (то есть, он уже готовый в каком-то разумном виде). А это не неделя и не две работы.
Druu
18.06.2019 05:20Но в общем случае я стараюсь не то чтобы избегать задач "за месяц найти способ сделать что-то", а дробить их на задачи типа "попробовать такой способ, другой, третий" с конкретным критериями завершения и результатами которые можно показать типа "вот графики, так получилось добиться 50 мс в 90%
Вы в данном случае, получаете, будете тратить время на формирование четкого плана на три месяца вперед (agile такой agile, кек)? Или же каждую неделю будете пробовать по способу и отчитываться "попробовал Х, не получилось, пробую Y" без какого-то уточнения, сколько займет этот процесс (ожидаемо) в общем?
VolCh
16.06.2019 00:32Как раз там где весь бжкоог известен с первого дня аджайл особо не нужен.
0xd34df00d
16.06.2019 00:37Тогда я таки не понимаю, чему он помогает.
VolCh
16.06.2019 04:17Аджайл помогает в условиях постоянного изменения требований. Когда на начало работ ещё точного понимания а что нужно — нет.
mva
16.06.2019 05:08я там выше по треду привёл пример админской работы (всего лишь одного проекта из десятков). И там, о да, "постонное изменение требований" во все поля. И попросил рассказать как в таких условиях применять сторипоинты.
0xd34df00d
16.06.2019 16:49А чем именно он помогает?
Раньше утверждалось, что он помогает планировать. Планировать конечные сроки в условиях постоянного изменения требований, наверное, затруднительно.
VolCh
18.06.2019 00:59Ну собственно аджайл, как я понимаю, возник затем чтобы избежать планирования конечных сроков в условиях постоянного изменения требований.
0xd34df00d
18.06.2019 01:07Вы отвечаете на вопрос о том, зачем он возник, а мой вопрос немного другой.
VolCh
18.06.2019 01:20Он помогает не тратить ресурсы на долгосрочное планирование путём отказа от него.
0xd34df00d
18.06.2019 01:38Если аджайлом называть произвольную методологию без долговременного планирования, то тогда да, конечно, это имеет смысл. Однако, обычно имеют в виду не это.
VolCh
18.06.2019 14:14Я утрировал пункт "Готовность к изменениям важнее следования первоначальному плану". Некоторые методологии отказываются от долгсрочного планирования в принципе, другие нет, но все принижают его ценность по сравнению с классикой.
Apathetic
16.06.2019 00:42Ну это спорно, на самом деле. Аджайл — это же не только оценка задач (она вообще не во всех аджайл-подходах нужна) и не только планирование, это вообще набор способов сделать процесс гибким и эффективным. Это включает в себя, в частности, методы анализа, ретроспективы, контроля и так далее. Если есть возможность всё это применять — почему бы нет?
VolCh
16.06.2019 04:20Гибкость зачем нужна? Для адаптации к изменяющимися условиям. В классическом проекте если условия существенно изменились, проект по сути закрывается и начинается новый, пускай и с использованием наработок закрытого.
mi76554
16.06.2019 12:25>позволяют планировать и прогнозировать
в банальном проектном управлении есть такая штука как оценка рисков
и оценка отклонения проекта и его составляющих
при отклонении/возникновении риска управляющий просто пересчитывет ход работ и распределение ресурсов.
да, при этом надо работать с людьми, слушать, объяснять, договариваться.
никто не «позволит» вам прогнозировать, это всегда ваш риск
будущего никто не знает, оценить вероятности успеха/успеха возможно только при изучении, достаточном знании и наблюдении всех состоявляющих проекта, в частности работы тех самых людей
и все равно управление проектами-кейсами в большей части исскуство, постигаемое человеком на практике
> «традиционные» методы разработки, типа того же waterfall, не справляются от слова никак.
когнитивное искажение.
не справляются люди, которые не имеют достаточных компетенций в управлении проектами, в частности не
— имеют достаточного знания предмета
— окружения проекта и его стейкхолдеров
— людей, создающих продукт
— поставок и компонентов
— критичности
— договороспособности по целям проекта/кейса
Ну, если кому-то попсовые методы помогают просто таки собраться и довориться, то флаг в кулак.
Но лучше помогает хороший человечный профайлинг и простое деловое обсуждение, с часами жизни и целями, с четким пониманием выгоды и росков каждого. И лидерство как результат работы, компетентности и адекватного социального ранга.
zloy_stas
16.06.2019 00:01> Классический waterfall, к слову, не так уж и плох для подавляющего большинства проектов с конечным сроком жизни.
для IT проектов waterfall не хорош примерно никогда. Главное преимущество итеративной и инкрементальной разработки не в точности оценок или плана, а в управлении рисками. Частые релизы снижают интеграционные и продуктовые риски. В классических waterfall проектах, все риски скопом ловишь в фазе интеграционного тестирования.VolCh
16.06.2019 00:37Классический как раз тоже с итерациями, просто они заметно реже.
zloy_stas
16.06.2019 01:03Классический — это тот, который описан в статье винстона ройса, там одна итерация. Если говорить про массовое производство, то для снижения рисков тоже используются итерации/инкремент — НИОКР, прототипы и т.д. Только в массовом производстве нельзя сделать дешево инкремент — только отзыв партии в случае «бага», или нераспроданный товар на полках, в software дорабатывать инкрементам значительно дешевле. И надо этим пользоваться во всю.
funca
15.06.2019 16:51Пока вы занимаетесь творчеством водночу, чисто для себя, вы вольны делать это когда хочется. Как только начинаете его продавать как работу, вы обязаны считаться с клиентами и заниматься им когда надо.
Толковые и бестолковые сотрудники есть как среди менеджеров так и разработчиков. Но если бросаться в крайности, то ни какого диалога не получиться, а проблемы сами собой не решаться. Ищите точки соприкосновения.
g_DiGGeR
16.06.2019 12:25Менеджеры оказались не способны помогать разработчикам разарабатывать, и организовывать.
Поэтому им пришлось все свою работу скинуть на плечи разработчикам, а самим делать митапы и фасилитировать встречи. Иначе поймут, что они не нужны и их уволят.
Я правильно понял, что на текущий момент автор не руководит тимой, так как вся команда QA разошлась отдельными QA специалистами по Dev командам?JuliaYuka Автор
16.06.2019 12:28Я правильно понял, что на текущий момент автор не руководит тимой, так как вся команда QA разошлась отдельными QA специалистами по Dev командам?
Команды же теперь нет, так что и прямого (привычного/стандартного) управления ее деятельностью тоже.
RNigmatullin
16.06.2019 12:29На первый взгляд Вы все верно и правильно говорите, но хочется поделиться одним примером из жизни. У нас есть медицинский софт, иногда так сложно что то сделать, исправить, адаптировать. И мне разработчики говорят, не тем путём идешь, можно договориться, пиши сразу мне, а я найду кто и как это исправит. Да несколько раз писал и действительно все решалось. Но вот незадача, от того, что это не согласовывалось, не документировалось — все это шло в разрез с документацией и при очередном обновлении это сломало логику работы и был простой. В итоге той компании пришлось заплатить штраф за 1 500 000.
Возможно Вы скажите, что сами виноваты и т.д., но для реализации или изменения потребовалось очень много согласований и разрешений. По этому важно обсуждать вместе, вся команда должна знать, понимать все изменения вносимые.
eboyko
16.06.2019 16:05> процесс SCRUM-разработки, позволяющий в жестко фиксированные и небольшие по времени итерации, называемые спринтами (sprints)
Скрам с первых же страниц возводит входной барьер, подменяя и запрещаяя использовать устоявшиеся понятные термины: вместо сроков спринты и сторипойнты. Уж не пытается ли когорта эффективных менеджеров защитить воображаемую вотчину от посягательств здравого смысла?
На практике скрам обмазывает людей процедурами, чтобы снизить их эффективность до прогнозируемого уровня. Меньше стресса из-за сорванных сроков, премии за стабильную поставку, а также чудовищные (если хотите, транзакционные) издержки и ощутимая демотивированность людей на местах.Apathetic
17.06.2019 19:04На практике
Судя по вашему комментарию, Вы понятия не имеете о том, что происходит на практике. На практике эффективность команд, начинающих работать по какой-либо из agile-методологий, возрастает в разы.
eboyko
17.06.2019 19:26> Судя по вашему комментарию, Вы понятия не имеете о том, что происходит на практике
Это единственный аргумент тех, кто в секте?
> эффективность команд возрастает в разы
В чем вы измеряете эффективность? (Уж не количеством ли одобрительных голосов, выраженных на ретроспективе?) Приведите, пожалуйста, пример такого расчета. Я честно гуглил, но нахожу только списки возможных метрик (улучшение одной, как всегда бывает, приведет к снижению других) и абстрактные рассуждения.Apathetic
17.06.2019 19:27Если Вы не знаете, как оценить эффективность работы команды, то как Вы можете утверждать, что agile не способствует её росту?
eboyko
17.06.2019 19:35Давайте все же посмотрим на пример расчета, а после вернемся к обсуждению.
Apathetic
17.06.2019 19:48-2Давайте без "давайте"? Я Вам, вроде как, ничем не обязан. Если Вы не знаете, что такое эффективность и при этом беретесь о ней судить — то какой смысл мне Вам что-то объяснять? Разберитесь со своей агрессией для начала, а после вернемся к обсуждению.
eboyko
17.06.2019 19:51Слив засчитан.
Apathetic
17.06.2019 19:55Если Вашей целью было "слить" кого-то — ради бога.
eboyko
17.06.2019 20:08Читатели во множестве тредов пытались добиться от вас информации о том, как работают основополагающие принципы методологии; буквально на каждого вы обиделись. Браво.
Apathetic
17.06.2019 21:44Понимаете, когда я отказываюсь продолжать дискуссию с человеком, настроенным агрессивно, настроенным на конфликт, — это не обида, это попытка сохранить себе нервы.
В моём представлении, дискуссия — это некий процесс обмена мнениями, попытками донести свою точку зрения, и обязательным условием этого процесса является взаимоуважение. Если его нет — то зачем мне эта дискуссия?
И да, я знаю, что это интернет, и тут всегда нужно быть готовым к тому, что тебя пошлют на три буквы. Но идти или нет, и продолжать ли слушать посылающего — этот выбор я оставляю за собой.
Druu
18.06.2019 05:25В моём представлении, дискуссия — это некий процесс обмена мнениями, попытками донести свою точку зрения
Ну вот у вас человек попросил раскрыть свою точку зрения, а вы в ответ: "Давайте без "давайте"".
Ну вам же конкретный вопрос был задан — какие вы имели ввиду метрики эффективности и как они использовались?
Потому что вы же понимаете, что таких метрик дохрена? И ваш визави может спокойно выбрать любую и сказать: "вот по этой метрике agile обосрался". И что дальше, вы скажете "это плохая метрика", но при этом не уточните, какая вам нужна? И, видимо, плохими будут все, в которых agile не блещет?
https://ru.wikipedia.org/wiki/%D0%9D%D0%B8_%D0%BE%D0%B4%D0%B8%D0%BD_%D0%B8%D1%81%D1%82%D0%B8%D0%BD%D0%BD%D1%8B%D0%B9_%D1%88%D0%BE%D1%82%D0%BB%D0%B0%D0%BD%D0%B4%D0%B5%D1%86
Am0ralist
17.06.2019 20:51На практике эффективность команд, начинающих работать по какой-либо из agile-методологий, возрастает в разы
Вы ничего не понимаете! На практике пьющие гомеопатию выздоравливают в разы быстрее!
Извините, не могу удержаться от проведения таких аналогий. Потому что если попросить вас ссылки на научные статьи, то что я получу в ответ?Apathetic
17.06.2019 21:47Прошу прощения за то, что отсылаю к поисковику, но если погуглить "agile effectiveness metrics", можно найти немало интересного на эту тему.
VolCh
18.06.2019 01:04Как по мне, то скрам призван повышать мотивированность работы путём изоляции, что ли, команды от микроменеджмента бизнеса.
0xd34df00d
18.06.2019 01:08Мой опыт показывает, что пока что получалось только наоборот. Представители бизнеса начинали присутствовать на стендапах и планнингах, обижались на задачи про технический долг, задавали вопросы о технических деталях с коннотациями «почему ты неделю работал, а в результате ничего визуально не пердит и не свистит», и так далее.
VolCh
18.06.2019 01:24Для меня ваше описание выглядит как нарушение принципов скрама. "почему не пердит? — нет в задаче требования пердеть"
0xd34df00d
18.06.2019 01:39Ну сорян, какой был.
Выглядит это скорее как желание оптимизировать издержки путём ещё более глубокого микроменеджмента.
eboyko
18.06.2019 01:16Соглашусь с 0xd34df00d: скрам в полный рост требует определения получателя фичи (стейкхолдера или как там было?), и его присутствия на встречах с целью сбора требований, критериев приемки, формирования диалекта и вообще модели.
VolCh
18.06.2019 01:25Только на фазах формулировке задачи и её приёмки. Грубо — два дня из 10 :)
eboyko
18.06.2019 01:39В начале жизненного цикла проекта на это может уходить едва ли не весь спринт. (Не всей команды, конечно, но трех человек и представителя — легко.)
Не так давно шесть дней вылетело. В первые три обо всем договорились и начали декомпозицию. Во второй понедельник руководство огласило некий аспект, который свел на нет 75% проведенного планирования. Сами, конечно, дебилы, что не предположили, не уточнили — но руководство на то и руководство, что не доступно с одного клика.
AlexunKo
15.06.2019 01:59+3Недоменеджеров или в инкубаторы или в ВУЗы или на минималку. Реальным проектам нужна компетентность, а не очередной начинающий лид.
cross_join
15.06.2019 14:33Тимлид — это руководитель группы или есть разница? Цель вопроса вовсе не поглумиться, а объединить в контексте с «N ошибок руководителя группы»
JuliaYuka Автор
15.06.2019 15:14Если под группой людей понимается команда, то почему нет? Другое дело, если группа — это ребята из разных команд со своими проектами и целями внутри них. Возможно кто-то иначе ответит на ваш вопрос.
funca
15.06.2019 16:27+1Рабочая группа и команда отличаются в механиках взаимодействия между их членами и мотивацией. Поэтому управляются по разному. Ещё можно разделять роли техлида — кто разбирается в производстве и тимлида — кто может драйвать людей.
cross_join
15.06.2019 17:41Вроде бы «команда» пришла из спорта для замены «рабочей группы» в связи с затертостью и забюрокраченностью термина или нет? Я понимаю разницу между рабочей и проектными группами, а вот между группой и командой — не вполне.
Zoomerman
15.06.2019 18:10Группа — это несколько объектов, объединенных одним или более общим признаком.
Команда — не голосовая — это группа разнообразных объектов, способная решать какую-либо задачу или выполнять работу с измеряемым параметром эффективности.
Группа определяется путём обобществления, команда подбирается путём детализации. Т.е. в группе важно делать упор на то, что людей объединяет. В команде же важно, чем один человек отличается от другого и как это укладывается в общее дело.
Для группы замена одного члена другим не принципиальна — всё равно в группе у всех одинаковый признак группы и группа при этом не перестает быть группой. В команде же замена одного члена другим практически невозможна. Выбытие участника команды останавливает всю команду. Подбор замены не всегда возможен.
Если разложить на столе детали редуктора — это будет группа запчастей. Общий признак — они предназначены для редуктора. На столе могут лежать несколько разобранных редукторов и это всё будет одна группа запчастей редуктора.
Но если собрать часть запчастей в редуктор — это уже будет команда, применительно к технике — узел, агрегат — в котором каждый член выполняет свою индивидуальную функцию, а вместе они передают крутящий момент от источника к получателю.cross_join
16.06.2019 20:40Рабочая группа как раз и предназначена «решать какую-либо задачу или выполнять работу с измеряемым параметром эффективности»
VolCh
15.06.2019 21:37Рабочая или проектная группа в моём понимании: люди, собранные вместе для решения конкретных задач. Они могут быть командой, а могут не быть. Командой их делают раздкляемые всеми или почти всеми общие цели и консенсус о способах их достижения. Задача лида или другого менеджера с точки зрения бизнеса — создать из группы команду, достижения целей которой будет достиженим целей бизнеса. Команда может не получится в принципе или команда получится, но цели у неё будут другими.
cross_join
16.06.2019 20:43Я все больше склоняюсь, что тимлид — лидер неформальный, как капитан команды в спорте. Руководитель группы — формальная должность, не всегда совпадающая с неформальным лидером.
VolCh
18.06.2019 01:08Я большую склоняюсь к мнению, что основная задача формального тимлида — это сделать из группы работу работающих работников команду, работающую на достижение поставленных перед ней целью. Успешное делегирование этой задачи или её части неформальному лидеру группы — один из способов её достижения.
cross_join
18.06.2019 11:18Бригада ударников коммунистического труда, практически :) О «тимлидах» в 1950-е феерические фильмы снимали.
Zoomerman
15.06.2019 17:31-2Лидам и менеджерам нужно помнить:
1) В туалет ходят с туалетной бумагой, а в душ с полотенцем; и не наоборот. Агил используют в поддержке продукта, ватерфол в разработке.
2) Если для планирования нужна консультация кодера/разработчика, то лид/менеджер — никто. У каждого своя работа, писать код и строить планы — это разные вселенные. Менеджеру сдать проект нужно как можно быстрее, а разработчик хочет сделать как можно надежнее. Каким хреном они могут вообще сами договориться? Цели разные.
3) Команда — это не группа. В группе может быть сколько угодно каких угодно человек. Но в команде каждый человек берет на себя часть от 5ти ролей. И ранжировать людей джун-мидл-сеньор в команде невозможно, т.к. у всех разные роли и за счет этого команда действует как единый механизм.
А в целом всем нам знакомо, что происходит, когда молодого необразованного амбициозного человека назначают начальником над соплеменниками. Коллеги, не расслабляйтесь, изучите матчасть по скрамам, агилам, ватерфолам и командам. И посылайте недоменеджеров и недолидов сразу, как услышите их «фирменный» сленг («фасилитация», например).
Человеку свойственно за англицизмами и подменой понятий скрывать недостаток знаний и навыков.
На месте работодателя я бы попросил удалить эту статью, чтобы не позорить компанию.
lappy
16.06.2019 11:09насколько вырос ваш доход в додопицце при переходе с должности тестировщика на должность их лида?
JuliaYuka Автор
16.06.2019 11:59В Dodo Pizza я пришла сразу на должность лида команды тестировщиков. Для меня тогда не было важно насколько увеличится мой доход при переходе с должности автоматизатора другой компании на должность лида в Додо. Сейчас нет команды тестировщиков как отдельной сущности, нет и необходимости ими отдельно управлять. Скорее теперь моя роль преимущественно в наблюдении за ними, консультации при необходимости, помощи в прокачке навыков по автоматизации и подобное.
lappy
16.06.2019 12:42ну окей, насколько вырос ваш доход при переходе с должности тестировщика в другой компании на должность лида в додо?
ttas
16.06.2019 11:44JuliaYuka, а вы пользуетесь каким-то автоматизированным инструментом эффективного распределения задач между членами команды? Если да, то каким?
JuliaYuka Автор
16.06.2019 12:17Когда у нас была отдельная QA команда мы использовали обычный Kaiten с нашей отдельной доской и бота, который помогал ребятам взаимодействовать с разными системами эффективнее. Сейчас у нас есть гильдийная доска (исследовательские задачи) и доска для бота (разработки и поддержки) без какой либо автоматизации по распределению задач между ребятами. С удовольствием бы узнала, а какой же инструмент используете вы, и как в нем автоматизирован процесс распределения задач.
GoForBroke
16.06.2019 12:30№2 очень похоже на комбинацию «Мелочная опека» + «Гений не на своем месте» из книги «Как пасти котов» Дж. Х. Рейнвотера.
Очень советую книгу, читал когда готовился к аналогичной должности.
botyaslonim
18.06.2019 10:54Я работал в нескольких IT-компаниях, и к тимлидам в сущности одна главная претензия: они устраняются от какого бы то ни было управления. Наверное, мне невезло, но тимлид везде был — самый опытный программист, который больше всех фигачит код. Самое главное для работника, который занимает эту должность — переключить мозги с непосредственно кодинга на управление ресурсами.
VolCh
18.06.2019 14:25Есть мнение, что тимлид вообще должен быть отстранён от непосредственно кодинга, чтобы эффективно управлять. Или грамотно делегировать полномочия по управлению сеньорам, подчинив им миддлов и джунов.
kost
Можно перевести это на русский или английский язык?
JuliaYuka Автор
"Фасилитировать встречу" означает помогать участникам встречи концентрироваться на её цели, а также мотивировать на активное обсуждение и принятие решений. У нас в Dodo создана школа scrum-мастеров, выпускники которой помогут договориться даже самым молчаливым.
kinall
Разве этим не модератор занимается? А вообще на описание тамады похоже))
warranty_voider
В принципе да, я думаю что было выбрано слово «фасилитатор» потому что на публичных дискуссиях (с участием модератора) айтишники бывают не так часто, поэтому в сознании большинства модератор это такой человек с бан-хаммером, задача которого пресекать всякие непотребства. А фасилитатор наоборот занимается тем, что способствует диалогу разных участников
MacIn
facilitate [f?'s?l?te?t] гл.
общ. способствовать; содействовать; оказать содействие; поспособствовать
образ. вести, проводить семинар и т.д.