Введение
Большинство привычных методов управления проектами основаны на скрупулезном расставлении всех точек над i еще до начала разработки. Требования к проекту должны быть разработаны, прописаны и проанализированы со всех возможных точек зрения еще до начала непосредственной работы над проектом. Противники этого подхода считают, что основным залогом успеха является гибкость, которая заключается в том, чтобы планировать на ходу, начав с приблизительной идеи, а затем внося изменения в процессе разработки. Тем не менее обе точки зрения весьма далеки от истины. Да, основная цель проекта заключается в том, чтобы получить обратную связь уже после первого релиза. Вполне естественно, что последующие изменения должны вноситься исходя из полученных отзывов. И, разумеется, в процессе разработки необходима определенная гибкость для внесения корректировок или даже полной смены направления разработки, если это необходимо. Тем не менее эти задачи должны быть реализованы упорядоченным образом, в соответствии с общим видением цели проекта и на основе успешных бизнес-решений. На первый взгляд гибкость и хаотичность могут казаться двумя сторонами одной медали, однако на самом деле гибкость позволяет реализовать более продуманный подход к управлению проектом, чем традиционные методы. Гибкие подходы требуют меньше усилий на подготовку, что, в свою очередь, ведет к более разумному распределению ресурсов. Вместо того чтобы планировать все заранее, Agile создает возможность получения результата уже на ранних этапах и позволяет добиваться стабильного прогресса на протяжении всего проекта. Гибкие подходы определяют конкретную цель с самого начала и предоставляют инфраструктуру для ее реализации, при этом не тратя времени на то, чтобы углубляться в детали до начала работы.
Определение видения
Недальновидные люди обречены на гибель. Моисей сказал это четыре тысячи лет назад, но большинство руководителей проектов до сих пор не понимают, что он имел в виду. Если мы не знаем, куда идем, то мы вряд ли доберемся куда-либо – и это особенно верно, когда речь идет о проектах. Люди часто имеют различные представления о том, чего и как они хотят добиться, и в итоге получают различные результаты. Четкое определение видения необходимо для успешного проекта. К сожалению, большинство проектов дают определение видению с помощью расплывчатых заявлений миссии, которые при более пристальном рассмотрении нередко оказываются бессмысленными:
• Мы предлагаем исключительное качество.
• Интересы наших покупателей для нас на первом месте.
• Мы будем лучшими в нашей сфере, и нас все будут любить.
Утверждения хорошие, но абсолютно бесполезные: с ними сложно поспорить, но использовать их для реализации практических бизнес-задач не представляется возможным.
Удача – это пересечение пространства возможностей и готовности ими воспользоваться.Дензел Вашингтон
Видение должно быть инструментом для вас. Вы можете его использовать для любых коммуникационных целей. Также видение полезно, когда вам нужно решить, что именно вы собираетесь делать, а чего не собираетесь. Наконец, оно важно в тех случаях, когда вам необходимо определить приоритетность задач. Видение проекта – это не столько общая формулировка целей, сколько практический инструмент для того, чтобы помочь вам сконцентрироваться на их реализации. Вы всегда должны быть готовы изменить или обновить видение, когда оно перестанет быть актуальным (а это рано или поздно обязательно произойдет).
В качестве примера использования видения давайте представим, что мы – компания, которая собирается продавать овощи в рестораны. Видение поможет нам понять, что конкретно это значит.
В конце сентября компания Project VegBox разработает новое приложение для iOS, с помощью которого покупатели смогут заказать доставку овощей в их рестораны, выбрав из десяти возможных наборов. В результате этого наш бизнес создаст новую линию продукции, расширив отдел, занимающийся овощами, а наши клиенты получат возможность быстро и удобно закупать овощи по оптовым ценам.
Видение объясняет, что именно мы собираемся сделать. Оно должно учитывать особенности целевой группы, платформы и продукта, как, впрочем, и сроки. Однако самое главное, чтобы видение могло объяснить значимость проекта для компании и потребителя.
Определение видения проекта
• Как называется проект или продукт, который вы производите?
• Для кого он предназначен?
• Когда он должен быть закончен?
• Что он делает?
• Чего он не делает?
• Какая выгода для вашего бизнеса от использования этого продукта?
• Какую выгоду получит клиент от использования этого продукта?
Описание видения должно быть составлено так, чтобы даже ваши мама и папа могли понять, что вы собираетесь сделать.
Блистательный пример
Семейный уик-энд не требует тщательного планирования. Более чем достаточно сойтись в основном: место назначения, что с собой брать и как добраться. Нет необходимости расписывать все по минутам и прорабатывать все возможные сценарии. Самое главное – это определиться, пойдете ли вы в тематический парк, будете отдыхать на пляже или посвятите день шопингу. Если конечная цель определена, все остальное – уже вопрос выбора методов, как до нее добраться.
Руководствуясь идеей бизнес-ценности
Слишком многие проекты начинаются с не до конца оформившейся идеи. Кому-то на руководящей должности или с деньгами, которые можно потратить, внезапно приходит в голову идея – и вот уже этот локомотив, который невозможно остановить, мчится неведомо куда. Конечно, далеко не всегда проекты начинаются с чьей-то прихоти, но не исключайте и того, что не всегда есть хорошие основания для старта проекта, несмотря на убедительные рассказы главного менеджера или полных энтузиазма умников компании. Всегда проявляйте должную осмотрительность – существует вероятность того, что было принято неразумное инвестиционное решение.
Гибкие подходы полностью сосредоточены на наибольшей бизнес-ценности. С начала и на протяжении любого проекта бизнес-команда должна точно знать, на что она собирается тратить свои деньги.
Блистательное определение
Люди упоминают получение отдачи от проекта так часто, что это уже стало бессмысленным. Что значит эта «отдача»? Рассуждайте в понятиях выгоды. Какую выгоду проект принесет заказчику или бизнесу? Успешный проект выгоден для всех.
Agile не определяет четко, что такое бизнес-ценность или «красота в глазах зрителя». Гибкие подходы служат основой того, чтобы деньги, заработанные с определенным трудом, были инвестированы с пользой. Agile облегчает и обеспечивает принятие разумных решений, но ничего более. Можно привести лошадь на водопой, но нельзя заставить ее пить.
Каждый выпуск продукта, каждая особенность, каждый нюанс – все это должно быть обговорено. Прошли те времена, когда от человека к человеку передавался лист с требованиями на техническом жаргоне или иностранном языке, который бизнесмены не до конца понимают. И совсем в прошлом времена, когда заказчик слепо доверялся людям, которых едва знает. В Agile бизнесмен описывает, что ему нужно, и затем работает с командой проекта, чтобы убедиться в том, что видение реализовано именно так, как задумано.
Кроме того, определив в точности, что необходимо, заказчик определяет это как необходимый минимум – и с этого начинает добавлять другие кирпичики. Первый выпуск продукта может не иметь всех «свистулек», но он должен быть работающим, реализовывать товар или услугу и быть выпущен как можно быстрее. Инвестируем в X, затем в Y – получаем последовательный выпуск продукта; это правило должно соблюдаться в течение всех этапов разработки и быть совершенно прозрачным.
Блистательная мысль
Если вы не знаете, что хотите построить (видение), какую выгоду получите (реализация товара или услуги) и для кого ваш проект (конечный потребитель), то, будь у вас даже лучшие эксперты в мире, вы все равно не получите никакого стоящего результата.
Формирование команды проекта
Многие люди старательно собирают в команду лучших людей, которых могут найти, – специалистов с соответствующим опытом, экспертов в своей области – и затем все портят, не предоставляя адекватного понимания бизнеса и лидерства. Не ставьте телегу впереди лошади! Важно достичь правильного уровня участия бизнеса в проекте – включить одного человека, который понимает видение бизнеса. Это не просто практично и прагматично, но и логично с точки здравого смысла.
В Agile этого человека обычно называют «владельцем продукта» (Product Owner), но существуют и варианты названия. Конечно, в этой блистательной книге его стоило бы называть «руководителем продукта», но для начала остановимся на простом определении. Владелец продукта представляет интересы бизнеса и конечного пользователя. Владелец продукта живет, дышит и мечтает о продукте и о том, каким он должен быть. Такие люди знают, чего именно хотят, даже если не знают способа, как этого достичь. Они лидеры, способные быстро принимать решения и отстаивать их.
Agile-команда – разнообразная, многофункциональная группа индивидуумов, способных воплотить видение от имени бизнеса. Проще говоря, у них есть все, чтобы выполнить работу надлежащим образом. Владелец продукта указывает путь только в плане бизнес-видения, но и это большой вклад в работу команды. Команда состоит из людей с гибким мышлением, не боящихся изменений и не считающих, что бюрократия – решение всех проблем. Уверенно принимающие решения, проявляющие инициативу деятельные люди подойдут лучше всего.
В определение видения и всех аспектов, касающихся выпуска продукта, должна быть вовлечена вся команда. Если поступать не так, возникнут сложности.
Создание журнала требований
Когда определены видение и то, какую выгоду проект должен приносить, следующий шаг для команды проекта – записать требования в возможных деталях. В центре каждого проекта – список требований, который в Agile называется журналом требований продукта, или бэклогом (Product Backlog). Он заменяет традиционное, подробное техническое задание и представляет собой список важных для бизнеса идей. Элементы журнала всегда ориентированы на конечного пользователя продукта, даже если речь идет о технической части проекта. Они должны быть понятны любому.
Важно, чтобы с самого начала команда проекта выработала коллективное видение, чтобы быть уверенными, что все понимают цели, содержание проекта и способы их концептуализации. Убедитесь, что все на одной волне с самого начала – это проще, чем потом пытаться исправить готовый на две трети продукт. Многоплановость команды также важна, потому что важно иметь возможность посмотреть на проблему под разными углами. Если необходимо, специалисты будут помогать друг другу.
Как сделать так, чтобы с самого начала все пошло наперекосяк
• Заявлять, что Agile – универсальное средство, даже для не предназначенных для него областей.
• Говорить, что тут все очевидно и любой дурак сможет справиться, так что никакого обучения не нужно.
• Считать, что Agile непогрешим, а неудачи происходят из-за личных недостатков.
• Устанавливать нереалистичные цели и сроки, оправдывая это тем, что в дивном новом мире Agile все возможно.
Определите базовую функциональность
Цель состоит в том, чтобы составить сводный список того, что необходимо для воплощения видения проекта. Есть несколько способов это сделать, и наш любимый подход – подумать о каждом шаге клиента, чтобы спланировать рабочий процесс.
Создайте функциональные группы
Как только определен или составлен рабочий процесс, соберите вместе все идеи насчет того, что необходимо будет сделать на каждом шаге этого пути. Подобная группировка этих элементов обеспечивает описание функциональности шага и может называться функциональными группами. Какие-то детали будут совершенно необходимы, а другие можно отнести к категории приятных дополнений. Их стоит упорядочить с самого начала.
Приоритетность характеристик
Опираясь на видение проекта и здравый смысл, определите приоритет каждого элемента в нисходящем порядке – от самого важной в каждом списке.
Определение первого выпуска
Как только вышесказанное будет сделано, обдумайте каждый важный шаг в движении к заказчику от первого дня до реализации и что является самой ценной частью идеи в рамках этих шагов. Такой выбор может быть сложным и в конце концов зависеть от мнения, но мнение заказчика – или того, кто представляет собой его бизнес, – имеет решающую роль. Конечный результат шагов – тот приемлемый минимум для заказчика, которого проект должен достичь в этом шаге. Это обычно называется минимально жизнеспособным продуктом (minimum viable product, MVP) или минимально жизнеспособным выпуском (minimum viable release, MVR).
Один из больших плюсов – быстрое получение важной обратной связи от конечных пользователей, однако, чтобы составить свое мнение, им необходимо что-то довольно существенное. Невозможно получить значимую обратную связь о техническом процессе, но о новой форме заказа VegBox – вполне. Естественно, это будет частью минимально жизнеспособного продукта.
Стоить помнить, что чем больше всего будет в минимально жизнеспособном продукте, тем больше времени потребуется для получения обратной связи, тогда как если продукт будет слишком мал, будет недостаточно информации для получения обратной связи. Вам придется найти баланс между прибылью и риском – никакого универсального правила тут нет. Постарайтесь найти точку, в которой вы получите полезные отзывы о чем-то, что поможет вам принимать обоснованные решения. Это будет полезно и для анализа рынка.
Также обращайте внимание на термины. Для кого-то слово «выпуск» будет означать доступный для использования продукт, для других – продукт, предназначенный для тестирования закрытой группой. Помните, что всегда существует возможность сначала представить продукт малой группе, а уже потом выпустить продукт соответствующим образом. Главное, не делайте допущений, что все понимают термины одинаково! Нет абсолютно правильных подходов – выберите тот, что лучше подходит вам.
Добавление характеристик
Как только определено, что будет в минимально жизнеспособном продукте (MVP) или минимально жизнеспособном выпуске (MVR), начинается настоящее веселье. Дополнительный функционал или новые характеристики продукта могут добавляться по частям или быть частью большого релиза. Это называется инкрементная поставка, и бизнесмены ее очень любят. Никаких больше долгих лет ожидания одного большого выпуска со всеми «свистульками». Выпуск продукта в Agile-разработке происходит быстро и часто. И, опять же, именно заказчик определяет, что и когда выпускать. Как минимум отдельный выпуск должен содержать одну характеристику, проверенную практикой.
Получение информации
Результаты нашего первого релиза – наш MVP – достаточно эфемерны, и нам нужно больше деталей, чтобы превратить их в полноценный продукт. Польза этих результатов заключается в том, что на данном этапе мы формулируем идеи, поэтому было бы бесцельно вырабатывать полноценный профиль продукта, который необязательно будет использован. Более чем достаточно выработать общее видение и сформулировать MVP, при этом не реализовывая сам продукт. На следующем этапе нам предстоит выяснить положительные и отрицательные стороны продукта. Классический инструмент решения данной задачи – пользовательская история.
Расскажи мне историю
Пользовательские истории (user story) – короткие простые описания характеристик продукта с точки зрения человека, который собирается его использовать. Обычно это пользователь или покупатель. Пользовательские истории обычно следуют простому формату.
Будучи <тип пользователя>, мне нужно <цель> по <причина>.
Пользовательская история – это абстрактная концепция, которая предоставляет достаточно информации, чтобы команда могла реалистично оценить ресурсы, необходимые для реализации проекта. Пользовательские истории часто записываются на стикерах или карточках, которые затем развешиваются на стенах или раскладываются на столах, чтобы облегчить процесс планирования.
Пользовательская история позволяет сфокусироваться на обсуждении характеристик продукта, что является важным шагом после выработки основного представления об этих характеристиках.
Никто не заставляет вас использовать пользовательские истории. Однако эти истории напоминают нам о важности коллективных обсуждений, и результаты этих коллективных обсуждений нередко важнее подробного плана работ.
ДАТА ДОСТАВКИ
БУДУЧИ НЕПОСТОЯННЫМ ПОКУПАТЕЛЕМ
МНЕ НУЖНА ГАРАНТИРОВАННАЯ ДАТА ДОСТАВКИ В МОМЕНТ СОВЕРШЕНИЯ ЗАКАЗА
ПО ПРИЧИНЕ ТОГО, ЧТО Я ДОЛЖЕН ЗНАТЬ, КОГДА ОЖИДАТЬ СВОЙ ЗАКАЗ, ЧТОБЫ ОН НЕ СГНИЛ ПОД ДВЕРЬЮ
В ходе этих обсуждений определяются ключевые аспекты главнейших характеристик продукта. Помните, записи сами по себе ничего не значат, однако живое коллективное общение позволяет нам не только выработать основополагающие детали, но и сохранить свежий взгляд на проект. Выигрышно во всех отношениях.
Выработка критериев принятия
Как мы узнаем, что мы сделали все? Это ключевой вопрос, и именно с него следует начинать дискуссию, следующую за обсуждением пользовательской истории. Чтобы действовать эффективно, нужно знать, когда остановиться. Когда заканчивается наш проект? Сколько сил мы должны вложить в него? Как избежать переработки и неизбежной фрустрации? Для успешного использования пользовательских историй мы должны выработать критерии принятия – предпосылки к проекту, которые должны быть реализованы, чтобы история была оценена как выполненная.
Не существует единственно правильных критериев принятия. Они могут быть как простыми, вроде условий удовлетворенности работой, так и очень подробными. В рамках Agile лучшими критериями принятия являются односложные оценки, написанные простым и понятным языком. Рассмотрим пользовательскую историю, связанную с датой доставки, и применим к ней критерии принятия:
• Дата доставки – всегда будет на следующий рабочий день после заказа.
• Если заказ был оставлен в субботу, то доставка будет в понедельник.
• Заказы на следующий рабочий день принимаются до трех часов по полудню.
• Клиент получает подтверждение о заказе по электронной почте.
• Все продукты в наличии доставляются по этим правилам.
• Мы сообщаем день заказа, но не точное время.
• У пользователя должна быть возможность оставить комментарий для курьера.
• Ожидаемый день доставки будет показан на экране при заказе.
Критерии принятия, написанные командой разработки, являются самым предпочтительным способом учесть все мелочи. Под руководством владельца продукта или бизнес-представителя команда может обсуждать пользовательские истории, устранять любые двусмысленности и определять конечный результат. Это лучший способ добиться согласованной работы, и эти обсуждения не должны быть длительными или трудоемкими. Их можно сделать как раз перед началом основной работы над проектом; цель состоит именно в том, чтобы начать с конца!
Кроме того, по критериям принятия можно отслеживать прогресс выполнения работ. Зачастую бизнесменов беспокоят расплывчатые фразы вроде «мы почти закончили» или «полагаю, мы на верном пути». Поэтому критерии принятия могут служить вехами на пути к завершению работ: мы реализовали половину из заявленных критериев принятия. Если критерии сформулированы должным образом, отслеживание прогресса будет легким – и все будут понимать, следует беспокоиться или нет.
Разделяя истории
Иногда в результате плодотворных обсуждений появляется очень много материала. Это хороший признак, не волнуйтесь и продолжайте записывать обсуждение. Некоторые идеи могут не подходить пользовательской истории, над которой вы сейчас работаете, или быть для нее слишком продвинутыми. Как только вы это поймете, сможете такие идеи отфильтровать и в дальнейшем добавить в более подходящие истории.
Другой подход заключается в том, чтобы написать новую историю – так называемое разделение историй. Типичный пример – ситуация, когда владелец продукта считает некоторые из критериев принятия необязательными и хочет выработать новую историю, включающую в себя дополнительные характеристики продукта. Как только новая история написана, она может быть включена в журнал требований (бэклог) вместе со всем остальным.
При написании историй очень важно знать, когда остановиться. Чем сложнее история, тем меньше вероятность того, что она будет полезна. Чрезмерно широкие критерии принятия – важный индикатор того, что что-то пошло не так. Обычно это значит, что историю надо разделить. Нередко вам придется разделять истории несколько раз, и в этом нет ничего плохого – наоборот, это прекрасный способ сделать работу над проектом более реалистичной.
– И нашему пользователю сразу будет понятно, где аварийный выход!
Когда размер имеет значение
Итак, у нас есть видение, бэклог, MVP, также набор продуманных пользовательских историй вместе с четкими критериями принятия. Отличная работа. Теперь стоит задаться вопросом: сколько времени и сил потребует практическая реализация всего этого? Обычно ответ на этот вопрос дают руководители проекта или профильные специалисты. Однако в Agile-проектах этим вопросом занимаются люди, непосредственно ответственные за реализацию проекта. Они не только смогут предоставить более реалистичную оценку. Это также позволит сплотить команду. Конечно же, от размера каждой пользовательской истории зависят сроки реализации MVP, как и проистекающие из этого характеристики. Тем не менее это все еще прекрасный способ оценить возможные проблемы с реализацией конкретных этапов проекта. Если вы видите, что члены команды чешут затылки, тяжело вздыхают и качают головами, то это не очень хороший знак.
Ряд оценочных техник исключительно хорошо подходит для Agile-проектов, например:
• Размеры одежды. Присвойте ярлычки S, M, L, XL и XXL каждой составляющей проекта, чтобы оценить приблизительное количество ресурсов, которое потребует ее реализация. Отличный способ для начинающих, который, впрочем, далеко не всегда точен.
• Оценочный подход. Используйте фиксированную шкалу, чтобы оценить трудозатраты для реализации составляющих проекта, например, на шкале от одного до ста 1 будет означать «очень легко», а 100 – «исключительно сложно». Данный подход начинает работать далеко не сразу, но у него много приверженцев.
• Принцип схожести. Распределите все истории в зависимости от их размера – от малых до больших. Затем присвойте значение 1 самой маленькой истории, после чего оцените все последующие истории соответственно. Прекрасный способ, чтобы оценить MVP.
Лучший способ выработать здравые оценки:
• Используйте открытый журнал требований.
• Не игнорируйте запутанные пользовательские истории.
• Большие, сложные и многофункциональные истории делают все интереснее.
• Надейтесь на лучшее.
• Не позволяйте сомнениям остановить вас.
• Не беспокойтесь – оценки все равно обычно бывают неверны.
Меньше значит больше
За пределами мира Agile-проектов практически всегда начинаются с игры в кошки-мышки. Бизнес-команда инстинктивно чувствует, что она должна просить все на свете и немножечко больше, потому что когда еще это делать, как не в начале проекта. Она также осознает, что, когда проект летит под откос – а это происходит всегда в той или иной форме, – это негативно скажется на количестве и качестве результатов. Поэтому основная стратегия бизнеса – просить все, чтобы на выходе получить хоть что-то.
Разработчики прекрасно понимают это и вполне положительно относятся к закладыванию в проект пространства для маневра. Проблемы начинаются тогда, когда проект предсказуемо катится в тартарары, но ряд изначально заложенных результатов уже находится в стадии реализации, и перед разработчиками встает дилемма относительно того, что делать с вложенными в эти промежуточные результаты ресурсами и усилиями. Когда время и (или) деньги разработчиков начинают подходить к концу, нередко оказывается, что самые важные задачи до сих пор не выполнены: например, в случае с реновацией дома не имеет смысла вкладывать последние деньги в высокотехнологичную кухню, если в ванной еще даже не начиналась побелка. Конечно же, здравый смысл подсказывает нам, что всегда стоит начать с реализации самых минимальных требований к проекту, но не стоит думать, что после их выполнения работа автоматически заканчивается. Обе стороны – и заказчик, и разработчики – должны быть уверены в том, что проект не заканчивается после первого рабочего прототипа и процесс улучшения и доведения до ума финального продукта продолжится и в дальнейшем. Доверие – важный залог успеха, но понимание важности поэтапной реализации задачи является основой Agile. При наличии этого понимания вероятность того, что проект скатится под откос вместе со всеми ресурсами, затраченными на его реализацию, сравнительно невелика, если, конечно же, первоначальная идея проекта не была абсолютно нереалистичной – но в этом случае проблема отнюдь не в Agile.
MVP – это абсолютный минимум, необходимый для начала использования или работы. Использование каждой функциональности или нюанса должно быть результатом рационального выбора. Критерий отбора прост: если MVP работает без этой характеристики, то она не нужна. На практике вы безусловно можете допустить наличие пары не совсем необходимых характеристик – до тех пор, пока их реализация не начинает отнимать ресурс у основной цели. Ваша цель – выработать набор требований к проекту, который можно быстро и беспрепятственно реализовать.
Как только команда и заказчик привыкают использовать этот подход, его преимущества становятся абсолютно очевидны: ускоренное время выхода продукта на рынок является ключевым элементом конкурентоспособного бизнеса. Кроме того, очень сложно предсказать идеальный профиль будущего продукта, поэтому гораздо разумнее вносить изменения в уже реализованный продукт. Гораздо приятнее обсуждать возможные улучшения продукта после того, как он вышел на рынок и его основные характеристики уже реализованы. Ничто не помешает команде вернуться к длинному списку дополнительных характеристик, которые ожидают своего воплощения.
Блистательная мысль
Отдел финансов редко выступает инициатором перехода к Agile, но его работники обычно очень положительно воспринимают данный переход, если объяснить им все его преимущества. Сокращение периода адаптации проекта для выхода на рынок, поэтапная реализация проекта и быстрый возврат инвестиций – все это звучит как райская музыка для людей, которые привыкли работать с деньгами. Достаточно сказать им, что гибкие подходы положат конец бесконечным спиралям бессмысленных бюджетных трат, – и эти люди ваши. Не забывайте о том, что они могут быть очень полезными союзниками!
Менеджмент рисков и ожиданий
В случае правильной реализации Agile-проекты должны быть избавлены от типичных проблем, которые преследуют обычные проекты. Менеджмент рисков и ожиданий является неотъемлемой частью Agile-подходов, которые построены на максимальной прозрачности рабочего процесса. Основной риск для Agile-проектов заключается в отсутствии понимания того, как именно функционирует гибкая разработка, поэтому повторите это еще раз.
• Не забрасывайте испробованные и надежные практики. Многие разработчики пытаются менять слишком многое слишком часто. Придерживайтесь плана и вносите изменения по одному. Если изменения не работают, откажитесь от них.
• Говорите. Говорите. ГОВОРИТЕ. Отсутствие взаимодействия между людьми – источник всех зол. Отсутствие информации является не менее губительным, чем плохая информация. Используйте регулярные отчеты о проделанной работе для гарантии того, что вы обсуждаете что нужно и когда нужно.
• Избегайте чрезмерно масштабных задач. Чем больше требований, тем сложнее их понять. Всегда старайтесь разбить большие задачи на несколько маленьких и более доступных задач.
• ПРОДОЛЖАЙТЕ ГОВОРИТЬ. Лучший способ избежать рисков при использовании гибкой системы разработки – это постоянно поддерживать контакт с окружающими вас людьми.
Блистательная мысль
Лучший способ привести все к краху – это формально адаптировать проект под Agile, продолжая работать с ним, как с обычным проектом. Бойтесь овец в волчьих шкурах.
Ведение журнала требований
Значение журнала требований невозможно переоценить. Это краеугольный камень вашего проекта. Тем не менее даже самый лучший журнал требований будет бесполезен, если вы его не ведете. Журнал требований – это живой организм, требующий внимания. Если использовать его должным образом, то журнал требований поможет вам понять, что происходит, найти общий язык с другими участниками проекта, уменьшить риски и контролировать ожидания. Если вы не уделяете журналу достаточно внимания, он будет просто отнимать время и сбивать с верного пути. Ведите ваш журнал требований!
В начале проекта журнал будет полон функциональных требований и характеристик, записанных в виде пользовательских историй. По мере развития проекта там будут появляться новые записи и пользовательские истории – это лишь один из возможных примеров создания элементов журнала. Основная задача журнала – сделать работу над проектом видимой, включая неудачи, бесполезные характеристики, возможные улучшения, новые идеи – вообще все. Записывайте и перерабатывайте их, а затем сортируйте в зависимости от их ценности.
Журнал требований принадлежит владельцу продукта, который несет за него ответственность. Владелец продукта не должен прекращать работу над журналом, он должен постоянно обновлять и использовать его как основу для ведения дел со всеми заинтересованными сторонами. Вносить изменения в журнал постоянно нелегко, но плюсы перевешивают неудобства. Прозрачность разработки – залог доверия, и лучший способ ее добиться – вести открытый для всех журнал.
Лучше всего, если владелец продукта и команда просматривают журнал каждый день. Это может быть частью постоянной рабочей практики или частью любой презентации, посвященной проделанной работе. Иногда ведение журнала занимает часы, а иногда минуты, однако важно обновлять записи постоянно.
Создание рабочей среды
Успех проекта, использующего Agile, в наибольшей степени зависит от его участников и того, как они взаимодействуют друг с другом. Нередко заставить людей эффективно взаимодействовать друг с другом довольно трудно, и рабочая среда играет в этом процессе ключевую роль. Самые успешные проекты – это те, участники которых сфокусированы на результате, работают в одном офисе и не имеют проблем с доступом к владельцу продукта. Не менее важно, чтобы у разработчиков перед глазами всегда была доска с задачами и, что особенно важно, журнал требований продукта. Работа в одном помещении снимает основную часть проблем, связанных с коммуникацией, позволяя не только эффективно взаимодействовать, но и налаживать личные связи, обсуждая то, кто и как провел выходные.
Блистательная мысль
Статичный журнал требований – признак грядущих неудач. Стоит обеспокоиться, если журнал не обновляется.
Впрочем, давайте будем реалистами. В идеальном мире мы все работаем в одном офисе, часто смеемся, остроумно шутим и не имеем проблем с зубами, но на практике некоторые из нас регулярно опаздывают на работу, мы часто работаем в разных городах и нередко целыми днями пропадаем в офисе заказчика. Независимо от обстоятельств, видимость и прозрачность взаимодействия является залогом успеха, но добиться этого на практике часто оказывается нелегко. Видеозвонки, электронные списки задач на гигантских тачскринах и переговоры в Скайпе далеки от идеала, однако лучше иметь что-то, чем ничего. Если, и это действительно очень важно, при всем при этом мы регулярно делаем записи в журнал, то все эти ухищрения могут сработать.
Для тех команд, которые не уверены в достижимости целей проекта и члены которых не знают своих точных обязанностей и последовательности выполнения задач, нет оправданий. Если между собой команда не разговаривает, значит, что-то пошло не так, и горькая правда состоит в том, что из-за этой рабочей среды падает производительность. Значимость эффективной коммуникации сложно переоценить; если у команды есть желание обсуждать рабочий процесс, они обязательно найдут способ, как это сделать.
Если вы не знаете, куда идете, то и придете куда-нибудь.Йоги Берра (американский бейсболист)
Завершающие слова
Любая попытка начать проект без четкого видения приведет к неудаче, так как в этом случае вам придется вырабатывать видение на лету. Прочный фундамент исключительно важен для любого созидательного процесса. Даже самая лучшая команда не сможет добиться успеха, не имея точной цели с самого начала. Выработать представление о конечном результате до начала проекта нелегко, но это единственный вариант.
Однако даже при наличии фундамента реализация проекта не похожа на легкую прогулку. Для успешной реализации поставленных задач вам понадобится журнал требований продукта; к счастью, для его создания вам не нужно составлять полный и детальный список требований. Не имеет смысла тратить время на создание гор документации для проекта, который, возможно, не увенчается успехом. Создание журнала требований может быть относительно быстрым примером коллективной работы, которая, при должной реализации, может оказаться интересной.
В случае с Agile-проектами сдача первых результатов не должна восприниматься как приговор. Первый результат представляет собой тот минимум, который необходим для того, чтобы запустить бизнес. Чем быстрее вы сможете реализовать последующие этапы проекта, тем продуктивнее будут первые результаты. Не откладывайте на завтра то, что можно сделать сегодня. Следите за развитием бизнеса и с удовольствием включайтесь в новый мир Agile.
Блистательный итог
• Начните с конкретного и рационального видения. Избегайте неясных и нереалистичных целей.
• Бизнес-ценность превыше всего, поэтому убедитесь, что вы и ваши коллеги имеют общее представление о том, что это такое.
• Любите ваш журнал требований продукта. Поддерживайте журнал на должном уровне и убедитесь, что в нем хватает пользовательских историй, понятных всем.
• Определитесь с MVP! Успех проекта зависит от того, как хорошо и быстро вы справитесь с этой задачей.
• Выработайте критерии принятия и всегда держите в голове конечный результат.