Гибкий подход (Agile,scrum)

ИНСТРУМЕНТЫ • 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-манифеста



Впрочем, разработчики не слиш-ком настойчивы в этом вопросе. Если заказчик говорит «нет», то ему не придется искать себе другого под-рядчика. «На мой взгляд, это вопрос ваших отношений с заказчиком, – комментирует Алексей Лапшин. – Наш опыт показывает, что вовлече-ние заказчика в 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 в своей организации?

– Я руковожу проектом перехода на эво-люционное управление в нашей компа-нии. Кроме гибкого самоуправления оно включает в себя еще последовательное и повсеместное следование всеми сотруд-никами эволюционной цели компании, принятой и выработанной ими же. А также их цельность на работе, то есть отсут-ствие у сотрудников масок и лицемерия, позволяющее им получать наслаждение от своей работы и искренне радоваться достижению компанией своих целей. Тем, кто решится на подобное у себя, могу сразу сказать, что ошибкой является ожи-дание, будто самоуправление само возь-мет верх, достаточно его декларативно разрешить. Его придется кропотливо вне-дрять сверху, сталкиваясь с сопротивле-нием на всех уровнях иерархии, вклю-чая и линейных сотрудников, которым придется брать на себя дополнительную ответственность, очень непривычную им. Но игра стоит свеч, так как благодаря эво-люционному управлению решения будут приниматься там, где возникает пробле-ма, и именно тогда, когда она возникает, а руководители из надзирателей и карате-лей превратятся в помощников и настав-ников. Кстати, вопреки некоторым мне-ниям, русский менталитет очень хорошо подходит к самоуправлению, возможно, даже лучше, чем любой другой.



дается, что улучшить в следующем «забеге». Между спринтами дела-ется короткий перерыв, а потом цикл повторяется. Это что касается процесса работы. Основная же задача Scrum – помочь команде в частности и компании в целом быть гибкими, не бояться изменений техзадания от заказчи-ка, непрерывно уточнять задачи и менять их по мере необходимо-сти, «открыться» для заказчика, не выстраивая перед собой барри-кад из регламентов, согласований, долгой разработки и долгого же ут-верждения. «Самое плохое – это если разработчик не контактирует с за-казчиком в течение длительного времени – полгода или год, – гово-рит Сергей Стрелков. – За это время у заказчика может все поменяться, включая людей и бизнес-процессы».

НачНем забег с поНедельНика?На словах Scrum вовсе не кажется чем-то слишком сложным. «Ключе-вая идея гибкого подхода достаточ-но проста, – подтверждает Сергей Осипов, – но эта внешняя простота

обманчива. Эффективность и ре-зультативность любой методологии и технологии зависит от того, как ор-ганизованы, как выполняются и кон-тролируются конкретные процессы, от конкретных людей на конкретных позициях (дьявол в деталях). Именно поэтому прочитать книгу с условным названием «Agile для чайников» и на-чать работать по новой методологии «с понедельника» можно, но хороших результатов ожидать сложно. Чтобы не идти методом проб и ошибок, мно-гие команды нанимают людей, име-ющих практический опыт работы по соответствующей методологии, или привлекают внешних менторов. Хороший тренер – это тот, у которого есть не только теоретические зна-ния, но и практический опыт».«Scrum не внедряется быстро, – добавляет Алексей Лапшин. – Это серьезное изменение не только в технологии, но и в отношении к работе, проекту, ответственности, своей роли. Легкость вовлечения за-казчика зависит от ваших с ним отно-шений, уровня доверия, вашей спо-собности объяснить, что изменится в проекте в связи с таким вовлече-нием, как изменится производитель-

