08.12.2017 05:19
vryashentsev 11 2200 Источник

Поход


Главный герой (Эл) ведет в поход школьников — класс своего сына. Задача — дойти до Чертова ущелья засветло, переночевать там и, на следующий день, вернуться обратно. Детишки выстраиваются в шеренгу по одному и отправляются в путь. Первым идет Эл, остальные — как придется. Строй растягивается и главному герою приходится перебраться в конец чтобы никто не потерялся. Тогда главный герой перестает видеть голову строя, что тоже его беспокоит. Он пытается сообразить как так получается и первое что видит главный герой — толстый мальчик, которому идти тяжелее чем другим. После небольшого привала и перепалки ребятишек из-за задержки, они снова отправляются в путь и поведение толстячка изменяется — теперь он не отстает от впереди идущего т.к., вероятно, ему стало стыдно, что он задерживает всех. Теперь при накоплении отставания от впереди идущего, он переходит на бег. Теперь толстячок тратит сил больше чем другие — надолго ли его хватит?

Если хоть кто-то промедлил (запнулся, почесался, поправил лямки рюкзака), то строй растягивается, а чтобы сократить строй — КАЖДЫЙ должен сократить расстояние с впереди идущим, недостаточно только одному сократить расстояние до ближайшего товарища.

Эл решает поставить ведущим самого медленного, чтобы строй не растягивался. Это работает, хотя и вызывает недовольство самых быстрых, которым приходится плестись со скоростью, совершенно не соответствующей их возможностям. Все остальные могут идут со скоростью выше скорости толстячка, поэтому строй всегда остается сжатым.

Если продолжать идти со скоростью самого медленного, то засветло к Чертовому ущелью точно не успеть. Но что тут можно поделать? Команда не бросает своих участников.

Озарение! Может толстячку можно помочь? Эй, толстячок, что у тебя в рюкзаке? Сковородка, 4 бутылка газировки, 3 банки тушенки, пакет мармеладных мишек, 2 пакета гречки. А давай-ка распределим содержимое твоего рюкзака на других. Ну вот, теперь мы идем те так быстро как могли бы идти самые быстрые, но уже совсем не медленно.

Понятия


Дойти до Чертова ущелья


Так описывается цель группы. Постановка цели это способ заставить группу идти в одном направлении и, мало того, совместно искать способы ускорения. Представьте с какой скоростью двигался бы строй и как сильно он бы растягивался если бы у группы не было цели или она была бы сформулирована слишком расплывчато или не была бы сформулирована вовсе.

Шеренга по одному


Разработка часто выстраивается в виде зависимых событий: сбор требований, проектирование, разработка, тестирование и затем релиз. Пока не собраны требования, нельзя приступить к проектированию и т.д. Замыкающий в строе не может оказаться впереди головы.

Строй растягивается


Каждое промедление любого участника может вызвать увеличение сроков, а вот ускорение любого участника уже не даёт уменьшения сроков разработки. Если сбор требований задержался на месяц, то тестировщики не смогут уже нивелировать это время — разве что решат выпустить непроверенный продукт.

Переход на бег


Это одно из очевидных решений. Тестировщик должен работать по 12 часов в день. Тогда он сможет на 50% быстрее проверить продукт. Да, некоторые руководители действительно так думают.

Поставить ведущим самого медленного


В итоге срок релиза определяется самым медленным звеном разработки. Как быстро бы не работали разработчики и тестировщики, если требования собираются пол года, то быстрее чем за пол года релиз не выпустить.

Толстячку можно помочь


В каждой конкретной задержке можно увидеть конкретные проблемы и риски и повлиять на них. Да, толстячку действительно можно помочь. Для этого группа должна быть внимательна к проблемам друг друга и постоянно отслеживать состояние работ каждого в каждый момент времени.

Зависимые события и статистические флуктуации


Вы уже должны были понять, что зависимых событий полно в жизни каждого из нас. Осталось понять, что статистические флуктуации (поправить лямки рюкзака, почесаться, запнуться) всегда работают на увеличение сроков, а не на сокращение. Кому-то может показаться, что статистические флуктуации в итоге должны нивелировать друг друга, но этого, к сожалению, не происходит. Статистические флуктуации всегда работают против нас.

