Записаться

4.1. Типы Agile-методологий и их распространенность

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

Agile - набор принципов и методик, которые необходимо встроить в деятельность компании.

Каждая организация имеет свои неповторимые черты, свой уровень зрелости процессов, свои условия, в которых она добивается поставленных целей. Использовать универсальные принципы для компаний с низким уровнем зрелости и для организаций, занимающих в лестнице CMMI самые высокие позиции, было бы недальновидным решением. Agile не подразумевает пошаговых руководств и конкретных рекомендаций, а лишь своими принципами задает рамки, в которых используют гибкие методологии.

В данной главе мы обсудим ряд гибких методологий разработки программных продуктов, использующихся при создании программных продуктов (рис. 4.1).

Рис. 4.1. Популярность Agile-практик, 2015 г.

Kanban

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

В основе Kanban лежат три базисных принципа:

• Визуализация (иероглиф "кан"). При иллюстрировании и моделировании процесса он разбивается на отдельные стадии (анализ, проектирование, разработка, тестирование и т. д.), упрощая таким образом его восприятие.
• Ограничение максимального количества задач на определенном этапе. Этот принцип позволяет свести потери к минимуму - максимальное сосредоточение на своих задачах.
• Оптимизация существующего процесса. Время на выполнение задачи отслеживается, анализируется, и вырабатываются предложения о том, как можно выполнить работу более совершенно. В процессе не должно быть простоев, равно как и не должна выполняться ненужная работа. Kanban характеризуется утверждением: "Уменьшение выполняющейся в данный момент работы". Данный тип методологии является, пожалуй, самым гибким. Это значит, что она является наиболее требовательной к условиям и ресурсам, в рамках которых предполагается ее эксплуатировать. Сотрудники, работающие по Kanban, должны быть готовы к экстремальной гибкости и при этом не должны ломаться.

Уникальность методологии Kanban, в сравнении с конкурентами по семейству Agile, состоит в:

• Способе распределения задач. Каждый специалист, работающий в команде разработчиков, может взять на себя лишь ограниченное количество, при этом выбор задач он осуществляет самостоятельно, а не по чьему-то указанию.
• Отсутствии временных рамок. Kanban не предполагает ограничения на время выполнения поставленных задач.
• Размере задач, которые необходимо реализовать. В сравнении с аналогами задач меньше, но их объем и трудоемкость значительно больше.
• Отсутствии активности оценки и планирования. Оценки сроков на задачу: опциональные или вообще их нет.

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

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

Kanban ориентирована на задачи. Сотрудники работают над задачами с самого начала и до завершения. Рабочая команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочно вначале. Если менеджер верит команде, то зачем иметь оценку времени?

Lean

Этот тип методологии подразумевает создание продукта в условиях максимальной экономии ресурсов с целью устранения всех возможных потерь. Изначальный функционал продукта ограничивается до минимально полезного. Таким образом, функционал реализуется путем поэтапного наращивания функционала небольшими порциями, сродни инкрементальному принципу реализации информационных систем. Корни этого подхода относятся к принципам бережливого производства (Lean Manufacturing). Мэри и Том Поппендик, о которых было упомянуто в "Введение в Agile" курса, адаптировали эти принципы для разработки программного обеспечения:

• устранение потерь;
• повышение качества;
• создание знаний;
• отсроченные обязательства;
• быстрая поставка;
• уважение людей;
• полная оптимизация.

Lean постулирует отказ от всего, что не добавляет ценности создаваемой информационной системе. Разрабатывать необходимо только то, в чем есть абсолютная уверенность, что это нужно делать сейчас. Устранение потерь во всех аспектах работы (бесполезные собрания, избыточные задачи, документация, неэффективные способы работы и т. д.). Акцент на то, что называется "системным подходом", то есть сотрудники работают как единое целое, как команда. Необходимо верхнеуровневое осознание того, что выполняемая работа помогает повышать ценность создаваемого продукта, в сравнении с аналогами. Не нужно заставлять людей работать на 150% их рабочего времени. Не нужно кодировать то, что не нужно. Дополнительный функционал создает дополнительные обязательства для пользователей и руководства. Сотрудники нуждаются в уважении как личностном, так и профессиональном. Нужно давать им ту работу, которую они лучше всего знают, как надо сделать. Смысл программной разработки в постоянном обучении. Принятие управленческих решений нужно выполнять в последний возможный момент. К моменту реализации необходимого функционала сотрудники будут знать уже больше и лучше ориентироваться не только в создаваемой системе, но и в бизнес-процессах и данных организации.

