Как IT команде успевать в сроки

Рецепт, который был мной придуман под команду, чтобы добиться попадания в сроки. Протестирован слабо, но признан успешным :)

BDSMУправлениеНастройки

Рецепт, который был мной придуман под команду, чтобы добиться попадания в сроки. Протестирован слабо, но признан успешным :). О том, почему в целом эта затея провалена — в другой заметке.

  1. Задачи оценивают только исполнители. Не допускать «ребят, да чё там — возьмите эту ещё — она же лёгкая». При этом должны присутствовать незаинтересованные люди, имеющие компетенции в данной области, чтобы сроки были более-менее реальными.
  2. Морозим список задач на итерацию. Никакого «ещё вот это надо успеть и вот это». Да, мир бизнеса довольно часто меняется. Но давайте на пару недель будем морозить наше представление о том, что нужно — тогда хоть что-то сможем сделать.
  3. Исследовать до того, как брать. Пока непонятно, как решать, не берём в работу, а исследуем. Таким образом — исследование — это тоже задача, она ограничена во времени, у неё есть результат — план того, как мы будем делать с объяснением, почему мы делаем именно так.
  4. Блокируем зависимые “ресурсы” до исполнения. Человек блокируется на исполнение самой приоритетной задачи. Освобождается только после исполнения всей приоритетной задаче, переходя к приоритету ниже. Так реально важные задачи будут делаться (первыми), а неважные — оставаться неважными.
  5. Закладываем 50% времени на интересные задачи, внезапность и поддержку. На планировании исходим из того, что можем потратить на обязательные задачи только половину времени. Всё это — чтобы было время на авралы, болезни, лень и прочие вещи, растягивающие сроки. Мы не боремся с ними, мы их учитываем. А если всё же команда всё успела раньше — есть время улучшить инфраструктуру, порефакторить код, покрыть пробелы в тестировании…
  6. Катим большие задачи только в начале итерации. Иначе это приводит к затяжной разработке, растягиванию сроков — мы ведь вот-вот всё закончим!
  7. Merge делает автор PR, есть необходимые approve-ры (2 штуки от разных членов команды). Таким образом есть личная ответственность за pull-request у автора.

Это без очевидных вещей типа ограниченности итерации, тестирования, ежедневных летучек (стендапов), таск-трекинга и подобного.

Как он получился? На протяжении нескольких итераций я наблюдал за ходом разработки на позиции TeamLead. На протяжении нескольких ретроспектив записывал недовольство. Потом вечером сел и написал решения проблемам. На утро некоторые вещи отполировал, некоторые объединил.

Подходит ли он вам? Не факт — "у каждого офиса запах особый".

Главное — наблюдать, определиться с проблемами, их решениями и действовать (обозначить правила игры и их контролировать).

Фото OpenCola — дух OpenSource в мире FastFood
OpenCola — дух OpenSource в мире FastFood

С легкой руки энтузиастов всеобщей открытости одним из ее представителей стал общепит. Здесь термин «открытый продукт» приобретает буквальное значение. До сих пор бал в этой отрасли правили жадные монополисты, предпочитавшие держать свои технологии под толстым-толстым слоем шоколада.

Фото Команда sudo возвращает ошибку «unable to resolve host»
Команда sudo возвращает ошибку «unable to resolve host»

Это ошибка возникает, когда Linux не может определить хост, на котором он работает. Решение проблемы — добавить хост компьютера в DNS записи. Самый простой путь — добавить строчку в /etc/hosts.