Попробуйте поиграть в игру. Берете коробок спичек и своих друзей. Чем больше будет друзей, тем показательней будет результат. Первый кидает кубик и вытаскивает столько спичек из коробка, сколько выпало на кубике и передает их второму. От второго до предпоследнего все также в свою очередь кидают кубик и перекладывают столько спичек, сколько выпало на кубике, из своей кучки в кучку следующего. Последний делает тоже самое только вместо передачи спичек следующему — отправляет их в релиз. Среднее значение, выпадающее на кубике, равно 3,5. Если статистические флуктуации в итоге выйдут в ноль, то для того чтобы отправить в релиз 100 спичек, понадобится 29 ходов.

Если кто-то попробовал поиграть в эту игру — напишите, пожалуйста, за сколько ходов какое количество спичек удалось отправить в релиз.

Способы решения описанной проблемы


Самый плохой вариант, который истощает человека — переход на бег. Его я обычно не рассматриваю т.к. считаю пагубным в стратегической перспективе.

Помочь толстячку — считаю хорошим вариантом. Но как разработчик или тетсировщик может помочь бизнес аналитику собрать требования или системному аналитику формализовать их и выработать проектное решение? В какой-то мере такая проблема решается с помощью кросс-функциональных команд, где каждый человек обладает более чем одной компетенцией. Коллеги, в таком случае, могут помогать друг другу.

Но самый перспективный, на мой взгляд, способ — это совмещение взаимопомощи в кросс-функциональных командах с распараллеливанием работ.

Первый способ распараллеливания — начинать тестирование одновременно с разработкой:

  • Написание тест планов.
  • Автоматизация функциональных тестов. Если говорить о тестах серверного API, то для их написания необходимо определить интерфейсы и желаемое поведение, как только это сделано, сразу могут быть написаны тесты. Если говорить об автоматизированном тестировании пользовательского интерфейса, то первым делом требуется разработать соглашения по именованию идентификаторов объектов, к которым будут обращаться тесты, как только сделано это, а также определен состав экранов, можно сразу писать UI тесты.
  • Составление критериев приемки задач.

Второй способ распараллеливания — дробить работу на более мелкие части:

  • Не нужно пол года собирать требования. Нужно собрать минимум требований, для одного маленького кусочка, и передать требования в разработку. Это позволит уже через пару недель запустить разработку и тестирование и сократить срок релиза практически на всё время сбора требований.
  • Даже если мы пока не можем распараллелить разработку и тестирование, тестировщикам не придется ждать долго, когда будет готов тестируемый функционал, ведь это совсем маленький блок конечного продукта.

Но есть еще один очень важный инструмент, который незаметно но существенно (это не парадокс!) влияет на статистические флуктуации. Это цель! Цель, если она принята каждым человеком группы, сокращает вероятность появления задержек и, мало того, создает стремление сокращать промежуток между зависимыми событиями. Ты, как человек, заинтересованный в достижении цели, будешь стремиться устранить препятствия, которые стоят как на твоём пути так и на пути твоих коллег. А если так будет делать каждый в группе, то препятствий станет гораздо меньше, риски будут прорабатываться заранее, никто не окажется один на один с неподъемной проблемой.

Заключение


Информацию о зависимых событиях и статистических флуктуациях взял из книги “Цель: процесс непрерывного совершенствования” Элияху Голдратта. Пример с походом к Чертовому ущелью и игрой со спичками взял оттуда же.

Из моего в данной статье — проекция на разработку.

Цель данной статьи — во-первых, рассказать об интересном феномене и, во-вторых, показать принципиальную сложность ускорения разработки по “водопаду”.

