Что такое Resolution Independence, или независимость от разрешения, если по-русски? RI — это возможность операционной системы рендерить определенные элементы интерфейса без жесткой их привязки к пиксельной сетке: пропорции этих элементов по отношению к другим элементам могут меняться при изменении разрешения. Необходимо это для того, чтобы люди с особо крупными или особо мелкими разрешениями экрана видели элементы интерфейса такого же размера, как и остальные.

Частным, наиболее востребованным, случаем RI являются масштабируемые шрифты, независящие от разрешения. Не уверен, реализован ли в какой-то операционной системе полноценный RI, но независимые от разрешения шрифты реализованы в AmigaOS еще в 1991, в Windows — в 1995… сейчас 2011 год, и независимые от разрешения шрифты не реализованы в Mac OS до сих пор.

Так в чем же проблема?

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

• Рядом у меня стоит 19-дюймовый монитор, его разрешение — 1280×1024. В прошлом все операционные системы были рассчитаны на такое соотношение сторон и физическое разрешение, которое составляет 86 DPI (точек на дюйм). Запомните это значение. При таком значение DPI во всех операционных системах можно работать, чрезмерно не напрягая зрение.
• Этот текст я пишу за 24-дюймовым монитором с разрешением 1920×1200, его физическое разрешение — 94.3 DPI. При таком разрешении физический размер текста в программах уже немного меньше, когда кегель ниже 10, глаза очень быстро устают.
• У меня есть MacBook Pro (выпущенный в конце прошлого года) с матовым экраном. Диагональ экрана ноутбука — 15.4 дюйма, а разрешение 1680×1050, то есть физическое разрешение у него получается аж 128.6 DPI. Это почти на 50% больше стандартных 86DPI, то есть текст на экране становится на 50% мельче. При таком разрешении практически во всех программах с настройками по-умолчанию человеку с нормальным зрением работать очень неудобно, человеку с плохим зрением — просто невозможно!

В результате в каждой программе мне приходится увеличивать размеры шрифтов, чтобы с компьютером можно было комфортно работать… И то удается его сменить не во всех программах. Еще хуже дело обстоит с вебом. Теоретически достаточно в броузере увеличить размер шрифтов по-умолчаниию. И действительно, на всех сайтах в интернете, где тексты заданы в относительных величинах (em, %), текст становится нормального размера… К сожалению, 80-85% всех сайтов в интернете верстают мудаки, не заботащиеся о пользователях. Они задают размеры шрифтов абсолютными величинами… В результате при высоком разрешении текст всегда очень-очень мелкий.
Но уж лучше я везде буду вручную увеличивать шрифты, чем пользоваться ноутбуком с глянцевым экраном (кстати, у глянцевого Macbook Pro физическое разрешение 108 DPI, что тоже слишком мелко, но и не катастрофично).

Прослеживается еще одна неприятная тенденция — компания Apple постепенно уменьшает диагонали экранов в своих компьютерах iMac, оставляя прежние разрешения. То есть раньше разрешение 1920×1080 было у 23-дюймовой модели, и 2560×1440 у 30-дюймовой. Теперь же такие разрешения у 21.5 и 27-дюймовых моделей соответственно. DPI первой — 102.5, второй — 108.8.

Однажды я запустил Windows 7 в виртуальной машине на своем макбуке… В настройках экрана я выбрал использование шрифтов размером 125% вместо стандартных ста… И в миг система стала показывать шрифты удобоваримого размера! Во всех приложениях, на всех веб-сайтах! То, на что в MacOS у меня уходят часы настройки, в Windows решается за считаные секунды… уже 16 лет подряд!
Меня впечатлило одно из обсуждений проблемы Resolution Independence на маке — из него видно, что многие люди покупали топовые модели Macbook Pro и iMac с высоким DPI, а потом либо возвращали их назад в магазин, либо ставили Windows вместо MacOS, потому что элементы интерфейса системы на их экранах были слишком мелкими.

Меня очень угнетает тот факт, что проблема существует уже давно, а Apple не делает никаких телодвижений чтобы решить ее: концентрируется вместо этого на простоте перехода новых пользователей с iOS на MacOS вместо того, чтобы решить проблемы старых пользователей. Для меня это послужило веской причиной дальнейшего использования т.н. Hackintosh’а на домашнем компьютере вместо покупки iMac’а.

Надеюсь, эта статья поможет людям не допустить ошибку при покупке техники Apple.

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

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

Впечатления

Итак, небольшой обзор в пунктах:

• В линейке Gunnars много разных очков (стоят от $100 до $189). Я решил не рисковать и взял самые навороченные — Halogen. Так что обзор посвящен именно им, эффект других моделей может быть немного другим. 
• Очки немного выгнутые, в них угол обзора больше, чем в обычных, изображение немного контрастней, и кажется, что они его самую малость приближают, хотя заявлено, что без диоптрий.
• Сделаны из пластика, достаточно качественного и легкого. В других моделях встречаются и металлические оправы. Веселит гордая надпись Made In China на одной из дужек.
• В этих очках иногда чувствуешь, что у тебя чуть-чуть слезятся глаза и потому моргаешь чаще обычного.
• Когда снимаешь очки — несколько секунд чувствуешь дезориентацию, экран монитора кажется выпуклым.
• В первый же день использования я почувствовал положительный эффект от очков. Вечером после работы резкость зрения у меня обычно падает, но с этими очками вечером зрение так же резко, как и днем!
• Общая усталость после работы за компьютером действительно немного меньше. Как оказалось, в этом есть и свой минус — тянет посидеть за компьютером дольше, потому что не чувствуешь естественную усталость глаз, как прежде — в результате можешь еще сильнее насиловать свой организм.
• В играх, вопреки моим ожиданиям, измененный угол обзора не помог вообще никак. В Quake Live и Battlefield BC2 я не стал лучше стрелять и не стал быстрее замечать врагов, появляющихся с края экрана. С другой стороны, меньше устаешь во время игры, особенно хорошо я прочувствовал это во время прохождения Deus Ex: Human Revolution с его 20+ часовым геймплеем.
• В комплект поставки, помимо самих очков, входят рекламные буклеты, скидочный купон и футляр для очков. Раньше давали более-менее качественный футляр, теперь же — хлипкий картонный, но и на том спасибо.
• Работать с цветом в этих очках по понятным причинам не следует, потому специально для фотографов, графических дизайнеров и.т.п. есть возможность заказать очки с не-желтыми стеклами. На сайте Gunnars, правда, сказано, что эффект от них не настолько выражен, как от желтых.
• Самое неприятное — доставка. Когда сотрудники заказывали очки в Киев — это им стоило $50. Мне, спустя несколько недель, доставка стоила уже все $60. При этом сотрудникам очки пришли крутой почтой FedEx, мне же их послали дешевеньким USPS Internarional, с которым ты даже не можешь отследить состояние посылки, когда она покидает территорию США. Я написал в Gunnars жалобу по этому поводу, они извинились и сказали, что отправка в Украину FedEx’ом за $50 была для них убыточной, потому перешли на USPS. Самое главное разочарование ждало меня, когда посылка, наконец, пришла: на посылке было четко написано, что стоимость доставки — $30, а не $60.

