Гибкий.ру Кратко о том, что входит в agile сегодня
К гибким «методам управления» относятся, в частности, фреймворк Scrum и метод Kanban. Согласно исследованию Agile в России, Канбан сейчас занимает прочное второе место по популярности после Скрама (если не считать самопальных гибких подходов, которые любят изобретать в российских компаниях).
В Scrum работа ведется спринтами — одинаковыми по продолжительности короткими итерациями. Вся работа выполняется силами небольшой (до 10 человек) команды, в которую входят разработчики, владелец продукта (отвечающий за успех продукта) и скрам-мастер (отвечающий за эффективность и правильное применение Scrum). Команда самостоятельно решает, кто, что, когда и как делает.
Все участники команды совместно планируют спринт, совместно демонстрируют результаты заинтересованным лицам и совместно ищут способы решения проблем как с продуктом, так и с процессом работы. В ходе спринта разработчики ежедневно и устно обсуждают препятствия, краткосрочные планы и разделение работы между собой.
Kanban — это метод повышения качества сервиса: набор принципов и практик, которые делают сервис (или разработку продукта) более быстрым и лучше соответствующим ожиданиям потребителей.
Канбан отличается от Скрама по многим параметрам, в частности:
- имеет более широкую область применения (не только новые продукты, но и поддержка, операционка);
- в отличие от Scrum, внедряется постепенно (без одномоментного изменения текущих процессов) и более просто (без изменений оргструктуры, например);
- нацелен не только на ускорение, но и на равномерность процессов;
- имеет сильно отличающиеся от Скрама метрики, не требующие оценки трудоемкости задач (например, время прохождения задачи в системе);
- отличается отсутствием фокуса на самоорганизацию команды и отсутствием прямой связи Kanban-практик с Agile-ценностями (у Канбана есть свои ценности, многие из которых вполне согласуются с ценностями Agile, например: клиентоориентированность, сотрудничество, прозрачность).
Подробнее об этом см. в статье про отличия Kanban и Scrum.
Наиболее широко применяется первая из 6 практик Kanban: визуализация процесса — в том числе, с помощью так называемой Канбан-доски. Это физическая или электронная доска со стикерами, обозначающими разные задачи. В отличие от Скрам-доски с 3-мя столбцами, в Канбане принято визуализировать на доске каждый этап процесса, а также делить каждый столбец на две части — «в работе» и «готово к следующему этапу»:
Конечно, Scrum и Kanban — это далеко не единственные подходы, входящие в Agile. Но большинство других активно развивающихся сейчас гибких подходов касаются проблем другого уровня, нежели описанные в этой статье.
Речь про проблемы крупных организаций, которые вынуждены конкурировать со стартапами как по скорости вывода новых продуктов на рынок, так и по скорости принятия решений. Таким организациям помогают, в частности, подходы SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum), а также нехитрая практика Scrum of Scrums. Это — тройка наиболее популярных подходов к масштабированию Agile, как показывает то же исследование Agile в России.
Отличительные особенности всех сколь-нибудь популярных в России подходов, имеющих отношение к Agile (а также к более широкому понятию Business Agility), вы можете посмотреть на одном экране, скачав нашу карту гибких подходов для бизнеса в виде картинки и в виде пригодного к печати плаката.
Что за этим кроется
Если посмотреть со стороны, в этом резком подъеме не будет ничего удивительного. Типаж «гений-одиночка с трудным характером» встречается все реже и реже по той причине, что мало какие технологии сейчас создаются одним человеком. На прошлой работе значительная часть моих обязанностей была связана с тем, чтобы приводить сотни, если не тысячи людей к соглашению и поддерживать этот консенсус, чтобы все двигались в едином направлении.
Когда работаешь в большом коллективе, разрешение сложностей с коммуникацией и сотрудничеством быстро превращается в определяющий фактор успеха или провала. Такие вещи, как «психологическая безопасность» и «взаимное доверие» влияют на повседневный рабочий процесс значительно сильнее, чем какие-то конкретные задачи по программированию.
Для джуниоров они важны по той причине, что определяют их качество жизни: пытаться выполнять технические задачи среди людей, которые тебя терпеть не могут, и сложно, и мучительно. Когда же переходишь на более высокий уровень, создавать и поддерживать атмосферу в команде постепенно становится твоей обязанностью.
Глубинное различие между позициями джуниора и сениора заключается в то числе и в этом: задача джуниора — искать ответы на вопросы, задача сениора — выяснять, какие вопросы нужно задавать. Когда пересекаешь определенный рубеж, число технических вопросов, которые соответствуют своему уровню экспертизы, резко падает, а широкое распространение разнообразных инструментов — от надежных компиляторов до Stack Exchange — означает, что сложных вопросов, на которые можно получить прямой однозначный ответ, становится все больше.
Конечно, всегда остаются самые головоломные проблемы, которые имеют критическое значение и с которыми неопытные сотрудники не справятся, сколько их ни бросай на задачу — разве что если резко прокачаются. Соответственно, продолжать отрабатывать и расширять свои навыки нам тоже нужно.
Но, развиваясь как специалист, вы скоре обнаружите, что все эти невероятно трудные технические задачи занимают у вас далеко не все рабочее время. Напротив, самые фундаментальные для работы системы (и самые сложные) проблемы касаются скорее того, как она взаимодействует с окружающим миром — то есть с людьми.
Что интересно, жесткие и мягкие навыки накладываются друг на друга куда сильнее, чем кажется большинству. Когда начинаешь рассматривать свою систему как часть более крупной системы, в которой в качестве элементов функционируют люди, когда начинаешь задаваться вопросом, как люди взаимодействуют друг с другом и ведут себя, многие из старых-добрых систем, разработанных за счет жестких навыков, не только становятся понятнее, но и дают более точные ответы на вопросы, которые принято относить к сфере мягких.
Два классических примера — правила эксплуатации на площадках с многочисленными пользователями и ранжирование всевозможных результатов. В обоих случаях вся суть в том, чтобы переводить «мягкое» интуитивное понимание, чего хотят люди, в «жесткие» математические выражения.
Но даже если не брать те случаи, когда сама техническая задача требует смеси мягких и жестких навыков, многие из мягких навыков, которые сейчас в цене, имеют прямое отношение к управлению сообществом. У этой сферы исторически сложилась плохая репутация среди программистов, потому что в ней (опять же, по старой традиции) всегда работали люди, ничего не понимающие в программировании, и, что еще более важно, относящиеся к нему и тем, кто им занимается, без намека на уважение.
Причина в том, что большая часть этих менеджеров вышла из школы индустриального менеджмента 20-го века — а это именно та область, которая подарила нам выражения вроде «человеческий ресурс». Работники для них — это лишние хлопоты и траты, масса, которой надо «управлять», чтобы поддерживать высокие нормы выработки.
Такой тип «управления», если его вообще можно так назвать, тоже не имеет ничего общего с мягкими навыками. Его создали люди, которые нередко считали, что постигли искусство работы с людьми, хотя в действительности делали это из рук вон плохо, в некоторых случаях — до патологической степени.
Уже одно то, что люди чувствуют недостаток уважения со стороны менеджеров, должно сильно настораживать. В конец концов, работа менеджера заключается в том, чтобы координировать людей и настраивать на командную работу. Если они не способны на самом базовом уровне выстроить отношения взаимоуважения между работниками и собой, другим ждать от них помощи в этом плане определенно не стоит.
Суть в том, что те мягкие навыки, о которых идет речь, не берутся из ниоткуда. Им учатся не на «уроках этикета» или «тусовках». Они складываются из наблюдения за людьми, изучения их особенностей, умения понимать их потребности, даже когда они сами не могут четко сформулировать, чего хотят — и, соответственно, отработать их невообразимо сложно, ничуть не проще, чем профессиональные умения.
Наша привычка говорить о них так, словно это никакие и не навыки, отказывать им в ценности и выводить за пределы профессиональной сферы нам только вредит: когда приходит необходимость самим выполнять соответствующие задачи, быстро выясняется, что не так уж там все и примитивно.
— Специалисты из нашей области уже много лет бьются над этой проблемой.— Больше им биться не нужно! Я здесь, чтобы решить ее при помощи алгоритмов!*Шесть месяцев спустя*— Ого, как тут все сложно.— Да что ты говоришь?
(Мне это напоминают историю с Одним Знакомым Инженером. Когда его команда переезжала в другое здание, он произнес роковые слова: дескать, организовать пространство проще простого, он сам с этим справится, он же инженер. Результаты были, скажем так, занятными.
Agile сложнее, чем 4 ценности
Во-первых, помимо ценностей, в Agile-манифесте есть также 12 принципов, которые уточняют и дополняют ценности.
Во-вторых, в статье «Что такое Agile-подход и зачем он нужен бизнесу» вы найдете подробное изложение 6 признаков работы по Agile, которые намного более конкретны, чем ценности и даже принципы. Приведу их здесь кратко:
- Потребности клиента понятны всем. Важно, что при Agile-подходе на нуждах клиента фокусируется не только бизнес и менеджер продукта, но и вся команда. То есть, каждый из разработчиков понимает: кто клиенты, что им нужно и какие их проблемы решает новый продукт. Это помогает находить более адекватные решения.
- Процессы и оргструктуры максимально упрощены. Правила и процессы, по которым работают Agile-команды, должны быть простыми, чтобы люди смогли сфокусироваться на клиентах и на создаваемом продукте.
- Работа короткими циклами (итерациями). Продолжительность цикла — порядка недели или месяца, за это время разработчики выдают какой-либо полезный для клиента результат.
- Системное получение и использование обратной связи. Разработчики демонстрируют продукт заказчику, получают обратную связь на продукт и сведения об изменениях планов заказчика, затем дорабатывают, добавляют что-то полезное и так далее по циклу. Но также цикл обратной связи работает и для совершенствования самого процесса разработки: для избавления от потерь, задержек и иных препятствий, мешающих повышению производительности.
- Максимум полномочий у исполнителей. В идеале, люди самостоятельно принимают решения и несут за них ответственность. Когда команда или даже отдельный сотрудник сам(а) может, хочет и имеет право решить какую-то проблему без ожидания действий извне, это значительно ускоряет работу.
- Внутренняя мотивация вместо «кнута и пряника». Agile-методы помогают настроить процессы таким образом, что сотрудники становятся более свободны и счастливы на работе, видят востребованность своего труда клиентами, ценят доверие и предоставленные им возможности для саморазвития. Люди с такой внутренней мотивацией эффективнее справляются с работой, особенно если это сложная творческая работа.
Эти 6 признаков характерны для многих гибких подходов, если они правильно применяются. Рассмотрим теперь чуть подробнее, что это за гибкие подходы.
О "гибких" технологиях в разработке программного обеспечения систем поддержки принятия решений
О «гибких» технологиях в разработке программного обеспечения систем поддержки принятия решений
Тиханычев Олег Васильевич
кандидат технических наук
старший научный сотрудник, ЗАО “НИИ проблем управления, информатизации и моделирования АВН”
123007, Россия, г. Москва, пр-д Хэрошзвский 1-Й, 5
И tow65@yandex.ru
Статья из рубрики “Базы знаний, интеллектуальные системы, экспертные системы, системы поддержки
принятия решений”
Аннотация.
Предметом исследования является процесс разработки программного обеспечения автоматизированных систем управления. Объект исследования – методологии организации разработки программного обеспечения. Общепризнанное перспективное направление повышения эффективности применения организационно-технических систем – автоматизация управления ими. В первую очередь автоматизация, организуемая по принципу системы поддержки принятия решений. Существенную долю эффективности любой автоматизированной системы обеспечивает её программное обеспечение. В первую очередь это относится к прикладному или специальному программному обеспечению. Разработка таких программ сопряжена с определёнными трудностями, в первую очередь – организационного характера. Обобщённый анализ показал, что в мировой практике существует достаточно широкий спектр методов организации процесса разработки программ. Эти методы можно разделить на две крупные группы относительно используемых алгоритмов на «жесткие» и «гибкие». Каждый из подходов эффективен для тех или иных условий разработки программного обеспечения. В статье проведён анализ факторов, влияющих на эффективность применения той или иной методологии, синтезированы предложения по целесообразности использования различных методологий в разных условиях процесса разработки. Анализ показал, что для условий разработки прикладного программного обеспечения автоматизированных систем поддержки принятия решений наибольшую эффективность обеспечивает применение «гибких» подходов. В обзорной статье рассмотрены особенности методологии Scrum, являющейся примером типичной реализации «гибких» подходов. На основе анализа особенностей применяемых методов и требований к их реализации, впервые сформулированы выводы о целесообразности применения гибких технологий при разработке прикладного программного обеспечения автоматизированных систем поддержки принятия решений
Ключевые слова: гибкие технологии разработки, организация процесса разработки, СППР, технологии разработки программ, программное обеспечение, автоматизированные системы управления, поддержка принятия решений, автоматизация управления, технология Agile, метод разработки Scrum
УДК:
004.415.2
DOI:
10.7256/2454-0714.2022.2.23743
Дата направления в редакцию:
05-12-2022
Дата рецензирования:
25-12-2022
Один из признанных подходов к повышению эффективности управления – снижение влияния априори присущей этому процессу субъективности за счёт использования математических методов поддержки принятия решений. Алгоритмически этот подход реализуется путём внедрения в практику управления экспертных систем (ЭС) и систем поддержки принятия решений (СППР). Технологически ЭС и СППР реализуются на базе автоматизированных систем управления (АСУ).
В состав типовой АСУ входят технические средства, информационно-лингвистическое и программное обеспечение (ПО), которое разделяется на общее (ОПО) и специальное
(СПО) программное обеспечение Ш. Иногда, для обеспечения детальности контроля разработки, в составе ПО АСУ отдельно выделяют общесистемное программное обеспечение (ОСПО), объединяя ОСПО и СПО в класс прикладного ПО. Эффективность работы АСУ зависит от всех её составных элементов, но функциональность определяется, в первую очередь, возможностями компонентов ПО.
Разработка любой АСУ, в том числе и её программных компонентов, осуществляется по ряду этапов, определяемых нормативной технической документацией (НТД) по организации процессов разработки. В соответствии с ГОСТ, к этим этапам относятся
– формирование требований к АСУ;
– разработка концепции АСУ;
– разработка и утверждение технического задания на создание АСУ;
– разработка эскизного проекта;
– разработка технического проекта;
– разработка рабочей конструкторской документации;
– ввод системы в действие;
– сопровождение АСУ.
Содержание данных этапов и их последовательность определяет технологию разработки и программных компонентов автоматизированных СППР
На практике, при реализации указанного порядка возникает множество проблем, в
первую очередь – организационных. Это определяется тем, что в разработке автоматизированных систем управления сложными распределёнными системами участвует не одно предприятие, а взаимозависимая кооперация разработчиков, работающих в интересах собственных групп потребителей, а иногда и нескольких заказчиков. Ситуация осложняется тем, что в большинстве случаев разработчикам не ставится сразу конкретная задача, а требования к системе постоянно уточняются: на этапах эскизного и технического проектирования.
Очевидное решение проблемы – использование средств автоматизации организации процесса разработки. Но проблема не так проста, как кажется: в настоящее время имеется достаточно широкий спектр подобных средств, реализующих различные методологии разработки. И выбор конкретного средства, определяющего в конечном итоге эффективность разработки, завязанную на сроки, стоимость и качество конечного продукта, является нетривиальной задачей, требующей скорейшего разрешения.
2.Анализ существующих технологий организации разработки программного обеспечения
Безотносительно используемой нашими разработчиками НТД, в мировой практике существует достаточно широкий спектр технологий разработки ПО. К основным из них можно отнести: рациональное программирование RUP (Rational Unified Process), итеративно-инкрементальный метод OpenUP, технологии быстрой разработки приложений RAD (rapid application development), методология MSF (Microsoft Solutions Framework), методология разработки программ с сертифицируемым уровнем надёжности Cleanroom (Cleanroom Software Engineering), технологии гибкого программирования Agile и другие.
Каждая из перечисленных технологий имеет преимущества и недостатки в тех или иных условиях применения, которые, в свою очередь, задаются НТД.
Анализ практики разработки программ показывает, что большинство из перечисленных технологий ориентированы на «жесткие» методологии, реализующие строгие алгоритмы работы. Подходы, определяемые существующей НТД, также рассчитаны на «жесткую» методологию, когда уже на начальном этапе работы в деталях определяется облик будущей системы: её назначение, структура, связи. Это в полной мере относится к разработке программного обеспечения.
Применение такого подхода оправдано с экономической точки зрения. Он хоть и не является самым эффективным из возможных, но обеспечивает получение «минимального гарантированного» результата. А в условиях, когда на начальном этапе удаётся описать детальную функциональную и информационную модель автоматизируемого процесса, показывает достаточно высокий уровень эффективности [4,5,6].
В то же время, возможность детально описать процесс автоматизированного управления имеется не всегда. Например, в части разработки ПО СППР, подобная ситуация является скорее исключением, чем правилом. Опыт показывает, что на начальном этапе создания, чаще всего известно лишь целевое назначение системы и её место в процессе управления, без детализации структуры. Соответственно, определяемые НТД технологии при разработке СППР работать будут не всегда эффективно.
3.Рекомендации по выбору методологии для разработки программного обеспечения
При разработке любой организационно-технической системы возникает вопрос выбора
методов и средств разработки. Перед разработчиком стоит оптимизационная задача выбора между использованием проверенных, надёжных и простых в применении средств, но, возможно, обладающими недостатком функционала и необходимостью освоения более сложных средств с возможной избыточной функциональностью.
Целесообразность использования того или иного подхода к разработке ПО определяется условиями данного процесса. Эти условия, в свою очередь, определяются: типом разрабатываемого ПО, порядком финансирования процесса разработки и способом управления разработкой.
Ориентируясь на тип разрабатываемого ПО необходимо, в первую очередь, учитывать порядок разработки и влияние вносимых изменений на другие компоненты АСУ. Например, СПО, в большинстве случаев, разрабатывается в завершающей стадии проекта, при уже готовом ОПО и ОСПО и практически не влияет на другие компоненты АСУ. Любые изменения ОПО, напротив, существенны для всех остальных компонентов и т.п. Ещё один показатель из этой группы: наличие или отсутствие прототипа. ОПО и ОСПО разрабатываются, как правило, по аналогии с ранее разработанными средствами аналогичного назначения и процесс их разработки может выстраиваться в соответствии с уже известной этапностью разработки прототипа. В свою очередь, СПО, как правило, разрабатывается без прототипа, на основе тенденций, и использование “жестких” подходов в данном случае может быть проблематичным.
Относительно способа управления разработкой можно выделить: формат задания порядка и содержания работ, порядок выстраивания отношений между заказчиком и исполнителем и другое. Каждый из этих факторов оказывает влияние на предпочтительность использования тех или иных технологий разработки ПО: чем жестче они регламентированы,тем проблематичнее использование “гибких” подходов.
С точки зрения финансирования проекты можно классифицировать как по «модели цены», выбираемой в ходе задания разработки, так и относительно этапности оплаты. Наименования моделей цены: от “жесткой фиксированной” до группы “по фактическим затратам” уже позволяют сделать предварительные выводы о возможности использования методологии разработки ПО.
Таким образом, сопоставление комплекса требований по разработке классов ПО АСУ и возможностей по детальности задания работ позволяет сделать выводы относительно целесообразности использования «жестких» или «гибких» технологий. Вариант обобщения таких выводов относительно основных классов П О АСУ приведен в таблице 1.
Таблица 1 – Целесообразность применения «гибких» технологий при разработке ПО
СППР
Условия задания разработки Класс программного обеспечения
ОПО ОСПО СПО
Детальное описание структуры и требований ±
Общее описание требований без детализации структуры ± ±
Общее описание ± ±
назначения, без
детализации
структуры
± – в зависимости от порядка финансирования проекта.
Анализ содержания таблицы 1 позволяет сформировать выводы, что для проектов разработки ПО с фиксированными требованиями целесообразно использовать «жесткие» технологии, а для проектов, отличающихся высоким уровнем неопределённости -«гибкие».
К одной из основных методологий, реализующих «гибкий» подход, относят методологию Agile (Agile software development). Эта методология реализуется несколькими
методиками [7,8], такими как экстремальное программирование (XP), методология разработки динамических систем (Dynamic Systems Development Method – DSDM), функционально-ориентированная разработка (Feature driven development – FDD), Scrum.
4.О возможности использования методологии Scrum для организации разработки программного обеспечения СППР
Типичный представитель семейства «гибких» подходов, методология Scrum, реализующая набор принципов, позволяющих по фиксированным и небольшим по времени итерациям, называемым спринтами (sprints), предоставлять конечному пользователю версии работающего ПО с непрерывно нарастающим функционалом.
Реализация этой методологии [9,10] осуществляется командами разработчиков, включающих основные группы специалистов (Core roles):
– руководитель разработки (Product Owner), который является, по сути, связующим звеном между командой разработки и заказчиком, представляя интересы конечного пользователя;
– координатор проекта (Scrum master), управляющий и организующий процесс разработки;
– команда разработчиков (Development team), состоящая из специалистов, непосредственно разрабатывающих программную продукцию: программных инженеров, архитекторов, программистов, тестировщиков и т.п.
Реализующая методологию Scrum команда разработчиков должна обладать следующими обязательными качествами:
– быть самоорганизующейся;
– быть многофункциональной, обладать всеми необходимыми навыками для разработки программных систем;
– нести коллективную ответственность за выполняемую работу.
К разработке проекта могут дополнительно привлекаться группы «сторонних» участников (Ancillary roles): конечные пользователи продукта (Users), эксперты в предметной области (Consulting Experts) и ряд других специалистов.
Основой методологии Scrum является цикличность работы, этапы (Sprint), в течении
которых выполняется работа над очередной версией продукта. Важным условием является то, что по окончанию каждого этапа должна быть получена очередная рабочая версия продукта. Sprint ограничены по времени и имеют одинаковую продолжительность.
На начальном этапе выполнения проекта определяется его обобщённая структура и сроки, формируется журнал разработки (Project Backlog), содержащий перечень требований по функциональности конечного продукта, описанный в виде набора работ, упорядоченных по степени важности. Журнал может редактироваться всеми участниками скрам-процесса в соответствии с их правами доступа.
Для контроля выполнения проекта используется специализированный инструмент: так называемая «диаграмма сгорания задач» (Burndown chart). Диаграмма визуализирует соотношение выполненных и оставшихся работ относительно общего времени на разработку проекта.
Перед началом каждого этапа проводится задающее совещание (Sprint Planning), на котором производится оценка и формирование перечня работ (Sprint Backlog) в журнале Project Backlog. Sprint Backlog содержит конкретные задачи, которые должны быть выполнены в рамках текущего этапа.
В рамках методологии, в ходе выполнения каждого этапа, проводятся ежедневные совещания (Daily Scrum), с задачей определения состояния работы над текущим Sprint, выявление проблем, уточнение стратегии достижения целей этапа.
По окончании каждого этапа проводится подведение его итогов (Sprint Review) и ретроспективное совещание (Retrospective meeting), задача которых оценить производительность работы на прошедшем этапе, спрогнозировать ожидаемую эффективность в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ в заданные сроки и другие вопросы.
К положительным сторонам методологии Scrum можно отнести то, что она позволяет получить потенциально рабочий продукт в конце каждого этапа. Scrum ориентирован на требования заказчика, адаптивен к их корректировке по мере разработки проекта. Фиксированная небольшая длительность каждого спринта придаёт процессу разработки предсказуемость и гибкость. Работа группы разработчиков осуществляется на основе самоорганизации с минимальной координацией руководством. Именно принципы открытости, инспекции и адаптации, реализованные в Scrum, делают применение гибких технологий привлекательным для заказчика проекта, в первую очередь – финансового. В том числе, в условиях высоких рисков, определяющих ожидаемую результативность работ по созданию СПО СППР. Исходя из этого, «гибкие» подходы оказываются наиболее удобными и для разработчиков при работе над уникальными проектами, к которым можно отнести большинство проектов разработки СП О автоматизированных систем управления [11,12].
К недостаткам методологии Scrum можно отнести высокие требования к качеству команды разработчиков, которым может соответствовать далеко не каждый коллектив.
Конечно, Scrum – это только методология, хоть и реализующая известную философию непрерывного совершенствования рабочего процесса через каждую его составляющую “Кайдзен” (Kaizen), давно доказавшую свою эффективность. Для её практического применения необходимо наличие технологического средства, в данном конкретном случае – программы для реализации методов управления проектами. Специализированного инструментария такого типа существует достаточно много: Jira,
Gemini, Redmine, Team Foundation Server (TFS) и другие. Функции этих программ во многом похожи, часть их совместима друг с другом.
Личный опыт автора – использование программы TFS^13^ для организации процесса создания программных компонентов СППР коллективом разработчиков. Практика показала, что возможности данной программы позволяют достаточно просто формировать «спринты» и задавать их содержание по иерархии «ситуации» – «функции» – «задачи», эффективно распределять и перераспределять работы, контролировать их выполнение. Наличие возможностей коллективной работы, фиксации ошибок и локализации «препятствий», обеспечивает распределённое управление и самоорганизацию команды разработчиков. Встроенный инструментарий управления разработкой делает TFS практически идеальным инструментом для реализации «гибких» методологий разработки ПО, обеспечивающим весь цикл, от назначения работ (рисунок 1), до контроля их выполнения (рисунок 2), автоматической сборки и тестирования.
Рисунок 1.Форма задания работы и назначения исполнителя
Рисунок 2. Форма сквозного контроля работ в TFS
Одновременно, использование TFS не противоречит сложившимся требованиям НТД, позволяя включать в описание работ постановки задач, алгоритмы, электронные модели
в нотациях IDEF, прототипы интерфейсов и другие данные в виде прикреплённых файлов. Впрочем, как отмечалось ранее, TFS не единственная система, эффективно работающая с “гибкими” технологиями. Эту сферу активно автоматизируют и другие разработчики. Например, в продукте JIRA создано специальное приложение JI RA Agile
(рисунок
Рисунок З.Главная форма проекта JIRA Agile Scrum
Впрочем, вне зависимости от положительных сторон и недостатков, использование тех или иных методологий и технологий в каждом конкретном случае, определяется назначением разрабатываемого продукта и условиями разработки.
5.О перспективах применения «гибких» технологий при разработке программного обеспечения СППР
Как показал анализ предметной области, в ряде случаев, характеризуемых неопределённостью условий разработки, применение «гибких» методологий, и таких инструментов как Scrum, позволит существенно повысить эффективность процесса: как в части функционала разрабатываемого продукта, с точки зрения заказчика по существу, так и с точки зрения эффективности затрат, то есть оптимизации участия финансового заказчика.
К сожалению, существующие, определяемые НТД подходы нацелены исключительно на «жесткие» методологии. А назначение и область применения СППР определяет, в том числе, необходимость использования «гибких» подходов к созданию ПО для них. Реализация мер по внедрению «гибких» технологий разработки в область создания П О СППР, где высока творческая составляющая и имеется априорная неопределённость результата, является непростой задачей, но необходимые усилия окупятся с избытком за счёт повышения эффективности всех этапов процесса разработки.
Библиография
1. ГОСТ 34.003-90 Автоматизированные системы. Термины и определения. – Введ. 01.01.92.-М.: Госстандарт России, 1992.-12 с. (Государственный стандарт Российской Федерации).
2. ГОСТ 34.601-90 Автоматизированные системы. Стадии создания-Введ. 01.01.92.-М.:
Госстандарт России, 1992.-7 с. (Государственный стандарт Российской Федерации).
3. ГОСТ 19.102-77 Единая система программной документации. Стадии разработки программ-Введ. 1.01.80.-М.: Государственный комитет стандартов Совмина СССР, 1987.-6 с. (Государственный стандарт Российской Федерации).
4. Рекомендации по стандартизации Р 50.1.028-2001 “Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования” (приняты постановлением Госстандарта РФ от 2 июля 2001 г. №256-ст) – М.: ИПК «Издательство стандартов», 2001.
5. Тиханычев О.В., Саяпин О.В., Гахов В.Р. Современные технологии информационного обследования как фактор успеха автоматизации управления // Информатизация и связь. – 2022. – №6, – с.90-93.
6. Лукинова О.В. Методологические аспекты управления жизненным циклом информационной системы на основе инструментов функциональной стандартизации // Программные продукты и системы. 2022. – № 4. – с.27-35. D0I:10.15827/0236-235X.116.027-035
7. Хенрик Книберг. Scrum и XP: заметки с передовой – Scrum and XP from the trenches.-C4Media, 2007. – С. 140. – ISBN 978-1-4303-2264-1.
8. Майк Кон. Scrum: гибкая разработка ПО – Succeeding with Agile: Software Development Using Scrum. — М.: «Вильямс», 2022. — С. 576.
9. Джефф Сазерленд. Scrum. Революционный метод управления проектами-Scrum. The art of doing twice the work in half the time. — Манн, Иванов и Фербер, 2022.-288 с.
10. Кеннет Рубин. Основы Scrum: Практическое руководство по гибкой разработке ПО = Essential Scrum: A Practical Guide to the Most Popular Agile Process. — М.: «Вильямс», 2022. – 544 с.
11. Тиханычев О.В. Общие подходы к обеспечению автоматизированной поддержки принятия решений. – М.: Эдитус, 2022. – 64 с. ISBN 978-5-00058-060-8
12. Симанков В.С., Толкачев Д.М. Информационное обеспечение ситуационного центра с использованием сети Интернет // Программные системы и вычислительные методы. — 2022.- № 3.-С.267-272. DOI: 10.7256/2454-0714.2022.3.16979
13. Тиханычев О.В., Макарцев Л.В., Гахов В.Р. Рациональная организация процесса разработки прикладного программного обеспечения как предпосылка успешной автоматизации поддержки принятия решений // Программные продукты и системы. -2022. – №4. С.706-710. DOI: 10.15827/0236-235X.120.706-710
Резюме. место agile среди родственных управленческих подходов
Итак, Agile — это не методология, не свод рецептов, не доски со стикерами и не стандартизованный набор встреч команды, предписанный в Scrum.
Это слово сейчас имеет два основных значения:
- Agile — это система ценностей (или образ мышления, или философия, если вам так больше нравится), которая способствует быстрой разработке новых продуктов, максимально отвечающих потребностям клиентов.
- Agile — это также собирательное название очень разных подходов к управлению разработкой, некоторые из которых даже не разделяют все 4 ценности Agile (пример — Kanban). Так уж исторически сложилось.
Agile фокусируется именно на разработке — точнее, на реализации и поставке готовых продуктов. Тогда как для генерации и проверки идей новых продуктов Agile следует дополнить различными продуктовыми подходами: Customer Development, Design Thinking и т.п.
С другой стороны, Agile — это про организацию процесса разработки, а не про технические детали реализации, зависящие от индустрии. Например, в IT-индустрии с той же целью (быстрая поставка ценности клиенту) применяются так называемые инженерные практики и DevOps, но они в Agile не входят.
Agile помогает решить две основные задачи, типичные для современного бизнеса:
- сократить время вывода продуктов на рынок / время их поставки потребителю;
- ускорить принятие решений на уровне команд и выше.
Для подходов к ускорению на уровне программ и портфелей проектов (в крупных организациях) грамотнее применять термин Enterprise Agility, хотя во многих контекстах их тоже относят к Agile.
Что же касается подходов к повышению гибкости/скорости принятия решений на уровне всего бизнеса, то это намного шире Agile. Так что для обозначения таких подходов следует использовать термин Business Agility, получивший распространение в конце 2022-х годов.
Среди 12 доменов бизнес-гибкости, показанных на рисунке, Agile полностью покрывает домен «Гибкость процессов», но также связан в той или иной степени с 5-ю другими доменами, по меньшей мере.
Таким образом, хотя Agile появился намного раньше других модных управленческих терминов, он не теряет своей актуальности. Будь вы хоть топ-менеджером, хоть руководителем проектов, хоть разработчиком продуктов, ценности и принципы Agile-манифеста вам стоит понять и запомнить, чтобы ваш гибкий процесс приносил ожидаемую пользу.
Хорошие новости: выход есть
Думаю, исправить ситуацию можно очень «простым» способом: начать относиться к мягким навыкам как к серьезным профессиональным умениям, ценить их наряду с последними, обучать людей и нанимать тех, кто уже их освоил — в общем, делать все то, что мы делаем по отношению ко всем прочим фундаментальным навыкам.
В качестве первого шага не помешало бы убедиться, что у нас есть общий словарь для их обсуждения. Довольно сложно ценить то, у чего нет названия. Типичные задачи, которые часто выпадают из нашего поля зрения, включают: «дать всем возможность иметь общее представление о том, что происходит с проектом в данный момент», «выработать общий словарь для основных технических концептов, чтобы любой мог их объяснить», «убедиться, что у всех есть право голоса, и важные опасения не остаются невысказанными просто из страха» и «сделать так, чтобы все участники чувствовали личную заинтересованность в проекте и считали его успех своим» (и это еще далеко не все).
Типичные показатели, на которые мы часто не обращаем внимания, включают: «насколько часто пользователи будет испытывать раздражение или другие отрицательные эмоции во время использования продукта и как это повлияет на удержание в долгосрочной перспективе?» или «как проходит следующая сессия после негативного опыта и как это скажется на общем впечатлении от продукта?».
Ничего нового я в предыдущем параграфе не перечислил: это все стандартные вопросы в различных профессиональным специальностям, от управления проектами до исследования пользовательского опыта. Но если команда в целом относится к ним как к побочным соображениям, а не ключевым факторам успеха, дело может закончиться катастрофой: сроки пропущены; разные группы работают над слегка отличающимися версиями продуктов, которые начнут конфликтовать только на финальной стадии, когда их интегрируют; одна из команд исподволь саботирует продукт, потому что не хочет, чтобы он стал успешным; пользователи наталкиваются на какой-нибудь «мелкий» баг и приходят в ужас (это может привести к чему угодно: от массового бегства до судебного иска); доверие клиентов постепенно выдыхается.
Если мы относимся к таким вещам как к важным, а не третьестепенным составляющим проекта, любой член команды должен иметь о них общее представление, чтобы быть в состоянии хотя бы оценить их значимость, даже если сам ими не занимается. Они должны рассматриваться как базис для отдельных ролей в команде, наравне с фронтендом, бэкендом или безопасностью, и распределяться между конкретными людьми.
Ничего страшного, если каждый инженер не будет обладать нужными навыками, чтобы исполнять все эти обязанности. Скажу больше: я буду поражен, если найдется человек, способный справиться с полным списком. Но делая из них «невидимый труд», который никем не ценится и нигде не учитывается, и притворяясь, что навыков, которые он требует, не существует, мы ничего не добьемся, только навредим себе.
Этот вред заключается не только в прямых последствиях (то есть в том, что нужная работа не выполняется), но и в менее очевидных — нам приходится бороться с лишними страхами. Тревога, о которой шла речь в начале статьи — это симптом того, что мы осознаем: нам не хватает чего-то критически важного, и это недостающее неизвестное с каждым днем становится все более необходимо.
Если мы считаем то, чего нам не хватает, «не навыком», а чем-то, что одни умеют просто с рождения (самые популярные претенденты — женщины и «тусовщики», хорошо если не одновременно), а другие (программисты) — нет, от такого положения дел нам становится не по себе.
Ведь получается, что нас вот-вот выкинут с работы и заменят какими-то непонятными людьми, которые будут смотреть на программистов свысока. Но если мы признаем все эти умения истинными навыками — то есть тем, чему люди учатся и в чем совершенствуются (ну, или не совершенствуются) всю жизнь, то это совсем другой разговор.
И разговор этот звучит примерно так: «Черт, у нас в команде никто не умеет [вставить нужное] и мы выкручиваемся как придется» — то есть до боли знакомо любому, кто был задействован хоть в одном проекте. Да, люди, которые справляются с этими задачами лучше всего, обычно приходят из областей, не связанных с программированием, это чистая правда — в области программирования уже несколько десятков лет принято пренебрегать обучением подобным вещам. Но это не значит, что у них не будет ни малейшего понимания программирования и уважения к этой сфере.
Возможно, я скажу банальность, но если человек, в обязанности которого входит координация программистов или отладка их взаимодействия с пользователями или еще что-то в этом роде, относится к программистам без уважения, он не будет справляться с работой и нанимать его не стоит.
Но нужно отметить, что это работает и в обратную сторону: каждый из участников проекта должен с уважением относиться ко всем навыкам, которые необходимы для работы над ним, и разбираться в них в достаточной степени, чтобы принимать участие в диалоге.
Если есть какая-то юридическая загвоздка, связанная с работой системы, все должны знать соответствующие статьи. Если исследование пользователей показало, что что-то вызывает у них позитивную или негативную реакцию, все должны учитывать эти факты при проектировании.
Если задержка блокирует какие-то типы пользовательского поведения, все должны понимать, в чем заключается проблема. И подобным же образом все должны понимать и ценить навыки работы с людьми — в конце концов, система, которую вы выстраиваете, включает в себя как минимум вас самих.
Чем agile отличается от методологий
Термин «методология» применяется к Agile по аналогии с предшествующими подходами к организации разработки программного обеспечения: RAD, RUP, XP и другими.
Однако те, кто сталкивался с Аджайлом, понимают: он не похож на предшествующие подходы, которые описывали процесс разработки в деталях. Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий.
RUP (Rational Unified Process) включает разбиение жизненного цикла разработки на 4 фазы, рекомендованные соотношения объемов работы по 9-ти потокам (workflows) на каждой фазе, а также конкретные инструменты для каждого потока. OpenUP — последняя методология-наследница RUP — короче и гибче, но все равно до краткости Agile ей далеко.
Методология — это совокупность методов и приемов, которые используются в разных сферах деятельности.
Метод — это способ достижения какой-либо цели.
Agile сам по себе не дает алгоритмов, способов и приемов. При этом входящие в Agile «гибкие» подходы нередко предписывают конкретные приемы:
В отличие от методологий, методов и фреймворков разработки ПО, в основе Agile — не конкретные процессы и даже не элементы процессов, а высокоуровневые ценности.
Следование этим ценностям повышает скорость разработки и бизнес-эффект от разрабатываемых продуктов. При этом стоимость разработки может увеличиваться, поэтому Agile нужен не всегда. Подробнее см. в разделе Область применения Agile.
Показанная выше условная схема гибких подходов взята из книги Бориса Вольфсона «Гибкие методологии разработки». Этот краткий справочник по огромному числу гибких управленческих инструментов весьма неплох для своего времени (2022), когда Agile применялся лишь в той индустрии, где он появился — в разработке программного обеспечения. Если же вы не связаны с этой индустрией, для углубления читайте более современные книги без IT-специфики.