10:00. Время для стендапа вашей команды.
Все рассказывают о заявках, которые они закрыли вчера, и объясняют, над чем они будут работать сегодня.

Когда раунд подходит к вам, и Agile-коуч / менеджер проекта упоминает заявку, над которой вы работаете, скажите:

Я почти закончил, мне просто нужно добавить несколько последних штрихов, но это должно быть просто и быстро

Перемотка вперед на пару дней или даже больше, и вы обнаружите, что повторяете это снова и снова.

Да, я почти уверен, что сегодня закончу, вчера у меня было несколько блокировщиков, но теперь я действительно почти закончил!

Будем честны. Сколько раз это случалось с вами (или вы видели, как это происходит в вашей команде)?
Как может задача, о которой вы сказали, что она почти выполнена, в итоге заняла еще 1 или 2 дня (если не целую неделю)?

Не пытаюсь быть злым или властным здесь. Я оказывался в такой ситуации много раз. Дело в том

почему мы говорим другим и себе почти готовую ложь?

Страх осуждения

Боимся ли мы признаться перед коллегами и начальством в том, что работаем медленнее, чем прикинули?

Избегайте конфликтов

Пытаемся ли мы быть уступчивыми и не заявляем, что мы все знали, что выполнить работу в срок не представляется возможным, и оценка (которая была навязана команде руководством) была неправильный?

Синдром самозванца

Это связано со страхом осуждения, но больше связано с внутренним страхом быть не в состоянии полностью справиться с задачей, и что, если мы говорим, что застряли или боремся, другие могут подумать, что мы не те эксперты, за которых притворяемся. .

Принцип Парето

Осознаем ли мы вообще, что мы сильно отстаем от графика, потому что самая трудная часть / или просто самая длинная часть еще впереди?

Принцип Парето, также известный как правило 80/20, говорит нам, что 80 % функций реализуются всего за 20 % времени, а на оставшиеся 20 % приходится 80 % времени. Зло кроется в деталях: мы, возможно, уже быстро создали форму или RestAPI, но нам все еще нужны все проверки, правильная обработка ошибок или CSS, и это определенно займет много времени!

Эффект Даннинга Крюгера

Осознаем ли мы все наши навыки, имеем ли мы четкое представление о задаче, которую необходимо выполнить, о неизвестных, которые могут быть скрыты, о возможных блокаторах? , технических знаний, необходимых для этого, возможно, мы действительно переоцениваем свои способности?

Ловушка перфекционизма

Может быть, мы просто слишком перфекционисты?

Мы были очень близки к завершению ( почти готово_), но затем мы решили провести рефакторинг этого уродливого фрагмента кода, используя какой-то шаблон проектирования, или абстрагироваться от всех дубликатов, и теперь мы прошли половину рефакторинга, и все перестало работать, (и, конечно же, мы не хотим/не можем спрятать все наши красивые изменения и поставить старую версию)

или, может быть, мы просто действительно не знаем, что означает «Готово».

ГОТОВО

Что означает «Готово» для вас, для вашей команды, для вашего босса, для вашего клиента?
Вы закончили, когда вы только что официально выполнили список вещей в тикете и можете, наконец, переместить тикет из столбца «Выполняется», а затем пойти выкурить сигарету или поиграть в кикер?

Когда задание можно считатьвыполненным?

50 оттенков готового

Существуют ли разные уровни готовности?

Обсуждали ли вы когда-нибудь это с членами вашей команды и agile-коучем?
Каковы шаги для выполнения задачи?

  • Реализация функции
  • Пишите модульные тесты
  • Проведите несколько ручных тестов, чтобы найти ошибки в использовании
  • Подготовьте его для различных сред
  • Интеграционные тесты
  • Разверните его

Может быть, ваша команда разделяет их на разные задачи или между разными разработчиками с разным стажем работы?
Возможно, вы пришли из команды или компании, где никто никогда не заботился о модульном тестировании, и теперь вам трудно рассматривать их как часть своей задачи, хотя на самом деле они воспринимаются как должное во время доставки функции.

