Фото Paul CC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

Автор:

Источник