^[1]

Фото Paul ^[2] CC ^[3]

Занимаясь разработкой IaaS-провайдера, мы в 1cloud ^[4] не понаслышке знаем о том, как важно грамотно организовать рабочий процесс всей команды. Недавно мы публиковали материал ^[5], в котором обсудили 13 вещей, которые не стоит говорить разработчикам и тестировщикам, а в другом посте затронули ^[6] тему корпоративной культуры организаций.

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

Джефф Моррис (Jeff Morris), занимавшийся управлением проектами в LucasArts, как-то сказал ^[7], что в разработке приложений главным критерием успеха является ежедневная работа. Успешные спортсмены не сразу стали выигрывать золотые медали на Олимпийских играх, они регулярно занимались и правильно питались под руководством своего тренера.

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

Вот несколько советов руководителям по организации процесса разработки приложений и сервисов.

Только спринт, только хардкор

Разработка должна вестись постепенно и итеративно, потому необходимо составить строгое расписание. На рисунке ниже представлен пример такого расписания для двухнедельного спринта.

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

Вам, как руководителю, стоит грамотно распределить нагрузку между сотрудниками, чтобы держать команду в тонусе. Дробите крупные задачи на более мелкие, дабы программисты не страдали под их «тяжестью». Как говорит ^[8] маркетолог Шерил Эндрюс (Cheryl Andrus), «даже небольшой успех может быстро приободрить команду». Каждый раз, когда разработчик завершает очередной маленький task, он заряжается энергией, и у него открывается второе дыхание.

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

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

Бегаем интенсивнее

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

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

Неплохим приемом будет выписать задачи на разноцветные карточки и повесить их на доску. Каждому цвету присвоить свой статус, например:

• Заблокирована – к задаче нельзя приступить (возникли технические неполадки или не выполнена связанная с ней задача).
• Не начата – к задаче можно приступить.
• В работе – над задачей ведется работа.
• Проверка – разработчик выполнил задачу и передал старшему на проверку.
• Выполнена – задача решена.

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

Расставляем приоритеты

Расстановка приоритетов – это залог того, что проект не «упадет» под конец дистанции. Интересную классификацию задач предложил ^[9] проект Drupal:

• Критичная задача: Нужно завершить как можно скорее, так как, возможно, кому-то это мешает продолжить работу. Откладывание таких задач может привести к резкому снижению производительности, сильно ухудшить пользовательский опыт и качество документации.
• Важная задача: Пока она не выполнена, запускать новую версию продукта нежелательно. Одним из типичных примеров важной задачи является рефакторинг кода. Рефакторинг ^[10] способен повысить не только читаемость кода, но и его производительность, что положительно скажется на отношении клиентов – об этом мы упоминали в одном из наших предыдущих постов ^[5].
• Задача средней важности: Релиз можно проводить и без ее завершения, однако качество программы может пострадать. Пример такой задачи – тестирование небольшого куска рабочего кода.
• Не важная задача: Выполняется «для красоты», так как не влияет на функционал приложения. Например, исправление опечаток в комментариях к коду.

Есть множество способов расстановки приоритетов задач. Выше представлен лишь один из них. Больше информации вы сможете найти по ссылкам (здесь ^[11], здесь ^[12] и здесь ^[13]).

Поддерживаем дыхание

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

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

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

Что касается специально разработанных баг-трекеров, то вот пара рекомендаций. Есть баг-трекер Jira ^[14], часто используемый большими командами. Для команд, состоящих из нескольких человек, подойдут Pivotal Tracker ^[15], Trello ^[16] и трекер Github ^[17]. Бесплатно распространяются Bugzilla ^[18] от Mozilla Foundation, Mantis BT ^[19], Redmine ^[20] и минималистичный Trac ^[21].

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

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

Упор на технику

Настройте свою команду на создание качественного программного обеспечения. Однако чтобы проверить это качество, необходимо регулярно тестировать сервис. Несколько советов на эту тему дали ^[22] участники обсуждения на Quora.

Дополнительно стоит отметить, что иногда нужно проводить тестирование с участием всей команды разработки. Хотя бы раз в неделю каждый должен «поиграться» со своим приложением, пощупать его. Однако полностью отдавать тестирование на откуп разработчикам не стоит ^[23].

---

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

Мы в 1cloud ^[4] стараемся делиться не только собственным опытом работы над сервисом по предоставлению виртуальной инфраструктуры, но и рассказывать о смежных областях знаний в нашем блоге ^[24] на Хабре. Не забывайте подписываться на обновления, друзья!

Автор: 1cloud.ru

Источник ^[25]