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

1. Методология P - D - P unitecsys.com

2. Каждой команде – своя методология Каждой команде - своя методология. Так полагает один из ведущих специалистов-методологов Алистер Коберн. Суть вопроса проста: методология не должна мешать людям, работающим над проектом. А люди все разные. С разным опытом, разными навыками, разными взглядами на жизнь. В этом причина того, что невозможно создать единую для всех, "самую правильную" методологию разработки ПО. Да и не нужно это. Достаточно подобрать или "синтезировать" методологию, подходящую тебе и твоей команде.

3. Зачем мы здесь собрались? Задача мастер-класса - дать вам первое представление о нашей методологии . Чтобы вы могли дальше решить сами - взять ее на вооружение целиком, взять из нее отдельные идеи для собственного синтеза, или же не брать ничего.

4. С чего начинается разработка? Современные методологии ориентированы на пользовательские требования. Нас убеждают в том, что работу нужно начинать обязательно со сбора и анализа этих требований. В целом, понятно почему. ПО создается как часть общей системы, в которую входят "интерфейсные элементы" - люди, оборудование, другие информационные системы. И проектирование ПО, конечно, лучше всего начинать с описания его внешних интерфейсов.

5. Что такое Use Cases ? В двух словах, use case - это некоторая история о том, как пользователь (не обязательно человек) использует информационную систему для получения некоторого «значимого для себя» результата. В кавычки я взял ту часть, которая на практике представляет собой одну из серьезных концептуальных проблем.

6. Сбор и анализ требований : пять проблем Первая проблема - решение вместо постановки задачи Прямой опрос пользователей практически всегда дает не описание "значимого результата", а описание некоторого набора действий, которые, как полагает пользователь, должны решить его проблему. Такой поворот разговора (описание какого-то решения вместо постановки проблемы) сразу отсекает часть решений, которые, не исключено, решали бы действительную проблему более удачным способом.

7. Сбор и анализ требований : пять проблем Вторая проблема - расстановка приоритетов Кейсы разных пользователей могут вступать в противоречия. Противоречить друг другу могут кейсы даже и одного пользователя. Различные кейсы подвержены риску в различной степени. Чтобы понять с чего начинать, нужно выявить важнейшие кейсы. И затем выявить самые сложные из них.

8. Сбор и анализ требований : пять проблем Третья проблема - нефункциональные требования Нефункциональные требования - это требования, которые сложно описать глаголами и существительными. Это то, что обычно так и тянет описать прилагательными - "быстро", "надежно", "безопасно", "удобно", "экономично". Пользователи, как правило, не в состоянии формулировать такие требования.

9. Сбор и анализ требований : пять проблем Четвертая проблема – «спящие» кейсы «А x да, еще мы раз в полгода делаем вот такую важную операцию» . Ничего страшного, если важный кейс вскрывается в ходе второго дня работы по сбору требований. Гораздо хуже, если он вскрывается за неделю до сдачи системы в эксплуатацию. Такие "спящие" кейсы представляют собой один из главных рисков проекта.

10. Сбор и анализ требований : пять проблем Пятая проблема – верификация Собранные и проанализированные требования необходимо верифицировать. Верно ли мы поняли проблемы наших пользователей? Верно ли мы записали? Хорошие ли мы предложили решения? Правильно ли расставили приоритеты? Не забыты ли какие-то важные нефункциональные требования? После завершения разработки системы, встанет еще один важный вопрос: соответствует ли то, что мы получили - тому, что мы хотели получить?

11. Ответ в стиле RUP Чтобы понять, что нужно делать – пригласите консультанта. Он настроит вам процесс путем отсечения лишнего – лишних процессов, работ, ролей и артефактов. Затем, с тем что осталось, вы попытаетесь взлететь. При работе над проектом используйте наш универсальный язык UML. Он почти так же распространен как эсперанто. И его почти так же удобно использовать для повседневного общения , n uk është ajo? ( Ох нет, простите, это албанский).