Комментарии (11)


  1. HappyGroundhog
    08.12.2017 10:41
    #10557474

    Как же все любят гнобить «Водопад» по отрывочным знаниям о нем…
    К слову исторически считается, что термин «водопад» впервые ввёл Winston W. Royce в своей книге “Managing the development of large software systems” (1970) и он же там и написал «I believe in this concept, but the implementation described above is risky and invites failure.». После чего еще несколько страниц описывает как бороться с возможными рисками «Водопада».
    Опять же, не нужно совать Agile куда угодно. Подход «сделали, не понравилось, переделали! Как же гибко!» очень хорошо работает там, где стоимость исправления и повторной итерации мала.
    А теперь давайте строить с помощью Agile гидроэлектростанцию.
    1. О, гидроэлектростанция! Не надо никаких долгих проектов. Берем моторчик, опускаем в воду — электричество!
    2. Теперь нам надо 100 моторчиков! Заливай дамбу!
    3. Хм… 100 моторчиков ведут себя странно…
    4. Ломай дамбу!

    У каждой методологии есть свои сильные и слабые стороны, как и у инструментов, и некоторые люди (ошибочно видимо) считают, что нужно просто их знать и уметь выбирать нужный… А то очень напоминает холивар виндузятников и линуксоидов. Человек впервые проникшийся линуксом/фреймворком/языком начинает пристраивать его везде)

    «Водопад» был признан рискованным вариантом еще его автором в 70-м, но тем не менее он успешно применяется и работает во многих отраслях, особенно в тех, где есть наработанные методы и цена неудачной «итерации» очень высока. Опять же автор рисовал его не как водопад в привычном смысле слова с невозвратным путем вниз

    Традиционное понимание водопада
    image


    1. vryashentsev Автор
      08.12.2017 12:32
      #10557694
      +1

      Спасибо за информацию!
      Везде, где есть последовательность действий, проявляется эффект, озвученный господином Элияху. Даже если добавить стрелочки в обратную сторону и привлечь заинтересованных лиц к определению требований.

      «Водопад умрёт» — это, конечно, фантазия. Есть области применения и для классической каскадной модели.

      Возможно причина эмоционального заголовка заключается в том, что я сейчас работаю с очень инертными организациями, которые используют «водопад» по привычке, а не потому что это необходимо. И терпят существенные потери и в цене и в сроках.


      1. HappyGroundhog
        08.12.2017 12:47
        #10557736

        Если последовательность нельзя распараллелить — то да, увы…
        Рекомендую прочитать 11 страниц оригинального текста, там тоже есть интересные советы на этот счет)


    1. vyatsek
      11.12.2017 13:14
      #10561116

      И еще в добавок к вашему каменту,
      прежде чем говорить что водопад плох, сначала разберитесь в каких условиях работал он и как. Свое начало waterfall берет а в 1956, во времена компьютеров с перфокартами. Задачи были в основном научного характера, никакой прикладной разработки не было. Для того, чтобы упорядочить хаус, Ройс, чтобы хоть как-то упорядочить разработку формализовал процесс, RUP потом описал этот процесс фазами и так или иначе в рамках одной или группы задач все эти фазы есть.
      Сравнивать waterfall и текущую разработку, все равно что сравнивать двигатели начала 20века и современные, с фазовращателями, гидротолкателями непосредственным впрыском, инжектором и т.д. А потом с умным видом говорить:«Да, двигатели начала века были совсем плохие и насегоднячний день они не годятся», конечно не годятся, потому, что тогда и средства были другие и задачи были другие и оккружение было другое.
      Опять таки натягиать сову на глобус привносить теорию ограничений, в разработку софта, примерно тоже самое, что давайте на заводе по производству окон применим космические технологические процессы.
      На реальном производстве, брак одной небольшой детали, может затормозить вообще все изделие целиком. Из реального примера: топливный корпус на ракету имеет очень сложный высокоточный тех. процесс, если запороть этот корпус на финальной стадии, то чтобы получить новый — придется подождать. Пока его отольют, обработают, протестируют. В процесс вовлечено огромное количество людей и цехов. Если деталь новая, то там вообще пол завода работает (конструкторы, испытатели, инструментальщики, технологи, литейщики). Зависимость между этапами очень высокая.
      В софте цикличность и гибкость на порядок выше. Фичу не успеваем — двинем срок, нужно точно в срок — выкинули пару фичей. Постоянно работающих людей над единой частью продукта обычно человек 10 от силы, по факту человек 5-6.
      Вся эта беготня вокруг Lean, Aglie, Canban и т.д. сводится к тому, что манагеры/процессно ориентированные граждане, хотят поднять свою важность. Вместо того, чтобы просто договориться как работать и делать дело.
      Не следует понимать что я отказываюсь от проектирования, прототипирования, требований и т.д. Но в софте все сильно проще, фича не заработала, в крайнем случае вернули предыдущую версию и все, единица продкта в утиль не идет. В ракете ошибка, которая проводит к падению пораждает очень большой гемморой, потому, что «фарш обратно не провернуть», нельзя откатить на предыдущую версию и успешно запустить ракету, уже все упало и сгорело.
      По этому учитесь общаться, договариваться, вырабатывать какие-то процессы взаимодействия и поменьше онанируйте на воплощение теоретического процесса на практике.


      1. vryashentsev Автор
        11.12.2017 13:47
        #10561226

        Я не понял чему конкретно вы возражаете. Вы говорите, что водопад это что-то из далекого прошлого и практически не применим к текущим реалиям. И я про то же.

        Вы говорите, что теория ограничений не применима в разработке, но простите, разве в разработке нет последовательности связанных событий?

        Про брак совсем не в тему написали. То что в разработке с браком проще — никто не спорит. Никто ничего по браку не утверждал.

        Вместо того, чтобы просто договориться как работать и делать дело


        На нюанс надо обратить внимание: тот кто просто договаривается и затем просто работает как договорился оказывается на обочине. Потому что договариваться надо постоянно и постоянно адаптироваться т.к. разработка ПО гораздо более динамичная область нежели производство, скажем, автомобилей, где раз «договорившись», можно 5 лет спокойно работать производя одну и ту же деталь. Но это тоже не по теме статьи.

        Что в итоге хотели сказать-то?


        1. vyatsek
          11.12.2017 17:27
          #10561698

          Зависимые события и статистические флуктуации или почему «водопад» умрет
          не надо трогать водопад, сравнение с водопадом — друной тон.
          Если коротко, то применение/адаптирование заводских процессов производства в IT лютый оверхед.
          Вы говорите, что теория ограничений не применима в разработке, но простите, разве в разработке нет последовательности связанных событий?
          По сравнению с производством — они ничтожны.


          1. vryashentsev Автор
            11.12.2017 18:20
            #10561788

            Да, похоже, сравнение с водопадом это действительно моветон. Учту.
            Кстати, я не предлагал использовать «заводские процессы». Наоборот, вполне такие IT-шные предлагаю использовать.
            А вот с ничтожностью проявления теории ограничений совсем не соглашусь. Там где «водопад» живее всех живых, столкнулся с вполне таки катастрофическим проявлением: пол года на сбор требований (тут серьезно просрочили), еще 4 месяца на разработку, еще 3 месяца на внедрение. И есть отличный потенциал для дальнейшего ухудшения ситуации т.к. сейчас все еще идет процесс сбора требований. Есть конечно и плюс — пришло понимание необходимости разрабатывать небольшими кусками.


  1. zloddey
    08.12.2017 12:34
    #10557698

    Если кто-то попробовал поиграть в эту игру — напишите, пожалуйста, за сколько ходов какое количество спичек удалось отправить в релиз.

    #!/usr/bin/env python2.7
