Г-да, в продолжение темы итеративной разработки.
Поделитесь опытом, что происходит в контрольной точке итерации, т.е. во время оценки результатов.
Кто что показывает заказчику — прототипы, билды, артефакты (проектные документы), что содержат данные документы, на каких их элементах делается акцент. Т.е. например, есть мнение, что показывать заказчику описание юзкейза в виде диаграмм последовательностей действий не очень хорошо, а есть и наоборот. Вобщем ваши мнения по этому поводу...
Здравствуйте, BalTun, Вы писали:
BT>Г-да, в продолжение темы итеративной разработки. BT>Поделитесь опытом, что происходит в контрольной точке итерации, т.е. во время оценки результатов. BT>Кто что показывает заказчику — прототипы, билды, артефакты (проектные документы), что содержат данные документы, на каких их элементах делается акцент. Т.е. например, есть мнение, что показывать заказчику описание юзкейза в виде диаграмм последовательностей действий не очень хорошо, а есть и наоборот. Вобщем ваши мнения по этому поводу...
Все зависит от заказчика. Если он далек от программирования и никогда не видел Use Cases — то лучше их ему и не показывать.
В зависимости от фазы проекта deliverables разные. В фазе проектирования — это документы: специфицации, architecture overview, и т.п. В фазе прототипирования — прототипы пользовательского интерфейса. Ну и так далее.
Deliverables должы быть такими, которые вы реально сможете сделать и заказчик сможет понять. Создавать тучу документации, которую никто читать не будет, вредно.
Главное — что бы заказчик знал, какой продукт вы делаете, какие у вас есть проблемы и открытые вопросы, и в какие сроки он может ожидать результата.
Здравствуйте, entin, Вы писали:
E>Здравствуйте, BalTun, Вы писали:
BT>>Г-да, в продолжение темы итеративной разработки. BT>>Поделитесь опытом, что происходит в контрольной точке итерации, т.е. во время оценки результатов. BT>>Кто что показывает заказчику — прототипы, билды, артефакты (проектные документы), что содержат данные документы, на каких их элементах делается акцент. Т.е. например, есть мнение, что показывать заказчику описание юзкейза в виде диаграмм последовательностей действий не очень хорошо, а есть и наоборот. Вобщем ваши мнения по этому поводу...
E>Все зависит от заказчика. Если он далек от программирования и никогда не видел Use Cases — то лучше их ему и не показывать.
E>В зависимости от фазы проекта deliverables разные. В фазе проектирования — это документы: специфицации, architecture overview, и т.п. В фазе прототипирования — прототипы пользовательского интерфейса. Ну и так далее.
А можно поподробнее, желательно список документов с шаблонами =)
E>Deliverables должы быть такими, которые вы реально сможете сделать и заказчик сможет понять. Создавать тучу документации, которую никто читать не будет, вредно.
E>Главное — что бы заказчик знал, какой продукт вы делаете, какие у вас есть проблемы и открытые вопросы, и в какие сроки он может ожидать результата.
Для заказчика это главное, согласен, но документы заказчику показываются не только для него, а ещё и для нас. Для нас — для того, чтобы он мог оценить и направить разработку своими замечаниями, претензиями, комментариями и пожеланиями, вобщем оценкой. Хотелось бы с этой точки зрения описать необходимые документы.
Понятно, что всё зависит от проекта, но всё-же, может для конкретного проекта, может для наиболее всеобъемлющего проекта примеры.
"BalTun" <18831@users.rsdn.ru> wrote: > Г-да, в продолжение темы итеративной разработки. > Поделитесь опытом, что происходит в контрольной точке итерации, т.е. во время оценки результатов.
Если говорить о RUP, то есть Контрольные Точки и контрольные точки. Первых — четыре: Lifecycle objectives, Lifecycle objectives, Initial operation capability и Product release. Вторые — те management milestones, которые каждый PM назначает сам в зависимости от прогресса в проекте. Если первые довольно чётко обозначены и то, что в них должно происходить, с большей или меньшей степенью формализовано, то в отношении вторых такая формализация отсутствует.
Поэтому, наверное, в таки точках должно происходить ровно то, что вы и написали: оценка результатов. Были ли достигнуты цели, преследуемые текущей итерацией? Какие артефакты и/или продукты проекта были изготовлены? Какие цели не были достингуты и почему? Как сейчас выглядит карта рисков проекта? Каковы планы на следующую итерацию?
Всё это можно (а зачастую — и нужно) оформлять в виде артефакта под названием Status Report. (Отмечу, что можно этого и не делать: какие артефакты формировать и в каком объёме, в сущности, определяется менеджером проекта и процессом, в рамках которого он действует.)
Писать Status Report нужно так, чтобы его можно было использовать и как внутренний документ, и как отчёт о ходе проекта, представляемый заказчику (в некоторых проектах обязательства исполнителя по периодическому предоставлению такого рода отчётности даже могут быть записаны если не в договоре, то в уставе проекта).
> Кто что показывает заказчику — прототипы, билды, артефакты (проектные документы), что содержат данные документы, на каких их элементах делается акцент. Т.е. например, есть мнение, что показывать заказчику описание юзкейза в виде диаграмм последовательностей действий не очень хорошо, а есть и наоборот. Вобщем ваши мнения по этому поводу...
Безусловно необходимо показывать заказчику прототипы — одной из ключевых ценностей проектной разработки является тесное вовлечение заказчика в рабочий процесс. Если есть прототип, необходимо получить мнение заказчика о нём; правило "лучше один раз увидеть систему, чем сто раз прочитать проектную документацию" по-прежнему работает.
Что же касается проектных документов, то думаю, что скрывать их от заказчика тоже не следует. При этом нудно помнить, что далеко не для всех язык UML является родным, и демонстрация описания use case в виде каких бы то ни было диаграмм вызовет, мягко говоря, недоумение. Однако использовать текстовое описание use case'ов оказывается очень полезным. Заказчики, как показывает моя практика, достаточно быстро и легко начинают воспринимать описание системы в виде UC-модели. Когда это оказывается необходимым (например, в целях наглядности), можно сопроводить описание прецедента (мне не нравится ни один из возможных переводов термина "use case" на русский язык, но я предпочитаю использвоать "прецедент" из-за его краткости) диаграммами. То есть, заказчик готов прочитать диаграмму, если она сопровождена текстом, в противном случае он воспринимает её как специальный программистский волапюк, который изобрёл Самый Главный Айтишник, чтобы "заряжать" бедным заказчикам такое недетское бабло.
Здравствуйте, BalTun, Вы писали:
BT>Г-да, в продолжение темы итеративной разработки. BT>Поделитесь опытом, что происходит в контрольной точке итерации, т.е. во время оценки результатов. BT>Кто что показывает заказчику — прототипы, билды, артефакты (проектные документы), что содержат данные документы, на каких их элементах делается акцент. Т.е. например, есть мнение, что показывать заказчику описание юзкейза в виде диаграмм последовательностей действий не очень хорошо, а есть и наоборот. Вобщем ваши мнения по этому поводу...
Это надо планировать и заранее согласовывать.
Но в любом случае это (как я понимаю) только фиксация определенного состояния
(этап успешно, или неуспешно пройден).
Не стоит планировать просмотр тех же use cases, а нужно просто зафиксировать,
что да, use cases были написаны, просмотрены кому надо и утверждены.
Само review и утверждение use cases должно быть ДО.
Очень неплохо, если у вас есть SQA в том смысле, как это понимается в SEI SW CMM.
Собственно проверка таких контрольных точек — это задача SQA.
Он, как адвокат заказчика, должен удостовериться, что все OK.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, BalTun, Вы писали:
BT>>Г-да, в продолжение темы итеративной разработки. BT>>Поделитесь опытом, что происходит в контрольной точке итерации, т.е. во время оценки результатов. BT>>Кто что показывает заказчику — прототипы, билды, артефакты (проектные документы), что содержат данные документы, на каких их элементах делается акцент. Т.е. например, есть мнение, что показывать заказчику описание юзкейза в виде диаграмм последовательностей действий не очень хорошо, а есть и наоборот. Вобщем ваши мнения по этому поводу...
B>Это надо планировать и заранее согласовывать.
B>Но в любом случае это (как я понимаю) только фиксация определенного состояния B>(этап успешно, или неуспешно пройден). B>Не стоит планировать просмотр тех же use cases, а нужно просто зафиксировать, B>что да, use cases были написаны, просмотрены кому надо и утверждены. B>Само review и утверждение use cases должно быть ДО.
review — имеется ввиду текстовое описание юзкейзов, или что ?
Кроме юзкейзов что ещё ревьюится ?
Отчётность меня не очень интересует, меня больше интересует качество оценки.
B>Очень неплохо, если у вас есть SQA в том смысле, как это понимается в SEI SW CMM. B>Собственно проверка таких контрольных точек — это задача SQA. B>Он, как адвокат заказчика, должен удостовериться, что все OK.
Не этот SQA случаем имеется ввиду ? Шучу...
Можно вкратце о функциях Software Quality Assurance (менеджера, видимо) в CMM ? Кто это, представитель заказчика, или исполнителя, какими численными показателями качества оперирует и каким образом их измеряет ? С кем при этом контактирует ?
Здравствуйте, BalTun, Вы писали:
BT>Здравствуйте, bkat, Вы писали:
B>>Здравствуйте, BalTun, Вы писали:
BT>>>Г-да, в продолжение темы итеративной разработки. BT>>>Поделитесь опытом, что происходит в контрольной точке итерации, т.е. во время оценки результатов. BT>>>Кто что показывает заказчику — прототипы, билды, артефакты (проектные документы), что содержат данные документы, на каких их элементах делается акцент. Т.е. например, есть мнение, что показывать заказчику описание юзкейза в виде диаграмм последовательностей действий не очень хорошо, а есть и наоборот. Вобщем ваши мнения по этому поводу...
B>>Это надо планировать и заранее согласовывать.
B>>Но в любом случае это (как я понимаю) только фиксация определенного состояния B>>(этап успешно, или неуспешно пройден). B>>Не стоит планировать просмотр тех же use cases, а нужно просто зафиксировать, B>>что да, use cases были написаны, просмотрены кому надо и утверждены. B>>Само review и утверждение use cases должно быть ДО.
BT>review — имеется ввиду текстовое описание юзкейзов, или что ? BT>Кроме юзкейзов что ещё ревьюится ? BT>Отчётность меня не очень интересует, меня больше интересует качество оценки.
review — это некая процедура, когда документ вычитывается всеми заинтересованными лицами
и потом по найденным замечаниям документ дорабатывается.
Обязательно кто-то (лучше если это будет SQA) должен убедиться,
что все замечания действительно устранены.
B>>Очень неплохо, если у вас есть SQA в том смысле, как это понимается в SEI SW CMM. B>>Собственно проверка таких контрольных точек — это задача SQA. B>>Он, как адвокат заказчика, должен удостовериться, что все OK.
BT>Не этот SQA случаем имеется ввиду ? Шучу... BT>Можно вкратце о функциях Software Quality Assurance (менеджера, видимо) в CMM ? Кто это, представитель заказчика, или исполнителя, какими численными показателями качества оперирует и каким образом их измеряет ? С кем при этом контактирует ?
SQA — это в общем не менеджерская позиция. Это скорее позиция полицейского,
который следит, что принятый в конторе процесс (RUP или еще бог весть что)
действительно соблюдается. В SW CMM про это написано.
Естественно, что такой человек не должен зависить ни от команды,
ни от руководителя проекта, ни от других менеджеров,
которые прямо отвечают за продукт. Есть требование, что такой человек
должен подчиняться только главному в компании боссу.
SQA не занимается тестированием, но следит, что тестирование проводится должным образом
Принято считать, что SQA — это представитель заказчика, который не урывками,
а постоянно толкается в команде и в любой момент защищает интересы заказчика.
Какими численными показателями качества он оперирует?
Сложный вопрос. Зависит от процесса.
Ну например можно запланировать, что после успешного прогона всех тестов (когда все баги пофиксены)
продукт должен без единого сбоя еще проработать на 5 машинах в течение недели
В общем, как я сказал, зависит от процесса и от метрик, которые вообще меряются на проекте.
