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

Всё в сравнении...

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

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

Полтора года сидел на Axure. Аналогов для себя еще не нашел. Но параллельно использую Balsamiq.
Для себя определился, Axure - если надо выйти на уровень понимания, и продемонстрировать, что-то в динамике, изменяющееся; Balsamiq - если надо, банально, зарисовать эскиз("мокап") страницы и впихнуть в ТЗ либо передать дизайнеру.

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

Там где в бальзамике я для какого то таска эскиз зарисовую за 5-10 минут, в акшуре надо минут 20 повозится. И еще мусорно выглядит.

В ТЗ вообще не должно быть скриншотов. Максимум - блок схемы.
Скриншоты и картинки это не ТЗ, это уже ФЗ - Функциональное задание. Не путайте!

Если в ТЗ вставлять скриншоты то ТЗ по более-менее среднему проекту будет состоять из 100-150 листов, что есть абсурдом. В ТЗ должны быть прописаны требования. По которым затем напишется методика испытаний для сдачи проекта и отдельно функциональные задания на то или иное требование или печень требований.

ТЗ должно быть лёгким для контроля изменений. Если для внесения изменения вам надо будет менять скриншоты или переписывать целую главу, то вас ожидает каторга и страдание. Я придерживаюсь не более 30 страниц в ТЗ.

Как всегда и везде, люди не до конца изучили agile/scrum и что то постят..

Ни где четко не прописано что заказчик должен быть вовлечен в процесс.

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

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

Если мы говорим о настоящем Agile Scrum, то собираем команду, изолируем её от всего кроме нашего проекта и дальше по методологии:

(тут есть только 2 простейших процесса где нужен заказчик на 1-2 часа в 2 недели. типичная ошибка, звать его везде как этому учат на дурацких тренингах за 1000$)

1. Собираем с заказчика хотелки и пихаем в беклог
2. Собираемся и грумим беклог дробя эпики на мелкие стори или еще мельче эпики
3. Делаем спринт пленинг и дробим беклог на задачи, поочередно оценивая всё
4. Согласовываем инкремент и какой Definition of Done
5. Работаем итерацию попутно проводя дейли статус митинги для синхронизации статусов и раннего выявления проблем
6. Демонстрируем в конце что получилось, собираем от заказчика фидбек и форматируем беклог, возвращая в него то что не готово и все что не влезло в спринт
7. Делаем ретроспективу и убеждаемся что копаем в нужном направлении и не делаем ничего лишнего либо добавляем в процессы работы то что стоило бы делать
8. Возвращаемся к пункту 1

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

Когда вы начинаете оценивать стоимость и сроки проекта под Agile/Scrum вы наступаете на теже грабли. Если заказчик не знает на что он идет то это не Agile.

Наши клиенты уже с шишками и готовы платить деньги не представляя стоимости проекта в целом и тем более его сроков. С большего это стартапы. На опыте запуски и провалы хороших проектов. Один из них уже 4й год на рынке и поднял 20 лямов инвестиций в США и сейчас является одним из успешных интернет магазинов в США.

Изначально на кармане у заказчика было денег понты и работало 2 человека на проект - бекенд и айос и копали-копали пока не выросли до постоянной команды в 5 человек (бекенд, фронтенд, айос, андроид, qa) которые непрерывно работают на проекте и копают спринтами один за другим. И ни кто никого не гонит. Заказчик купается в бабле