Экстремальное программирование

Авторами этой методологии являются Кент Бек, Уорд Каннингем, Мартин Фаулер. Именно об этих людях мы говорили, когда в "Введение в Agile" делали историческое отступление об авторах Agile. Методология получила свое название благодаря воплощению идеи применить полезные классические методы и техники разработки программного обеспечения, подняв их на качественно новый "экстремальный" уровень. К примеру, этап ревизии кода, заключающийся в аудите одним программистом кода, написанного другим программистом, в "экстремальном" варианте представляет собой "парное программирование". Таким образом, мы получаем рабочий процесс, в ходе которого один программист занимается кодированием, а его напарник в это же время непрерывно просматривает только что написанный код. Через некоторое время они меняются ролями.

Если подвести локальный итог рассмотренных ответвлений гибких методологий в целом, то главным минусом станет "плавающая" оценка сроков разработки и бюджета. К неоспоримым плюсам стоит отнести малые сроки производства продукта, отсутствие простоев на время согласования проектной документации, оперативное управление изменениями и пр.

Последняя, оставшаяся к рассмотрению и, пожалуй, наиболее распространенная методология из семейства Agile - Scrum.

По результатам актуальных исследований и опросов, именно Scrum является самой популярной техникой управления процессами разработки программного обеспечения

Scrum

В Scrum требования разбиваются на небольшие подгруппы, каждая из которых должна быть максимально независима от другой. Это делается для того, чтобы в течение каждого нового спринта (промежутка между выпуском новых версий продукта) команда разработчиков могла реализовать новый функционал. Scrum подразумевает постоянную коммуникацию - будь то планирование очередной итерации работ совместно с клиентом или ежедневный Scrum-митинг, в течение которого команда обсуждает ряд наиболее важных вопросов, ответы на которые непосредственно влияют на создаваемый программный продукт. Именно на примере описания и подробного рассмотрения Scrum в дальнейшем будет вестись речь о Agile.

4.2. Scrum - гибкий управленческий процесс

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

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

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

Среди множества других, одной из особенностей этой методологии следует выделить ежедневные короткие совещания, во время которых идет обсуждение результатов предыдущих итераций (спринтов) и ставятся задачи на следующие. Это позволяет заинтересованным менеджерам держать под контролем процесс разработки, при необходимости направляя его в нужное русло.

Достоинства Scrum:

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

Возможность изменения требований привлекательна для многих заказчиков:

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

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

Scrum содержит и важные недостатки. Ввиду простоты и минималистичности, Scrum задает небольшое количество довольно жестких правил. Однако это вступает в конфликт с идеей "клиент всегда прав", так как заказчикам не важны внутренние правила команды разработки, особенно если они его ограничивают.

Так же общеизвестной проблемой Scrum являются большие издержки на обсуждения, встречи и большие потери времени на стыках спринтов. Как минимум день уходит на закрытие очередного спринта, а потом день - на открытие нового. В условиях, когда спринт длится 2 недели, 2 дня составляют 20% рабочего времени. Итог - 30-40% времени при применении Scrum тратится на поддержание самого процесса (ежедневные встречи, планирование и детализирование работ, презентация полученных результатов и пр.)

