Наверх ▲

Управление разработкой высоконагруженных проектов

Владимир Габриелян Владимир Габриелян Владимир расскажет о различных этапах и инструментах управления разработкой высоконагруженных проектов, а также о возможных проблемах в процессе управления и о способах решения возникших проблем.

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

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

Думаю, многие включили бы в список атрибутов высоконагруженного проекта все три пункта, да еще добавили бы пару десятков признаков. Так вот, я склоняюсь к тому, что любой интернет-проект может стать высоконагруженным. Я вас уверяю: когда разработчики Mail.ru только писали почту в далеких 90-х, они понятия не имели, насколько популярным может стать этот проект. Очень многие сайты и сервисы в Рунете и в Интернете в целом создаются без учета того, что они могут стать высоконагруженными. Именно поэтому мы, как люди, которые управляют разработкой, должны понимать, что все, что мы пишем, должно быть рассчитано на последующую популярность проекта. Иначе зачем это делать?

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

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

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

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

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

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

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

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

Есть одно выражение, которое придумал очень известный в тусовке PHP-разработчиков г-н Колларенс. Оно звучит так: «Все разработчики хотят разрабатывать, но не все хотят разрабатывать для вас». Я, в принципе, с ним согласен. Сейчас мы поговорим о том, что нужно сделать, чтобы разработчик хотел разрабатывать для вас, в ваших проектах, в вашей компании.

Все разработчики имеют чувство собственности в отношении своего кода, они хотят уважения и признания их заслуг. Объясню, почему я акцентирую на этом ваше внимание. Существует такая должность, как менеджер по продажам. Там очень четкая характеристика: много принес денег – ты большой молодец, тебе почетная грамота, чуть ли не поцелуй от генерального директора. Есть такая профессия, как менеджер проекта – это человек, который делает проект целиком. Соответственно, если проект запустился в срок и в хорошем качестве – значит, менеджер - молодец. Если все сделано не в срок и некачественно - значит, менеджер плох. А разработчик – это фигура, которую очень тяжело оценить. Мало кто может понять, насколько конкретный разработчик справился со своей задачей. Именно поэтому, как правило, разработчиков очень редко хвалят. Хвалите своих разработчиков - это очень хорошая мотивация. Для многих разработчиков это так же важно, как и деньги.

Следующий пункт, на котором я хочу остановиться, – это чувство собственности в отношении своего "куска" программного кода. Эта проблема актуальна для больших компаний. Когда у вас есть большой отдел разработки, код часто мигрирует от одной команды к другой, от Васи к Пете. В итоге уже никто не знает, кто начал делать продукт, кто его закончил, кто сделал ошибку, которая мешает жить всей компании, и так далее. Поэтому постарайтесь сегментировать разработку так, чтобы один-два конкретных программиста отвечали за конкретную процедуру. Чтобы в случае возникновения проблем в проекте, когда в коде уже найдена ошибка, вы знали, к кому подойти и сказать: «Ну что же ты сделал?». Это должна быть конкретная фамилия. Это не должен быть начальник отдела разработки или весь отдел разработки, это должен быть конкретный человек. Все должны знать имя и фамилию конкретного специалиста, который отвечает за данный кусок кода. Это помогает нам достигать неплохого уровня качества.

Скажу пару слов о том, кто должен быть руководителем вашей команды разработки. Я хочу сказать, что это должен быть самый уважаемый член команды. Что это значит? Это значит, что авторитет этого человека среди разработчиков должен быть велик - это сэкономит время на объяснение каких-то вещей. Он должен получить этот авторитет не за то, что его назначили "сверху", а за то, что он лучший разработчик в нашей команде. Это позволяет экономить время в спорах и решать большое количество управленческих задач.

