Разработка веб проекта после запуска (Agile 2.0)

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

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

Вот поэтому от того, насколько вы позаботились о "наблюдаемости" вашей системы заранее, во многом зависит ваш успех, и то, как быстро вы займете нишу со своим продуктом. Более того, пользователи, которые привыкли к тому что изменения в систему привносятся медленно, увидев исправленную проблему через 15 минут после того как они сообщили проблему (или не сообщили и вы увидели ее из логов, или попросили небольшое изменение), приходят в полный восторг и думают - "эти парни наверное неплохо разбираются в своем деле". Таким образом из ошибки на сайте вы можете получить лояльных пользователей - ядро любой системы в современном мире (чуть не сказал web 2.0 мире, но мы не об этом).

Главное для вас на старте - обеспечить работу основных сценариев, и быть готовым к тому чтобы наблюдать за пользователями и мгновенно реагировать. Этой возможностью ("живым" наблюдением за пользователем и таким же "живым" процессом изменения) и отличается веб проект и это стоит это учитывать при его разработке.

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

Как это обеспечить? Все достаточно просто, начнем с наблюдаемости. Вы должны иметь возможность (и желание) наблюдать на за пользователями как на макро так и на микро уровне.

Макро уровень - это Google Analytics, AWStats, внутренние статистики (количество регистраций в день и т. д.). Эти инструменты позволят вам знать так называемую среднюю температуру по палате, и при наличии отклонений копнуть немного вглубь причин (например всплески активности, частоты индексации различными поисковиками, тенденции посещаемости по дням, популярные страницы). Кроме того, с помощью Google Analytics можно следить за конверсией пользователей, настроив правильным образом цели, в этом случае вы получите возможность знать насколько эффективны те или иные способы рекламы. Наблюдая за 404 ошибками в AWStats вы сможете найти битые ссылки в вашем проекте и т. д. Словом макро уровень это то, что обычно показывают топ менеджменту на презентациях результатов работы, но зачастую эти инструменты позволяют давать и более глубокую статистику, нужно только уметь грамотно ими пользоваться.

Микро уровень - это логирование, начиная от access logs вашего сервера и заканчивая... впрочем конца здесь нет, помните старую шутку про войну слоганов - "Яндекс - найдется все, Гугл - а ничего и не терялось", вы должны стремиться к тому чтобы не терять важную информацию о действиях пользователя. Храните все, код рекламной кампании с которой пришел пользователь, http referer - адрес сайта с которого он перешел к вам и стал вашим клиентом, при возникновении ошибки на сайте присылайте на емейл всю информацию о запросе, все http заголовки, полный stack trace ошибки. Невозможно все предусмотреть заранее, но вы должны пользоваться следующим правилом, если произошла ошибка и у вас нет достаточно информации чтобы узнать что именно произошло не так, не рвите на голове волосы, а добавьте необходимое логирование, не ленитесь, это действительно важно. В качестве примера приведу случай из нашей жизни. У нас стали попадаться на сайте картинки в каких-то непонятных цветах, изначально мы для экономии места все ужимали в 640 на 640, и, как следствие, потеряли оригиналы и не могли понять причину данного явления. Обнаружив это мы добавили код который сохраняет оригинал, и обнаружили ошибку с CMYK JPEG и PIL, которую исправили. (Правда теперь нам еще осталось написать простой cron скрипт который будет удалять все оригиналы старше недели, и к тому же выкинуть их из бекапов)

Помимо всего вышеперечисленного, организуйте наблюдаемость за результатом действий пользователей, мы это называем content feed. В нашей системе, все регистрации, добавления товаров, новостей, вакансий, и другие важные действия пользователей отдаются через RSS. В этот поток для каждой записи вы также можете вставить REST actions, например, заблокировать, активировать, пометить и прочее. Да, вы должны быть модераторами и поддержкой пользователей на ранней стадии жизни проекта, без этого вы просто не сможете написать инструментарий для людей которые будут этим заниматься впоследствии, когда проект разрастется. Вы должны есть еду вашей собаки, и она отплатит вам за это хорошей службой. К тому же чтение контента и общение с пользователями даст вам очень много ценных знаний о том как ваша система используется, что и где не так, даст почву для новых идей.

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

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

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

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

Очевидно, что для того чтобы этого достичь, обновление вашей системы до новой версии должно занимать секунды и минуты, и, в идеале, происходить практически незаметно для пользователя (сохранение сессий, незначительный down time). В нашем проекте в случае, когда не нужно вносить сложных изменений в базу данных, недоступность сервера занимает 2-3 секунды. А сам процесс обновления состоит в обновлении ветки SVN и перезапуске веб-сервера. Никаких тестов, никаких сборок, никаких кластеров. Залил изменение в SVN, запустил скрипт на сервере, проверил что все работает и через пару минут можно писать письмо пользователю, что его проблема устранена.

Но не стоит увлекаться и мелкими изменениями, система должна развиваться. Чтобы обеспечить это развитие для себя мы выделили 2 типа итераций (циклов) которые мы чередуем, - это итерации развития (ИР) и поддержания (ИП). ИР - это внесение нового функционала в проект, обычно длится у нас от 3-х до 7 рабочих дней, причем дата завершения плавающая, ее цель - внести в систему изменение. Это то, что в обычных проектах и понимается под итерацией. В начале ИР текущая версия уходит в live-ветку, в которой в дальнейшем исправляются все неотложные проблемы, а главная разработка идет в trunc-е. После ИР следует ИП - длится она 1-3 дня и состоит в том, что мы не ведем разработку в trunc-е а живем в live-ветке, наблюдаем за тем как приживается новый функционал и вносим изменения налету. В это время мы также дорабатываем дизайн, copy-тексты, мелкую логику, внутренние инструменты, статистики и прочие вещи которые не могут серьезно поломать систему. Как только мы довольны тем как работает новый функционал и нас начинает напрягать поддержка, мы сливаем все изменения в trunc и начинаем новую ИР.

Как результат, за 4 недели мы сделали 4 релиза (ИР) по такой модели и вполне довольны скоростью разработки, которая хоть сократилась, но зато функционал стал более акцентирован на пользователя, а не на сферического коня в вакууме. Мы стали любить и чувствовать наших пользователей, а они нас, и, признаться, это совсем другие ощущения, чем просто писать бездушный код.

Ограничения. Я думаю что это все работает на небольших командах (нас 3 человека) состоящих из опытных разработчиков, которые могут полностью доверять друг другу. Может это работает и в других случаях, но думаю тогда может появиться своя специфика. Это не работает в проектах основанных на технологиях где время от коммита до деплоймента превышает 10 минут. Ну и само по себе это не работает в аутсорсинговых проектах.

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

Вопросы, предложения, идеи как всегда приветствуются.