Архив рубрики: TOC

Книга: The Phoenix Project

clip_image002[7]Итак, я добрался до Святая Святых девопса – бЫзнес-романа The Phoenix Project. Снова прозреваю, что кроме меня его уже все читали. Так что я снова коротенько по задевшим лично меня моментам, равно как и по непонятным или смешным.

Интересный подход: выкатывать, но не включать функционал. Тогда код уже на проде и всё работает, в общем-то. Или включаем, но не для всех пользователей или сценариев. Или только для тестирования. Увы, не для всех типов ПО подходит. Но нужно использовать, где это возможно.

Есть три путя:

1)      Никакой локальной оптимизации, никакого «с моей стороны пуля вылетела». Делаем мелкими партиями, никогда не передаём дефектный код дальше. Инструментарий:

a.       Continuous build, integration and deployment.

b.       Создание окружений по запросу.

c.       Ограничение WIP.

d.       Построение safe systems and organizations that are safe to change. Вот этот кусок несколько абстрактен. Прозреваю, что пойму, когда настанет пора (или когда прочитаю DevOps Handbook J).

2)      Построение обратной связи. Не очень понятно, как мне это делать в своей ситуации. Тоже нужно разбираться.

a.       Остановка production line когда тесты и билды фейлятся. Здесь всё просто относительно, если мы качественно разберёмся с пп.1 и 2d.

b.       Постоянно улучшать работу даже в ущерб повседневной работе. Всё понятно, но нужно где-то взять политической воли. Есть взаймы у кого-нибудь? =)

c.       Создание быстрых автотестов, подтверждающих, что код всегда готов к деплою.

d.       Создание общих целей между Dev & Ops.

e.       Всепроникающая телеметрия, показывающая, всё ли хорошо. Тут печаль, в наших обстоятельствах это будет дорого, долго и сложно. Но подвижки есть.

3)      Создание культуры, которая пестует постоянные эксперименты и учёбу на ошибках и успехах.

a.       Создание культуры инноваций и принятия риска. Вот тут ещё учиться и учиться. Мне.

b.       Выделение хотя бы 20% времени на постоянное улучшение. Как показал эксперимент, тупо выделение этого времени не работает. Нужно предыдущий подпункт корректировать, да и ещё чего-то может не хватать.

Хотя везде идёт рефреном «break the silos», всё равно эта история – про повышение ответственности той части команды, которая пишет код продуктов. Автоматизация релизов просто не оставляет других шансов. Если ручное развёртывание Ops’ами релизов ещё как-то нивелирует последствия плохого кода или тестирования (админ может руками что-то откатить или допилить на лету вместе с разработчиком), то полная автоматизация должна это сделать сама. Нет, понятно, что разбудить админа, чтобы он починил, всё равно можно, но это дополнительное время простоя. Немного нивелируется это тем, что теперь ответственность Ops за инфраструктуру именно доставки кода и окружений также становится очень высокой. На самом деле, надёжность этого куска должна быть, кажется, запредельной. Чуть ли не выше доступности самих продуктов.

Автоматизировать всё нужно даже не для сокращения издержек, а для того, чтобы разрабы могли сами получать окружение, похожее на продуктив. Чтобы прохождение тестов на stage-среде действительно было маркой качества: развёртывание в бой не сорвётся. И чтобы переиспользовать эту экспертизу для разных команд разработки.

Вопросы:

По книге основные потоки работы это: бизнес-проекты, технические проекты, изменения, починка/тушение пожаров. Но как-то до меня из книжки не дошло:

1)      Почему разделяются бизнес и технические проекты? Обновление почтовой системы – технический проект? Но там есть функционал для бизнеса, допустим. В общем, мне это деление кажется несколько условным.

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

Из занятного: снова появляется Русская Мафия, которой с придыханием нужно продать данные ваших клиентов, украденные хакерами. Всё-таки к Медведю с Балалайкой мы, похоже, добавляем ещё один национальный бренд. =)

Легко ли читать: Да, легко и интересно. Всё-таки, это больше художка, и не так, чтобы плохо написанная.

clip_image004

Полезность: выше средней. Прорыва у меня пока нет, всех ответов нет. Нужно следующее читать. Но и зря потраченным временем это не назвать – польза однозначно есть.

clip_image006

 

Про задачки простые и не очень

clip_image002Одно из подразделений разработки в нашей компании использовало так называемые задачи-какашки (см. первую картинку). Это такие мелкие задачки, которые можно взять и быстро сделать. Что следует из быстро сделанной задачи? Правильно: рост удовлетворения, мотивации, и повышение уровня гормона «шиловжопин» ( (с) Cartmendum). Ну и задача, однако, тоже выполнена. Закидывались эти задачки в очередь команде тимлидом по какому-то набору принципов, из которого нам сейчас интересно только одно правило:

clip_image004

То есть количество таких задач должно быть ограничено. Причем, в разработках есть разные agile и прочие водопады, которые с помощью спринтов дополнительно позволяют ограничить объем задач на единицу времени. То есть хочешь, не хочешь, а более другими вещами заняться тоже придётся. В итоге, и фокус сохраняется, поскольку очередь задач конечна (это вообще достаточно важно), и мотивация от того, что нет выбора, что сделать (хотя выбор по прежнему иллюзорен ;) ), и приходится делать эту «мерзскую задачслу» прямо сейчас, тоже не сильно падает, поскольку чуть-чуть ее отложить можно.

В общем, в разработческом мире с этим если и не порядок, то хотя бы видимый порядок. А что в админском мире? А у нас получается следующая картина:

1) Нет никакой ложки никакого SCRUM‘а

2) Есть мнение, что задача, которая делается чистым временем полчаса, не должна делаться 2 недели. Это мнение ничем не обосновывается ничем, разве что «ну тут же полчаса»

3) График, показывающий сколько дней задачи валяются в беклоге выглядит вот так:

clip_image006

То есть ряд задач не выполняется вообще (внимание, вопрос: что это за класс задач обычно? ;)).

Как итог, количество таких мелких и приятных задач потенциально бесконечно, а тяжелые и неинтересные задачи как раз и сваливаются в категорию задач «More than month». Ну и часть проектов сдается с запозданием

Есть ли способы сохранять возможность ковырнуть мелкую задачу в промежутках между «тяжелыми», не откладывая последние навсегда? Вот, что пришло в голову за какое-то время:

1) Все-таки поставить ограничитель. Варианты:

a. Честность исполнителя

b. Физический ограничитель: количество таких-то задач не более, чем X%

c. Другой физический ограничитель: мы берем на неделю такие-то задачи, а остальные… Через неделю приходите

2) Забить на это дело: задачки ж выполняются, отчеты пишутся. А что проекты не в срок сдаем – так смотрите, сколько текучки – не успеваем, добавьте ресурсы.

3) Выполнять все строго по порядку. Не позволять изменять приоритет задачи в ближнем горизонте ни под каким соусом.

4) Считать задачи определенного типа более приоритетными, чем другие. То есть, если есть такая задача есть в беклоге, то за другие браться запрещено. По сути, это 1b, но с плавающим процентом.

У меня есть ощущение, что таксономия выше не полная. Есть ли у зала еще варианты?

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