Часть 1. Визуализация данных и процесс сотрудничества

1. Фон: Ограничения методологии Agile и экосистема SI

1.1. Суть методологии Agile: Быстрая реакция и гибкость к изменениям

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

Основной процесс, к которому стремится Agile, — это постоянная доставка пригодного программного обеспечения через повторяющиеся короткие циклы разработки (Итерации или Спри́нты), постепенно встраивая обратную связь в продукт.

1.2. Осознание как PM разработки и направление развития системы управления проектами (PMS)

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

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

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

1.3. Стена реальности: Структурные противоречия экосистемы SI, требующие количественных показателей в пределах фиксированных сроков

SI проекты, как правило, имеют традиционную водопадную структуру, основанную на заранее установленном бюджете, фиксированной продолжительности и четко определенном объеме работ (RFP). Клиент, как сторона контракта, ожидает, что функциональные требования, указанные на момент заключения контракта для управления рисками, будут точно реализованы к окончательному сроку поставки.

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

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

Каков точный процент общего прогресса по сравнению с текущими требованиями?

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

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

2. Определение проблемы: Административные расходы, вызванные отчетностью при Agile

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

2.1. Инверсия основного и подчиненного: Бэклог, который был искажен в 'данные для отчетности клиенту' вместо плана разработки

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

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

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

2.2. Черная дыра ресурсов: Усталость от ручной документации и отслеживания часто изменяющихся элементов бэклога

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

Чтобы преодолеть этот разрыв, менеджеры проектов (PM) и ведущие разработчики постоянно тратят административные усилия. Работа по ручной переработке часто изменяющихся данных бэклога, извлеченных в файловом формате, в шаблоны водопада для отчетности клиентским руководителям с использованием Excel или PowerPoint, повторяется, в результате чего сами инструменты становятся черной дырой ресурсов, снижающей продуктивность проекта.

2.3. Психологическая усталость: Искажение ежедневных встреч Скрам и ПМС становится инструментом наблюдения

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

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

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

3. Процесс решения: Подход, ориентированный на визуализацию данных и процессы сотрудничества

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

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

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

3.1. Архитектурная философия: Строительство 'Системы обратной связи в реальном времени через визуализацию данных' вместо наложения правил

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

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

3.2. Дизайн диверсификации панели визуализации данных по ролям команды

Хотя говорится, что это данные с одинаковыми характеристиками, структура, которая выражает всю информацию на одном экране, вызывает избыток или недостаток информации в зависимости от членов организации.

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

• Представление инженера:Это предоставляет основанный на Канбане вид, который интуитивно захватывает зависимости между потоками задач в реальном времени на уровне кода и архитектурных компонентов. Выделяя основные технические проблемы, с которыми сталкиваются отдельные инженеры и инфраструктурные узкие места, он может создать среду, которая побуждает разработчиков сосредоточиться исключительно на контексте реализации их основной функциональности, такой как сложные запросы или моделирование данных.

• Вид менеджера проекта (PM View):Предоставляет вид, который интегрирует тренд скорости команды на основе story points и кумулятивной диаграммы потока. Особенно часто встречается на практике.Изменения в реальном времени по добавлению, удалению, story points и оценочным баллам бэклога агрегируются и визуализируются в реальном времени без отдельной встречи.Создан для того, чтобы помочь администраторам непрерывно отслеживать сигналы риска по всему проекту и проактивно защищаться от переполнения графика.

• Вид клиента:Мы смело уходим от фрагментированных технических терминов и детализированных единиц билетов, сосредоточенных вокруг инженерии, предоставляя вид, адаптированный к перспективе клиента.Сопоставление WBS (структуры разбивки работ) и идентификаторов требований с количественной матрицей уровня завершения реального времени Agile бэклога.Показав это, мы стремимся предоставить клиентскому менеджеру надежное количественное подтверждение того, что проект находится под полным контролем в рамках договора через представление отслеживания прогресса.

3.3. Соответствие Agile процессам сотрудничества для обмена контекстом работы

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

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

• Упор на уточнение бэклога:Основная задача уточнения бэклога заключается не просто в исправлении текста, а в фактическом выполнении.Четко обозначьте объем бэклога и точно скорректируйте очки историй и оценку ценности.Он должен быть согласован. В процессе этого неясности бэклога будут прояснены, и вся команда сможет видеть одни и те же приоритеты.

3.4. Оптимизация ежедневного скрама: максимизация плотности коммуникации и предотвращение процессов потери времени.

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

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

• Обмен черновиками основных вопросов:Перед началом ежедневной встречи по скраму все члены отряда должныЗаранее записать основные технические проблемы или проблемы с расписанием на доске и в общем потоке.Мы придерживаемся установленных правил. Это создает основу для визуального распознавания факторов риска сразу после своевременного начала встречи.

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

3.5. Управление и отчетность о ресурсной экономии через визуализированное совместное использование

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

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

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

4. Следующие шаги по улучшению процесса

В Части 1,Характеристики ограничений и контрактных структур в экосистеме SIМы диагностировали реальность искаженной гибкой методологии из-за. Ухудшения незавершенной работы, усталости от документации и ежедневных скрамов, которые затенены формальной отчетностью и т. д.Реальность административных издержек, с которыми сталкиваются практикиопределено.

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

Если Первая часть сделала основу для обеспечения видимости и снижения административного трения через многомерную визуализацию, следующая серия отразит эту дизайнерскую философию с точки зрения agile.Направление планирования разработки DevLimeчтобы делиться, и, кроме того, устранить фундаментальную усталость от человеческого ввода и когнитивные нагрузкиКак разумно масштабировать систему PMS через внедрение ИИЯ хотел бы обратить внимание на содержание.

5. Ссылки

5.1. Популярные Agile-руководства и ценности Scrum

• Кен Швабер, Джефф Сазерленд, "Руководство по Scrum" (последнее издание)

  • Контекст ссылки: Это общепризнанный руководящий принцип, который наглядно иллюстрирует концепции реагирования на неопределенность, гибкости и периодических обратных связей через спринты, акцентируемые в '1.1. Суть Agile-методологий'.

• Роберт К. Мартин, "Чистый Agile" (Insight, 2020)

  • Контекст ссылки: Эта популярная книга предлагает интуитивное и простое объяснение того, почему суть agile разрушается, а также административные накладные расходы и феномен фейкового agile, в которые практики склонны попадать, с точки зрения разработчика.

5.2. Стандарты управления проектами и анализ гибридной среды

• Институт управления проектами, "Руководство по практике Agile" (PMI, 2017)

  • Контекст ссылки: Это представляет собой гибридный подход, который снижает давление количественного прогресса и управленческое трение, возникающее из сочетания структуры водопада и agile-спринтов, учитывая уникальность отечественной среды системной интеграции, обсуждаемую в '1.3. Стена реальности' и '2. Определение проблемы'.

5.3. Визуализация работы и инновации в процессе Канбан

• Дэвид Дж. Андерсон, "Канбан: успешные эволюционные изменения для вашего технологического бизнеса" (Insight, 2014)

  • Контекст ссылки: Это предоставляет практическую основу для архитектуры Канбан, которая значительно снижает управленческие ресурсы, исключая искусственные управления рабочими процессами или соблюдение правил, предложенные в '3. Процесс решения проблем', и визуализируя данные в нескольких измерениях (вид инженера/PM/клиента) для обмена.

dev.young