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

Многие нам говорят: "Но ведь есть basecamp, assembla, trac, jira, зачем вы делаете что-то свое, какой в этом смысл?"

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

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

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

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

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

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

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

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

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

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

Самостоятельные и небольшие задачи вполне могут выполняться фрилансерами, результат работы которых можно наблюдать в многочисленных портфолио на фрилансерских сайтах. В данном случае, результат работы по дизайну, полиграфии, разработке сайтов зачастую достаточно просто оценить лишь взглянув на работы. Но как быть с приложениями, которые не разместить на сайте или не передать заказчику для ознакомления? Строчка в резюме: "принимал участие в разработке системы управления уровня предприятия" не говорит об исполнителе практически ничего, кроме того, что предметная область ему известна. Более того, факт участия не говорит о характере и качестве участия в проекте. Одна команда может писать приложение год, а другая аналогичное приложение - три месяца.

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

Что может узнать заказчик о команде?

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

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

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

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

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

Как исполнителю предстать в лучшем свете перед заказчиком?

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

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

Нюансы

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

Не все заказчики готовы публиковать результаты проектов, а зачастую организуют процесс на своих серверах. Это затрудняет возможность получения объективной оценки проекта внешним пользователем. Мы еще думаем как лучше организовать передачу статистических показателей на сайт DEVPROM.net из таких проектов, может быть у вас есть идеи?

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

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

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

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

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

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

На мой взгляд, для адекватной формы обратной связи нужно:

• сделать ее максимально доступной пользователю, а не маленькой ссылкой внизу страницы
• помещать заведенные пользователями пожелания в журнал (User Backlog?), к которому обязательно давать доступ пользователям
• подписывать пользователя по email на все действия с его пожеланием (запланировано на итерацию, реализовано, отложено и т.п.)
• иметь возможность комментировать пожелание для общения пользователя и команды, с отправкой уведомлений по email
• обеспечить возможность пользователям голосовать за пожелания (рейтинговать), чтобы влиять на их включение в следующий релиз продукта
• в идеале, буквально нажатием одной кнопки пожелания пользователей должны попадать в бэклог команды разработки и далее планироваться на итерацию, т.е. форма обратной связи должна быть интегрирована с инструментом ведения проекта.

Звучит заманчиво?

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

Форма встраивается на сайт несколькими строками html кода, цвета, размер и шрифты настраиваются.

Вдобавок ко всему, к форме прилагается и отличный инструмент для управления проектами DEVPROM.

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

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

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

Для 100% кросс-функциональной команды, где разработчик = тестировщик = аналитик, это наверное не так важно - если анализ требований будет не успевать, остальные накинутся и помогут. Но много ли таких команд вы знаете?

(далее рассуждаем, приняв эффективность аналитической деятельности 1 разработчика меньше эффективности такой же деятельности 1 аналитика)

Давайте представим себе, что у нас недельная итерация, в команде помимо разработчиков только один аналитик по 4 часа в день - итого 20 доступных часов. А задач на анализ оказалось на 30 часов (например, недооценили) - и все необходимо сделать, чтобы хорошо начать следующую итерацию.

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

А burndown продолжает показывать, что все в норме!

Вот здесь и поможет еще один показатель, требуемая скорость разработки по фазам - если у нас осталось работ, например на анализ, больше чем физически доступно времени аналитиков, то загорится красная лампочка и нам придется вовремя обратить на нее внимание.

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

Описываемая методика заимствована из семейства Agile и не предполагает составления плана в привычном понимании, какой строится при помощи диаграммы Гантта. Методика базируется на двух основных понятиях: однотипность итераций (принцип вчерашней погоды - если погода установилась, то завтра погода будет такая же как и вчера) и скорость команды.

Методика

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

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

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

Остается еще один момент: все функции требуют различной трудоемкости на реализацию. Можно делить их на классы: простые, обычные и сложные. Мы пошли другим путем и оцениваем трудоемкость отдельного пожелания (feature или user story). Здесь возникает погрешность недооценки, поскольку команде, не реализовав и не поняв всех тонкостей реализации пожелания, трудно точно его оценить. С другой стороны команда состоит из людей и пожелание может быть выполнено не с первого раза, что обнаружится по результатам тестирования. Поэтому вводится еще один показатель: процент ошибок.

Результат

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

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

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

Ограничения

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

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

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

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

Если ваша команда разрабатывала Web-приложение, автоматизирующее деятельность магазина, а теперь ей предлагается разработать трейдинговое приложение на C++, то скорее всего показатели команды придется собрать заново. Однако, в любом случае это крайне рискованная затея :)

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

Люди уже давно научились планировать и описывать процессы при помощи практик календарно-сетевого планирования, ярким представителем которых является диаграмма Гантта. Разработано и обкатано множество программных инструментов, легко доступных любому желающему.

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

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

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

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

Ресурсы

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

Скоуп проекта

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

Сроки

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

Зависимости

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

Итеративность

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

Выводы

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

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

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