Пользователь
0,0
рейтинг
10 июля 2012 в 15:46

Разработка → Джоэль Спольски: производственные запасы в разработке ПО перевод

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

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

Хранение запасов стоит денег. Предположим, что на хлебозаводе есть шесть 50-тонных силосов для хранения муки. Это значит, что в среднем каждый день в них находится около 150 тонн муки. По сегодняшним ценам это 73000$ мёртвого капитала.

Есть и другие издержки, например порча. Мука может храниться месяцами, но готовые булочки начинают терять в цене как только выйдут из печи; через 24 часа они не стоят почти ничего.

Зачем тогда вообще хранить запасы? Затем что есть ещё и расходы связанные с их нехваткой. Если на заказ новой партии булочек с кунжутом уходит два дня, то, если они вдруг закончатся в вашей закусочной, ваш бизнес по продаже гамбургеров остановится на двое суток. Запасы — это буфер, который предотвращает непредвиденные остановки. Сейчас придумано множество алогоритмов для вычисления оптимального объёма этих буферов (для начала: бережливое производство, теория ограничений).

Зачем я вам всё это рассказываю? Затем, что в производстве ПО тоже существуют места, где накапливаются «производственные запасы». И хранение этих запасов может стоить кучу времени и денег.

«Что? Разве можно сравнивать производство софта и булочек?» — спросите вы.

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

  1. Принятие решений (стоит ли нам реализовать эту функцию?)
  2. Проектирование (спецификации, планирование, макеты и т.д.)
  3. Реализация (написание кода)
  4. Тестирование (поиск ошибок)
  5. Отладка (исправление ошибок)
  6. Выпуск (доставка программы потребителям, развёртывание на сервере)

(P.S. «Водопад» тут ни при чём. Нет. Совершенно точно нет! Отвалите!)

Запасы могут скапливаться между всеми этим этапами. Например, когда программист заканчивает писать код (этап 3), он отправляет его тестировщику (этап 4). В любой момент времени какое-то количество кода дожидается своей очереди на тестирование. Это и есть запасы.

Стоимость таких запасов огромна. Они могут добавить шесть или даже двенадцать месяцев ко времени релиза. Всё это время куча кода и идей простаивает на разных этапах производства вместо того, чтобы попасть в руки пользователей. Эти задержки могут стать решающим отличием инновационного продукта (iPhone) от вечно вторых догоняющих аналогов (Windows Phone). Практически невозможно заставить потребителя купить Windows Phone, если iPhone вышел всего шестью месяцами раньше.

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

Давайте пройдёмся по трём местам, где скапливается больше всего запасов.

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

Проблема в том, что 90% фич из бэклога никогда не будут реализованы. Так что каждая минута, потраченная на запись, проектирование, обдумывание или обсуждение таких фич — потерянное время. Когда я слышу, что некоторые команды практикуют регулярное «расчёсывание бэклога», аккуратно и методично растрачивая драгоценное время на вещи, которые никогда не станут частью конечного продукта, мне хочется вырвать себе глаза.

Предложение: Не позволяйте бэклогу разрастаться больше чем на месяц-другой работы. Если бэклог полон, не вносите туда новых элементов, пока не реализуете старые. Не надо тратить время на обсуждение, проектирование или спецификации фич из бэклога. Он должен рассматриваться как список вещей, о которых запрещено говорить и над которыми запрещено работать до начала реализации.

Баг-трекеры. Это отличная вещь. Особенно если багрепорты подробны, полны и конкретны. Но я заметил, что в реальном мире желание не пропустить ни единого сообщения об ошибке приводит к тому, что однажды вы с ужасом обнаруживаете, что в вашем трекере 3000 незакрытых ошибок, некоторые из которых уже давно потеряли актуальность, другие невозможно воспроизвести, а большинство даже не стоят того, чтобы их исправлять, потому что они совершенно незначительны. На то, чтобы собрать эти багрепорты, ушли месяцы и годы, и вы спрашиваете себя, как это вообще возможно — у нас 3000 ошибок, а продукт при этом очевидно очень хорош, пользователи любят его и пользуются им каждый день? И вам становится ясно, что вы просто чересчур усердно собирали эти ошибки, вместо того, чтобы развивать продукт.

