2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Управление разработкой ПО – Agile Development

Управление разработкой ПО – Agile Development

ServiceNow Agile Development (SDLC ) позволяет управлять методами гибкой разработки Scrum , при разработке программного обеспечения и его сопровождения на протяжении всего жизненного цикла – от создания, тестирования до внедрения.

Многие компании имеют различные приложения для управления разработкой ПО, но зачастую иметь набор инструментов под каждую задачу не имеет смысла, так как платформа ServiceNow включает в себя приложения для гибкой разработки Agile Development. К тому же ServiceNow Agile Development легко интегрировать с порталом услуг, сервисом управления инцидентами и другими приложениями ServiceNow.

ServiceNow Agile Development

Зачастую компании, особенно молодые стартапы, начинают внедрение гибкой разработки ПО с доски и стикеров, покупка и внедрение сложных программных продуктов нерентабельны и нецелесообразны.

Приложение Agile Development является составляющей SaaS -платформы ServiceNow, не требует установки, так как работает из облака, и легко настраивается для быстрого старта. Приложение представляет собой цикличный и последовательный процесс для среды разработки программного обеспечения, обеспечивает работу Scrum – одной из наиболее популярных методик.

Основные характеристики Scrum:

  • Короткие и жестко фиксированные по времени итерации, называемые спринтами (sprints), позволяющие гибко реагировать на изменяющиеся потребности в процессе развития.
  • Повторяющаяся последовательность событий, этапов и совещаний.
  • Практика внедрения и тестирования новых требований, называемая историями (stories), дающая гарантию выпуска готовых релизов после каждого спринта.
  • Основные роли методологии: владелец продукта (product owner), скрам-мастер (scrum master) и члены команды (team members).

Как активировать ServiceNow Agile Development

Список плагинов, необходимых для работы Agile Development на платформе ServiceNow:

Agile Development – основное приложение.

Context Ranking – необходим для работы Agile Development.

NG shared components – необходим для работы Agile Development.

Custom Charts – необходим для работы Agile Development.

Model Management – необходим для работы Agile Development.

SDLC – SCRUM – необходим для работы Agile Development.

Software Development Lifecycle SDLC – обычно предустановлен, необходим для работы Agile Development.

Project Portfolio Suite (опционально) – для использования панели управления проектом.

Demand Management (опционально) – используется по требованию.

Вам необходимо активировать плагин Agile Development, чтобы начать использовать приложение.

Вы можете использовать приложение на свое усмотрение, оно открытое, и вы можете вести разработку ПО, используя методологию waterfall или agile, или применять гибридный метод agile/waterfall, как делают многие другие компании. Независимо от того, какой метод вы выберете, приложение Agile Development будет удобной отправной точкой реализации гибкой (Agile) методологии разработки вашего ПО.

Рассмотрим реализацию стандартной терминологии Agile на платформе ServiceNow.

Основа SCRUM

Ежедневные совещания (Daily Scrum)

Скрам-мастер организует короткие встречи с членами команды каждый день, чтобы обсудить прогресс выполнения, текущие работы, запланированные работы, препятствия, мешающие выполнению работы (blockers).

Blocked Story

Scrum Release

Бэклог продукта (Product backlog)

Владелец продукта создает и ведет Product Backlog, который представляет собой список пользовательских историй, упорядоченных по степени важности, предъявляемой к разрабатываемому продукту, может включать в себя themes, epics и stories. Product Backlog постоянно пересматривается и дополняется, так как в процессе разработки появляются новые требования и удаляются ненужные, а также происходит пересмотр приоритетов. Для точной расстановки приоритетов и времени выполнения историй владелец продукта работает с членами команд.

Product Backlog

Бэклог релизов (Release Backlog)

Release Backlog содержит список историй, выполнение которых необходимо для выпуска текущего релиза. Владелец продукта совместно со скрам-мастером отвечают за определение этих историй, они могут относиться к одному или нескольким продуктам. Как правило, процесс принятия решений основан на шкале времени выпуска релизов, степени важности историй в Product Backlog и их сложности. Могут существовать и другие критерии помещения историй в Release Backlog, это зависит от характера самого продукта. Истории, находящиеся в Release Backlog, ориентированы на выпуск релиза, но не ассоциированы с каким-либо спринтом, это происходит динамично в процессе подготовки.

Stories By Release

Бэклог спринта (Sprint Backlog)

В списке Sprint Backlog содержатся истории, которые члены команды договорились выполнить в течение спринта. При планировании спринта скрам-мастер после совещания с членами команды решает, какие еще истории они могут завершить в этом спринте. Как правило, это истории с самым высоким приоритетом. Команда сама определяет, какие скрам-задачи необходимо решить для каждой истории, в то время как владелец продукта консультирует их по всем вопросам.


Sprint Pla
nning Board

Спринты (Sprints)

