В теме 28 ответов, и 5 участников, последнее обновление сделано пользователем 
ekaterina 10 г, 4 мес. назад.
-
Сообщения
-
«вам нужно либо процесс менять на адекватно итеративный (и чтобы ожидания всех сторон по поводу деталей процесса совпадали), либо отказывать клиенту в слониках и бантиках (не лучший вариант, но, собственно, а кто просил waterfall?:)).»
Думаю, применение гибких методик — лишь вопрос времени. А отказывать клиенту в слониках и бантиках, действительно, не самый лучший вариант.
Огромное вам спасибо за помощь и искренний интерес! Правда, не совсем поняла, для чего делать вот это:
«В конце, при передаче системы в приемку, вы убираете все из Истории изменений (мол, не было слоника), убираете все цветовые выделения и т.п. и приводите документ в формальный вид.»
Если с заказчиком эта вторая версия не согласовывается, то было бы удобно сразу видеть, в чем отличие от спецификации подписанной.
И да, было бы здорово услышать еще мнения/рекомендации по ведению истории изменений.
У вас ТЗ — это единственный документ, который вы разрабатываете? Если да, то у вас печалька, потому что требования (любого уровня) склонны постоянно меняться.У нас обычно создаются следующие документы:
1. ТЗ — содержит высокоуровневое описание того, что должно быть в системе.После подписания заказчиком остается неизменным на текущем этапе разработки.
2. Если заказчик после подписания вспоминает о каких-то требованиях, то это оформляется как Протокол изменений. Там описывается кто запросил, когда, и общая суть требования.
3. Спецификация требований — содержит подробное описание реализации требований, изложенных в ТЗ. Используется внутри команды для разработки и тестирования. Всегда должна быть актуальна.
При начале следующего этапа разработки ТЗ может актуализироваться.
Благодарностей: 1 Цитировать
«У вас ТЗ — это единственный документ, который вы разрабатываете?»
Нет, ТЗ — не единственный документ. Его я привела для примера. На самом деле у нас готовятся различные документы в зависимости от типа проекта.
Если это типовое внедрение СЭД, то чаще всего разрабатываются (бюджет и сроки обозначены еще до начала внедрения):
Устав проекта — документ, в котором описываются рамки проекта (участники, их роли, автоматизируемые процессы, этапы внедрения и сроки, риски).
В случае типового внедрения «скелет» системы уже есть, остается только нарастить функционал по пожеланиям заказчика. В этом случае нет необходимости готовить ТЗ . Если же необходима, допустим, еще и интеграция, то тогда сначала разрабатывается ТЗ на интеграцию, а затем только готовится проектное решение.
Проектное решение — документ, в котором подробно описаны автоматизируемые процессы и техническая составляющая.
При появлении новых требований после подписания Проектного решения они заносятся в Журнал регистрации проблем и пожеланий (дата, кто предложил, что, состояние решения вопроса). Это перекликается с вашим Протоколом изменений. Но есть один минус при таком подходе — открыв Проектное решение нельзя увидеть общую картину, нужно сопоставлять его с Журналом. Поэтому и возник вопрос ведения истории изменений в новой версии. В случаях, когда это типовое внедрение, и документ подписывается один раз (не уверена, что для типового внедрения можно будет применить итерационный подход), наверное, все-таки удобнее вести Журнал. С заказчиком согласовываются отдельные требования. Ему и не нужен документ целиком. А если идет не внедрение СЭД, а, например, разработка отдельного модуля на базе внедренной системы, и процесс итерационный, тогда есть смысл вести в документе историю изменений и сразу вносить правки в текст.
Некоторые требования из этого журнала могут быть запущены как задачи для разработчиков (внутренний багтрекер). Т.е. у нас нет документа типа Спецификации, которую вы оформляете. Разработчики получают не Спецификацию для работы, а конкретные задачи, каждая из которых — отдельное требование. По сути, это та же Спецификация, только порезанная на маленькие кусочки.Мне интересно, каким образом из ТЗ у вас рождается Спецификация? Она создается параллельно ТЗ? И каким образом построена работа у разработчиков и тестировщиков по Спецификации?
Денис, спасибо за комментарий! Он помог мне взглянуть на ситуацию с иного ракурса.
Алёна, давайте вернемся к вашему изначальному вопросу «Каким образом вы отображаете изменения требований в документации?».Попробую выделить различные задачи в этом процессе на примере документов в MS Word.
Увидеть отличия между разными версиями документа — решается разными способами:
1. Включенный Track changes. В определенный момент все изменения принимаются, чтобы получить новый срез.
2. Сравнение двух документов стандартными средствами. Точнее предыдущего варианта, может применяться по необходимости. необходимо хранить разные версии документов (если вы используете версионный контроль, то это происходит автоматически).
3. Визуальное сравнение глазами — самый неточный и затратный способ, однако может применяться, если первые 2 работают неверно.Увидеть, кто и когда сделал изменения:
1. Использовать Track Changes
2. Использовать версионный контроль и сравнение двух докуметов стандартными средствами.Увидеть, с каким запросом заказчика связаны изменения -это самая проблемная часть. Проблема заключается в том, что один запрос может приводить к множеству мелких измений по всему документу. Соответственно любая индикация прямо по тексту документа (комментариями, примечаниями, цветом и т.д.) будет приводить к захламлению документа избыточной информацией.
Можно вести изменения в отдельном документе и проставлять ссылки на изменяемые разделы, но как только у вас запросы начнут накладываться друг на друга (то есть «запрос 2″ дополнительно изменяет изменения «запроса 1″, и т.д.), вы начнете терять изначальные причины каких-либо изменений.
Поэтому инструменты для последнего пункта надо подбирать исходя из ваших потребностей — насколько вам надо заморачиваться с этим.
По поводу того, каким образом из ТЗ рождается спецификация — ТЗ описывает «что должно быть» (пользователь может просмотреть список документов), спецификация описывает «как это должно работать» (экранная форма с детальным описанием, необходимая бизнес-логика, маппинг на протокол взаимодействия между системами). То есть ТЗ = функциональные требования, Спецификация = системные.
«Алёна, давайте вернемся к вашему изначальному вопросу «Каким образом вы отображаете изменения требований в документации?».»
Да, хорошее предложение. Что-то меня все время тянет уйти в сторону от темы и выяснить попутно другие вопросы:)
Для меня основной задачей изначально было — увидеть отличия от единственной подписанной версии. Соответственно, увидеть, кто и когда внес правки в документ, кто инициатор изменения и иметь возможность просмотреть изменения по тексту документа.
Наиболее удобным способом на данный момент кажется создание листа изменений в документе и выделение изменений другим цветом по тексту (возможно, все-таки применение Track Changes в MS Word). Так как нет удобного способа связать пункт в листе изменений и правки в тексте (перекрестные ссылки не подходят), то от этой идеи, видимо, придется отказаться ввиду ее трудоемкости и отсутствия острой необходимости.
Так как нет удобного способа связать пункт в листе изменений и правки в тексте (перекрестные ссылки не подходят)
Вы можете поставить на измененный текст в документе Bookmark, и затем поставить на него перекрестную ссылку из своего листа изменений (можно даже из отдельного документа). Если запрос приводит к нескольким изменениям в документе, то в листе изменений вы делаете несколько ссылок.
выделение изменений другим цветом по тексту
Как быть если изменение изменяет предыдущее изменение? :)
«Вы можете поставить на измененный текст в документе Bookmark, и затем поставить на него перекрестную ссылку из своего листа изменений (можно даже из отдельного документа). Если запрос приводит к нескольким изменениям в документе, то в листе изменений вы делаете несколько ссылок.»
Такой способ я попробовала. Если изменений мало, то можно его использовать. Но в случае большого количества изменений в тексте данный способ себя не оправдывает.
«Как быть если изменение изменяет предыдущее изменение? :)»
Думаю, решение будет зависеть от изменения. Если оно в корне что-то меняет и достаточно объемное, то лучше создать новую версию документа. Если это небольшое изменение требований (например, еще раз переименовать поле на форме), то можно и поверх предыдущего написать. Хотя более правильным в данной ситуации кажется создание новой версии.
У нас на проекте принят следующий способ обозначения версий документации: рассмотрим на примере use cases. Когда разрабатывается новый кусок функционала, мы пишем стори карты… Но по итогу мы обновляем существующие use cases, учитывая те изменения, которые были внесены в функционал. В начале юз-кейса есть таблица под названием «Revision History«, где прописываем Дату изменения, Версию (номер), ID стори карточки, Описание (кратко), Автора (кто вносит изменения). Добавленный/измененный текст выделяем цветом. Текст, который нужно удалить, также выделяем цветом изачеркиваемего. По итогу имеем актуальный юз-кейс. На нашем проекте этот способ уже работает давно.Благодарностей: 1 Цитировать
Екатерина, спасибо вам за то, что поделились опытом!У меня возникло пару вопросов:
1. Use cases — это основные документы на вашем проекте?
2. Что содержится в стори картах?
3. Use cases и стори карты (все остальные проектные документы) ведутся в MS Word?
Вики не актуальна, т.к. на данный момент мы используем для тех же целей систему электронного документооборота (внедрением которой занимаемся). На ее базе разработан функционал для регистрации ошибок/пожеланий и контроля выполнения задач. После регистрации ошибки и др. можно запустить задачу по жесткому маршруту. Есть возможность создания любого количества версий документа, возможность создания произвольной задачи и другие функции. Возможно, вики позволяет делать что-то такое, чего у нас нет, но, к сожалению, я не работала с другими инструментами.
К слову, ведение документации в Confluence решает проблему версионности и отслеживания изменений в самой документации. Но не совсем понятно, пытаетесь ли вы решить именно эту проблему с помощью системы документооборота, внедрением которой занимаетесь. Если да, то, безусловно, wiki системы неактуальны. Если нет, то все же стоит обратить внимание и попробовать (у той же Confluence есть возможность посмотреть пробную версию).
К примеру тот же SharePoint, хоть и является довольно продвинутой системой документооборота, не позволяет сравнивать версии документа. Но, если вы поддерживаете версионность в вашей системе, то можно использовать стандартные средства MS Word:
1. Скачать 2 последние версии документа
2. Открыть одну из версий и выбрать функцию «сравнить» http://screencast.com/t/veWjZoFV
3. Выбрать более старую версию и новую версию http://screencast.com/t/0xWYzAbR
4. В новом документе отобразится сравнение версий http://screencast.com/t/4NFMFv0Xux
Вариант не идеальный, но попробовать стоит.
Благодарностей: 1 Цитировать
Да, версионность (возможность создания неограниченного количества версий) в нашей системе поддерживается, но нет функционала, позволяющего сравнить версии.«К слову, ведение документации в Confluence решает проблему версионности и отслеживания изменений в самой документации. Но не совсем понятно, пытаетесь ли вы решить именно эту проблему с помощью системы документооборота, внедрением которой занимаетесь. »
Как я уже писала выше:
«Для меня основной задачей изначально было — увидеть отличия от единственной подписанной версии. Соответственно, увидеть, кто и когда внес правки в документ, кто инициатор изменения и иметь возможность просмотреть изменения по тексту документа.
Наиболее удобным способом на данный момент кажется создание листа изменений в документе и выделение изменений другим цветом по тексту (возможно, все-таки применение Track Changes в MS Word). Так как нет удобного способа связать пункт в листе изменений и правки в тексте (перекрестные ссылки не подходят), то от этой идеи, видимо, придется отказаться ввиду ее трудоемкости и отсутствия острой необходимости.»
Использование стандартных возможностей MS Office для сравнения версий — достаточно длительный процесс. На мой взгляд, лучше тогда включать режим отслеживания изменений (Track Changes ) в MS Word. А еще лучше (для визуального восприятия) — вручную выделять цветами вставки и удаления.
Извините на задержку с ответом) Алена, ответы на ваши вопросы ниже:2. Что содержится в стори картах?
Стори карты — это и есть требования. На основе стори карт девелопер разрабатывает функционал, а тестеровщик пишет тест кейсы.
1. Use cases — это основные документы на вашем проекте?
Сразу пишем стори карты и рисуем wireframes. Затем обновляем юз-кейсы. Cоставляем отдельный документ для заказчиков о том, что было реализовано (со скринами). Поэтому к основным я бы отнесла стори карты (понять, что конкретно меняется/добавляется) и юз-кейсы (используются, чтобы понять, как работает система на текущий момент).
3. Use cases и стори карты (все остальные проектные документы) ведутся в MS Word?
Use cases ведем в MS Word. Стори карты в TFS (Microsoft Visual Studio). Wireframes рисуем в Axure. Остальные документы в MS Word.
Екатерина, если не сложно, можете объяснить, как вы ведете story cards в TFS? Это какая то специальная фича TFS или вы используете стандартные типы WI? И можно увидеть пример стори карты?Герман, ответы на Ваши вопросы ниже:можете объяснить, как вы ведете story cards в TFS? Это какая то специальная фича TFS или вы используете стандартные типы WI? И можно увидеть пример стори карты?
New Work Item = Feature. Закладка ‘Links’ -> ‘New’ -> New Work Item Type = Story Card.
В ‘Description’ пишем user story в формате: ‘As a <role> I want <ability> so that <benefit> .’
А в ‘Conditions of Acceptance’ пишем требования в следующем формате: Validate that smth is true.
Например,
Validate that the following note is displayed below the input field: “*Note.”
Validate that the Administrator is able to change the X amount.Благодарностей: 2 Цитировать
Вы должны авторизироваться для ответа в этой теме.