12. Что происходит в реальной жизни Трудоемкость «затачивания» RUP под команду приводит к тому, что никто этого не делает. Максимум, делается кастомизация под всю компанию. Последствия – формальная отработка методологии «снаружи» и абсолютно другой процесс разработки «внутри». Использование UML для общения с заказчиком приводит к катастрофическим последствиям – заказчик не понимает ничего, и либо посылает всю проектную команду, либо подписывает задания не глядя. Во втором случае все проблемы вылезают на этапе предъявления системы. Сдача проекта превращается в «размен» багов на фичи.

13. Ответ в стиле XP и SCRUM В методологиях XP и SCRUM ответ очень прост : Заказчик сам пишет кейсы. Если кейс программисту непонятен – заказчик обязан переформулировать его иначе. Например- разбить на части. Заказчик сам расставляет приоритеты. Если заказчик забыл о нефункциональных требованиях – это его проблемы. Как вспомнит, так и отрефакторим. То же самое касается «спящих» кейсов. Верификация правильности сбора и анализа требований – проблема заказчика. Пусть не ошибается. А для верификации приложения заказчик должен написать нам приемочные тесты.

14. Что происходит в реальной жизни На свете бывают волшебные заказчики, готовые всерьез работать в методологии « agile » (читай : брать на себя все риски сбора и анализа требований). Они встречаются примерно так же часто, как волшебные единороги, и чуть чаще, чем разработчики, умеющие выдерживать собственные сроки. Если вам не повезло, то максимум что вы получите – самого бесполезного и ненужно работника, в качестве представителя заказчика на проекте. Разумеется, при сдаче системы вы войдете ровно в тот же цикл размена багов на фичи.

15. Что происходит в реальной жизни – 2 Есть простые проекты. На этих проектах все решения могут быть приняты одним «Главным специалистом заказчика». Но есть проекты сложные, включающие в себя кейсы очень разных групп пользователей. Один человек в такой ситуации не может представлять интересы всех групп.. В лучшем случае вы получите «перекос» функциональности системы – потребности, известные конкретному представителю заказчика, будут решены хорошо, а потребности других групп пользователей будут если не проигнорированы, то удовлетворены гораздо хуже. В худшем случае вы получите политический конфликт, способный похоронить весь проект.

16. Общая картина Чтобы успешно отработать проект в методологии XP или SCRUM, вам должно очень сильно повезти с менеджером проекта на стороне заказчика. В его лице вы должны получить человека, способного грамотно собрать и «увязать» требования самых разных групп пользователей, способного самостоятельно расставить приоритеты, способного принимать решения и брать на себя ответственность за эти решения. Если вам не повезло, и такого менеджера на стороне заказчика не нашлось, ваш проект скорее всего обречен на типичные проблемы.

17. Что делать? Крайне редко бывает так, что на стороне заказчика в принципе нет вменяемых людей. Здесь поделать ничего нельзя. К счастью, чаще бывает так, что вменяемый человек просто не может уделять проекту столько времени, сколько необходимо было бы в рамках подходов XP/SCRUM. Это беда поправимая. Нужно самим взять на себя ответственность менеджера проекта. Иными словами, мы вторгаемся на территорию, которую другие методологии заранее отводят заказчику..

18. Что требуется от менеджера проекта Говорить на одном языке с владельцем проекта. Понимать потребности владельца проекта. Экономить время владельца проекта. Завоевать доверие владельца проекта. Выстроить конструктивные отношения с пользователями..

19. Ответ в стиле P.D.P Принципиальное отличие – мы не спрашиваем заказчика, что нужно сделать. Вместо этого мы спрашиваем – чего нужно добиться в итоге. Какую задачу надо решить. Мы начинаем не с кейсов. Мы начинаем с целей.

20. Говорить на одном языке Язык заказчика – это язык целей. Заказчик знает, что ему нужно. Но не знает как это сделать. Наша работа – перевести потребности проекта с языка целей на язык решений. Чтобы перевод был правильным, необходимо очень хорошо понимать переводимый «текст». Иначе вместо литературного перевода мы в лучшем случае получим кривой «подстрочник».

21. Понимать потребности Потребности заказчика – это достижение его целей, за приемлемую цену. Без понимания целей нет понимания потребностей. Заказчик подвержен обычным человеческим слабостям – неуверенности, мимолетным увлечениям, излишнему доверию к рекламе, и т.д. Понимание целей позволяет нам удерживать курс проекта. Иногда - вопреки сиюминутным интересам заказчика.

