Очень больная тема эта метрика, к сожалению не могу её снять сейчас.
Для этого планирую немного изменить процесс работы в jira (а это возможно только после нового контракта с командой разработки) и начать снимать её в феврале.
У нас так устроен процесс, что релизы мы делаем в среду, а примерный список задач на спринт я согласовываю в понедельник (потом в среду мы его конечно уточняем). Что позволяет избежать риска несогласованных задач. И риск этот риск — да, моя забота.
Ошибочная оценка задачи связана далеко не только с QA и его работой. Плохие оценки случаются, и надо как-то на это реагировать.
Но да, писать свои критерии приемки я не стал именно из-за QA, до того как он начал писать DoD с моим ревью задачи после тестирования часто имели много ошибок, иногда очевидных.
Не совсем понял вопрос последний.
Аналитика моя или разработчиков?
Очевидно коэффициент зависит от объема и сложности задач.
Думаю для крупных аналитика/архитектура разработчика ко всему процессу у нас имеет коэффициент x5, может больше, но точно меньше x10.
Я в детали кода не лезу, ревью не провожу, экспертом по технологиям не являюсь и т.д.
Так что назвать меня тимлидом довольно сложно.
Как я писал мне не нужна точная оценка времени. Для меня (в силу контрактных особенностей) даже выгодно если программисты будут ошибаться в оценке. Но мне надо чтобы ожидания бизнес-заказчика оправдывались, поэтому ошибка пусть будет, но она будет предсказуемой.
И в силу контрактных особенностей разработчикам всё равно надо проводить оценку своих задач.
Если чуть-чуть пояснить эти особенности, то мы платим им за время затраченное на задачу, если время затраченное сильно превысило оцененное, то к сумме будет применяться коэффициент вплоть до коэффициента 0,1.
Про своеобразность — согласен.
Но давайте приведу примеры:
У нас есть фронтэнд разработчик, который совсем ничего не может делать в бекэнд части.
У него в спринте 3 задачи по фронтэнд и ещё есть 10 задач по бэкенд.
Он молодец и сделал все свои 3 задачи раньше срока. Что ему делать дальше? Добавлять задачи в спринт? Плохая идея, может не выдержать тестировщик. Брать задачи бэкендера? Как я говорил таких компетенций у него нет. Помогать тестировать? Лучше и дешевле это сделает тестировщик.
В итоге остается только брать задачи, которые позже попадут в следующие спринты.
Все со сроками согласились, оценку провели и всё хорошо. Но потом всплыла задача которая была ошибочно оценена. При этом задача это самая важная для бизнес-заказчика в этом спринте. И у меня есть 2 варианта действий (все мотивации и давайте поработаем ночью испробованы и не помогают успеть решить её в срок):
а) Подойти к бизнес-заказчику и сказать давай релиз отодвинем на 1-2 дня?
б) Подойти к бизнес-заказчику и сказать, вот сегодня мы выкатим не особо нужные тебе фичи, но вот через неделю выкатим то что тебе реально надо.
И я выбираю 1-ый путь, что не согласовывается с чистым скрамом, но я нигде и не говорил что мы живем по этой методологии.
Из-за особенностей контрактования у нас команда работает над проектом 1 год, потом происходит тендер и его выиграть может та же компания или другая. Поэтому это дело не сугубо команды.
Под остановить процесс я имел ввиду перестать на неделю к примеру реализовывать новые таски. А бизнес-заказчик по проекту Cofoundit очень часто тестирует гипотезы и т.д. И у меня (в проекте Cofoundit) нет полномочий самостоятельно принимать такие решение.
О спринтах тут ничего не говорились. Если появилась задача на рефакторинг на 1 день это не значит что её начали в тот же день, это значит что она займет 1 день когда решим её взять (вероятно в следующем спринте)
Остальная метрика. Она не очень показательна, как мне кажется.
Появляются зачастую задачи, которые надо решать не в ближайшую неделю. Или после оценки принимается решение о снижении приоритета. Что увеличивает время в столбце — До начала разработки.
Также время в ожидании релиза не показательно к примеру:
а) программист может быстро успеть решить все таски в текущем спринте и приступить к следующему, что приведет что часть его задач будет долго ждать релиза.
б) программист может сильно затянуть с решением своих задач, которые критически выкатить в ближайший релиз, что может привести к увеличению срока всех остальных задач в ожидании релиза на 1 день.
И оба результата будут иметь одинаковый эффект в столбце — Ждет релиза.
Тут более показательны запланированные и фактические сроки релиза, но к сожалению таких данных у меня под рукой нет.
Хотелось бы узнать у вас в какую сходимость вы не верите? Во время в каждом статусе или в качество оценки?
Давайте буду отвечать по частям.
1. Кто принимает решение об использовании тех или иных технологий?
Основной набор технологий был сформирован ещё до моего прихода и даже до текущий команды разработки. Есть 2 пути добавления/изменения технологий у нас в проекте:
а. Я хочу что-то поменять, доношу свои потребности до команды и они мне предлагают варианты технологий/средств применимых для этого.
б. Команда сама приходит к мысли что им проще жилось бы с какой-то технологией/средством, они мне об этом говорят и обосновывают свою позицию. Если убеждают (обычно убеждают), то мы начинаем её использовать.
2. Кто определяет архитектуру системы?
Глобально архитектуру системы определяет команда разработки, но если я считаю что кусок встраивается довольно большой, то я принимаю участие при обсуждении архитектуры.
3. Как Вы объясняете Заказчику, что на самом начальном этапе на стадии проектирования были допущены ошибки и приняты неверные решение и что теперь наращивание функционала системы делать все труднее и труднее и времени на это уходит больше?
Для команды разработки заказчик — я. Моё взаимодействие с бизнес заказчиком на команде отражается в минимальном объеме.
Если то что они хотят поменять укладывается условно в 1 день, то я просто принимаю это решение.
Если же надо к примеру на неделю остановить процесс и всё переписать, то тут я более подробно анализирую что именно это нам даст и иду с этими данными к бизнес заказчику.
Был довольно свежий пример, раньше на внесения изменений в одну часть анкеты кандидата мы тратили 2-3 дня, но после того как потратили меньше недели на рефакторинг смогли ускорить этот процесс и начать тратить менее 1 дня. В итоге счастлива и команда разработки (я верю что программистам приятно работать в «красивом» проекте) и заказчик (его потребности решаются быстрее и это вложении окупилось менее чем за месяц).
4. Как Вы объясняете Заказчику, что на самом начальном этапе на стадии проектирования были допущены ошибки и приняты неверные решение и что теперь наращивание функционала системы делать все труднее и труднее и времени на это уходит больше?
См. пункт 3.
Но что скрывать, бывают моменты, когда надо выкатить какую-то задачу в срок и тянуть больше нельзя. Тогда я принимаю решение выкатить «костыльное» решение. Но сразу договариваюсь с разработчиком что вернемся к этой части кода в течение определенного срока (не более 2 недель) и уже дальше общаясь с бизнес заказчиком объясняя ему что рефакторинг необходим, иначе через пару недель проект у нас завалится и мы потратим огромное время его восстановление.
DoD пишет тестировщик и я его проверяю.
Есть мнение, что если буду писать DoD сам, то тестироваться задачи будут только по моим DoD и никак иначе, что увеличит вероятность попадания ошибки на прод.
Для больших задач я при созвоне рассказываю как пользователи будут это использовать, но это не является исчерпывающим критерием приемки.
1. Разработку начали до моего прихода и оценка спринтов уже велась, так что считать первые спринты при мне удачными — нельзя. Хотя вы и правы они как раз и нужны для уточнения методов оценки.
2. Этот вопрос решался в моем взаимодействии с заказчиком и слабо связан с работой с аутсорс команды, поэтому он и не описан тут. Если интересует могу предоставить статистику с учетом всех этапов.
3. Опять же согласен с вами. Но разработку начинали до меня на базе уже сложившихся процессов. Поэтому этим аспектом занялись только когда он начал «гореть».
Деплой на тестовые сервера как написано в статье автоматизировали. Деплой на прод делаем в ручном режиме, с учетом того что делаем это не чаще 2 раз в неделю с затратой около 1 часа времени не вижу смысла сейчас автоматизировать и этот процесс.
Модульные тесты пишутся, но покрывают далеко не весь код, а только наиболее важные и сложные модули.
День добрый, спасибо за обратную связь.
Проверим и доработаем!
Очень больная тема эта метрика, к сожалению не могу её снять сейчас.
Для этого планирую немного изменить процесс работы в jira (а это возможно только после нового контракта с командой разработки) и начать снимать её в феврале.
Но да, писать свои критерии приемки я не стал именно из-за QA, до того как он начал писать DoD с моим ревью задачи после тестирования часто имели много ошибок, иногда очевидных.
Аналитика моя или разработчиков?
Очевидно коэффициент зависит от объема и сложности задач.
Думаю для крупных аналитика/архитектура разработчика ко всему процессу у нас имеет коэффициент x5, может больше, но точно меньше x10.
Я в детали кода не лезу, ревью не провожу, экспертом по технологиям не являюсь и т.д.
Так что назвать меня тимлидом довольно сложно.
Как я писал мне не нужна точная оценка времени. Для меня (в силу контрактных особенностей) даже выгодно если программисты будут ошибаться в оценке. Но мне надо чтобы ожидания бизнес-заказчика оправдывались, поэтому ошибка пусть будет, но она будет предсказуемой.
И в силу контрактных особенностей разработчикам всё равно надо проводить оценку своих задач.
Если чуть-чуть пояснить эти особенности, то мы платим им за время затраченное на задачу, если время затраченное сильно превысило оцененное, то к сумме будет применяться коэффициент вплоть до коэффициента 0,1.
Про своеобразность — согласен.
Но давайте приведу примеры:
У нас есть фронтэнд разработчик, который совсем ничего не может делать в бекэнд части.
У него в спринте 3 задачи по фронтэнд и ещё есть 10 задач по бэкенд.
Он молодец и сделал все свои 3 задачи раньше срока. Что ему делать дальше? Добавлять задачи в спринт? Плохая идея, может не выдержать тестировщик. Брать задачи бэкендера? Как я говорил таких компетенций у него нет. Помогать тестировать? Лучше и дешевле это сделает тестировщик.
В итоге остается только брать задачи, которые позже попадут в следующие спринты.
а) Подойти к бизнес-заказчику и сказать давай релиз отодвинем на 1-2 дня?
б) Подойти к бизнес-заказчику и сказать, вот сегодня мы выкатим не особо нужные тебе фичи, но вот через неделю выкатим то что тебе реально надо.
И я выбираю 1-ый путь, что не согласовывается с чистым скрамом, но я нигде и не говорил что мы живем по этой методологии.
Остальная метрика. Она не очень показательна, как мне кажется.
Появляются зачастую задачи, которые надо решать не в ближайшую неделю. Или после оценки принимается решение о снижении приоритета. Что увеличивает время в столбце — До начала разработки.
Также время в ожидании релиза не показательно к примеру:
а) программист может быстро успеть решить все таски в текущем спринте и приступить к следующему, что приведет что часть его задач будет долго ждать релиза.
б) программист может сильно затянуть с решением своих задач, которые критически выкатить в ближайший релиз, что может привести к увеличению срока всех остальных задач в ожидании релиза на 1 день.
И оба результата будут иметь одинаковый эффект в столбце — Ждет релиза.
Тут более показательны запланированные и фактические сроки релиза, но к сожалению таких данных у меня под рукой нет.
Давайте буду отвечать по частям.
1. Кто принимает решение об использовании тех или иных технологий?
Основной набор технологий был сформирован ещё до моего прихода и даже до текущий команды разработки. Есть 2 пути добавления/изменения технологий у нас в проекте:
а. Я хочу что-то поменять, доношу свои потребности до команды и они мне предлагают варианты технологий/средств применимых для этого.
б. Команда сама приходит к мысли что им проще жилось бы с какой-то технологией/средством, они мне об этом говорят и обосновывают свою позицию. Если убеждают (обычно убеждают), то мы начинаем её использовать.
2. Кто определяет архитектуру системы?
Глобально архитектуру системы определяет команда разработки, но если я считаю что кусок встраивается довольно большой, то я принимаю участие при обсуждении архитектуры.
3. Как Вы объясняете Заказчику, что на самом начальном этапе на стадии проектирования были допущены ошибки и приняты неверные решение и что теперь наращивание функционала системы делать все труднее и труднее и времени на это уходит больше?
Для команды разработки заказчик — я. Моё взаимодействие с бизнес заказчиком на команде отражается в минимальном объеме.
Если то что они хотят поменять укладывается условно в 1 день, то я просто принимаю это решение.
Если же надо к примеру на неделю остановить процесс и всё переписать, то тут я более подробно анализирую что именно это нам даст и иду с этими данными к бизнес заказчику.
Был довольно свежий пример, раньше на внесения изменений в одну часть анкеты кандидата мы тратили 2-3 дня, но после того как потратили меньше недели на рефакторинг смогли ускорить этот процесс и начать тратить менее 1 дня. В итоге счастлива и команда разработки (я верю что программистам приятно работать в «красивом» проекте) и заказчик (его потребности решаются быстрее и это вложении окупилось менее чем за месяц).
4. Как Вы объясняете Заказчику, что на самом начальном этапе на стадии проектирования были допущены ошибки и приняты неверные решение и что теперь наращивание функционала системы делать все труднее и труднее и времени на это уходит больше?
См. пункт 3.
Но что скрывать, бывают моменты, когда надо выкатить какую-то задачу в срок и тянуть больше нельзя. Тогда я принимаю решение выкатить «костыльное» решение. Но сразу договариваюсь с разработчиком что вернемся к этой части кода в течение определенного срока (не более 2 недель) и уже дальше общаясь с бизнес заказчиком объясняя ему что рефакторинг необходим, иначе через пару недель проект у нас завалится и мы потратим огромное время его восстановление.
DoD пишет тестировщик и я его проверяю.
Есть мнение, что если буду писать DoD сам, то тестироваться задачи будут только по моим DoD и никак иначе, что увеличит вероятность попадания ошибки на прод.
Для больших задач я при созвоне рассказываю как пользователи будут это использовать, но это не является исчерпывающим критерием приемки.
2. Этот вопрос решался в моем взаимодействии с заказчиком и слабо связан с работой с аутсорс команды, поэтому он и не описан тут. Если интересует могу предоставить статистику с учетом всех этапов.
3. Опять же согласен с вами. Но разработку начинали до меня на базе уже сложившихся процессов. Поэтому этим аспектом занялись только когда он начал «гореть».
Модульные тесты пишутся, но покрывают далеко не весь код, а только наиболее важные и сложные модули.