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

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

В системе управления проектами DEVPROM используются Agile принципы, согласно которым инструмент вторичен для процесса, другими словами - должен эффективно адаптироваться под текущие условия проекта. Если ваш проект переходит в стадию сопровождения, то вам не нужно искать баг-трекер, мигрировать в него данные или отказываться от накопленного опыта и обуждений по проекту. Вам достаточно отключить ненужные опции методологии. Методология в DEVPROM - это некий набор практик, при помощи которых DEVPROM адаптируется под ваш конкретный процесс. В отличие от других баг-трекеров, вам не придется перенастраивать workflow, просто отключите на время ненужный функционал, например, планирование задач.

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

9 декабря на AgileDays мы будем рассказывать про то, как внедрить Agile на уровне компании, в нескольких (десятках?) проектов, учитывая потребности и интересы всех заинтересованных в процессе и разрабатываемом продукте сторон.

Одним из основных инструментов работы Agile команды является доска задач (task board) и чаще всего это действительно настоящая доска, на которой располагаются стикеры с описанием задачи, а цветом стикера определяется приоритет. Это очень удобный и наглядный способ командной работы над некоторым пулом задач. Однако, у него есть ряд слабых сторон, из-за которых в один, как это обычно бывает, самый ответственный момент, вы можете потерять информацию о месячной итерации:

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

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

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

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

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

Пример №1

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

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

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

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

Пример №2

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

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

Надеяться, что несколько независимых разработчиков (фрилансеров в данном случае) объединятся в команду и будут производить высокого качества продукт в нужные сроки - крайне рискованное занятие. Конечно бывают иключения, но нанимать в таком случае лучше всего удаленную команду, которая сработалась и уже знает свои основные параметры: скорость и эффективность (подробнее о них читайте в посте "Agile: использование velocity").

Не нужно путать удаленных работников с удаленной командой. Обязательно нужно использовать инструмент для совместной работы, мы рекомендуем DEVPROM как идеальное решение для распределенных команд, реализующее основные практики Agile.

Пример №3

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

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

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

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

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

А причина в целом довольно простая:

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

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