Члены команды работают над завершением историй в текущем Sprint Backlog. Прогресс выполнения отслеживается во время проведения ежедневных совещаний, на которых члены команды обсуждают завершенные накануне истории, планируют работу на следующий день, решают вопросы о blockers. Скрам-мастер сосредотачивает внимание членов команды на завершении историй в текущем спринте, а также старается устранить все препятствия, с которыми они столкнулись. В конце спринта все истории должны быть выполнены. Любые невыполненные истории помещаются в соответствующий бэклог. Итоговая встреча после завершения спринта позволяет членам команды обсудить, как протекала работа, какие проблемы возникали и как можно улучшить выполнение будущих спринтов.

Burndown Chart

Обзор спринта и ретроспективы (Sprint Review and Retrospectives)

В конце спринта скрам-мастер и члены команды обсуждают завершенную работу, демонстрируют новые возможности и представляют их владельцу продукта. Обсуждение проделанной работы – важная составляющая скрам-разработки, позволяющая выявить проблемы и не допустить их в будущем, улучшив выполнение других спринтов.

Sprint Retrospective

Планирование спринта (Sprint Planning)

Следующий спринт начинается с переноса историй из release backlog в sprint backlog. Скрам-мастер и члены команды выбирают те истории, которые они могут завершить в течение спринта.

Улучшения и недостатки (Enhancements and Defects)

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

Enhancement


Если вы хотите узнать подробнее о работе с приложением Agile Development, рекомендуем зайти в официальный раздел документации портала ServiceNow или обратиться к специалистам компании «ИТ Гильдия» – официального сертифицированного партнера ServiceNow.

Подписывайтесь на блог компании «ИТ Гильдия» – официального сертифицированного партнера ServiceNow, чтобы следить за новыми статьями, которые позволят вам достигнуть успеха, внедряя платформу.

Оставайтесь в курсе событий

Подписывайтесь на рассылку новых материалов блога по почте

Читайте также

» d=»M16 10L0 20V0z» fill=»#abc0e1″/> «> » width=»16″ height=»20″>

» d=»M16 10L0 20V0z» fill=»#abc0e1″/>

» d=»M7 4.5L0 9V0z» fill=»#158dee»/>

» d=»M7 4.5L0 9V0z» fill=»#158dee»/>

» d=»M7 4.5L0 9V0z» fill=»#158dee»/>

» d=»M7 4.5L0 9V0z» fill=»#158dee»/>

» d=»M7 4.5L0 9V0z» fill=»#158dee»/>

» d=»M7 4.5L0 9V0z» fill=»#158dee»/>

© 2013-2019 «ИТ Гильдия».
Все права защищены.

115280, Москва, Ленинская Слобода, 26, строение 5, офис 5519, БЦ «Симонов Плаза».

191028, Санкт-Петербург, Литейный проспект, 26 , офис 523, БЦ «Преображенский двор».

Scrum за пять минут

Agile и Scrum в проектном управлении

Чтобы лучше понимать, что такое Scrum, как методология управления проектами, нужно начать с Agile.

Agile (с англ. «гибкий», «подвижный», «быстрый») — это система ценностей. «Внедрить» Agile нельзя, ведь ценности можно лишь предложить людям, максимум — привить их. Придерживаясь каких-то убеждений, разделяя некие принципы, можно проецировать их на любые свои действия (и на любой вид коллективной деятельности). На основе Agile развивается целый комплекс подходов, но самая распространенная практика в управлении проектами — Scrum (Скрам).

Четыре ценности и 12 принципов Agile подробно описаны в Agile-манифесте, а узнать больше об Agile можно из предыдущей статьи в блоге «Апланы» — «Agile и управление проектами».

Scrum — это фреймворк или «каркас», один из Agile-процессов, практическое воплощение его ценностей, предназначенное для разработки, поставки и поддержки сложных продуктов.

Чтобы объяснить суть подхода, создатели Scrum (и одни из создателей Agile) Кен Швабер и Джефф Сазерленд разработали «Исчерпывающее руководство по Скраму», в котором описали основные «правила игры», а затем дополняли его на протяжении более двадцати лет. Конечно, Scrum не стоит на месте, а продолжает развиваться. Но в чем же его суть? В чем причина его успеха?!

Читать еще:  ТОП-5 главных рисков кибербезопасности в 2020 году

Scrum: теория и ценности

В современном мире, особенно в высококонкурентной сфере IT, скорость выпуска продукта стоит в приоритете. При этом качество не должно страдать. Scrum позволяет выпускать функциональный продукт снова и снова, через определенные временные отрезки (от двух недель до месяца), называемые спринтами. Спринт — это ядро Scrum, его главная составляющая, проект в миниатюре. Новый спринт начинается сразу после окончания предыдущего. По результатам каждого из них принимается решение: выпускать этот реально работающий программный продукт как есть, либо продолжить улучшение на следующем этапе.

