Пользовательские истории. Искусство гибкой разработки ПО - [47]
Это мой друг Шериф, который работает в компании под названием Atlassian. Шериф занимается Confluence – популярной вики-системой, используемой огромным количеством организаций для хранения информации, с которой они работают, и управления ею наряду с прочим. Кроме того, они создали JIRA – один из самых популярных инструментов для управления разработкой по методологии Agile. Разумно предположить, что компания, которая специализируется на создании инструментов для электронного хранения информации и управления ею, и сама пользуется своей продукцией – как говорится, «сами ешьте еду своей собаки»[19], – и в Atlassian это действительно так. Но кроме того, в этой компании понимают, как важны плодотворные обсуждения историй лицом к лицу.
Осматривая офис Atlassian в Сиднее, я видел стены, увешанные стикерами, разрисованными досками и эскизами экранов. Присмотревшись, на стикерах можно было заметить номера задач в системах для управления работой, которыми пользовалась команда. Ребята ловко перемещались от систем к физическому пространству и обратно. Когда Шериф показал мне, как и что они хранят в Confluence, я был поражен сочетанием фотографий, коротких видео, а также множества обсуждений.
Борьба и единство радиатора и морозилки
В своей книге «Создание программного обеспечения как коллективная игра»[20] Алистер Коберн употребляет термин «информационный радиатор», чтобы описать, как информация, размещенная в комнате на видном месте, помогает работающим там действовать эффективно. Люди постоянно подходят, чтобы посмотреть на нее. Если эта информация актуальна и полезна, около стены разворачивается множество обсуждений, во время которых люди могут обращаться к записям, дополнять и развивать их.
Когда я захожу в комнату, где стены совершенно пусты или украшены пейзажами и натюрмортами, а то и кошмарными мотивационными плакатами, я здорово огорчаюсь. С помощью этих стен сотрудники могли бы развернуть эффективнейшую совместную работу! Но если то, что висит на стене, является информационным радиатором, то, очевидно, должны существовать средства, являющиеся информационным морозильником – местом, где информация должна храниться и, возможно, надолго оставаться погребенной под коркой льда, как продукты в морозилке у вас дома (я, например, регулярно нахожу там что-то неожиданное).
В Atlassian мне прежде всего бросилось в глаза то, что вся имеющаяся у них информация – как внутри, так и вне их инструментов – актуальна и полезна.
Представьте себе карточку из библиотечной картотеки. На ней имеется ровно столько информации, сколько нужно вам для управления карточками и подтверждения того, что вы обсуждаете нужную книгу. Хорошая карточка выглядит примерно так.
В общем случае на карточке, скорее всего, будет следующее.
• Короткое заглавие. Им легко оперировать во время обсуждения, когда вы говорите об этой истории. Хорошее название – самая полезная часть истории. Не стесняйтесь изменить его, если первоначальный вариант получился не совсем понятным.
• Описание. Одно-два предложения, описывающие то, как вы представляете себе ход истории. Хорошая идея описать здесь «Кто?», «Что?» и «Почему?»: кто использует эту функцию или нуждается в ней, что он будет с ней делать и какую пользу от этого получит.
По мере обсуждения историй вы будете добавлять информацию, которая подводит итог некоторых дискуссий. Здесь будут следующие элементы.
• Номер истории. Когда историй у вас будет много и вы захотите перенести их в трекинговую систему, номер поможет вам найти нужный, так же как десятичный код Дьюи помогает найти книгу в библиотеке. Но, что бы вы ни делали со своими историями, пожалуйста, не называйте их по номерам! Если вас так и тянет называть номер вместо названия – это верный симптом того, что название неудачное. В конце концов, библиотекари же не называют книги по номеру в десятичной системе Дьюи!
• Оценка трудозатрат, размер или бюджет. Когда вы начнете обсуждать историю, вам непременно понадобится прикинуть, сколько времени займет разработка этого программного обеспечения. Эту величину можно назвать по-разному, например оценка времени или трудозатрат, размер или бюджет. Пользуйтесь термином, принятым в вашей организации.
• Важность. Возможно, вы будете долго спорить о важности одной истории по сравнению с другой. Одним нравится использовать числовую шкалу, а другим – помечать карточки наклейками с текстом «Высокая», «Средняя», «Низкая».
• Параметры. Если вам и в самом деле важны результаты, укажите особые параметры, которые будете отслеживать после выпуска программного продукта, чтобы убедиться в его успешности.
• Зависимости. Другие истории, от которых данная история может зависеть или быть с ними тесно связанной.
• Статус. Запланирована ли история для определенного релиза? Началась ли работа над ней? Идет ли разработка? История завершена?
• Даты. Как на библиотечной карточке имеется дата издания книги, так и на вашей карточке нужно фиксировать даты, когда история была добавлена, принята в разработку и завершена.