Выводы

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

Если будете покупать до 30 сентября 2011 — можете воспользоваться моим 15% скидочным кодом ThankU11. Очки Halogen, например, с ним будут стоить не $189, а $160.

Проблема в людях!

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

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

Такой продукт ОБРЕЧЕН! В лучшем случае, его удастся сделать, уложившись в срок, может даже в бюджет, но он никогда не станет успешным, понимаете?

Корни профанации

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

1. Ежедневное стоячее scrum-совещание всей команды на 15 минут, где все должны ответить на 3 вопроса: «что сделал», «что будешь делать?», «что препятствует выполнению твоей работы?».
2. Разбиваем процесс на итерации (обычно одинаковой продолжительности).
3. Ведем требования к проекту в виде User Stories. Вешаем их на доску, оцениваем истории в поинтах вместо часов. Может, даже играем с членами команды в planning poker.
4. В конце итерации проводим ретроспективу, чтобы послушать, кто что думает о происходящем…
5. Некоторые еще добавляют чисто инженерные практики вроде парного программирования, разработки через тесты и парного code review.

Скажите честно, вы действительно думаете, что именно в этих пяти пунктах состоит Agile и именно это нужно, чтобы продукт, который вы делаете, стал успешным?

Давайте взглянем на Agile-манифест — документ, на основе которого как раз и появились гибкие методологии разработки:

• Люди и взаимодействие важнее процессов и инструментов
• Работающий продукт важнее исчерпывающей документации
• Сотрудничество с заказчиком важнее согласования условий контракта
• Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

По-моему, очень зрелые и трезвые мысли. Обратите внимание, в манифесте вообще ничего не говорится о пяти описанных выше обрядах! Более того, в определенных ситуациях эти обряды могут быть даже противоположны тому, о чем говорится в Agile-манифесте.
Успешное выполнение проектов и создание успешных софтверных продуктов — это, в первую очередь, вопрос культуры и опыта, но никак не методологии! Гибкие методологии — это всего лишь наборы рекомендаций и техник, без соответствующей культуры они не помогут вашему проекту ровным счетом ничем!

Scrum-совещания быстро станут унылой бюрократией, если члены команды и без того регулярно делятся друг с другом информацией о своей работе и проекте, либо если члены команды просто не видят пользы в этих совещаниях. Разделение проектной работы на итерации и их четкое планирование вряд ли даст какой-то ощутимый выхлоп, если работа над проектом состоит, в основном, в исправлении багов и вялой поддержке пользователей. Planning Poker вряд ли принесет хоть какую-то пользу, если команда состоит из одного разработчика, одного тестировщика и одного дизайнера, каждый из которых слабо разбирается в работе коллег. Code Review и TDD для одноразовых проектов (рассчитанных, например, чтобы один раз показать где-то на презентации и все) скорее помогут вам успешно просрать бюджет, чем сделать продукт лучше для целевой аудитории.

Работать надо не «чтобы было Agile», а с умом! Управление проектами — это не про методологии, это про людей, про их цели и ожидания, про их коммуникацию, про их мотивацию!

Что же нужно для гибкого процесса разработки?

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

• Четкое понимание бизнеса, для которого делаются продукты: понимание целевой аудитории продуктов, которые ты делаешь. Эти знания должны быть, как минимум, у лидеров проектной команды и заказчика проекта, а в идеале — у всех участвующих в процессе людей.
• Профессионализм проектной команды. Если у нас есть несколько талантливых опытных разработчиков, дизайнер, QA и менеджер — этого еще не достаточно, чтобы считать команду профессиональной, нужно еще многое… Умение всех этих людей работать над общей целью, отлично осознавая, как делается работа коллег в смежных областях. Понимание того, как следует себя вести, если что-то пошло не так, как планировалось, и нужно резко менять курс, импровизировать. Иногда необходимо браться за откровенно неинтересную работу.
• Профессионализм заказчика продукта (в случае работы над собственным продуктом это может быть сама проектная команда). Заключается он в том самом понимании бизнеса, умении адаптироваться к изменениям рынка, прислушиваться к мнению команды, умению вовремя распознать в команде проекта инвалидов и послать их подальше.
• Достаточная смелость, чтобы вовремя признать свои ошибки и донести их до остальных участников проекта, а не стараться тянуть до последнего или вообще скрыть свои ошибки. Опять же касается это всех людей, вовлеченных в проект.
• Мотивация, конечно же! Если участники проекта по какой-то причине не хотят заниматься тем, чем занимаются — ничего хорошего из этого не выйдет, сила воли безграничной не бывает.

Если вам есть, что сюда добавить — отметьтесь в комментариях к статье.

На прощание

Нужно думать головой, а не пытаться следовать методологиям как религиям. Если людям не интересен проект, над которым они работают, а лидеры проекта не понимают, чего хотят — то проблема именно в людях, а не в «неправильной» методологии. Даже если будешь проводить стэндап-митинги, ретроспективы и играть в planning poker — проект всеравно сдохнет!
Работать с умом гораздо сложнее тупого следования набору формальных обрядов, но это единственный надежный способ делать качественные программные продукты в рамках разумных сроков и бюджетов.

