Как не упустить срыв сроков

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

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

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

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

Любой старт требует маркетинговое исследование

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

Измерение скорости команды

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

Уменьшение формализации без снижения качества

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

Agile и риски

Неправильно думать, что Agile отрицает весь наработанный опыт, полученный в проектном менеджменте :) Вот и риски - это тема, которую Agile не обходит стороной. Просто чаще все не так формализовано, однако, если нужно подойти к проблеме системно, то рекомендую вот этот раздел на MSDN: http://msdn.microsoft.com/en-us/library/cc500363.aspx

Параметры Agile проекта

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

В предыдущем посте я писал, про то как опубликовал свой проект в облаке. Кстати, само облако работает на новом инструменте, специально ориентированном на Agile практиках. То есть, по сути, это software as a service этого самого инструмента. На мой взгляд, это положительно характеризует инструмент, то есть доказывает его работоспособность и полезность.

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

Мой проект в облаках

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

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

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

Куда можно положить проект

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

Попробовал готовые конструкторы сайтов, например ucoz, резюме: не то, больше того, совсем не то! Лабать решение на Drupal-е тоже не охота, надо ведь разбираться.

Вчера посоветовал товарищ посмотреть на "Облако проектов", кому интересно, то вот ссылка: http://projectscloud.ru На первый взгляд, судя по описанию - прямо в точку, и бесплатно. Попробуй посмотреть что там да как.