Вы правы, нельзя быть полностю уверенным в оценке. И, конечно, есть риск пропустить какую-то зависимость. Однако все планы строятся именно на оценках и зависимостях. Независимо от того, скрам у вас или нет.
По поводу второго тезиса. Перечитайте, пожалуйста, внимательнее. Речь про оценку задачи одной компетенции носителем другой.
Прекрасно! Я с вами полностью согласен. Качество продукта - это главное. Но вот даст ли вам Заказчик год на проектирование? Будет ли он готов заплатить вам за ваш проект? И не изменятся ли требования к продукту за год?
В статье описано мнение (она и помечена категорией "Мнение"). Вы можете прислушаться либо пропустить мимо. Тут нечему верить.
У вас или работа до ужаса типовая и тогда вам заранее известно сколько займет та или иная задача.
Правильно я понимаю, что в своей работе вы не используете никаких оценок? Вы не планируете объёмов и сроков их выполнения? Когда сделаете, тогда и хорошо?
Говорят у вас ИТ инфраструктура сыпется вплоть до того что в БД транзакции теряются и сервисы постоянно падают.
Если вы старались, то должны были узнать, что там нет "ритуалов", есть только "события".
Действительно, есть события. А ещё их называют церемонии. А ещё их называют ритуалы. А вы просто занимаетесь буквоедством.
Нет, вы изначально не понимали зачем эти события, поэтому к вам пришло такое "осознание". Когда не понимаешь предназначения чего-либо, оно всегда кажется бессмысленным.
Это ваша личная интерпретация. Однако если нет темы для обсуждения, например, на ретроспективе, то нет смысла её проводить каждый спринт.
я прекрасно понимаю о чем говорю, иначе не писал бы, и как раз прекрасно понял что вы написали в статье
Если вы действительно поняли, о чём написано в статье, то написали бы комментарии по сути предлагаемой модели, а не стали бы обвинять в несоответствии фреймворку. Для вашего сведения, в каждой компании своя имплементация скрам. И она зависит как от внутренней организации компании и внутренних ограничений, так и от зрелости самой команды.
Нет такой "штуки", как "ёмкость", есть velocity
Если вы не знакомы с понятием capacity, не стоит утверждать, что его нет. Надо уметь факт от плана отличать.
Опять двадцать пять — в сторипоинтах оцениваются истории
В сторипоинтах оцениваются элементы бэклога. История - это один из типов элементов. А ещё есть технические задачи, задачи на устранение ошибок, задачи на устранение техдолга и пр.
Ну, теперь точно понятно — вы не старались полностью соответствовать этому фреймворку, иначе знали бы о таком понятии, как кроссфункциональная команда, почему она важна и как ее создавать.
Кроссфункциональность, которая предполагает наличие в команде всех компетенций, необходимых для реализации продукта, не означает, что аналитик способен дать адекватную оценку задач разработчика.
Странно слышать обвинения от человека, не находящегося в контексте. Поверьте, это вас не красит.
Судя по комментарию, вы не понимаете отличие velocity от capacity, не понимаете, что такое бэклог и из чего он состоит, не поняли и даже не попытались понять, о чём написано в статье.
Вывод: Думайте прежде, чем что-то написать, и будте добрее)
По первому тезису согласен. Без понимания ошибки искать тяжелее и дольше.
По второму, алгоритмы писать ужасно, когда это единственное задание, от которого зависит исход подбора. Когда же оно одно среди множества, его невыполнение компенсируется выполнением остальных. А если кандидат справляется с алгоритмами, это наоборот выделяет его среди массы
Развитие компетенций внутренних сотрудников - отдельная увлекательная история. Встречал разные подходы, но интересен ваш опыт - в процессе оценки даёте ли вы сотрудникам новые задания (например, спроектировать решение по заданным требованиям и обосновать проект) или останавливаетесь на анализе артефактов их работы?
Соглашусь, вопросы должны позволить взглянуть на кандидата с разных сторон. А их составление - отдельный навык.
Насчет приведённого примера. Вам он кажется странным. Однако нашим аналитикам приходится работать в т.ч. с XML-сервисами, настраивать интеграции, участвовать в разборе дефектов. Поэтому нам важно, чтобы человек понимал правила формирования XML. И текущая статистика показывает, что с данным вопросом успешно справляется почти половина кандидатов. Практически столько же проходит скрининг
Справедливое замечание. Именно поэтому на первом этапе допускается четверть неверных ответов. А то, что знает кандидат, коллеги определяют на дальнейших этапах
Конечному пользователю в большей степени интересна собранная версия документации, но не её исходники. Поиск по собранным HTML-кам у нас реализован на уровне CI/CD. Плюс команды "прикапывают" ссылки на сборки на странице проекта
Да, верно, опечатка. Про мегабайты речь. Спасибо!
Спасибо, что поделились опытом. Полностью поддерживаю проработку бэклога на несколько спринтов вперёд
Вы правы, нельзя быть полностю уверенным в оценке. И, конечно, есть риск пропустить какую-то зависимость. Однако все планы строятся именно на оценках и зависимостях. Независимо от того, скрам у вас или нет.
По поводу второго тезиса. Перечитайте, пожалуйста, внимательнее. Речь про оценку задачи одной компетенции носителем другой.
Да, соглашусь, в гикой разработке есть свои слабые стороны. И ваш тезис действительно имеет смысл. Спасибо за комментарий!
Прекрасно! Я с вами полностью согласен. Качество продукта - это главное. Но вот даст ли вам Заказчик год на проектирование? Будет ли он готов заплатить вам за ваш проект? И не изменятся ли требования к продукту за год?
В статье описано мнение (она и помечена категорией "Мнение"). Вы можете прислушаться либо пропустить мимо. Тут нечему верить.
Правильно я понимаю, что в своей работе вы не используете никаких оценок? Вы не планируете объёмов и сроков их выполнения? Когда сделаете, тогда и хорошо?
А вы всему верите, что говорят?
Действительно, есть события. А ещё их называют церемонии. А ещё их называют ритуалы. А вы просто занимаетесь буквоедством.
Это ваша личная интерпретация. Однако если нет темы для обсуждения, например, на ретроспективе, то нет смысла её проводить каждый спринт.
Если вы действительно поняли, о чём написано в статье, то написали бы комментарии по сути предлагаемой модели, а не стали бы обвинять в несоответствии фреймворку. Для вашего сведения, в каждой компании своя имплементация скрам. И она зависит как от внутренней организации компании и внутренних ограничений, так и от зрелости самой команды.
Если вы не знакомы с понятием capacity, не стоит утверждать, что его нет. Надо уметь факт от плана отличать.
В сторипоинтах оцениваются элементы бэклога. История - это один из типов элементов. А ещё есть технические задачи, задачи на устранение ошибок, задачи на устранение техдолга и пр.
Кроссфункциональность, которая предполагает наличие в команде всех компетенций, необходимых для реализации продукта, не означает, что аналитик способен дать адекватную оценку задач разработчика.
Покер планирование, скрам покер, как вам угодно
Странно слышать обвинения от человека, не находящегося в контексте. Поверьте, это вас не красит.
Судя по комментарию, вы не понимаете отличие velocity от capacity, не понимаете, что такое бэклог и из чего он состоит, не поняли и даже не попытались понять, о чём написано в статье.
Вывод: Думайте прежде, чем что-то написать, и будте добрее)
По первому тезису согласен. Без понимания ошибки искать тяжелее и дольше.
По второму, алгоритмы писать ужасно, когда это единственное задание, от которого зависит исход подбора. Когда же оно одно среди множества, его невыполнение компенсируется выполнением остальных. А если кандидат справляется с алгоритмами, это наоборот выделяет его среди массы
Абсолютно согласен с вашим тезисом!
Тест дается всем. Он не оценивает технический уровень кандидата. Оценка уровня происходит на техническом интервью
Развитие компетенций внутренних сотрудников - отдельная увлекательная история. Встречал разные подходы, но интересен ваш опыт - в процессе оценки даёте ли вы сотрудникам новые задания (например, спроектировать решение по заданным требованиям и обосновать проект) или останавливаетесь на анализе артефактов их работы?
:)
Если у вас "не малый опыт в системной аналитике", мы друг друга точно не поймём, т.к. у меня опыт в системном анализе
Соглашусь, вопросы должны позволить взглянуть на кандидата с разных сторон. А их составление - отдельный навык.
Насчет приведённого примера. Вам он кажется странным. Однако нашим аналитикам приходится работать в т.ч. с XML-сервисами, настраивать интеграции, участвовать в разборе дефектов. Поэтому нам важно, чтобы человек понимал правила формирования XML. И текущая статистика показывает, что с данным вопросом успешно справляется почти половина кандидатов. Практически столько же проходит скрининг
По внешним кандидатам данных нет, но точно могу сказать, что внутренние ребята, в т.ч. лиды и синьоры, проявляют интерес и просят дать им пройти бота)
Справедливое замечание. Именно поэтому на первом этапе допускается четверть неверных ответов. А то, что знает кандидат, коллеги определяют на дальнейших этапах
Безусловно, скрининг можно было оставить на HR и по-прежнему "жечь" его время)
В части проверки софтов хороший поинт
Конечному пользователю в большей степени интересна собранная версия документации, но не её исходники. Поиск по собранным HTML-кам у нас реализован на уровне CI/CD. Плюс команды "прикапывают" ссылки на сборки на странице проекта
Пилоты не имели целью уйти от Confluence. Их цель - знакомство с новым инструментом, оценка его удобства для ведения документации на фронт