Как избежать потерь при написании кода

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

Долгий путь к качеству полон отклонений, фальстартов и обходных путей. Враг качества – это отходы, потому что отходы никогда не желательны. Никто никому не платит за вывоз мусора. Иногда мы терпим расточительство как часть процесса создания чего-то полезного и желательного, но чем больше мы сможем сократить количество отходов при создании чего-либо, тем лучше.

В разработке программного обеспечения потери можно выразить несколькими способами:

1. Дефекты
2. Холостой ход и ожидание
3. Перепроизводство
4. В процессе
5. Любая другая деятельность, которая непосредственно не приносит пользы пользователям.

Давайте рассмотрим каждый из этих пяти видов отходов.

Дефекты

Кажется, в индустрии программного обеспечения преобладает мнение, что ошибки (дефекты) неизбежны. Дело не в том, а когда и в каком количестве ошибки попадут в производство.

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

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

Холостой ход и ожидание

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

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

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

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

Перепроизводство

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

Это ужасное раздувание создает много отходов. Борьба с раздуванием — вот что такое разумная дисциплина разработки программного обеспечения.

В процессе

Одна из самых больших проблем в разработке программного обеспечения известна как Geek-At-Keyboard (GAK). Распространенным заблуждением является то, что инженеры-программисты тратят большую часть своего времени на написание кода. Это далеко от истины. Большая часть времени, затрачиваемого на повседневную деятельность (помимо посещения собраний), уходит на действия с клавиатурой, не связанные с написанием кода: работа с конфигурациями и средами, ручной запуск приложения и навигация по нему, ввод и повторный ввод тестовых данных, пошаговое использование отладчика и т. д.

Вся эта деятельность – пустая трата времени. Они не способствуют созданию ценности. Одним из наиболее эффективных средств минимизации непроизводительного времени GAK является разработка через тестирование (TDD). Написание тестов перед написанием кода — проверенный метод избежать чрезмерной обработки. Подход «сначала тестирование» — очень эффективный способ устранения потерь.

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

На заре нашей профессии ценность измерялась количеством строк кода, создаваемых за единицу времени (за день, неделю, месяц и т. д.). Позже от этого довольно неэффективного способа измерения ценности отказались в пользу рабочего кода. Убедительной корреляции между количеством строк кода и рабочим кодом нет. А как только работающий код стал мерилом ценности, количество строк кода стало неважным.

Сегодня мы понимаем, что работающий код также является бессмысленным показателем. Тот факт, что код компилируется, строится и работает, не означает, что он делает что-то ценное. Успешное выполнение кода может заключаться в выполнении бессмысленных операций, например, подсчете от 0 до 10, а затем обратно в 0. Гораздо важнее сосредоточиться на коде, который соответствует ожиданиям конечных пользователей.

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