Однажды ко мне в гости зашел приятель и спросил, чем я обычно занимаюсь по работе. Я просто открыл Remember The Milk и показал ему список выполненных задач.

Remember The Milk — это очень гибкое и удобное веб-приложение для работы со списками задач, не навязывающее каких-то жестких правил работы. Благодаря этому RTM можно использовать просто как линейный список задач(вроде списка покупок в магазине), но можно реализовать на его основе свою мощную GTD-систему. Причем, реализации у разных людей получаются иногда совершенно непохожими.

RTM существует уже 4 или 5 лет, и я пользуюсь им почти с самого старта проекта. За это время я перепробовал десятки разных GTD-планировщиков, но всякий раз возвращался назад к RTM — ни одно другое средство не было для меня столь же удобным.

Организация списков задач и поиск по ним

В Remember The Milk у меня существует несколько списков задач: 4 базовых и 2-3 smart-list’а (о них позже). Для начала давайте поговорим о базовых списках:

• Inbox — по-умолчанию все новые задачи попадают именно в этот список, по сути он является дампом памяти. Появилась какая-то идея, задача или важная мысль — бросаешь ее в inbox, чтобы не забыть.
• Actions — самый важный список. В нем находятся задачи на ближайшие несколько дней. Большинство задач в нем либо нужны очень срочно, либо очень важны для меня, либо и то и другое. В списке Actions нет смысла держать больше задач, чем можешь успеть до конца недели, потому у меня в нем обычно не более 15-20 задач (одни задачи решаются, другие приходят из остальных трех списков).
• Someday — если задачи не очень важны в данный момент или не очень срочны, но о них все еще важно не забывать — они попадают именно в список Someday. Например, «слетать на неделю в Сирию и Ливан» или «Почитать книгу «Внутри торнадо» Джефри Мурра».
• Waiting — особый список для задач, выполнить которые я не могу сейчас по независящим от меня причинам, но смогу потом: типичный пример такой задачи — «Купить книгу «The Four Steps to the Epiphany» в электронном виде, когда она появится в Amazon Kindle Store».

Помимо самого текста к любой задаче в RTM можно добавить много полезной мета-информации:

• Приоритет (всего 3)
• Метки
• Deadline
• Продолжительность
• URL
• График повторений
• Набор текстовых заметок.

Метки — пожалуй, единственный из атрибутов, который я использую всегда (кроме inbox’а: вы же помните, что он служит просто разгрузкой для мозга?). С помощью меток я разделяю задачи на контексты и проекты. Просто определил для себя, что теги начинающиеся с «p-» — это проекты, а теги начинающиеся с «@» — контексты, например:

• @computer — контекст для задач, которые мне нужно выполнить за компьютером.
• @reading — контекст для напоминаний о том, что я хочу что-то прочитать.
• @writing — аналогично, контекст для идей тех или иных статей
• @adility — задачи, связанные с компанией, где я работаю
• @travel — идеи будущих путешествий, задачи по подготовке путешествий и.т.п.

В дальнейшем в один клик можно увидеть списки задач по определенным контекстам, проектам, приоритетам и.т.п. Результаты поиска можно сохранить и использовать заново в дальнейшем: это и есть т.н. smart lists — мощнейшая функция RTM.

Не знаю как вам, но мне тяжеловато оперировать большими списками задач, кроме того, я стараюсь работать сфокусированно, не отвлекаясь на ерунду: во время работы не хочу, скажем, видеть задачи, связанные с путешествиями или чтением литературы и.т.п., дома же я не хочу обращать внимание на рабочие задачи (трудоголизм до добра не доводит). В результате я просто создал 2 smart-листа на основе текущих задач в Actions:

• Work — невыполненные задачи из списка Actions с тегом @adility. Многие задачи в этот список у меня попадают, даже минуя inbox, потому что они появились сегодня, и выполнить их нужно тоже сегодня. Экспериментально я обнаружил: если в списке больше 10 задач — явно я что-то делаю не так, слишком оптимистично.
• Misc — невыполненные задачи из списка Action с любыми тегами кроме @adility.

Ежедневная работа со списками

Первое что важно запомнить — чтобы система была системой, а не просто набором слабо связанных задач, ее нужно регулярно поддерживать в актуальном состоянии.
Каждый день я просматриваю список задач в inbox, проставляю им необходимые теги, дедлайны, заметки и переношу их из inbox’а либо в Actions, либо в Someday, изредка в Waiting. Каждый день я расставляю приоритеты задачам в Actions. Задачи с высоким приоритетом почти всегда выполняю в тот же день. Стараюсь разбирать задачи пораньше, в течение часа после того как проснусь. Ежедневно на это уходит всего 5 минут.

Кроме того, раз в неделю, по воскресеньям, я просматриваю весь список задач в Waiting и Someday:

• Отбираю самые важные задачи на следующую неделю.
• Проверяю, можно ли уже приступать к выполнению задач из Waiting.
• Вспоминаю, чем вообще собирался заниматься, какие у меня были идеи.
• Убираю потерявшие актуальность задачи: часть из них оказывается бесполезной или слишком неинтересной, часть задач я выполняю, мимоходом забыв о всяких там GTD.

Я не живу по строжайшему расписанию и не делаю всегда то что нужно вместо того что хочется — у меня для этого сила воли не та, тем не менее, GTD помогает эффективно расходовать свое время и не забывать ни о чем важном (главное — не забыть записать в RTM). Но когда у меня появляется свободное время — стараюсь избегать прокрастинации и делать что-то полезное, что соответствует настроению, состоянию. Сегодня вечером, например, я собирался устроить занятие музыкой (учусь играть на гитаре) и почитать книгу, но почувствовал, что читать лень и пальцы болят еще с прошлого занятия, а вот написать что-то, что давно собирался, готов… Заглянул в список задач с тегом @writing — и сел писать эту статью. Все просто.

Почему Remember The Milk лучше чем другие?

