Книга: Пользовательские истории. Искусство гибкой разработки ПО

Истории надо рассказывать, а не писать

Истории надо рассказывать, а не писать

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

Еще до того, как я в полной мере осознал, почему истории получили такое название, я понял, что могу написать множество историй – в виде предложения или краткого заголовка, на карточках или стикерах. Я могу менять их местами и расставлять в соответствии с приоритетом, выбирая самые важные из них. Как только я решу, что одна из историй более важная, чем другая, можно начать ее обсуждение. Это было суперкруто! Почему я раньше не записывал ничего на карточках, чтобы удобно было организовать работу таким образом?

Проблема была в том, что одна карточка могла представлять собой нечто, внедрение чего в продукт заняло бы у разработчика несколько часов. Или дней. Или недель. Или целый месяц – кто знает? Точно не я – во всяком случае, пока мы не начнем говорить об этом.

Начав обсуждение истории во время работы над своим первым проектом Agile, я невольно вызвал неприятный спор, когда оказалось, что история слишком велика. Мне хотелось, чтобы он был реализован в течение следующей итерации, но разработчики, с которыми я разговаривал, доказали мне, что это невозможно. У меня было смутное ощущение, что я что-то делаю не так. Разработчики выделили небольшую часть, о внедрении которой на следующей итерации можно было говорить, но я был раздражен тем, что нам не удалось поговорить масштабно, рассмотрев все в целом. На самом деле мне хотелось знать, сколько времени займет разработка большой функциональности, которую хотелось получить в итоге. Я надеялся, что дискуссия поможет мне оценить это, но ничего не вышло.

Оглавление книги