Цитаты из книг автора «Алексей Минкевич»

Согласно первому изданию книги Extreme Programming Explained, выделяют четыре группы основных приемов экстремального программирования. 1. Короткий цикл обратной связи (Fine-scale feedback). Разработка ПО является диалогом между возможностями и желаниями, при этом меняется и то, и другое. В этих условиях нужно искать баланс между требованиями бизнеса, техническими возможностями и качеством. Владелец продукта или заказчик работают напрямую с командой и всегда доступны для вопросов и диалога. 2. Процесс разработки непрерывный, а не пакетный. Если есть хороший инструментарий по сборке, автоматическому тестированию и выпуску в продакшн, то публиковать новый функционал можно по его готовности частыми небольшими релизами. При этом каждая строчка кода может попасть в релиз почти сразу после написания. Чтобы это стало реальностью, нужен хорошо подготовленный инструментарий непрерывной интеграции (Continuous integration). Команда непрерывно осуществляет рефакторинг и улучшение дизайна, архитектуры продукта, модулей системы и процесса разработки. Хорошим процентным соотношением считается 70 на 30: 70% времени команда работает над задачами бизнеса, а 30% — над рефакторингом и устранением дефектов. 3. Простота (Simple design) против избыточного проектирования. Как ни странно это прозвучит, но очень легко сделать что-либо сложным. Придумать действительно красивое и простое решение всегда тяжело: это требует времени. Французский ученый и философ Блез Паскаль заметил: «Я пишу длинно, потому что у меня нет времени написать коротко». С точки зрения проекта это означает, что его суть должна умещаться в одну-две фразы или выражаться в емком образе, как миссия компании. Для упрощения работы командами используются единые стандарты по написанию кода и автоматические инструменты для проверки соответствия этим стандартам. 4. Социальная защищенность программистов (Programmer welfare). Команда должна уметь поддерживать высокий рабочий темп на неопределенном временном промежутке. И речь идет не о неделях, а о месяцах и даже годах. Поэтому очень важно соблюдать баланс «работа — жизнь». У разработчиков должен быть нормальный рабочий график, чтобы они не «сгорали». Все эти четыре группы приемов не только верны в теории, но и на практике используются в IT. Они продиктованы здравым смыслом и опытом. Теперь давайте посмотрим на Lean-подход, который очень хорошо дополняет Extreme Programming.

От управленческого Agile перейдем к инженерному. Экстремальное программирование (Extreme Programming, XP), как и большинство других гибких методологий, — скорее философия, чем набор инструментов. Модель рабочего процесса по XP выглядит как частая последовательность выпусков продукта. Настолько частая, насколько это возможно. Но при этом обязательно, чтобы в выпуск входила новая атомарная функциональность. «Атомарная» означает, что нужно продемонстрировать хоть и маленький, но новый и полностью рабочий функционал. Разбить функционал на атомарный не так просто, как кажется. В самом начале разработки клиентского приложения такси-сервиса мы решили использовать такой подход и провели несколько дней за размышлениями, как можно разбить функционал приложения на атомарный. В итоге в первый спринт была создана иконка приложения, по клику на которую оно запускалось и открывалась карта. Во втором спринте на карту была добавлена метка с текущим местоположением пользователя, а еще появилась возможность масштабировать карту. В третьей итерации появилась строка адреса, и при движении пользовательской отметки по карте автоматически считывался текущий адрес, и т.д. В каждой итерации добавлялся атомарный функционал.

4. Измерение времени цикла. Главная метрика эффективности при использовании Kanban — это скорость, с которой задача «пролетает» из «Бэклога» в «Готово». Поэтому важно измерять среднее время на выполнение одной задачи и постоянно оптимизировать процесс, чтобы сократить его. Отслеживать скорость можно при помощи контрольной карты — это метрика, которая указывает среднее время прохождения задачи по доске. Хорошо, если каждый месяц скорость немного возрастает. Выглядит эта метрика так (рис. 66). Точки — время, за которое выполнялись задачи. Прямая линия — среднее время выполнения задач за период времени, выбранный для отчета. Волнистая линия — скользящее среднее, показатель изменения скорости прохождения задачи по доске со временем. В нашем примере скользящее среднее уменьшается. Это очень хорошо и свидетельствует о постоянном улучшении процесса. Светло-серая область — стандартное отклонение. Оно показывает, насколько предсказуемо время выполнения задач. Kanban имеет множество применений. В сфере IT он распространен в командах оперирования, где идет большой поток задач, которые может выполнить практически любой член команды. Также он отлично показывает себя в тех случаях, когда приходится работать в условиях очень высокой неопределенности — например, над продуктом на высококонкурентном рынке с частыми сменами приоритетов бизнеса и необходимостью регулярно вносить в систему изменения с целью тестирования различных гипотез.