Scrum использует итеративный (регулярный повтор полного цикла работы над продуктом с непрерывным анализом результатов предыдущего этапа, корректировкой требований и процесса) и инкрементальный подходы (приращение результатов предыдущего этапа), чтобы управлять рисками и улучшать прогнозируемость.

Благодаря итерационной разработке, продукт можно выпускать быстро, с высокой периодичностью, а его качество можно постоянно улучшать, внося определенные доработки и корректировки. Таким образом, работоспособная и потенциально полезная версия продукта доступна в любой момент.

Scrum компактный, простой для понимания, но трудный для совершенного овладения. Он основан на теории эмпирического управления, согласно которой источником знаний является не что иное, как опыт, а источником решений — реальные данные. Процесс эмпирического управления основан на «трех китах»: прозрачности, инспекции и адаптации.

Команда в Scrum опирается на несколько ценностей: преданность, смелость, сфокусированность, открытость и уважение.

Суть Scrum — в маленькой команде людей

Разделяя ценности, каждый участник Scrum-команды должен уважать других, быть открытым с коллегами, смел, сфокусирован на результате и предан делу. Все должны знать, что происходит в проекте, с тем чтобы помочь команде добиваться нужных результатов. В любой момент каждый может высказать свое мнение по открытым вопросам или вызваться помочь отстающему коллеге.

Scrum-команды самоорганизующиеся и кросс-функциональные. В традиционной компании программисты сидят с программистами, бухгалтеры — с бухгалтерами. В Scrum наоборот — в одной команде находятся специалисты из разных областей: разработчики, тестировщики, дизайнеры, представители бизнеса и т. д. Все несут одинаковую ответственность за продукт.

По словам создателей фреймворка, суть Scrum — в маленькой команде людей. Они поясняют это так: «Каждая отдельная команда чрезвычайно гибка и адаптивна. Эти преимущества проявляются, распространяясь на любое количество команд в организации: одну, несколько или целые сети команд, которые разрабатывают, выпускают, осуществляют эксплуатацию и поддержку продуктов, таким образом объединяя труд тысяч людей».

Обычно Scrum-команда состоит из пяти-девяти человек (не считая скрам-мастера и владельца продукта и при условии, что они не участвуют в разработке). Важно, чтобы команда оставалась гибкой и ей хватало навыков для выполнения значимой работы.

Джефф Безос — основатель компаний Amazon и Blue Origin, владелец The Washington Post и богатейший человек в мире (Forbes, 2018) — приверженец Scrum. Он сформулировал простое и очень наглядное правило: команда должна быть достаточно маленькой, чтобы ее можно было накормить двумя пиццами. «Правило двух пицц», внедренное в Amazon, идеально соотносится с философией Scrum — именно таким количеством можно накормить от четырех до восьми человек.

В Scrum сотрудники не руководят друг другом, а работают сообща. Роли и состав команды на протяжении спринта не меняются.

Роли в Скраме

В традиционном варианте Scrum можно выделить три роли: владелец продукта, скрам-мастер и команда разработки. Однако, многие идут дальше. Так появляются дополнительные роли: заказчик, бизнес-аналитик и другие.

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

Владелец продукта — это человек-промежуточное звено между заказчиком и командой разработки (может быть на той и на другой стороне). Он несет ответственность за достижение максимальной ценности продукта.

События Скрама

Scrum предполагает четыре вида формальных событий, направленных на инспекцию и адаптацию: стендап (ежедневное собрание во время спринта), планирование спринта, обзор спринта и его ретроспектива. О прозрачности и открытости тоже никто не забывает. Например, стендапы Microsoft, на которых разработчики за чашкой чая обсуждают планы на ближайшие сутки, легко найти в сети.

Scrum-мероприятия со стороны могут выглядеть как «легализация бардака», потому как команды сами определяют формат встречи. Самое главное — достигнуть поставленных целей. На стендапе участники, как правило, стоя планируют работу на ближайший день, обговаривая что было выполнено накануне, и с какими трудностями столкнулся каждый член команды. Такая встреча длится не дольше 15 минут, поэтому, чтобы не терять время, участники могут здесь же пить кофе и перекусывать.

Создатели данного метода считают, что благодаря такому подходу, такой свободе, можно быстро решать проблемы различной сложности и креативно подходить к созданию программного или любого другого продукта.

Методы

Методология Agile довольно широка, но самые популярные методы — Kanban и Scrum.

Kanban

Визуальный подход к управлению проектами, когда команды создают физические представления своих задач, часто используя заметки на досках (или через онлайн-приложения). Задачи проходят через заранее определенные этапы, чтобы отслеживать прогресс и выявлять общие препятствия.

Scrum

Метод, в котором небольшую команду возглавляет Scrum Master, основной задачей которого является устранение всех препятствий для успешного завершения работы. Работа выполняется короткими циклами, называемыми спринтами, команда ежедневно собирается для обсуждения текущих задач и проблем, которые необходимо устранить.

