Пользовательские истории. Искусство гибкой разработки ПО - [45]

Все эти вопросы и предположения могут потребовать дополнительного исследования или изучения. Составьте для этого особый план.

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

 Обсудите «Как?». Очень часто, присутствуя на обсуждении историй, я слышу чей-то раздраженный голос: «Мы должны обсуждать, что мы делаем, а не как!». Под этим обычно подразумевается, что нужно обсуждать действия и мотивы пользователей, а не код, который необходимо написать. А я чувствую точно такое же раздражение, когда мы говорим только о «Что?», не затрагивая «Почему?». В действительности при хорошем обсуждении мы стремимся к оптимизации всех трех составляющих. На самом деле нехорошо, когда кто-то предполагает, что определенное решение или какой-то способ технической реализации является требованием. Поэтому без явного обсуждения «Как?» (а если вы разработчик, вы неизбежно думаете об этом аспекте) очень трудно оценить стоимость решения. А слишком дорогое решение никак не может быть наилучшим.

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

 Обсудите, сколько времени понадобится. В конце концов все-таки приходится принять несколько решений, чтобы продвинуться вперед и что-то построить или не построить. Эту ситуацию можно сравнить с решением о покупке товара, не имеющего ярлычка с ценой.

В мире программного обеспечения понятие стоимости в первую очередь связано с временем, которое потребуется на написание кода. На ранних этапах вполне допустимо использовать понятия «очень долго» или «пару дней». Еще лучше сравнить то, что вы обсуждаете, с чем-то уже законченным: «Это похоже на те улучшения для комментариев, которые мы реализовали в прошлом месяце». По мере того как мы все ближе подбираемся к началу разработки, все дольше обсуждаем и принимаем все больше решений, оценки трудозатрат должны становиться все более точными. Но не забывайте: в любом случае мы говорим лишь об оценках, а не об обязательствах.

Сделайте «фото из отпуска»

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

Если вы пишете на бумаге, прихватите ее с собой и заглядывайте в нее позднее. Если записи сделаны на стене, можно просто обращаться к ним по мере надобности. Кроме того, если вы общаетесь как настоящая команда, то обнаружите, что вам не нужно беспрестанно все повторять. Люди и так будут помнить подробности обсуждения, особенно если вы сопровождали его документами и простыми рисунками… теми самыми «фото из отпуска».

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

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

Придется о многом позаботиться

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

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

Глава 8. Не бросайте на карту всё

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