Большую часть того, что я описал, можно выполнить и в других GTD-инструментах. Почему же я использую именно Remember The Milk и чем он лучше других?

1. Это веб-приложение. Соответственно, не нужно никакой специальной синхронизации для работы с ним с нескольких компьютеров или мобильных устройств, не нужно думать о бекапах и сохранности данных. Раньше с RTM можно было работать даже в оффлайне благодаря технологии Google Gears. К сожалению, Google эту технологию прикрыла в пользу HTML5 local storage, а на последнюю RTM еще не перешли.
2. Smart Lists — о них достаточно написал выше. Подобной штуки не встречал больше нигде.
3. Эффективная работа с клавиатурой. Поразительно, но почти все task-manager’ы построены по принципу «ткнул мышкой, ввел задачу, ткнул мышкой еще 3-4 раза в разные места интерфейса, чтобы настроить параметры задачи». Это же чертовски долго, особенно, для приложения, которое должно разгружать мозг… Иногда во время всяких совещаний я добавляю (а позже уточняю и приоретизирую) более десятка разных задач — и все это занимает считанные секунды, благодаря клавиатурным сокращениям и.т.д. Интерфейс, рассчитанный только на работу мышью/тачпадом сжирает больше времени на наведение курсора и клики мышью, чем на запись самой задачи. Только не подумайте, что RTM — сугубо для клавиатурных гиков, все действия в нем можно проводить и мышкой, как в остальных аналогичных инструментах, но с клавиатуры это можно делать намного быстрее!
4. Гибкость. Другие инструменты навязывают вам свой унифицированный процесс. Это удобно на первых порах, но лишает дополнительных удобств. С RTM же я сначала придумал процесс, затем реализовал его в RTM… и потом еще долгое время адаптировал под свои нужды, когда решал, что так будет удобнее.

В следующий раз могу поделиться готовыми рецептами использования Remember The Milk.

Со временем стало ясно: интересующие меня темы востребованы сильнее чем прежде, более-менее глубоких статей о них в рунете катастрофически мало, аудитория блога почти не уменьшилась за годы бездействия, а знакомые все так же настырно просят написать статьи на ту или иную тему.
Теперь, после некоторых изменений в моей жизни, могу и хочу снова заниматься этим сайтом: у меня вновь достаточно мотивации, сил и времени. Главная тематика сайта остается прежней: интернет, управление проектами и работа с людьми, технологии, лайфхаки и самосовершенствование, MacOS и продукция Apple. Разве что, теперь хочется больше писать об интернете и способах повышения качества жизни, меньше о технологиях.

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

Хотите сделать сайт лучше? Расскажите, какие из тем блога наиболее интересным вам!

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

• «Гибкая разработка веб-приложений в среде Rails» — лучшая книга для любого Rails-разработчика» — бред собачий! Это книга «для чайников», не отражающая реалий rails-разработки.
• «Rails — это вещь в себе» — еще больший бред. Rails, вообще-то, обладает мощной инфраструктурой, включающей множество сторонних сервисов и библиотек.

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

Развертывание приложения

В Ruby есть очень мощный инструмент для работы с удаленными unix-серверами — Capistrano. Он же является стандартом де-факто для развертывания рельсов на production/staging серверах.

Принцип работы Capistrano в контексте рельсов простой — разработчик с локальной машины запускает capistrano, который в свою очередь подсоединяется к удаленному серверу через SSH и выполняет ряд команд: вытягивает свежую версию приложения из репозитория, создает для нее отдельную директорию и устанавливает символические ссылки для директорий со статическим контентом, перегружает веб-сервер и другие сервера (например, сервер для полнотекстовой индексации и поиска данных). Большим плюсом Capistrano в сравнении с аналогичными инструментами является поддержка rollback'ов. То есть в случае неудачного развертывания проекта Capistrano откатит все в исходное состояние.

Выше описан простейший пример работы Capistrano, который обычно выполняется с помощью его стандартных рецептов (скриптов). Вообще же с помощью капистрано можно можно разворачивать приложения в нескольких окружениях, можно разворачивать приложения сразу на кластерах серверов, можно на этих кластерах удаленно чистить кеш и вообще выполнять любые команды, которые можно выполнить в консоли unix-сервера. Существуют отдельные наборы рецептов капистрано, например capistrano-ext, Dump или rubaidhstrano, позволяющие автоматизировать резервное копирование баз данных и синхронизировать статические файлы (как и базы данных) в локальном окружении разработчика с production'ом.

Кстати, capistrano совсем не обязательно использовать с рельсами, впервые я с ним столкнулся полтора года назад, тогда с помощью Capistrano мы разворачивали PHP(symfony)-приложения на кластерах серверов.

Нет предела совершенству. В след за Capistrano появились проекты Shadow Puppet и Moonshine. Shadow Puppet — это инструмент для автоматизации настройки самих unix-серверов, с его помощью можно автоматизировать установку всего софта, библиотек, создание пользователей, настройки безопасности — очень полезный инструмент системного администратора. Moonshine представляет собо надстройку над Capistrano и Shadow puppet, позволяющую автоматически настроить «голый» удаленный сервер и развернуть на нем Rails-приложение, имея на удаленном сервере всего лишь пользователя с sudo-правами. К сожалению, в настоящий момент Moonshine поддерживает только Ubuntu Server 8.10 и Git-репозитории.

Существует альтернатива Capistrano — Vlad the Deployer, он проще в использовании, но на фоне Capistrano функционал Влада кажется скудным.

Профилирование, мониторинг производительности, слежение за ошибками

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

Задачу профилирования и мониторинга производительности решают такие сервисы, как Five Runs, New Relic и Scout. Функциональность у всех трех похожа, потому расскажу о таких средствах на примере NewRelic'а, являющегося лидером тройки.

