На Гайдаровском форуме Герман Греф заявил, что Сбербанк перейдет на новые информационные технологии, выбрав в качестве основного партнера российско-американскую компанию со штатом 60 сотрудников.
При этом Сбербанк потратил 65 млрд руб.
над амбициозным и сложным проектом по централизации ИТ-структуры и сегодня насчитывает более 22 000 ИТ-сотрудников, в том числе 6 тысяч человек в Сбертехе.
Основной причиной перехода стала скорость изменений в ИТ, которая была низкой и привела к отставанию ИТ Сбербанка от лидеров по развитию и гибкости ИТ-инфраструктуры.
Насколько важна скорость внесения изменений в разработку? На что следует обратить внимание при управлении процессом разработки? Стоит ли использовать модели и методологии? Давайте попробуем разобраться.
Окружен
При разработке собственной автоматизированной системы управления (АСУ) перед вами возникают вопросы с двух сторон.Например, с одной стороны, вы сами управляете процессом разработки, а с другой — адаптируете свою XRM (например, Рули24 ) для компаний, желающих использовать его как инструмент управления своим развитием (девелоперские компании, партнеры девелоперских компаний).
Помимо того, что система включает в себя учет временных ресурсов и планирование задач, вам необходимо правильно оценить среду, с которой вам предстоит работать.
На упрощенной схеме ИТ-инфраструктуры компании все элементы разделены.
Однако мы с вами прекрасно знаем, что в реальной жизни «чистый профиль» встречается редко и нет четкого разделения функциональных обязанностей.
На самом деле, в этом нет ничего плохого; более того, в последнее время набирает популярность DevOps — подход, предполагающий «гибрид» разработчика и администратора, а также быстрое развертывание и тестирование релизов.
Именно ввиду таких функциональных пересечений на первый план выходит управление развитием.
Прежде чем перейти к моделям, приемам и методам, давайте обрисуем цикл разработки, которым необходимо управлять.
Подходов к циклу существует огромное количество, но мы обратимся к стандарту ГОСТ 34.601-90. 
Мы неслучайно затронули эту тему – в нашей компании ILADA возникла острая необходимость изменения модели управления развитием в связи с ростом бизнеса и динамичными требованиями наших клиентов.
Эксперты нашей команды тщательно проанализировали различные модели и методологии и взвесили все «за» и «против».
Сегодня мы готовы поделиться с вами материалом, а заодно выслушать в комментариях рекомендации, основанные на вашем опыте.
Модели развития – три столпа управления
Управление ИТ и управление развитием всегда стремились найти оптимальную модель.Модели развивались вместе с технологиями и изменениями в коммерческой составляющей разработки.
Скорость изменения технологий, развитие бизнеса и постоянно меняющийся спрос повлияли на модели: от жесткого водопадного развития мир пришел к итеративной модели и так называемой гибкой разработке.
Однако, как и в любой науке, обязательно учитывался предыдущий опыт и переносился лучший опыт всех моделей в более современные.
Выделим и кратко рассмотрим три основные модели.
Каскадная модель развития (водопадная модель): определение требований, проектирование, программирование, тестирование, внедрение, сопровождение.
Разработчик, следуя этой модели, последовательно переходит от одного этапа к другому.
Очевидно, что, несмотря на строгость подхода и четкое выделение этапов, данная модель негибкая и требует больших трудовых и временных ресурсов.
Казалось бы, каскадная модель в наше время должна была отмереть как непродуктивная, но она продолжает жить и использоваться, хотя все больше и больше в государственных и оборонных структурах.
Например, в проектах государственного значения в Германии принято использовать V-модель развития, в основе которой лежит каскадная модель.
Этот выбор не лишен логики: такую модель можно тщательно контролировать и снизить большинство управленческих рисков.
Однако государство редко работает в режиме жесткой экономии и не вынуждено каким-либо образом оптимизировать процесс – у него другие задачи.
Современный бизнес выбирает разные модели.
Итеративная модель разработки предполагает выполнение работ параллельно с постоянным анализом результатов и корректировкой предыдущих этапов.
Здесь процесс разработки предстает перед нами как цикл: планирование – разработка – тестирование – оценка.
Эта модель выглядит привлекательно за счет снижения рисков, работы в проектных командах, равномерного распределения нагрузки участников разработки, постоянного тестирования и доработки.
Вероятно, это наиболее подходящая модель разработки корпоративного программного обеспечения, поскольку она предполагает взаимодействие пользователя и клиента, использует опыт команды и снижает накладные расходы на разработку.
С точки зрения рынка продукт, созданный с использованием итеративной модели, может быть дешевле, чем аналогичный продукт, созданный с использованием каскадной модели.
Спиральная модель , также подходит для коммерческой разработки, особенно сложных проектов), сочетает в себе преимущества прототипирования (создание минимально работающего прототипа) и водопадной модели.
При этом на каждом этапе могут использоваться разные модели разработки, главное, чтобы заказчик как можно быстрее получил работающее программное обеспечение.
По сути, это итерационная разработка: не завершив один этап, разработчики переходят к следующему, дополняющему результаты предыдущего этапа.
Благодаря формированию плана разработки и строгому его соблюдению разработка осуществляется достаточно быстро.
Эта модель помогает преодолеть такие проблемы управления компанией-разработчиком, как нехватка рабочей силы, задержки в разработке и доставке программного обеспечения, а также изменение требований клиентов.
Особенно успешно эта модель работает на крупных проектах, например, при внедрении сложных дорогостоящих CRM и ERP, когда в процессе доработки и развертывания системы клиент имеет ограниченные ресурсы на стороне вендора (вся команда не может работать над одним клиента), так и на стороне заказчика в любое время могут быть получены измененные требования.
В рамках каждой модели разработчики могут применять разные методологии разработки программного обеспечения — системы ценностей разработчика, которые лежат в основе бизнес-процессов и управления разработкой.
Как выбрать модель развития?
Современные компании — это универсальные организации, которые одновременно разрабатывают основной продукт, создают клиентские версии, осуществляют модификации и реализуют внедрение.Соответственно, следовать одной выбранной модели очень сложно.
Чтобы определить, какая модель подходит вашей компании, вам нужно провести небольшое внутреннее исследование.
- Как позиционирует себя компания — разработчик крупных заказных проектов, вендор (производитель) серийного ПО, разработчик уникального решения, разработчик SaaS-решений или разработчик небольших проектов? Или, может быть, она участвует в проектах по внедрению программного обеспечения?
- Как долго длятся эти проекты: месяц, квартал, год, три года или десятилетия?
- Каков состав команды? Какова квалификация?
- Кто клиент? Готовы ли типичные клиенты работать на стороне разработчика и взаимодействовать на всех этапах, или они пассивные наблюдатели, согласовавшие техническое задание и ожидающие результата?
Например, крупные проекты, в том числе разработки для ОПК и промышленности, скорее всего, выберут каскадную модель, позволяющую максимально глубоко изучить все аспекты взаимодействия технологий при разработке, разделить зоны ответственности и тщательно реализация каждого этапа.
Думаю, что крупные разработчики и поставщики масштабных корпоративных и пользовательских решений также тяготеют к каскадной или смешанной модели: операционные системы (кстати, в случае с Microsoft это MSF — сочетание каскадной и спиральной моделей), CRM, ERP, xRM. Для индивидуальных решений и проектов внедрения идеально подходят итеративные и спиральные модели разработки.
Эти же модели, скорее всего, выберут стартапы, крупные сайты и порталы, социальные сети, то есть масштабные проекты, которые, однако, не тиражируются и не кастомизируются.
Могу привести пример разработки нашей системы.
Рули24 .
Для разработки версионных пакетных решений наша команда использует каскадную модель, а для проектов внедрения и кастомных релизов — итеративную и спиральную модели.
Что касается методологий, то мы еще не выбрали окончательный вариант, но построили систему управления разработкой, близкую по духу к agile, на базе Ruli24. Более того, именно работа над проблемой управления разработкой подтолкнула нас к созданию модуля управления процессами.
Как это произошло?
Очевидно, что весь цикл разработки укладывается в набор процессов:- Процесс исследования, в ходе которого собираются требования и составляются технические спецификации.
- Процесс создания проекта, результатом которого является создание сначала прототипа, а затем законченного работающего программного обеспечения, готового к внедрению на стороне клиента.
Этот процесс также включает проверку программного обеспечения.
- Процесс сопровождения проекта.
Это не что иное, как сервисная поддержка HelpDesk, обрабатывающая обращения пользователей согласно установленному регламенту уровня обслуживания.
Запросы необходимо сортировать, накапливать, обрабатывать и на их основе формировать базу знаний.
- Проведение форумов и встреч, связанных как с разработкой новых продуктов, исследованиями, так и с тем, что происходит внутри компании относительно текущей деятельности.
- Разработка новых версий программного обеспечения — стандартный бизнес-процесс компании-разработчика; он включает в себя обычные этапы: создание проекта версии, тестирование версии, сдачу версии заказчику.
Пока речь идет о 10 клиентах и 5 проектах, все проблемы решаются устно и путем записи на доске.
Однако по мере роста проектов необходима автоматизация, причем таким образом, чтобы все уровни процессов и управления проектами были связаны между собой.
В своей работе мы использовали разные системы управления, но ни одно решение не позволяло связать воедино все процессы, которые работают внутри компании.
Мне приходилось работать над несколькими системами одновременно.
Так пришло понимание, что необходимо создавать свой продукт — «Рули24. Управление процессами» .
Данное решение объединяет все нерегулируемые процессы, связанные с деятельностью компаний.
И с помощью этого продукта вы сможете управлять как бизнес-процессами, так и проектами, управлять обслуживанием клиентов и взаимоотношениями с клиентами и документооборотом.
Как любой разработчик коммерческого ПО, мы отдали предпочтение нашему продукту, чтобы попутно протестировать его.
Несколько внедрений в ИТ-компаниях доказали правильность нашего решения.
Ну и пять секунд хвастовства — бизнес-сообщество оценило наше решение и команда получила награду SOFTTOOL как «Продукт года».
Итак, модель выбрана, теперь нужна методология.
Давайте поговорим о них.
Умная методология
В последнее время невероятную популярность приобрела гибкая методология управления разработкой, так называемая agile-методология.Давайте рассмотрим его подробнее и выясним, всем ли он подходит. Слово agile, пришедшее в английский язык из французского, означает «ловкий, ловкий».
Пожалуй, никакое слово не описывает эту методологию лучше.
Как я уже упоминал, Agile не включает в себя жесткие правила или практики, а определяет ценности, которыми руководствуются команды, использующие эту методологию.
На первый взгляд основные идеи гибкой методологии выглядят не совсем реалистично:
- люди и взаимодействие важнее процессов и инструментов — похоже, такой подход приведет к разобщенности команды и нежеланию нести ответственность за результаты работы;
- работающий продукт важнее исчерпывающей документации – сложно представить сложную информационную систему, производственное программное обеспечение или, например, текстовый редактор без подробной сопроводительной документации;
- сотрудничество с заказчиком важнее согласования условий договора – для российских реалий этот пункт выглядит просто пугающе: каждый разработчик боится постоянного изменения требований со стороны заказчика;
- готовность меняться важнее, чем следование первоначальному плану — согласитесь, без дорожной карты развиваться сложно.
Эта методология на самом деле значительно упрощает разработку продукта.
Уверен, что не в последнюю очередь это связано со специфическим подходом к формированию команды разработчиков и управлению этой командой: помимо архитектора, программистов и дизайнера в команду обязательно входят представители заказчика (его сотрудники или его руководитель проекта).
Вот причины и ожидания перехода к Agile, перечисленные респондентами опроса Techbeacon: Расширение сотрудничества между командами, которые обычно не работают вместе — 54% Повышение уровня качества программного обеспечения - 52% Увеличение удовлетворенности клиентов - 49% Сокращение времени вывода продукта на рынок – 43% Снижение стоимости разработки - 42% В целом у Agile есть множество преимуществ, благодаря которым он смог завоевать любовь не только менеджеров, но и самих разработчиков.
- Agile-подход позволяет иметь всегда актуальный продукт, отвечающий требованиям клиентов, поскольку методология предполагает принцип реагирования на меняющиеся требования клиентов.
С одной стороны, продукт актуален, с другой — клиент всегда получает именно то, что хочет, а значит, у него меньше стимулов обращаться к команде конкурента.
- Частая поставка программного обеспечения посредством коротких спринтов дает команде возможность быстро разобраться с бэклогом проектов и реализовать наиболее приоритетные задачи.
- Тесное взаимодействие с заказчиком на всех этапах проекта помогает правильно интерпретировать техническое задание и в сочетании с короткими спринтами дает возможность отклониться от требований и создать функционал, не востребованный клиентом.
- Внимание к используемым технологиям и удобству использования существенно влияет на качество разрабатываемого продукта.
Проект постоянно адаптируется к новым тенденциям и запросам пользователей.
- Самоорганизация команд и личное общение хорошо влияют на продуктивность каждого члена команды.
Как показало исследование, Agile не приживается лишь у 15% команд, выбравших его.
С точки зрения бизнеса Agile также выгоден во всех отношениях.
- Это позволяет ускорить выход на рынок и постоянно удовлетворять потребности рынка.
- Продукт, созданный по гибкой методологии, создает у пользователей впечатление чрезвычайно лояльного.
например, вы можете собирать отзывы пользователей и использовать их в спринте, постоянно сообщая об изменениях.
Готовность к переменам существенно повышает доверие к проекту.
- Agile помогает согласовать ИТ (разработку и обслуживание) с бизнес-целями.
- Несмотря на кажущуюся демократичность, методология повышает общую производительность компании.
Конечно, есть и негативный опыт использования agile. Это может произойти в трех основных случаях.
- Заказчик заходит слишком далеко, меняет требования без уважительной причины, и команда превращается в машину для непрерывного, экстренного рефакторинга.
Менеджер всего проекта (скрам-мастер) обязан общаться с клиентской стороной и объяснять, что требования должны быть разумными и соответствовать целям бизнеса.
Чехарда в развитии и постоянные изменения направлений развития продуктов не приводят к хорошему.
- Команда не может самоорганизоваться и превращает agile в расхлябанность и пустую болтовню на собраниях.
Ведь до 30% времени спринта тратится на встречи и встречи (4-8 часовая встреча перед спринтом, не более 15 минут после и каждый день).
Необходимо донести до команды, что эти встречи — важная часть работы над проектом и их задача — не обмен сплетнями и шутками, а собранное обсуждение проблем, задач и времени проекта.
Ведь на карту поставлены удовлетворенность клиентов, доходы компании и личный доход каждого сотрудника.
- Снижение качества продукта из-за небрежного отношения к технологиям разработки и особенностям ИТ-инфраструктуры.
Действительно, бывает, что команда, увлекшись юзабилити или дизайном, совершенно забывает о производительности, рефакторинге и тестировании на разных сборках.
Именно здесь на помощь приходит управление производительностью, которое также должно стать бизнес-процессом.
Об этом я расскажу чуть ниже.
Scrum — толпа разработчиков
Scrum — это методология управления проектами, используемая в Agile. Scrum предназначен для контроля качества процесса разработки, а также представляет собой подход к управлению разработкой и сопровождением проекта.Скрам предполагает короткие итерации в спринтах по 15-30 дней, в ходе которых команда максимально сосредоточена на разработке и по итогам которых пользователь получает работающее программное обеспечение с новыми функциями, выбранными из бэклога проекта в качестве приоритетов.
Задачи по разработке функционала не могут меняться на протяжении спринта, а время строго фиксировано и его сдвиг — сигнал о том, что команда не учитывает некоторые факторы при планировании.
Чем короче спринт в Scrum, тем гибче разработка — выбирая задачи из бэклога, разработчики знают, что движутся в правильном направлении и создают именно то программное обеспечение, которое нужно заказчику.
Основным источником информации о необходимых улучшениях и новом функционале в Scrum является бэклог проекта, где все члены команды могут собирать любые требования.
Этот список упорядочен по важности каждого изменения.
Исходя из времени спринта и опыта команды, в бэклог спринта попадают задачи с наивысшим приоритетом — то, что будет реализовано в следующий период разработки и разделено на задачи для членов команды.
В Scrum-команду входят архитектор, дизайнер, программисты, тестировщики и представитель заказчика.
Перед спринтом проводится 2-8-часовое совещание по планированию спринта, в ходе которого мотивированно выбираются задачи из бэклога проекта и задается продолжительность спринта.
В конце спринта также состоится большое последующее совещание.
Ежедневно проводятся небольшие встречи продолжительностью до 15 минут для оценки текущего положения дел и необходимости корректировки действий.
Все это время строится диаграмма сгорания задач — график, на котором отмечается объем проделанной и оставшейся работы.
Чаще всего Scrum-команда ведет доски с стикерами, на которых они перемещают задачи между этапами.
Несмотря на кажущийся хаос, scrum — это высокодисциплинированный подход к управлению разработкой, обеспечивающий прозрачность всех задач для всей команды и ориентированный на результат.
Lean/Canban — Scrum, дошедший до дзена
Одним из вариантов Scrum является методология бережливой разработки (lean) и Kanban. В разработку они пришли из японского автопрома, а именно из концерна Toyota, который широко известен своим подходом к бережливому производству и успешно использует карточную систему Канбан для сборки автомобилей без затоваривания склада и перегрузки цеха.Канбан, как и Скрам, — это не бизнес-процесс, не действие, а система ценностей разработчиков, методология.
В процессе Канбан команда работает над задачей от начала до конца; сроки выполнения задания отсутствуют. В этой методике важно уметь правильно расставлять приоритеты задач.
В отличие от Scrum, Kanban исключает необходимость ожидания решений или разработки ненужной функциональности.
Короткие циклы разработки, раннее тестирование, равномерное распределение нагрузки в команде и система визуальной разработки обеспечивают прозрачность работы и полную стабильность команды.
Сегодня эту методологию выбирают крупные девелоперские компании и даже некоторые банки.
Подходит ли вам Agile?
Agile сам по себе является достаточно продуманной методологией, но ее не следует воспринимать как единственную истину.Прежде чем обращаться к той или иной методологии, как и в случае с моделями, важно определить, какой подход к реорганизации будет наиболее эффективен для вашей компании.
Возможно, стоит развиваться по строгим ГОСТам времен СССР с тщательной подготовкой ТЗ и созданием технического проекта, а может, пора купить доску, наклейки и познакомить команду с Канбан.
Agile удобно использовать, если вы:
- Требования к проекту четко не определены или постоянно меняются по запросу клиента или в результате конкурентной разведки.
- Характеристики будущего продукта подвержены большой волатильности.
- Нет времени на подготовку официальной проектной документации; вам придется работать на лету.
- Подрядчик и заказчик имеют повышенную толерантность к риску.
- У вас есть возможность создать сплоченную и эффективную команду для управления разработкой.
- Ваш продукт можно легко разбить на модули, с которыми могут работать гибкие команды.
В целом можно применять разные методологии и комбинировать их в одной компании: например, разрабатывать по водопадной модели и стандартам ГОСТ, а для внедрения создавать scrum-команды.
Главное, что подобные комбинации направлены на максимальную эффективность работы, скорость реализации проекта и высокое качество разработки.
Но все же главное, чем следует руководствоваться при выборе методики, – это накопленный опыт и здравый смысл.
Режим здесь не лучший советчик.
Обещанный моральный урок о продуктивности
В основе управления жизненным циклом разработки большинства программ лежит системная инженерия или проектирование производительности, обеспечивающее подход и инструменты для создания жизнеспособного программного обеспечения.Какая бы методология разработки программного обеспечения ни была выбрана, по крайней мере на одном из этапов используется проектирование производительности (PE).
Вот как разные эксперты оценивают важность проектирования производительности применительно к определенным аспектам и методологиям разработки: 
PE нацелен на нефункциональные требования (насколько производительным должно быть программное обеспечение, т.е.
насколько быстро оно должно работать в определенных условиях).
На этапе разработки PE стремится создать код, обеспечивающий лучшую производительность.
В ходе тестирования PE устанавливает системные требования и изучает производительность на различных конфигурациях (нагрузка, тип операционной системы, взаимодействие с различными типами устройств и т. д.), лучшие из которых будут использоваться в производстве.
После внедрения программного обеспечения проектирование производительности отвечает за три основные области:
- управление уровнем обслуживания (SLA) – установление соответствия программного обеспечения требованиям, мониторинг и анализ работы систем;
- управление инцидентами и проблемами — решение проблем с производительностью, реконфигурация устройств, изменение конфигурации устройств, рефакторинг кода для повышения производительности;
- управление мощностью — постоянный мониторинг для установления соответствия программного обеспечения нефункциональным требованиям с течением времени.
Например, если в ходе анализа выяснится, что производительность системы упала из-за увеличения количества пользователей или транзакций, принимается решение об изменении конфигурации оборудования или программного обеспечения, чтобы вернуться к стандартным показателям производительности.
Современные возможности создания графических интерфейсов, использования баз данных со сложной архитектурой и работы с облачными технологиями создают проблему производительности, на которую PE должен реагировать, причем на всех этапах жизненного цикла продукта.
Возьмем, например, наша система Рули24 .
В конфигурациях для среднего и крупного бизнеса (например, банков, промышленных предприятий, связи) это достаточно сложное программное обеспечение.
Кроме того, наша система работает на СУБД Oracle, которая является мощной, но общеизвестно медленной.
Мы тщательно работаем над производительностью и архитектурой нашего ПО, стремясь обеспечить минимальное время отклика для текущей конфигурации.
Нам это удается.
И дело вовсе не в Oracle, а в умении управлять архитектурой и постоянном рефакторинге кода.
И еще несколько методик
За рамками нашего краткого обзора выходят несколько методологий разработки, которые, несмотря на свою специфику, продолжают успешно использоваться в компаниях-разработчиках.Давайте пройдемся по основным из них.
- TDD (разработка через тестирование) — очень короткие циклы разработки, при которых сначала пишется тест, охватывающий функционал, а затем пишется код, который проходит этот тест и по результатам этих двух операций проводится рефакторинг.
Это достаточно спорная методология, поскольку, с одной стороны, она направлена на уменьшение ошибок программы и позволяет создавать более удобные интерфейсы (программист просто вынужден думать как пользователь), но с другой стороны, это очень трудоемко, требует времени на написание тестов и приводит к увеличению накладных расходов на поддержку программного обеспечения.
TDD — одна из крайних методик программирования, однако, в отличие от ряда других методик, она не подходит для разработки корпоративных информационных систем.
- DSDM (Метод разработки динамических систем) , Dynamic Systems Development Method) — методология разработки программного обеспечения, основанная на RAD (Rapid Application Development) и направленная на соблюдение бюджета и сроков проекта.
Эта модель популярна благодаря своим преимуществам, в частности гибкости, демократичности, значительному взаимодействию внутри команды и с будущим пользователем, возможности итеративного подхода и разделения компонентов на ключевые и второстепенные.
- RUP (рациональный унифицированный процесс) — еще одна итеративная методология разработки, при которой работа над проектом строится из нескольких итераций по 2-6 недель, на выходе каждой из которых должен быть промежуточный работоспособный продукт. Проект разделен на четыре этапа: начальный с формированием видения проекта, оценкой рисков, разработкой требований и экономического обоснования; уточнение документации требований и проектирования архитектуры; этап строительства, включая разработку перед выпуском; завершающий этап внедрения, обучение и поддержка.
- RAD (быстрая разработка приложений, быстрая разработка приложений) — методология, направленная на быструю и удобную разработку программного обеспечения.
По этой методологии проект разрабатывается за 3-5 месяцев небольшой командой разработчиков, а заказчик вовлекается в процесс еще до начала разработки и участвует на всех этапах.
Акцент в методологии делается на оперативные изменения по требованию заказчика по функциональным и нефункциональным требованиям.
Методика широко используется во всех областях разработки, но не оправдана при наличии четких требований и строго определенного функционала.
Технология RAD удобна для разработки (и модификации) корпоративного ПО, поскольку это тот случай, когда сроки сжаты, а требования к функциональности, графическому интерфейсу и производительности могут меняться в процессе разработки.
- Разработка программного обеспечения для чистых помещений (методология чистых помещений) — интересная методология разработки ПО с сертифицированным уровнем надежности.
Направлен на предотвращение сбоев, ошибок и проблем с производительностью в процессе создания, а не на устранение проблем после создания программного обеспечения.
Жесткая методология, не нашедшая широкого применения в коммерческой сфере.
- MSF (Microsoft Solutions Framework) — методология, разработанная на основе практического опыта Microsoft. Скорее, это даже целая система управления проектами разработки, состоящая из множества моделей и правил.
Он сочетает в себе каскадную и спиральную модели развития и является универсальным, поскольку не включает жестких процедур.
MSF ориентирована на этапы, учитывает изменения требований к проектированию и основана на коротких итеративных циклах всей системы разработки: проектирования, кода, документации.
Методология охватывает все этапы разработки продукта, включая внедрение, в результате которого создается ценность бизнеса.
MSF во многих крупных компаниях как для внешней (заказной) разработки, так и для разработки по ТЗ внутренних заказчиков.
Работая с методологией, компания получает ряд преимуществ: организованную работу, команду, разделяющую ценности, а также опыт лучших практик тех, кто уже внедрил ту или иную методологию.
По сути, каждая девелоперская компания уже придерживается определенной моды.
Теги: #agile #scrum #lean #canban #Управление разработкой #команда разработки #цикл разработки #методология разработки #модели разработки #ERP-системы #CRM-системы #Управление разработкой
-
Восстановление Данных Стало Проще
19 Oct, 24 -
Неклассифицированный
19 Oct, 24 -
Какая У Вас Операционная Система? Опрос
19 Oct, 24 -
Почему Ты Спрашиваешь, Где Я Живу?!
19 Oct, 24 -
С Новым Годом, Дорогие Дамы!
19 Oct, 24 -
Еще Одна Логическая Задачка
19 Oct, 24
