Добро пожаловать во второй выпуск нашей серии «Семь отходов разработки программного обеспечения». В
первом эпизоде мы представили концепцию устранения потерь в наших усилиях по разработке программного обеспечения. Уничтожение отходов можно проследить вплоть до середины 1900-х годов, зарождения бережливого производства и системы производства Toyota (TPS). Вот как Тайичи Оно, отец TPS, описал его суть:
Все, что мы делаем, это просматриваем временные рамки, с момента, когда клиент дает нам заказ, до момента, когда мы собираем деньги. И мы сокращаем сроки, сокращая отходы, не связанные с добавленной стоимостью. [1]
Прочитайте другие части этой серии :
Как видите, устранение отходов — это прежде всего скорость. Как мы можем уменьшить длину временной линии?
Подумайте обо всех вещах, которые замедляют вас при реализации функции. Подумайте обо всех вещах, которые вы должны сделать (или отменить!), Чтобы вы могли выполнить свою «настоящую работу», ту работу, которая фактически повышает ценность для клиента. Это ваши накладные расходы. Накладные расходы равны отходам.
Первым источником отходов, на котором мы собираемся сосредоточиться, является частично выполненная работа. Что насчет частично выполненной работы, которая замедляет нас? Как это усложняет нашу работу в качестве разработчиков? В конце концов, не все ли частично сделано до того, как оно закончено? Чтобы понять, почему частично выполненная работа является настолько расточительной, вам нужно оглянуться назад на производственные отходы, из которых они взяты: инвентарь. Для слов об инвентаризации, давайте вернемся к фрагменту моей предыдущей статьи о Kanban :
Минимизация инвентаря (или WIP) является отличительной чертой бережливого мышления, поскольку инвентарь считается ключевым «отходом» любого процесса. Управление большими запасами (или WIP) увеличивает затраты (т.е. складирование, отслеживание, потеря стоимости с течением времени и т. Д.) И скрывает неэффективность процесса. Минимизируя запасы, мы можем уменьшить затраты и привлечь внимание к неэффективности процессов, чтобы их можно было улучшить.
Как вы можете ясно видеть, проблема заключается в управлении
ВЫСОКИМИ СУММАМИ инвентаря. Исходя из этого, мы видим, что проблема заключается в управлении
ВЫСОКИМИ СРЕДСТВАМИ частично выполненной работы. Так в чем же проблемы с частично выполненной работой?
- Частично выполненная работа часто устаревает задолго до ее завершения. Пока программный код не будет выпущен в производство, у вас нет ни малейшего понятия, решает ли он бизнес-проблему. И поскольку деловые проблемы в любом случае являются движущейся целью, вполне вероятно, что вы решите вчерашнюю проблему, а не сегодняшнюю. Или, как однажды сказал мудрец, вы можете достичь вершины лестницы только для того, чтобы прислониться к неправильной стене!
- Частично выполненная работа ВСЕГДА мешает другой работе. Любая работа, которая не была проверена, интегрирована, протестирована и развернута, мешает любым другим усилиям по разработке. Сколько раз к вам приходило срочное задание, и вам приходилось откладывать кучу кода, чтобы вернуться в стабильное состояние? Сколько раз вы боялись регистрировать свой код в конце дня, потому что вы не уверены в том, что у вас есть на рабочем столе? Как долго ты это отпустил? Насколько труднее стало работать, чем дольше вы ждали интеграции? Эти вопросы показывают нам, насколько бесполезной может быть частично выполненная работа.
Так каковы некоторые из проявлений частично выполненной работы? Poppendieck предоставляет нам превосходный список в Реализации Lean Software Development [2]:
- Некодированная документация — требования / особенности / истории / и т. Д. которые задокументированы задолго до кодирования, быстро устаревают, заставляя эту работу повторяться до того, как значение может быть доставлено.
- Несинхронизированный код — код, который долгое время находится на рабочей станции разработчика, делает интеграцию этого кода в общий репозиторий более сложной задачей. То же самое можно сказать и о нескольких ветвях управления источниками, которые живут в течение длительных периодов времени до слияния с основной линией.
- Непроверенный код — Код без соответствующих автоматических тестов является питательной средой для ошибок. Без тестов у вас нет возможности доказать, что ваш код работает немедленно и повторяемо.
- Недокументированный код — Конечно, идеальным является самодокументированный код. Но если у вас должны быть отдельные артефакты документации, они должны разрабатываться параллельно с кодом. В противном случае вы только продлеваете сроки и увеличиваете вероятность ошибок.
- Неразвернутый код — чем дольше вы держите свой код, тем больше времени занимает выяснение того, решает ли он проблемы ваших пользователей и приносит ли вам пользу Кроме того, чем дольше вы ждете развертывания, тем больше ресурсов для новых неиспользуемых функций. Развертывание в режиме «большого взрыва» легко ошеломит ваших пользователей.
Джек Милунски упоминает дополнительное проявление в
своей статье об отходах № 1: закомментированный код. Сколько раз вы видели следующее:
// Save this in case we need it later
/*
Foo foo = new Foo("Foo");
...
foo.save();
*/
Хотя это действительно так, что вам это может понадобиться позже, для его восстановления из системы контроля версий не требуется много усилий. Комментирование «мертвого» кода для последующей реанимации только делает программное обеспечение менее читаемым и обслуживаемым.
Я хотел бы отметить еще одно проявление: скопировать и вставить «повторное использование». Поднимать код из одного класса и дословно переносить его в другой класс — это невероятно плохая форма. Если исходный код был ошибочным, все, что вы сделали, это клонировали ошибку. Скопированный и вставленный код имеет тенденцию воспроизводиться так же, как вирус. Давайте возьмем лучшее и скажем, что код был чистым и правильным. Как только бизнес-логика должна измениться, вы должны запомнить все местоположения и коснуться их всех. Это похоже на хранение инвентаря для дальнейшей обработки.
Обработка, которая почти гарантированно произойдет.
Вот и все для этого эпизода «Семи отходов разработки программного обеспечения». Оставайтесь с нами для следующего выпуска: дополнительные функции.
Список литературы
[1] Оно, Тайити.
Производственная система Toyota: за пределами крупномасштабного производства . Пресса Производительности, 1988.
[2] Poppendieck, Мэри и Том.
Внедрение разработки Lean Software: от концепции до денег . Аддисон-Уэсли, 2006.