Каждый разработчик, который слышал о движении Lean, знает, что существует семь принципов Lean, которые можно использовать в качестве основы для этого подхода в любой отрасли — от производства до разработки программного обеспечения. Однако принципы часто слишком универсальны, чтобы их можно было легко применять: книга Lean Software Development предоставляет инструменты мышления, которые реализуют все принципы в нашей области деятельности.
Первый принцип называется « Устранить отходы» : вмешаться, чтобы удалить из процесса все, что не добавляет ценности конечному продукту. Сколько раз мы составляли проект документа или презентации только потому, что было принято писать его для каждого проекта?
Сегодня мы увидим первый из инструментов для устранения отходов, который называется « Видя отходы» .
Семь Пустошей
Мэри Поппендик определяет Семь отходов разработки программного обеспечения как категории работ, которые не являются частью анализа или кодирования и не обеспечивают ценность для вашего клиента, который может быть пользователем продукта менеджера, который решает продажи в других компаниях. ,
Частично выполненная работа
Также называемый WIP (работа в процессе), эти отходы идентифицируются со всеми частично разработанными функциями или историями. Примерами WIP являются функции, которые:
- полностью указан в большом документе, но еще не разработан.
- Зарегистрирован, но еще не проверен.
- Модуль протестирован, но еще не интегрирован с остальной частью системы.
- Интегрированный, но еще не выпущенный или развернутый, где клиент может использовать его.
Эти функции находятся в подвешенном состоянии и не будут представлять никакой ценности для клиента, пока они не достигнут его. Тем временем мы оплачиваем бремя большей кодовой базы и принимаем на себя риск того, что за время, необходимое для завершения функции, цели пользователя изменятся, что сделает часть наших усилий бесполезной. Вы не будете доставлять заявку на покупки в Черную пятницу в декабре; кривая полезности других функций обычно не столь резкая, но чем больше смещено в будущее, тем меньше его текущая стоимость.
Дополнительные процессы
По крайней мере, в сфере налогов и контрактов каждый из нас сталкивался с такой формой бумажной работы, которая не обеспечивает ценность. Существуют особые требования, такие как соответствие стандарту, который требует этих процессов (в противном случае продажа копии программного обеспечения может быть незаконной или невозможной), но мы должны делать снимок на каждом этапе разработки, который выполняется по привычке, а не из нужно.
Дополнительные функции
В соответствии с гибкими процессами бережливый подход говорит нам оставаться в соответствии с тем, что требуется для реализации истории, а не добавлять какие-либо дополнительные функции. Из-за более низкой стоимости транзакции заманчиво добавить что-то большее, чем требуется сейчас: в случае, если нас попросят, нам не придется переделывать тот же код через два дня. Однако часто бывает так, что нам будет предложено внести другое изменение, сделав то, что мы сделали устаревшим, или что функция будет работать как есть, без каких-либо улучшений: тем временем мы оплатим затраты нашего потраченного времени на реализацию дополнительных и большей кодовой базы для поддержки.
Переключение задач
Каждый раз, когда мы переключаемся между действиями, приходится платить за настройку, чтобы освоить новую. Это верно как в производстве, так и в сфере знаний: нам нужно сосредоточиться на нашей новой задаче, открыть необходимые инструменты и найти нужные файлы. Это похоже на разогрев кеша разума, который изначально полон несвязанных знаний.
Ожидание
Программное обеспечение, испытывающее проблемы с производительностью, часто содержит множество потоков, которые блокируются в ожидании доступности какого-либо ресурса или завершения какой-либо операции (подумайте о вызовах базы данных и сети). То же самое относится и к процессу разработки программного обеспечения: если мы ждем пару дней каждый раз, когда задаем вопрос внешнему человеку, мы будем тратить много времени на ожидание — хотя, если бы этот человек находился в одной комнате с нами, мы могли бы наслаждайтесь более быстрой обратной связью.
движение
Люди и предметы перемещаются во время проекта — но, как и в сетях, чем больше вы перемещаете, тем больше вы замедляетесь. Документ с требованиями, который перемещается между заказчиком и разработчиком несколько раз, является пустой тратой не только на время ожидания, которое он производит, но также и в том смысле, что часть молчаливых знаний, окружающих документ, теряется. Предположим, я разговариваю с клиентом и составляю документ со списком всего, что ему нужно; Я даю вам документ и больше никогда не участвую в разработке. Не хотите ли вы поговорить с клиентом напрямую?
дефекты
Каждая ошибка, которая попадает к конечному пользователю, является пустой тратой: не только пользователь теряет свое собственное время, но и отслеживание ошибок означает, что нужно создавать новые заявки, мы должны найти, какая часть кода вызывает проблему, и новая релиз должен быть создан. В то же время очень легко исправить ошибку, если вы обнаружите ее за несколько минут: она может быть введена только кодом, над которым вы работаете; таким образом, мы можем думать о дефектах как об отходах, которые растут со временем, пока они остаются в коде без исправления.
Примеры проектов
Поскольку я часто использую проекты с открытым исходным кодом в качестве тестового стенда для новых методов, я попытался собрать примеры отходов в своем проекте PHPUnit_Selenium, библиотеке для тестирования на основе браузера из кода PHP.
- Частично выполненная работа . Я стараюсь максимально сократить время выполнения функции, выпуская максимум каждые 2 или 3 недели. Само программное обеспечение всегда доступно для повторного использования, и, к счастью, благодаря PEAR пользователям очень просто обновить свою копию с помощью одной команды.
- Дополнительные процессы : выпуск означает также компиляцию файла package.xml, в котором просто перечислены все файлы, содержащиеся в папке. В настоящее время не существует простого решения для восстановления этого файла, и уже был случай, когда файл отсутствовал в списке, вызывая разрыв. Теперь у меня есть автоматическая проверка, но мне интересно, может ли это обновление быть проще.
- Переключение задач : даже когда мне нужно исправить одну однострочную ошибку, для начала работы над кодом потребовалось несколько задач:
java -jar selenium-server.jar cd code/phpunit-selenium/selenium-1-tests python -m ...
which means I have to start a Selenium Server, and a local HTTP server to access some static pages. Continuous Integration opened up my eyes on this, and now I have a single script to start all of that. I did not eliminate task switching, which would be preferrable, but at least I am containing its cost.
- Motion and Waiting: fortunately, an open source project of a small scale does not have these problems. There is a case that is always present however: conversations on bug trackers. My standard response in case of a difficult to interpret ticket is something like:
Please include a test subclassing Selenium[2]TestCase that fails while exposing this bug; does this affect only a particular version?
because I am trying to minimize the number of answers I need from a user. Posting on a web page is not a phone conversation, and each response may take a day to arrive.