Следующая вещь, о которой я хочу поговорить, - это прозрачность принятия решений. Она позволяет нам формировать команду особым образом. Что это значит? Все члены вашей команды должны понимать, почему принято то или иное решение. Что это значит? Допустим, я предложил архитектуру «A», а кто-то предложил архитектуру «B», и я как разработчик должен четко понять, почему мы решили делать не то, что я предложил. Также я должен понимать, почему мы выбираем конкретные методики тестирования. То есть на все вопросы «почему» у меня как у разработчика должны быть четкие и прозрачные ответы, которые снимут напряженность в команде. Многие специалисты считают процесс разработки творческим, и им трудно пережить решение не в их пользу, - в этом случае прозрачность принятия решений очень полезна. Каким образом достигается прозрачность? Здорово, если все члены команды находятся в одном помещении, слушают доводы друг друга и принимают участие в обсуждении. Я вообще противник обычных совещаний: вы знаете, как это бывает, когда все встали, пошли в комнату переговоров, посидели там 6 часов, попили чаю и разошлись. Нет, совещание должно происходить непосредственно на рабочем месте. Если вам есть, что добавить, вы можете принять участие в разговоре, а если нет, просто продолжаете программировать.

Последняя вещь – это открытые коммуникации. Вы - как разработчик или как менеджер - должны сделать так, чтобы все члены команды знали, чем занят их коллега. Самое ужасное: сидят два разработчика рядом, и одного спрашивают: «Вася, а чем занимается Петя?». А он отвечает: «Я не знаю». Это плохо, потому что они никогда не поделятся опытом и никогда не обменяются "куском" кода. То есть Петя никогда не расскажет Васе о том, что он  уже наступал на те "грабли", которые Вася только программирует.

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

Следующая позиция – это архитектор. Задача этого человека – привносить в разработку какие-то новые идеи, потому что ни для кого не секрет, что часто глаз "замыливается". Когда мы 10 лет делаем один и тот же продукт, бывает очень тяжело привнести туда что-то новое, и задача этого человека - реализовывать на практике принципы R&D. На самом деле, R&D – это results and development. То есть ваше подразделение R&D должно создавать конкретные практически осуществимые идеи, которые вы реализуете в вашем проекте.

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

Следующая роль. Администратор или ответственный за продакшн, она по-разному называется, – этот человек необходим для того, чтобы ваша команда разработчиков в первую очередь узнавала о том, что происходит после того, как продукт был закончен. После того, как продукт попадает на продакшн, администратор, ответственный за продакшн, – это единственный человек, который может донести до разработчиков информацию о том, что они сделали. Я не рассматриваю тот вариант, когда у разработчика нет доступа на "живые" серверы, – это идеологически неправильно, это приведет к большим проблемам, поэтому администратор должен не только администрировать, но и предоставлять обратную связь. «Ребята, вы мне принесли большие проблемы с этими обновлениями», – если он этого не скажет, разработчики продолжат делать продукт именно таким образом, и администратор рано или поздно повесится. Шучу, но в каждой шутке есть доля правды.

Последняя роль, о которой стоит упомянуть, – это тестировщик. Роль тестировщика в Интернет-проекте - это тема для отдельного доклада. Мы решили, что тестировщики – это группа пользователей, которые имеют какой-то доступ к разработчику. Это люди, которые могут воспользоваться бета-версией проекта, которые входят в какое-то отдельное сообщество и которые могут сообщить конкретному разработчику: «Ты вчера мне написал чат, я сегодня его использовал – это, это и это не работает». Самое смешное, что нам повезло: людям в Интернете это еще и нравится. Думаю, если начать брать за это плату, они сами будут платить. Надо пользоваться этим!

Я, естественно, не буду говорить ни о каких конкретных технологиях. Скажу лишь о том, какой контрольный список (англ. check-list) необходим при ее выборе технологии. Главный вопрос: какая технология для вас будет хороша? Я сказал «для вас» неслучайно, потому что для соседних компаний эта же технология может быть плоха.

Итак, технология хороша для вас, если

...эта технология знакома вашей команде.

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

...эта технология беспредельно масштабируема горизонтальным способом.

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

Принимайте решения на основе собственного опыта, а не на основе советов своих коллег. У ваших коллег может быть другая команда и другая компания, поэтому применить у вас их опыт может оказаться довольно тяжело. Отдельно остановлюсь на тестах, которые легко найти в Интернете. Любой синтетический тест я могу развернуть на 180 градусов и показать совершенно другие результаты. В синтетическом тестировании очень тяжело показать то, что происходит на самом деле, поэтому решение в пользу выбора MySQL или Oracle, надо принимать самостоятельно. Авторы журнальных статей не знают ваших обстоятельств. 

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