Scrum относится к семейству Agile, в котором не приветствуется создание планов коммуникаций, реагирования на риски, управления сложными техническими изменениями. Итог - сложное, а иногда невозможное формальное (юридическое или административное) противодействие нарушениям правил Scrum. Конечно, нерадивого сотрудника можно просто уволить, но это не является системным способом решения проблемы. Процессы в компании должны быть выстроены так, чтобы, оставляя определенную степень свободы сотруднику, всегда можно было бы контролировать его не только количественно, но и качественно. Для этого есть множество техник и методик, применение которых характеризует зрелость компании в целом и ее процессов в частности. Все лидирующие в различных сегментах компании характеризуются низким уровнем увольняемости. Ротация сотрудников нужна для каждой организации, но ротация не должна быть массовой. Когда уходят ключевые сотрудники, организация ставит себя под удар. В Scrum этот недостаток попытались преодолеть за счет постулата универсализма и упор на самоорганизующуюся многофункциональную команду. При кажущемся снижении затрат на координацию команды это приводит к повышению затрат на отбор персонала, его мотивацию, обучение. В определенных условиях рынка труда, формирование полноценной, эффективной Scrum-команды может быть невозможным. Хорошие сотрудники стоят дорого, и руководство организации должно отдавать себе в этом отчет.

Фокус Scrum - управление продуктом в условиях неопределенных и часто меняющихся требований, которые характеризуют современный неустойчивый информационный мир.

4.3. Как воспитывать сотрудников?

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

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

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

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

Общие рекомендации, используя которые можно учесть 90% возможных проблем, заключаются в управлении следующими факторами:

• "Воспитание" эффективности. Каждый сотрудник должен иметь перед собой трудные, но достижимые цели, выраженные в виде совершенствования или развития навыков полезных для компании и интересных самому работнику. Эти цели подкрепляются в виде четких и понятных планов развития, декомпозированных на конкретные задачи (расширить компетенции в бизнес-процессах компании, освоить новый инструмент по работе с БД и т. д.), которые должны иметь четкий срок и метрику.
• Планирование сложных рабочих заданий. Рабочие задачи следует планировать так, чтобы они были понятны сотруднику и практически подкрепляли развитие его навыков. Таким образом, мы получаем четкую зависимость между его эффективностью, способностью и желанием решать задачи, необходимые для достижения целей компании.
• Синхронизация понимания между руководством и сотрудниками о задачах развития и пути достижений результата конкретных задач. Руководство и работники должны находиться в состоянии открытой, честной коммуникации. Доверие приводит к осознанию безопасности. Безопасность - это один из первейших инстинктов, удовлетворение которого приводит к созданию комфортной рабочей обстановки. Выстраивание доверия и согласованности понимания в действиях, необходимых для достижения поставленных целей, - одна из основных задач руководства на пути получения долгосрочного результата от деятельности сотрудников.
• Командная работа. Работники могут чувствовать себя изолированно и неудовлетворенно, если они не являются частью сплоченной команды или если ими тайно "жертвуют" по тем или иным причинам. Данная проблема решается за счет создания команд различной величины, которые должны быть саморегулируемы. Саморегуляция достигается, если члены команды понимают значимость командной работы и необходимость достижения результатов.
• Философия лидерства как новый тип управления командной работой. При внедрении изменений важным движущим фактором является наличие лидера, который собственным примером сможет продемонстрировать преимущества, которые будут получены командой от применения этих изменений. Этот лидер должен иметь опыт, желательно успешный, работы по внедряемым процессам. Можно очень долго и красиво рассказывать о том, как будет хорошо, но сотрудникам важно иметь коллегу, который сможет подсказать, как правильно и оптимально поступить в тех или иных рабочих условиях. Это является катализатором быстрого достижения результатов от внедрения. В противном случае риск "блуждания" по лабиринтам процессов и увеличения времени на адаптацию увеличивается в несколько раз.

В итоге следует, что для воспитания рабочей философии рекомендуется следовать следующим основным принципам:

