Gaepton, безусловно, имеет право на собственное мнение. Оно, с одной стороны, перекликается с моими мыслями, с другой стороны — является противоположным.
Истина, как водится, где-то посередине.
Если Вам действительно интересен сравнительный анализ — я готова его сделать и опубликовать. Если же Вы считаете Garepton гуру, а всех прочих дураками, то я не буду пытаться Вас переубедить.
Только документация в этом не помогает. Помогает трекинг-система, в которой можно описывать связанные UC, задачи, баги и тест-кейсы.
Это важное замечание, спасибо. По документом я подразумеваю не текстовый файл, а, скажем так, единицу информации. Естественно, эта единица должна не просто лежать в репозитории, а находиться с контролируемом пространстве. Мы используем для этого jira, но, безусловно, существуют и другие инструменты.
Так не бывает. Математически доказано что не бывает полной и непротиворечивой системы. Кроме того, чем больше текста и чем больше участников, тем меньше вероятность что все участники одинаково поймут все написанное.
Это уже несколько другой вопрос, касающийся, скорее, управления проектом, чем документирования.
А я вообще противник чистого текста, предпочитаю для описания схемы и таблицы :)
Это документация, которую пишут аналитики.
Нефункциональные требования включаются в ТЗ, я их в описании документа даже отельным буллетом выделила :) Схема деплоймета, как правило, включается туда же отдельным пунктом.
Вот для внешних интерфейсов лучше писать самостоятельные доки, этот момент я в тексте упустила. Обещаю исправиться :)
Коллега, я тоже с госами работаю :)
Лармана читала, спасибо. Его методология, как и любая другая, имеет право на жизнь, но использовать её «в чистом виде» можно только на сферических проектах в вакууме.
Наши с Вами подходы различаются, в первую очередь, по той причине, что Вы, насколько я поняла, изначально разработчик, а я аналитик :)
Это не значит, что один подход лучше другого, они оба могут работать, всё зависит от многих факторов: привычек команды, объёмов и типа проектов, способов постановки задач.
Просто любопытство: а гостовую документацию у Вас техпис делает?
Я просто опустила этап сбора требований, потому что это такая отдельная история :)
Все требования генерятся на основании описания бизнес-процессов заказчика. То есть собрали информацию, согласовали описание процессов, отсюда и пляшу, на основании процессов выделяю подсистемы и функции, и дальше в лес, к упитанным партизанам.
кроме платного Balsamiq можно рассмотреть бесплатный Evolus Pencil
Ваш вариант мне тоже нравится :)
Естественно, не существует однозначных рецептов, я описала только один способ. Многое зависит от специфики проекта, команды и личный предпочтений аналитика.
Начинать всегда проще «сверху».
Попробуйте просто составить реестр функций, которые выполняются в системе. Функции лучше разбивать на смысловые блоки: что происходит на сайте, что в одном приложении, что в другом, и так далее. Условно это будут Ваши подсистемы. Описание на уровне «в приложении „погода“ пользователь может: посмотреть погоду на сегодня, посмотреть погоду на неделю, настроить автообновление».
Потом функции можно разобрать на составляющие: «для просмотра погоды на неделю необходимо щелкнуть по кнопке „Неделя“». И уже к этой вот составляющей можно привязать описание алгоритмов, классов, методов и прочих ценных «кишок» системы.
Для начала Вам даже сложные инструменты не нужны, хватит Excel. Попробуйте составить таблицу, в которую включите все данные для каждой подсистемы (приложения, сайта и т.д.): функция, алгоритм, используемая БД, описание. Возможно что-то ещё, зависит от специфики проекта. Знаю людей, которые ещё использовали ссылки на комменты в коде, но это высший пилотаж :)
Конечно, труд титанический, но, на выходе, полученный результат сэкономит Вам в дальнейшем очень много времени.
Если есть необходимость, стучите в личку — могу попробовать помочь.
По сути, схема должна быть такой же, меняется только процесс разработки. Получается некий вариант «reverse engineering».
По опыту: нужно выделить одного аналитика, который станет «штатным занудой» и задолбает всех вопросами «как это работает и зачем тут эта менюшка». Неблагодарный, на первом этапе, труд, слишком часто нафиг норовят послать :)
На основании полученных данных он составить «большое ТЗ» и, по необходимости, ЧТЗ.
Параллельно нужно запустить процесс «потокового документирования», то есть написания Use Cases и Test Cases для новых задач. Тут очень важно, чтобы РП был адекватный и умел настоять на необходимости «описывать каждый чих». Все новые доки должны сразу же подвязываться к ТЗ/ЧТЗ.
Естественно, обязательно нужно использовать технические средства совместной работы, поддерживающие версионность.
Постепенно можно довести ситуацию до близкой к идеалу.
На самом деле, мне кажется, что тут гораздо больше довлеет не «техническая проблема», а чистая психология: команда, которая не привыкла работать по документам, со скрипом перестраивается на другой режим работы. Приходится уговаривать и шантажировать :)
Истина, как водится, где-то посередине.
Если Вам действительно интересен сравнительный анализ — я готова его сделать и опубликовать. Если же Вы считаете Garepton гуру, а всех прочих дураками, то я не буду пытаться Вас переубедить.
Это важное замечание, спасибо. По документом я подразумеваю не текстовый файл, а, скажем так, единицу информации. Естественно, эта единица должна не просто лежать в репозитории, а находиться с контролируемом пространстве. Мы используем для этого jira, но, безусловно, существуют и другие инструменты.
Это уже несколько другой вопрос, касающийся, скорее, управления проектом, чем документирования.
А я вообще противник чистого текста, предпочитаю для описания схемы и таблицы :)
Нефункциональные требования включаются в ТЗ, я их в описании документа даже отельным буллетом выделила :) Схема деплоймета, как правило, включается туда же отдельным пунктом.
Вот для внешних интерфейсов лучше писать самостоятельные доки, этот момент я в тексте упустила. Обещаю исправиться :)
Лармана читала, спасибо. Его методология, как и любая другая, имеет право на жизнь, но использовать её «в чистом виде» можно только на сферических проектах в вакууме.
Наши с Вами подходы различаются, в первую очередь, по той причине, что Вы, насколько я поняла, изначально разработчик, а я аналитик :)
Это не значит, что один подход лучше другого, они оба могут работать, всё зависит от многих факторов: привычек команды, объёмов и типа проектов, способов постановки задач.
Просто любопытство: а гостовую документацию у Вас техпис делает?
Все требования генерятся на основании описания бизнес-процессов заказчика. То есть собрали информацию, согласовали описание процессов, отсюда и пляшу, на основании процессов выделяю подсистемы и функции, и дальше в лес, к упитанным партизанам.
Спасибо, обязательно посмотрю.
Удачи Вам :)
Естественно, не существует однозначных рецептов, я описала только один способ. Многое зависит от специфики проекта, команды и личный предпочтений аналитика.
Попробуйте просто составить реестр функций, которые выполняются в системе. Функции лучше разбивать на смысловые блоки: что происходит на сайте, что в одном приложении, что в другом, и так далее. Условно это будут Ваши подсистемы. Описание на уровне «в приложении „погода“ пользователь может: посмотреть погоду на сегодня, посмотреть погоду на неделю, настроить автообновление».
Потом функции можно разобрать на составляющие: «для просмотра погоды на неделю необходимо щелкнуть по кнопке „Неделя“». И уже к этой вот составляющей можно привязать описание алгоритмов, классов, методов и прочих ценных «кишок» системы.
Для начала Вам даже сложные инструменты не нужны, хватит Excel. Попробуйте составить таблицу, в которую включите все данные для каждой подсистемы (приложения, сайта и т.д.): функция, алгоритм, используемая БД, описание. Возможно что-то ещё, зависит от специфики проекта. Знаю людей, которые ещё использовали ссылки на комменты в коде, но это высший пилотаж :)
Конечно, труд титанический, но, на выходе, полученный результат сэкономит Вам в дальнейшем очень много времени.
Если есть необходимость, стучите в личку — могу попробовать помочь.
Рада, что оказалась полезной.
По сути, схема должна быть такой же, меняется только процесс разработки. Получается некий вариант «reverse engineering».
По опыту: нужно выделить одного аналитика, который станет «штатным занудой» и задолбает всех вопросами «как это работает и зачем тут эта менюшка». Неблагодарный, на первом этапе, труд, слишком часто нафиг норовят послать :)
На основании полученных данных он составить «большое ТЗ» и, по необходимости, ЧТЗ.
Параллельно нужно запустить процесс «потокового документирования», то есть написания Use Cases и Test Cases для новых задач. Тут очень важно, чтобы РП был адекватный и умел настоять на необходимости «описывать каждый чих». Все новые доки должны сразу же подвязываться к ТЗ/ЧТЗ.
Естественно, обязательно нужно использовать технические средства совместной работы, поддерживающие версионность.
Постепенно можно довести ситуацию до близкой к идеалу.
На самом деле, мне кажется, что тут гораздо больше довлеет не «техническая проблема», а чистая психология: команда, которая не привыкла работать по документам, со скрипом перестраивается на другой режим работы. Приходится уговаривать и шантажировать :)