Совершенствование процесса доставки программного обеспечения
Идеального процесса не существует — никогда не было и никогда не будет — я не пробовал их все, но я пробовал достаточно, чтобы понять, что попытка применить шаблонный заводской процесс к творческому, уникальному начинанию никогда не работает.
Вы не можете структурировать подачу искусства (вот почему это называется искусством).
Но вы можете освоить навыки, разработать инструменты и выяснить элементы, которые могут улучшить доставку этой творческой вещи.
Например, мне нравится думать, что я умею рисовать (мне трудно), но я продолжаю упорно над этим работать. Я работаю над этим каждый день, по крайней мере, 30 минут (обычно столько времени я трачу на то, чтобы разочароваться), я не беспокоюсь о карандашах или бумаге — я знаю книги, которые мне нравятся, и я использую базовые карандаши, которые Джек Кирби.
Это структура моего процесса доставки рисунков, которая обеспечивает творческую доставку.
Точно так же я отношусь к процессам доставки программного обеспечения — они существуют (процесс), чтобы обеспечить творческое и уникальное внедрение программного обеспечения. Во всех местах, где я работал, все процессы были разными — некоторые работали хорошо, некоторые провалились, — но благодаря этому я понял, каковы элементы успешного процесса доставки программного обеспечения.
Последовательность
Если я спрошу вас, как проект А сравнивается с проектом Б, что вы будете использовать в качестве этого определения, чтобы убедиться, что вы сравниваете яблоки с яблоками?
Будь то функции, истории, элементы бэклога продукта, задачи, ошибки, очки истории, часы, минуты, дни, размеры футболок, эпики, спринты, циклы и т. д. и т. д. — не имеет значения, что вы решите использовать. Важно то, что вы используете его последовательно во всех своих проектах, поэтому, когда дело доходит до вопросов и сравнений скорости разработки, циклов разработки, итераций, выпусков, скорости, того, что завершено, что осталось, как мы отслеживаем до финиша и так далее и тому подобное — вы сравниваете одно и то же.
Программное обеспечение есть программное обеспечение. Если вы пойдете по пути создания разных процессов для разных проектов, которые собирают разные наборы показателей, вы никогда не сможете сравнить, как один сравнивается с другим.
Простота коренится в последовательности, и когда вы соблюдаете ее последовательность, ваше время адаптации к новым проектам и предсказуемость того, что делает команда, резко возрастает.
Контекст домена
Программные процессы укоренены в домене, для которого они созданы. Программный процесс, который я использую для проектирования военно-морских кораблей, будет кардинально отличаться от процесса, который я использую для создания телефонных API.
Почему?
Поскольку контекст и потребность различны — разработка процесса создания телефонных API очень воспроизводима, у нас есть множество API для телефонных подключений, мы можем очень быстро перебирать эти API. Мы можем двигаться быстро, пробовать новые идеи, смотреть, как они терпят неудачу, и пробовать снова. Если я создаю программное обеспечение для военного корабля, цикл тестирования, скорее всего, будет значительно длиннее, а технологии и API, которые я использую, будут отличаться от API моего телефона, где я могу получить что угодно из Интернета.
Контекст отличается, и контекст следует учитывать и включать в то, что вы доставляете.
Доверять
Люди смеются, когда я говорю это, да, они смеются, потому что первое, что они говорят: «Конечно, мы доверяем друг другу», — и все же, когда они собираются на какую-либо часть проекта, все должны быть там.
Все они здесь, потому что мы не доверяем людям брать на себя инициативу, владеть частями того, что доставляется, и что-то делать с этим.
Я был в командах, которые преуспели и потерпели неудачу, и эти команды совершенно не похожи на команды, которые не доверяют друг другу. Когда команды не доверяют друг другу, ничего не получается, ничего не делается, они тянутся вперед, и все продолжают надеяться, что что-то произойдет, но этого не происходит — потому что они не верят друг другу даже в том, что они потерпят неудачу.
Так они впадают в паралич.
Вы должны доверять своей команде, и они должны доверять вам. Всегда помните, люди, поставляйте программное обеспечение, а не процессы.
Простота
Я говорил это раньше, когда обсуждал согласованность, но простота является ключом к доставке программного обеспечения. Вы не должны предоставлять процесс, вы должны предоставлять программное обеспечение. Если вы делаете это обременительным, если вы делаете его непонятым, если вы делаете его запутанным — измените свой процесс.
Я большой сторонник того, чтобы не автоматизировать процесс слишком рано. Запустите его на спринт или два, посмотрите, как он работает, запишите части, которые можно автоматизировать, и когда вы будете удовлетворены тем, что людям не нужно управлять процессом, и вы получаете от него то, что хотите.
Автоматизируйте это.
Упростите это.
Заставьте его петь так, чтобы когда люди регистрируют код, они пели ему дифирамбы.
Сделайте его последовательным, уважайте свою область, завоевывайте доверие в своей команде и сохраняйте простоту — это все, что вам нужно сделать для совершенствования процесса доставки программного обеспечения.
Хотите еще? Ознакомьтесь с моей книгой Code Your Way Up — она доступна в электронной или мягкой обложке на Amazon (Канада и США). Подпишитесь на нас в Твиттере @Codeyourwayup и узнайте больше о наших программах Software Leadership здесь.
