После того как Agile завоевала определенную нишу в области процессного управления сферы информационных технологий, стало очевидно, что для дальнейшего развития необходимы конкретные практические подходы, адаптированные под "боевые" условия конкурентной среды функционирования предприятий.
Каждая организация имеет свои неповторимые черты, свой уровень зрелости процессов, свои условия, в которых она добивается поставленных целей. Использовать универсальные принципы для компаний с низким уровнем зрелости и для организаций, занимающих в лестнице CMMI самые высокие позиции, было бы недальновидным решением. Agile не подразумевает пошаговых руководств и конкретных рекомендаций, а лишь своими принципами задает рамки, в которых используют гибкие методологии.
В данной главе мы обсудим ряд гибких методологий разработки программных продуктов, использующихся при создании программных продуктов (рис 4.1).
(рис 4.1) Популярность Agile-практик, 2015 г.
Это яркий представитель процессной методологии, которая появилась благодаря японскому послевоенному экономическому чуду в сфере машиностроения и постепенно была заимствована в сферу информационных технологий.
В основе Kanban лежат три базисных принципа:
Уникальность методологии Kanban, в сравнении с конкурентами по семейству Agile, состоит в:
Выгода от применения приведенных постулатов весьма спорна. Как выполнять контроль над разработкой, если мы убираем основные инструменты контроля - сроки, скорость работы и т. д.? Ответ на приведенный вопрос мы оставим на более поздние обсуждения, которые приведем в следующих главах.
Kanban ориентирована на задачи. Сотрудники работают над задачами с самого начала и до завершения. Рабочая команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочно вначале. Если менеджер верит команде, то зачем иметь оценку времени?
Этот тип методологии подразумевает создание продукта в условиях максимальной экономии ресурсов с целью устранения всех возможных потерь. Изначальный функционал продукта ограничивается до минимально полезного. Таким образом, функционал реализуется путем поэтапного наращивания функционала небольшими порциями, сродни инкрементальному принципу реализации информационных систем. Корни этого подхода относятся к принципам бережливого производства (Lean Manufacturing). Мэри и Том Поппендик, о которых было упомянуто в первой главе курса, адаптировали эти принципы для разработки программного обеспечения:
Lean постулирует отказ от всего, что не добавляет ценности создаваемой информационной системе. Разрабатывать необходимо только то, в чем есть абсолютная уверенность, что это нужно делать сейчас. Устранение потерь во всех аспектах работы (бесполезные собрания, избыточные задачи, документация, неэффективные способы работы и т. д.). Акцент на то, что называется "системным подходом", то есть сотрудники работают как единое целое, как команда. Необходимо верхнеуровневое осознание того, что выполняемая работа помогает повышать ценность создаваемого продукта, в сравнении с аналогами. Не нужно заставлять людей работать на 150% их рабочего времени. Не нужно кодировать то, что не нужно. Дополнительный функционал создает дополнительные обязательства для пользователей и руководства. Сотрудники нуждаются в уважении как личностном, так и профессиональном. Нужно давать им ту работу, которую они лучше всего знают, как надо сделать. Смысл программной разработки в постоянном обучении. Принятие управленческих решений нужно выполнять в последний возможный момент. К моменту реализации необходимого функционала сотрудники будут знать уже больше и лучше ориентироваться не только в создаваемой системе, но и в бизнес-процессах и данных организации.
Авторами этой методологии являются Кент Бек, Уорд Каннингем, Мартин Фаулер. Именно об этих людях мы говорили, когда в первой главе делали историческое отступление об авторах Agile. Методология получила свое название благодаря воплощению идеи применить полезные классические методы и техники разработки программного обеспечения, подняв их на качественно новый "экстремальный" уровень. К примеру, этап ревизии кода, заключающийся в аудите одним программистом кода, написанного другим программистом, в "экстремальном" варианте представляет собой "парное программирование". Таким образом, мы получаем рабочий процесс, в ходе которого один программист занимается кодированием, а его напарник в это же время непрерывно просматривает только что написанный код. Через некоторое время они меняются ролями.
Если подвести локальный итог рассмотренных ответвлений гибких методологий в целом, то главным минусом станет "плавающая" оценка сроков разработки и бюджета. К неоспоримым плюсам стоит отнести малые сроки производства продукта, отсутствие простоев на время согласования проектной документации, оперативное управление изменениями и пр.
Последняя, оставшаяся к рассмотрению и, пожалуй, наиболее распространенная методология из семейства Agile - Scrum.
По результатам актуальных исследований и опросов, именно Scrum является самой популярной техникой управления процессами разработки программного обеспечения
В Scrum требования разбиваются на небольшие подгруппы, каждая из которых должна быть максимально независима от другой. Это делается для того, чтобы в течение каждого нового спринта (промежутка между выпуском новых версий продукта) команда разработчиков могла реализовать новый функционал. Scrum подразумевает постоянную коммуникацию - будь то планирование очередной итерации работ совместно с клиентом или ежедневный Scrum-митинг, в течение которого команда обсуждает ряд наиболее важных вопросов, ответы на которые непосредственно влияют на создаваемый программный продукт. Именно на примере описания и подробного рассмотрения Scrum в дальнейшем будет вестись речь о Agile.
Принципы итеративной разработки программного обеспечения предполагают действия по определенным итерациям. Небольшие кусочки, каждый из которых должен представлять собой законченную функциональность, выполняются в соответствии с постепенным наращиванием дополнительных более качественных и детализированных атрибутов автоматизации разрабатываемого продукта должны быть реализованы в определенных временных рамках. Суть заключается в том, что вы постоянно, циклично делаете все необходимое для выкладки очередной версии продукта. Продукт становится качественнее, а команда сотрудников, разрабатывающая информационную систему, приобретает опыт на всех этапах разработки и с каждой следующей итерацией начинает все лучше понимать истинные потребности бизнес-пользователей. Результатом каждой итерации является инкремент.
Scrum - это стандартизированный вариант организации процесса разработки программного обеспечения для итеративной и инкрементальной разработки. Для работы по Scrum необходим набор артефактов, с помощью которых и выполняется управление и направление создаваемого продукта.
Scrum с самого начала создавался для управления процессами контроля, планирования и анализа на всех этапах создания информационной системы. Благодаря такому подходу к разработке он пользуется высокой популярностью у команд, занимающихся поддержкой и/или сопровождением программных продуктов.
Среди множества других, одной из особенностей этой методологии следует выделить ежедневные короткие совещания, во время которых идет обсуждение результатов предыдущих итераций (спринтов) и ставятся задачи на следующие. Это позволяет заинтересованным менеджерам держать под контролем процесс разработки, при необходимости направляя его в нужное русло.
Достоинства Scrum:
Возможность изменения требований привлекательна для многих заказчиков:
Это особенно привлекательно для малых компаний, так как избавляет от необходимости найма или обучения специализированного персонала дорогостоящих руководителей.
Scrum содержит и важные недостатки. Ввиду простоты и минималистичности, Scrum задает небольшое количество довольно жестких правил. Однако это вступает в конфликт с идеей "клиент всегда прав", так как заказчикам не важны внутренние правила команды разработки, особенно если они его ограничивают.
Так же общеизвестной проблемой Scrum являются большие издержки на обсуждения, встречи и большие потери времени на стыках спринтов. Как минимум день уходит на закрытие очередного спринта, а потом день - на открытие нового. В условиях, когда спринт длится 2 недели, 2 дня составляют 20% рабочего времени. Итог - 30-40% времени при применении Scrum тратится на поддержание самого процесса (ежедневные встречи, планирование и детализирование работ, презентация полученных результатов и пр.)
Scrum относится к семейству Agile, в котором не приветствуется создание планов коммуникаций, реагирования на риски, управления сложными техническими изменениями. Итог - сложное, а иногда невозможное формальное (юридическое или административное) противодействие нарушениям правил Scrum. Конечно, нерадивого сотрудника можно просто уволить, но это не является системным способом решения проблемы. Процессы в компании должны быть выстроены так, чтобы, оставляя определенную степень свободы сотруднику, всегда можно было бы контролировать его не только количественно, но и качественно. Для этого есть множество техник и методик, применение которых характеризует зрелость компании в целом и ее процессов в частности. Все лидирующие в различных сегментах компании характеризуются низким уровнем увольняемости. Ротация сотрудников нужна для каждой организации, но ротация не должна быть массовой. Когда уходят ключевые сотрудники, организация ставит себя под удар. В Scrum этот недостаток попытались преодолеть за счет постулата универсализма и упор на самоорганизующуюся многофункциональную команду. При кажущемся снижении затрат на координацию команды это приводит к повышению затрат на отбор персонала, его мотивацию, обучение. В определенных условиях рынка труда, формирование полноценной, эффективной Scrum-команды может быть невозможным. Хорошие сотрудники стоят дорого, и руководство организации должно отдавать себе в этом отчет.
Фокус Scrum - управление продуктом в условиях неопределенных и часто меняющихся требований, которые характеризуют современный неустойчивый информационный мир.
После того как менеджментом компании будет принято решение использовать Scrum в операционной деятельности, необходимо организовать его внедрение. Наиболее важным аспектом в вопросе внедрения является адаптация сотрудников компании к новому рабочему процессу. Адаптация будет эффективной в том случае, когда изменения преподнесены не как новое управленческое веяние, а как необходимость. Организации, в которых подобный подход к процессам и активностям управления изменениями организован на высоком уровне зрелости, имеют значительное преимущество перед конкурентами за счет их гибкости и адаптивности под постоянно меняющиеся условия внешней и внутренней бизнес-среды.
Причины, по которым сотрудники становятся лояльными к организации, ее целям и задачам, продолжают трудиться на ее благо, крайне разнообразны и определяются многими факторами. Продолжать рассуждать о важности разделения сотрудниками миссии компании нецелесообразно.
Если компания заинтересована в сотрудничестве с определенными работниками, ей нужно уметь продумать, иногда индивидуально, как удерживать того или иного "уникума". Для этого можно выделить сегменты респондентов в соответствии с длительностью работы, проанализировать ответы ветеранов для установления возможных закономерностей. По результатам опроса обсуждают пути продолжения работы, выявляют возможные проблемы.
Общие рекомендации, используя которые можно учесть 90% возможных проблем, заключаются в управлении следующими факторами:
В итоге следует, что для воспитания рабочей философии рекомендуется следовать следующим основным принципам:
Подводя локальный итог темы управления и развития кадров в Scrum, нужно сказать сокровенное: "Кадры решают все". Именно сотрудники и их навыки формируют основную ценность любой компании. А когда речь заходит о гибких методологиях, то значимость утверждения, приведенного выше, возрастает в несколько раз. На потенциале и трудолюбии команды будет держаться качество программного продукта. Кадрами предстоит заниматься очень много и кропотливо, но эта работа окупается.
Предпочтения и профессиональные "устои" каждого специалиста формируются в соответствии с широтой его взглядов на мир и шаблонностью профессионального мышления. Как правило, работники стараются бессознательно сопротивляться переменам. Любым. Чем серьезнее и глобальнее перемены, тем более ожесточенные сопротивления. Если речь идет о коренном изменении рабочей философии и переходе на гибкие методологии разработки программного обеспечения, то перестройки кардинальные.
Сопротивление принято снимать за счет жесткой политики перехода, называемой взрывом. Вкратце, она заключается в навязывании сотрудникам новой реальности. "Навязывание" определяется конкретной культурой управления организацией. Руководитель должен быть осторожным и внимательным при принятии любых решений, связанных с проведением изменений, но при этом необходимо решительно придерживаться принятых правил. Даже если они кому-то не нравятся.
Для того чтобы понять, как реагировать на возможное сопротивление, полезно понять, на каком уровне возникают сопротивления:
От понимания того, на каком уровне возникает сопротивление и чем оно характеризуется, возникает понимание способов устранения проблем.
На каждом из приведенных уровней есть свои особенности сопротивления и свои приемы воздействия с целью уменьшения сопротивления.
На организационном уровне структурные и культурные факторы могут способствовать широкому распространению сопротивления. Существующие структура и культура не могут оперативно приспособиться к новым требованиям и измениться. Причины заключаются в том, что для приспособления к изменениям в масштабе предприятия необходим продолжительный интервал времени и большие ресурсы.
Один из способов уменьшения сопротивления - системный подход. Однако сложность заключается в том, что для понимания поведения организации как системы необходимо учитывать поведение всех взаимосвязанных в организации групп. Системный подход предусматривает рассмотрение организации как единого целого, выявление взаимосвязей между различными частями системы, например, путем изменения иерархического порядка принятия решений или обеспечения некоего равновесия между социальной, организационной, технической и прочими частями системы. Если у компании нет ресурсов на применение системного подхода к изменениям, самым действенным способом является лозунг: "Можешь - начинай работать, не можешь - ищи для себя работу". Если речь идет о сотрудниках с невысокой квалификацией, то, возможно, эта стратегия управления изменениями имеет право на существование. Если же речь идет о сотрудниках, которые своими действиями формируют интеллектуальную собственность компании, выраженную в виде автоматизированных процессов и уникальных данных, адаптированных под конкретные условия функционирования организации, то этот подход может привести к катастрофе.
При осуществлении изменений необходимо иметь в виду, что компания как система включает в себя не только формальные группы (управления, отделы, секторы и т. д.), но и неформальные, например группы "ветеранов". Широкое освещение стратегического замысла и консультации перед осуществлением стратегии (в идеале - на стадии проектирования изменений) могут помочь уменьшить сопротивление со стороны групп и выявить, что же действительно беспокоит людей в предложенной ситуации. Для этого может потребоваться:
Формальные и неформальные группы, к которым принадлежат сотрудники, придерживающиеся определенных взглядов относительно изменений. Эти взгляды решающим образом влияют на позицию сотрудника - члена группы, которую он будет занимать.
Некоторые сотрудники, несмотря на принадлежность к группе, могут иметь личную обеспокоенность относительно влияния изменения на их будущее положение в организации, возможностей карьеры, реализации устремлений и перспектив.
При управлении ценными сотрудниками важно правильно понять возможные причины сопротивления конкретных групп работников (консерваторы, прагматики, новаторы), и только после этого можно будет выбрать правильную стратегию управления сопротивлением. Чтобы помочь сотруднику приобрести новое понимание происходящего и пересмотреть свое отношение к изменению, чаще всего требуется индивидуальная работа с ним по разъяснению выгод и преимуществ, которые он лично получит в результате реализации изменений.
Такая работа должна привести к изменению поведения сотрудника. Сопротивляющийся сотрудник - не проблема, а человек, которого необходимо понять и предоставить ему объективную информацию о необходимости выполняемых изменений. Обычно после осознания значимости проводимых изменений сотрудники постепенно переходят на их сторону. При этом важно различать, что причины сопротивления у менеджеров и специалистов могут быть разными по причине разницы выполняемых функциональных обязанностей (табл. 4.1).
| № | Специалисты | Менеджеры |
|---|---|---|
| 1 | Недостаточная информированность | Опасение потери контроля и власти |
| 2 | Страх перед неизвестностью | Нехватка времени |
| 3 | Опасение потерять работу | Устраивает существующее положение вещей |
| 4 | Недостаточная поддержка со стороны руководства | Непонятно, что лично я буду иметь от этих перемен |
| 5 | Невозможность участвовать в принятии решений |
Успешная реализация изменений в организации всегда характеризуется умелым применением целого ряда перечисленных подходов, часто в самых различных сочетаниях, и отличается двумя особенностями - менеджеры используют эти подходы с учетом их достоинств и недостатков и реалистично оценивают ситуацию.
Наиболее распространенной ошибкой руководства является использование только одного или ограниченного числа подходов независимо от ситуации. Это касается и сурового начальника, который часто прибегает к принуждению, и менеджера, ориентированного на своих сотрудников, который постоянно пытается привлекать и поддерживать своих людей, и начальника-циника, всегда манипулирующего своими сотрудниками и часто прибегающего к манипуляции, и интеллигентного менеджера, который в большой степени полагается на образование и общение, и, наконец, менеджера типа адвоката, который всё время старается вести переговоры.
Основная задача руководства - принимать верные и своевременные решения, используя различные подходы не только поодиночке, но и в сочетании друг с другом.
Основная цель использования управленческой методологии Scrum - эффективное управление ресурсами с возможностью сосредоточения всех участников гибкого процесса на конечном результате. В основе Scrum лежат принципы, предписывающие полностью сосредоточиться на продукте, разработка и развитие которого является основным результатом деятельности. Суть принципов Scrum унаследована от принципов, перечисленных в Agile Manifesto (см. главу 1).
Основное внимание сосредоточено на команде как средстве разработки качественного продукта. Реализация продукта осуществляется за счет тесного и постоянного взаимодействия с заинтересованными сторонами в целом и владельцем продукта в частности. В ходе этого взаимодействия команда разработчиков становится более гибкой и готовой к изменениям. Инструменты, документация, условия работы и планы вторичны, но также очень важны. Таким образом, фокус сосредоточен на команде, которая удовлетворяет потребность заказчика.
Команда - группа людей, взаимодополняющих и взаимозаменяющих друг друга, которые собраны для совместного решения задач создания продукта, посредством которых они поддерживают взаимную ответственность перед владельцем продукта. В идеале специалисты, задействованные в Scrum, должны представлять собой самоуправляемый и самоорганизующийся коллектив, цель которого - реализовать требования к продукту в том объеме и с уровнем качества, удовлетворительным для последующего использования продукта.
Успешность рабочего процесса обеспечивается за счет непрерывного общения друг с другом и со всеми заинтересованными сторонами. На всех этапах работы над продуктом происходит непрерывное взаимодействие, в ходе которого определяется, как можно реализовать конкретную задачу с учетом достоинств и недостатков конкретной реализации. Вся полученная в ходе взаимодействия информация учитывается и используется в дальнейшем. В последующем это помогает оптимизировать процесс разработки наилучшим образом и постепенно совершенствоваться и развиваться. Идеал команды в Scrum - самоуправляемый коллектив профессионалов, объединенных общей целью.
Для работы над продуктом у сотрудников, объединенных в единую команду, есть все необходимое - Product Owner, бэклог продукта…
Scrum продуктивен из-за своей простоты. Члены команды имеют свободу самим определять, каким образом разрабатывать продукт. И в этом скрыта самая большая сложность Scrum. Одним из основных качеств, которые отделяют начинающего от состоявшегося профессионала, является черта самоанализа, которая заключается в постоянном переосмыслении того, что и как он делает. Цель самоанализа - улучшить работу, над которой идет размышление. Необходимо вырваться из рамок "так положено" и понять, что конкретно нужно сделать для достижения результата наименьшими затратами. Гибким быть непросто. Для того чтобы быть эффективным, нужна соответствующая квалификация. Именно уровень этой квалификации во многом предопределяет качество проработки требований, которые необходимо реализовать. Но при этом необходимо учитывать, что инженерия требований для разработки функционала должна выполняться в необходимом объеме. Требования должны создаваться непрерывно при активном сотрудничестве заинтересованных лиц с командой разработки. Важно помнить, что конечная цель сбора требований в том, чтобы облегчить и разделить общее понимание требований для всех тех, кто вовлечен в процесс разработки. Требования могут различаться по детальности и степени проработки и принимать самые разные формы. Для получения общего представления о требованиях полезно иметь какую-нибудь форму или шаблон документации, определяемой командой для каждой конкретной ситуации.
В Scrum в качестве инструмента используются use case. Более подробно о технике проработки требований мы поговорим в главе 8.
Основное внимание Scrum-команды сосредоточено на артефакте, разработка которого является их обязанностью, - продукте. Работа над продуктом должна строиться исходя из актуального понимания существующих потребностей в функционале. Можно долго размышлять о возможных путях развития, но эти размышления должны основываться на стойком базисе действительности. Любые прогнозы меняются в зависимости от тактических данных. Тренд необходим, но это не должно быть определяющим фактором в работе. Важно итеративно разрабатывать "нужную" функциональность, постоянно измерять ее эффективность и, отталкиваясь от ключевых актуальных метрик, продумывать дальнейшее направление развития продукта.
Можно выделить еще несколько ключевых факторов, управление которыми будет влиять на создание продукта (риски, технологии, инженерные практики и пр.), но основными являются именно сам продукт и команда, которая участвует в его разработке. Остальные являются либо производными, либо второстепенными, и в соответствии с их значимостью для внедрения и адаптации Scrum будут рассмотрены далее.
Во второй лекции были обоснованы важность и необходимость регламентации существующих в компании процессов как средства контроля, мониторинга и поиску возможностей дальнейшего развития деятельности организации. Наличие регламента позволяет гарантировать организационный порядок, но для этого каждая компания, проводя внедрение определенной процессной деятельности, адаптирует эталонные принципы выбранной методологии для реалий своей компании и стремится к наиболее эффективному использованию существующего процесса в рамках имеющихся ресурсов. Условием и гарантом эффективности процесса является регламент, следуя которому можно достичь запланированных результатов в определенные сроки и прогнозировать дальнейшее развитие функционала.
В Scrum-документах зафиксировано, что основной ценностью являются люди, которые за счет оптимального взаимодействия друг с другом должны достичь запланированных результатов. Именно за счет командного взаимодействия должна достигаться рабочая гармония. Значимость "записанного" порядка взаимодействия снижается, во главу угла выходит человеческий фактор. При создании и следовании процессу необходимо держаться принципа золотой середины, то есть нужно руководствоваться основными постулатами методологии, но корректировать тактику в зависимости от конкретных условий окружающей среды и в уме держать необходимость внедрения принципа гибкости. Командный процесс в идеале должен получиться:
В этом плане Scrum представляет собой процесс "с человеческим лицом", в котором каждый член команды должен контролировать своего сотоварища, так как за результат деятельности несет ответственность вся команда.
Рабочий процесс должен находиться под контролем владельца продукта. Это позволяет избежать нестабильности и добиться возможности достоверно прогнозировать результаты посредством управленческих инструментов. Для обеспечения его контролируемости в Scrum предусмотрены все необходимые атрибуты (доска задач, бэклог продукта, бэклог спринта), о которых мы поговорим чуть позже.
Под инженерными практиками понимается проверенный временем набор технических решений, связанных непосредственно с разработкой программного продукта. Сложно разработать качественный продукт без внедрения этих практик в повседневную работу.
Немаловажным фактором является понимание преимуществ и возможностей того или иного инструмента, а также сложностей и специфики его внедрения.
Большинство практик, применяемых в Scrum, своими корнями уходят в экстремальное программирование. Именно на этой методологии рассматриваемые далее практики доказали свою эффективность.
Для начала поговорим о технике Code Review. Это деятельность, связанная с ревизией, производимой командой кода. Ревизия должна осуществляться на систематической основе. Она позволяет обнаружить и исправить ошибки, оставшиеся незамеченными автором, но заметные для того, кто проводит ревизию. Оговоримся, что ревизию должен проводить каждый раз следующий член команды.
Данная практика позволяет разрабатывать более стабильный и качественный программный продукт. Код программы становится более структурированным и стабильным, плюс ко всему постепенно каждый член команды, прошедший должность ревьюера, начинает более глубоко понимать все детали реализуемой информационной системы.
Далее поговорим о Unit Testing. Это техника, в основе которой лежат инструменты для проверки работоспособности отдельных частей программного продукта как по отдельности, так и в совокупности для проверки интеграции модулей и отдельных систем. Реализация Unit Testing позволяет своевременно реагировать на некорректные изменения логики программного продукта, приводящие к ошибкам и сбоям. Unit-тестирование способствует стабилизации программного продукта и его места в информационном ландшафте заказчика, снижению количества проблем при интеграции.
Code Refactoring. Это не просто техника. Благодаря развитию и распространению Agile рефакторинг стал полноценным техническим направлением деятельности. Refactoring предписывает осуществление изменений внутренней структуры исходного кода, которые не должны повлечь изменения в поведении программы. За счет применения Code Refactoring достигается упрощение структуры программного продукта и повышение скорости его работы. Это способ систематического приведения кода в порядок, при котором шансы появления новых ошибок минимальны. В сущности, при проведении рефакторинга кода вы улучшаете его дизайн уже после того, как он создан.
Как следствие получаем экономию на дальнейшем сопровождении и поддержке.
Build Automation. Это техника автоматической сборки исходного кода, выполнения тестов и развертывания программы на целевом ландшафте. Автоматизация позволяет повысить качество процесса разработки и поставки продукта. Результаты Build Automation не так очевидны бизнес-заказчикам системы, но за счет внедрения этой техники с технической команды снимается часть работы, после чего они могут направить освободившиеся ресурсы на более значимые для бизнес-пользователей активности.
Continuous Integration. Практика непрерывной интеграции направлена на выполнение частых автоматизированных сборок программного продукта. Цель - выявление и решения интеграционных проблем. Переход к непрерывной интеграции позволяет снизить трудоемкость интеграции и сделать ее более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.
Все перечисленные инженерные практики, безусловно, связаны между собой и дают максимальный эффект лишь при работе в комплексе. Каждая из них направлена на поддержание стабильного рабочего процесса, ведущегося по Scrum. Их введение способствует созданию качественных информационных систем быстро и с меньшими рисками.
В промышленной разработке программного продукта самое важное - взаимодействие с заказчиком. Использование инженерных практик и подходов Agile подразумевает регулярную и довольно тесную связь с ним для понимания того, как каждая из внедряемых практик влияет на удовлетворенность заказчика. Каждый из этапов работы над продуктом становится более открытым, понятным и обсуждается на каждой стадии. Внедрение и использование каждой инженерной практики возможно только после того, как владелец продукта оценит ее результат. Команда разработки и заказчик берут на себя одинаковую ответственность за конечный результат.
Agile представляет не столько направление процессной методологии, которое делает акцент на коммуникации взамен избыточному документационному обоснованию выполняемых работ, сколько семейство различных техник, которые доказали свою успешность на протяжении долгого периода эксплуатации в различных типах деятельности.
Основным представителем семейства гибких процессов по распространенности и эффективности является Scrum. Именно на его рассмотрении будет сосредоточен фокус данного курса. Главной отраслью, в которой Scrum нашел свое применение на сегодня, является сфера информационных технологий. Именно поэтому в Scrum появились специализированные артефакты, которые призваны адаптировать его под реалии данного направления деятельности.
При внедрении любой процессной методологии и Scrum в частности необходимо помнить о том, что основной движущей силой любого изменения являются сотрудники. Поэтому необходимо понимание того, как должно выполняться адаптирование нововведения, как необходимо работать с персоналом и каким аспектам внедрения уделить наибольшее внимание.
"Ядро" Scrum - это команда квалифицированных мотивированных специалистов, заинтересованных в развитии программного продукта. Коммуникации внутри команды позволяют преодолевать возникающие проблемы и решать задачи за счет общих договоренностей. Кроме коммуникации для успешного достижения результатов целесообразно применять проверенные временем успешные инженерные практики. Они смогут помочь в решении первостепенных технических задач и сосредоточить внимание профессионалов на разработке качественной информационной системы.
В каждой команде необходимо наличие сотрудников, каждый из которых будет обладать определенными навыками и квалификацией, что позволит выполнять им определенные функции. Таким образом, команда состоит из работников, выполняющих определенные роли.
О команде и ролях мы поговорим в следующей главе.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.