Десятая глава является завершающей главой данного курса.
В ней будут затронуты наиболее интересные и спорные темы, касающиеся использования и дальнейшего развития Agile в организациях, которые пришли к пониманию того, что Agile должна стать частью их операционного бизнеса.
Кроме того, в этой главе будут раскрыты темы, которые, как правило, вызывают наибольшее количество вопросов у тех, кто использует Agile уже какое-то время и имеет определенный опыт и навыки применения Scrum, Kanban или прочих видов гибкой методологии.
В третьей главе мы рассмотрели и достаточно подробно сравнили классический, итерационный и гибкий подходы к разработке программного обеспечения, а также постарались обоснованно развенчать мифы о несовместимости совместного использования различных подходов.
Во многом такие сторонние точки зрения обусловлены противоположным опытом и ситуацией, в которых осуществлялось и осуществляется эксплуатация данных подходов. Но, несмотря на этот дуализм, многие современные исследователи и специалисты констатируют, что можно приобрести много преимуществ от одновременного использования обоих методов в организации.
Одна из наиболее авторитетных организаций в области процессов SEI (организация - автор модели CMMI) опубликовала технические заметки, в которых излагается, почему можно использовать оба метода одновременно.
Различные причины инициировали рост рассматриваемых методов. Во многих организациях, которые пришли к идее внедрения Scrum или любой другой гибкой методики, он приходит на смену классическому подходу. Это происходит не одномоментно, а в течение определенного интервала времени, за который организация должна осуществлять свою полноценную деятельность (приносить доход, развиваться и т. д.), поэтому возникают пересечения этих методов:
Молодые специалисты, практикующие гибкие методологии, поднимаются по карьерной лестнице и видят влияние водопада на гармоничный процесс гибкой разработки. К примеру, на уровне проектов внедрения классический подход фокусируется на том, чтобы продукты разрабатывались в полном объеме, в то время как гибкая модель концентрируется на том, как его разрабатывать.
Многие современные компании поставлены перед необходимостью сочетать основные процессы, выстроенные по классическому принципу разработки программного обеспечения, с наличием эффективных команд разработчиков, использующих гибкие методологии. С другой стороны, есть прецеденты, когда в преимущественно "гибкой" среде используется ограниченный по времени итеративный подход.
Нет процесса, который одинаково эффективен при различных условиях функционирования.
Организации совершают непоправимую ошибку, если являются адептами лишь одной технологии. Они ограничивают себя в рассмотрении наиболее эффективных веяний и постепенно приходят в состояние полной зашоренности.
Текущие веяния говорят о том, что наиболее эффективные организации со временем все больше внимания будут уделять совмещению гибких и классических методологий разработки программного обеспечения.
Не каждая Scrum-команда может позволить себе "матриархально" владеть полным циклом управления используемым ею процессом разработки. В качестве примера можно привести разработку программных продуктов с участием субподрядчиков, к которым в большинстве случаев выдвигаются требования по подтверждению уровня зрелости их собственных процессов области информационных технологий.
По сути это означает, что разработчики программного обеспечения должны использовать сходный набор передовых методов и применять в практике создания программных продуктов такие стандарты, как ISO 9001 (процессные стандарты), ISO 13458 (стандарт медицинской отрасли), требования закона Сарбейниса-Оксли (акционерные компании на территории США) и пр. Таким образом, одной из задач Scrum-команды, направленной на разработку качественного программного продукта, является постоянная забота о том, как интегрировать профильные стандарты в создаваемый ими продукт.
Scrum-команда поставлена в условия, когда сама отвечает за конечный результат и при этом минимальным образом зависит от внешнего окружения. В таких условиях возрастает необходимость постоянного совершенствования используемых процессов в плане соответствия отраслевым и международным практикам для целей наименее затратной синхронизации получаемых результатов с результатами деятельности возможных партнеров и коллег. В случае, если этого не будет происходить, команда рискует отстать от реальности рынка как процессно, так и технологически, и разрабатывать "отсталый" продукт.
Членам Scrum-команд необходимо заботиться о том, чтобы соблюсти набор правил и принципов, предписываемый "best practice" и профильным стандартам. Для этого следует:
Роль аудитора и консультанта могут выполнить сотрудники организации. При этом они должны обладать нужным уровнем квалификации, который позволил бы успешно выполнять возложенные на них функции и обязанности, а также соответствующими чертами характера.
Подытоживая, следует отметить, что Scrum, как и любое другое процессное направление деятельности, должен развиваться за счет принятия и адаптации наиболее успешных практик, доказавших свою эффективность. Кроме всего прочего, важно отметить необходимость постоянного совершенствования профильного направления деятельности. В нашем случае речь идет о разработке программного обеспечения, которая является одной из самых динамичных областей и консерватизм в которой, как правило, оборачивается потерей скорости разработки и внедрения новых продуктов.
Методология Lean направлена на совершенствование и процессное развитие. Она не подходит для тех процессов, которые находятся на "зачаточном" и начальном уровнях зрелости. По сути, о необходимости внедрения методологии Lean задумываются те компании, которые достигли определенного качественного уровня.
В Lean, так же как и в Scrum, работа разбивается на небольшие пакеты (сравнимо с понятием бэклога спринта), которые должны реализовываться отдельно и независимо. Lean, в целях разработки предсказуемого результата, содержит определенный поток операций (workflow) с этапами. В Scrum существуют свои специфичные процессы и процедуры, которые подтвердили свою эффективность. Lean добавляет к "гибким" принципам схему потока операций, для того чтобы каждая из итераций выполнялась одинаково качественно.
Оба направления в своей основе имеют системный подход, основанный на постоянном обучении и совершенствовании. В данном случае Scrum является базисом, на основе которого станет возможным "надстраивать" специфичные методы и методики, которые будут способствовать повышению эффективности процессов компании и, как следствие, увеличивать/улучшать результат.
Организация методологии Lean и ее этапов позволяют быть уверенными в том, что каждая часть проекта/продукта/процесса реализуется так, как этого требует результат. В Lean, как, впрочем, и в Agile, нет четких границы этапов, но, как и в Scrum, прописаны ограничения спринтов.
Как и гибкие процессы, Lean более похожа на концепцию, образ мышления, нежели четко регламентированную методологию. Используя принципы Lean, можно создать адаптивную систему, удовлетворяющую конкретным требованиям. Для этого необходимо следовать следующим принципам:
Подытоживая, стоит сказать, что сильной стороной Lean является разнообразный набор инструментов и подходов к работе для удовлетворения разнообразных требований. Lean сочетает гибкость и структурированность, но немного отличается в этом от Scrum.
Его недостатком является слишком детальная и дотошная проработка каждой стадии работы. Lean предполагает такой подход к каждой задаче и этапу. Это основной минус применения Lean, когда речь идет о средних и мелких продуктах. В отличие от Scrum, Lean не предлагает четкого рабочего процесса для реализации "кусочков", что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и четких коммуникаций.
Внедрение и последующее использование Lean должно стать целью для тех организаций, в которых Agile уже завоевала свое место и на ряде проектов подтвердила свою эффективность.
Необходимость цифровой трансформации (ЦТ) на сегодня осознана уже многими компаниями. Под ЦТ понимается прежде всего создание гибкой процессной инфраструктуры, способной поддержать любые начинания по развитию бизнеса и способствовать достижению намеченных результатов в как можно более сжатые сроки.
То, как сегодня работают специалисты и как они взаимодействуют с клиентами, определяет возможность предприятия стать лидером профильного сегмента рынка и добиться успеха.
Не для кого уже не секрет, что роль и влияние информационных технологий в этих процессах очень велики. Для конечного потребителя уже недостаточно информационных систем, которые могут удовлетворить только минимальные требования к автоматизации.
Пользователи ждут продуктов, в которых успешно сочетались бы удобство в получении необходимой информации с ее последующим анализом и обработкой, как на своем рабочем месте, так и вне его. Интерфейс должен быть понятен без длительного изучения различных инструкций, быстрое исправление проблемных ситуации в случае сбоя, а в идеале предвосхищение таких сбоев, - все это неотъемлемые характеристики рабочей среды успешной "цифровой" компании. Метаморфоза, которая позволит компаниям приобрести подобные черты, и называется цифровой трансформацией.
Решение проблемы метаморфозы многие видят в переходе к гибкому стилю работы не только в процессах разработки, внедрения и последующей эксплуатации ИТ-продуктов, но и в компании в целом. Scrum позволит организовать стабильные, предсказуемые поставки рабочего инкремента корпоративных информационных систем. Более того, бизнес-процессы, организованные по гибким принципам, позволят достичь максимальной загрузки сотрудников компании и найти ресурсы для стратегического или инновационного развития организации.
Кроме того, в качестве основных характеристик компании, прошедшей стадию цифровой трансформации, можно выделить следующие:
В цифровом бизнесе продуктивность каждого участника бизнес-процесса определяется качеством работы информационных систем. Цифровая трансформация компании требует сильного руководства - только оно может быть драйвером серьезных изменений. Требуется четкое понимание того, какие части компании и каким образом необходимо преобразовать. Цифровая трансформация во многом является экспериментом, плоды успешности которого позволят компании перейти на другой уровень зрелости. При этом абсолютно не важен профиль компании - информационные технологии в силах предоставить нужный инструмент с требуемым уровнем настройки, а если взять за основу основные постулаты и принципы Scrum, то эта настройка будет осуществляться наиболее подходящим для конкретных условий образом и в максимально сжатые сроки.
Новички, познакомившиеся с Agile, уверены в том, что, применив гибкие методики к любому типу процесса и организации, можно добиться высоких результатов. Это не так. Это ложная реклама. Agile в целом и Scrum в частности требуют многих усилий и осмысленного применения для того, чтобы добиться результатов.
Если вам заявляют, что стоит пригласить внешнего Agile coach или Scrum-мастера и они смогут выполнить всю необходимую работу, то это тоже неправда. Сегодня на рынке есть множество компаний, которые не программировали и не имеют опыта руководства людьми. Подобное "обучение" с помощью таких специалистов не принесет значимых плодов. Люди, занимающиеся пропагандированием и внедрением гибких практик, должны уметь программировать, анализировать, руководить, тестировать и обладать в этих навыках достаточно высоким уровнем компетенции. Если подобного опыта у "всезнающего" консультанта нет, то как с ним можно обсуждать специфические ситуации, связанные с продуктом или Scrum? Консультант по внедрению гибких процессов, который получил высшее образование вчера и не написал ни строчки кода, приносит меньше пользы, чем члены команды. Нельзя обучать тому, чего ты ни разу не делал. И "делать" означает "делать многократно и постоянно", а не иметь в послужном списке один пилотный проект.
При этом найти причины неудач очень просто. Их и искать не надо - они, как правило, лежат на поверхности. Принципы Scrum предписывают, как нужно действовать, но в них не описан алгоритм работы. Эта концептуальность критикуется, но, если бы гибкие методологии претендовали на роль конкретных техник, тогда их использование не нашло бы такого широкого распространения. Алгоритм работы должен быть определен в конкретной организации с учетом условий ее деятельности и его поэтапной корректировки в целях совершенствования. Гибкие методологии не должны навязываться. Они должны быть добровольно приняты и одобрены коллективом разработчиков, которые заинтересованы в его применении. Попытка навязать его применение приведет к подавлению роли команды и последующему отторжению.
Это лишь малых перечень проблем, которые приводят к критике культуры Agile. Компаниям, которые пришли к необходимости внедрения и использования этой методологии, рано или поздно придется эти проблемы решать. Игнорирование и замалчивание приведет к "тихим" или явным революциям. Подытоживая, выделим следующие постулаты:
Когда менеджмент приходит к необходимости внедрения гибких методологий, то необходимо осознать, что быть гибкими предстоит всем. Если команде в рамках ее полномочий поручено выполнять ряд действий, принимать решения и нести за них ответственность, то это должно быть действительно так. Если команда не принимает решений, то это разрушает ее изнутри. Команда должна принять решение о том, что и как она будет развивать и что для этого необходимо. Если решения принимаются не командой, а спускаются "сверху", то в конечном итоге вы получите не коллектив мотивированных и самостоятельных разработчиков, а безынициативную группу послушных сотрудников.
Много прекрасных команд на первых этапах своей деятельности терпят неудачи. Много команд успешны без Scrum. Принимая решение об использовании Scrum, нужно взвесить все за и против и следовать принятому решению.
Вряд ли можно рассчитывать на то, что гибкие методологии будут применяться в идеальной среде, свободной от вмешательства окружающего реального мира. Неидеальность реального мира - это реальный факт. Этот факт необходимо учитывать всегда. Таким образом, очевидна необходимость сопровождения и развития отдельно взятого Scrum конкретной компании. Scrum - гибкая процессная методология, или, по-другому, - управленческая дисциплина. И как любую дисциплину, цель которой - приносить предсказуемый результат, ее необходимо контролировать. Но трудоемкость менеджерских активностей можно уменьшить и с самого начала "воспитывать" в сотрудниках, входящих в Scrum-команду, лояльность к изменениям, приверженность к обучению и совершенствованию. Явным результатом этого будет достижение более высокого уровня процессной зрелости и профессиональной культуры.
Путем экспериментирования Scrum-команды могут повести организацию к освоению все более и более эффективных способов работы.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.