Дисциплинированное исполнение методов гибкой разработки (Disciplined Agile Delivery - DAD) - это набор методов, предложенный IBM, чтобы помочь большим группам разработчиков программного обеспечения успешно применять методы гибкой разработки, как это делают более мелкие группы. DAD ― не просто еще один метод гибкой разработки; это гибридная модель, в которой собраны практические рекомендации, взятые из опыта применения проверенных методов гибкой разработки. Кроме того, DAD дополняет обычные методы гибкой разработки рекомендациями, учитывающими условия предприятия. В результате организации с проектными группами, состоящими более чем из 20 человек, могут извлечь из методов гибкой разработки максимум выгод. При формировании DAD-групп нужно учитывать ряд моментов. Основные пять из них являются предметом этой статьи.
Agile Manifesto, опубликованный в 2001 году, определил основной дух методов гибкой разработки. Позднее IBM выдвинула набор методов под общим названием "Дисциплинированное исполнение методов гибкой разработки" (Disciplined Agile Delivery - DAD), чтобы помочь большим группам разработчиков программного обеспечения добиваться таких же успехов, каких в последнее десятилетие добивались небольшие группы. Дело не в том, что существующие, обычные методы гибкой разработки недостаточно "дисциплинированы"; напротив, большинство этих методов требует больше дисциплины и строгости исполнения, чем традиционные или специализированные методы. Однако в сложных условиях предприятия эти рекомендации не всегда учитывают реалии крупных проектов гибкой разработки.
DAD представляет собой гибридную модель, в которой собраны лучшие практические рекомендации широко применяемых и проверенных методов гибкой разработки, таких, как Scrum, XP, Crystal, FDD и DSDM. Хотя каждый из этих методов ценен сам по себе, их нельзя назвать полными во всех отношениях, потому на практике, чтобы получить нечто относительно связное, обычно собирают приемы из различных методов. Скотт Эмблер, главный методист IBM по гибким/рациональным ИТ-методам, объединил лучшие рекомендации нескольких методов, что и привело к созданию модели DAD. Мне посчастливилось работать со Скоттом, и я использовал эти методы в своих собственных проектах.
Кроме того, DAD дополняет обычные методы гибкой разработки рекомендациями, учитывающими условия предприятия. Например, DAD демонстрирует группам, как применять основные идеи, такие как очередь задач, к следующему уровню и сделать их более подходящими для условий крупного предприятия. Это помогает взаимодействовать с подразделениями предприятия за пределами своей группы разработки, такими как отделы архитектуры программного обеспечения или администрирования баз данных. Некоторые разработчики ошибочно полагают, что освоив гибкие методы, они избавятся от необходимости взаимодействовать с этими подразделениями. Это не так. Самые гибкие группы должны смотреть по сторонам, особенно если они сотрудничают с другими проектами и другими подразделениями организации.
Основываясь на своем личном опыте как разработчика и руководителя группы, работавшего в широком спектре гибких проектов, я предлагаю следующие советы, которые помогут читателю продумать вопросы, связанные с управлением крупными проектами, реализуемыми на принципах гибкой разработки. Это всего лишь некоторые соображения, которые следует учитывать при организации группы для выполнения проекта методом гибкой разработки, состоящей из 20 или более программистов, но они помогут встать на правильный путь.
Совет 1: набирайте специалистов широкого профиля
При использовании традиционных методов разработки обычно считается, что лучшие результаты дает группа, состоящая из узких специалистов. На самом деле, как раз наоборот. Во многих случаях, чем более узкие специалисты участвуют в проекте, тем больше они стараются составить идеальные документы, написать совершенный код и получить наилучшие модели. Кроме того, группа, которая опирается на специалистов, не имеющих навыков за пределами своей специальности, может работать неэффективно. Например, если в группе только один человек разбирается в базах данных, это не только чревато задержкой, но и весь процесс получения работающего решения может оказаться в руках одного участника.
DAD рекомендует формировать группы из "специалистов широкого профиля", то есть людей со специальностью, но обладающих общими знаниями в нескольких областях, составляющих жизненный цикл разработки программного обеспечения. Скажем, аналитик может быть специалистом в области требований, а также иметь общее представление о тестировании, и если группа отстает в части тестирования, аналитик засучит рукава и поможет ей.
В проекте, над которым я сейчас работаю, программисты занимаются не только написанием кода, но и участвуют в создании сценариев развертывания и непрерывной интеграции. В результате они приобретают знания в области общей инфраструктуры и управления конфигурацией. Другой пример: тестеры традиционно сосредоточены на пользовательском интерфейсе и на том, как работает программное обеспечение с точки зрения "черного ящика". Но в мире гибкой разработки им все чаще приходится расширять свою техническую подготовку и вставать на точку зрения разработчиков. Они приносят команде больше пользы, если могут написать код своих тестов, а не просто проверить функциональность с позиций пользовательского интерфейса.
Совет 2: умение сотрудничать важнее интеллектуального потенциала
Иногда группы, состоящие из блестящих умов, не приносят ожидаемых результатов. Группа умных людей не обязательно становится хорошей командой. Успех приходит только тогда, когда эти люди работают сообща, стремясь к общей цели. Я знаю очень умных людей, которые не желают трудиться в коллективе, а предпочитают работать самостоятельно. Возможно, в организации и найдется место и для таких людей, но не в группе гибкой разработки.
К тому же в реальной жизни нельзя подобрать группу суперзвезд на каждый проект. Нужно научиться продуктивно и эффективно работать не с суперпрограммистами, а с людьми, обладающими средними, предсказуемыми способностями. Так что, когда я собираю группу, я ищу людей, которые хорошо работают в коллективе, придавая ему компетентность и уверенность. Они оставляют свои "я" за порогом, понимая, что не могут знать всего и должны учиться чему-то у других.
Совет 3: создайте группу подходящего размера для текущего проекта
DAD определяет группы трех уровней: классическую небольшую группу, группу среднего размера и большую группу. Конечно, модель DAD ориентирована главным образом на средние и большие группы. Для больших групп, которые могут иметь ряд подпроектов, где одновременно разрабатываются общие компоненты, важно учитывать, как группы и их руководители будут работать вместе. Дело в том, что классическая теория гибкой разработки требует небольших, самодостаточных групп, которые в состоянии самостоятельно выпускать готовые решения. Но при увеличении размера мы выходим за рамки такой группы и привлекаем других специалистов.
Например, в моем текущем проекте дюжина различных технологий объединяются в рамках очень большой системы. Конечно, мы применяем принцип "специалистов широкого профиля", но каждый не может знать все эти 12 технологий. Поэтому мы пригласили таких специалистов, как эксперты по Linux, гуру баз данных и специалисты по безопасности и межсетевым экранам.
В крупных проектах, подобных этому, вы переходите в производственную среду, где приходится, например, работать с группами DevOps или группами модернизации. Другими словами, система не находится в изоляции. Проект, над которым я работаю в настоящее время, должен быть интегрирован с существующей системой. Все, что поступает в производство, очень жестко контролируется, проходя строгий процесс управления изменениями, поэтому мы регулярно взаимодействуем с людьми, не входящими в группу.
DAD также включает рекомендации по первоначальному планированию при запуске проекта, которые могут оказаться очень полезными, когда разные группы работают вместе. В нетривиальных проектах необходимо предвидеть проблемы, которые придется решать, и возможные решения. Может потребоваться общий обзор задачи и предлагаемой технической архитектуры, краткое изложение рисков и другие общие сведения, необходимые для достижения согласия заинтересованных сторон о действительной полезности проекта.
Рассчитанные на малые группы методы гибкой разработки программного обеспечения, такие как Scrum, учитывают, что стиль руководства, при котором менеджер создает подробный план-график работ, назначает задачи и говорит, сколько времени отводится на решение каждой из них, проблематичен. Практики гибкой разработки признают, что лучше всего, когда такие решения принимают люди, которые фактически выполняют работу. Разработчики сами ставят перед собой задачи, делают оценки, решают эти задачи и разделяют между собой нагрузку. По существу, они работают как эффективно функционирующая, самоорганизующаяся команда без явно определенного менеджера проекта. Группа назначает кого-то руководителем только для облегчения организации процесса в целом.
DAD использует концепцию ответственного за продукт , взятую непосредственно из Scrum; по существу, DAD не меняет эту роль. Ответственный за продукт определяет объем работ, расставляет приоритеты и уточняет требования к работе. Как ответственный за продукт, он отвечает за идею решения. Однако те, кто применяет DAD на практике, признают, что для крупных и сложных проектов может потребоваться присутствие в группе экспертов, помогающих ответственному за продукт.
DAD предлагает еще одну роль, аналогичную ответственному за продукт, ― ответственного за архитектуру. Приятно иметь дело с группой талантливых разработчиков, но важно также иметь кого-то, кто "отвечает" за архитектурную идею разрабатываемого решения и несет ответственность за ключевые технические решения. Ответственный за архитектуру может сотрудничать с внешними специалистами, такими как администратор баз данных или архитектор ПО предприятия, чтобы гарантировать, что решения, принимаемые группой разработчиков, не противоречат нормам и принципам предприятия в целом. Это технический эксперт проекта, регулярно взаимодействующий с внешними подразделениями.
Я, как руководитель группы, в значительной мере полагаюсь на ответственного за архитектуру. В настоящее время я сижу в комнате, где работают 25 человек. Это больше, чем в классической группе гибкой разработки, но это хороший пример масштабирования проекта с помощью DAD. Слева от меня сидит ответственный за архитектуру, так что я всегда могу задавать вопросы типа:
- "Правильно ли у нас расставлены люди?"
- "Смягчили ли мы свои технические риски?"
- "Кому в группе требуется помощь? Не нужно ли прикрепить к ним кого-то?"
- "Есть ли на предприятии технические ресурсы или образцы, которое мы могли бы использовать?"
Как руководителю группы, особенно такой большой, мне трудно досконально знать, как идут дела у каждого из разработчиков. Поэтому я полагаюсь на ответственного за архитектуру как на своего партнера, помогающего мне сделать группу эффективной.
Ответственный за архитектуру важен и по другой причине. Архитектура ― это потенциальный источник огромного риска для проекта, учитывая внешние зависимости, такие как производственная среда, потребности бизнеса, устаревшие данные, старые системы и многое другое. Ответственный за архитектуру определяет, какие рабочие элементы реализовать на ранних итерациях, чтобы уменьшить эти риски как можно раньше. Эта практика DAD называется "жизненным циклом ценности с точки зрения риска" (risk value lifecycle), в отличие от других гибких методов, которые расставляют приоритеты работ только в соответствии с их бизнес-ценностью. Ответственный за архитектуру помогает определить критические технические риски и требования по уменьшению этих рисков, что ближе к концу проекта станет чрезвычайно трудным и дорогостоящим делом.
Совет 5: будьте осторожны с самоорганизацией группы, особенно если ей недостает опыта
Самоорганизующиеся группы ― прекрасная идея гибкой разработки. Члены группы лучше всех знают, как отрегулировать свои процессы, чтобы достичь максимальной эффективности. Они научились и могут работать вместе. К примеру, Хэл знает, достаточно ли отправить Джули сообщение по электронной почте, или лучше поговорить с ней лично. В идеале группа должна обладать основными навыками для решения своей задачи по созданию программного обеспечения. На практике же самоорганизующиеся группы хороши там, где есть прочная техническая база, хорошее знание передового опыта и некоторое представление о методах гибкой разработки.
Неопытные или молодые группы могут не обладать всеми этими качествами. Они могут не понимать, как смоделировать решения, исходя из архитектуры или требований. Или, что еще важнее, могут быть незнакомы с методами гибкой разработки и не понимать различных приемов.
Так что, предоставляя группам возможность самоорганизации, необходимо учитывать компонент навыков и опыта. Их недостаток может привести к хаосу и к созданию недисциплинированного коллектива. Существует и фактор личности. Некоторые люди не любят решать, какие задания им выполнять или в каком порядке. Они предпочитают прямые указания в традиционной манере. Руководитель должен учитывать эти предпочтения и привычки и знать, когда кто-то нуждается в наставлениях или прямом руководстве его повседневной деятельностью.
Здесь главное, что самоорганизующаяся группа работать может, но степень допустимой самоорганизации зависит от зрелости и способностей этой группы. Хороший руководитель не просто дает группе карт-бланш на управление всем, чем она захочет. Он должен знать, что делает его группа, и пристально следить за тем, чтобы она продолжала эффективно трудиться.
Общая теория гибкой разработки обеспечивает прочную основу для выпуска программного обеспечения с высокой бизнес-ценностью для заказчиков, но на практике это может оказаться не так просто. В крупных проектах не всегда все идет гладко, что Скотт Эмблер и я наблюдаем каждый день. Мы не предлагаем опрокинуть корзину и начать изобретать новые методы гибкой разработки, потому что при должном подходе к организации существующие методы работают. Но есть некоторые пробелы, которые мы и пытаемся заполнить.
Конечно, мы не намерены придавать DAD характер предписания. Например, хотя мы предпочитаем указывать требования в своем списке рабочих элементов в виде пользовательских историй, те, кто хочет, могут использовать удобные для себя сценарии. DAD - это всего лишь модель. Следует выбирать те методы, которые наилучшим образом отвечают потребностям гибких проектов.
DAD помогает большим группам разработки программного обеспечения успешно выполнять проекты на основе методов гибкой разработки. Модель DAD, объединившая практические рекомендации, взятые из ряда существующих и проверенных методов гибкой разработки, дополняет их методами, учитывающими условия крупного предприятия. В результате организации с проектными группами, состоящими более чем из 20 человек, могут извлечь из методов гибкой разработки максимум выгод. Собирая группу для DAD, учитывайте эти советы: набирайте специалистов широкого профиля, учитывайте навыки работы в коллективе, создавайте группу подходящего размера для своего проекта, изучите принципы гибкой команды и ее организации, но будьте осторожны с самоорганизующимися командами.