Comments 48
Зам техдира не знает что такое scrum и удивляется демо?
Ну почему сразу не знает? Scrum скраму рознь. Многие просто не умеют его готовить. А demo во многих компаниях быстро превращается в формальность и умирает.
Вопрос в том, чтобы заставить все эти полезные штуки работать (и тогда в них поверят и к ним подключатся разработчики).
Автор как раз пишет про процессы и как они настроены в его новой компании.
Автору: Спасибо, было интересно прочитать. Надо продолжать делать demo. :)
Помимо продолжительности, какие еще проблемы с покером планирования у вас были?
Вопрос в том, чтобы заставить все эти полезные штуки работать (и тогда в них поверят и к ним подключатся разработчики).
Автор как раз пишет про процессы и как они настроены в его новой компании.
Автору: Спасибо, было интересно прочитать. Надо продолжать делать demo. :)
Помимо продолжительности, какие еще проблемы с покером планирования у вас были?
Спасибо, рада что интересно.
С покером еще был следующий момент, если человек не разбирается в задаче и это не его область ему обычно сложно оценить сложность, тут обычно видно по голосованию — если все хорошо объяснено оценки довольно кучные. Оценки сильно отличающиеся от остальных как правило показывают, что человек, который их ставил не понимает как делать задачу.
С покером еще был следующий момент, если человек не разбирается в задаче и это не его область ему обычно сложно оценить сложность, тут обычно видно по голосованию — если все хорошо объяснено оценки довольно кучные. Оценки сильно отличающиеся от остальных как правило показывают, что человек, который их ставил не понимает как делать задачу.
Ну почему сразу не знает? Scrum скраму рознь. Многие просто не умеют его готовить.
Потому что достичь достаточно высокой должности и не увидеть как его готовят в ай-ти надо ещё очень сильно постараться.
P.S. Лично я scrum не люблю. Но некоторые вещи вполне себе используются.
Достаточно вспомнить старое слово «планерка»
Про scrum: одно дело знать о том, что это и совсем другое видеть как это реально используют.
Про демо: думаю нужно небольшое углубление. Понятно, что при изменении интерфейса программы или добавления новых функций их легко показать. Так как первая компания была продуктовая там большую долю времени занимала оптимизация работы системы. И вот осознания, что это тоже можно показывать на демо не было. А оказывается можно, на пальцах, высокоуровневым языком, но можно.
Про демо: думаю нужно небольшое углубление. Понятно, что при изменении интерфейса программы или добавления новых функций их легко показать. Так как первая компания была продуктовая там большую долю времени занимала оптимизация работы системы. И вот осознания, что это тоже можно показывать на демо не было. А оказывается можно, на пальцах, высокоуровневым языком, но можно.
А про минусы, пожалуйста
Поддерживаю!
UFO just landed and posted this here
Есть такая проблема. Мне кажется это от того, что люди не понимают зачем им эта информация, у них не возникало в ней нужды, а им ее уже дали.
Мне all hands очень нравится, я рада, что они есть. Можно провести параллель с бегущим отрядом и его командиром. На all hands командир периодически говорит, например «Эй, ребята, я бегу на Север, буду искать клад старого Джо, мне нужна будет помощь в поиске и раскопках.» И я могу для себя понять — хочу ли я туда, интересно ли мне это, насколько я считаю интересным и правильным бежать и раскапывать клад Джо. В общем я рада, что эта информация у меня есть.
Мне all hands очень нравится, я рада, что они есть. Можно провести параллель с бегущим отрядом и его командиром. На all hands командир периодически говорит, например «Эй, ребята, я бегу на Север, буду искать клад старого Джо, мне нужна будет помощь в поиске и раскопках.» И я могу для себя понять — хочу ли я туда, интересно ли мне это, насколько я считаю интересным и правильным бежать и раскапывать клад Джо. В общем я рада, что эта информация у меня есть.
Очень печально когда зам. техдира в описании процесса применяет такие слова как «мне очень нравится»
Это не критерий для оценки эффективности workflow
Это не критерий для оценки эффективности workflow
Спасибо за коммент. У меня часто рождается именно ощущение — хорошо, нравится, и если покопаться оно чем-то обосновано. Тут поделилась больше эмоциональной частью, и после вашего комментария, поняла. что не хватает собственно почему я считаю это полезным.
Чем на мой взгляд хороши all hands meeting?
Чем на мой взгляд хороши all hands meeting?
- Повышения прозрачности со стороны руководства для сотрудников. Как следствие повышение доверия. Озвучивания целей и курса компании дает возможность человеку следовать этому курсу осмысленно, видя цель, больше вероятности, что к ней придешь. Это инструмент распространения видения цели на всю компанию. Сам каждый решит будет он лично двигаться к этой цели или нет, но знать о ней он по крайней мере будет.
- Формирования у разработчиков общей картины, видения происходящего. Я сталкивалась с такой проблемой – продукт разросся и разработчик пилит какую то маленькую часть, но при этом что вокруг нее не представляет. Нет понимания бизнес процессов и потребностей клиентов, на мой взгляд all hands способствует формированию общей картины.
- Возможность непосредственно пообщаться с руководством компании. Иногда у человека зреют какие-то вопросы, которые хочется задать собственнику (или директору) компании, но возможности это сделать нет. All hands такую возможность предоставляет.
С подлючением! И это стоило статьи?
Bridge call конечно решает проблему, но зачастую прескучнейшее занятие, часто не хватает визуализации (расшаривания экрана) и многие участники не вовлечены активно, поэтому мягко говоря скучают и страдают фигней во время таких звонков.
Визуализации очень не хватает. Особенно в сочетании с отсутствующим доступом это, например, меня доводит. Проблема есть, а сделать что-то с ней я не могу. Вид пытки такой. Как вариант озвучивать те действия, которые бы я сделала в этой ситуации и задавать вопросы.
У нас bridge call (или war room, если всё очень серьёзно) делается одновременно с webex — визуализация присутствует обычно.
TeamViewer не способен от этого спасать?
Я бы добавил еще один пункт, который присутствует в американских компаниях, это совещание, которое собирают по окончанию проекта и где все участники высказываются, о положительных и отрицательных моментах которые были в проекте, а так же пожеланиях по улучшению работы в будущем.
Когда же эта ересь со Scrum отойдет в мир иной?
Я могу только описать свой месячный опыт наблюдателя в одной из американских корпораций.
Итак, по порядку. Stand up meeting. Народ рассказывает, как он классно написал SQL скрипт или что компьютер не имеет доступа к каким-то там ресурсам. Один, якобы, Java разработчик изучает отличия JRE от JDK. Судя по всему, монотонное жужжание некоторых докладчиков и не особо интересно остальным, но традиция должна быть соблюдена.
Каждое утро, три идиотских вопроса: Что сделано, Что планируется делать, Есть ли проблемы.
Тут настоящий разгул для талантливых с виду натур, можно вступить в бессмысленную полемику или даже повысить значимость своей работы, придумывая на ходу чрезвычайные сложности которые могут возникнуть при создании какого-либо тривиального действа.
Мой любимый демонстрация. Неделя не должна была пройти даром. Бизнес заказчик должен знать каждую деталь разработки, несмотря на то, что «пациент» еще не в полной кондиции, но бизнес хочет знать как там у нас с дела со всеми аспектами работы. Команда разработчиков загодя планирует демонстрацию, по сути это репетиция, которая должна быть близка к основному спектаклю.
Наиболее отчаянные разработчики показывают одну и ту же демонстрацию с небольшими, я бы сказал, косметическими изменениями. Последние, единогласно признаются существенным достижением в нашем проекте. Овации, благодарственные речи, судя по всему ничего не понимающих менеджеров. Радость и всеобщее ликование накрывают команду.
Идем дальше, планирование работ. И вот появляется список каких-то бизнес кейсов, они должны быть решены в следующей итерации этого безумного Scrum вертепа. По внешнему описанию и общему дух кейсы поступают прямо по спутниковому каналу с одного из центральных офисов на Марсе. Команда виртуозов сразу же берется за интерпретацию сиих даров высокоразвитых цивилизаций и производит оценку трудозатрат освоения новых технологий. Для этого участники сбора, по старинке, перекидываются в картишки, с некоторыми неясными непосвященному глазу номерками, которые являются некой заменой обычных трудозатрат. Общее голосование выносит свой безжалостный вердикт.
Тут вступает детальное обсуждение. 15 минут можно смело потрать на обсуждение того факта, как же здорово сделать журналирование работы Java web-сервиса. Бизнес заказчик должен знать все детали сего сакрального действа, другой же части так же нужно всячески показать важность оного.
Как итог, 30-40% времени разработчика тратится на звонки, встречи и прочую активность такого рода.
Я так и не смог дать ответ, почему дела обстоят именно так.
И не надо на себя примерять шкурку американского опыта, у них весьма распространен наем персонала по телефону. Я думаю, сложно сделать вывод, что мы из «Одной стаи» основываясь только на нескольких телефонных звонках. Вот и придумывают всякие управленческие костыли для работы с такими «мутными командами».
И да, минусы от адептов секты Scrum только приветствуются!
Я могу только описать свой месячный опыт наблюдателя в одной из американских корпораций.
Итак, по порядку. Stand up meeting. Народ рассказывает, как он классно написал SQL скрипт или что компьютер не имеет доступа к каким-то там ресурсам. Один, якобы, Java разработчик изучает отличия JRE от JDK. Судя по всему, монотонное жужжание некоторых докладчиков и не особо интересно остальным, но традиция должна быть соблюдена.
Каждое утро, три идиотских вопроса: Что сделано, Что планируется делать, Есть ли проблемы.
Тут настоящий разгул для талантливых с виду натур, можно вступить в бессмысленную полемику или даже повысить значимость своей работы, придумывая на ходу чрезвычайные сложности которые могут возникнуть при создании какого-либо тривиального действа.
Мой любимый демонстрация. Неделя не должна была пройти даром. Бизнес заказчик должен знать каждую деталь разработки, несмотря на то, что «пациент» еще не в полной кондиции, но бизнес хочет знать как там у нас с дела со всеми аспектами работы. Команда разработчиков загодя планирует демонстрацию, по сути это репетиция, которая должна быть близка к основному спектаклю.
Наиболее отчаянные разработчики показывают одну и ту же демонстрацию с небольшими, я бы сказал, косметическими изменениями. Последние, единогласно признаются существенным достижением в нашем проекте. Овации, благодарственные речи, судя по всему ничего не понимающих менеджеров. Радость и всеобщее ликование накрывают команду.
Идем дальше, планирование работ. И вот появляется список каких-то бизнес кейсов, они должны быть решены в следующей итерации этого безумного Scrum вертепа. По внешнему описанию и общему дух кейсы поступают прямо по спутниковому каналу с одного из центральных офисов на Марсе. Команда виртуозов сразу же берется за интерпретацию сиих даров высокоразвитых цивилизаций и производит оценку трудозатрат освоения новых технологий. Для этого участники сбора, по старинке, перекидываются в картишки, с некоторыми неясными непосвященному глазу номерками, которые являются некой заменой обычных трудозатрат. Общее голосование выносит свой безжалостный вердикт.
Тут вступает детальное обсуждение. 15 минут можно смело потрать на обсуждение того факта, как же здорово сделать журналирование работы Java web-сервиса. Бизнес заказчик должен знать все детали сего сакрального действа, другой же части так же нужно всячески показать важность оного.
Как итог, 30-40% времени разработчика тратится на звонки, встречи и прочую активность такого рода.
Я так и не смог дать ответ, почему дела обстоят именно так.
И не надо на себя примерять шкурку американского опыта, у них весьма распространен наем персонала по телефону. Я думаю, сложно сделать вывод, что мы из «Одной стаи» основываясь только на нескольких телефонных звонках. Вот и придумывают всякие управленческие костыли для работы с такими «мутными командами».
И да, минусы от адептов секты Scrum только приветствуются!
Я во многом согласна, именно поэтому хочу о самой методологии написать отдельно, мои ощущения и впечатления от работы во многом совпали с Вашими. В Scrum понравился именно подход к оценки задач.
И не надо о ней писать. Чем меньше балбесов знают о каком-то сектантском учении тем лучше нам нормальным котам, которые гуляют сами по себе. Впрочем, даже знание этих бедняг не остановит нас.
Сижу ржу, хочется поделится первоначальным шоком «Нет, правда, правда они тратят на это по 1 часу в день? и 2-3 на груминг в неделю? и еще retrospective и еще sprint planning? А когда работать?» и потом все-таки были положительные моменты, которые можно стянуть и применить с пользой.
Для понимания, нужен ли скрам разработчикам или введен начальством в качестве «серебряной пули» — достаточно спросить как оценки времени выполнения задач соотносятся с реальностью и как это соотношение меняется со временем. Если это где-то 0.85-0.9 или растет к этому — скрам помогает. Если же программисты «промахиваются» раза в два и это не меняется месяцами — «что-то здесь не там».
Ну и для продвинутых/наглых — можно поинтересоваться кто ответственен за скрам-оф-скрамс и есть ли постоянный скрам-консультант. Если СОС организует начальство, а консультант торчит в фирме на постоянной основе — ничего путного из этого не выйдет, ритуалы так и останутся ритуалами а время будет бесполезно потеряно.
Ну и для продвинутых/наглых — можно поинтересоваться кто ответственен за скрам-оф-скрамс и есть ли постоянный скрам-консультант. Если СОС организует начальство, а консультант торчит в фирме на постоянной основе — ничего путного из этого не выйдет, ритуалы так и останутся ритуалами а время будет бесполезно потеряно.
Любую идею можно саботировать или довести до абсурда. Скрам — это не методология, а фреймворк, который нужно подстраивать под каждый конкретный случай. В основе Скрама лежит некоторое количество вполне здравых мыслей — что команда способна сама себя регулировать; что двигаться стоит небольшими шагами, чтоб суметь при надобности быстро переориентироваться; что важно добиться понимания всеми того, что делается, в каком виде проект и сколько времени он займет; что в нынешних условиях быстро сделанный минимум лучше опоздавшего на полгода максимума…
А элементы методологии нужно применять и адаптировать по назначению. Ну, например, пресловутый Stand-up. Он на самом-то деле нужен не всегда, и не обязательно каждый день. Но идея весьма проста — быстро глянуть на то, что мы, как команда делаем, и что собираемся делать дальше. Никакая полемика и никакое обсуждение проблем не допускаются, stand-up должен занимать минут 10, ну 15 от силы. В некоторых командах это не нужно, там и так все хорошо знают, что делается. А в некоторых нет хорошего контакта, и получается кто в лес, кто по дрова.
Или планирование. Оно, на самом деле очень полезно хотя бы тем, что происходит проговаривание задач, и можно добиться того, что все понимают задачу одинаково. Ну, например, если стоит задача «Сделать автоматический бэкап данных», то очень возможно, что заказчик хочет иметь возможность записать данные в отдельный файл, а программист собирается создавать сложную облачную систему. Кроме того, благодаря такому проговариванию есть шанс отловить ситуацию, когда внешне простая задача на самом деле гораздо сложнее, чем кажется. У меня бывало несколько раз, что один из членов команды оценивал задачу в гораздо больше баллов, чем остальные, и при обсуждении указывал на подводные камни, которые он знал из своего опыта. Я уж и не говорю про то, что вычисляемая в результате скорость команды замечательно помогает при разговоре с начальством.
Вам, похоже, просто не повезло, и вы не работали в месте, где такого рода методология по-настоящему успешно применяется.
Ну, а то, что в Америке распространен наем по телефону — это, извините, чушь. Первое собеседование — да. А наем без встречи в реальной жизни — очень редко. Дешевле оплатить человеку билет и гостиницу, чем потом расхлебывать.
А элементы методологии нужно применять и адаптировать по назначению. Ну, например, пресловутый Stand-up. Он на самом-то деле нужен не всегда, и не обязательно каждый день. Но идея весьма проста — быстро глянуть на то, что мы, как команда делаем, и что собираемся делать дальше. Никакая полемика и никакое обсуждение проблем не допускаются, stand-up должен занимать минут 10, ну 15 от силы. В некоторых командах это не нужно, там и так все хорошо знают, что делается. А в некоторых нет хорошего контакта, и получается кто в лес, кто по дрова.
Или планирование. Оно, на самом деле очень полезно хотя бы тем, что происходит проговаривание задач, и можно добиться того, что все понимают задачу одинаково. Ну, например, если стоит задача «Сделать автоматический бэкап данных», то очень возможно, что заказчик хочет иметь возможность записать данные в отдельный файл, а программист собирается создавать сложную облачную систему. Кроме того, благодаря такому проговариванию есть шанс отловить ситуацию, когда внешне простая задача на самом деле гораздо сложнее, чем кажется. У меня бывало несколько раз, что один из членов команды оценивал задачу в гораздо больше баллов, чем остальные, и при обсуждении указывал на подводные камни, которые он знал из своего опыта. Я уж и не говорю про то, что вычисляемая в результате скорость команды замечательно помогает при разговоре с начальством.
Вам, похоже, просто не повезло, и вы не работали в месте, где такого рода методология по-настоящему успешно применяется.
Ну, а то, что в Америке распространен наем по телефону — это, извините, чушь. Первое собеседование — да. А наем без встречи в реальной жизни — очень редко. Дешевле оплатить человеку билет и гостиницу, чем потом расхлебывать.
Чтобы собрания любые, не только stand-up не были бесполезными требуется человек, который следит за обсуждением и прерывает не относящиеся к делу ветки. Сам Stand-Up происходит за 15 минут и при нормальном размере комманды 5-8 человек каждый должен высказаться, а это 3 или меньше минут на человека — не заскучаешь.
Бизнес заказчик должен знать каждую деталь разработки, несмотря на то, что «пациент» еще не в полной кондиции, но бизнес хочет знать как там
у нас с дела со всеми аспектами работы.
В скраме пациент всегда еще не в полной кондиции — продукт всегда улучшается. Если работа правильно распланирована — то каждая демо является кусочком новой функциональности для клиента (которую он может использовать в продакшене сразу после демы), либо исправлением существующей функциональности, котороая не устроила клиента.
Наиболее отчаянные разработчики показывают одну и ту же демонстрацию с небольшими, я бы сказал, косметическими изменениями.
Это показатель того, что product owners — не знают как правильно писать user story. Задача для scrum master — их научить. Если последний не видет этого или ничего не делает — его вина. Если у него нет достаточных полномочий — вина руководства.
И вот появляется список каких-то бизнес кейсов, они должны быть решены в следующей итерации этого безумного Scrum вертепа
Ну во-первых не бизнесс кейсов, а user story. Описание реальной проблемы реального пользователя которое может быть понятно любым членом комманды (пусть после некоторых объяснений).
Для этого участники сбора, по старинке, перекидываются в картишки, с некоторыми неясными непосвященному глазу номерками, которые
являются некой заменой обычных трудозатрат. Общее голосование выносит свой безжалостный вердикт.
А что там неясного с номерками? С точки зрения разработчика — смотришь на несколько задач A, B, C и D которые ты делал ранее и сравниваешь больше ли задача E, которую нужно оценить, чем каждая из них или меньше — и выдаешь результирующую циферку. Если ты выдал циферку которая сильно отличается от остальных — вы обсуждаете почему ты так думаешь и почему они думают по-другому. Если оказывается что ты учел что-то что они не видели — делается новая оценка, если их доводы оказываются убедительнее — ты можешь поменять свою.
С точки зрения тех, кто ведет проект — циферки накладываются на временную шкалу и сверяются с прошлым. Если в прошлом спринте сделали 10 пунктиков а в позапрошлом 8, а в позапозапрошлом 9 — они говорят 8 — это более менее гарантированная производительность комманды, 10 — это очень оптимистичная. А дальше берут приоритизированый и оцененый бэклог будующей работы и примерно прикидывают какая часть работы будет сделана в следующем спринте а какая не будет.
5 минут можно смело потрать на обсуждение того факта, как же здорово сделать журналирование работы Java web-сервиса.
Для того, чтобы от этого отучиться надо некоторое время поработать в XP и освоить принцип YAGNI. Пока задача не в бэклоге и не приоритизирована — она не обсуждается. Как бизнесс так и техническая. Задача тех. лида засунуть технические задачи в бэклог и сторговаться с product owner о приоритетах (по большому счету обосновать необходимость решения).
Как итог, 30-40% времени разработчика тратится на звонки, встречи и прочую активность такого рода.
Это правда. Встречи и общение возрастают при scrum. Если нравится сидеть и не отсвечивая колбасить код, то не самый оптимальный процесс. Но если хочется делать продукт и понимать зачем и для кого ты его делаешь — то скрам хороший.
Когда же эта ересь со Scrum отойдет в мир иной?
Наверное вместе с принципами Стивена Кови ;))
Как итог, 30-40% времени разработчика тратится на звонки, встречи и прочую активность такого рода.В далёком лохматом 2005 бывший сотрудник компании, где я тогда работал, ушедший в американскую компанию, говорил, что якобы по их стандартам программист должен программировать 4 часа в день. Как я понял, под «программировать»имелся в виду непосредственно кодинг. Чем-то похоже.
Не знаю, насколько часто встречается проблема, когда руководство компании не понимает, что делают программисты.Что-то фундаментально неправильно в такой компании.
А решение очень простое – code review должны делать сами разработчики. Только не тот, который писал код, а 2-3 других человека.Поздравляю с открытием мира ITIL и одной из его практик — segregation of duties.
Все методики по-своему хороши, но каждый пытается на этом заработать подавая под своим соусом (речь о консультантах, которые внедряют это все в компании).
Но на мой взгляд во всех этих митингах и стендапах очень много «воды» и очень мало «делать». Все собираемся кругом, водим хороводы, пожимаем руки и сидим с нахмуренными лбами, в итоге половина рабочего дня, а то и весь уходит в утиль без видимых продвижений.
Несомненно митинги нужны, но мне кажется, что люди на него должны приходить со следующим заполненным списком от старого, доброго Карнеги, который к эффективности и менеджменту имел посредственное отношение, но тем не менее этот воркфлоу позволяет действительно делать, а не встречаться и обсуждать, обсуждать, обсуждать. Такие совещания займут не более 15 минут, а эффекта намного больше.
Собственно сам список вопросов:
1. В чем сущность проблемы?
2. Какова причина возникновения проблемы?
3. Какие могут быть решения?
4. Какое решение вы предлагаете?
Но на мой взгляд во всех этих митингах и стендапах очень много «воды» и очень мало «делать». Все собираемся кругом, водим хороводы, пожимаем руки и сидим с нахмуренными лбами, в итоге половина рабочего дня, а то и весь уходит в утиль без видимых продвижений.
Несомненно митинги нужны, но мне кажется, что люди на него должны приходить со следующим заполненным списком от старого, доброго Карнеги, который к эффективности и менеджменту имел посредственное отношение, но тем не менее этот воркфлоу позволяет действительно делать, а не встречаться и обсуждать, обсуждать, обсуждать. Такие совещания займут не более 15 минут, а эффекта намного больше.
Собственно сам список вопросов:
1. В чем сущность проблемы?
2. Какова причина возникновения проблемы?
3. Какие могут быть решения?
4. Какое решение вы предлагаете?
Да, отсутствия структуры собрания порождает кучу проблем и потерянное время, а как следствие если посчитать сколько компании обходятся все участники митинга в час, то можно увидеть, что все это стоит очень дорого.
Согласен с вашей оценкой. И думаю что очень часто отсутствие смысла в собраниях — результат того, что нет того для кого обсуждаемая проблема важна. Как его называют champion. Того, кто как паравоз будет тащить обсуждение, ну и того кто будет противовесом и голосом разума.
Эммммм… вы зам. тех дира и только сейчас узнали про эти вещи?
Вы б читали побольше чтоли. Меньше откровений было бы при смене работы.
Запоздалый комментарий. Но все же лучше позже, чем никогда.
Очень меня интересует вопрос про оценку времени за решение задач. Из своего опыта я скажу — эта оценка никогда не бывает ни честной, ни точной. А знаете, почему?
Потому что работать 8 часов кряду невозможно — ну невозможно физически! Уходит время на отдых, туалет, иногда хочется встать и пройтись, почитать тот же хабр. По оценкам некоторых, на работу в среднем реально уходит до 4(!!!) часов в день.
И вот в таких условиях нам надо оценить задачу А и задачу Б.
Допустим, реальная оценка обеих задач — по 4 часа. Если придерживаться формального подхода, на их решение требуется один день (8 часов же!). Но так как никто реально не работает 8 часов, либо надо завышать оценки всегда, либо выделять официальное время на неработу (что никогда не делается). Именно поэтому разработчики стоят перед сложным выбором — или сказать правду и пахать как проклятые (во имя чего?) или работать нормально, но наврать с оценкой.
Кто может прокомментировать данную ситуацию?
Очень меня интересует вопрос про оценку времени за решение задач. Из своего опыта я скажу — эта оценка никогда не бывает ни честной, ни точной. А знаете, почему?
Потому что работать 8 часов кряду невозможно — ну невозможно физически! Уходит время на отдых, туалет, иногда хочется встать и пройтись, почитать тот же хабр. По оценкам некоторых, на работу в среднем реально уходит до 4(!!!) часов в день.
И вот в таких условиях нам надо оценить задачу А и задачу Б.
Допустим, реальная оценка обеих задач — по 4 часа. Если придерживаться формального подхода, на их решение требуется один день (8 часов же!). Но так как никто реально не работает 8 часов, либо надо завышать оценки всегда, либо выделять официальное время на неработу (что никогда не делается). Именно поэтому разработчики стоят перед сложным выбором — или сказать правду и пахать как проклятые (во имя чего?) или работать нормально, но наврать с оценкой.
Кто может прокомментировать данную ситуацию?
Формально у вас 40 рабочих часов в неделю.
Но нормальный менеджер не будет планировать более 28 — 32 часов (если вы lead, то можно планировать еще меньше, если процесс работы с командой не формализован каким-то супер крутым образом).
«Запасные» 8 — 12 часов — коммуникация, переключения и прочие оверхеды (в том числе habr, мелкие фиксы до 15 мин., месседжеры, почта. ответы на вопросы и т.д.). Не забывайте, что это не отменяет поправочного коэффициента в оценке задач (x1,2 — 1,4).
В итоге 8 часовые задачи никогда не ставятся на 1 день (всегда на 2).
+ не забывайте, что оценка нужна в первую очередь для обратной связи. Опоздать не страшно (реально сложно учесть все нюансы), страшно никому об этом не говорить до последнего момента.
Но, возможно, я просто не сталкивался с методологиями, в которых запрещена корректировка оценки. :)
Но нормальный менеджер не будет планировать более 28 — 32 часов (если вы lead, то можно планировать еще меньше, если процесс работы с командой не формализован каким-то супер крутым образом).
«Запасные» 8 — 12 часов — коммуникация, переключения и прочие оверхеды (в том числе habr, мелкие фиксы до 15 мин., месседжеры, почта. ответы на вопросы и т.д.). Не забывайте, что это не отменяет поправочного коэффициента в оценке задач (x1,2 — 1,4).
В итоге 8 часовые задачи никогда не ставятся на 1 день (всегда на 2).
+ не забывайте, что оценка нужна в первую очередь для обратной связи. Опоздать не страшно (реально сложно учесть все нюансы), страшно никому об этом не говорить до последнего момента.
Но, возможно, я просто не сталкивался с методологиями, в которых запрещена корректировка оценки. :)
Спасибо за ответ.
Полагаю, вы правы, и надо просто закладывать «запасное» время. Просто мне лично никогда не приходилось это наблюдать вживую. Если все решили, что задача на 8 часов (все — это скрам же!), то она всегда ставилась на один день. Наверное, мне просто не попадались нормальные лиды, которые понимали, что 8 часов на задачу не означают 8 часов, проведенных в офисе.
Полагаю, вы правы, и надо просто закладывать «запасное» время. Просто мне лично никогда не приходилось это наблюдать вживую. Если все решили, что задача на 8 часов (все — это скрам же!), то она всегда ставилась на один день. Наверное, мне просто не попадались нормальные лиды, которые понимали, что 8 часов на задачу не означают 8 часов, проведенных в офисе.
Если брать конкретно эту компанию, был разговор на одном из митингов, что нужно планировать не более 6 часов в день работы, остальное почта, коммуникации. Как и сказал Loengreen.
На моей практике, если сравнивать работу без оценки задачи и с оценкой, я точно выберу с оценкой. Пусть даже немного неверной. Общая картина в итоге получается более предсказуемой и прозрачной. Кроме того навык оценки задач улучшается, чем больше оценки, тем точнее она становится (так по крайней мере в идеале). Конечно, бывает, что в середине выполнения вылезет какой-нибудь Кракен и задача займет сильно больше исходной оценки, но это скорее исключение, чем правило.
На моей практике, если сравнивать работу без оценки задачи и с оценкой, я точно выберу с оценкой. Пусть даже немного неверной. Общая картина в итоге получается более предсказуемой и прозрачной. Кроме того навык оценки задач улучшается, чем больше оценки, тем точнее она становится (так по крайней мере в идеале). Конечно, бывает, что в середине выполнения вылезет какой-нибудь Кракен и задача займет сильно больше исходной оценки, но это скорее исключение, чем правило.
Sign up to leave a comment.
5 классных вещей в процессах американской компании