22. Экономить время Все, что действительно нужно заказчику – это уверенность в том, что дело движется в правильном направлении. Не перегружайте заказчика техническими подробностями. Освободите время заказчика от обсуждения мелочей. Говорите с заказчиком о том, что действительно важно – о самых главных целях и самых важных рисках.

23. Завоевать доверие Если вы говорите с заказчиком на одном языке, если вы понимаете его потребности, если вы не тратите впустую его время – значит, вы заложили хорошую основу для возникновения и укрепления доверия. Все что вам остается сделать – это не подводить со своими обещаниями. Дело техники.

24. Владелец и пользователи Нужно хорошо понимать разницу между заказчиком (владельцем) проекта, и пользователями проекта. Владелец – это тот, кто платит вам деньги. И это тот, кто заказывает музыку (определяет цели). Пользователи следуют целям проекта, и делают это таким способом, который нужен владельцу проекта. С заказчиком у вас должно быть полное доверие. С пользователями достаточно конструктивных отношений.

25. Конструктивные отношения Интересы владельца проекта часто расходятся с интересами пользователей. Простой пример – средства безопасности в банковских системах доставляют неудобства их пользователям. Тем не менее, от этих средств никто никогда не откажется. Наличие понятных целей, утвержденных владельцем проекта, позволяет вам не вступать в неконструктивные пререкания с пользователями. Пользователи понимают, что источником их «неприятностей» выступаете не вы.

26. Как работать с целями проекта Вместе с заказчиком найдите главные цели проекта. Опишите в общем виде способ достижения каждой главной цели. Из описания выделите подчиненные цели. Опишите в общем виде способ достижения каждой подчиненной цели. Повторяйте, пока не придете к финальным кейсам.

27. Главные цели Главные цели – это то, ради чего существует проект. Заказчик всегда готов сформулировать главные цели, потому что это то единственное, что он очень хорошо знает и понимает. Обычно на проекте бывает сразу несколько главных целей. В интернет-проектах главные цели зачастую соответствуют способам монетизации.

28. Пример перечня главных целей Биржа труда Мы хотим зарабатывать на работодателях, которые будут размещать вакансии на платной основе. Мы хотим зарабатывать на работодателях, которые захотят отрекламировать свою компанию на рынке труда. Мы хотим привлечь соискателей, чтобы обеспечить популярность ресурса.

29. Пример описания способа Мы хотим зарабатывать на работодателях, которые будут размещать вакансии на платной основе. Работодатель формирует заказ на размещение некоторого количества вакансий в течение определенного времени. Выставляется счет на оплату. После оплаты работодатель получает возможность размещать вакансии. После окончания срока оплаты, вакансии работодателя автоматически скрываются.

30. Выделяем второстепенные цели Приведенное описание дает нам следующий набор подчиненных целей : Работодатель должен быть идентифицирован. В системе должны присутствовать его реквизиты – для выставления счета. Работодатель должен иметь возможность формирования заказов. Работодатель должен знать, когда он может уже размещать вакансии, и когда они будут автоматически скрыты. Оплаченные вакансии должны отображаться посетителям сайта. Не оплаченные вакансии не должны отображаться никому, кроме их владельца-работодателя.

31. Снова описываем способы Работодатель должен быть идентифицирован. В системе должны присутствовать его реквизиты – для выставления счета. Работодатель регистрируется на сайте, получает логин и пароль. Используя логин и пароль, работодатель указывает реквизиты в своем профиле. В любой момент работодатель может свои реквизиты изменить.

32. Приходим к финальным кейсам Работодатель регистрируется на сайте, получает логин и пароль. Открыть в браузере адрес <site>, нажать ссылку «Регистрация», вбить свой e-mail в поле « E-mail », вбить название организации в поле «Организация», нажать кнопку «Зарегистрироваться». Получить на e-mail письмо с подтверждением регистрации, перейти по ссылке из письма, увидеть на экране свой пароль, и получить его же в следующем письме.

