Формирование требований из хотелок заказчика
•Download as PPTX, PDF•
1 like•1,913 views
Презентация Руфина Сарваровой на SQA Days-16 14-15 ноября 2014, Санкт-Петербург, Россия www.sqadays.com
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Формирование требований из хотелок заказчика
Similar to Формирование требований из хотелок заказчика (20)
More from SQALab
More from SQALab (20)
Формирование требований из хотелок заказчика
- 1. Формирование требований из хотелок заказчика Сарварова Руфина ICL Services, Казань
- 2. Требования не были плохими.. Их просто не так поняли • 75% - наш проект "обречен с самого начала." • 80% - переделываем работу больше половины времени • 78% - бизнес-заинтересованные стороны должны принимать более активное участие • 55% - бизнес-цели проекта ясны • < 20% - требования проекта соответствуют потребностям бизнеса • 23% довольны по завершению проекта
- 3. Что такое требования? • Требования определяют цель • Требования определяют потребности (проблемы) • Требования определяют решение • Требования определяют ограничения связанные с решением или проектом по его реализации
- 4. Идеальные требования Для аналитика Для программиста Для тестировщика
- 5. Роль требований «Анализируйте требования для определения риска связанного с тем, что конечный продукт не будет работать правильно в его предполагаемой среде использования» – CMMI, Guidelines for Process Integration and Product Improvement, Chrissis, Konrad, Shrum. 04.07.2010
- 7. Мы, не испытываем головной боли, мы только её переносчики Область проблем - Пользовательские требования Область решений - Системные требования
- 8. Область проблем и решений недостаточное понимание существующих проблем невозможность определить границы доминирование разработчиков и исполнителей в дискуссиях о системе, ограничения свободы в выборе решения.
- 9. Ошибки Недостаточно четко определенные группы пользователей продукта Не выделены представители, заинтересованные в продукте Излишняя детализация
- 10. Систематизация заинтересованных сторон Власть 5 4 Легитимность Срочность/ Интерес 1 7 3 2 6
- 11. Высокий уровень абстракции Потребности Возможности Функции системы Язык заказчика
- 12. Сформулировать требования 1. Определить ключевые заинтересованные лица 2. Сформулировать проблему 3. Сформулировать возможности продукта 4. Документирование (описать в виде диаграмм, UC).
- 13. Оценка и проверка требований • Является ли требование полным? • Является ли требование ясным? • Является ли требование выполнимым? • Является ли план тестирования и тесты понятным и приемлемыми? • Требования могут быть измерены? • Требования могут быть протестированы? • Могут быть связаны с архитектурой системы?
- 14. Эволюция Дарвина
- 15. Кейс 1 требование1 от ЗЛ1 требование2 от ЗЛ2 требование3 от ЗЛ3
- 16. Кейс 2 “нужно чтобы отчёты открывались быстрей!” “нужно отрефакторить функционал Х” “почему у нас всё так медленно?” “алгоритм не работает!”
- 17. Заключение Хорошая работа над требованиями – это правильно, ПОНЯТНЕНЬКО!
Editor's Notes
- 75% считают, что их проекты всегда или обычно "обречены с самого начала." 80% признают, что они переделывают работу половину своего времени 78% считают, что требования бизнеса не синхронизированы с требованиями проекта и бизнес-заинтересованные стороны должны принимать более активное участие и участие в процессе требования. Нечеткие бизнес-цели: только 55% считают, что бизнес-цели своих проектов ясны им. Менее 20% считают, что требования проекта соответствуют потребностям бизнеса. Только 23% заявляют, что все довольны по завершению проекта http://www.geneca.com/75-business-executives-anticipate-software-projects-fail/
- например - «получить «правильный» продукт для выхода с ним на рынок в подходящее для этого время, для захвата рыночной ниши» – «получить прибыль от реализации проекта» Требования определяют потребности (проблемы) – Требования заинтересованных сторон, бизнес требования • Требования определяют решение: – Процедуры, регламенты, системные требования • Требования определяют ограничения связанные с решением или проектом по его реализации: – Сроки, бюджет, персонал, применяемые технологии, соответствие требованиям законодательства и т.д.
- На каждом этапе необходим свой уровень детализации требований. Естественно, что на первом этапе аналитик должен выработать общее видение продукта, что хочет заказчик. Например, если приходит заказчик и просит сделать ему халат, то задача аналитика в том, чтобы понять его боль и определить конечную цель. Заказчику нужен халат потому что ему холодно? Что он не может ходить голышом? Чтобы поддерживать некий уровень своего социального положения? В зависимости от этого аналитик может продумать различные решения – шуба, утеплённый, длинный или с инкрустацией кристаллов сваровски.
- CMMI в своём гайдлайне утверждает ..
- http://mandenews.blogspot.ru/2010/08/test3.html http://moodle.unitec.ac.nz/pluginfile.php/163808/mod_resource/content/0/Agreement_Certainty_Matrix_1_.pdf Cynefin framework Теперь я бы хотела познакомить вас с Cynefin фреймворком – это классификация проблем и по нему же можно классифицировать проекты. На этом слайде немного видоизменённая матрица Стейси от Brenda Zimmerman. Вам необходимо действовать в зависимости от того, где на этой матрице вы в данный момент находитесь. Высокая определённость – когда причинно-следственные связи ясны, известны методы воздействия, результаты предсказуемы Слабая определённость – причинно-следственные связи непонятны, методы решения непроверенные, результаты непредсказуемы Высокий уровень соглашения – ценности, цели, перспективы и позиции ключевых заинтересованных сторон, которые вовлечены в процесс разработки и получения ценности продукта, достаточно близки, чтобы прийти к единому соглашению и готовые идти дальше. Низкий уровень соглашения – ценности, цели, перспективы и позиции ключевых заинтересованных сторон, которые вовлечены в процесс разработки и получения ценности продукта, очень далеки, трудно прийти к соглашению и найти общий язык. Зиммерман выделяет 5 видов ситуаций: Simple характеризуется простым контейстом, ясна причинно-следственная связь и решение является прямолинейным и либо уже известно либо его можно легко найти. Резульаты предсказуемы и все понимают что и почему они делают. Пример: приготовление торта по рецепту. Менеджеры и руководители в такой ситуации прямолинейны – они диагностируют проблему, проверяют, что решение является подходящим и сосредотачиваются на точной реализации. Complicated – сложный контекст, где ключевые стороны близки к соглашению, но причинно-следственная связь не очевидна, но может быть выяснена. Решение в таком случае основывается на экспертном мнении и опыте. Пример – отправить ракету на луну. Political – причинно-следственные связи ясны, но ключевые стороны далеки от согласия, лучшим решение признаётся, если все ключевые стороны согласны с ним. Пример – социальный проект по повышению уровня минимальной заработанной платы. Complex – причинно-следственные связи размыты, решения несовершенны и не могут быть выработаны заранее. Сложные проекты динамичны, согласия трудно достичь. Пример: восстановление торговли на оживлённной торговой улице Или – вырастить ребёнка. Хаотичный – существуют ситуации когда контекст является турбулентным, заинтересованные стороны сами по себе и возможно даже настроены против друг-друга. Выработанные решения могут решить проблему только сиеминутно. Пример – оказание помощи после землетрясения. В данном ситуации руководители должны стремиться вовлечь все заинтересованные стороны, создать коммуникационные каналы и собрать как можно больше информации, чтобы выбраться из кризиса. David Snowden и Mary Boone рекомендует в таком случае иметь 2 команды – одна которая будет выводить из текущего кризиса, а вторая будет продумывать меры, которые позволят избежать подобных проблем в будущем. Наверху (0, y) будет Agile гибкая методология разработки, где требования несогласованы Внизу будет Prototyped модель, где требования согласованы, но велика неопределённость Обобщая, Простые – следуйте рецепту, инструкциям, правилам. Сложные – поиск решения, накопление опыта Политические – создайте общий язык с заказчиком Комплексные – обучение на практике Хаотичные – стабилизировать, создать возможности для улучшения ситуации
- Например, в системе управления автомобильным движением: • Заинтересованные стороны (stakeholders) могут выразить проблему следующим образом: максимизация транспортного потока, при минимизации риска возникновения дорожных происшествий на пересечении дорог при минимизации стоимости обслуживания решения. • Системные инженеры (system engineers) могут предложить различные решения этой проблемы: разного рода светофоры; организация кругового движения на определенных участках дороги; а может быть и мост в качестве наиболее подходящего решения в рамках существующих ограничений, стоимости разработки и последующего обслуживания. • Архитекторы (designers) будут разрабатывать проект моста с учетом существующих физических ограничений, налагаемых окружающей средой. Область решений, эта та область, в которой инженеры задействуют все свои способности и изобретательность, пытаясь решить обозначенные проблемы. Основное отличие области решений от области проблем состоит в том, что разработка требований в области решений начинается с набора четко определенных требований, а разработка требований в области проблем стартует с нечеткой цели или размытого списка общих пожеланий. Очень часто заинтересованные стороны выражают проблему уже в терминах предопределенного решения. Это привносит дополнительную работу аналитику, поскольку теперь ему необходимо анализировать является ли предлагаемое (а фактически, требуемое) решение наилучшим или это всего лишь лишнее ограничение (недоразумение). (как в случае с халатом) Например, заказчики, формулируя проблемы, начинают с того, что им необходимы светофоры. Исполнитель же, в свою очередь, задавая вопросы, лишь потом выясняет истинные цели - необходимо увеличение пропускной способности транспортного потока при минимизации риска для водителей и пешеходов, что и является формулировкой проблемы независимой от ее конкретной реализации. После получения такой формулировки проблемы становятся понятными причины выбора последующих решений, которые, возможно, будут подтверждены при помощи моделирования, которое, в свою очередь, будет являться основанием для более детальных спецификаций абстрактного описания решения. В случае покупки готовой системы необходимо принять решение, что использовать в качестве критерия оценки систем - область проблем (пользовательские требования) или область решения (системные требования). Зачастую решение известно заранее и тогда имеет смысл покупать систему, удовлетворяющую системным требованиям. Однако формулировка проблем в чистом виде дает большие преимущества, даже если основой для выбора приобретаемой системы являются системные требования.
- Отсутствие четкого разделения между проблемами и решениями, может привести к следующим негативным последствиям:. • недостаточное понимание существующих проблем;. • невозможность определить границы (масштаб) системы и понять какой функционал должен в нее входить, а какой нет;. • доминирование разработчиков и исполнителей в дискуссиях о системе, поскольку единственное описание, существующее для системы, описывает ее в терминах реализации, а не в формулировках проблем;. • невозможность нахождения наилучшего решения из-за ограничений свободы в выборе решения.
- Основными ошибками, допускаемыми на этапе первичного сбора требований, являются: Недостаточно четко определенные группы пользователей продукта Не выделены представители, заинтересованные в продукте Излишняя детализация Чтобы не допустить этих ошибок можно дать несколько рекомендаций: • Разделите пользователей продукта на категории в соответствии с их ролями • В каждой группе выберите одного - двух человек в качестве представителей интересов группы. Выбранные люди должны быть лидерами (пусть даже и неформальными) в своей группе, четко представлять бизнес процессы, в которых участвует группа и лояльно настроенных по отношению к проекту создания и внедрения разрабатываемой системы. • Не пытайтесь сразу и досконально описать все требования. Это приведет лишь к затягиванию работ. Требования должны прорабатываться и детализироваться в ходе проекта. • Каждому требованию присваивайте приоритетность. Это позволит реализовывать в первую очередь самые необходимые требования, откладывая реализацию второстепенных возможностей на более поздний срок.
- Итак, давайте посмотрим, как выделять и классифицировать группы заинтересованных сторон. RONALD K. MITCHELL выделяет 7 типов заинтересованных сторон и разделяет их по степени влияния и наличия власти. Например, есть группа лиц, которые заинтересованы в том, чтобы уже скорей всё сделали и запустили. Но у них нет власти, не они выделяют бюджет и не они имеют право принимать решения. Это, как правило, внедренцы и те, кому отсутствие продукта доставляет боли. Итак, первая группа это те, кто платит, кто решает – да или нет. 2 - юристы\законники 3 – запросы этой группы отправлять «когда-нибудь потом обязательно» 4 – вовлекать, держать в курсе 5 – это дополнительная возможность. Договариваться о реализации их потребностей через спонсора. 6 – конечные пользователи 7 – нужно заинтересовать эту категорию тем, что интересует 6-ю Аналитик должен прислушиваться к группам 4,5,7 2,4,7,6,5 – проинтервьюировать Помните мы уже с вами обсуждали, что нужно найти истинную цель и желание. Так вот это лучше всего можно выяснять он-сайд, в курилках, в буфете с представителями групп 2, 4, 6, 5. Они вам могут рассказать много интересного. Например, Нонна Анатольевна может рассказать, что на самом деле проект провальный и просто текушего менеджера хотят подставить как мальчика для битья. Или, вы можете выяснить, что на самом деле цель – попилить по-лучше бюджет. Или – отчитаться перед другим руководством. Как ещё можно выявлять требования и проблемы заказчика? Семинары, опросы, брейн-штормы, командировки на место. R Mitchell, (B) and (D) Agle Wood, 1997, to the theory of stakeholder identification: define principle of who and what really matters. Academy of Management Review, 22 (4)
- Итак, вот мы выделили и классифицировали ключевые стороны. Далее мы определяем проблемы заказчика и заинтересованных сторон и соотносим область проблем с областью решения. И тут важно на языке заказчика донести ему наше видение. Для того можно использовать UC диаграммы, схемы или просто описание текстом. Главное – чтобы заказчику было понятно. Возможности, которые мы описали мы можем в функциональных спецификациях для себя уже писать в любом удобном нам виде, но высокий уровень заказчика должен быть на языке заказчика.
- 2. Сформулировать проблему можно по результатам интервью, проверить её лучше всего в кулуарах и курилках. В формулировке проблемы должно быть: Проблема Затрагивает В результате чего Успешное решение должно Сформулировать всё на языке заинтересованных сторон
- Является ли требование: полным? ясным? выполнимым? Является ли план тестирования и тесты понятным и приемлемыми? Требования могут быть измерены? Требования могут быть протестированы? Могут быть выделены (т.е. связаны) с архитектурой системы?
- Побеждает тот, кто больше приспособлен. Удовлетворить заказчика Подготовиться к изменениям
- Это не требование – это проблема. Описать её, сформулировать область решений. Сформулировать возможности продукта и реализовать соответствующие функции.