Я в тестировании 12 лет, работал в Наумен и Яндекс.
Сейчас я возглавляю отдел тестирования в Контуре из 150 человек и продолжаю работать тестировщиком в одной из команд. После шести месяцев аттестации менеджеры разных команд рассказали, какие цели они поставили перед своими тестировщиками.
У каждого пятого было такое: «Научитесь оценивать сроки выполнения задач по тестированию».
Зачастую такого рода «оценка сроков» требуется не только от тестировщиков, но и от разработчиков.
Оценка сроков в 95% случаев.
Спасибо, xkcd .
Я считаю абсолютно вредной практиковать, когда исполнитель оценивает сроки выполнения отдельного задания.Сейчас я объясню, как это работает. О произведениях классиковЭто напрямую связано с отсутствием системного образования и низкими требованиями к руководителям.
Максим Дорофеев - эффект сокращения сроков
Цитирую из книги « Техники джедаев ", хотя это было возможно Закон Паркинсона цитировать:К нам приходит человек, ставит задачу и спрашивает, сколько времени может занять ее выполнение.Оценивая задачу, мы, конечно, хотим назвать срок, к которому мы ее обязательно выполним, а поскольку многое может случиться (и мы подозреваем, что что-то обязательно произойдет), мы включаем в оценку определенное количество времени.
.
Вместо того, чтобы сразу приступить к выполнению задачи, мы «занимаемся срочным», поскольку «эта задача еще не горит» — у нас есть вышеупомянутый резерв.
Задача начинает «дымить», и мы приступаем к ней.
Если ничего не происходит, значит, мы вовремя, а если что… Мы уже потратили резерв на это «что-то» и в итоге опаздываем.
В результате любой срок, названный крайним сроком, становится крайним сроком, раньше которого задача не будет завершена.
К особенно неприятным последствиям это приводит при работе в команде, когда реализация одной задачи или проекта требует сотрудничества разных специалистов и разных отделов.
Человек как выпрямитель (и диод) — иллюстрация из «Техники джедая».
видео там тоже.
Том ДеМарко - Человеческий фактор
В пятой части первой главы есть ссылки на исследования зависимости производительности от того, кто проводил оценку сроков.
Кратко: сам факт оценки влияет на сроки в худшую сторону примерно на 40%.
Рекомендую прочитать.
Все факторы, перечисленные в пятой главе, актуальны и сегодня.
Деминг и Нив.
Эпоэкспериментируйте с красными бусинами За последний год я дважды слышал от менеджеров: «Мы научились укладываться в сроки, исходя из оценок задач, теперь такой-то программист или тестировщик вообще не нарушает сроки, которые он себе поставил».
Я думаю, что это чрезвычайно серьезная проблема, потому что это значит, что данный программист или тестировщик систематически и сознательно завышает сроки, работает расслабленно и врёт руководителю .
В мире существуют вариации, и ненарушение оценок для конкретных задач означает, что оценка такого человека всегда находится справа от кривой распределения фактического периода работы.
Авторы, упомянутые в заголовке, говорят, что единственный правильный способ оценки времени — статистический.
Следует оценить пакет типовых задач.
«У нас у всех разные задачи»? Это ложь.
В течение года не будет много разных задач.
Как правило, такое заявление является признаком непродуманности процесса и невыполнения упражнений: декомпозиция, MVP, прототипы, стандартизация.
О клиентах, которым нужны сроки Во-первых, следует отметить, что чаще всего – и это само по себе забавно – от ответа исполнителя ничего не зависит, потому что тайминг имеет уже .
Менеджер не заинтересован сколько времени нам понадобится, чтобы выполнить задание? , А Уложимся ли мы в срок и что именно мы сможем сделать? .
Это разные вопросы и на них нужно отвечать по-разному.
Как правило, ответ на вопрос «успеем ли к заданному сроку» — это аналитика и MVP, качественная инфраструктура разработки и объем технического долга, а именно сложность рефакторинга и наличие автоматических регрессионных тестов.
Еще раз: определение сроков мешает подрядчику уложиться в срок.
Во-вторых, есть ряд развивающих упражнений.
Не все из них простые.
Они не отвечают напрямую на вопрос «когда функция будет готова».
Однако они уменьшают размер поставки, уменьшают сложность разработки и тестирования и, в конечном итоге, уменьшают изменчивость графика.
- MVP
- декомпозиция проблемы
- ограничение незавершенной работы (программист не берется за новые задачи, пока не будут выполнены старые)
- отдельные выпуски рефакторинга и последующих функций
- отдельный выпуск бэкенда, фронтенда и других частей продукта
- канареечные релизы
- Применение флаги функций
- умение тестировщиков отделять важные дефекты от неважных
- способность команды выпускать релизы с неважными дефектами
Если упражнения не выполнены, то, скорее всего, любой срок, указанный руководителем, будет ложью.
О некомпетентных менеджерах Очень легко перепутать оценку времени (когда задача будет выполнена) и оценку усилий (сколько времени потребуется на разработку функции).
Оценивать сроки, как мы уже выяснили, если не вредно, то, по крайней мере, бессмысленно.
Но оценка затрат на рабочую силу — весьма полезное занятие.
Необходимость оценить трудозатраты при выполнении задачи вынуждает нас выполнить перечисленные выше полезные упражнения: главным образом, декомпозицию этой задачи.
Но мы должны помнить об этом оценка трудозатрат в команде с некомпетентным менеджером очень легко превращается в оценку сроков .
Существует миллион когнитивных искажений и непонимание того, как работают производственные цепочки.
Пример из жизни: — Сколько времени вы потратите на эту функцию? — Я буду писать полторы недели и исправлять ошибки три дня.То есть разница между «Я потрачу на эту задачу день» и «задание будет готово через день» множественная и принципиальная.— То есть оно будет готово через 3–4 недели?
Ты учишь жизни, но чего ты добился сам? Да, давайте поговорим обо мне и моей команде.
Некоторые из перечисленных упражнений мы успешно делаем, а некоторые учимся делать.
Некоторые этого не делают, и это печально.
Я думаю, что мы научились ограничивать количество невыполненных работ, рефакторинг перед выпуском и отделять важные ошибки от неважных.
Вот как мы оцениваем сроки тестирования.
Делим задачи на маленькие, большие и другие.
Около половины задач второстепенные; их делает дежурный тестер в свободное время.
Небольшая задача помечается в YouTrack тегом «за час» и выполняется за один подход (от получаса до двух часов), если не возникает осложнений.
Большие задачи помечаются тегом «проект», и по ним сразу понятно, что этого просто не произойдет. У каждой основной задачи есть руководитель, задача которого — следить за выполнением упражнений из списка выше.
Остальные задачи никак не отмечены.
Упражнения из списка начинают делать, если затраченное на них время превышает произвольно выбранный и переменный лимит в 2 недели.
Если в очередь попадает срочная задача, нужно бросить все и заняться ею.
Не надо оценивать.
Однако будет полезно уточнить сроки, чтобы понять, какие дефекты и недостатки можно устранить.
Таких срочных задач меньше десяти процентов.
Последний раз я засиживался на работе по просьбе руководителя для выполнения срочного задания более двух лет назад. Пару раз раньше, в 2015 и 2016 годах.
P.S. Один из самых важных навыков в нашей работе — не делать лишней ерунды.
В том числе не заниматься «прикидкой сроков» и самообманом.
Я желаю тебе того же.
(Подпишитесь на нашу Telegram-канал , там не плохо.
) Теги: #deadline #peopleware #джедайские техники #демарко #дорофеев #деминг #оценка времени #сроки реализации #мужские части #тестирование веб-сервисов #управление разработкой #управление проектами #управление продуктом
-
Веб-Аналитика: Технология Или Образ Жизни?
19 Oct, 24 -
Совмещение Ip-Адресов — Freebsd
19 Oct, 24 -
Идти! Идти! Идти…
19 Oct, 24 -
Офис Sup Глазами Провинциальных Дизайнеров
19 Oct, 24 -
Честная Жеребьевка
19 Oct, 24