Итак, на какие вопросы мы должны ответить?

  1. Как мы будем масштабировать нагрузку, если она будет?
  2. Как мы можем использовать то, что уже есть? Как правило, в компаниях уже имеются какие-то наработки, которые можно использовать в текущем продукте, "включив" фантазию.
  3. Как мы применим то, что мы запрограммируем сейчас, в наших будущих продуктах? Часто бывает достаточно дописать совсем немного кода, чтобы проект стал портируемым и "юзабельным" в наших последующих продуктах.
  4. Нужно выбрать ответственного. Это может быть не лидер группы, а любой программист, который лучше всего разбирается в нужной технологии. 
  5. Сроки. Когда мы это сделаем?

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

Итак, какой инструментарий нам нужен для нашей разработки?

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

Есть вещь, которая называется "радар". "Радаром" может быть все, что угодно. Например, доска для маркера или стена, на которую мы прилепили бумажки с текстом. Также это может быть записная книжка, лежащая на одном столе для всех. Смысл "радара" в том, чтобы любой разработчик или любой член команды мог, подняв глаза от монитора, увидеть, есть ли та задача, которой он занимается, на этом "радаре" или нет. Потому что в больших командах в длительных проектах очень часто сложно определить, насколько нужно то, что ты делаешь, настолько это важно в данный момент. Поэтому "радар" – это инструмент, куда руководитель команды может поместить задачу и, соответственно, разработчик поднял глаза и увидел – о, я занимаюсь важной вещью! Или там поднял глаза, а его задачи на "радаре" нет, он подходит к руководителю и говорит: «Слушай, я тут фигню какую-то делаю». В этом случае задача меняется, и разработчик начинает заниматься важными вещами. У меня бывали случаи, когда половина команды занималась второстепенными задачаи, и в итоге половина времени уходила в никуда.

Следующая вещь – список идей. Он тоже может существовать на любом носителе. В чем его идея? В длительных проектах часто бывает, что кому-то приходят идеи, которые невозможно реализовать прямо сейчас - пока нет потребности, времени, желания или еще чего-то. Идея фиксируется в спике, и к ней при необходимости можно вернуться. Иначе ее можно забыть и не вспомнить. А так всегда, когда у нас есть свободные пять минут, мы открываем список идей и смотрим, что хорошего мы уже придумали, но еще не сделали. Очень полезная вещь, рекомендую!

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

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

Расскажу про техзадание. Знаете, я не знаю, нужно оно или нет, на самом деле. Перечислю те принципы, по которым можно решить, нужно техзадание или нет.

Если проект занимает больше месяца, если работает много команд, если есть удаленные команды, если есть разработчики на аутсорсинге, – тогда техзадание точно нужно.

Если проект короткий, если подобный проект уже делали, если команда проекта помещается за одним столом – техзадание не нужно.

Лучшее техзадание, по моему опыту, – это работающий макет. Если кто-то что-то заранее покажет хотя бы на уровне html-верстки.

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

После того, как вы приходите к консенсусу, вы должны проверить следующие вещи. Первое: вы раздробили процесс разработки на минимальные кванты. Что это значит? Квант должен быть не больше недели, потому что неделя – это и так большой срок. В идеале он еще короче. Результатом каждой разработки является развертывание на продакшн-сервер. То есть максимальный цикл разработки – это неделя. Будет очень здорово, если в результате вашей разработки на продакшн-сервере получается что-то, что можно увидеть. Если визуализация существует, то конкретный разработчик может сказать: «Вот смотри, эту кнопочку я сделал на этой неделе».

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

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

Итак, теперь как выглядит наша разработка каждый день? Из графика мы выбираем какую-то конкретную задачу или список задач на эту неделю. Каждый день мы в течение 15-20 минут проводим встречу всех участников проекта. Это делается в начале дня, чтобы люди поделились друг с другом новостями: кто что сделал, кто что собирается делать, какие проблемы есть. В качестве приема, который заставит людей говорить кратко, можно использовать "standup-session" – просто стулья убрать. Как правило, это способствует краткости.

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

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

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

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

Второе, что обязательно нужно сделать, – нужно назначить и зафиксировать новый срок сдачи, потому что если мы будем двигаться в процессе «ну сейчас доделаем, ну еще чуть-чуть», я видел разработки, которые в режиме «ну еще щас», длились, наверное, по восемь месяцев. Где-то должен быть новый конкретный срок, дата.

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