Предложения:

  • Сразу отсеивайте ошибки, которые слишком незначительны, чтобы их записывать.
  • Следите за тем, чтобы в любой момент время на исправление всех ошибок из багтрекера не превышало двух недель.
  • Если их накопилось больше — остановитесь и начните исправлять их, пока не доберётесь до откровенно глупых и незначительных ошибок. После этого закройте их все с пометкой «won't fix». Не бойтесь пропустить что-то важное — серьёзные ошибки обязательно всплывут ещё не раз.

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

Это одна из самых дорогих форм запасов. Они могли бы приносить вам деньги, но они просто пылятся в ожидании релиза, а тем временем продукт более шустрых конкурентов уже делает это!

Самое страшное, что разработчики часто даже не чувствуют разрушительного эффекта таких задержек, так как вся команда сидит на ночных сборках и использует новые фичи каждый день. Наверняка в Microsoft все жутко довольны Windows 8, которой они пользуются уже с год, так что им не понять страданий OEM-поставщиков, которые пытаются продавать компьютеры с Windows 7 в мире Mac OS X Lion.

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

Итак, к чему я веду? У нас в Fog Creek были все три вида запасов: гигантский бэклог, чудовищная база багрепортов и фичи, годами дожидающиеся релиза. Мы прочувствоали всё это на своей шкуре. И я понял, что нам нужна система, которая ограничивала бы размер запасов.

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

Trello отлично работает с небольшим количеством запасов, но быстро становится громоздкой и неудобной, когда вы впихиваете в неё много лишнего. Это сделано намеренно. Это позволяет видеть и чувствовать, когда запасов слишком много. (щёлкните по скриншоту и посмотрите на нашу собственную страницу разработки).

Каждый день вы смотрите на доску Trello и видите, например, что уже целых 17 фич готовы и ждут релиза. Это побуждает устранить затор как можно быстрее.

Каждый раз, когда кто-то предлагает безумную новую идею, вы смотрите в бэклог и, если там слишком много записей, не тратите время на обсуждение и обдумывание этой идеи.

Я искренне надеюсь, что такой подход позволит вам тратить намного меньше времени на работу над вещами, которые никогда не увидят белый свет. «Расчёсывание бэклога». Что за чушь!

