У «Кока-Колы» почти всегда такие двухлитровые бутылки газировки пакуются по восемь штук – два ряда по четыре бутылки. Типы упаковок могут различаться. Иногда эта восьмерка находится в картонных коробках с открытым верхом. Другой тип упаковки – просто обернутые полиэтиленом со всех сторон бутылки: стянутые вначале довольно туго, в итоге они все равно слегка болтаются внутри такого мешка. Иногда полиэтиленовая обертка рвется, и тогда бутылки болтаются сильнее, а то и совсем высыпаются наружу. Такие упаковки не представляют большой проблемы для ручного построения палет. Работники прекрасно видят, где полиэтилен хорошо натянут, где – более свободно и где порван совсем, и поправляют палеты так, чтобы дефекты не приводили к падению коробок или отдельных бутылок. Но для автоматики это катастрофа! У нас не было способа определить, где упаковка тугая и бутылки сидят как влитые, а где они вихляются или даже выпадают из полиэтиленовой обертки.
Но хуже всего были поддоны (trays) с ячейками для восьми двухлитровок, где бутылки стояли свободно и не были стянуты никакой пленкой. Если такой поддон падал вбок, бутылки просто рассыпались в разные стороны. Даже в первых испытаниях на складе «Кока-Колы», когда палеты состояли всего лишь из нескольких коробок, это случалось регулярно. В дальнейшем, когда размер палет увеличился, это стало острейшей проблемой.
Несколько месяцев я работал с командой планирования палет (PBP), не будучи формально ее членом. Я старался помочь довести до ума палеты для «Кока-Колы» и мои последние алгоритмические наработки для палет из обычных коробок. Работа двигалась со скрипом, медленнее, чем проект KP в 2011 г., хотя в команде к этому моменту было больше людей.
В июле 2016-го лидер этой команды, Кайл Т., решил уйти из «Симботика». Здесь у него не очень получалось, он стал искать новую работу и получил предложение от Гугла в офис в Кембридже, пригороде Бостона, где располагаются также Гарвард и MIT. Майк Фандоцци, недавно пришедший вице-президент по софтверу и один из дружков Гахагана, предложил мне лично возглавить команду PBP. Я согласился, чувствуя, что иначе проект полностью завалят и это будет иметь катастрофические последствия для «Симботика» в целом.
Омар К. к этому времени ушел сам, избавив меня от необходимости увольнять его. Но он успел за полтора года напортачить в некоторых частях кода так, что исправить все это было труднее, чем написать с нуля. Например, так и не разобравшись в моем сложном алгоритме упаковки прямоугольников, он без моего ведома нашел в сети более простой алгоритм с готовым кодом. Но этот алгоритм собирал упаковку значительно хуже, оставляя много дыр между стеками. Когда же команда начала в спешке переписывать мой алгоритм упаковки рядов прямоугольников, код получился очень сырым, даже по сравнению с кодом Дэвида Эренберга 2011 г. Теперь нам предстояло постепенно улучшать его.
Я уже давно не работал в команде, непосредственно пишущей рабочий код. Весь наш софтвер к этому времени был полностью переделан на C# и. NET. Сам язык C# за последние годы ушел далеко вперед, и мои собственные познания в нем сильно отставали.
Еще в 2012 г. «Симботик» перешел на принципы эджайл (agile) в разработке софта. Для меня это тоже было в новинку. Последние несколько лет я с любопытством наблюдал за заседаниями наших софтверных команд, копошащихся в ворохе разноцветных бумажных стикеров, где они писали отдельные фразы, передавали их друг другу или наклеивали на белую доску. Это было важной составной частью эджайл-процесса – так проводилась ретроспектива предыдущего «спринта» и планирование нового.
Эджайл зародился в начале нулевых и к началу 2010-х стал модным течением в софтвере. Фактически его популярность стала признанием неэффективности более традиционных практик. Крупные софтверные проекты проваливались все чаще и почти никогда не вписывались в бюджет и запланированные сроки выполнения. Традиционный подход к софтверным проектам можно было назвать архитектурным, хотя для этого употребляют обычно другие термины, например «водопад» (waterfall), описывающий последовательные фазы проекта как сообщающиеся бассейны, где вода поэтапно перетекает из одного в другой. Такой подход предполагает тщательное планирование, так что основные или почти все детали дизайна обсуждаются и утверждаются в начале проекта, перед его выполнением, как детали архитектуры здания. Затем начинается исполнение проекта в соответствии с этими планами, и оно тоже проходит через фазы написания кода, тестирования, интеграции с другими частями и, наконец, финального этапа с тестированием всех запланированных компонент вместе.
С ростом объема и сложности проектов архитектурный подход работал все хуже, и все больше разработчиков софта осознавали это в начале XXI в. Многое практически невозможно было просчитать заранее. Первоначальные предположения летели к чертям, отовсюду появлялись неучтенные факторы и исключения из правил. Выяснялось, что производительность отдельных компонент не отвечает заложенным в архитектуру ожиданиям: одни тормозили, другие жрали память, данные блуждали где-то в сетях коммуникаций и приходили поздно или вовсе терялись. Почти всегда через несколько месяцев после начала проектов их текущий вид совсем не соответствовал запланированной на старте архитектуре.
Эджайл был основан на другом принципе – его можно назвать «эволюционным». Код должен развиваться не как строящееся здание в соответствии с точным чертежом, а как живой организм – от эмбриона до взрослой особи. После рождения этот организм в каждый момент времени должен быть «живым» – рабочим кодом, выполняющим все большую часть функций, заложенных в проекте, и делать это все более и более эффективно. Эджайл подразумевал непрерывное улучшение кода – рефакторинг, занимающий львиную долю рабочего времени программистов. Вначале код может быть примитивным, но все-таки он выполняет минимум нужных задач. На следующих этапах он обрастает новыми чертами и опциями, а возможности, уже функционировавшие в нем, должны становиться более эффективными. Код проходит непрерывный путь от гадкого утенка до прекрасного лебедя, но в процессе даже утенок должен уметь плавать и вскоре немного летать.
Конечно, у эджайла были и свои недостатки, причем весомые. Многократное превращение изначально уродливого кода в оптимальный требовало значительных затрат, хоть и растянутых во времени, – несоизмеримо больших, чем имплементация изначально хорошего дизайна. Но изначально хороший дизайн постепенно становился редкостью – не из-за глупости разработчиков (что, впрочем, редкостью не было), а из-за сложности и непредсказуемости проектов. Эджайл был не столько способом выполнить проект быстрее и эффективнее, сколько завершить его как факт – добиться, чтобы он хоть как-то работал, а не превращался в безнадежный клубок хаоса, как немало проектов, развивавшихся по традиционной методологии.
Эджайл предполагал непрерывную работу над уменьшением «технического долга» (technical debt) – постоянное улучшение кода, позволяющее поддерживать проект в хорошем рабочем состоянии. В реальности это далеко не всегда получалось. Код все равно обрастал техническим долгом быстрее, чем его можно было устранить, и в этой гонке команды разработчиков редко побеждали даже за годы тяжелой работы. В определенный момент ситуация становилась безнадежной и код нужно было переписывать с нуля, обычно на другом языке и с использованием новых, быстро развивающихся инструментов.
Для меня самого эджайл был в новинку. Я пришел в команду, уже привычную к этой практике, и не хотел нарушать ее без крайней необходимости. Но в содержание работы – применение ключевых алгоритмов – нужно было срочно вносить большие коррективы. У команды не было нужного фокуса. Члены команды постоянно выдумывали, что бы такое попробовать для улучшения палет. Палеты же выходили ужасными – как для «Кока-Колы», так и те, что планировались для склада в Бетлехеме и строящегося первого склада «Волмарта». В то время как многие из актуальных на тот момент проблем были уже намного успешнее решены в существующем софте KP в Ньюбурге, команда PBP тут и там изобретала велосипед, экспериментируя с разными подходами и ухищрениями, многие из которых мне казались тупиковыми с самого начала.
Мне пришлось достаточно жестко разворачивать направление работы в нужную сторону. В эджайле это контролируется через бэклог – отсортированный по приоритетности список «историй», то есть небольших задач, решение которых составляет работу команды. Предполагается, что история должна выполняться не дольше чем за один спринт – основную единицу рабочего времени в методике эджайла: как правило, это две недели. Каждой истории присваиваются «пойнты» (баллы) – целочисленная оценка сложности истории. В сумме пойнты задач, выбранных на каждый спринт, должны быть примерно одинаковыми и отражать возможности (capacity) команды в данный момент – с учетом отпусков, болезней, ухода одних сотрудников и прихода других. Присвоение пойнтов новым историям происходит во время «груминга» (подготовки) – специальных собраний всей команды, где обсуждается общий дизайн историй и их относительная сложность.
В первые месяцы нам пришлось радикально чистить прежний бэклог и «грумить» по три или по четыре раза в неделю, пока команда привыкала к новым приоритетам, алгоритмическим подходам и темпу работы. Нужно было торопиться: требования резко улучшить качество палет сыпались отовсюду, и самым критическим направлением оставалась «Кока-Кола».
Глава одиннадцатаяЯзык (программирования) и до Киева доведет
Еще весной 2016 г. Крис Гахаган на одном из общих собраний компании, разглагольствуя о ее расширении и поиске новых инженерных ресурсов, обмолвился, что в ближайшем будущем мы привлечем новые ресурсы «фром юкрейн». Он промямлил эту фразу, почти проглотил ее, по-видимому, не слишком желая в тот момент подробно останавливаться на этой теме. Кто-то все-таки з