Когда приложение развернуто в production-окружении, начинает работать специальный rails-плагин NewRelic RPM. Он собирает информацию о каждом запросе к приложению, о каждом запросе к базе данных, времени выполнения этих запросов (и, соответственно, времени загрузки страниц), нагрузке на процессор, вызванной этими запросами. Время от времени эти данные отправляются на сервер NewRelic фоновым процессом. После этого на сайте NewRelic'а можно посмотреть множество отчетов, показывающих, например, самые медленные контроллеры, самые медленные SQL-запросы и отдельные транзакции, причем, легко можно посмотреть использование индексов в запросах. Кроме того, NewRelic хранит статистику, потому можно отслеживать динамику нагрузок, удобно сгруппированные отчеты об ошибках (мы же не хотим читать длинные логи?) и многое другое.

Естественно, можно использовать NewRelic и в development-окружении, в этом случае он является больше инструментом профилирования, нежели мониторинга и статистики.

Для тех, кому не нужна настолько подробная (и дорогая) статистика, которую дает NewRelic, но нужно удобно отслеживать ошибки, происходящие на production-серверах, есть простой сервис — HopToad. Можно, конечно, для этой цели пользоваться rails-плагином с говорящим именем «Exception Notifier», но он может в определенных ситуациях может неприятно заспамить ваш почтовый ящик.

Тестирование, проверка качества кода

Честно говоря, автоматическое тестирование — один из моих любимых аспектов Rails, такое обилие разнообразных крутых инструментов тестирования я видел, пожалуй, только в Java.

По умолчанию рельсы используют стандартный рубишный Test::Unit в качестве тест-фреймворка. Однако, в последнее время все более модным становится т.н. Behavior Driven Development, и в руби появился свой BDD-фреймворк — RSpec, который плотно интегрируется с рельсами. Судя по коду разных современных проектов, RSpec в ruby-мире сейчас даже более популярен, чем Test::Unit.

В RSpec входит собственное средство для создания mock-объектов (необходимых, например, при тестировании контроллеров), однако вместо него можно использовать более развитые Mocha и Flex Mock.

С целью минимизации времени, затрачиваемого на рутинное написание тестов, был разработан Shoulda — набор макросов для совместного использования Rails и Test::Unit. Посмотрите, насколько более простым и читабельным он делает код тестов.
Специально для людей, предпочитающих RSpec был выпущен аналог Shoulda под названием Remarkable.

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

Хотите «настоящего» BDD, чтобы можно было описывать требования к будущему функционалу простым языком и в итоге превращать их в функциональные/интеграционные тесты? — попробуйте Cucumber.
Если вам, как и мне, Cucumber кажется излишеством, существует другой мощный инструмент — WebRat. Задача «крысы» — интеграционное тестирование, то есть пройтись по страницам сайта, прокликать формы, убедиться в том, что сервер вернул ожидаемый результат. Сценарии WebRat писать очень просто и он интегрируется с любыми тест-фреймворками для Ruby. В обычном режиме работы WebRat'у даже не нужен броузер для прогона тестов. Однако бывают ситуации, когда нам необходимо тестировать операции, выполняемые JavaScript'ом, в этом случае WebRat можно запустить в другом режиме работы: он будет использовать Selenium(который, в свою очередь, использует броузер) для прогона тестов. Поддерживать же подобные webrat-тесты ощутимо проще, чем чистые Selenium-тесты.

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

Непрерывная интеграция

При работе над масштабным проектом, или просто в случае распределенной разработки часто возникают проблемы из серии «Петя, после твоего коммита опять сломался билд, срочно чини!» или более характерное для славянских программистов «Ебаный в рот! Кто сломал билд?». Одним из очевидных спобов решения таких проблем является «непрерывная интеграция». Для Ruby в целом и рельсов в частности существует своя версия известного CI-средства — CruiseControl.rb.
Существует также альтернатива — Integrity, но ее я ни разу не пробовал.

Сервера приложений

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

Лучшим решением запуска rails-приложений является Phusion Passenger (также известный как mod_rack и mod_rails). Passenger встраивается модулем в веб-серверы Apache и Nginx и динамически выделяет ресурсы рельсам, подобно mod_wsgi для python и mod_php для PHP. Естественно, это позволяет экономнее расходовать ресурсы сервера и упрощает развертывание приложений.

Для полноты картины стоит отметить Thin. Это сервер, работающий аналогично Mongrel'у, но быстрее и потребляя при этом меньше ресурсов.

Асинхронное выполнение задач

Существует ряд задач, которые выполняются сравнительно долго, например, конвертация видео или загрузка файлов на Amazon S3. Такие задачи желательно (а во многих случаях — обязательно) выполнять в фоне. Долгое время наиболее распространенным инструментом асинхронного выполнения задач в рельсах был BackgroundRB, однако brb потребляет неприлично-много ресурсов, потому рекомендую альтернативный инструмент — Workling.

По умолчанию Workling работает в паре с message queue сервером Starling, разработаным изначально для Twitter'а, однако не советую использовать Starling в production'е. Вместо старлинга можно использовать любой amqp-совместимый сервер, например, RabbitMQ или ActiveMQ.

Мониторинг процессов

Одним из главных недостатков Ruby являются утечки памяти. В Ruby Enterprise Edition и Ruby 1.9 эту проблему частично решили. Но в суровые времена, когда все гоняли рельсы сугубо на Mongrel'ах и Ruby 1.8.6, проблема стояла значительно серьезнее, чем сейчас, потому необходимым было средство, которое следило бы за процессами Mongrel'а и перегружало его при достижении лимита потребляемой памяти. Чаще всего для этих целей использовали совсем не рубишный Monit и его Ruby-аналог — God (который, на мой взгляд, значительно удобней и гибче в конфигурации). Доходило даже до того, что все процессы мониторили God'ом, а сам God — Monit'ом.

К счастью, ситуация стала лучше, но God и Monit (который использовался и используется для мониторинга баз данных, веб-серверов и многих других вещей в unix-системах) все еще остаются простыми и удобными средствами мониторинга процессов, сфера применения которых выходит далеко за рамки перегрузки Mongrel'а при достижении лимита памяти.

Запуск консольных команд

Давно уже для Ruby разработали Rake — инструмент для автоматизации сборки программного кода по типу GNU Make или Apache ANT. Но, в отличие от Make и ANT, Rake-скрипты пишутся на самом Ruby, что сделало их легко расширяемыми и более удобными в написании. В итоге в Rails стали использовать Rake для выполнениях любых консольных команд, например, для запуска тестов, миграций или обновления Rails.