ность команды, удовлетворенность заказчика результатом. Не надо стремиться все сделать в один шаг, даже если вы считаете, что готовы к такому шагу. Начните с простых, понятных, но эффективных изме-нений. Внедрите итерационность (sprint) в проект, организуйте де-монстрации приращения продукта в конце каждой итерации, настрой-те отчетность исполнения в рамках каждой итерации по исполнению работ, по изменениям в требовани-ях, по тестированию. Затем привле-ките заказчика к приоритезации, планированию. Демонстрируйте ему, как меняется производительность команды от итерации к итерации за счет слаженности команды, полу-чения обратной связи. Внедрение Scrum не может завершиться, всегда есть место для улучшений, но вы до-бьетесь большего внимания со сто-роны заказчика. Поиграйте с длиной итерации. Чем короче итерация, тем чаще вы обсуждаете результаты с за-казчиком, но тем сложнее выделить работы, которые можно успеть сде-лать и при этом показать значимое приращение продукта».Участие заказчика – еще один камень преткновения. Он должен хотеть участвовать. «Если у за-казчика нет времени на проект, то, значит, нет и обратной связи, что в итоге приводит к несоответ-ствию разрабатываемой системы с видением ее на стороне заказ-чика, – рассуждает Сергей Стрел-ков. – Например, в практике КРОК принято еще на этапе предложения описывать степень вовлеченности заказчика в работу над проектом. Так как мы работаем с крупными компаниями, то с их стороны при-нимают участие десятки людей: от пользователей и финансистов до инженеров и руководителей ИТ-подразделений, все из них находят время для проекта».Почему внезапно стать Agile-ори- ентированной компанией не по-лучится, понятно на примере про-

стейшего житейского опыта. Кто из нас не знает, что физкультура – это полезно, и хорошо бы начать бегать с понедельника? Но кто из нас действительно побежал, и не просто побежал, но и про-должил свои благие начинания? «Мы уже разобрались, что Agile – это не методология, – объясняет детали Сергей Дмитриев. – Про-читать манифест и завтра же на-чать работать с новым сознани-ем в теории можно. На практике вам будет мешать прошлый опыт. На сегодняшний день наши орга-низации не основаны на тех цен-ностях, которые описаны в ма-нифесте. И если вы прочитаете сегодня в умной книге, что завтра нужно действовать по-другому, ваши реальные действия завтра, скорее всего, не изменятся, потому что действовать вы будете по при-вычке. Именно поэтому и нужны тренеры и коучи, которые будут «держать зеркало» и давать орга-низации обратную связь, показы-вая нам наши собственные дей-ствия со стороны и комментируя, когда они будут расходиться с на-шими новыми намерениями. Пере-ход организации к новому образу мышления завершится только тогда, когда большинство людей в компании начнет думать и дей-ствовать по-другому. Это процесс изменения сознания личности, который не происходит за день, неделю и даже месяц. Именно по-этому процесс трансформации ор-ганизации занимает многие годы, иногда десятилетия».

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

Management Institute, который уже сертифицирует специалистов-практиков по методам Agile», – го-ворит Сергей Стрелков. С другой стороны, всегда ли при-менимы эти принципы? «Подход применим, когда есть люди, кото-рые знают, как его использовать в конкретной ситуации, – считает Игорь Визгин. – Карго-культ – глав-ная проблема при работе в Agile. Слепое подражание не дает резуль-татов и заканчивается разочарова-нием. Если говорить про рабочую ситуацию, то использование не-скольких вариантов в работе одной команды снижает эффективность. Я бы не хотел оказаться в ситуации, когда с одним заказчиком работаем по скраму, с другим – по канбану, с третьим – по уотерфолу, а потом приходит еще один клиент, и на-чинается классическое проектное управление. На мой взгляд, глав-ное – работать по одной методоло-гии, а не устраивать микс, подстра-иваясь под каждого заказчика».«Принципы Agile сложно при-менять только в случае госкон-трактов, – считает Сергей Стрел-ков, – так как Agile подразумевает гибкость по отношению к техниче-скому заданию в отличие от нашего законодательства. Однако некото-рые положения можно воплощать и тут. Например, в ходе работы техническое задание может быть детализировано с порождением частных ТЗ, функциональных спец-ификаций и прочих документов, ко-торые уточняют требования».По мнению Сергея Осипова, целе-сообразность применения Agile под вопросом в следующих случаях:• в инфраструктурных проектах, имеющих сложный процесс под-держки;• в проектах, где подтверждение технического задания требует очень длительного формального цикла;• если нет обратной связи с ко-нечным пользователем системы, а также невозможно иным спосо-

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

Technology

Гибкий подход (Agile,scrum)