• Выбирайте сотрудников "точечно". Выбор конкретных работников должен быть взаимосвязан с задачами, которые стоят перед компанией сейчас и должны возникнуть в ближайшей перспективе.
• Воспитывайте в сотрудниках эффективность или расставайтесь с ними. Сотрудники и компания должны расти и развиваться вместе. Если сотрудник стремится осваивать новые навыки и при этом использует их в работе, то именно это тот тип работника, который должен стать частью локомотива будущих побед организации. Грамотные исполнители, которые качественно выполняют свои функциональные обязанности, тоже нужны, но они не будут способствовать развитию компании, они будут способствовать ее стабилизации в уже занятой рыночной нише.
• Сотрудникам необходима возможность обучаться как на рабочих местах, так и в процессе работы пилотных проектов. После принятого решения об изменениях в процессах компании следует начать с пилотных проектов оптимизации тех активностей, в которых есть лидеры, за которыми смогут начать тянуться остальные. Способствуйте тому, чтобы ваши сотрудники имели возможность получить необходимые знания и информацию об изменениях.
• Необходим опыт и знания коллег, уже внедривших Scrum. Лидеры изменения должны на практике знать то, о чем говорят в теории.
• Необходимо постоянно осведомлять людей о произошедших переменах. В компании должна быть организована система оповещений и атмосфера доверительной коммуникации о происходящих изменениях. Не пренебрегайте "сарафанным" радио, которое можно организовать через кадровый департамент или аналогичную службу. Доносите информацию даже о самых незначительных победах, обозначайте возникшие проблемы и пути их решения.

Подводя локальный итог темы управления и развития кадров в Scrum, нужно сказать сокровенное: "Кадры решают все". Именно сотрудники и их навыки формируют основную ценность любой компании. А когда речь заходит о гибких методологиях, то значимость утверждения, приведенного выше, возрастает в несколько раз. На потенциале и трудолюбии команды будет держаться качество программного продукта. Кадрами предстоит заниматься очень много и кропотливо, но эта работа окупается.

4.4. Как управлять сопротивлением?

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

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

Для того чтобы понять, как реагировать на возможное сопротивление, полезно понять, на каком уровне возникают сопротивления:

• на организационном уровне;
• на уровне группы;
• на уровне индивида.

От понимания того, на каком уровне возникает сопротивление и чем оно характеризуется, возникает понимание способов устранения проблем.

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

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

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

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

• информирование о результатах организационной диагностики тех подразделений и групп, которые непосредственно затрагивает изменение;
• проведение семинаров и дискуссий, в которых бы участвовала конкретная группа сотрудников;
• организация информационной сети, чтобы каждый мог узнать о том, что происходит, и имел возможность выразить свои сомнения;
• привлечение на сторону изменений членов влиятельных и авторитетных неформальных групп в организации.

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

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

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

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

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

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

Основная задача руководства - принимать верные и своевременные решения, используя различные подходы не только поодиночке, но и в сочетании друг с другом.

4.5. Чем нужно управлять в Scrum

Основная цель использования управленческой методологии Scrum - эффективное управление ресурсами с возможностью сосредоточения всех участников гибкого процесса на конечном результате. В основе Scrum лежат принципы, предписывающие полностью сосредоточиться на продукте, разработка и развитие которого является основным результатом деятельности. Суть принципов Scrum унаследована от принципов, перечисленных в Agile Manifesto (см. "Введение в Agile" ).

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

Scrum опирается на людей и взаимодействие между ними. Грамотное управление людьми выходит на первый план.

Команда

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

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

Требования

Для работы над продуктом у сотрудников, объединенных в единую команду, есть все необходимое - Product Owner, бэклог продукта…

Scrum продуктивен из-за своей простоты. Члены команды имеют свободу самим определять, каким образом разрабатывать продукт. И в этом скрыта самая большая сложность Scrum. Одним из основных качеств, которые отделяют начинающего от состоявшегося профессионала, является черта самоанализа, которая заключается в постоянном переосмыслении того, что и как он делает. Цель самоанализа - улучшить работу, над которой идет размышление. Необходимо вырваться из рамок "так положено" и понять, что конкретно нужно сделать для достижения результата наименьшими затратами. Гибким быть непросто. Для того чтобы быть эффективным, нужна соответствующая квалификация. Именно уровень этой квалификации во многом предопределяет качество проработки требований, которые необходимо реализовать. Но при этом необходимо учитывать, что инженерия требований для разработки функционала должна выполняться в необходимом объеме. Требования должны создаваться непрерывно при активном сотрудничестве заинтересованных лиц с командой разработки. Важно помнить, что конечная цель сбора требований в том, чтобы облегчить и разделить общее понимание требований для всех тех, кто вовлечен в процесс разработки. Требования могут различаться по детальности и степени проработки и принимать самые разные формы. Для получения общего представления о требованиях полезно иметь какую-нибудь форму или шаблон документации, определяемой командой для каждой конкретной ситуации.