Также существуют дополнительные наборы Rake-задач, выполняющие рутинные операции, например: создание резервных копий базы данных и статических файлов rails-приложения, отображение информации о внешних ключах в базе данных, для которых нет индексов, и многие другие. Отличные примеры дополнительных rake-задач для Rails — limerick_rake и dump.

Визуализация объектной модели

В данном случае лучше один раз увидеть. RailRoad рисует диаграммы объектной модели ваших Rails-приложений. Посмотрите примеры моделей и контроллеров.

Специализированый хостинг

Большинство коммерческих Rails-проектов хостятся на VPS'ах, выделенных серверах и cloud-хостингах вроде Amazon EC2. Однако существуют и специализированные Rails-хостинги (большая их часть — это все те же VPS'ы и надстройки над EC2, куда уже установлены популярные ruby/rails библиотеки, apache с passenger'ом и.т.п.).

• Heroku
• Engineyard
• Rails Machine
• Brightbox

Среды разработки

Существует стереотип, будто все rails-разработчики используют для разработки либо TextMate на маке, либо юниксовые vim/emacs/gedit, и для Ruby/Rails нет «взрослых» IDE.

Отчасти это правда, действительно подавляющее большинство Rails-разработчиков не пользуются IDE, но далеко не все! Качественные IDE для Ruby существуют: Aptana RadRails на основе Eclipse, JetBrains RubyMine на основе IntelliJ Idea, NetBeans (который мне не удалось запустить на маке). Лично я предпочитаю RubyMine за его отслеживание ошибок в коде, автодополнение, удобный поиск внутри проекта, отладку кода прямо в IDE и автоматизацию рефакторинга.

В целом, как мне кажется, ситуация с IDE для Ruby хуже чем у Java и .NET, но лучше, чем у Python и PHP.

Вместо заключения

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

Статья написана для сайта developers.org.ua

1. Управление проектами — это работа с людьми. Умение завоевать уважение команды и клиентов в тыщу раз важнее умения рисовать диаграммы Ганта. Ни в коем случае не поддавайся рассказам всяких менеджеров-теоретиков, считающих PMBOK важнейшей книгой для управленца: эти клоуны могут долго рассуждать о преимуществах и недостатках методологий RUP, CRYSTAL или XP, но понятия не имеют, что делать, если разработчик длительное время работал с нормальной эффективностью, а потом резко «опустился», они не чувствуют, когда стоит делегировать полномочия, а когда этого делать нельзя.
2. Постоянно учись, читай, постоянно экспериментируй, постоянно сомневайся в себе, совершай ошибки и исправляй их последствия. Ошибок не допускает только тот, кто топчется на месте. Да, постоянные изменения и нескончаемое обучение означают постоянный стресс — и с этим ничего не удастся поделать, но со временем начинаешь спокойнее относиться к собственным ошибкам и неудачам, легче переносить стресс.
3. Бери на работу только тех людей, которые эту работу обожают: тех, кто с гордостью рассказывают о своих заслугах, интересуются твоей компанией, следят за новинками в отрасли. Если этого не соблюдать — легко получишь обыкновенный ленивый офисный планктон, который работает «из-под палки», самостоятельно не обучается и довольно медленно растет в профессиональном плане. Людей, которые в целом любят свою работу, и мотивировать гораздо проще, и работать с ними интереснее. Тебе не нужен сисадмин, мечтающий заниматься журналистикой, или разработчик, который на самом деле хочет быть дизайнером, а код писать ненавидит и каждый раз «переступает через себя», чтобы выполнить новую задачу. Тебе нужны такие люди, которых сам будешь выгонять из офиса, чтобы не просидели до ночи, изучая новую технологию. На эту тему немало эссе написал Джоэль Спольски.
4. Учись отступать и проигрывать. Очень важно уметь вовремя остановить провальный проект. Иногда необходимо отказаться от проекта, иногда — даже уволиться. Запятнанную репутацию нелегко «отбелить». Как ни крути, а у жизни тоже есть свой дедлайн, потому не инвестируй временной ресурс своей жизни в мертворожденные проекты, эти инвестиции не окупятся.
5. Хочешь выстроить четкую систему в работе, наладить процессы, чтобы все было четко и без сюрпризов? Начни с себя: без жесткого контроля собственного времени никак не обойтись. GTD — не только модный акроним, но и реально полезная методология, которая при грамотном обращении поможет убивать в себе оптимизм и не забывать ничего важного. Учись мгновенно принимать правильные решения, много решений... Если не выходит — устанавливай дедлайн принятия решения: и руководство/клиенты, и подчиненные будут тебе за это благодарны.

Интересно, как я буду смотреть на эти советы через 5 лет?

Встречаются как-то два психолога. Первый начинает разговор за жизнь:
— Я себе недавно купил навороченный Феррари...
А второй сначала косо смотрит на первого, а потом и говорит:
— Слушай, мы же все-таки профессионалы. Давай просто расстегнем брюки и померяемся!

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

Знаете, это реальная проблема на территориях пост-совка: к сайту компании у нас принято относиться не как к инструменту зарабатывания денег, но как к красивым картинкам и просто фактору престижа. Такой сайт приятно показать друзьям, коллегам, клиентам, жене, в конце концов... но стоит ли он вложенных средств? Да, сайты в экс-СССР стоят очень дорого, как для стран 3-го мира: совершенно реальна ситуация, когда компании, торгующие, например, сантехникой, платят за разработку сайта в Киеве или Москве дороже, чем их коллеги в Нью Йорке или Сан Франциско. Уверен, вы сразу подумали о Студии Лебедева, но на самом деле я имею в виду не только ее, а множество компаний. Кроме того, за рубежом САЛ знают, в основном, как компанию, занимающуюся промышленным дизайном, а не сайтами... Ну, не привыкли там платить за дизайн больше, чем он может принести. Как вы думаете, многие ли компании в России и Украине думают о том, какой ROI будет у их сайта: как быстро сайт окупится и окупится ли вообще?

