Поход
Главный герой (Эл) ведет в поход школьников — класс своего сына. Задача — дойти до Чертова ущелья засветло, переночевать там и, на следующий день, вернуться обратно. Детишки выстраиваются в шеренгу по одному и отправляются в путь. Первым идет Эл, остальные — как придется. Строй растягивается и главному герою приходится перебраться в конец чтобы никто не потерялся. Тогда главный герой перестает видеть голову строя, что тоже его беспокоит. Он пытается сообразить как так получается и первое что видит главный герой — толстый мальчик, которому идти тяжелее чем другим. После небольшого привала и перепалки ребятишек из-за задержки, они снова отправляются в путь и поведение толстячка изменяется — теперь он не отстает от впереди идущего т.к., вероятно, ему стало стыдно, что он задерживает всех. Теперь при накоплении отставания от впереди идущего, он переходит на бег. Теперь толстячок тратит сил больше чем другие — надолго ли его хватит?
Если хоть кто-то промедлил (запнулся, почесался, поправил лямки рюкзака), то строй растягивается, а чтобы сократить строй — КАЖДЫЙ должен сократить расстояние с впереди идущим, недостаточно только одному сократить расстояние до ближайшего товарища.
Эл решает поставить ведущим самого медленного, чтобы строй не растягивался. Это работает, хотя и вызывает недовольство самых быстрых, которым приходится плестись со скоростью, совершенно не соответствующей их возможностям. Все остальные могут идут со скоростью выше скорости толстячка, поэтому строй всегда остается сжатым.
Если продолжать идти со скоростью самого медленного, то засветло к Чертовому ущелью точно не успеть. Но что тут можно поделать? Команда не бросает своих участников.
Озарение! Может толстячку можно помочь? Эй, толстячок, что у тебя в рюкзаке? Сковородка, 4 бутылка газировки, 3 банки тушенки, пакет мармеладных мишек, 2 пакета гречки. А давай-ка распределим содержимое твоего рюкзака на других. Ну вот, теперь мы идем те так быстро как могли бы идти самые быстрые, но уже совсем не медленно.
Понятия
Дойти до Чертова ущелья
Так описывается цель группы. Постановка цели это способ заставить группу идти в одном направлении и, мало того, совместно искать способы ускорения. Представьте с какой скоростью двигался бы строй и как сильно он бы растягивался если бы у группы не было цели или она была бы сформулирована слишком расплывчато или не была бы сформулирована вовсе.
Шеренга по одному
Разработка часто выстраивается в виде зависимых событий: сбор требований, проектирование, разработка, тестирование и затем релиз. Пока не собраны требования, нельзя приступить к проектированию и т.д. Замыкающий в строе не может оказаться впереди головы.
Строй растягивается
Каждое промедление любого участника может вызвать увеличение сроков, а вот ускорение любого участника уже не даёт уменьшения сроков разработки. Если сбор требований задержался на месяц, то тестировщики не смогут уже нивелировать это время — разве что решат выпустить непроверенный продукт.
Переход на бег
Это одно из очевидных решений. Тестировщик должен работать по 12 часов в день. Тогда он сможет на 50% быстрее проверить продукт. Да, некоторые руководители действительно так думают.
Поставить ведущим самого медленного
В итоге срок релиза определяется самым медленным звеном разработки. Как быстро бы не работали разработчики и тестировщики, если требования собираются пол года, то быстрее чем за пол года релиз не выпустить.
Толстячку можно помочь
В каждой конкретной задержке можно увидеть конкретные проблемы и риски и повлиять на них. Да, толстячку действительно можно помочь. Для этого группа должна быть внимательна к проблемам друг друга и постоянно отслеживать состояние работ каждого в каждый момент времени.
Зависимые события и статистические флуктуации
Вы уже должны были понять, что зависимых событий полно в жизни каждого из нас. Осталось понять, что статистические флуктуации (поправить лямки рюкзака, почесаться, запнуться) всегда работают на увеличение сроков, а не на сокращение. Кому-то может показаться, что статистические флуктуации в итоге должны нивелировать друг друга, но этого, к сожалению, не происходит. Статистические флуктуации всегда работают против нас.
Попробуйте поиграть в игру. Берете коробок спичек и своих друзей. Чем больше будет друзей, тем показательней будет результат. Первый кидает кубик и вытаскивает столько спичек из коробка, сколько выпало на кубике и передает их второму. От второго до предпоследнего все также в свою очередь кидают кубик и перекладывают столько спичек, сколько выпало на кубике, из своей кучки в кучку следующего. Последний делает тоже самое только вместо передачи спичек следующему — отправляет их в релиз. Среднее значение, выпадающее на кубике, равно 3,5. Если статистические флуктуации в итоге выйдут в ноль, то для того чтобы отправить в релиз 100 спичек, понадобится 29 ходов.
Если кто-то попробовал поиграть в эту игру — напишите, пожалуйста, за сколько ходов какое количество спичек удалось отправить в релиз.
Способы решения описанной проблемы
Самый плохой вариант, который истощает человека — переход на бег. Его я обычно не рассматриваю т.к. считаю пагубным в стратегической перспективе.
Помочь толстячку — считаю хорошим вариантом. Но как разработчик или тетсировщик может помочь бизнес аналитику собрать требования или системному аналитику формализовать их и выработать проектное решение? В какой-то мере такая проблема решается с помощью кросс-функциональных команд, где каждый человек обладает более чем одной компетенцией. Коллеги, в таком случае, могут помогать друг другу.
Но самый перспективный, на мой взгляд, способ — это совмещение взаимопомощи в кросс-функциональных командах с распараллеливанием работ.
Первый способ распараллеливания — начинать тестирование одновременно с разработкой:
- Написание тест планов.
- Автоматизация функциональных тестов. Если говорить о тестах серверного API, то для их написания необходимо определить интерфейсы и желаемое поведение, как только это сделано, сразу могут быть написаны тесты. Если говорить об автоматизированном тестировании пользовательского интерфейса, то первым делом требуется разработать соглашения по именованию идентификаторов объектов, к которым будут обращаться тесты, как только сделано это, а также определен состав экранов, можно сразу писать UI тесты.
- Составление критериев приемки задач.
Второй способ распараллеливания — дробить работу на более мелкие части:
- Не нужно пол года собирать требования. Нужно собрать минимум требований, для одного маленького кусочка, и передать требования в разработку. Это позволит уже через пару недель запустить разработку и тестирование и сократить срок релиза практически на всё время сбора требований.
- Даже если мы пока не можем распараллелить разработку и тестирование, тестировщикам не придется ждать долго, когда будет готов тестируемый функционал, ведь это совсем маленький блок конечного продукта.
Но есть еще один очень важный инструмент, который незаметно но существенно (это не парадокс!) влияет на статистические флуктуации. Это цель! Цель, если она принята каждым человеком группы, сокращает вероятность появления задержек и, мало того, создает стремление сокращать промежуток между зависимыми событиями. Ты, как человек, заинтересованный в достижении цели, будешь стремиться устранить препятствия, которые стоят как на твоём пути так и на пути твоих коллег. А если так будет делать каждый в группе, то препятствий станет гораздо меньше, риски будут прорабатываться заранее, никто не окажется один на один с неподъемной проблемой.
Заключение
Информацию о зависимых событиях и статистических флуктуациях взял из книги “Цель: процесс непрерывного совершенствования” Элияху Голдратта. Пример с походом к Чертовому ущелью и игрой со спичками взял оттуда же.
Из моего в данной статье — проекция на разработку.
Цель данной статьи — во-первых, рассказать об интересном феномене и, во-вторых, показать принципиальную сложность ускорения разработки по “водопаду”.