В Scrum в качестве инструмента используются use case. Более подробно о технике проработки требований мы поговорим в "Атрибуты Scrum" .

Продукт

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

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

Можно выделить еще несколько ключевых факторов, управление которыми будет влиять на создание продукта (риски, технологии, инженерные практики и пр.), но основными являются именно сам продукт и команда, которая участвует в его разработке. Остальные являются либо производными, либо второстепенными, и в соответствии с их значимостью для внедрения и адаптации Scrum будут рассмотрены далее.

4.6. Значимость соблюдения процесса

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

В Scrum-документах зафиксировано, что основной ценностью являются люди, которые за счет оптимального взаимодействия друг с другом должны достичь запланированных результатов. Именно за счет командного взаимодействия должна достигаться рабочая гармония. Значимость "записанного" порядка взаимодействия снижается, во главу угла выходит человеческий фактор. При создании и следовании процессу необходимо держаться принципа золотой середины, то есть нужно руководствоваться основными постулатами методологии, но корректировать тактику в зависимости от конкретных условий окружающей среды и в уме держать необходимость внедрения принципа гибкости. Командный процесс в идеале должен получиться:

• прозрачным;
• инспективным;
• адаптивным.

В этом плане Scrum представляет собой процесс "с человеческим лицом", в котором каждый член команды должен контролировать своего сотоварища, так как за результат деятельности несет ответственность вся команда.

Рабочий процесс должен находиться под контролем владельца продукта. Это позволяет избежать нестабильности и добиться возможности достоверно прогнозировать результаты посредством управленческих инструментов. Для обеспечения его контролируемости в Scrum предусмотрены все необходимые атрибуты (доска задач, бэклог продукта, бэклог спринта), о которых мы поговорим чуть позже.

4.7. Инженерные практики

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

Немаловажным фактором является понимание преимуществ и возможностей того или иного инструмента, а также сложностей и специфики его внедрения.

Большинство практик, применяемых в Scrum, своими корнями уходят в экстремальное программирование. Именно на этой методологии рассматриваемые далее практики доказали свою эффективность.

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

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

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

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

Code Refactoring. Это не просто техника. Благодаря развитию и распространению Agile рефакторинг стал полноценным техническим направлением деятельности. Refactoring предписывает осуществление изменений внутренней структуры исходного кода, которые не должны повлечь изменения в поведении программы. За счет применения Code Refactoring достигается упрощение структуры программного продукта и повышение скорости его работы. Это способ систематического приведения кода в порядок, при котором шансы появления новых ошибок минимальны. В сущности, при проведении рефакторинга кода вы улучшаете его дизайн уже после того, как он создан.

Как следствие получаем экономию на дальнейшем сопровождении и поддержке.

Build Automation. Это техника автоматической сборки исходного кода, выполнения тестов и развертывания программы на целевом ландшафте. Автоматизация позволяет повысить качество процесса разработки и поставки продукта. Результаты Build Automation не так очевидны бизнес-заказчикам системы, но за счет внедрения этой техники с технической команды снимается часть работы, после чего они могут направить освободившиеся ресурсы на более значимые для бизнес-пользователей активности.

Continuous Integration. Практика непрерывной интеграции направлена на выполнение частых автоматизированных сборок программного продукта. Цель - выявление и решения интеграционных проблем. Переход к непрерывной интеграции позволяет снизить трудоемкость интеграции и сделать ее более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.

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

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

4.8. Краткие выводы

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

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

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

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

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

О команде и ролях мы поговорим в "Роли Scrum".