Adaptive Project Framework – это адаптивная структура проекта. Такой метод управления проектами вырос из идеи, что большинством IT-проектов нельзя управлять с помощью традиционных методов. Работа выполняется поэтапно и оценивается после каждого этапа.

Extreme Project Management – это экстремальное управление проектами. Метод, в котором вы можете изменить план проекта, бюджет и даже конечный результат в соответствии с меняющимися потребностями, независимо от того, как далеко продвинется проект.

Как использовать Agile-методологию управления проектом для совместной работы

Есть множество способов внедрить Agile-методологию управления проектом, и подход к сотрудничеству в вашей команде будет зависеть от того, какую именно методологию вы выберете.

Например скрам — это структура выполнения задач, при которой формируются маленькие команды под руководством скрам-мастера, главная задача которого — устранение препятствий и предоставление участникам команды всего необходимого для выполнения работы. Скрам основан на проведении коротких итерационных рабочих циклов, которые называются спринтами. Каждый спринт включает в себя планирование, демонстрацию и ретроспективу, а также ежедневное совещание, на котором скрам-мастер и участники его команды разбирают выполненную часть работы, удачные методы и проблемы, требующие немедленного рассмотрения.

Еще одна популярная Agile-методология называется канбан. Канбан использует наглядный подход к управлению проектами, когда участники команды создают визуальные отображения выполняемых задач, используя для этого онлайн-приложения или стикеры на доске. По мере выполнения проекта задачи перемещаются по заранее определенным этапам, что помогает следить за прогрессом и выявлять препятствия. Поскольку весь ход работы представлен в наглядном виде, участники команды точно знают, на какой стадии выполнения находится проект, и могут быстро переходить от одной задачи к другой.

Конечно, основные методы сплочения команды не зависят от того, какую именно Agile-методологию вы выбрали. Вот несколько рекомендаций по укреплению сотрудничества:

  • Уделите время мероприятиям по сплочению команды и знакомству коллег друг с другом. Если участники проектной группы смогут наладить доверительные отношения, им будет проще общаться и обмениваться информацией.
  • Запрашивайте отзывы от всех участников. Некоторые из сотрудников наверняка окажутся интровертами и не будут проявлять себя на совещаниях, но это вовсе не значит, что у них не могут возникать хорошие идеи. Постарайтесь выяснить их любимые способы взаимодействия и позаботьтесь о том, чтобы их мнения тоже были услышаны.
  • Используйте подходящие инструменты для обмена данными и сотрудничества. Программное обеспечение, разработанное для удовлетворения потребностей Agile-команд, поможет вам получить максимальные преимущества от управления проектом с помощью Agile-методологии.

Описание технологии Agile/Scrum

Agile – это гибкая методология разработки (англ. Agile software development). Представляет собой революционную концепцию, в рамках которой выполняется разработка программного обеспечения. В рамках данной концепции существует несколько методик.

Все эти методики ставят целью минимизацию рисков, достигается эта цель разработкой (проектированием) короткими итерациями.

Основополагающие ценности Agile содержатся в “Манифесте Agile”:

Scrum – это конкретная технология (методы ведения проекта и роли участников процесса), реализующая принципы Agile.

Данная технология позволяет в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять заказчику работающее ПО с новыми возможностями, для которых определён наибольший приоритет.

Требования к результатам спринта определяются в начале спринта (планирование спринта) и не могут изменяться в процессе спринта. Небольшая длительность спринта придает процессу предсказуемость и гибкость.

Роли Scrum

  1. Scrum Master. Бизнес-аналитик, руководитель проекта. Проводит совещания, следит за соблюдением технологии Scrum, снимает противоречия и направляет команду. Основная обязанность – обеспечение выполнения технологии Scrum.
  2. Product Owner. Владелец проекта, функциональный заказчик. Представляет интересы заказчика (конечных пользователей).
  3. Development Team. Команда специалистов (разработчиков). Состоит из специалистов различного профиля- аналитиков, архитекторов, программистов, тестировщиков. Команда отвечает за результат как единое целое.
Читать еще:  Что нужно сделать для снижения стоимости облака AWS

Элементы Scrum

Sprints (Спринт)

Спринт – итерация в процессе, в ходе которой создается новый результат. Спринт жестко фиксирован во времени – от 1 до 4 недель. Чем короче спринт, тем гибче является процесс разработки, поскольку после каждого спринта требования к системе могут корректироваться на основании обратной связи от заказчика. Соответственно, снижаются риски работы в неправильном направлении. С другой стороны при более длительном спринте снижаются издержки на совещания, и больше остается времени на решение задач проекта.

Project backlog (журнал задач проекта)

Project backlog – журнал пожеланий проекта. Это список требований к системе, упорядоченный по приоритету – важности реализации. Журнал пожеланий могут дополнять все участники процесса.

Sprint backlog (журнал задач спринта)

Sprint backlog – журнал пожеланий спринта. Содержит функциональность, отобранную владельцем проекта (Product Owner) для реализации на текущем спринте.