from random import randint

total_items = 100
players = 10
pools = [total_items] + players * [0]
steps = 0

while pools[-1] < total_items:
    steps += 1
    for idx in xrange(players):
        amount = min(randint(1, 6), pools[idx])
        pools[idx+1] += amount
        pools[idx] -= amount

    print pools

print "Steps: %d" % steps

    Для 10 игроков обычно выходит 38-48 шагов.


    1. vryashentsev Автор
      08.12.2017 17:15
      #10558274

      Спасибо!


  1. speshuric
    08.12.2017 13:35
    #10557862

    Ну вот… Такой живописный эпизод хорошей книги так исковеркать, что аж вспоминается анекдот про "мне Мойша напел".


    • Начнем с того, что шли они не в шеренгу, а в колонну.
    • Кусок с походом полностью вырван из контекста. В оригинальной книге это был один из ключевых моментов изобретения техники "буфер-барабан-веревка". Почему шли, почему это важно, как реагировали дети на предложения — всё это и есть контекст.
    • Применять "Цель" впрямую к разработке — достаточно спорно и сложно, это сто раз обсуждено и много лет назад написаны "Цель-3", "Критическая цепь" и "Синдром стога сена". Более того идеи КЦ уже проникли и в PMBoK.

    И еще момент. При чтении "Целей" надо понимать, что это очень-очень хороший рекламный материал к консалтингу, обучению Голдратта и к другим более сложным материалам. То, что они хорошо написаны — не отменяет их назначение (в корп. блогах на хабре тоже есть хорошие статьи)


    1. vryashentsev Автор
      08.12.2017 17:20
      #10558282

      Похоже, я поторопился. Буду стараться лучше.