Делать правильные вещи

Также может случиться так, что вы закончили, но сделали что-то неправильно, потому что боялись задавать вопросы или исходили из неверных предположений.

Возможно, вас попросили создать простой прототип для проверки идеи, будущего проекта. Или MVP (Minimum Viable Product) — отшлифованная, работающая, готовая к производству, протестированная версия продукта, но с очень базовыми функциями.
Но вы все еще реализуете Restful API. для всех источников данных или бороться с CSS за выравнивание или стиль этой кнопки «Отправить». Все, что никому не нужно на этом этапе.

Может быть, вы зациклились на охвате модульным тестированием и заблудились в насмешках/заглушках каждого фрагмента кода, когда некоторые модульные тесты и дополнительные интеграционные тесты были бы проще, быстрее и на самом деле более полезными.

Многие люди, говорящие о разработчиках 10X, думают только о технических навыках и скорости, но забывают об этом фундаментальном аспекте эффективности И результативности.

Эффективность заключается в том, чтобы делать все правильно; эффективность заключается в том, чтобы делать правильные вещи.

Нет смысла быть быстрым и совершенным, если вы в конечном итоге сделаете то, о чем никто не просил.

Ползучесть области

Задавать вопросы, понимать требования и ожидания также важно для переопределения объема вашей задачи и улучшения планирования спринта и оценки команды
Возможно, задачу следовало разделить на большее количество заявок, более детализированные подзадачи, а затем общая картина и мелкие детали были бы более четкими, и поэтому время, необходимое для выполнения задачи, было бы более точным.
Когда цели определены, реже возникает множество других небольших изменений в требованиях по пути ( без корректировки сметы или даты поставки)

Узкие места при проверке кода

Сколько раз вы думали, что закончили, но затем вам возвращали билет во время проверки кода, потому что ваш код был полон опечаток, вы не писали модульные тесты, вы забыли добавить проверку во входные данные формы или вы забыли учитывать переменные env и слишком много зависимостей жестко закодированы?

Просто тот факт, что вы переместили тикет на утверждение в установленное время, не означает, что это было сделано и что вы доставили вовремя, и теперь это вина надоедливого код-ревьюера и теперь вам нужно больше времени, чтобы «сделать» эти корректировки. (см. Определение сделано выше)

Ошибки

Я не говорю, что все, что вы отправляете, должно быть без ошибок, но если вас попросили реализовать форму, и если вы забыли добавить базовую проверку для обязательного поля, и все вылетает, вы не можете просто сказать...:

ну, но это ошибка! Я только что реализовал форму, давайте закроем заявку на историю/задачу и откроем для нее запись об ошибке. (к сожалению, я это слышал…)

и вы называете это "готово"?

Итак, как вы видели, причин, по которым задача не может считаться выполненной или не может быть выполнена в отведенное время, предостаточно.
Своевременная доставка необходима для успеха вашей команды и компании, а также для профессионального разработчика.

Это означает, что мы никогда не должны быть расплывчатыми, и мы должны осознавать цель и наш прогресс. И если случится так, что вы отстанете от графика, если поймете, что не успеете вовремя, не лгите, не опускайте правду, упоминая «простые последние штрихи или не относящиеся к делу заминки».

Речь идет не о чувстве вины и стрессе по этому поводу, а скорее об информировании вашей команды и руководителя проекта, чтобы, возможно, у вас было больше времени или вы могли получить некоторую помощь. сильный>.

Изображение на обложке: Кейптаунский мост на форшорной автостраде — строительство началось в 1970 году и осталось незавершенным в 1977 году — и до сих пор существует (я видел это во время своего отпуска в Южной Африке в октябре прошлого года и был совершенно ошеломлен..)

Первоначально опубликовано на https://dev.to 30 марта 2020 г.