Knigionline.co » Компьютеры » Пользовательские истории. Искусство гибкой разработки ПО

Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон (2014)

Пользовательские истории. Искусство гибкой разработки ПО
Пользовательские ситуации – это способ описания притязаний к разрабатываемому продукту. В книжке поведано, как верно применить эту технику, дабы сфокусироваться на установленной задачке и пожеланиях покупателя, а не распыляться на реализации второстепенных функций. Создатель книжки демонстрирует, как этот расклад не только ускоряет и классифицирует разработку, но и улучшает взаимопонимание в команде.
Уже достаточно большое количество организаций ввело у себя методологии Agile и Lean, в следствие этого, абсолютно ,вполне вероятно, что вы уже успели попасться в одну из ловушек, образующихся по причине неправильного осознания концепции ситуаций. Вот кое-какие из них. Книжка несомненно поможет вам:
Потому что ситуации дают возможность для вас сосредоточиться на разработке маленьких фрагментов ПО, просто закончить и рассмотреть неделимую картину. В итоге выходит обычный продукт-франкенштейн, любому юзеру которого бесспорно, собственно что он произведен из разрозненных, не связанных частей с иной частью.
Когда вы трудитесь над продуктом значимых объемов, создание малехоньких частичек одного за иной, вынуждает людей думать, когда же вы в конце концов закончите и собственно , что же выйдет в итоге. Как будто вы строитель.
Потому что ключевое в концепции ситуаций — это рассмотрение, люди нередко запамятывают производить записи. В итоге вещь обсуждения и достигнутые соглашения забываются.
Потому что в не плохих ситуациях ожидается присутствие критериев приемки, мы сосредоточиваемся на определении данных критериев. Но данный процесс и описание создаваемого продукта — не одно и то же. В итоге команда не имеет возможность окончить запланированную работу в запланированные , нужные сроки.
Потому что неплохие ситуации обязаны быть написаны с позиции юзера, но есть большое количество качеств, коих юзер элементарно не лицезреет, члены команды говорят: «У сего продукта нет юзеров, например собственно , что тут пользовательские ситуации не подходят».
В случае если вы уже угодили в 1 из данных ловушек, я (автор) стараюсь прояснить все вызвавшие
их недоразумения. Вы спрашиваете, как расценить совершенную картину, продуктивно дискуссировать цели и задачки юзеров и делать неплохое ПО.
Для кого ещё данная книжка:
Для вас, естественно. Тем более в случае если вы ее уже приобрели. Я вот считаю, собственно , что вы создали мудрую инвестицию. Во всяком случае, чтение книжки станет тем более нужным для знатоков надлежащих областей.
Продукт-менеджеры и UX-специалисты в платных компаниях, производящих продукты, обязаны прочитать данную книжку, дабы перебросить мостик от мира пользовательского навыка и работы продукта к тактическим намерениям и составляющим бэклога. В случае если вы чувствуете проблемы, пробуя перебежать от представления о продукте к отдельным составным частям, которые обязана сделать ваша команда, описания вам несомненно помогут. В случае если для вас непросто вынудить иных людей поставить себя на пространство юзеров, карта ситуаций для вам несомненно поможет. В случае если вы никоим образом не сможете увязать совместно добрый дизайн взаимодействия и практическое проектирование продукта, для вас книга станет помощником. И в случае если пробуете выполнить опыт в манере стартапа Lean, она также станет помощником.
Адепты клиентов, бизнес-аналитики, а еще продукт-менеджеры в организациях, занятых в сфере информационных технологий, обязаны прочитать эту книжку, дабы взвести мосты меж юзерами, разработчиками и другими заинтересованными сторонами. В случае если вы тратите большое количество усилий, дабы все заинтригованные лица в вашей фирме пришли в конце концов к какому-либо договору, карты ситуаций помогут. А в случае, если создатели затрудняются, пробуя нарисовать неделимую картину, ситуации будут полезны и тут.
Тренеры процессов Agile и Lean, в случае если они желают помогать командам и отдельным людям работать эффективнее, обязаны прочитать эту книжку. Не считая такого, задумайтесь, как неправильное представление о ситуациях развилось у служащих вашей организации! Используйте ситуации, обычные упражнения и практики, описанные в данной книжке, дабы посодействовать вашим командам развиваться.
И в конце концов, все другие. При применении процессов Agile мы почаще всего ждем плодотворной работы с ситуациями от людей, исполняющих прямые обязанности бизнес-аналитиков или же адептов клиентов, но на самом деле действенной работа будет, в случае если почвы станут популярны и доступны всем. В случае если люди не знают самых простых вещей, вы нередко будете слышать претензии о том, что ситуации дурно расписаны, или же очень длинные, или же мало детализированные.
Данная книжка несомненно поможет, но не так, как вы ждете. Вы совместно с другими читателями спрашиваете: создание ситуаций — это не метод чем какого-либо другого строчить запросы, а дорога к большим, продуктивным и санкционированным дискуссиям. Данное издание поможет вам сконструировать такие облики дискуссий, которые помогут вам владеть нужной информацией.

Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон читать онлайн бесплатно полную версию книги

