[Управление разработкой, Agile, Управление продуктом, Управление персоналом] SCRUM: Разработка и поставка продукта
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Разработка и поставка продукта является смысловой конструкцией, которая характеризует наличие, понимание, использование инженерных подходов и инструментов для разработки программного обеспечения. Активное использование инженерных практик позволяет выпускать продукт высокого качества инкрементно и итеративно, соответствующего потребностям стейкхолдеров. В данной статье предложена система метрик для измерения и дальнейшего анализа атрибутов организации разработки и поставки программного продукта.Остальные части программы оценки готовности к трансформации:
SCRUM: Понимание и применение фреймворка
SCRUM: Гибкое управление продуктовыми направлениями
SCRUM: Развитие сотрудников и продуктовых командИнженерная практика CI/CDИнженерная практика CI (непрерывная интеграция) / CD (непрерывная поставка) позволяет активировать эмпирический процесс инспекции рабочей функциональности продукта с большой частотой для дальнейшей адаптации в части решения найденных проблем. Идея данной практики заключается в том, что любые изменения разработчика в части ПО должны быть слиты в общий репозиторий кодовой базы как можно чаще; далее должна происходить компиляция сборки из общего репозитория как можно чаще для инспекции изменений. ХарактеристикаМетод исследованияМетрикаGIT инструментыНаблюдение за инструментом GIT GIT инструмент есть - 0 балловGIT инструмент нет - 5 баллов Частота CIНаблюдение за периодичностью CI, выполняемым одним разработчиком менее раза в сутки - 0 баллов1 раз в сутки - 1 балл4 раз в сутки - 3 баллаболее 5 раз - 5 баллов Время CI Наблюдение за временем CI, выполняемым одним разработчиком более 4 ч. - 0 балловот 1 ч. до 4 ч. - 1 баллот 30 мин. до 1 ч. - 3 баллаот 5 мин. до 30 мин. - 5 баллов Частота CDНаблюдение за периодичностью CD, выполняемое на стенде разработки менее раза в сутки - 0 балловот 2 - 4 раз в сутки - 1 баллболее 5 раз в сутки - 3 баллапри каждом CI - 5 баллов Время CDНаблюдение за временем CD, выполняемое на стенде разработки более 8 часов - 0 баловот 3 ч. до 8 ч. - 1 баллот 1 ч. до 3 ч. - 3 балламенее 1 ч. - 5 баллов Роль DevOpsНаблюдение за присутствием роли DevOps в контуре разработки роль отсутствует - 0 балловроль присутствует - 5 баллов Количество средНаблюдение за применяемыми средами в процессе разработки более 3 сред - 0 баллов3 среды - 5 баллов Количество веток Наблюдение за используемыми ветками в процессе разработки более 2 веток - 0 баллов2 ветки - 5 баллов [0 - 28] - низкий результат, свидетельствующий об отсутствии инженерной практики CI/CD как класса. Управление средой разработки и поставками происходит хаотичным образом с повышенными временными и экономическими затратами. При данном результате, необходимо переосмыслить текущий подход в части его трансформации и зафиксировать в плане мероприятий для улучшения каждой из характеристик. Не рекомендуется проводить мероприятия вне контекста общей программы трансформации.[28 - 33] - средний результат, свидетельствующий о наличии инженерной практики CI/CD как класса, однако, существуют определенные ограничения для его эффективного использования. В рамках данного результата, необходимо рассмотреть мероприятия, направленные для улучшения характеристик с низкой оценкой. Допускается проводить внедрение мероприятий изолировано от общей программы. [34 - 40] - максимальный результат, свидетельствующий о использовании инженерной практики CI/CD, как это задумано по определению. В случае данного результата, целесообразно зафиксировать процессы и практики для разработки регламента в целях масштабирования на новые продукты. Рекомендуется также рассмотреть следующее свойство: непрерывное обеспечение качеством (CQ), так как в паре c CI/CD достигается больший синергетический эффект.Непрерывное обеспечение качества CQВ отличие от QA (quality assurence), которое фокусируется на решении возникших проблем с использованием инструмента доступных регламентов и процедур, система непрерывного обеспечения качества CQ (continious quality) создает условия для решения проблем через непрерывное улучшение процессов и компетенций сотрудников. Одним из основополагающих принципов CQ является создание оптимальных контуров обратной связи (тестирования) в части нахождения дефектов программного обеспечения, а также частоты запуска обозначенных контуров. ХарактеристикаМетод исследованияМетрикаUnit тестыОпрос разработчиков о наличии unit тестов. 0 - 30% покрытие - 0 баллов30 - 50 % покрытие - 1 балл50 - 80 % покрытие - 3 балла80 - 100% покрытие - 5 баллов Функциональные тесты Опрос разработчиков о наличии функциональных тестов. 0 - 30% покрытие - 0 баллов30 - 50 % покрытие - 1 балл50 - 80 % покрытие - 3 балла80 - 100% покрытие - 5 баллов Регрессионные тесты Опрос разработчиков о наличии регрессионных тестов. 0 - 30% покрытие - 0 баллов30 - 50 % покрытие - 1 балл50 - 80 % покрытие - 3 балла80 - 100% покрытие - 5 баллов Нагрузочные тесты Опрос разработчиков о наличии нагрузочных тестов. 0 - 30% покрытие - 0 баллов30 - 50 % покрытие - 1 балл50 - 80 % покрытие - 3 балла80 - 100% покрытие - 5 баллов АвтотестыОпрос разработчиков о наличии автотестов. 0 - 30% покрытие - 0 баллов30 - 50 % покрытие - 1 балл50 - 80 % покрытие - 3 балла80 - 100% покрытие - 5 баллов Частота unit тестированияНаблюдение за периодичностью unit тестирования не проводится - 0 балловменее 1 раз в день - 1 балл1 раз в день - 3 баллапри каждом MR - 5 баллов Частота регрессионого тестирования Наблюдение за периодичностью регрессионного тестирования в окружении разработки по запросу - 0 балловпри выпуске версии - 1 баллпри выпуске фичи - 5 баллов Частота нагрузочного тестированияНаблюдение за периодичностью нагрузочного тестирования в окружении разработки по запросу - 0 балловпри выпуске версии - 1 баллпри выпуске фичи - 5 балловЧастота функционального тестирования Наблюдение за периодичностью функционального тестирования в окружении разработки по запросу - 0 балловпри выпуске версии - 1 баллпри выпуске фичи - 5 баллов Частота запуска автотестов Наблюдение за периодичностью запуска автотестов в окружении разработки не проводятся - 0 баллов1 раз в неделю - 1 баллпару раз в неделею - 3 баллапри каждом CD - 5 баллов [0 - 35] - низкий результат, свидетельствующий об отсутствии системы непрерывного обеспечения качеством (CQ) как отдельного организационного класса. Производственный процесс разработки программного обеспечения является дефектно ориентированным при котором запускаются циклы “тестирование - исправление” при каждом выполнении регрессионного тестирования. Отдельно стоит упомянуть про технический долг, который растет по экспоненте. При данном результате, рекомендуется переосмыслить текущие подходы и разработать программу мероприятий для улучшения каждой из характеристик. Не рекомендуется проводить мероприятия вне контекста общей программы трансформации.[35 - 50] - средний результат, свидетельствующий о наличии системы непрерывного обеспечения качеством (CQ) как класса, но присутствуют ограничения для его эффективного проявления. При данной оценке уже наблюдаются проявления подхода “сначала тестирование - потом программирование” , однако он не выделен в отдельную сущность как часть культуры CQ. Рост технического долга имеет линейную зависимость от выпущенных версий. В рамках данного результата, необходимо рассмотреть мероприятия, направленные для улучшения характеристик с низкой оценкой. Допускается проводить внедрение мероприятий изолировано от общей программы. [42 - 50] - максимальный результат, свидетельствующий о ярко выраженном свойстве, которое развивается и характеризует производственный процесс разработки ПО, как функционально-ориентированным (feature driven). Любые активности, связанные с тестирование, рассматриваются как очевидные и рутинные операции, которые не требуют время для планирования и выполняются в едином производственном потоке. Оптимальный организационный потокОптимальный организационный поток - принцип организации производства разработки продукта при котором минимизируются административные барьеры для осуществления всего комплекса работ от стадии идеи до поставки инкремента в продуктивную среду клиента. Под административными барьерами понимаются созданные группы по функциональному признаку и наличие сотрудников с выделенной функцией управления. При оптимальном потоке снижается время ожидания ответа на вопрос, что приводит к снижению времени выпуска протестированного и работоспособного инкремента продукта. ХарактеристикаМетод исследованияМетрикаВремя ожидания ответа на запрос принятия решения Наблюдение за средним временем ожидания ответа на вопрос в контексте принятия решения или блокирования работы более 8 ч. - 0 балловот 1 ч. до 8 ч. - 1 баллот 30 мин. до 1 ч. - 3 балламенее 30 мин. - 5 баллов Принцип организации групп Наблюдение за принципом организации групп функциональный принцип - 0 балловпродуктовый принцип - 8 баллов Звенья управления Наблюдение за количеством сотрудников с функцией управления на пути движения задачи более 2х звеньев - 0 баллов2 звена управления - 5 балла1 звено управления - 8 баллов Транспарентность коммуникаций Наблюдение за инструментом коммуникаций в разрезе контентных вопросов хаотичные каналы - 0 балловфиксированные каналы - 5 балловТранспарентность триггеров событийНаблюдение за триггерами при которых должно произойти определенное событие (тестирование, авторская приемка, новый билд)ручная нотификация - 0 балловавтоматизированная - 5 балловОтношение решенных задач к открытымНаблюдение за графиком роста решенных задач в отношении к открытымпреобладают пологие участки - 0 балловстабильный рост - 5 баллов Визуализация организационного потокаНаблюдение за применяемыми подходами в части визуализации движения задачи по потокуотсутствует визуализация - 0 балловприсутствует в контексте функциональной задачи - 1 баллприменяются SCRUM, Kanban доски для визуализации общего потока - 5 баллов[0 - 29] - низкий результат, свидетельствующий об неоптимальном организационном потоке которому свойственно до 50% времени ожидания на решение задач, а также фокусирование на задачах, которые быстро теряют свою актуальность. В первую очередь, рекомендуется сделать акцент на снижение звеньев управления на пути движения задачи и изменить принцип организации групп на предметный (продукт, сервис, компонент). Данные мероприятия необходимо зафиксировать в программе трансформации.[29 - 34] - средний результат, свидетельствующий о формировании оптимального организационного потока, однако существуют ограничения для его эффективного использования. Рекомендуется разработать мероприятия с акцентом на снижение времени ожидания и формирование культуры визуализации рабочего потока с помощью инструментов доступных инструментов (SCRUM и Kanban доски).[35 - 41] - высокий результат, свидетельствующий о наличии оптимального организационного потока при котором соблюдается принцип транспарентности и предметно-ориентированная группа сфокусирована на задачах, которые имеют актуальность в текущий момент времени. Время предоставления ответов на вопросы внутри предметно-ориентированной группы сводится к минимуму , что сказывается на уменьшении времени релизного цикла. Рекомендуются зафиксировать данное свойство, как эталонной и включить в программу обучения и коучинга.Управление рискамиПо определению, риск - это неопределённое событие или условие, которое в случае возникновения имеет позитивное или негативное воздействие на репутацию компании, приводит к приобретениям или потерям в денежном выражении. Процесс идентификации риска и его приоритезации лежит в основе эмпирического процесса его инспекции по необходимым атрибутам (природа, степень влияния, последствия) и дальнейшей адаптации в части запланированных мероприятий, включаемых в бэклог. Можно выделить три категории рисков:
- Финансовый риск - можем ли мы заплатить за продукт?
- Бизнес риск - будет ли продукт использоваться ? продукт решает проблему?
- Технический риск - можем ли разрабатывать и поддерживать продукт?
На всех уровнях разработки программного обеспечения должно присутствовать понимание о природе риска и мероприятиях, которые позволяют ими управлять.ХарактеристикаМетод исследованияМетрикаФинансовый рискНаблюдение за частотой выпуска релизов на продуктивную среду клиентаболее 3 мес. - 0 балловот 2 мес. до 3 мес. - 3 балладо 2 мес. - 5 балловБизнес рискНаблюдение за частотой демонстрации инкремента продукта стейкхолдерампри выпуске версии - 0 балловпри выпуске инкремента - 5 балловТехнический рискНаблюдение за объемом технического долгатехнический долг растет с каждой версией - 0 балловтехнический долг снижается с каждой версией - 5 балловНаблюдение за фактом появления критических ошибок после выпуска версии в продуктивную средупользователь воспроизвел критическую версию - 0 балловпользователь не воспроизвел критическую ошибку - 5 балловМы не будем определять интегральную шкалу оценки свойства “управление рисками”, в связи с тем, что каждая категория риска является самодостаточной характеристикой и требует индивидуального подхода в интерпритации и разработки мероприятий. В случае низких оценок для финансового и бизнес рисков, рекомендуется рассмотреть мероприятия, разработанные в рамках исследования метрика для гибкого управления продуктовыми направлениями. Мероприятия в рамках технического риска, необходимо рассматривать по результату изучения CI/CD инженерной практики и непрерывного обеспечения качества CQ.
===========
Источник:
habr.com
===========
Похожие новости:
- [Программирование, Java, Проектирование и рефакторинг, Управление разработкой] Инструменты для разработчиков могут быть волшебными. Вместо этого они пылятся на полке (перевод)
- [Алгоритмы, Управление проектами, Agile] ДНК (Деление на команды) – визуализация взаимосвязей людей и команд
- [Управление персоналом, Научно-популярное] Google сэкономил на «удалёнке» четверь миллиарда долларов за первый квартал 2021 года
- [Разработка под iOS, Разработка мобильных приложений, Разработка под Android] Сервис для UX-тестирования мобильных приложений за 45 часов: результаты онлайн-хакатона с Oprosso
- [Управление персоналом, Карьера в IT-индустрии] Дайджест событий для эйчаров и рекрутеров в IT на май 2021
- [.NET, Visual Studio, C#, Разработка под Windows] Тайловый менеджер для Windows своими руками на C# Windows Form
- [Читальный зал] Мы преодолеем
- [Управление продуктом, Бизнес-модели] Тестирование гипотез B2B
- [Конференции] Самая крупная конференция разработчиков Урала готовит бесплатную онлайн-трансляцию. Для кого, зачем и как?
- [Управление персоналом, Карьера в IT-индустрии, Читальный зал] Как отвечать на собеседовании, чтобы побудить нанять вас (перевод)
Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_agile, #_upravlenie_produktom (Управление продуктом), #_upravlenie_personalom (Управление персоналом), #_scrum, #_agile, #_startup, #_produkt (продукт), #_razrabotka (разработка), #_transformatsija (трансформация), #_komanda (команда), #_mindset, #_blog_kompanii_otr (
Блог компании ОТР
), #_upravlenie_razrabotkoj (
Управление разработкой
), #_agile, #_upravlenie_produktom (
Управление продуктом
), #_upravlenie_personalom (
Управление персоналом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 16:10
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Разработка и поставка продукта является смысловой конструкцией, которая характеризует наличие, понимание, использование инженерных подходов и инструментов для разработки программного обеспечения. Активное использование инженерных практик позволяет выпускать продукт высокого качества инкрементно и итеративно, соответствующего потребностям стейкхолдеров. В данной статье предложена система метрик для измерения и дальнейшего анализа атрибутов организации разработки и поставки программного продукта.Остальные части программы оценки готовности к трансформации: SCRUM: Понимание и применение фреймворка SCRUM: Гибкое управление продуктовыми направлениями SCRUM: Развитие сотрудников и продуктовых командИнженерная практика CI/CDИнженерная практика CI (непрерывная интеграция) / CD (непрерывная поставка) позволяет активировать эмпирический процесс инспекции рабочей функциональности продукта с большой частотой для дальнейшей адаптации в части решения найденных проблем. Идея данной практики заключается в том, что любые изменения разработчика в части ПО должны быть слиты в общий репозиторий кодовой базы как можно чаще; далее должна происходить компиляция сборки из общего репозитория как можно чаще для инспекции изменений. ХарактеристикаМетод исследованияМетрикаGIT инструментыНаблюдение за инструментом GIT GIT инструмент есть - 0 балловGIT инструмент нет - 5 баллов Частота CIНаблюдение за периодичностью CI, выполняемым одним разработчиком менее раза в сутки - 0 баллов1 раз в сутки - 1 балл4 раз в сутки - 3 баллаболее 5 раз - 5 баллов Время CI Наблюдение за временем CI, выполняемым одним разработчиком более 4 ч. - 0 балловот 1 ч. до 4 ч. - 1 баллот 30 мин. до 1 ч. - 3 баллаот 5 мин. до 30 мин. - 5 баллов Частота CDНаблюдение за периодичностью CD, выполняемое на стенде разработки менее раза в сутки - 0 балловот 2 - 4 раз в сутки - 1 баллболее 5 раз в сутки - 3 баллапри каждом CI - 5 баллов Время CDНаблюдение за временем CD, выполняемое на стенде разработки более 8 часов - 0 баловот 3 ч. до 8 ч. - 1 баллот 1 ч. до 3 ч. - 3 балламенее 1 ч. - 5 баллов Роль DevOpsНаблюдение за присутствием роли DevOps в контуре разработки роль отсутствует - 0 балловроль присутствует - 5 баллов Количество средНаблюдение за применяемыми средами в процессе разработки более 3 сред - 0 баллов3 среды - 5 баллов Количество веток Наблюдение за используемыми ветками в процессе разработки более 2 веток - 0 баллов2 ветки - 5 баллов [0 - 28] - низкий результат, свидетельствующий об отсутствии инженерной практики CI/CD как класса. Управление средой разработки и поставками происходит хаотичным образом с повышенными временными и экономическими затратами. При данном результате, необходимо переосмыслить текущий подход в части его трансформации и зафиксировать в плане мероприятий для улучшения каждой из характеристик. Не рекомендуется проводить мероприятия вне контекста общей программы трансформации.[28 - 33] - средний результат, свидетельствующий о наличии инженерной практики CI/CD как класса, однако, существуют определенные ограничения для его эффективного использования. В рамках данного результата, необходимо рассмотреть мероприятия, направленные для улучшения характеристик с низкой оценкой. Допускается проводить внедрение мероприятий изолировано от общей программы. [34 - 40] - максимальный результат, свидетельствующий о использовании инженерной практики CI/CD, как это задумано по определению. В случае данного результата, целесообразно зафиксировать процессы и практики для разработки регламента в целях масштабирования на новые продукты. Рекомендуется также рассмотреть следующее свойство: непрерывное обеспечение качеством (CQ), так как в паре c CI/CD достигается больший синергетический эффект.Непрерывное обеспечение качества CQВ отличие от QA (quality assurence), которое фокусируется на решении возникших проблем с использованием инструмента доступных регламентов и процедур, система непрерывного обеспечения качества CQ (continious quality) создает условия для решения проблем через непрерывное улучшение процессов и компетенций сотрудников. Одним из основополагающих принципов CQ является создание оптимальных контуров обратной связи (тестирования) в части нахождения дефектов программного обеспечения, а также частоты запуска обозначенных контуров. ХарактеристикаМетод исследованияМетрикаUnit тестыОпрос разработчиков о наличии unit тестов. 0 - 30% покрытие - 0 баллов30 - 50 % покрытие - 1 балл50 - 80 % покрытие - 3 балла80 - 100% покрытие - 5 баллов Функциональные тесты Опрос разработчиков о наличии функциональных тестов. 0 - 30% покрытие - 0 баллов30 - 50 % покрытие - 1 балл50 - 80 % покрытие - 3 балла80 - 100% покрытие - 5 баллов Регрессионные тесты Опрос разработчиков о наличии регрессионных тестов. 0 - 30% покрытие - 0 баллов30 - 50 % покрытие - 1 балл50 - 80 % покрытие - 3 балла80 - 100% покрытие - 5 баллов Нагрузочные тесты Опрос разработчиков о наличии нагрузочных тестов. 0 - 30% покрытие - 0 баллов30 - 50 % покрытие - 1 балл50 - 80 % покрытие - 3 балла80 - 100% покрытие - 5 баллов АвтотестыОпрос разработчиков о наличии автотестов. 0 - 30% покрытие - 0 баллов30 - 50 % покрытие - 1 балл50 - 80 % покрытие - 3 балла80 - 100% покрытие - 5 баллов Частота unit тестированияНаблюдение за периодичностью unit тестирования не проводится - 0 балловменее 1 раз в день - 1 балл1 раз в день - 3 баллапри каждом MR - 5 баллов Частота регрессионого тестирования Наблюдение за периодичностью регрессионного тестирования в окружении разработки по запросу - 0 балловпри выпуске версии - 1 баллпри выпуске фичи - 5 баллов Частота нагрузочного тестированияНаблюдение за периодичностью нагрузочного тестирования в окружении разработки по запросу - 0 балловпри выпуске версии - 1 баллпри выпуске фичи - 5 балловЧастота функционального тестирования Наблюдение за периодичностью функционального тестирования в окружении разработки по запросу - 0 балловпри выпуске версии - 1 баллпри выпуске фичи - 5 баллов Частота запуска автотестов Наблюдение за периодичностью запуска автотестов в окружении разработки не проводятся - 0 баллов1 раз в неделю - 1 баллпару раз в неделею - 3 баллапри каждом CD - 5 баллов [0 - 35] - низкий результат, свидетельствующий об отсутствии системы непрерывного обеспечения качеством (CQ) как отдельного организационного класса. Производственный процесс разработки программного обеспечения является дефектно ориентированным при котором запускаются циклы “тестирование - исправление” при каждом выполнении регрессионного тестирования. Отдельно стоит упомянуть про технический долг, который растет по экспоненте. При данном результате, рекомендуется переосмыслить текущие подходы и разработать программу мероприятий для улучшения каждой из характеристик. Не рекомендуется проводить мероприятия вне контекста общей программы трансформации.[35 - 50] - средний результат, свидетельствующий о наличии системы непрерывного обеспечения качеством (CQ) как класса, но присутствуют ограничения для его эффективного проявления. При данной оценке уже наблюдаются проявления подхода “сначала тестирование - потом программирование” , однако он не выделен в отдельную сущность как часть культуры CQ. Рост технического долга имеет линейную зависимость от выпущенных версий. В рамках данного результата, необходимо рассмотреть мероприятия, направленные для улучшения характеристик с низкой оценкой. Допускается проводить внедрение мероприятий изолировано от общей программы. [42 - 50] - максимальный результат, свидетельствующий о ярко выраженном свойстве, которое развивается и характеризует производственный процесс разработки ПО, как функционально-ориентированным (feature driven). Любые активности, связанные с тестирование, рассматриваются как очевидные и рутинные операции, которые не требуют время для планирования и выполняются в едином производственном потоке. Оптимальный организационный потокОптимальный организационный поток - принцип организации производства разработки продукта при котором минимизируются административные барьеры для осуществления всего комплекса работ от стадии идеи до поставки инкремента в продуктивную среду клиента. Под административными барьерами понимаются созданные группы по функциональному признаку и наличие сотрудников с выделенной функцией управления. При оптимальном потоке снижается время ожидания ответа на вопрос, что приводит к снижению времени выпуска протестированного и работоспособного инкремента продукта. ХарактеристикаМетод исследованияМетрикаВремя ожидания ответа на запрос принятия решения Наблюдение за средним временем ожидания ответа на вопрос в контексте принятия решения или блокирования работы более 8 ч. - 0 балловот 1 ч. до 8 ч. - 1 баллот 30 мин. до 1 ч. - 3 балламенее 30 мин. - 5 баллов Принцип организации групп Наблюдение за принципом организации групп функциональный принцип - 0 балловпродуктовый принцип - 8 баллов Звенья управления Наблюдение за количеством сотрудников с функцией управления на пути движения задачи более 2х звеньев - 0 баллов2 звена управления - 5 балла1 звено управления - 8 баллов Транспарентность коммуникаций Наблюдение за инструментом коммуникаций в разрезе контентных вопросов хаотичные каналы - 0 балловфиксированные каналы - 5 балловТранспарентность триггеров событийНаблюдение за триггерами при которых должно произойти определенное событие (тестирование, авторская приемка, новый билд)ручная нотификация - 0 балловавтоматизированная - 5 балловОтношение решенных задач к открытымНаблюдение за графиком роста решенных задач в отношении к открытымпреобладают пологие участки - 0 балловстабильный рост - 5 баллов Визуализация организационного потокаНаблюдение за применяемыми подходами в части визуализации движения задачи по потокуотсутствует визуализация - 0 балловприсутствует в контексте функциональной задачи - 1 баллприменяются SCRUM, Kanban доски для визуализации общего потока - 5 баллов[0 - 29] - низкий результат, свидетельствующий об неоптимальном организационном потоке которому свойственно до 50% времени ожидания на решение задач, а также фокусирование на задачах, которые быстро теряют свою актуальность. В первую очередь, рекомендуется сделать акцент на снижение звеньев управления на пути движения задачи и изменить принцип организации групп на предметный (продукт, сервис, компонент). Данные мероприятия необходимо зафиксировать в программе трансформации.[29 - 34] - средний результат, свидетельствующий о формировании оптимального организационного потока, однако существуют ограничения для его эффективного использования. Рекомендуется разработать мероприятия с акцентом на снижение времени ожидания и формирование культуры визуализации рабочего потока с помощью инструментов доступных инструментов (SCRUM и Kanban доски).[35 - 41] - высокий результат, свидетельствующий о наличии оптимального организационного потока при котором соблюдается принцип транспарентности и предметно-ориентированная группа сфокусирована на задачах, которые имеют актуальность в текущий момент времени. Время предоставления ответов на вопросы внутри предметно-ориентированной группы сводится к минимуму , что сказывается на уменьшении времени релизного цикла. Рекомендуются зафиксировать данное свойство, как эталонной и включить в программу обучения и коучинга.Управление рискамиПо определению, риск - это неопределённое событие или условие, которое в случае возникновения имеет позитивное или негативное воздействие на репутацию компании, приводит к приобретениям или потерям в денежном выражении. Процесс идентификации риска и его приоритезации лежит в основе эмпирического процесса его инспекции по необходимым атрибутам (природа, степень влияния, последствия) и дальнейшей адаптации в части запланированных мероприятий, включаемых в бэклог. Можно выделить три категории рисков:
=========== Источник: habr.com =========== Похожие новости:
Блог компании ОТР ), #_upravlenie_razrabotkoj ( Управление разработкой ), #_agile, #_upravlenie_produktom ( Управление продуктом ), #_upravlenie_personalom ( Управление персоналом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 25-Ноя 16:10
Часовой пояс: UTC + 5