Мы пользовались обыкновенным webwhiteboard.com, но с тем же успехом можно использовать realtimeboard.com (платный).
Сохранение истории не так важно. Сторимап — живой инструмент, важно его текущее состояние. После того, как истории сделаны, он теряет свою актуальность. Его можно сфотографировать и сохранить на память, но толку от него уже нет. Для новой фичи или нового релиза делаем новый сторимап.
Что касается индексирования — после того как сторимап помог нам определиться с приоритетами и разбить истории на мелкие, мы занесли их в обычный инструмент для работы в спринте (Jira или Trello), а там с поиском все в порядке :)
Мы так и сделали. Просто чтобы не откладывать выход на рынок, мы вышли с минимальным меню и услуг. В первой версии сайта для США у нас даже не было изображений пиццы :).
Поняв, что своя пицца для американцев востребована, мы изучили решения конкурентов — Доминос, Папа Джонс и других, и на их основе сделали свое, только более легковесное и удобное.
Сторимэп — это в первую очередь инструмент для общения, а общаться лучше всего лично, стоя у доски и тыкая в нее пальцами или маркерами. Удаленно тоже можно, но эффективность на порядок снижается. Удаленно как правило один говорит, остальные слушают (или делают вид).
Приемочные тесты, на мой взгляд, гораздо ценнее юнит тестов. Они несут больше информации о системе в целом, часто описывают сценарии с точки зрения пользователя а не разработчика и позволяют избегать сложной настройки моков. Это так.
С другой стороны, юнит тесты очень сильно помогают выстроить дизайн приложения, когда он неизвестен (разработка через тестирование).
Сложность, связанная с изменением архитектуры для запуска юнит тестов вызвана именно тем, что тесты пишутся после того, как дизайн системы уже построен. Если делать наоборот, то есть создавать систему одновременно с тестами, то дизайн сразу растет тестируемым и подстраивать его под тесты уже не приходится.
Я думаю что нужны и те и другие тесты. Но их ценность меняется в процессе работы над проектом. Ценность юнит тестов высока сначала и постепенно снижается к концу проекта, потому что как правило мало что меняется.
Тесты, которые запускаются на самом верхнем уровне, на мой взгляд, легко писать но очень сложно поддерживать. Поэтому Хенрик предлагает писать их так, чтобы они описывали сценарии пользователя, но при этом работали на фейкнутой системе, в которой подменяются самые нижние слои. Это сделает их быстрыми и поддерживаемыми.
Возникает вопрос — а почему приемочные тесты длятся несколько часов? Обычно это происходит потому, тестируют приложение через UI, сверху донизу, через все слои. В тестирование вовлекаются медленные ресурсы (SQL DB, внешние сервисы, файловая система) — именно поэтому они и становятся долгими, и к тому же хрупкими и ненадежными. Требуется уйма дополнительных усилий на подготовку данных перед запуском теста и чистку данных после запуска. Чистить в том числе нужно и после неудачных запусков.
Подход, который предлагает Хенрик, и который мы применяли в своих проектах — организовывать приемочные тесты таким образом, чтобы они по-прежнему охватывали максимальное количество слоев, но при этом не зависели от медленных ресурсов. Если вы подмените настойщую SQL DB на In-Memory DB, файловую систему и внешние сервисы на мок, то ваши приемочные тесты станут интеграционными, и бегать будут как из пулемета.
Сохранение истории не так важно. Сторимап — живой инструмент, важно его текущее состояние. После того, как истории сделаны, он теряет свою актуальность. Его можно сфотографировать и сохранить на память, но толку от него уже нет. Для новой фичи или нового релиза делаем новый сторимап.
Что касается индексирования — после того как сторимап помог нам определиться с приоритетами и разбить истории на мелкие, мы занесли их в обычный инструмент для работы в спринте (Jira или Trello), а там с поиском все в порядке :)
Поняв, что своя пицца для американцев востребована, мы изучили решения конкурентов — Доминос, Папа Джонс и других, и на их основе сделали свое, только более легковесное и удобное.
Правда написание самого DSL тоже не бесплатно :)
С другой стороны, юнит тесты очень сильно помогают выстроить дизайн приложения, когда он неизвестен (разработка через тестирование).
Сложность, связанная с изменением архитектуры для запуска юнит тестов вызвана именно тем, что тесты пишутся после того, как дизайн системы уже построен. Если делать наоборот, то есть создавать систему одновременно с тестами, то дизайн сразу растет тестируемым и подстраивать его под тесты уже не приходится.
Я думаю что нужны и те и другие тесты. Но их ценность меняется в процессе работы над проектом. Ценность юнит тестов высока сначала и постепенно снижается к концу проекта, потому что как правило мало что меняется.
Тесты, которые запускаются на самом верхнем уровне, на мой взгляд, легко писать но очень сложно поддерживать. Поэтому Хенрик предлагает писать их так, чтобы они описывали сценарии пользователя, но при этом работали на фейкнутой системе, в которой подменяются самые нижние слои. Это сделает их быстрыми и поддерживаемыми.
Подход, который предлагает Хенрик, и который мы применяли в своих проектах — организовывать приемочные тесты таким образом, чтобы они по-прежнему охватывали максимальное количество слоев, но при этом не зависели от медленных ресурсов. Если вы подмените настойщую SQL DB на In-Memory DB, файловую систему и внешние сервисы на мок, то ваши приемочные тесты станут интеграционными, и бегать будут как из пулемета.