В то время как основной целью Scrum является организация и управление проектами, Lean больше занимается оптимизацией процессов для быстрого производства качественных продуктов. Это может быть вашим первым шагом к принятию гибких принципов, или это может быть что-то, к чему ваша команда развивается, когда Scrum недостаточно. Я приглашаю вас прочитать историю моей команды и то, как мы перешли от Scrum к более легкому процессу разработки.
Маленькая история
Lean — это набор принципов, определенных японской автомобильной промышленностью в 1980-х годах. Инженер по качеству Toyota Джон Крафчик придумал этот термин, наблюдая за процессами и инструментами, используемыми для устранения отходов при массовом производстве автомобилей. Лишь в 2003 году Мэри и Том Поппендик представили Lean как процесс разработки программного обеспечения в своей книге Lean Software Development: Agile Toolkit .
В то время как Scrum — это набор правил и ролей, Lean — это набор принципов и концепций с несколькими инструментами. Оба метода считаются гибкими, и они используют одну и ту же идеологию быстрой доставки, уменьшая при этом количество дефектов и ошибок. Я всегда подчеркиваю гибкость Agile, но не могу игнорировать тот факт, что Scrum представляет собой обязательный набор правил. На самом деле, религиозные фанаты Scrum кричали богохульство за несоблюдение правил Scrum.
Lean, с другой стороны, более открыт; его последователи представляют процесс как набор легко адаптируемых рекомендаций.
Это побуждает команду или компанию принимать решения, и она адаптируется к решениям и ежедневным сюрпризам, с которыми сталкиваются ваша команда и компания.
Когда моя команда повзрослела и начала использовать Scrum , мы почувствовали, что некоторые ее аспекты сдерживают нас. Мы стали довольно дисциплинированной и однородной командой. Некоторые встречи нам больше не подходили, и мы начали понимать, что ежедневные встречи были неэффективными. Мы узнали, что проблемы должны решаться быстрее, и мы чувствовали необходимость избегать этих процедур, которые сдерживали нас.
Мы двинулись дальше.
Две основные концепции Lean
Lean раскрывает две основные концепции, но основные идеи: устранение отходов и улучшение рабочего процесса.
Устранение отходов
Если что-то сломается, оно сломается в пятницу.
Все, что стоит на пути производства, — это отходы. Это включает потерянное время, оставшиеся материалы и неиспользованную рабочую силу. Дефекты в конечном продукте являются отходами; это напрасно тратит время на их исправление, тратит деньги на их замену и тратит ресурсы на поиск других решений.
Концепция отходов приятно переводит в мир разработки программного обеспечения. Отходы могут быть описаны поздними поставками, ошибками и программистами, не имеющими ничего общего (не путайте это с «программистам следует программировать восемь часов в день без паузы и YouTube»).
Улучшение потока
Концепция Lean Toyota концентрируется на производственном потоке. На производственном предприятии поток представляет собой цепочку процедур, которые превращают сырье в конечную продукцию. Эти процедуры могут сильно отличаться друг от друга и могут занимать различное количество времени, но каждая из них может быть улучшена, чтобы сделать их более эффективными. Это постоянное сражение, поиск и устранение узких мест в процессе.
Идеальный поток — это такой процесс, при котором каждый этап требует одинакового количества времени и усилий для производства одинакового количества продуктов.
Это не означает, что каждый процесс должен стоить одинаковую сумму денег, но каждый процесс должен быть в состоянии завершить с одинаковой легкостью.
По иронии судьбы, Scrum был инструментом, который в конечном итоге заставил нас осознать потери в нашем проекте. В то время как мы придерживались чистого Scrum в некоторых областях нашего производства, мы начали выявлять ошибки и / или задержки, которых мы могли бы легко избежать, приняв другой подход.
В то время мы мало знали о Лин. Мы прочитали несколько статей на эту тему, но мы поступили неправильно и проигнорировали их, потому что мы были так сосредоточены на нашем процессе Scrum. Мы были почти убеждены, что Скрам был Святым Граалем, но наш «Скрам-пулемет» начал осечку. Нам нужно было открыть наши умы.
Принципы Бережливого производства
Для разработки программного обеспечения принципы Лин были адаптированы в следующие семь.
1 — ликвидировать отходы
Переход от Scrum к Lean на самом деле освобождает.
При разработке программного обеспечения вы можете находить и устранять потери, распознавая вещи, которые необходимо улучшить. В прагматическом смысле все, что не является прямой ценностью для клиента, является тратой. Приведем несколько примеров: пустая трата — это ошибка, комментарий в коде, неиспользуемая (или редко используемая функция), команды, ждущие других команд, принимающие личный вызов … Вы понимаете. Все, что сдерживает вас, вашу команду или ваш продукт, является пустой тратой, и вы должны предпринять соответствующие действия для его удаления.
Я помню, одной из наших проблем была частая необходимость реагировать быстрее, чем два спринта. Развитие спринтов и соблюдение правил Scrum запрещает вам изменять истории, назначенные текущему спринту. Команда должна адаптироваться, когда пользователь находит ошибку и нуждается в исправлении, или когда самый важный клиент хочет функцию, которую можно легко выполнить за два дня. Скрам просто не достаточно гибок в этих случаях.
2 — Усиление обучения
Придайте большое значение образованию.
У вас есть отходы, и вы, естественно, хотите меньше отходов в будущем. Но почему там отходы? Это, скорее всего, исходит от члена команды, который не совсем знает, как подходить к конкретной проблеме. Ничего страшного; никто не знает всего Придайте большое значение образованию.
Определите области, которые нуждаются в наибольшем улучшении (с точки зрения знаний) и начните обучение. Чем больше вы и ваша команда знаете, тем легче сократить отходы.
Например, изучение Test Driven Development (TDD) может уменьшить количество ошибок в вашем коде. Если у вас есть проблемы с интеграцией модулей разных групп, вы можете узнать, что означает Непрерывная интеграция, и реализовать подходящее решение.
Вы также можете узнать из отзывов пользователей; это позволяет вам узнать, как пользователи используют ваш продукт. Часто используемая функция может быть доступна только при навигации по пяти меню. Это признак траты! Вначале вы можете винить в таких отходах программистов и дизайнеров (и, возможно, вы правы), но пользователи склонны использовать ваше программное обеспечение так, как вы никогда не предполагали. Обучение от ваших пользователей помогает устранить этот вид отходов. Это также поможет вам устранить неправильные или неполные требования. Отзывы пользователей могут вести продукт по тем путям, которые вы никогда бы не рассмотрели.
В какой-то момент моя команда определила, что некоторые модули могли бы быть лучше написаны, если бы мы знали больше о домене в начале. Конечно, нет способа повернуть время вспять, и переписать огромный кусок кода нецелесообразно. Мы решили потратить время, чтобы узнать о домене, когда поставили задачу с более сложной функцией. Это может потребовать нескольких часов или даже недель, в зависимости от сложности проблемы.
3 — принять решение как можно позже
Каждое решение имеет цену. Это может быть не сразу и не материально, но стоимость есть. Откладывание решений помогает вам полностью подготовиться к проблемам, с которыми вам нужно столкнуться. Вероятно, наиболее распространенным примером отложенного решения является проектирование базы данных.
Решения не должны быть техническими по своему характеру; общение с клиентами помогает вам принимать решения, которые влияют на подход к вашим продуктам.
Но пользователи не всегда знают, чего хотят. Откладывая принятие решений о функциях до тех пор, пока пользователям действительно не понадобится эта функция, вы получите больше информации о проблеме и сможете предоставить необходимые функции.
Выберите Agile методологию, которая лучше всего подходит для вас и вашей команды.
Четырнадцать лет назад команда приняла решение сохранить конфигурацию приложения в базе данных MySQL. Они приняли это решение в начале проекта, и теперь нынешняя команда (моя команда) несет тяжелую ношу. К счастью, этот продукт больше не находится в активной разработке, но нам все еще приходится время от времени поддерживать его. То, что должно быть простой задачей, становится монументально огромным.
С другой стороны, мы учились на ошибках наших предшественников. Мы принимаем программные, архитектурные и проектные решения как можно позже. На самом деле, мы усвоили этот тяжелый урок, прежде чем принять Lean. Напишите открытый и отделенный код и напишите дизайн, который не зависит от конфигурации и настойчивости. Это, конечно, труднее сделать, но в конечном итоге сэкономит вам много времени в будущем.
Некоторое время назад мы добавили в наш продукт функцию, которая сжимает данные на диске. Мы знали, что это будет полезно, и хотели добавить его в наш продукт как можно быстрее. Мы начали с простой функциональности, избегая решений, касающихся опций и конфигурации, до более позднего времени. Пользователи начали предоставлять отзывы через несколько месяцев, и мы взяли эту информацию, чтобы принять решение о параметрах и конфигурации функции. Мы изменили эту функцию менее чем за день, и ни один пользователь не пожаловался и не запросил дополнительную функциональность. Это было легко изменить; мы написали код, зная, что мы сделаем модификацию в будущем.
4 — Доставить как можно быстрее
Мы живем в постоянно меняющемся мире. Программы, которые мы пишем сегодня, предназначены для компьютеров, которые через два года устареют. Закон Мура остается в силе, и так будет и впредь.
Скорость доставки — все в этом быстро меняющемся мире.
Поставка продукта в течение трех лет ставит вас в тупик, поэтому очень важно как можно скорее порадовать своих клиентов. История доказала, что неполный продукт с приемлемым количеством ошибок лучше, чем ничего. Кроме того, у вас есть бесценные отзывы пользователей.
У нашей компании была мечта: доставить после каждого спринта. Естественно, это нецелесообразно в большинстве случаев. Наши пользователи не хотели обновлять продукт каждую неделю или месяц. Поэтому, пока мы стремимся выпустить каждую версию нашего кода, мы этого не делаем. Мы узнали, что «быстрый» — это то, что воспринимает пользователь, а не то, что мы физически способны сделать. В отрасли нашего продукта быстрое означает регулярные обновления каждые несколько месяцев и исправление критических ошибок в течение нескольких дней. Вот как наши пользователи воспринимают «быстро»; другие виды продуктов и отраслей имеют разные определения «быстро».
5 — Расширение возможностей команды
Программисты раньше были ресурсами, заключенными в ячейки, молча выполняющими свои задачи для своей компании. Это был выдающийся образ программиста в конце 1990-х, но это уже не так.
История показала, что этот подход и традиционное управление проектами водопада не подходят для программного обеспечения.
В какой-то момент это было так плохо, что только около 5% всех программных проектов были реализованы. Бизнесы и продукты на миллион долларов терпели неудачу в 95% случаев, что приводило к огромным потерям.
Лин обнаружил, что немотивированные программисты стали причиной таких потерь. Но почему не хватает мотивации? Ну, программисты и команды разработчиков не были услышаны. Компания ставила задачи и управляла сотрудниками, которые рассматривались только как ресурсы, создающие исходный код.
Lean поощряет менеджеров прислушиваться к программистам и призывает программистов обучать своих менеджеров процессу производства программного обеспечения. Это также побуждает программистов напрямую работать с клиентами и пользователями. Это не означает, что разработчики делают все, но дает им возможность влиять на эволюцию производства. Удивительно, но чувство « Вы знаете эту замечательную функцию, которую любят пользователи? Это была моя идея! », Является большим мотивирующим фактором.
Но не думайте, что это работает только для больших команд; наша команда маленькая. В нашей компании всего несколько разработчиков, поэтому мы всегда были рядом с нашими пользователями. Эти отношения позволили нам влиять на наш продукт сверх того, что изначально могли себе представить наши менеджеры.
6 — Создать целостность
Все, что стоит на пути производства, — это отходы.
Целостность — это надежность вашего продукта и то, как клиенты видят ваш продукт в целом. Целостность — это единообразие, надежность и безопасность пользовательского интерфейса, а также безопасность пользователя при использовании вашего продукта. Целостность — это полное изображение, которое пользователь создает для вашего продукта. Например, целостность пользовательского интерфейса включает в себя внешний вид между страницами, экранами, модулями или даже между пользовательским интерфейсом вашей системы и веб-сайтом компании.
Но целостность также можно наблюдать и практиковать на уровне исходного кода. Целостность может означать, что ваши модули, классы и другие части написаны аналогичным образом. Вы используете одни и те же принципы, шаблоны и методы в своей кодовой базе — даже между разными командами. Целостность означает, что вы должны часто рефакторинг вашего кода. Это непрерывная и бесконечная работа, и вы должны стремиться, но никогда не достигать ее.
Поддержание целостности в нашем исходном коде является сложной задачей. Мы поняли, что найти дублирующийся код — это самое сложное, и под дублированием я не имею в виду пару строк дублирующего кода в одном методе или классе.
Дело даже не в поиске в разных модулях одного и того же кода; речь идет о поиске этих частей общей логики, выделении их в свои собственные классы и использовании их в нескольких местах.
Найти логическое дублирование очень сложно и требует глубоких знаний исходного кода.
Я был в одном проекте больше года, и я все еще удивлен, когда нахожу дублирующий код. Но это хорошая вещь; мы достигли точки, когда мы на самом деле видим эти вещи и принимаем меры к ним. Поскольку мы начали активно удалять дублирующую высокоуровневую логику, качество нашего кода повысилось. Мы на шаг ближе к достижению честности.
7 — увидеть весь
Пользователи не всегда знают, чего хотят.
Когда вы создаете свое приложение, вы должны думать о сторонних компонентах, на которые вы полагаетесь при разработке вашего продукта, а также о других третьих сторонах, с которыми ваш продукт связывается. Ваше приложение должно интегрироваться с дизайном устройства или операционной системы на настольном ПК. Не проще ли использовать приложение, которое интегрируется с системой уведомлений вашего смартфона, а пользовательский интерфейс отражает интерфейс операционной системы?
Да, увидеть все не так просто. Вы должны оторваться от мельчайших деталей и посмотреть на свой продукт издалека. Одним из запоминающихся моментов в разработке нашего продукта было то, что мы поняли, что должны полагаться на то, что другие программисты создают в других проектах. Мы поняли, что ядро системы, запрограммированное другими, является одним из сторонних компонентов, на которые мы полагаемся.
В какой-то момент этот сторонний компонент изменился. Мы могли бы просто применить бинты к нашему приложению, или мы могли бы пойти простым путем и обвинить программистов, которые написали этот компонент. Вместо этого мы взяли проблему за рога и исправили проблему в стороннем ядре. Видеть целое и работать с ним может быть грязно, но это может иметь значение между продуктом и отличным продуктом.
Канбан — отличный инструмент
Есть несколько инструментов и методов, чтобы заставить Lean работать. Я предпочитаю Kanban , инструмент, основанный на плате, который похож на доску планирования Scrum. Представьте себе канбан-доску как двойную воронку.
Слева бесконечный список историй, которые нам нужно рассмотреть. Все законченные истории накапливаются справа, и менеджер или владелец продукта определяет, когда публиковать новый выпуск, основываясь на этом списке.
В середине наш эффективный процесс Канбан. Продукт должен быть стабильным и готовым к выпуску, когда мы закончим рассказ. Это не обязательно означает, что функция выполнена; продукт может иметь несколько частично реализованных функций. Но стабильность, безопасность и надежность продукта должны быть качеством производства.
Больше гибкости с релизами
Мы неплохо справились с нашим текущим спринтом. Это был обычный понедельник, спокойный день с небольшим волнением, но к среде мы начали видеть некоторые проблемы. Это нормально, это происходит постоянно. Однако для преодоления этих трудностей потребовалось дополнительное время. Владелец нашего продукта согласился с нами продолжить работу над текущей функцией и продлить текущий спринт примерно на три или четыре дополнительных дня.
Пятница пришла с сюрпризом. Вы знаете правило: если что-то сломается, оно сломается в пятницу. Важному и потенциальному клиенту требовалась определенная функция перед подписанием контракта с компанией. Мы должны были отреагировать (и быстро!). Новый релиз был обязательным … Но подождите! Мы находимся в середине спринта. Продукт должен быть готов к выпуску к концу спринта. Что мы делаем? Scrum сказал бы сделать новую функцию в следующем спринте, но мы уже опаздываем с текущим спринтом! Это был момент, когда мы начали понимать, что мы должны думать меньше, чем индивидуальный спринт. Мы должны быть в состоянии адаптироваться быстрее и выпускать быстрее, если это необходимо.
Канбан Правление
Доска Канбан выглядит очень похоже на доску планирования Scrum, но с некоторыми дополнениями, чтобы лучше приспособиться к процессу Lean.
Первый столбец слева — это полное отставание: все, что нам нужно сделать в какой-то момент. Справа у вас есть другая воронка, содержащая все законченные (но не выпущенные) истории.
В середине наш процесс. Эти столбцы могут отличаться в зависимости от каждой команды и процесса. Обычно рекомендуется иметь по крайней мере один столбец для следующих нескольких задач и другой столбец для историй, которые в настоящее время находятся в разработке. Изображение выше демонстрирует еще несколько столбцов, чтобы лучше представить процесс разработки.
В столбце To-Do перечислены задачи, которые нам нужно выполнить. Затем у нас есть Дизайн , где разработчики работают над созданием текущих историй. Четвертый столбец — Разработка , собственно кодирование. Наконец, в столбце « Тестирование» перечислены задачи, ожидающие рассмотрения другим партнером по команде.
Ограничить работу в процессе
Никто не знает всего.
Если вы сравните эту доску Канбан с доской для планирования схваток, вы сразу заметите очевидные различия. Во-первых, у каждого столбца есть номер, представляющий максимальное количество историй, которые могут находиться в этом столбце. У нас четыре задачи, четыре в разработке, три в разработке и две в тестировании. Отставание и завершенные задачи не имеют такого ограничения.
Значение каждого столбца должно быть определено командой. На изображении выше я присвоил столбцам произвольные числа; ваши цифры могут значительно отличаться. Кроме того, цифры не являются окончательными. Адаптируйте числа при выявлении и устранении узких мест.
Динамически распределять ресурсы
Одним из самых удивительных качеств Kanban и Lean является важность сотрудничества и перераспределения усилий. Как вы видите на доске, каждый столбец нашего процесса содержит карточки с людьми на них. На примерной доске восемь разработчиков — довольно большая команда! Доска всегда представляет текущий статус того, кто чем занимается в данный момент.
Согласно нашей коллегии, над дизайном работают три человека, две пары занимаются разработкой и одно тестирование разработчика. Истории переходят к следующему столбцу, и работа в текущем столбце завершена, и в зависимости от типа разработки и организации команды один и тот же разработчик может продолжать работать над той же историей, что и в процессе.
Давайте предположим, что у нас есть специализированные люди. Таким образом, основная функция трех дизайнеров — это дизайн, четыре разработчика пишут код, а одинокий тестер в основном тестирует продукт / функцию. Если дизайнер заканчивает историю, она переходит к разработке, а другая история из списка дел включается в дизайн.
Это нормальный процесс. История была перенесена из дизайна в разработку, и теперь разработка в максимуме. Но что, если другой дизайнер заканчивает другую историю? Это дает команде разработчиков четыре истории — нежелательная ситуация.
Лин хочет избежать заторов. Запрещается перемещать историю в следующий столбец, если он превышает максимум столбца. В этом случае ресурсы должны быть перераспределены; дизайнер, который закончил свою задачу, должен выбрать, что делать дальше. Его первый вариант — вытащить еще одно задание из столбца дел, но он не может этого сделать, потому что ему нужно передать недавно завершенное задание команде разработчиков (что он не может сделать). Его единственный вариант — начать работать над историей развития. Возможно, он не лучший разработчик, но его усилия помогут поддерживать процесс.
Если тестер заканчивает последний рассказ в своей колонке, он может помочь дизайнеру в его задаче разработки.
Это круто! Команда может реорганизоваться на лету! Вы видите отходы? Вы видите узкое место в потоке? Принять немедленные меры!
Как только история в колонке разработки завершена, тестер возвращается к тестированию, дизайнер — к разработке, а разработчики — к истории, над которой работал дизайнер и тестер. Но имейте в виду, что вам не нужно следовать этому точному рецепту; разработчик может начать проектирование, когда дизайнер и тестировщик закончили разработку своей истории. Тебе решать!
Наша доска теперь вернулась к нормальной жизни.
Добро пожаловать Scrum-Ban
Запрещается перемещать историю в следующий столбец, если он превышает максимум столбца.
Я с ностальгией наблюдал, как наш мастер схватки разобрал нашу доску . Кусочек за кусочком он сорвал нашу любимую доску, которая затем превратилась в гору мятой бумаги.
В комнату вошел еще один коллега с несколькими огромными листами свежей белой бумаги в руках. Наш совет должен был переродиться во что-то другое, более подходящее для наших нужд. После того, как бумажные листы оказались на стене, мы начали специальную встречу, чтобы определить столбцы, необходимые для определения нашего процесса. Затем мы обсудили количество историй, которые должны быть в каждом столбце. После того, как все было тщательно расписано и расположено на стене, мы испытали это странное чувство … печаль о старом, но счастье о новом.
Мы сделали то, что многие люди называют Scrum-Ban . Мы сохранили некоторые концепции Scrum, такие как Scrum Master и владелец продукта, и мы все еще оцениваем и оцениваем истории. Но теперь мы сосредоточены на Lean и Kanban, сохранении потока, обнаружении и устранении отходов и узких мест.
Переход от Scrum к Lean на самом деле освобождает. Члены команды стали намного дружнее, и мы поняли, что должны предложить помощь, как только в нашей колонке ничего не будет. Это чувство, что разработчики имеют значение, заставило нас задуматься о проекте в целом; Мы заботимся о проекте больше, чем когда-либо прежде.
Последние мысли
Lean не всегда считался Agile. Даже сегодня некоторые Agilists отказываются признать это как Agile методологию. Но все больше и больше программисты принимают Lean как одну из самых совершенных методологий Agile.
Как отметил один из моих мудрых коллег, Лин и Канбан позволяют вам самостоятельно следовать этой методологии. Так что, если вы одинокий разработчик и вам нужны инструменты, чтобы сделать вашу жизнь проще, попробуйте некоторые бесплатные инструменты Kanban.
На веб- сайте AgileZen имеется бесплатная учетная запись, позволяющая отслеживать один проект.
Я обнаружил, что это один из лучших бесплатных онлайн инструментов Kanban; Я даже использую его каждый день для отслеживания и планирования прогресса статей и курсов, которые я предоставляю для Tuts +. Конечно, вы всегда можете обновить свою учетную запись AgileZen, если вам нужно отслеживать больше проектов.
В этой статье мы рассмотрели Lean и Kanban как эволюцию Scrum. Значит ли это, что Lean лучше, чем Scrum? Точно нет! Это зависит от проектов и людей, с которыми вы работаете. Как всегда, выберите Agile методологию, которая лучше всего подходит для вас и вашей команды.