При таких высоких ценах сайты ухитряются делать с отвратительного качества CMS'ками, подчас слабее бесплатных Joomla и Drupal, а часто выбирают и просто отвратительный Bitrix...

В интернете можно найти минимальные цены ведущих веб-студий России за 2006 год, как вы понимаете, сейчас эти цены повысились.
А что делать? Ведь нужно платить дизайнерам, которые сделают эксклюзивный дизайн (возможно, и несколько макетов на выбор)... Скорее всего, макет еще придется дорабатывать — и утверждение макета может растянуться надолго... И все это время нужно платить менеджерам, потом верстальщикам надо сверстать макет, еще позже макет нужно будет прицепить к CMS'ке, вполне возможно, что эту самую CMS'ку придется под конкретный сайт доделывать. В общем, не с потолка цены берутся...

Но задумывались ли вы когда-нибудь, что будет, если отказаться от эксклюзивности — если не придется разрабатывать новые макеты дизайна, не придется вносить в них правки и не придется утверждать дизайн, не придется верстать его и не придется подключать сверстанный дизайн к CMS, не придется доделывать эту самую CMS?

Что будет, если подстроить свое видение веб-сайта под уже сложившиеся стандарты? Чем же плохо использование чужого дизайна или просто шаблонного, проданного десятку разных клиентов? А ничем, по большому счету, это не плохо, кроме того, что вы лишитесь понт-фактора. Но подумайте хорошенько, важен ли он для бизнеса?

Представьте себе ситуацию: жители соседних деревень Виларибо и Вилабаджо открыли магазины авто-запчастей — с одинаковым ассортиментом, ценами и уровнем обслуживания. Вскоре оказалось: через интернет можно привлечь много новых клиентов. Деревня Виларибо обратилась в солидную студию веб-дизайна, где им за 100 наноюнитов в два месяца сделали сайт под ключ с эксклюзивным дизайном. По прикидкам жителей Виларибо, затраты на сайт должны окупиться через 12 месяцев. Жители деревни Вилабаджо быстро отреагировали: они пришли в студию поскромнее и заявили: «Пожалуйста, возьмите сайт магазина «Виларибо», измените название на «Вилабаджо», поставьте наш контент и все настройте». Через месяц всего за 25 наноюнитов владельцы авто-магазина «Вилабаджо» получили свой сайт — такой же, как у «Виларибо»...
Прошло полгода... В деревне Вилабаджо праздник — ведь их веб-сайт уже окупился и теперь стабильно приносит прибыль... А жители деревни Виларибо все еще «в минусе».

Конечно, такой подход подойдет далеко не всем: дорогие бутики, студии дизайна, многие банки и страховые компании — у них у всех бизнес зависит от понтов (или престижа, кому как больше нравится), потому им необходим эксклюзив, точно так же и для промо-сайтов нужен эксклюзив, но я имею в виду «сайты-визитки». Но ведь большинству представителей мелкого и среднего бизнеса разработка эксклюзивного сайта в надежной веб-студии просто «не по зубам».

Некоторым кажется, будто шаблонный дизайн хуже эксклюзивного — это фикция: качество и эксклюзивность дизайна никак между собой не связаны. Например, на сайтах большинства софтверных компаний дизайн откровенно убогий, но он эксклюзивен! Более того, в серийных продуктах гораздо проще поддерживать качество на высоком уровне, чем в штучных: отличным примером этого служит McDonalds. В Макдональдс используют шаблонный конвейерный метод, в большинстве ресторанов — эксклюзивный. При этом еда в Макдональдс приготовлена качественнее, чем в большинстве ресторанов. Серьезно! — Она не изыскана, она не красива, она вредна для здоровья, но приготовлена качественно — в точнейшем соответствии с рецептурой, одинаково качественно для каждого посетителя, потому что за ней стоит настолько отточенная система, какую ни один ресторан не сможет обеспечить. McDonalds и прочие фастфуды не уничтожили ресторанный бизнес, но четко заняли свою нишу: в дешевых фастфудах питается гораздо больше людей, чем в дорогих ресторанах. Точно так же постепенно произойдет и с разработкой веб-сайтов: эксклюзив останется только для тех, кому это нужно и кто способен за это платить. Делать все сайты-визитки эксклюзивными — не естественнее, чем увидеть всех женщин на улицах в одежде от кутюр.

Конечно, дизайнеры не захотят со мной согласиться — ведь их основная работа состоит в том, чтобы производить эксклюзивный дизайн... Трудно признаться себе, что ты делаешь нечто переоцененное и ненужное... Мне кажется, сейчас отрасль находится на своем пике и года через 2-3 начнет двигаться в сторону упрощения и удешевления. В первую очередь, от этого пострадают дизайнеры, которых просто окажется слишком много — конкуренция на рынке повысится, а зарплаты, соответственно, снизятся.

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

Успешно прошли

• LiveDev — интересный и приятный русскоязычный блог о веб-разработке, в том числе на Django. Побольше бы таких сайтов в рунете!
• Психологический журнал «Искусство быть собой» — за последние год-два я еще не встречал настолько качественного сайта о саморазвитии и «популярной» психологии. В отличии от большинства подобных сайтов радует авторский контент и отсутствие «тупых понтов» у автора. Надеюсь, Олег Сатов, автор сайта, и дальше будет продолжать в том же духе.
• Антикорпоратив.ру — сайт о бизнесе, корпоративной среде (вернее, о ее вреде), «лайфхаках». Наиболее полезен работникам больших бездушных компаний.
• Управление проектами в картинках — интересный менеджерский блог, о нем я уже писал в прошый раз.
• 4 конверта — блог о финансовом самоконтроле. Все сказано в названии. Интересный проект Макса Крайнова, недавно отделившийся от его основного сайта.
• ContraMarketing — толковый блог с наблюдениями бывшего маркетолога. Искренний и циничный.

Не прошли карантин

