Предлагаю вашему вниманию перевод статьи, в которой высказывается интересная точка зрения на размер релизов/задач при разработке информационных систем. По мнению Аллана Келли, при разработке ПО отсутствует экономия на масштабе, а при увеличении объема задач/релизов экономика только ухудшается. Статья содержит примеры и доводы, иллюстрирующие это, и автор рекомендует стараться ставить небольшие и конкретные задачи, работать более мелкими релизами. Пытливый читатель сразу задаст вопросы: «Можно ли из этого сделать вывод, что необходимо максимально уменьшать размер задач/релизов? Где же тогда этот предел? Нужно ли выводить в продуктив по одной строчке кода?» Эти вопросы, к сожалению, не раскрыты в статье. По моему личному опыту, в имеющихся условиях у команды существует некоторый оптимальный размер задач/релизов, который определяется зрелостью процессов, спецификой культуры команды и уровнем развития инженерных практик. Для кого-то это три месяца, для кого-то это одна неделя, кто-то способен работать в режиме непрерывной поставки… Однако если инвестировать в то, чтобы команда научилась бы работать меньшими задачами/релизами, то это впоследствии принесет долгосрочную отдачу.
«Практичные люди, считающие себя совершенно свободными от каких-либо идейных влияний, — обычно всего лишь рабы какого-нибудь покойного экономиста». Джон Мейнард Кейнс
Большинство из вас не только знакомы с идеей экономии на масштабе, но и ожидают, что она работает повсюду. Большая часть нашей рыночной экономики основана на предположении, что когда вы покупаете/тратите больше, вы получаете больше на единицу расходов.
На каком-то этапе нашего образования (даже не изучая экономику или исследование операций) мы усвоили идею, что если Генри Форд построит один миллион одинаковых черных автомобилей и продаст один миллион автомобилей, то каждый автомобиль будет стоить меньше, чем если бы Генри Форд изготовил один автомобиль, продал один автомобиль, построил другой очень похожий автомобиль, продал этот автомобиль и т. д. В итоге получается, что Генри Форд производит автомобили дешевле и продает их дешевле, так что покупатели выигрывают.
(Действительно, идея и история массового производства и экономии на масштабе тесно переплетены. Но все же сейчас я говорю не о массовом производстве, а об экономии на масштабе.)
Вы полагаете, что если вы пойдете в свой местный супермаркет, чтобы купить молоко, то покупка одной большой упаковки молока, скажем, объемом 4 пинты за один раз, будет дешевле, чем покупка четырех упаковок по одной пинте.
В моем выступлении #NoProjects я использую этот слайд, он всегда вызывает смех:
Молоко дешевле в большой упаковке. ПО дешевле в мелкой таре. ПО в мелкой таре сокращает риски.
Вчера я проверил эту теорию в своем местном Sainsbury’s, вот доказательство:
1 пинта молока стоит 49 пенсов (стоимость одной пинты — 49 пенсов).
2 пинты молока стоят 85 пенсов, или 42,5 пенса за пинту (стоимость дополнительной пинты — 36 пенсов).
4 пинты молока стоят 1 фунт стерлингов, или 25 пенсов за пинту (стоимость каждой из двух дополнительных пинт — 7,5 пенсов).
(И если вы не знали, Великобритания является страной, использующей две системы мер (метрическую и британскую). Такие страны, как Канада, Нидерланды и Швейцария, учат своих людей говорить на двух языках. В Великобритании людей учат использовать две системы мер!)
Эта идея так глубоко укоренилась, что, когда супермаркеты не ставят цену ниже за покупку большего объема, то поступают жалобы (см. The Guardian).
Покупая молоко в Sainsbury’s, вы покупаете не только молоко: Sainsbury’s нужно помещение, нужен персонал, затраты на то, чтобы «заманить» меня в магазин. Все эти затраты одинаковы, если вы купите одну пинту или четыре. Вот почему магазин может снизить стоимость единицы товара при покупке большой партии.
В качестве причины корпоративных слияний часто называют экономию за счет масштаба: создание концессий с поставщиками, производство большего количества товаров для снижения общих затрат. Отделы закупок рассчитывают на экономию на масштабе.
Но… и это большое НО… приготовьтесь…
Разработка программного обеспечения не имеет экономии на масштабе.
Экономика разработки ПО ухудшается с увеличением масштаба.
Если бы программное обеспечение продавалось пинтами, то четырехпинтовая упаковка программного обеспечения не просто стоила бы в четыре раза дороже упаковки объемом одной пинты, она стоила бы намного дороже.
Вокруг нас сплошные убытки.
- Небольшие команды часто превосходят большую команду. Пять человек, работающих в плотной команде, будут гораздо более продуктивными из расчета на одного человека, чем команда из 50 или даже 15 человек. (Команда разработчиков Quattro Pro в начале 1990-х годов, вероятно, является лучшим задокументированным примером этого.)
- Чем больше строк кода в программном обеспечении, тем сложнее улучшить его или исправить ошибку. Внесение исправления в систему с одним миллионом строк может быть более чем в 10 раз сложнее, чем исправление системы с 100 000 строк.
- Проекты, которые были задуманы как крупные, имеют гораздо более высокие затраты и более низкую производительность (на единицу результата), чем небольшие системы. (Книга Кейперса Джонса 2008 года содержит некоторые таблицы производительности на единицу функции, которые иллюстрируют это. Стоит отметить, что самые большие системы, как правило, военные, и они имеют чудовищную производительность — например, F35 или A400.)
- Лучше попросить обратную связь у пользователя раньше, когда сделали еще не очень много. Чем дольше ждем, тем больше может быть проблем впоследствии.
Примеры можно было бы еще продолжить.
Но есть и другая причина: работа большими релизами увеличивает риски.
Предположим, что 100 мл молока испортилось. Если 100 мл испортилось в одной маленькой упаковке, то вы потеряли 1 пинту молока. Если 100 мл испортилось в упаковке объемом 4 пинты, то вы потеряли 4 пинты.
Предположим, что ваши разработчики допускают одну ошибку в год, которая не ловится тестированием и приводит к крупной проблеме для пользователя. Предположим, вы это знаете, поэтому, чтобы поймать ошибку, вы проводите больше тестов. Чтобы снизить затраты на тестирование, вам нужно тестировать больше программного обеспечения, поэтому вы делаете релизы большего размера с большим количеством изменений — в русле экономии на масштабе. На самом деле это делает тестирование сложнее, но… Предположим, вы делаете один релиз в год. Этот релиз приводит к «синему экрану смерти» для пользователя. Теперь пользователь видит, что каждое выпущенное вами обновление ломает его компьютер. 100% ваших релизов — сломаны.
Если вместо этого вы выпускаете обновления еженедельно, то все равно один раз в год вы выпустите релиз с критической ошибкой. Однако все же пользователь видит, что в течение года было 51 успешных релизов без ошибок и только один — с ошибкой. В итоге — менее 2% ваших релизов являются проблемными.
Да, я говорю о размере партии. Разработка программного обеспечения более эффективна, если разрабатывать и поставлять функциональность небольшими партиями. (У Дона Райнертсена в его книге «Принципы разработки продукта» также есть рассуждения, поддерживающие тезис об отсутствии экономии на масштабе при разработке ПО.)
Хорошо, есть несколько мест, где разработка программного обеспечения действительно демонстрирует экономию на масштабе, но в большинстве случаев — это приносит только убытки.
Это происходит потому, что каждый раз, когда вы добавляете к программному обеспечению дополнительные функции — затраты на единицу продукции увеличиваются.
- Добавьте четвертого человека к команде из трех человек, и количество возможных «коммуникационных» путей увеличится с 3 до 6.
- Добавьте одну функцию в релиз, и у вас будет одна функция для тестирования, добавьте две функции, и у вас будет три теста: по одному на каждую функцию, плюс один на тестирование взаимодействия между ними.
Кроме того, учтите, что человеческий разум способен вместить лишь определенный объем информации. По мере увеличения сложности (больше изменений, больше кода) наша когнитивная нагрузка увеличивается, мы замедляемся, совершаем ошибки, тратим больше времени.
(Экономия от увеличения объема содержания (scope) и увеличения специализации тесно связаны с экономией на масштабе, и в целом экономика разработки ПО ухудшается при увеличении объема содержания (поэтому, лучше ставить более конкретные задачи) и при большей специализации (специалисты широкого профиля обычно предпочтительнее, чем узкопрофильные).)
Однако будьте аккуратны: после того, как программное обеспечение разработано, эффект экономии на масштабе становится неограниченным. Мир переключается. Созданное программное обеспечение, вероятно, демонстрирует большую экономию на масштабе, чем любой другой продукт, известный человеку. (С экономической точки зрения, затраты на изготовление первого экземпляра чрезвычайно высоки, но затраты на изготовление идентичной копии (изготовление) по сути близки к нулю — «Ctrl-C Ctrl-V»).
Что же это значит?
Во-первых, вам нужно перенастроить свой , почти все в современном мире были воспитаны в парадигме экономии на масштабе со времен школы. Вы должны начать думать об убытках при увеличении масштаба.
Во-вторых, всякий раз, когда вы сталкиваетесь с проблемой, когда вы чувствуете желание двигаться быстрее, бегите в противоположном направлении, двигайтесь медленнее.
В-третьих, воспользуйтесь каждой возможностью стать меньше.
В-четвертых, научитесь работать маленькими партиями, оптимизируйте свои процессы, инструменты, подходы… в общем, чем сделать несколько больших штуковин — лучше сделать много маленьких.
В-пятых, и это убийственно: знайте, что большинство людей вообще не понимают этого. На самом деле все хуже…
В любой существующей организации, особенно в крупной корпорации, большинство людей, принимающих решения, — сторонники только лишь теории экономии на масштабе. Они ожидают, что дешевле производить большое, чем маленькое, и навязывают это мнение другим, особенно людям, занимающимся разработкой программного обеспечения. (Поэтому крупные компании, пытающиеся быть гибкими, напоминают мне мужчин среднего возраста, покупающих спортивные автомобили.)
Многие из этих людей попали туда, где они находятся сегодня из-за эффекта экономии на масштабе, многие из этих компаний существуют из-за эффекта масштаба; в их сфере деятельности быть большим — это быть успешным.
Но в мире разработки программного обеспечения такое является рецептом неудачи и недостаточной эффективности. Конфликт между в парадигме экономии на масштабе и убытках, которые оно приносит в разработке ПО, создаст напряженность и разногласия.
Теперь я вас убедил? Становитесь маленькими.
Наконец, я все чаще задаюсь вопросом, где еще отсутствует экономия на масштабе? Не может быть, чтобы это было свойственно только для разработки программного обеспечения. Я задаюсь вопросом, не являются ли убытки от масштаба свойственными вообще для всей умственной работы?
Даже если это не так, поскольку все больше и больше работ становятся похожими на разработку программного обеспечения – из-за важной роли знаний конкретного индивида и использования программных средств, — я ожидаю увидеть все больше и больше примеров убыточности от масштаба.
Автор: Савочкин Егор