Перед вами обложка книги Джен Ятис «Торты, которым не повезло», опубликованной в издательстве Эндрю Мак-Милла (спасибо Джен и Джону Ятис за предоставление иллюстрации). Книга получилась по мотивам ее очень забавного сайта cakewrecks.com (только не ходите туда, если у вас нет по меньшей мере часа свободного времени). На сайте собрана коллекция по-идиотски украшенных тортов, логика их создателей не поддается объяснению, хотя Джен и предпринимает попытки сделать это. Так, одна из самых часто встречающихся и в книге, и на сайте тем – неверно понятые требования. Джен, конечно, не называет их требованиями, ведь это слишком формальный термин, вместо этого она употребляет слово «записи», так как исполнитель слушает и записывает, понимая буквально то, что слышит. Глядя на эти фото, я могу вообразить сотрудника кондитерской, который слушает заказчика и записывает его пожелания, а потом передает их кому-то, кто будет украшать торт.

Заказчик: «Здравствуйте, я хотел бы заказать торт».

Работник: «Конечно, что бы вы хотели на нем написать?»

З.: «Вы могли бы написать “Всего хорошего, Алиса” фиолетовым цветом?»

Р.: «Конечно».

З.: «А вокруг надписи пусть будут звезды».

Р.: «Без проблем. Я записал ваши пожелания и прямо сейчас передам их кондитеру-декоратору. Торт будет готов к завтрашнему утру».

Вот что получилось в результате.

Вот еще один пример. В разработке программного обеспечения такие вещи мы называем нефункциональными требованиями.

Все это очень весело, и можно посмеяться над 20 долларами, пропавшими зря. Но часто понесенные потери бывают куда более серьезными.

Может быть, вы слышали о неудачной попытке отправить в 1999 году на Марс орбитальный климатический зонд, в результате аварии которого NASA понесло убытки в размере 125 млн долларов[2]? Если не слышали, вот суть случившегося. Если когда-нибудь какой-либо проект по самые уши тонул в бумажной документации, это был, несомненно, проект NASA. Но несмотря на огромное количество требований и других документов, зонд вышел из строя по той простой причине, что NASA пользовалось метрической системой измерений, а инженеры партнерской компании Lockheed Martin, которые разрабатывали навигационные команды для двигателей аппарата, – британской. В результате никто не знает, где сейчас находится зонд, и некоторые надеются, что он нашел свое место на солнечной орбите где-то за Марсом.

Какая ирония – мы вкладываем огромные усилия в написание документов, чтобы общаться более ясно и избегать недоразумений, а в итоге получаем прямо противоположный результат.

Общие документы не дают единого понимания.

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

Единое (общее) понимание – это когда мы оба хорошо понимаем, что и почему представляет себе каждый. Очевидно, что между кондитерами и людьми, дававшими им инструкции, такого понимания не было. И в NASA какой-то важный начальник не обеспечил одинакового понимания того, как работает система управления, всеми участниками процесса. Уверен, если вы трудитесь в сфере разработки ПО, то быстро вспомните аналогичную ситуацию: два человека были уверены, что пришли к соглашению относительно функции, которую хотели добавить в проект, но оказалось, что они представляли себе совершенно разные вещи.

Единое понимание – это невероятно просто

Перейти
Наш сайт автоматически запоминает страницу, где вы остановились, вы можете продолжить чтение в любой момент
Оставить комментарий