Следующее «если», которое иногда нас всех постигает, – это изменения в ТЗ. За это команда обычно "благодарит" проект-менеджера. Эта проблема существует, и для того, чтобы в вашей команде не возникало напряженности, обязательно нужно обсудить с ней, почему это произошло. В интернет-проектах это бывает особенно часто, поскольку, пока вы писали одну штуку, конкурент уже запустил другую, и нужно срочно что-то сделать лучше, чем у конкурента, притом буквально завтра. Поэтому у всей команды должно быть четкое видение, почему мы бросили писать то и начали писать это. Это первое.

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

И не попадайтесь в самую главную ловушку IT-менеджера, когда к вам приходят люди и говорят: «Ну, тут же пять минут. Вот тут вот чуть-чуть». Тут, там пять минут, за день сто задач, и в итоге половина вашей команды занимается совершенно другими задачами, которые не имеют отношения к вашему основному проекту. Каждый раз, когда появляется какая-то внешняя задача, которой не было в плане, отражайте ее в вашем временном плане. Как правило, когда IT-менеджеры это делают, менеджер проекта говорит: «Боже мой, ну зачем ты меняешь план? Это же всего пять минут!» Я ему на это отвечаю: «Я же и меняю всего на пять минут. Чего ты нервничаешь?» Поэтому всегда нужно отражать даже самые мельчайшие изменения в плане – это важно, это вам потом поможет понять, что произошло, почему мы не угадали сроки.

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

Следующий момент – "боевое" и тестовое развертывание. "Боевое" – это когда мы "раскладываем" продукт на "живые" серверы, тестовое – когда серверы тестовые. Это должно выполняться одним и тем же скриптом или одним и тем же инструментом развертывания. Это позволит нам иметь в репозитории такой код и такие утилиты, которые позволяют добиваться одинакового результата на тестовом сервере, где разработчик полностью хозяин и может сделать все, что угодно, и на продакшн-сервере. Соответственно, когда разработчик сам на свой тестовый сервер "раскатывает" с помощью этих утилит, и ничего не собирается, это сэкономит время админу, который попробует собрать это на "живых" серверах, у него не соберется, он пойдет к разработчику и скажет: «Вот, у тебя ничего не работает». Поэтому, если у вас одни утилиты и там, и здесь, это просто сокращает время. Конечно же, еще раз хочу обратить внимание, что развертывание – это дело группы эксплуатации, группы системных администраторов, программистов эксплуатации. Главное, что это не те же люди, которые занимаются написанием кода. Потому что остановить себя, имея "root" на сервере, и не подправить невозможно. Не подвергайте своих разработчиков такому соблазну, это всегда кончается плохо.

И еще один очень важный момент, который позволит вам уменьшить количество проблем. Это развертывание исключительно из системы контроля версий. Неважно, что это будет: CVS, SVN, еще что-то – неважно. Важно, чтобы код не "поехал" на "живые" серверы с тестового сервера, от разработчика, еще откуда-то. У вас есть система контроля версий, вот оттуда выкладываем. Любой тестовый сервер – это сервер, который может быть "сожжен", причем безболезненно для процесса разработки. Такой подход позволит вам иметь актуальную копию ПО в вашем репозитории – раз, возможность воспроизвести то, что находится на "живом" сервере, на втором таком же, – два. Потому что переносить отдельные библиотеки, отдельное ПО или отдельные какие-то шаблоны и еще какие-то вещи с тестового сервера очень тяжело.

Я закончил. Ваши вопросы?

Вопросы и ответы