Burndown chart ( Диаграмма сгорания задач )

Burndown chart – диаграмма сгорания задач. Демонстрирует объем сделанной и оставшейся работы относительно срока проекта. Диаграмма актуализируется ежедневно. Предусмотрены два вида диаграмм:

  • Диаграмма сгорания для спринта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать в текущем спринте.
  • Диаграмма сгорания для проекта — показывает, сколько уже задач сделано и сколько ещё остаётся сделать до завершения проекта.

Abnormal Termination ( Остановка спринта)

Abnormal Termination – остановка спринта. Спринт может быть остановлен раньше его планового срока окончания в исключительных ситуациях. Например, если задачи спринта не могут быть достигнуты или если они стали неактуальными. Решение об остановке принимается командой или Владельцем проекта. После остановки начинается новый спринт.

Sprint Planning Meeting ( Планирование спринта)

Sprint Planning Meeting – планирование спринта. Происходит в начале каждого спринта:

  • Из бэклога проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда в данном спринте.
  • На основе выбранных задач создается бэклог спринта. Каждая задача оценивается в ч/часах. Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи.
  • Обсуждается и определяется, каким образом будет реализован этот объём работ.
  • Продолжительность совещания ограничена сверху 4—8 часами в зависимости от продолжительности итерации, опыта команды и тому подобного. Совещание делится на 2 части:
    1. Участвует владелец проекта и скрам команда. Выбирают задачи из бэклога проекта.
    2. Участвует только команда: обсуждают технические детали реализации, наполняют Sprint Backlog (бэклог спринта).

Daily Scrum meeting ( Ежедневное совещание)

Daily Scrum meeting – ежедневное совещание команды. Правила проведения совещания:

  • проводится в одно и то же время, в одном и том же месте;
  • не более 15 минут;
  • каждому участнику надо ответить на 3 вопроса:
    • Что я сделал вчера
    • Что я планирую сделать сегодня
    • Что мне мешает

Scrum of Scrums ( Скрам над скрамом )

Scrum of Scrums – Скрам над скрамом – совещание нескольких Scrum-команд. Проводится после ежедневного скрам совещания. Позволяет нескольким скрам командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Повестка та же, что и на ежедневном скрам совещании плюс следующие вопросы:

  • Что каждая команда сделала с момента предыдущего ежедневного совещания?
  • Что каждая команда сделает к следующему ежедневному совещанию?
  • Есть ли проблемы, мешающие или замедляющие работу каждой команды?
  • Нужно ли другой команде сделать что-то из задач вашей команды?

Sprint review meeting (о бзор итогов спринта )

Sprint review meeting – о бзор итогов спринта. Проводится в конце спринта.

  • Команда демонстрирует результаты спринта всем заинтересованным лицам. Привлекается максимальное количество зрителей.
  • Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
  • Нельзя демонстрировать незавершенную функциональность.
  • Ограничена четырьмя часами в зависимости от продолжительности итерации и объема результата.

Retrospective meeting ( Ретроспективное совещание)

Retrospective meeting – р етроспективное совещание. Проводится в конце спринта. Обсуждение результатов спринта:

  • Члены команды высказывают своё мнение о прошедшем спринте.
  • Отвечают на два основных вопроса:
    • Что было сделано хорошо в прошедшем спринте?
    • Что надо улучшить в следующем?
  • Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).
  • Ограничена одним-тремя часами.

Чем Agile отличается от Scrum?

Если кратко, то Scrum – это одна из Agile-методик.

  • для продуктовых команд, которые хотят повысить скорость работы и увеличить бизнес-ценность создаваемого продукта;
  • для аутсорсинговых команд – если требование внедрения Agile/Scrum исходит от Заказчика, мы поможем понять как лучше отстроить процесс работы;
  • для организаций, которые хотят наладить взаимодействие между IT и бизнесом в рамках внутренних проектов автоматизации.

Burndown диаграмма в Jira

Цена и стоимость внедрения

Мы предлагаем типовое внедрение за 6 недель. Стоимость составит от 13 до 15 тысяч долларов. Стоимость типового внедрения зависит от сложности вашей организации и количестве человек, которые будут участвовать во внедрении. Также важную роль играет местонахождение вашего предприятия. Командировочные расходы оплачиваются дополнительно.

Краткий ликбез по Waterfall

Waterfall (каскадная) – это методология ведения проекта, когда фазы работ идут последовательно. Следующая фаза начинается только после завершения предыдущей. Наглядно это выглядит так:

Получается, план такой:

  1. Установили и прояснили требования заказчика и согласовали их с командой;
  2. Подготовили весь дизайн проекта;
  3. Разработали программное обеспечение целиком по заданным технологиям;
  4. Протестировали проект на наличие багов;
  5. И только после всех предыдущих, последовательных этапов — запустили в эксплуатацию.