• SitePoint — крупное сообщество посвященное веб-разработке, управлениию небольшими интернет-проектами, маркетинге и дизайне в интернете. К сожалению, окончательно скурвился: минимум практических материалов.
• LUK!Around — блог о путешествиях. Испортился: вместо блога о путешествиях превратился в блог о Берлине, где в каждом новом посте содержится совсем немного информации — складывается впечатление, что автору не о чем писать, потому он так поступает. Странно, что совпало это с активной рекламой у Давыдова. Надеюсь, в будущем сайт снова наберет обороты.

Временно в карантине

• Иван Пирог в режиме онлайн — недавно открывшийся блог Ивана, организатора семинаров Exception. Он обещает писать статьи на темы самосовершенствования и самомотивации, IT-бизнеса. Пока что на сайте всего 3 статьи, но довольно познавательные. Уверен, сайт и дальше будет радовать качественным авторским контентом.
• Agile-сообщество Беларуси — с одной стороны интересный сайт про agile-методологии. С другой — пока не могу понять, стоят ли его статьи затрачиваемого на чтение времени.
• AGOGE — сообщество сильных. Блог с дурацким названием о личностном развитии современного человека. Пока не понятно, насколько он самобытен, время покажет.
• David Cramer — интересный и полезный с практической точки зрения блог python-разработчика. Много информации о фреймворке Django и шаблонизаторе Jinja.
• Mac OS от Винтика и Шпунтика — простой и забавный сайт о MacOS и софте для нее.
• Пепелсбей.net — сайт о верстке с приятным дизайном. Негатива не вызывает, но статей на сайте пока слишком мало чтобы сформировать окончательное мнение.
• Подлипенский Павел — Блог о технологиях и деньгах. В название все сказано. Молодой и интересный сайт об IT-бизнесе. Рекомендую!
• MediaRevolutiuon — добротный русский сайт о маркетинге в средствах интернет-медиа. Радует обилие статистики вроде «Мужчины в возрасте 18-34 лет — наиболее активные зрители видеоконтента в Сети, 74% опрошенных заявили, что смотрят онлайновое видео по меньшей мере раз в неделю. Треть опрошенных мужчин в возрасте 18-24 лет смотрят онлайновое видео каждый день.».

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

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

1. Пожалуй, самое главное, что удалось сделать — разделить один большой проект на целый пакет мелких и средних проектов, таким образом, каждая рабочая группа, состоящая из 2-5 человек, стала заниматься одним и только одним проектом. 
2. Вместе с разделением крупного проекта на мелкие изменилась и стратегия коммуникаций. Теперь команды разработки и их тимлиды регулярно взаимодействовали лишь с техническими руководителями в США, решая тактические вопросы и согласовывая API, а с локальными руководителями проектов вывяли текущие проблемы. В свою очередь, руководители проектов общались между собой и с высшим руководством сугубо о вопросах стратегии, рисков, интеграции проектов и изменения состава групп, а технические руководители между собой решали сложные архитектурные вопросы, утверждали API и следили за документированием технических решений. Отойдя от формальностей, можно сказать — главной задачей руководителей проектов и технических руководителей стало устранение преград на пути своих команд и интеграция проектов, но никак не отчетность. 
3. Часть команд стали проводить регулярные стоячие совещания, что было простым и дешевым способом для участников проекта «находиться на одной волне» и выявлять реальные и потенциальные проблемы своевременно. Без разделения «1 проект — 1 команда» это было бы невозможно.
4. Длину итераций увеличили с одной до двух недель и стали планировать их так, чтобы в конце всегда оставался запас в пару дней. Это частично позволило избавиться от постоянной гонки, в которой все чувствуют себя проигравшими — когда работаешь в нормальном ритме, то и ошибок допускаешь меньше.
5. Оценки сроков и планы перестали «спускаться сверху»: теперь оценки сроков задач проводилась их непосредственными исполнителями под присмотром тимлидов, после чего согласовывалась с руководителем проекта и техническим руководителем, которые, как правило, срок увеличивали, учитывая дополнительные риски и сложности.
6. Стали использовать средства Continuous Integration. Полноценного TDD у нас все равно не получилось, но удалось заставить разработчиков тестировать свой код и более-менее стабилизировать качество билдов продукта.
7. Ввели т.н. «development blogs», куда разработчики (реально — тимлиды) должны были каждый день записывать свои достижения и проблемы, с которыми они столкнулись. Эти блоги на некоторое время стали главным средством коммуникации удаленных команд (ведь они находились в разных офисах), кроме того, это заставляло разработчиков писать! Впрочем, когда объем взаимодействия между разными командами уменьшился, от блогов мы отказались для большинства проектов. 
8. Постепенно мы разработали различные автоматические средства отчетности и оценки сроков (используя идеи evidence based scheduling Джоэля Спольски), реализовав их как Jira plug-ins. Но постепенно отказались и от ежедневной формальной отчетности. Вести ее можно было разве что по собственному желанию, чтобы лучше ощущать «пульс проекта». Руководитель проекта теперь отвечал строго за успешное окончание каждой итерации, а не за успешное бумагомарание. 
9. Стали проводить ретроспективы (к сожалению, они проводились между руководством разных проектов без участия разработчиков) в конце итераций. Это не произвело чуда, но помогло увидеть проблемы с разных точек зрения и, конечно же, не наступать на одни и те же грабли дважды.
10. Ввели еженедельную оценку оффшорных команд людьми из главного офиса в США, где каждый мог по пятибалльной шкале оценить уровень коммуникации, качества кода и адекватного восприятия документации. Локальные руководители проектов получали информацию и видели, кто какую оценку поставил. Многим поначалу казалось, что это сделано с целью найти козлов отпущения и показать «вот мы тут белые-пушистые, а они там за океаном бездельники и мудаки». На самом же деле, все эти оценки позволяли увидеть, кто конкретно не доволен взаимодействием, после чего не гадать — а связаться с этим человеком и узнать, чем именно он не доволен и совместно с ним улучшить рабочий процесс. Медленно, но уверенно все это получилось. Как всегда в распределенной разработке, главная трудность — коммуникация, а самый трудно контролируемый фактор — фактор человеческий.

Выводы

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

А вы масштабировали agile-процесс? Если да, то как?