3. «Охота на бутылочные горлышки». Как только вы наладите свои мосты и узнаете их ограничения, у вас появится информация о пропускной способности вашей системы, которая эквивалентна его самому медленному участку, или «бутылочному горлышку». Увеличение производительности самого медленного шага ведет к общему увеличению производительности всей системы. Kanban наглядно демонстрирует, где в процессе разработки находится «бутылочное горлышко», то есть перед какой колонкой скапливаются карточки. Одним из способов решения вопроса «бутылочных горлышек» является их расширение за счет более свободных узлов. Например, если в колонке «Проверка кода» постоянно образуются очереди из задач выше определенного уровня, то следует перестроить процесс таким образом, чтобы они не застревали в этом статусе. Одна из наших команд договорилась, что утро рабочего дня начинается с ревью и коллеги не приступают к разработке, пока вся колонка «Проверка кода» не опустеет. Методология Kanban подразумевает наличие кросс-функциональной и самоорганизующейся команды, каждый член которой может помочь коллеге. С моей точки зрения, это возможно только частично. Например, если тестирование не справляется, то разработчики помогают тестировщикам, что теоретически возможно. А вот обратный вариант в моей практике не встречался. Если Kanban указывает на то, что «бутылочное горлышко» находится на этапе разработки, то работать с ним нужно или увеличивая численность команды, или инвестируя в инструменты сборки и тестирования. Работа с «бутылочными горлышками» помогает видеть проблемные места и итерационно улучшать работу над самым медленным шагом, что, в свою очередь, ускоряет весь процесс.

2. Ограничение Work in Progress (WIP). Это количество задач, выполняемых одновременно на каждом этапе разработки. Проще говоря, мы определяем максимальное количество задач, которое можем выполнить на одном этапе. Ограничения позволяют нам избежать тех самых завалов. Представьте себе мост, по которому спокойно проезжают машины со скоростью 80 км/ч при 70%-ной загрузке. Если же загрузка вырастает до 80%, то скорость падает до 60 км/ч, при 90%-ной загрузке скорость составит всего 20 км/ч, а когда загрузка приближается к 100%, движение практически останавливается. По сути, при разработке это правило действует так же: чем меньше у исполнителя параллельных задач, тем быстрее он выполняет свою работу. Быстро и качественно справляться можно только тогда, когда ты сфокусирован на небольшом количестве задач, а в идеале — на одной. Если параллельно вести десяток дел, то время выполнения каждого из них серьезно увеличивается. Например, если тестировщик вдруг заметил баг, а разработчик занялся другой задачей, не дожидаясь завершения проверки, то это окажет значительное влияние на время, за которое будет завершена первая задача.

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

Обратите внимание на приведенную выше схему. Наверху нашей доски есть строка (иначе ее называют «плавательная дорожка» — от англ. swimlane) «Срочно», куда мы помещаем срочные задачи, которые нужно завершить в первую очередь. Такой подход таит в себе ловушку: если злоупотреблять этой строкой, то постепенно туда могут перекочевать все ваши задачи и вы опять вернетесь к вопросу «Как приоритизировать работу». Поэтому рекомендуем вам заранее договориться о правилах приоритизации задач.

Задачи продвигаются по колонкам слева направо. Правда, иногда бывает движение и в обратную сторону — к примеру, если в ходе проверки кода выяснилось, что требуется доработка. Важно понимать, что естественным является только движение слева направо. Любое движение в обратную сторону должно приравниваться к браку и, следовательно, подвергаться анализу с целью устранения.

четыре основных принципа Kanban. 1. Визуализация процесса разработки. Одно из основных достоинств Kanban заключается в том, что с его помощью можно визуализировать всю незавершенную работу, что, в свою очередь, дает вам наглядное понимание потоков работ и их ограничений. Для того чтобы начать работать по Kanban, вам понадобятся карточки и доска. Обычно для физических досок в качестве карточек используют стикеры (Post-it notes). Каждая задача записывается на отдельном стикере, который затем помещается на доску, расчерченную на столбцы. Каждый столбец соответствует этапу в рамках вашего процесса разработки; в производстве колонки могут быть эквивалентны узлам обработки или станкам. Главное заблуждение — принимать в качестве «узла» конкретного человека, так как он может выполнять сразу несколько ролей и вместо упрощения потоков производства у вас может получиться «порция спагетти». В самом простом случае столбцов будет три: «Бэклог», «В разработке», «Сделано». По мере работы над задачей карточка продвигается по колонкам от «Бэклога» до «Сделано». В своей работе мы использовали такие колонки: Бэклог (перечень всех задач, которые нужно сделать); Выбрано для работы (выбранные для разработки задачи, которые мы будем брать в работу в ближайшее время); В работе (задачи, работа над которыми ведется в настоящее время); Проверка кода (задачи, в которых процесс непосредственно разработки уже завершен, но требуется согласование решения с другими членами команды и проверка кода); Тестирование (задачи, с которыми работает команда тестирования); Для демо (задачи, результат которых можно демонстрировать владельцу продукта); Готово (завершенные задачи, результатом которых является работающее решение, что подтверждает владелец продукта после демонстрации).

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