По-моему, у вас самый обычный planning poker, просто вы поставили перегородочки между разработчиками, чтобы они не видели, какую карточку выбрал сосед.
Совершенно верно. С помощью данного конкретного инструмента я решал утилитарную задачу. Подходит ли он для всех кейсов разработки и для всех команд? Нет
это вообще сторукое лицо-рука, коммуникации в команде не выстроены совершенно, тут к planning poker’у еще рано переходить.
Большинство проблем в мире случаются из-за неэффективной коммуникации. Это данность, с которой каждый из нас работает.
Любопытен ваш опыт, какие у вас критерии перехода к planning poker?
Очень хорошее замечание! Вы правы, люди всегда люди:
Люди могут иногда забывать отмечать свои действия.
Бывает, что они не всегда относятся к этому ответственно, заполняя некоторые данные точно, а другие оставляя на усмотрение памяти.
Не обойтись и без случаев, когда люди преукрашивают или преуменьшают свои достижения, чтобы создать определенное впечатление.
Фактическое время - не «священная корова». Я как руководитель могу повлиять на выстраивания необременительного процесса трекания времени. Необходимо находить баланс между требованиями к точности, которые могут оказывать давление на разработчиков, и приемлемыми отклонениями.
Мы не приветствуем переключения между задачами, потому что это драматически снижает эффективность. Но, к сожалению, и у нас такое бывает.
Ценность Planning Poker - во всестороннем обсуждении задач перед оценкой. Поэтому странно звучит аргумент "Отвлечь ценных специалистов от работы".
Не все встречи одинаково полезны.
Как я подчеркивал в своей статье, каждая задача требует своего инструмента. Данный инструмент эффективен в решении задач, где предыдущие этапы выполнены специалистами качественно, и имеются четкие артефакты.
imho статья в очередной раз демонстрирует столкновение культур - традиционной корпоративной (иерархия, планы со сроками, "учёт трудозатрат" и "утилизация ресурсов", вот это вот всё) и Agile (команда разработки все решения принимает сама, и менеджер ей не нужен).
Я работал как в традиционной корпоративной среде, так и в творческой, современной Agile-компании. Крупные проекты - большие заказы от бизнеса, и для успешной работы необходимо умение оперировать в их системе координат
Чем большим количеством инструментов и подходов вы владеете, тем шире поле задач, которые можно решить. Полностью отрицать корпоративные методы, так же недальновидно, как отказываться от Agile. Все зависит от решаемой задачи.
Да, конечно, оценка трудозатрат - материя сложная. Особенно, если с ней не работать.
Кейс, когда разработчики перезакладываются, это показатель недоверия между руководителем и специалистами и боязнь наказания.
Мое понимание оценки времени, которое я транслирую команде:
Мы не делаем культ из оценок, но стремимся к реалистичному значению. Как в случае математического предела переменная неограниченно приближается к какому-то постоянному значению
Оценка не пересматривается только при неизменности вводных данных, на основании которых она была сделана.
Оценка КРИТИЧЕСКИ нужна для планирования и для работы с бизнесом.
Вы - правы: мои сотрудники - не дураки. Но мы экспериментировали с форматами встреч для оценок и этот вариант им зашел.
В проектном управлении ещё с прошлого века есть с десяток техник оценивания и составления расписания...
Само по себе наличие техник не спасает от того факта, что многие проекты проваливаются и руководители дают обещания из головы.
Согласитесь, есть с десяток техник, позволяющих похудеть.
Но практика - критерий истины. Руководитель, у которого в арсенале несколько инструментов, которые он активно применяет в своей каждодневной работе, будет эффективнее руководителя, который знает множество техник, но не использует их.
Замесц одно в ваших расчётах и составлении расписаний для заказчика не учитываются зависимости, а разработке ПО их отсуствие это прямо нонсенс)
Верно! Важно учитывать зависимости, особенно это критично при проектировании микросервисов. Но это следующий уровень осознанности руководителя))
Оценка трудозатрат осуществляется только по упомянутому списку или есть на руках доп.материалы (к примеру, бизнес-требования от заказчика)? Если на руках только список, то это, конечно, лучше, чем просто название эпика, но все-равно "плюс-минус километр"
Верно! Подход идеально подойдет для простой функциональности (например, без интеграции со сторонними модулями), либо если у вас сработанная команда на знакомом проекте и новый эпик из вашей доменной области.
При разделение процесса на Discovery и Delivery, этап согласования бизнес-требований будет выполнен на первом этапе. Будем считать, что наша команда «Дрим тим» - это Delivery.
Хорошо, что в таблице учитывается отсутствие специалистов, но имеет смысл, наверное, учитывать и последовательность работ? Первую-вторую неделю будет активно работать СА, и активность его будет снижаться ближе к окончанию разработки, а вот QA точно появится не сразу. Или на этом этапе расчетов в этом нет такой необходимости?
Согласен, последовательность важна. Как я уже отвечал в другом комментарии, мы формируем гэп по аналитике. Соответственно, у нас СА всегда идут впереди. А вот для QA у нас всегда есть работа. Поскольку мы разрабатываем несколько функциональностей параллельно.
Доля условности в показанных расчетах есть. Однако вы можете под себя гибко адаптировать расчет через коэффициент загрузки специалиста. Но не заигрывайтесь))
Я обычно использую данный подход, когда приходит большой кусок работы. Если фича на 40-60 часов, решаю это в уме.
Как-то не сходятся трудозатраты из таблички с получившимся графиком. Точно график и таблица коррелируют друг с другом?
778 часов + 20% (резерв на непредвиденные ситуации) = 934 часа
Не совсем понятно, как можно сделать такой вывод, основываясь на таблице и графике? Или есть еще вводная информация, которая была упущена в статье?
Грубо округлим объем работ по SA, FE и BE, получается по 200 часов.
По QA - 100 часов.
На системном анализе у нас 2 специалиста (200 / 2 = 100), на FE,BE по 1 специалисту. Следовательно очевидно, что по FE и BE необходимо усиление.
Есть ли другие варианты подсчета? Мой опыт мне подсказывает, что если я выгружу 100 задач по фронту в Джире, то разбег между ними будет просто колоссальный
Да, если задачи в Jira можно кластеризировать на Small, Medium, Large, то статистика по кластерам будет вполне репрезентативна.
Поскольку среди заказчиков существует вариативность, то может быть абсолютно по-разному.
Я как заказчик ремонтных работ в квартире имею уже другие требования и критерии при выборе исполнителей, чем я же, но до своего первого ремонта в жизни.
Так как длительность спринта для проектов может быть разной (1-4 недели), то для наглядности я использовал универсальный поход с календарными неделями.
В портфеле любой компании заказной разработки обычно всегда лежат несколько проектов.
Эти проекты, во-первых, могут быть на разных этапах разработки (пред-договорные отношения, юридическое оформление, согласование ТЗ, согласование результата, оплата), а во-вторых, часть из них будут оплачены по fixed price, а другая часть - по time & materials.
Ситуация, что какие-то проекты в моменте «кормят» другие проекты, - вполне распространенная.
Ситуация, что исполнитель потратил свое время, а заказчик выбрал другого, - тоже обычная.
Мне кажется, ваш комментарий выходит за рамки темы статьи. Это больше вопрос бюджетов, тарифных ставок и в целом экономики проекта.
«Образование заказчика» - это управление ожиданиями клиента. И да, это работа, которую нужно проводить.
А со стороны исполнителя эта работа должна проводиться только совместными усилиями руководителей на различных уровнях: Release Manager —> Project Manager —> Руководитель разработки. Если не будет согласованности и приверженности одним и тем же принципам, то вероятность успеха кратно снижается.
Не забываем, что у исполнителя всегда есть опция - не заключать контракт с конкретным заказчиком, который им не подходит. Но адекватных заказчиков в корпоративном мире много. Поэтому важны и первичные переговоры и выстраивание доверительных отношений в процессе работы. Т.е. Вы объяснили человеку как будет, вы взяли на себя ответственность в исполнении этих обещаний, вы должны их исполнять. Тогда отношения укрепляться и к вам не будет придирок и вопросов.
Очень точное замечание! Спасибо! В данном конкретном примере при заболевании системного аналитика команда не сможет начать свою работу.
Для того, чтобы команда была не заблокирована, мы стараемся в своей работе:
Во-первых, формировать гэп по аналитике хотя бы на 1 рабочую неделю.
Во-вторых, следим, чтобы в бэклоге технического долга всегда были задачи, которыми могут заниматься разработчики.
В-третьих, всегда можно попросить помощи соседних команд.
План - это всегда только план. Изначальный план - это проекция возможного будущего на основе текущих допущений и вводных. Которые, естественно, могут измениться.
А любое изменение на проекте, будь то болезнь, либо новые проблемы, - это будни руководителя. И в его обязанности входит задача передоговориться с заказчиком в связи с изменениями. А если вам удалось выстроить доверительные отношения, то он отнесется с пониманием и вы сможете удачно передоговориться.
Метод pi отличный. Уверен, что он работает - для определенных частных случаев. Однако он не помогает решать фундаментальную проблему неопределенности.
Рассмотрим 2 примера:
Пример 1: Разработчик, релиз менеджер, руководитель проекта - каждый на своем уровне перестраховывается на 3,14. И заказчик отказывается сотрудничать по такой смете.
Пример 2: Заказчик от кого-то услышал, что «хитрые айтишники» практикуют тригонометрию при оценке задач, режет смету на 3,14 и категорически отказывается вести переговоры по срокам и смете. Хорошо, если речь идет о смете, составленной «хитрым айтишником» из примера 1. Он худо-бедно сможет выйти хотя бы в ноль.
В худших условиях будет добросовестный исполнитель, который посчитал реалистичные сроки и смету.
В результате возникает мир кривых зеркал, взаимных недовольств и обид.
Изначально данная статья родилась из наблюдения за некоторыми руководителями, которые давали обещания ИЗ ГОЛОВЫ. И результат из головы, умноженный хоть на 10 pi, может быть недостаточным для реализации задачи.
Совершенно верно. С помощью данного конкретного инструмента я решал утилитарную задачу. Подходит ли он для всех кейсов разработки и для всех команд? Нет
Большинство проблем в мире случаются из-за неэффективной коммуникации. Это данность, с которой каждый из нас работает.
Любопытен ваш опыт, какие у вас критерии перехода к planning poker?
Поправьте меня, если я не правильно вас понял.
Вы же сами предлагаете оценку времени. Т.е. ценность планирования вы все же признаете?
Очень хорошее замечание! Вы правы, люди всегда люди:
Люди могут иногда забывать отмечать свои действия.
Бывает, что они не всегда относятся к этому ответственно, заполняя некоторые данные точно, а другие оставляя на усмотрение памяти.
Не обойтись и без случаев, когда люди преукрашивают или преуменьшают свои достижения, чтобы создать определенное впечатление.
Фактическое время - не «священная корова». Я как руководитель могу повлиять на выстраивания необременительного процесса трекания времени. Необходимо находить баланс между требованиями к точности, которые могут оказывать давление на разработчиков, и приемлемыми отклонениями.
Мы не приветствуем переключения между задачами, потому что это драматически снижает эффективность. Но, к сожалению, и у нас такое бывает.
Да, безусловно влияет. И вот, что я делаю в этом случае: https://habr.com/ru/articles/789414/
Не все встречи одинаково полезны.
Как я подчеркивал в своей статье, каждая задача требует своего инструмента. Данный инструмент эффективен в решении задач, где предыдущие этапы выполнены специалистами качественно, и имеются четкие артефакты.
Я работал как в традиционной корпоративной среде, так и в творческой, современной Agile-компании. Крупные проекты - большие заказы от бизнеса, и для успешной работы необходимо умение оперировать в их системе координат
Чем большим количеством инструментов и подходов вы владеете, тем шире поле задач, которые можно решить. Полностью отрицать корпоративные методы, так же недальновидно, как отказываться от Agile. Все зависит от решаемой задачи.
Да, конечно, оценка трудозатрат - материя сложная. Особенно, если с ней не работать.
Кейс, когда разработчики перезакладываются, это показатель недоверия между руководителем и специалистами и боязнь наказания.
Мое понимание оценки времени, которое я транслирую команде:
Мы не делаем культ из оценок, но стремимся к реалистичному значению. Как в случае математического предела переменная неограниченно приближается к какому-то постоянному значению
Оценка не пересматривается только при неизменности вводных данных, на основании которых она была сделана.
Оценка КРИТИЧЕСКИ нужна для планирования и для работы с бизнесом.
Вы - правы: мои сотрудники - не дураки. Но мы экспериментировали с форматами встреч для оценок и этот вариант им зашел.
Спасибо!
Само по себе наличие техник не спасает от того факта, что многие проекты проваливаются и руководители дают обещания из головы.
Согласитесь, есть с десяток техник, позволяющих похудеть.
Но практика - критерий истины. Руководитель, у которого в арсенале несколько инструментов, которые он активно применяет в своей каждодневной работе, будет эффективнее руководителя, который знает множество техник, но не использует их.
Верно! Важно учитывать зависимости, особенно это критично при проектировании микросервисов. Но это следующий уровень осознанности руководителя))
Верно! Подход идеально подойдет для простой функциональности (например, без интеграции со сторонними модулями), либо если у вас сработанная команда на знакомом проекте и новый эпик из вашей доменной области.
При разделение процесса на Discovery и Delivery, этап согласования бизнес-требований будет выполнен на первом этапе. Будем считать, что наша команда «Дрим тим» - это Delivery.
Согласен, последовательность важна. Как я уже отвечал в другом комментарии, мы формируем гэп по аналитике. Соответственно, у нас СА всегда идут впереди. А вот для QA у нас всегда есть работа. Поскольку мы разрабатываем несколько функциональностей параллельно.
Доля условности в показанных расчетах есть. Однако вы можете под себя гибко адаптировать расчет через коэффициент загрузки специалиста. Но не заигрывайтесь))
Я обычно использую данный подход, когда приходит большой кусок работы. Если фича на 40-60 часов, решаю это в уме.
778 часов + 20% (резерв на непредвиденные ситуации) = 934 часа
Грубо округлим объем работ по SA, FE и BE, получается по 200 часов.
По QA - 100 часов.
На системном анализе у нас 2 специалиста (200 / 2 = 100), на FE,BE по 1 специалисту. Следовательно очевидно, что по FE и BE необходимо усиление.
Да, если задачи в Jira можно кластеризировать на Small, Medium, Large, то статистика по кластерам будет вполне репрезентативна.
Поскольку среди заказчиков существует вариативность, то может быть абсолютно по-разному.
Я как заказчик ремонтных работ в квартире имею уже другие требования и критерии при выборе исполнителей, чем я же, но до своего первого ремонта в жизни.
Так как длительность спринта для проектов может быть разной (1-4 недели), то для наглядности я использовал универсальный поход с календарными неделями.
Да, мы сравниваем план и факт в конце спринта.
Верно! Согласен с вашим замечанием, что мой вывод не безупречен. И согласен, что то, как были нарезаны задачи в бэклоге, может исказить результат.
Однако здесь мне важно было проиллюстрировать, что оценку нужно делать не из головы, а на основе арифметических расчетов, близких к элементарным.
В портфеле любой компании заказной разработки обычно всегда лежат несколько проектов.
Эти проекты, во-первых, могут быть на разных этапах разработки (пред-договорные отношения, юридическое оформление, согласование ТЗ, согласование результата, оплата), а во-вторых, часть из них будут оплачены по fixed price, а другая часть - по time & materials.
Ситуация, что какие-то проекты в моменте «кормят» другие проекты, - вполне распространенная.
Ситуация, что исполнитель потратил свое время, а заказчик выбрал другого, - тоже обычная.
Мне кажется, ваш комментарий выходит за рамки темы статьи. Это больше вопрос бюджетов, тарифных ставок и в целом экономики проекта.
Заказчик оплачивает готовый продукт. «Образование» - это просто диалог, внутри которого происходит обсуждение рабочих вопросов и требований.
Часы менеджера относятся к расходам проекта. Они учитываются в его смете, наряду с часами разработчиков, а также прочими косвенными расходами.
«Образование заказчика» - это управление ожиданиями клиента. И да, это работа, которую нужно проводить.
А со стороны исполнителя эта работа должна проводиться только совместными усилиями руководителей на различных уровнях: Release Manager —> Project Manager —> Руководитель разработки. Если не будет согласованности и приверженности одним и тем же принципам, то вероятность успеха кратно снижается.
Не забываем, что у исполнителя всегда есть опция - не заключать контракт с конкретным заказчиком, который им не подходит. Но адекватных заказчиков в корпоративном мире много. Поэтому важны и первичные переговоры и выстраивание доверительных отношений в процессе работы. Т.е. Вы объяснили человеку как будет, вы взяли на себя ответственность в исполнении этих обещаний, вы должны их исполнять. Тогда отношения укрепляться и к вам не будет придирок и вопросов.
Очень точное замечание! Спасибо! В данном конкретном примере при заболевании системного аналитика команда не сможет начать свою работу.
Для того, чтобы команда была не заблокирована, мы стараемся в своей работе:
Во-первых, формировать гэп по аналитике хотя бы на 1 рабочую неделю.
Во-вторых, следим, чтобы в бэклоге технического долга всегда были задачи, которыми могут заниматься разработчики.
В-третьих, всегда можно попросить помощи соседних команд.
План - это всегда только план. Изначальный план - это проекция возможного будущего на основе текущих допущений и вводных. Которые, естественно, могут измениться.
А любое изменение на проекте, будь то болезнь, либо новые проблемы, - это будни руководителя. И в его обязанности входит задача передоговориться с заказчиком в связи с изменениями. А если вам удалось выстроить доверительные отношения, то он отнесется с пониманием и вы сможете удачно передоговориться.
Согласен, что этот кейс - самый эпичный, фееричный факап, про который даже инопланетянам будет стыдно рассказывать, когда они прилетят на Землю))
Он был взят для примера, чтобы подсветить всю сложность работы с неопределенностью, которая возникает при оценке сроков и бюджетов.
Метод pi отличный. Уверен, что он работает - для определенных частных случаев. Однако он не помогает решать фундаментальную проблему неопределенности.
Рассмотрим 2 примера:
Пример 1: Разработчик, релиз менеджер, руководитель проекта - каждый на своем уровне перестраховывается на 3,14. И заказчик отказывается сотрудничать по такой смете.
Пример 2: Заказчик от кого-то услышал, что «хитрые айтишники» практикуют тригонометрию при оценке задач, режет смету на 3,14 и категорически отказывается вести переговоры по срокам и смете. Хорошо, если речь идет о смете, составленной «хитрым айтишником» из примера 1. Он худо-бедно сможет выйти хотя бы в ноль.
В худших условиях будет добросовестный исполнитель, который посчитал реалистичные сроки и смету.
В результате возникает мир кривых зеркал, взаимных недовольств и обид.
Изначально данная статья родилась из наблюдения за некоторыми руководителями, которые давали обещания ИЗ ГОЛОВЫ. И результат из головы, умноженный хоть на 10 pi, может быть недостаточным для реализации задачи.
Спасибо большое, баг пофиксил)))