В Waterfall можно управлять изменениями требований и рисками, но это скорее исключительные ситуации, которые требуют дополнительных затрат времени и бюджета.

Devprom ALM — управление процессом разработки ПО

  • Devprom ALM
  • Scrum Board
  • DevOps Board

Devprom ALM — система управления жизненным циклом программных продуктов и программно-аппаратных комплексов — основа эффективных процессов командной работы над проектами и продуктами. Обеспечивает поддержку всего жизненного цикла разработки программного обеспечения, полноценную трассировку всех проектных артефактов, от исходных требований до кода, тестов и работающего продукта.

Функциональные блоки:
  • Управление проектами и ресурсами на уровне компании (УП)
  • Разработка и управление требованиями (УТ)
  • Организация поддержки программных продуктов (ОП)
  • Управление разработкой и поставкой программного кода (Р)
  • Подготовка тестовой документации и управление тестированием (Т)
  • Разработка эксплуатационной документацией (Д)
  • Управление любыми активностями в стиле Agile и Lean, без использования каких-либо инструментов разработчиков http://scrumboard.ru
  • Запись результатов ретроспектив в базе знаний для улучшения работы команды.
  • Контроль трудозатрат и эффективное планирование работ в команде.

  • Управление потоком задач из поддержки, разработки и мониторинга на одной Kanban-доске — http://devopsboard.com
  • DevOps на практике, проактивное обнаружение ошибок и мониторинг поведения инфраструктуры и приложений.
  • Ручное и автоматизированное тестирование приложений.
  • Поддержка пользователей по Email и через сайт тех. поддержки.

Стоимость и лицензии

Название лицензииСтоимость, руб.
Базовая функциональность, необходимая для организации совместной работы предоставляется бесплатно и без ограничений: база знаний, доски пожеланий и задач, управление по Scrum и Kanban, учет затраченного времени и отчеты. Полноценная замена Jira+Confluence, Redmine, YouTrack, Mantis, Bugzillaбесплатно
Постоянная лицензия на модуль «Разработка и управление требованиями (УТ)» для 1 пользователя-редактора (например, системный аналитик). Все остальные пользователи могут смотреть материалы, оставлять комментарии, участвовать в процессе согласования, но не могут редактировать требования.16000
Постоянная лицензия на модуль «Подготовка тестовой документации и управление тестированием (Т)» для 1 пользователя-редактора (например, тестировщик или тест-дизайнер). Все остальные пользователи могут смотреть материалы, оставлять комментарии, участвовать в процессе согласования, но не могут заполнять тестовые отчеты и редактировать тестовую документацию.12000
Постоянная лицензия на модуль «Управление разработкой и поставкой программного кода (Р)» для 1 пользователя-редактора (например, программист). Остальные пользоваели могут просматривать коммиты, исходный код, но не могут настраивать подключения к системам контроля версий и участвовать в рецензировании кода.6000
Постоянная лицензия на модуль «Разработка эксплуатационной документацией (Д)» для 1 пользователя-редактора (например, технический писатель). Все остальные пользователи могут смотреть материалы, оставлять комментарии, участвовать в процессе согласования, но не могут изменять разделы документации.8000
Постоянная лицензия на модуль «Организация поддержки программных продуктов (ОП)», без ограничения по количеству пользователей60000
Постоянная лицензия на модуль «Управление проектами и ресурсами на уровне компании (УП)», без ограничения по количеству пользователей80000

Лицензионные условия выгодно отличают наш продукт от конкурентов, где приходится дорого оплачивать функциональность на всех пользователей, хотя им большая часть и не нужна.

Если у вас остались вопросы по стоимости решения, отправьте нам запрос стоимости решения вашей задачи. Пожалуйста, укажите в письме роли, количество сотрудников, задействованных в процессе разработки и кратко опишите вашу задачу.

Мы предлагаем использовать платформу Devprom ALM в учебном процессе совершенно бесплатно, подробнее.

В зависимости от предпочтения Заказчика возможны два варианта использования Devprom ALM:

  • На наших серверах по модели SaaS (приложение-как-услуга), подробнее.
  • На вашем сервере, под управлением Windows или Linux, подробнее.
  • В любой момент можно осуществить переход от одного варианта использования ПО к другому, без потери данных.

Используйте Devprom ALM бесплатно в течение 30 дней, чтобы лучше узнать возможности инструмента для решения ваших задач.

Конкурентные преимущества

Перед решениями, построенными на основе баг-трекера, плагинов и дополнительных приложений:

  • Единая точка входа ко всем проектам и проектным артефактам, полная прозрачность происходящего на уровне компании.
  • Все необходимые профессиональные инструменты, доступные даже небольшим командам.
  • Готовое решение и процессы для автоматизации и управления зрелым процессом разработки ПО.

