Много проектов

Если вам приходится вести несколько проектов, разделять участников команды между ними и уметь за всем этим следить, чтобы еще прогнозировать наличие ресурсов для следующих проектов, то вот интересная заметка: http://devprom.ru/news/Управление-портфелем-проектов

Риски нефункциональных требований

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

Проектирование архитектуры в Agile

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

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

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

Вот интересная заметка по поводу описания атрибутов качестваразрабатываемого приложения: http://devprom.ru/news/Определение-нефункциональных-требований

Интересные практики описания архитектуры в Agile проектах: http://agileconsulting.ru/

Гибгкий подход к документированию

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

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

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

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

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

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

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

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

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

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

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