Перевод: Joel Spolsky
Илья Сименко @ilya42
карма
524,7
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

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

  • +12
    Спольски долго бился головой о тяжелый, неудобный интерфейс FogBugz, и наконец написал свою Kanban доску? :)
  • –7
    Про мир Mac OS X улыбнуло:) Видимо, мы в каких-то разных мирах живем.
    И да, новая версия операционной системы должна выходить раз в ~5-10 лет (как это происходит с виндой, линуксом и той же макосью), а не каждые полгода, как у андроида. Да, новые фичи надо выкатывать по мере реализации, но ни в коем случае не ломать совместимость с уже написанным софтом.
    • +4
      вы удивитесь, но макось последняя вышла год назад, а новая будет в конце месяца. убунту релизится раз в полгода, но есть и вообще rolling-release.
      Это в windows мире любят 5 лет заботливо что-то делать, а потом люди плюются, когда пересаживаются, потому что нифига не понятно.
      • 0
        см. ниже
    • 0
      Простите, а у какого конкретно дистрибутива Linux новая версия выходит раз в 5-6 лет?
      • –8
        Я про ядро, если кто не понял. Что там маркетологи на коробочке нарисовали — дело десятое, главное что софт не ломается.
        • +7
          Ядро и ОС, это разные вещи это раз.
          Операционная система не определяется ядром. Это два.
          Ядро линукса релизится куда чаще раза в 5 лет (минорные релизы), даже чаще релиза убунты. Это три.
          Пользователю побоку, что там в ядре поменялось. Пользователю важно удобство. Это четыре
          • –8
            Пользователю и особенно программисту не побоку, что на рынке присутствуют одновременно два-три поколения устройств с разными версиями ОС, которые не просто не совместимы между собой, но требуют рефакторинга приложений ради совместимости. Вот это — засада.
            А то, что где-то что-то пропатчили или добавили финтифлюшечку в новом релизе — так это и под винду этих патчей иногда по нескольку штук в день выходит.
            • –4
              (первая часть про андроид была, если кто не понял)
            • +1
              расскажи пожалуйста про то, как не ломают совместимость в виндах. а то я везде слышал мнения другого толка.
              • 0
                может перейдем от слухов к фактам? Где что поломалось в винде скажем при переходе от 95 к 7, ну кроме пары недокументированных функций и прямого доступа к железу?
                • 0
                  лично у меня перестал работать EAX, потому что они еще в висте это выпилили. Creative запилили костыль под названием Alchemy, который работает только на их картах. остальные в пролете
                  • 0
                    А EAX разве не поделие самой Креатив? Они перестали поддерживать != выпилили в висте.
              • +2
                Зря вы так категорично. При всей моей симпатии к *nix-like, думаю, M$ таки тратит на поддержку обратной совместимости значительно больше всех остальных. Иногда доходя до абсурда, на мой взгляд, но это другой вопрос. Почитать можно на The old new things поискав по соответсвующим запросам.
                • +1
                  Это было так примерно до Висты, а потом начали ломать обратную совместимость уже особо не задумываясь. Вин8 — в этом плане вообще отличится.
                  • 0
                    Позвольте не согласиться. Начиная с висты кардинальным образом закрутили гайки в плане безопасности, включая сразу десяток механизмов ломающих старые, кривонаписанные программы. Это и тотальный переход на учётки без админских прав, и uac, и DEP, и разного рода рандомизация памяти, и выпиливание доступа к системным папкам для всех, включая админов, и введение уровней исполнения, и ещё куча всякого такого. Вот и поломалось много чего, но в основном потому что и раньше работало через одно место.
  • –2
    Подсказки гугла при поиске joel spolsky жгут напалмом.
  • +1
    >Trello отлично работает с небольшим количеством запасов, но быстро становится громоздкой и неудобной, когда вы впихиваете в неё много лишнего. Это сделано намеренно.

    Умные люди давно уже придумали ограничивать число задач, которые могут быть в определенной стадии. Нужен тупо физический блок. Это азы канбана.
    А позволять делать, но так, чтобы это было неудобно — самая ужасная практика из всех возможных :)
    • –1
      Убунта раз в полгода выходит. windows по плану раз в 3 года. Какие 5-10 лет? Единственный раз было 5 лет между XP и vista.
  • 0
    Я в легком шоке от видео, хочу себе такое!
  • +2
    >Сразу отсеивайте ошибки, которые слишком незначительны, чтобы их записывать.

    сомнительное какое-то предложение. Кто должен решать значительна ошибка или незначительна? Тестировщик? Пусть уж лучше она won't fix лежит и поиском находится, чем каждый раз на нее натыкаться и думать, надо ли ее фиксить или нет.
    • 0
      Сделайте поправку на категоричность суждений Спольски ;) Он, помнится, в книжке disclaimer писал.
    • –3
      В маленьких коммандах зачастую тестировщик он же кодер
      • 0
        Видимо маленьких комманд ни у кого не было…
    • 0
      В вашем опыте правда были проекты с несколькими тысячами багов, где баг, не помня его в прошлом, можно было найти поиском?
      По-моему, это из области фантастики.
      • 0
        1к — 2к были.
        И если один из тестеров находит баг в каком-то старом компоненте, то он должен проверить, а не создал ли его кто-либо еще до него. Поиск в баг-трекерах и расставление тегов помогает.
  • +2
    не вносите туда новых элементов, пока не реализуете старые
    остановитесь и начните исправлять их, пока не доберётесь до

    Тут есть серьезное противоречие с общим посылом «не останавливайтесь» и «не держите запасов». И вообще, не совсем в духе Спольски: не только хромающая логика, но и недоказанный и очевидно не универсальный подход «давайте побежим и трахнем вон ту коровку©».
    • 0
      Согласна, инновационные идеи не допустим до обсуждения просто потому что у кого-то не было времени бэклог почистить? Просто систему приоритизации нужно хорошую. Есть классные штуки, которым можно поставить высокий приоритет, а есть не гениальные вещи, но зато легко реализуемые — их можно маркировать как easy win. И в зависимости от наличия времени/ресурсов вытаскивать из бэклога идеи согласно приоритетам.
  • +1
    Спольски почитал Голдратта?)
  • +2
    Такое ощущение, что Спольски активно ищет, но пока точно не знает, что ему надо.
    Вот, к примеру, в продукте сразу же сами собой напрашиваются теги или категории (и они есть в планах). Маркировать шестью цветными меточками (пусть даже и именоваными) не очень наглядно. Свободно определяемые теги были бы удобнее. Приоритеты в каком-либо виде и фильтры по ним тоже не помешали бы
    Я пока что так выкрутился — создал несколько пользователей с соответствующими аватарами, теперь у меня есть наглядные иконки (их можно объединять и по ним можно фильтровать, естественно):

    image

    Кроме того, подсознательно хочется привнести какие-то элементы GTD в этот канбан. Ну то есть ToDo — они ж бывают «Сделать сегодня» либо «На этой неделе», либо «когда-нибудь» и т.д. Вообще Спольски — весьма разумный, может ему удастся в конечном итоге сделать действительно удобную штуку. Да и то, что есть — уже вполне работоспособно. Когда он допилит приложение для андроида, будет совсем хорошо.
  • +1
    «50-тонных силосов для хранения муки» — Видимо, в оригинале — silo либо silo tower? Силос в русском языке — это корм для скота, а silo tower — силосная башня, в данном тексте — элеватор.
    • +1
      Силос — это не только корм для скота. Вот, например, одно из словарных определений. А элеватор — это прежде всего зернохранилище. В моём детстве во время экскурсии на хлебозавод эти башни называли именно силосами.
      • 0
        ясно, будем знать
  • 0
    >Каждый раз, когда кто-то предлагает безумную новую идею, вы смотрите в бэклог и, если там слишком много записей, не тратите время на обсуждение и обдумывание этой идеи.

    Блин, ну почему всегда абстрактные предложения? Почему все эти рассуждения, выглядят как философия?

    Покажите мне практический пример, как отключать себе мозг, чтобы «не тратите время на обдумывание этой идеи»?
    Я не могу не думать над самыми разными задачами. Если кто-то высказал мысль, и если она здравая, то я не представляю себе, как отключиться и не думать о ней хоть какое-то время.

    Единственный практический пример, который приходит, это убивать на месте того, кто зная о большом числе текущих обсуждений, позволил себе поселить в головах других, новую мысль. Тогда, зная о последствиях, народ будет заглядывать в список, прежде чем поселить в головах других, свои идеи… хотя конечно и это не всегда сработает)) (это прикол конечно...)
  • +5
    1. Вырвано из контекста LEAN ( yandex.ru/yandsearch?text=LEAN&lr=10435 ) с минимальной адаптацией для ИТ

    Также очень здорово прочитать «Цель» Голдратта

    2. "Предложение: Не позволяйте бэклогу разрастаться больше чем на месяц-другой работы. Если бэклог полон, не вносите туда новых элементов, пока не реализуете старые. Не надо тратить время на обсуждение, проектирование или спецификации фич из бэклога. Он должен рассматриваться как список вещей, о которых запрещено говорить и над которыми запрещено работать до начала реализации."

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

    Вывод — надо правильно управлять бэклогом

    3. "На то, чтобы собрать эти багрепорты, ушли месяцы и годы, и вы спрашиваете себя, как это вообще возможно — у нас 3000 ошибок, а продукт при этом очевидно очень хорош, пользователи любят его и пользуются им каждый день?"

    Та же фигня, предложение все закрыть не канает. Важно понимать как вы управляете и как вы в рамках управления проводите проверку и воздействие (PDCA — Plan, Do, Check, Act).

    4. «Фичи, ожидающие релиза. „
    Очень специфично, для гугл хрома это вполне оправданно, и даже в случае выхода USB 4 отсутствие его оперативной поддержки для существующих операционных систем будет фейлом. А вот внедрение какой-нибудь релиционно СУБД ориентированной файловой системы вряд ли может делаться в минорном апдейте ввиду сложности новой технологии и изменения программного ландшафта для зависимых систем.

    Короче, чувак рекламирует какой-то там софт…
  • 0
    Как же Джоэль любит хлебобулочные ассоциации.
    Напомнило
    • 0
      Не удивительно. Он проработал на хлебопекарне какое-то время.
      • 0
        Написал не прочитав ссылку :) Сорри
  • 0
    Rapid board'ы на гринхоппере в джире как раз об этом же и, на мой взгляд, намного удобнее.

  • 0
    «Так же как и кусочки теста...» — просто мосг взорвало.

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