Перед зарубежными аналогами:

  • Полноценная ALM по цене баг-трекера.
  • Русскоязычная поддержка и индивидуальные консультации.
  • Локализация современных практик и методологий под особенности производства ПО в РФ.
  • Оперативная и доступная доработка платформы под потребности вашей команды и используемых процессов.
  • Обмен опытом, полученном при работе с российскими компаниями разработчикам ПО.
  • Русскоязычный интерфейс системы, с возможностью переключения на англоязычный интерфейс.
  • Открытый код и низкая стоимость владения за счет использования «железа» уровня рабочей станции и свободно-распространяемого промежуточного ПО.

Наш продукт – первая российская система класса ALM (Application Lifecycle Management). Основные наши конкуренты – дорогие западные продукты, выстроенные под западные процессы и аудиторию:

  • Atlassian ALM — семейство продуктов компании Atlassian и дополнительного набора плагинов третьесторонних разработчиков. При внедрении и эксплуатации требует вовлечения системного интегратора. Стоимость решения зависит от числа пользователей экспоненциально, вне зависимости от того, какими компонентами или плагинами пользуется конкретный пользователь. Импортозаместим JIRA и Слабые стороны Wiki и Confluence для управления требованиями
  • Polarion ALM, HP ALM, HP QC — лидеры отрасли на зарубежных рынках, не локализованы на русский язык, не адаптированы под российскую практику разработки ПО. Стоимость лицензий превышает Devprom ALM на порядок. Сравнение систем управления требованиями и Лучше чем Microsoft TFS
  • Microsoft TFS, VersionOne, TargetProcess — инструменты для управления проектами (PPM), с развитыми возможностями для управления тестированием (TMS), не содержат функциональности для эффективной работы с бизнес- и системными требованиями, записанными в форматах ТЗ, UseCases и других стандартов отрасли. Не предоставляют возможностей по разработке и управлению изменениями в технической документации, организации поддержки пользователей. Лучше чем Microsoft TFS
  • Есть и другие продукты, например, IBM Rational (Jazz). Они крайне дороги, требуют длительного, сложного и дорогого внедрения.

ПопробоватьСкачать под WindowsDockerДокументация

Поддержка

Поддержка и обновления для Devprom ALM, установленном на сервере вашей компании, доступны по ежегодной подписке:

  • Русскоязычная премиум поддержка согласно SLA, указанному в договоре поддержки.
  • Консультации по установке и настройке, обновлению Devprom ALM, удаленное администрирование сервера.
  • Пакеты обновлений до новых версий Devprom ALM.

Стоимость поддержки составляет половину от стоимости используемых лицензий (на момент оплаты) и оплачивается один раз в год. Если вы приобретаете 20 лицензий и больше, стоимость первого года поддержки составит 0 рублей.

Внедрение и обучение

Мы поможем выстроить правильный процесс разработки ваших продуктов, поделимся нашим многолетним опытом, чтобы значительно сократить ваш путь к эффективному производству программных продуктов. Мы используем только лучшие практики индустрии, проверенные нашими клиентами, помогаем с их внедрением и проводим обучение.

  • Аудит текущего подхода или процесса, анализ рисков, выработка рекомендаций.
  • Выбор наиболее подходящего процесса разработки, разработка основных метрик оценки эффективности.
  • Выделение ролей участников процесса разработки, распределение ролей в команде, разработка схемы взаимодействия.
  • Обучение сотрудников в соответствии с их ролями.
  • Автоматизация участков процесса разработки, повышающая эффективность процесса в целом.

Доработка ПО под заказчика

Для удобного использования ПО, оно должно быть интегрировано в инфраструктуру организации, поддерживать и автоматизировать особенности процессов, выстроенных в командах и компании в целом.

В Devprom.ALM заложены мощные механизмы расширения функциональности, позволяющие адаптировать приложение практически под любые задачи:

  • REST API, позволяет получать и сохранять данные, передавать их в другие системы.
  • При помощи открытого SDK это могут сделать ваши специалисты или внешние исполнители, например, наши разработчики или разработчики наших партнеров. Таким образом, вы не попадаете в зависимость от одного вендора и можете минимизировать стоимость или риски за счет привлечения любых внешних исполнителей.

Доработка Devprom ALM силами наших специалистов осуществляется по договору сопровождения, на основе заранее согласованного видения (или технического задания). В процессе разработки мы постоянно демонстрируем промежуточные результаты и корректируем дальнейшие шаги по разработке. В процессе приемки и при пилотной эксплуатации мы уточняем требования и ожидания заказчика и доводим решение до финального состояния, при котором оно выполняет все возложенные на него задачи.

Техническая поддержка

Наша команда не оставит вас наедине с техническими сложностями, которые могут возникнуть в процессе внедрения и эксплуатации нашего ПО. Мы оказываем квалифицированную техническую помощь в рамках договора поддержки по следующим направлениям:

  • Консультации по выбору конфигурации оборудования и общесистемного программного обеспечения ПО
  • Консультации по установке, администрированию и настройке ПО
  • Консультация по организации резервного копирования баз данных ПО
  • Консультации по восстановлению работоспособности ПО (в случае ее потери)
  • Информирование о появлении новых версий ПО и их предоставление
  • Консультирование по обновлению версий ПО
  • Консультирование общим вопросам использования ПО
  • Удаленное администрирование серверов и настройка ПО