33. Что в итоге : иерархия целей Цель Главная цель Главная цель Главная цель Способ Способ Способ Способ Цель Способ Цель Способ Цель Способ Цель Способ Кейс Кейс Кейс Кейс Кейс Кейс

34. Замечание об иерархии На схеме хорошо видно, что подчиненные цели и финальные кейсы могут существовать в интересах сразу нескольких главных целей проекта. Приоритеты целей транслируются на приоритеты кейсов. Если бы мы рассматривали только кейсы, не понимая какие цели за этими кейсами стоят – расстановка приоритетов по кейсам показалась бы нам странной и нелогичной.

35. Решение пяти проблем Переход от кейсов к целям облегчает решение пяти проблем сбора и анализа требований. В первую очередь – за счет резкого сокращения объема работы для представителя заказчика. Это означает, что работу может сделать тот, кто действительно может решать любые вопросы. Мы получаем реального заказчика, вместо бесполезного «представителя». Имея на руках формализацию главных целей, заказчик может спокойно доверить вам всю работу по превращению главных целей в финальные кейсы.

36. Решение пяти проблем Первая проблема - решение вместо постановки задачи. Задавая вопрос «чего вы хотите добиться» вместо «что вам нужно делать», мы начисто исключаем первую проблему.

37. Решение пяти проблем Вторая проблема - расстановка приоритетов. Владельцу проекта очень легко расставить приоритеты главных целей. Эти приоритеты очевидным образом транслируются вниз – на подчиненные цели и кейсы. Технические приоритеты (связанные с рисками) по-прежнему расставляете вы сами.

38. Решение пяти проблем Третья проблема - нефункциональные требования Нефункциональные требования к кейсам следуют из нефункциональных требований к целям высокого уровня.

39. Сбор и анализ требований : пять проблем Четвертая проблема – «спящие» кейсы Следуя целям, и способам их достижения, мы не ставляем места «спящим» кейсам.

40. Сбор и анализ требований : пять проблем Пятая проблема – верификация Цели и способы верхнего уровня изложены языком заказчика. Заказчику их легко верифицировать. По итогам исполнения проекта, заказчику точно так же легко верифицировать результат – не по финальным кейсам, а по общим процедурам достижения главных целей.

41. Эти ужасные изменения требований Работая с целями вместо кейсов, мы получаем возможность снизить остроту проблемы изменения требований. Мы будем лучше понимать причины, побуждающие к изменению требований. Более того, в большинстве случаев мы получим возможность предугадывать грядущие изменения, и предлагать их самим.

42. Причины изменения требований Крайне редко изменение требований связано с изменением собственно целей. В абсолютном большинстве случаев изменение требований продиктовано изменением способа достижения какой-то из целей. Причиной изменения способа достижения цели является осознание того факта, что выбранный способ не позволяет добиться поставленной цели.

43. Предвидение изменения требований Нам не составляет труда предвидеть изменения способа достижения цели, если по этой цели мы согласовали с заказчиком способ верификации. Тогда мы сами способны контролировать ситуацию. Если мы видим, что выбранный способ не проходит верификацию – смело можем сами предлагать внесение изменений. Всегда лучше возглавлять процесс, который ты не можешь отменить или запретить.

44. Язык описания Только заказчик имеет право верифицировать главные цели проекта и способы их достижения. Чтобы заказчик имел возможность свое право осуществить – цели и способы должны быть изложены на языке, естественном для заказчика. То есть на естественном языке, с использованием терминологии предметной области проекта.

45. Состав описания Описание цели – чего мы хотим добиться Описание способа в общем виде – какие действия и кому следует произвести, чтобы цели добиться. Описание способа может включать нефункциональные требования. Описание способа проверки достижения цели. Выглядит как сценарий тестирования, включает в себя примеры реальных данных, реальных ответов системы, временные интервалы, и любые другие повторяемые и измеримые параметры.

46. Что дальше Методология P-D-P призвана решить сверхзадачу : достижение максимально возможного взаимопонимания между всеми участниками проекта. Теперь вы все знаете о первой опоре методологии – «цели вместо кейсов». Прошу задавать вопросы. Можно здесь и сейчас, можно попозже – на сайте p-d-p.ru