Download as PDF, PPTX
More Related Content
Гибкий подход (Agile,scrum)
- 1. ИНСТРУМЕНТЫ • aвтоматизацияавтоматизация • ИНСТРУМЕНТЫ 58 59www.mdmag.ruМОЕ ДЕЛО. МАГАЗИН • октябрь 2016 а результат записали. Так появился Agile Software Development Manifesto, или, если говорить по-русски, мани- фест о гибкой разработке программ- ного обеспечения. Однако вся эта романтика выгля- дит далекой от сферы бизнеса (если он не касается разработки) и в част- ности ритейла. Однако вместе с Agile и даже до него начали появляться методики работы, включающие в себя подходы Agile и призванные, как выразился один из авторов по- добной методики – Scrum, помочь сделать двойную работу в два раза быстрее. А вот это уже выглядит привлекательно. «На мой взгляд, использование Agile позволяет бы- стрее повысить уровень ответствен- ности всех членов проектной коман- ды за общий результат, повышает уровень взаимопомощи, позволяет сотрудникам быстрее повышать свою квалификацию, – делится мне- нием Алексей Лапшин, генеральный директор компании «АйТи. Бизнес решения». Согласитесь, такие вещи актуальны для любой компании. Вслед за ИТ-командами «гибкий подход»сталиприменятьнебольшие коллективы, которые хоть и не за- нимались ИТ-разработками, но все же производили некий интеллекту- альный продукт, у которого есть ко- нечный заказчик. Например, такими коллективами были анимационные студии. Потом многие корпорации, не связанные непосредственно с ИТ- бизнесом, открыли у себя собствен- ные отделы разработки, чтобы пи- сать обеспечение «под себя», – таким компаниям тоже были интересны новые подходы, особенно учитывая тот факт, что с приходом мобильных технологий все больше предпри- ятий начали приобщаться к разра- ботке ПО хотя бы в виде мобильных приложений. «Отделы разработки внутри компаний обычно создаются (в противовес внешним компаниям- разработчикам) как раз для того, чтобы более тесно работать с биз- несом и его потребностями, более Гибкий подход Как только российские банки всерьез заинтересовались темой Agile, это стало по- настоящему модно, и не только в банковской среде. Настолько модно, что в эфире Пер- вого канала об Agile пытались говорить Владимир Познер и Герман Греф. Последний так впечатлился этой концепцией, что теперь внедряет ее в подразделениях Сбербанка и вы- ступает с объяснениями, почему было принято такое решение. Поветрие дошло и до ри- тейла: в компании «ВкусВилл – Избенка» переходят к гибкому самоуправлению. АВТОР: Наталья Николаева динамично реагировать на изме- нения, свести к минимуму форма- лизацию, когда есть подписанное ТЗ и протокол о том, что разрабо- тано именно то, что написано в ТЗ, но система не используется. Одной из причин появления гибкого под- хода стали серьезные противоречия между динамичными потребностя- ми бизнеса и абсолютной властью согласованного ТЗ, – рассказыва- ет Сергей Осипов, вице-президент MAYKOR-GMCS. – Получалось, как в анекдоте: «Если врач сказал везти в морг, значит, поедем в морг!», пусть больной уже и очнулся». Но даже если компания никак не связана с ПО, не имеет своего ИТ-отдела по разработке софта, не производит интеллектуальный продукт и не стремится стать Agile- компанией, принципы этой фило- софии и даже основы некоторых конкретных методик работы знать недурственно. Хотя бы потому, что при заказе ИТ-продуктов у компа- нии, которая работает по принци- пам Agile, заказчик, скорее всего, будет втянут в игру – исключитель- но для пользы общего дела. «В со- ответствии с Agile-манифестом уча- стие заказчика в проекте – это один из основных принципов. Поэтому если ему вся эта кухня неинтересна, то это и не совсем Agile», – говорит Сергей Стрелков, руководитель на- правления собственных разработок компании КРОК. «На протяжении всего проекта разработчики и пред- ставители бизнеса должны еже- дневно работать вместе», – поясняет Игорь Визгин, product owner марке- тинга и веб-разработки компании «Дримкас». – У нас при создании продуктов происходит постоянное общение разработки и заказчика (представителей бизнеса или, точ- нее, заинтересованных лиц). Наш заказчик глубоко погружен в Agile, и так сложилось, что вся команда была знакома с методологиями. Если клиент выразил желание вне- дриться в процесс по полной, то луч- ше не сворачивать с пути». ак что же такое этот Agile? Простые опреде- ления,разбросанныетут и там по Сети, говорят, что это методология, которую следует приме- нять при разработке программного обеспечения. Звучит как-то слиш- ком специализированно, не правда ли? Тренеры по Agile отвечают: «Это не методология». Практика приме- нения добавляет: «И она не только для разработчиков». Agile – это не формулы и не науч- ные выкладки. Больше всего это по- хоже на то, чем занимались разные литературные школы в прошлом, когда единомышленники собира- лись и обсуждали, как им слагать стихи и прозу и каковы их взгляды на этот предмет. В результате бур- ных дебатов рождался манифест. Так произошло и тут, только вместе собрались не поэты, а ИТ-эксперты, у каждого из которых были идеи от- носительно разработки ПО и взаи- модействия с конечным заказчиком ИТ-продукта. Встретившись в горах Юты (весьма романтично!), 17 че- ловек определили свои ценности и образ мыслей на означенную тему, Т 1. Наивысшим приоритетом для нас является удовлетворение потребно- стей заказчика благодаря регулярной и ранней поставке ценного программ- ного обеспечения. 2. Изменение требований приветствует- ся даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. 3. Работающий продукт следует выпу- скать как можно чаще, с периодично- стью от пары недель до пары месяцев. 4. На протяжении всего проекта разра- ботчики и представители бизнеса долж- ны ежедневно работать вместе. 5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и пол- ностью доверьтесь им. 6. Непосредственное общение являет- ся наиболее практичным и эффектив- ным способом обмена информацией как с самой командой, так и внутри команды. 7. Работающий продукт – основной пока- затель прогресса. 8. Инвесторы, разработчики и пользова- тели должны иметь возможность под- держивать постоянный ритм бесконечно. Agile помогает наладить такой устойчи- вый процесс разработки. 9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. 10. Простота – искусство минимизации лишней работы – крайне необходима. 11. Самые лучшие требования, архитек- турные и технические решения рождают- ся у самоорганизующихся команд. 12. Команда должна систематически ана- лизировать возможные способы улучше- ния эффективности и соответственно кор- ректировать стиль своей работы. Источник: сайт http://agilemanifesto.org/ Основополагающие принципы Agile-манифеста
- 2. ИНСТРУМЕНТЫ • aвтоматизацияавтоматизация • ИНСТРУМЕНТЫ 60 61www.mdmag.ruМОЕ ДЕЛО. МАГАЗИН • октябрь 2016 Впрочем, разработчики не слиш- ком настойчивы в этом вопросе. Если заказчик говорит «нет», то ему не придетсяискатьсебедругогопод- рядчика. «На мой взгляд, это вопрос ваших отношений с заказчиком, – комментирует Алексей Лапшин. – Наш опыт показывает, что вовлече- ние заказчика в Scrum-активности повышает эффективность проекта. Но если заказчик к этому не готов или активно сопротивляется тако- му вовлечению, а эффективность проектов вас устраивает, то и ме- нять ничего не нужно». Начав об Agile, мы заговорили о Scrum. Дело в том, что Agile – это список определенных ценностей и ориентиров, в то время как кон- кретный образ действий, тактика, описываются в таких системах, как Scrum, и другие. «Существует ряд методологий, реализующих гиб- кий подход: Scrum, экстремальное программирование (XP), DSDM, Crystal, FDD, Kanban, – перечисляет Сергей Осипов. – Scrum является наиболее распространенной мето- дологией гибкой разработки, име- ющей свои особенности». «Agile – это образ мышления, куль- тура, опирающаяся на ценности, описанные в манифесте. Agile – это то, как люди думают. В то время как Scrum – один из многих фреймвор- ков, способов организации своей работы. Scrum – это то, как люди работают», – поясняет Сергей Дми- триев, business agility coach, основа- тель компании Unusual Concepts. – При этом часто бывает так, что говорим Agile – подразумеваем Scrum. У большинства людей эти понятия не разделяются, и они пользуются ими попеременно. Многие считают Agile и/или Scrum методологией, что тоже неверно. Методология – это рецепт, позво- ляющий достичь определенных результатов. Ни Agile, ни Scrum ме- тодологией не являются. Почему произошла путаница этих понятий, мы можем только гадать, возмож- но, потому, что, услышав что-то новое, люди не удосуживаются под- робно изучить детали, а собирают информацию по слухам коллег, ко- торые собирали ее по слухам дру- гих коллег. Или, может быть, это связано с широким распростране- нием фреймворка Scrum: на сегод- няшний день им пользуются более 80% agile-команд». По словам Сергея Дмитриева, внедрить Agile в компании нель- зя по определению: «Внедрить Agile» – очень странная фраза, ведь мы обычно не говорим «внедрить людям в нашей организации опре- деленный образ мышления», ско- рее, правильно говорить о «пере- ходе к новому образу мышления». При этом перейти на определенный образ мышления в одном отделе изолированно от остальной органи- зации, – это тоже довольно странная история. Представьте, что мы бы за- хотели в русской ортодоксальной церкви перевести хор на исповедо- вание ислама. Agile это все-таки об- раз мышления для всей организа- ции, а не для какой-то ее части. Это еще одна очень распространенная ошибка в понимании смысла Agile. Другое дело Scrum. Его как фрейм- ворк можно применить изолиро- ванно внутри какого-либо отдела. Хотя, скорее всего, вы очень быстро обнаружите, что Scrum, опираясь на определенные ценности, будет обнажать проблемы в других частях организации, которые потребуют вашего внимания и соответствую- щего изменения образа мышления людей вне того отдела, где Scrum был внедрен изначально». Scrum в массы! Если Scrum другое дело – рассмо- трим его поподробнее. В то время как идеи Agile умещаются на одну страницу, о Scrum пишут целые кни- ги.Книгиполучаютсяпотому,чтоав- торы подробно объясняют, что они попробовали, что получилось, а что не сработало. Все пересказывать не будем, но основная идея такова. Нужно реализовать продукт. Для этого продукта составляется один список задач и назначается один принимающий (product owner) – это как раз должен быть либо сам заказчик, либо его полномочный представитель, который будет при- нимать непосредственное участие в планировании, демонстрации, об- суждении итогов. Именно он ставит задачи (user story), которые вносят- ся в список (product backlog), а так- же назначает важность этих задач. Итак, список готов, задачи там упо- рядочены в соответствии с их важно- стью. Далее команда, которая будет выполнять эти задачи, приглашается на планирование. Здесь они не сидят и слушают, что прикажет началь- ник, а сами оценивают трудозатраты и пытаются определить, сколько за- дач они сделают за определенный пе- риод, и составляют список (sprintlog) на этот период. Определенный пе- риод называется sprint. До момента окончания работ и создания полно- ценного продукта таких периодов может быть много, но при этом це- льюкаждогопериодаявляетсязавер- шение определенного функционала, который можно – и обязательно нуж- но – показать принимающему. «Еще один ключевой принцип Agile – мак- симально быстро доставить до заказ- чика значимый результат, – делится опытом Сергей Стрелков, – поэтому в отделе разработки КРОК есть как методологические принципы, так и инструментальная поддержка, по- зволяющая довольно быстро под- готовить прототип системы, сгене- рированный по модели предметной области, и показать его заказчику еще на начальных этапах проекта. После чего мы стараемся выпускать релизы системы с минимальными временными интервалами, посте- пенно наращивая начальный резуль- тат и максимально адаптируя его под потребности заказчика». Командно определяется, сколь- ко задач может включить в себя 1 sprint и как будут продемонстри- рованы результаты. Затем команда решает, кто что будет делать. Ответ- ственность за принятые решения лежат на команде, самоорганизо- ваться им помогает Scrum-мастер. Таким образом, нет приказов сверху. Есть задачи и есть профессионалы, которые будут ее выполнять. Вопросам планирования уделяется очень много времени. Сначала идет общее планирование (где каждый раз присутствует полномочный представитель заказчика), затем начинается sprint, в ходе которо- го проводятся ежедневные Scrum- пятиминутки. В ходе планирования и непосредственной работы особое место отводится визуализации: для этого нужна доска, графы в ней (например, «в планах», «в процес- се», «готово», «цель (с графиком)»), и стикеры, которые по ходу дела перемещаются из графы в графу. Таким образом, в любой момент времени команда видит, как идет работа, кто что делает, сколько еще осталось и что мешает. Процесс планирования отчасти геймифици- рован. Например, Хенрик Книберг в своей книге «Scrum и XP: заметки с передовой» рассказывает, как для оценки трудозатрат у них «играют» в специальный планировочный по- кер. Совещания длинные, но ску- чать там некогда: все вовлечены, все участвуют, голос каждого важен. При этом качество выпускаемого функционала даже не обсуждает- ся – оно всегда должно быть макси- мальным. Сляпать абы что, только бы показать это заказчику – не вы- йдет. Причина проста: по оконча- нии спринта команда проводит демонстрацию своих наработок: то, что они сделали, должно на- глядно функционировать. Помимо заказчика на демонстрации при- сутствуют другие отделы. Никому не хочется тратить время на ерун- ду, и если команда оплошала, то все видят это, нет шансов. Коллеги ворчат, заказчик понимает, что де- монстрация пошла не туда, – в ито- ге всем очевидно, что качество все- таки страдать не должно. По окончании спринта проводит- ся ретроспектива (и опять с уча- стием заказчика): оценивается продуктивность (человеко-дни), верность прогнозов, которые дава- ла команда в самом начале, обсуж- Agile в ритейле Чтобы понять, насколько ритейл при- близился к Agile и гибкому управле- нию, мы взяли интервью у Валерия Разгуляева, управляющего информа- цией «ВкусВилл – Избенка». Эта тема близка компании. Недавно Валерий даже выступил в качестве докладчи- ка в рамках Agile Business Conference 2016 в Москве. – Agile кажется узкоспециализиро- ванной методологией, направленной исключительно на управление неболь- шими командами, занимающимися изготовлением интеллектуального продукта. Однако банки с восторгом отнеслись к новым принципам рабо- ты и внедряют их у себя. Возможно ли такое в ритейле? – Если мы обратимся к манифесту гиб- кого управления, то обнаружим, что его принципы универсальны и применимы не только к разработке программного обеспечения, но и к любой сфере, в кото- рой происходит управление. Разумеется, все это применимо и к рознице. Более того, в России уже сейчас есть рознич- ные компании, которые живут по этим принципам. Причем это как не очень большие, узкоспециализированные ком- пании, такие как «Альпиндустрия»; так и «ВкусВилл – Избенка». – Как выглядит Agile на практике? – Если говорить про нас, то это ком- пания, где нет бюджетов, дресс- кода и спускаемых сверху приказов. Любое нововведение проговаривается с помощниками по рознице на пред- мет удобства их использования для продавцов-консультантов. Бухгалтерия значит меньше, чем удовлетворение клиента, и в случае конфликта инте- ресов именно бухгалтерия думает, как правильно оформить то, что было пра- вильно с точки зрения наилучшего обслуживания клиентов. Что касается логистики, то товар доставляется с рас- пределительного центра в магазины без приемо-передач от склада транспорту и от транспорта в магазины – води- тель просто забирает товар на складе и оставляет его в магазине ночью, когда там может еще никого больше и не быть. Наш покупатель может любой товар вернуть без объяснения причин, чека и паспорта; может любой товар бес- платно попробовать, чтобы понять, хочет он его покупать или нет. В целом все друг другу по умолчанию доверяют. Нет никаких штрафов, а если чело- век не справляется со своей работой, то его работу просто разделяют между ним и еще одним сотрудником, чтобы понять, субъективны или объективны проблемы, с которыми он столкнулся. А еще у нас есть форум, который изо- билует таким количеством негативных сообщений о работе магазинов, что любая другая компания уже давно удалила бы если и не весь форум, то все такие сообщения. Но мы открыты. – Что бы вы посоветовали ритейлеру, который захочет попробовать Agile в своей организации? – Я руковожу проектом перехода на эво- люционное управление в нашей компа- нии. Кроме гибкого самоуправления оно включает в себя еще последовательное и повсеместное следование всеми сотруд- никами эволюционной цели компании, принятой и выработанной ими же. А также их цельность на работе, то есть отсут- ствие у сотрудников масок и лицемерия, позволяющее им получать наслаждение от своей работы и искренне радоваться достижению компанией своих целей. Тем, кто решится на подобное у себя, могу сразу сказать, что ошибкой является ожи- дание, будто самоуправление само возь- мет верх, достаточно его декларативно разрешить. Его придется кропотливо вне- дрять сверху, сталкиваясь с сопротивле- нием на всех уровнях иерархии, вклю- чая и линейных сотрудников, которым придется брать на себя дополнительную ответственность, очень непривычную им. Но игра стоит свеч, так как благодаря эво- люционному управлению решения будут приниматься там, где возникает пробле- ма, и именно тогда, когда она возникает, а руководители из надзирателей и карате- лей превратятся в помощников и настав- ников. Кстати, вопреки некоторым мне- ниям, русский менталитет очень хорошо подходит к самоуправлению, возможно, даже лучше, чем любой другой.
- 3. ИНСТРУМЕНТЫ • aвтоматизацияавтоматизация • ИНСТРУМЕНТЫ 62 63www.mdmag.ruМОЕ ДЕЛО. МАГАЗИН • октябрь 2016 дается, что улучшить в следующем «забеге». Между спринтами дела- ется короткий перерыв, а потом цикл повторяется. Это что касается процесса работы. Основная же задача Scrum – помочь команде в частности и компании в целом быть гибкими, не бояться изменений техзадания от заказчи- ка, непрерывно уточнять задачи и менять их по мере необходимо- сти, «открыться» для заказчика, не выстраивая перед собой барри- кад из регламентов, согласований, долгой разработки и долгого же ут- верждения. «Самое плохое – это если разработчик не контактирует с за- казчиком в течение длительного времени – полгода или год, – гово- рит Сергей Стрелков. – За это время у заказчика может все поменяться, включая людей и бизнес-процессы». Начнем забег с понедельника? На словах Scrum вовсе не кажется чем-то слишком сложным. «Ключе- вая идея гибкого подхода достаточ- но проста, – подтверждает Сергей Осипов, – но эта внешняя простота обманчива. Эффективность и ре- зультативность любой методологии и технологии зависит от того, как ор- ганизованы, как выполняются и кон- тролируются конкретные процессы, от конкретных людей на конкретных позициях (дьявол в деталях). Именно поэтому прочитать книгу с условным названием «Agile для чайников» и на- чать работать по новой методологии «с понедельника» можно, но хороших результатов ожидать сложно. Чтобы не идти методом проб и ошибок, мно- гие команды нанимают людей, име- ющих практический опыт работы по соответствующей методологии, или привлекают внешних менторов. Хороший тренер – это тот, у которого есть не только теоретические зна- ния, но и практический опыт». «Scrum не внедряется быстро, – добавляет Алексей Лапшин. – Это серьезное изменение не только в технологии, но и в отношении к работе, проекту, ответственности, своей роли. Легкость вовлечения за- казчиказависитот вашихс нимотно- шений, уровня доверия, вашей спо- собности объяснить, что изменится в проекте в связи с таким вовлече- нием, как изменится производитель- ность команды, удовлетворенность заказчика результатом. Не надо стремиться все сделать в один шаг, даже если вы считаете, что готовы к такому шагу. Начните с простых, понятных, но эффективных изме- нений. Внедрите итерационность (sprint) в проект, организуйте де- монстрации приращения продукта в конце каждой итерации, настрой- те отчетность исполнения в рамках каждой итерации по исполнению работ, по изменениям в требовани- ях, по тестированию. Затем привле- ките заказчика к приоритезации, планированию. Демонстрируйте ему, как меняется производительность команды от итерации к итерации за счет слаженности команды, полу- чения обратной связи. Внедрение Scrum не может завершиться, всегда есть место для улучшений, но вы до- бьетесь большего внимания со сто- роны заказчика. Поиграйте с длиной итерации. Чем короче итерация, тем чаще вы обсуждаете результаты с за- казчиком, но тем сложнее выделить работы, которые можно успеть сде- лать и при этом показать значимое приращение продукта». Участие заказчика – еще один камень преткновения. Он должен хотеть участвовать. «Если у за- казчика нет времени на проект, то, значит, нет и обратной связи, что в итоге приводит к несоответ- ствию разрабатываемой системы с видением ее на стороне заказ- чика, – рассуждает Сергей Стрел- ков. – Например, в практике КРОК принято еще на этапе предложения описывать степень вовлеченности заказчика в работу над проектом. Так как мы работаем с крупными компаниями, то с их стороны при- нимают участие десятки людей: от пользователей и финансистов до инженеров и руководителей ИТ- подразделений, все из них находят время для проекта». Почему внезапно стать Agile-ори- ентированной компанией не по- лучится, понятно на примере про- стейшего житейского опыта. Кто из нас не знает, что физкультура – это полезно, и хорошо бы начать бегать с понедельника? Но кто из нас действительно побежал, и не просто побежал, но и про- должил свои благие начинания? «Мы уже разобрались, что Agile – это не методология, – объясняет детали Сергей Дмитриев. – Про- читать манифест и завтра же на- чать работать с новым сознани- ем в теории можно. На практике вам будет мешать прошлый опыт. На сегодняшний день наши орга- низации не основаны на тех цен- ностях, которые описаны в ма- нифесте. И если вы прочитаете сегодня в умной книге, что завтра нужно действовать по-другому, ваши реальные действия завтра, скорее всего, не изменятся, потому что действовать вы будете по при- вычке. Именно поэтому и нужны тренеры и коучи, которые будут «держать зеркало» и давать орга- низации обратную связь, показы- вая нам наши собственные дей- ствия со стороны и комментируя, когда они будут расходиться с на- шими новыми намерениями. Пере- ход организации к новому образу мышления завершится только тогда, когда большинство людей в компании начнет думать и дей- ствовать по-другому. Это процесс изменения сознания личности, который не происходит за день, неделю и даже месяц. Именно по- этому процесс трансформации ор- ганизации занимает многие годы, иногда десятилетия». Кому с Agile жить хорошо С одной стороны, Agile стал про- никать в самые разные сферы биз- неса. Принципы гибкого подхода теперь пытаются перенести даже на методы управления проекта- ми или компаниями в целом. «Это признает, в частности, и Project Management Institute, который уже сертифицирует специалистов- практиков по методам Agile», – го- ворит Сергей Стрелков. С другой стороны, всегда ли при- менимы эти принципы? «Подход применим, когда есть люди, кото- рые знают, как его использовать в конкретной ситуации, – считает Игорь Визгин. – Карго-культ – глав- ная проблема при работе в Agile. Слепое подражание не дает резуль- татов и заканчивается разочарова- нием. Если говорить про рабочую ситуацию, то использование не- скольких вариантов в работе одной команды снижает эффективность. Я бы не хотел оказаться в ситуации, когда с одним заказчиком работаем по скраму, с другим – по канбану, с третьим – по уотерфолу, а потом приходит еще один клиент, и на- чинается классическое проектное управление. На мой взгляд, глав- ное – работать по одной методоло- гии, а не устраивать микс, подстра- иваясь под каждого заказчика». «Принципы Agile сложно при- менять только в случае госкон- трактов, – считает Сергей Стрел- ков, – так как Agile подразумевает гибкость по отношению к техниче- скому заданию в отличие от нашего законодательства. Однако некото- рые положения можно воплощать и тут. Например, в ходе работы техническое задание может быть детализировано с порождением частных ТЗ, функциональных спец- ификаций и прочих документов, ко- торые уточняют требования». По мнению Сергея Осипова, целе- сообразность применения Agile под вопросом в следующих случаях: • в инфраструктурных проектах, имеющих сложный процесс под- держки; • в проектах, где подтверждение технического задания требует очень длительного формального цикла; • если нет обратной связи с ко- нечным пользователем системы, а также невозможно иным спосо- бом улучшать знания о предмет- ной области у проектной команды; • если команда состоит из недо- статочно квалифицированных специалистов, которые не готовы к изменениям и внедрению про- грессивных подходов. Он обрисовывает конкретную ситуацию: «Максимальный эф- фект достигается в том случае, когда применяемая методология соответствует целям и задачам конкретного проекта. Например, компания-разработчик выиграла открытый конкурс на разработку системы для заказчика. При этом конкурсная документация содер- жала не только детальное тех- ническое задание на разработку системы, но также определяла ста- дии и этапы реализации проекта, принципы документирования, по- рядок сдачи-приема и т.п. В этом случае не самой удачной идеей бу- дет после заключения контракта предложить заказчику работать по какой-то из Agile-методологий. С другой стороны, можно приве- сти следующий пример сочетания элементов различных методоло- гий. Для заказчика выполнялась разработка комплексной инфор- мационной системы. Работы ве- лись по техническому заданию, где все этапы были заранее опре- делены. Одним из этапов была разработка серверной части. В процесс разработки серверной части весьма сложно вовлекать ко- нечных пользователей на итера- ционной основе (как этого требу- ют методологии гибкого подхода), так как для пользователя сервер- ная часть почти «невидима». Тогда было принято решение проводить регулярные итерации с привлече- нием двух сторонних компаний- разработчиков, которые в этом случае выступали в роли оппонен- тов. Это позволило значительно повысить качество разработки и избежать ряда рисков на самых ранних этапах».