Дмитрий Гулев, разработчик. Владимир, спасибо вам за интересный доклад. У меня к вам вопрос по поводу процесса разработки. У вас было сказано… Мне кажется, тут некоторое противоречие. С одной стороны говорится, что у нас разработчики любят, когда код кому-то принадлежит, когда есть некоторая собственность, когда кто-то отвечает за конкретный код. Вот я написал код – я за него ответственный, да? Но это, с одной стороны, противоречит кросс-функциональности, которая в Agile пропагандируется. Понятно, что кросс-функциональность – это, конечно, идиллия. С другой стороны, это противоречит тому, что сказано: «Боритесь с расслоением команды». Вот это как вы можете прокомментировать?
Владимир Габриелян. Давайте я вам немножко объясню. Эта презентация – это видение, это мой подход к Agile. Я просто десять лет использую, тогда этого слова еще не было. Я считаю, что лучше иметь одного ответственного или двух, потому что с одним человеком может что-то случиться, чем иметь такую массу разработчиков, которые универсальны на все руки. Что касается, как выбрать между тем, что нам будет лучше – сделать ли нам четкую ответственность или сделать нам командную работу… Для меня ответ заключается в том, что лучше всего, когда у вас есть группа разработчиков – один, два, три, – которые занимаются определенной частью продукта, и просто следующая интересная задача достается другой группе. Когда для каждой группы существуют и сложные задачи, и простые. Нужно бороться с расслоением таким образом.
Дмитрий Гулев, разработчик. Понятно. И второй маленький вопрос. Вы говорили про средства учета времени. А какие вы используете?
Владимир Габриелян. Мы используем свое собственное.
Вопрос из зала. У меня короткий вопрос по поводу того, вот работают разработчики, желая получать удовольствие от работы, это мы им можем предоставить, они еще хотят получать зарплату, ну и наша задача – заметить, что кто-то хорошо работает, кто-то работает плохо, кому-то дать премию, кого-то похвалить. Как это решается?
Владимир Габриелян. Смотрите. Вот тот процесс разработки, о котором я говорю, подразумевает очень короткие этапы. В конце каждого этапа существуют встречи, где люди обсуждают, что получилось, что не получилось. Соответственно, так как встреча групповая, зачастую очень хорошо видно, почему возникла проблема, и, по сути, вся команда решает, кто молодец, а у кого возникла проблема. Это очень хорошо видно. Просто достаточно присутствовать на этой встрече. Увидеть, кто, как себя ведет, кто, что сделал в этом проекте.
Вопрос из зала. Еще один вопрос. У вас в схеме на неделю – неделя кончается выкладкой. А где там тестирование? Какое у вас соотношение тестовых разработчиков?
Владимир Габриелян. Еще раз. Я показывал то, что непосредственно человека, который занимает должность тестировщика, у меня нет вообще ни одного.
Вопрос из зала (уточнение). Функциональные тесты кто пишет, а также автоматические и системные?
Владимир Габриелян. Программисты.
Вопрос из зала (уточнение). Это все в рамках работы команды?
Владимир Габриелян. Да.
Вопрос из зала (продолжение). А отвечает кто?
Владимир Габриелян. Вот ты разрабатываешь определенную функцию, ты для нее написал тест, ты отвечаешь за результат – даже свалить не на кого.
Вопрос из зала. Выкатываются ли баг-фиксы в середине недели?
Владимир Габриелян. Смотри. То, что я сказал про длину цикла в неделю – это максимальная длина, а в рамках этой недели может быть, я с Петей закончу работу за полдня, и, соответственно, тут же происходит тестирование и релиз. Кто-то заканчивает через неделю, соответственно у них – через неделю тестирование и релиз. Неделя – это не тот момент, когда все закончили и все выходят в продакшн, а максимальный срок разработки, который позволяет очень четко контролировать, кто, что делает. 

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Станислав Лагун

Станислав Лагун

Senior Software Developer, Mirantis Inc.

Евгений Кирпичев и Станислав Лагун (Mirantis) делятся опытом построения высоконагруженного кластера с использованием RabbitMQ.

Юрий Востриков

Юрий Востриков

Один из ведущих разработчиков Mail.Ru.

Юрий Востриков (Mail.Ru) рассказывает о Tarantool/Silverbox - высокопроизводительной базе данных в оперативной памяти.

Сергей Аверин

Сергей Аверин

Руковожу разработкой проектов в Баду. Программирую server-side. Конференционный маньяк. Среди проектов, которые я делал — Хабрахабр, dirty.ru, trendclub.ru. Специализируюсь на больших/сложных веб-проектах.

twitter: twitter.com/ryba_xek
facebook: facebook.com/ryba.xek

Сергей Аверин (Badoo) рассказывает о постоянных соединениях (pconnect) и проблемах их внедрения.