Организация цикла разработки в команде10.04.2017 15:49

Так я начал изучать PHP + SQL (MySQL), а в дальнейшем освоил базовый уровень JS, библиотеку jQuery и сопутствующий минимальный пакет технологий AJAX и JSON.

Первый опыт

Так получилось, что первой моей официальной работой в WEB-сфере стал филиал крупнейшей зарубежной корпорации. Филиал существовал давно, но выполнял другие функции. С моим приходом был создан WEB-отдел (главный офис находился в Канаде, но web-отделы действовали и в других странах). В мои задачи входила поддержка и разработка сайтов компании (к моему счастью, все они были на Joomla!).

Мы использовали самописный таск-менеджер, а схема работы была следующей:

Тимлид ставил задачу. Ответственный (как правило, — разработчик) изучал ее и, при необходимости, запрашивал (в ней же) дополнительные ресурсы: доступы сторонних сервисов, графические материалы или контент. Все задачи курировал помощник тимлида. Как раз он и осуществлял связь (расшаривал задачу) между отделами.

Сама разработка велась на dev-копии сайта. В мои обязанности входила не только разработка на PHP, но и верстка/правки сайтов, а также frontend-часть. После завершения задачи разработчик должен был перечислить список изменяемых файлов. Далее производилось тестирование/проверка работы тимлидом или его замом, после чего измененные файлы уходили на manager-копию сайта. На ней работали в основном контент-менеджеры. Все проводимые работы затрагивали только базу данных, не касаясь изменения файлов (за исключением добавления графического материала). После заполнения контентом и соответствующих проверок изменения загружались на production версию сайта.

После нескольких лет фриланса такой подход к работе казался немного необычным. Но надо — значит надо (в то время я еще не знал о разновидностях систем контроля версии, деплоях, методологиях и прочих фишках командной разработки).

Моя попытка № 2

Не проработав в первой компании и полугода, я перешел в другую, русскоязычную фирму. Обязанности были все те же: разработка/правка сайтов под Joomla! на HTML+CSS / PHP / JavaScript / jQuery с применением AJAX + JSON. Единственная разница — не было конкретного тимлида. Был директор, который давал проект. Спрашивал, за какое время я смогу его реализовать, а потом я приступал к работе. Сам себе начальник: и тимлид, и разработчик, и верстальщик, и контентщик (только что дизайн не рисовал).

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

Навстречу светлому будущему

Новая компания была прогрессивной и быстроразвивающейся. Изначально сайты создавались по тому же принципу, по которому я начинал знакомство с CMS Joomla!: в основном это была интеграция готовых расширений под требования проекта. Постепенно фирма перерастала в web-агентство, которое занималось исключительно разработкой сайтов «под ключ» с индивидуальным подходом к каждому проекту. Примерно в то время я и устроился на работу. На вопрос: «Что можно сделать на Joomla! ? — я смело отвечал: — Всё!» (ведь хороший программист действительно может всё ?). Спустя месяц работы меня назначили ведущим разработчиком.

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

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

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

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

В любом случае в идеале необходимо свести задачи по backend-части в параллельную работу над дизайном и версткой. По завершению верстки она интегрируется с серверной частью. Также стоит отметить — при параллельной работе нескольких разработчиков над проектом команда придерживается методологии git flow (автор — Vincent Driessen), где веткой release brunches управляет тимлид либо сотрудник, ответственный за тестирование.

*Для удобства разработки можно настроить автоматический deploy master ветки на тестовый сервер (если это позволяет сделать проект).

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

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

Частные случаи

API

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

Мелкие проекты

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

Методологии работы

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

Резюме

В этой статье я кратко изложил свой путь к текущему образу работы команды. Единственное, что хочется отметить — такой принцип организации подойдет не для каждой компании. Многое зависит от количества сотрудников, их квалификации, от самих поставленных задачах. К примеру, если сайт требует реализации мобильного приложения или сложного API, принцип работы будет отличаться от текущего.

Возможно, в будущем мне удастся объединить все (или большинство) подходов к разработке, использовать лучшие практики существующих методологий и написать свою собственную. Которая будет удовлетворять потребностям большинства людей и компаний, работающих в WEB-сфере.

Полный текст статьи читайте на CMS Magazine