Применение доски задач для управления бизнес-процессами

Рассмотрим возможный вариант использования разработанного решения на примере взаимодействия трех различных организаций в рамках одного события. Предлагаемая ситуация не претендует на полную достоверность всех деталей. Она представлена в упрощенном виде с целью наглядно показать ширину возможностей для использования системы электронного документооборота в общем и разработанного решения в частности.

Исходная ситуация. На нефтеперерабатывающем предприятии проведена плановая проверка Ростехнадзором по вопросам промышленной безопасности. Выявлены нарушения на одной из технологических площадок, для устранения которых требуется размещение дополнительных средств контроля воздушной среды рабочей зоны, а также перенос регулирующих элементов на линии в соответствии с нормативными правовыми актами. В предписании указан срок устранения замечаний, по истечении которого проводится повторная проверка.

Допущения. Все организации и сотрудники, участвующие в примере, имеют систему электронного документооборота. Поэтому все внутренние процессы компаний, а также официальная переписка и передача документации осуществляются в электронном виде и не рассматриваются в рамках примера.

Решение. Для устранения нарушений, выявленных Ростехнадзором, существует ряд обязательных мероприятий, выполняемых в хронологическом порядке:

1. Написание технического задания на реконструкцию (модернизацию).

2. Разработка проекта специализированной организацией.

3. Экспертиза проектной документации в аккредитованной организации.

4. Проведение строительно-монтажных работ.

5. Выполнение пуско-наладочных работ.

6. Ввод площадки в эксплуатацию приказом по предприятию.

Мероприятия 1, 4–6 выполняются на предприятии. Для написания технического задания формируется команда из опытных сотрудников различного профиля (технолог, энергетик, механик, киповец и др.). Каждый участник команды выполняет задачу в рамках рабочего элемента по своему направлению (рисунок 5).

Рисунок 5. Карточка рабочего элемента с заданием.

Обобщенные данные по рабочим элементам включаются в техническое задание. Подготовка материалов для технического задания и его написание осуществляется в рамках спринтов, где статусы задач отображаются на Scum-доске (рисунок 6). Вместе с подготовкой технического задания в спринты включаются задачи по согласованию и заключению договоров с проектной (проектным институтом) и экспертной организациями на оказание услуг, подбору оборудования и закладных конструкций, составлению заявок, аналитических справок, служебных записок и др.

Рисунок 6. Представление Scrum-доски на нефтеперерабатывающем предприятии.

Мероприятие 2 выполняется проектной организацией. Каждый новый проект по реконструкции (модернизации) является уникальным и разрабатывается на основании технического задания заказчика. Поэтому формируется проектная команда, участники которой – специалисты по различным направлениям. Проект разрабатывается командой в жесткие сроки, и для этого целесообразно использовать доску задач и выполнять задачи в рамках спринтов (рисунок 7).

Рисунок 7. Представление Scrum-доски проектной организации.

При прохождении рабочих элементов (разделов документации) по статусам («Проектирование», «Рецензирование» и «Утверждение») для обратной связи между участниками команды целесообразно использовать закладку «Обсуждение», реализованную в виде чата (рисунок 8). На данной закладке фиксируется вся история переписки в рамках рабочего элемента.

Рисунок 8. Внешний вид закладки «Обсуждение».

После того как проект выполнен, он направляется на экспертизу по промышленной безопасности в аккредитованную организацию (мероприятие 3). Экспертиза проекта выполнятся группой экспертов по своей области аттестации (аккредитации). Для прозрачности процесса экспертизы между всеми экспертами и руководством организации, а также соблюдения установленных сроков также целесообразно использовать доску задач (рисунок 9). Для оперативного контроля и анализа результатов выполнения запланированных задач в рамках спринта используется диаграмма сгорания (рисунок 10).

Рисунок 9. Внешний вид доски задач в экспертной организации.

Рисунок 10. Внешний вид диаграммы сгорания в рамках спринта.

Заключение экспертизы направляется для регистрации в Ростехнадзор. А перед началом работ по реконструкции туда направляется также требуемый пакет документов. Это является основанием для выполнения мероприятий 4–6. Данные мероприятия являются заключительным этапом, зависящим от сотрудников предприятия. Поэтому для наглядности процесса также целесообразно выполнять мероприятия в рамках спринтов, используя для этого Scrum-доску и диаграмму сгорания.

Рассмотренный пример показывает, что предлагаемая доска задач может использоваться не только для управления процессом разработки ПО в соответствии с Agile-методами, но и в качестве основного средства визуализации и автоматизации управления различными процессами в других областях деятельности.

Ссылка на основную публикацию
Статьи c упоминанием слов:
Adblock
detector