Я разработчик, который увлечен потоком доставки в системах управления проектами. Я много думал об этом и читал такие книги, как Agile Management for Software Engineering , Искусство гибкой разработки , Slack и мой личный фаворит, проект Phoenix .
Проект «Феникс» действительно открыл мне глаза на многие недостатки, с которыми мы сталкиваемся. Мне также очень повезло, что у меня была возможность не просто изучать различные методы доставки, но и практиковать их, управляя группами доставки.
В этой статье я решил объединить два моих увлечения: разработка программного обеспечения и процесс доставки.
Фактически, я закончил создание базового симулятора пропускной способности!
Что вы собираетесь изучать
- Восемь основных недостатков, которые увеличивают время ожидания
- Как на практике работают следующие потоки доставки:
- Водопад
- Scrum
- Kanban
- Почему все должны расслабиться и немного расслабиться
- Почему время ожидания является корнем зла, когда дело доходит до эффективности
- Что речь идет о команде, а не о человеке, когда дело доходит до доставки программного обеспечения
8 отходов в разработке программного обеспечения
Прежде чем мы начнем, важно, чтобы вы понимали различные виды отходов в разработке программного обеспечения.
Этот список не является исчерпывающим, и я уверен, что кто-то может написать книгу на эту тему, которая занимает сотни страниц. Но этот список даст вам основные модели, которые вы должны рассмотреть.
1. Транспорт
Эти недостатки возникают, когда вы перемещаете артефакты. Возможно, вы отправляете код в несколько филиалов или проходите регистрацию.
2. Инвентаризация
Это когда произведенные артефакты не используются.
Артефакты, такие как:
- Требования
- Архитектурные проекты
- Графика и каркасы
- Доказательство-из-концепция
- Код
… производятся за недели или месяцы. В тот момент, когда создается артефакт, он устарел и нуждается в изменении.
3. Движение
Эти недостатки возникают при создании артефактов.
Большинству разработчиков необходимо совмещать много задач одновременно. За переключение контекста и многозадачность приходится платить.
Может быть, вам нужно отслеживать различные версии программного обеспечения, проекты и дорожные карты. Или люди постоянно звонят тебе или приезжают, чтобы увидеть тебя о чем-то.
Вам нужно подобрать работу, которой вы не занимались в течение нескольких дней, месяцев или лет, и вам нужно заново изучить то, что вы уже сделали.
4. Ожидание
Вы ждете, чтобы ваша регистрация прошла. Или вы ждете появления артефактов.
Ваша ИТ-инфраструктура ненадежна, ваш компьютер перестает работать, интернет отключается или почтовый сервер не работает.
Ваши тестеры в команде становятся бэк-эндами. Они ждут работы в течение нескольких дней, и получают ее прямо в конце итерации.
Вы обнаружили, что неправильно поняли требование — теперь есть еще много работы.
Или, может быть, вы ждете, чтобы кто-то просмотрел ваш код.
5. Перепроизводство
Вы создали свое программное обеспечение, но не отправляете его. Он сидит на полке, и никто не покупает его. Произведенная вами работа больше не нужна.
6. Переработка
Это происходит, когда вы создаете артефакты, которые не были запрошены.
Вы совершенствуете свой код и добавляете дополнительные точки расширения для тех удивительных функций, которые будут созданы в будущем.
Вы на самом деле работаете над тем, что никто не просил, и вы делаете это, потому что это «круто».
7. Дефекты
Это происходит, когда ваши артефакты содержат ошибки.
То, что вы произвели, не соответствует согласованным критериям приемлемости. Или, может быть, то, что не соответствует техническим стандартам (производительность, безопасность, ремонтопригодность).
8. Навыки
Это происходит, когда производитель артефактов используется недостаточно.
Возможно, вы не получили адекватной подготовки для выполнения реальной работы. Или вы можете сделать гораздо более сложную работу … но она вам не дается.
Что такое слабина?
Да, это приложение для обмена сообщениями, но в данном случае я говорю о влиятельной книге под названием « Slack: Get Past Burnout, Busywork и Myth of Total Efficiency» . Длина 209 страниц — я не собираюсь делать это справедливость, но вот резюме:
Чтобы ваши команды были более счастливыми, менее изнуренными, более инновационными и чтобы ваша организация лучше реагировала на изменения, вы должны добавить «свободное время» к процессу доставки.
Когда вы планируете свою итерацию, вы просто добавляете 10%, 20% или любой процент времени, который вы выбираете для инноваций.
Наше моделирование собирается проверить эту теорию и посмотреть, улучшит ли она скорость доставки.
Симуляция
Я создал набор симуляций для трех методологий управления проектами. Вы увидите их ниже, а также диаграмму, которая будет сравнивать пропускную способность каждого подхода доставки.
правила
Эта симуляция была упрощена для моей и вашей пользы. Мяч в очереди может либо двигаться вперед, либо просто оставаться на месте (пропустить поворот). Мяч в очереди не может двигаться вперед, если перед ним находится мяч. Если очередь заполнена, новый шар не будет добавлен к нему.
Насколько эти правила актуальны?
Вы можете подумать: почему мяч просто остается на одном месте, почему он пропускает поворот? Ну, я пытался смоделировать реальный мир.
Помните восемь отходов? Все они вызывают время ожидания, и поэтому мяч может пропустить поворот.
Но это означает, что все шары позади него не могут двигаться вперед. Они заблокированы. Когда мяч заблокирован, он будет мигать.
В реальном мире все также беспорядочно и немного случайно. Я добавил несколько случайных блоков ко всем потокам доставки, чтобы сделать вещи более реалистичными.
Например, Kanban должен, теоретически, работать потрясающе, поскольку он минимизирует многие из 8 отходов — но мы люди, мы делаем ошибки, и приоритеты клиентов меняются.
Давайте смоделируем некоторые подходы доставки!
Водопад
Это последовательный пакетный подход. Одна команда определенной дисциплины выполняет некоторую работу и передает ее следующей дисциплине, и так далее, пока вы не отправите.
Обычно обратной связи очень мало, а когда есть обратная связь, это очень поздно.
Люди занимаются массовой работой и передают ее по цепочке.
Однако, очень часто эта работа возвращается к первоначальному автору, прежде чем снова идти по цепочке.
Регулярное моделирование
Моделирование с провисанием
Kanban
Это единый подход потока частей. Междисциплинарные или составные команды работают над чем-то, и немедленно выпускают это.
Обратная связь незамедлительна, и работа добавляется и удаляется специальным образом.
Регулярное моделирование
Моделирование с провисанием
Scrum
Скрам — это параллельный пакетный процесс. Кросс-дисциплинарные команды работают над проблемой одновременно, а затем отправляют свое программное обеспечение.
Команды проводят ретроспективные встречи, планируют встречи, ухаживают и т. Д. Время выделяется на подготовку и улучшение.
Регулярное моделирование
Сравнение скорости доставки
На этой диаграмме показано количество шариков, доставленных по каждому подходу доставки после 10 000 итераций.
Что мы можем извлечь из этого моделирования?
1. Нам нужно расслабиться и немного расслабиться.
В любой системе, где есть случайность, мы должны учитывать некоторую слабость.
Чем больше случайности в системе, тем больше слабости вам нужно добавить.
Добавляя время, вы уменьшаете случайность, что уменьшает блокировки, что уменьшает время выполнения заказа. Нехватка времени позволяет вам лучше справляться с вещами. Однако вы платите за это — со временем.
Но идея в том, что со временем это даст вам гораздо больше времени назад. Люди совершают меньше ошибок, проводят более качественные дискуссии, чувствуют себя счастливее на работе, лучше делятся знаниями, делают меньше переделок и не так часто уходят.
Но все же намного лучше иметь хороший, сильный процесс, в котором случайность устраняется в максимально возможной степени, а также учитывается некоторая слабость.
2. Нам нужно сократить время ожидания, чтобы увеличить скорость доставки.
(Delivery Rate) - (Wait Time In The System) = Actual Delivery Rate
Это уравнение звучит до боли очевидно.
Но посмотри вокруг. В вашей организации все настроено так, чтобы сократить время ожидания? Ответ, вероятно, будет: нет.
Как сократить время ожидания? Вот несколько советов:
- Имейте меньше проектов, продолжающихся одновременно.
- Убедитесь, что команды доставки небольшие. Большие команды нуждаются в большем общении и большем управлении, а это чистые отходы.
- Убедитесь, что объем доставки очень ясен, используя критерии INVEST .
- Доставить точно в срок.
- Поставь только-достаточно.
- Дайте людям время, чтобы сделать реальную работу. Сократите количество встреч и общих перерывов.
- Разбейте работу на очень маленькие кусочки, чтобы люди чувствовали и видели прогресс.
- Разбейте работу на очень маленькие куски, чтобы их было легче оценить и спланировать.
- Дайте людям больше времени, чтобы сделать что-то, чем они просят. В худшем случае это займет больше времени, потому что что-то появилось (они обнаружили больше работы, были прерваны и т. Д.). В лучшем случае они действительно доставят рано и будут чувствовать себя мотивированными, чтобы перейти к следующему пункту.
Этот список не является интуитивно понятным. Такое чувство, что мы должны поступить наоборот, поскольку мы живем в обществе, где люди думают, что, оказывая огромное давление на людей, снижая их оценку, они могут выполнять более быструю и качественную работу.
Я обвиняю книги самопомощи в неправильном понимании закона Паркинсона: «работа расширяется, чтобы заполнить время, доступное для ее завершения».
Это предложение не является научным «законом», не было доказано доказательствами и было вырвано из контекста . Люди также часто забывают, что быть эффективным гораздо важнее, чем просто быть эффективным. Людям нужно время, чтобы подумать в позитивной обстановке, чтобы они могли быть эффективными.
3. Все дело в команде, а не в личности.
Важная концепция, которую нужно помнить: когда вы находитесь в системе, речь идет не о вашей индивидуальной скорости доставки. Речь идет о скорости доставки всей системы. Позволь мне объяснить.
Вы можете быть очень эффективным человеком. Вы можете работать вокруг времени ожидания, как вы работаете сверхурочно, потому что вы действительно любите свою работу.
Допустим, вы программист, и вы делаете это.
Если вы не получаете требования от бизнес-аналитиков достаточно быстро, вы можете угадать, что вам нужно делать дальше. Поскольку вы пишете код практически вслепую, вы создаете инвентарь, дефекты, и вы почти наверняка перепроизводите.
Вы можете реорганизовать некоторый код, потому что он не так хорош. Он некоторое время сидел на полке, и вы еще не отправили его, но вам просто не нравится, как он выглядит. В этом случае вы, скорее всего, перерабатываете и создаете отходы.
Представьте, что вы являетесь разработчиком бэк-энда, а интерфейс еще не готов.
Угадай, что будет? Вы начнете работать над какой-то другой функцией, когда разработчик внешнего интерфейса завершит свою работу.
Это означает, что вы сейчас работаете над двумя функциями. Что, если парень заболел? Теперь вы работаете над тремя, четырьмя, пятью функциями.
В то же время в организации не было добавлено никакой реальной ценности. Почему? Потому что ничего не было отправлено, и никто не использует то, что вы написали.
Вы просто создаете инвентарь и ничего не изучаете, так как не получаете отзывов от своих клиентов.
Хотите верьте, хотите нет, но будучи очень эффективным сотрудником и работая не над тем, вы можете нанести больше вреда, чем пользы.
Если вы действительно хотите много работать, это нормально! Рефакторинг отправлен, но с ошибками в коде, улучшит качество обслуживания (производительность, безопасность и т. Д.), Соединится с младшим инженером, улучшит внутренние процессы или вместо этого проведет некоторое исследование.
Когда вы находитесь в системе, вы только сильны, как самое слабое звено в системе.
Так что исправьте самое слабое звено системы и наслаждайтесь лучшей скоростью доставки.
Вот тут и вступает в силу теория ограничений (ToC), прочитайте мою статью о ToC здесь .
Вывод
Чем больше случайностей в системе, тем больше слабости необходимо учитывать для повышения скорости доставки.
Найдите узкое место и сделайте все возможное, чтобы сократить время ожидания, чтобы улучшить общую скорость доставки (это то, чему учит нас теория ограничений).
Запомните восемь отходов и безжалостно удалите их из своих процессов.
Если вам интересно посмотреть, как работают эти симуляции, или вы хотите адаптировать их для создания ваших собственных симуляций, вы можете найти код на GitHub .