С целью получить больше информации о проекте и задумке опубликовали статью на Хабрахабре. Если вам есть что сказать или прокомментировать чье-то мнение, то читайте и присоединяйтесь к дискуссии: http://habrahabr.ru/company/devprom/blog/51004/

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

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

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

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

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

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

Ресурсы

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

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

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

Сроки

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

Зависимости

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы как думаете?

Локальная установка Subversion в качестве репозитория исходного кода может понадобится вам в двух случаях:

• вы не готовы доверять свой исходный код публичным сервисам (таким как opensvn.csie.org, googlecode или assembla), но хотите пользоваться DEVPROM на сервере http://devprom.ru для управления проектами
• вы вообще не готовы доверить ничего публичным сервисам, и устанавливаете на свой собственный сервер как DEVPROM, так и Subversion в качестве репозитория исходного кода.

Для обоих случаев вам поможет следующая инструкция по локальной установке Subversion и интеграции его с DEVPROM.

После того, какна локальном сервере установлен DEVPROM, необходимо установить Subversion.

Для этого следует скачать дистрибутив Subversion с сайта http://www.collab.net/downloads/subversion/

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

В параметрах Apache необходимо указать порт 81, поскольку порт 80 уже занят веб-сервером DEVPROM. Запомните путь к репозиториям, который вы указали для Apache. После установки приложения необходимо перезагрузить компьютер.

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

 svnadmin create local

где local - это название репозитория, вы можете выбрать любое название.

Перейдите в каталог, в котором располагаются файлы, которые вы хотите добавить в репозиторий и добавьте эти файлы в репозиторий:

 svn checkout http://localhost:81/svn/local ./
 svn add *
 svn commit --message=""

Теперь создайте проект в DEVPROM и в параметрах подключения к Subversion в качестве пути к проекту введите строку http://localhost:81/svn/local

Вы должны увидеть файлы, добавленные ранее. Интеграция DEVPROM и Subversion на ваших локальных серверах завершена.

Успешного вам завершения проектов!

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

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

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

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

Посмотрите какие возможности получает ваша программа:

• Размещение в каталоге проектов - посетители проектного хостинга и разработчики программ знакомятся с вашей программой. Возможно, кто-то из них станет постоянным пользователем в будущем, либо сразу даст вам несколько дельных советов. Вам гарантирован начальный приток пользователей без необходимости рекламы программы. Возможно, среди них найдутся ваши будущие партнеры.
• Размещение информации о программе - общие сведения о программе, ее функциях и возможностях, скриншоты вы размещаете в базе знаний проекта. Вам не требуется владеть версткой HTML, наполнение страниц осуществляется при помощи Wiki. Сведения о программе отображаются на странице вашего проекта и доступны всем пользователям, а также поисковым службам.
• Организация связи с пользователями - потенциальные пользователи добавляют новые пожелания к функциональности и сообщают об ошибках на странице вашего проекта, голосуют за те или иные доработки, позволяя вам лучше ориентироваться в текущих ожиданиях пользователей. Пользователи будут задавать вопросы по программе, а вы на них сможете оперативно отвечать. Информация о пожеланиях и вопросах дублируется сообщениями по электронной почте. Вы можете вести блог проекта, в котором сообщать о новых версиях, изменениях и фичах программы.
• Размещение дистрибутива или исходного кода - ссылка на дистрибутив вашей программы размещается на странице проекта и позволяет пользователям знакомиться с функционалом. Вы видите, кто из пользователей скачал программу, и можете получить от этого пользователя больше сведений об использовании программы, если другие неохотно сообщают вам об ошибках или пожеланиях. Если ваша программа распространяется с исходными кодами, то, используя любой бесплатный репозиторий Subversion, вы сможете выложить исходный код и он будет доступен вашим пользователям или партнерам.
• Использование помощи сообщества разработчиков - участники проектов обмениваются советами по ведению проектов, они вам могут пригодиться. Вы можете найти услуги, полезные вам на текущей стадии проекта, например, связанные с дизайном, маркетингом, администрированием, продажами и т.п. Если чувствуете потребность в дополнительных ресурсах, то можете разместить вакансию или передать часть задач на аутсорсинг, которым могут заняться участники сообщества.
• Профессиональный инструмент для ведения проекта - процесс разработки программы станет более прозрачным и понятным. Используя статистику по скорости и качеству разработки, вы сможете лучше понимать сроки выхода новых версий. Вы получаете возможность организовать команду по разработке вашей программы с участием разработчиков, распределенных географически, тем самым, сэкономив на офисе и других издержках.

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

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

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

Успешного вам завершения проекта!