devprom

Спрашиваешь... так делают процентов 90. Другое дело - правильно ли они поступают при этом? Часто документацию путают с проектированием. Это разные вещи и у них разные цели.

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

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

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

1. Зависит от сложности/объема задачи. Если все помещается в голове, то для чего тогда документация? Любая, UML или текст, не важно. Если что-то нужно продумать, то можно записать на доске/бумаге, сфоткать, потом выбросить.

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

3. Уважительной причиной чего-то не делать будет четкое понимание того, как связанные с этим риски минимизируются. Долой догмы. Если в среднесрочной перспективе мы четко осознаем, что фиксация/документирование требований не принесет пользы, то зачем тратить на это время/ресурсы?

Этой теме посвящена целая книга: "Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд" от авторов: Лиза Криспин, Джанет Грегори.

Там очень хорошо описана роль тестировщиков и разработчиков (в части тестирования), как лучше выстроить процесс, на что обращать внимание и т.п.

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

В UML для этих случаев используется два типа диаграмм: Activity (активностей) и Sequence (последовательности). Диаграмма активностей больше подходит для описания алгоритмов, с ветками, условиями и т.п. Диаграмма последовательности больше подходит для описания взаимодействия компонентов при реализации некоторого сценария. То есть первое больше про логику (или бизнес-логику), а второе - про реализацию в системе.

В вашем случае видимо больше всего подойдет как раз диаграмма последовательности, вот пример:

Диаграмма видов деятельности.

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

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

По каждому разделу ТЗ создаете задачи на подготовку макетов, доработку ТЗ, реализацию (разработку). Там же видите их статус (выполнено/не выполнено).

Все это можно организовать при помощи связки онлайн-редакторов (google docs, dropbox paper) и таск-менеджеров. Но, имхо лучше в одном сервисе это иметь, например, как сделано в scrumboard. В базе знаний пишем требования, на основе статей базы знаний создаем доработки или задачи - что еще нужно?

таск-трекеров много, но хороших систем управления по Scrum единицы: scrumboard одна из них.

Trac

Если хотите установить к себе на сервер, то лучше всего AgileTeam
Если лень ставить, то можно использовать online scrumboard

Бесплатный, без ограничений, open-source - AgileTeam

open-source решение на PHP называется AgileTeam.

Доброго времени суток.
У нас маленькая команда в 20 человек. Используем redmine уже несколько лет и все это время не хватало только удобного таймера для учета времени по каждой задаче. Но не так давно и эту проблему решили с помощью десктопного таймера RMClient. Методологию используем смешанную и нас все устраивает. Возможно, если вы измените схему работы с самим redmine то и переходить не придется.

Если говорить об установке на свой сервер, то лучшим вариантом будет бесплатный AgileTeam.

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

Бомба есть - это scrumboard

Для описанного вами случая лучше всего подойдет AgileTeam.

Бесплатная доска задач с поддержкой Scrum и Kanban для установки на свой сервер AgileTeam.

Мы используем Devprom - бесплатный трекинг задач + Kanban + недорогой, но приятный и функциональный сервис-деск