Agile, Scrum, разработка ПО Archives – Страница 12 из 30

Как бизнес-аналитику встроиться в гибкую среду?

Есть ли роль бизнес-аналитика в гибкой среде? Я уже довольно давно работаю бизнес-аналитиком, и этот вопрос возникает постоянно. Бизнес-аналитики зачастую считают, что они должны оправдывать свою роль в гибкой разработке. Тот факт, что такой вопрос всё время задают, проистекает из руководства по Scrum. Scrum Guide определяет три роли в команде: команду разработчиков, Scrum -мастера и владельца продукта. Легко заметить, что здесь не упоминается о роли гибкого бизнес-аналитика. Нельзя сказать, что мы единственные, кто остался в стороне – также не определены роли для архитекторов решений, тестировщиков, группы обеспечения качества, менеджера развёртывания, дизайнера пользовательского интерфейса или технических писателей. Мы все каким-то образом…

Бэклог! – Как много в этом слове …

Команды, работающие над развитием различных продуктов, имеют одну общую цель: обеспечить максимальную скорость изменения своего продукта для реализации возникающих потребностей пользователей / заказчиков. Вопрос: В каких условиях команда может достигнуть требуемых показателей? Ответ: При одновременном достижении двух условий: Команда, как черный ящик, устроена внутри корректно: умеет работать с потоком обрабатываемых объектов (намеренно не указываю каких), пропускная способность отдельных этапов обработки сбалансирована. Достижение такого состояния – предмет отдельной целенаправленной работы, детализировать далее не будем, предполагаем далее, что оно достигнуто. Команда может управлять входом поступающих объектов: объекты должны быть замкнутыми (в математическом смысле :): иметь строгие границы) так, чтобы команда могла их…

Может ли быть слишком много прозрачности в работе Agile-команд?

Прозрачность часто называют одним из трёх столпов Agile, наряду со способностью к проверке и адаптации. Но может ли команде быть нанесён вред от излишней прозрачности? Майк Кон (Mike Kohn), один из соавторов и основателей Scrum и Scrum Alliance, считает, что это возможно, и предлагает свой подход по снижению возможного урона. Для начала давайте определим, предлагает Майк, прозрачность как отражение того, как работает команда. Измеримая часть на самом базовом уровне может быть представлена следующими метриками: скорость работы отработанные часы количество story points на одного сотрудника команды диаграммы выгорания количество исправленных дефектов за один спринт и проч. Некоторые из них, возможно, стоит…

5 спорных моментов, убранных из Scrum

Сам по себе фреймворк Scrum уже давно перестал быть инновацией. Появившись задолго до подписания Agile-манифеста, Scrum сегодня неразрывно связан с миром гибких подходов. Основой фреймворка уже довольно давно является “Руководство по Scrum” (Scrum Guide). С момента своего появления этот документ довольно сильно изменился. В своей статье голландский специалист Вилем-Ян Агелинг рассказывает о пяти спорных моментах, выпавших из руководства по Scrum за эти годы. Если вы перешли на Scrum пять или более лет назад, то ваше понимание Scrum отличается от того, которое существует сегодня. Есть много вещей, которые когда-то определялись как Scrum, даже упоминались в руководстве по Scrum, но в какой-то…

Почему стоит меньше рассуждать об Agile и больше о потоке

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

DevOps и “смерть” разработчиков. Что-то пошло не так

Разработка уже умерла давным-давно и была заменена DevOps. Или, по крайней мере, так должно было случиться после появления DevOps. Знакомая мантра? Бернард Броуд (Bernard Brode) в своей заметке на портале DevOps.com рассказывает, почему это не так. На самом деле у разработчиков всё просто отлично. Например, прямо сейчас на крупнейшем в мире сайте по поиску работы Monster.com около 150 000 вакансий для разработчиков. И для сравнения лишь около 16 000 позиций для специалистов DevOps. Похоже, что революция, в ходе которой разработчики должны были бы быть заменены инженерами DevOps, не случилась. “Смерть” разработчиков Угасание позиции разработчика предсказано было уже давно. Фактически, с…

Agile-методы не подходят для устаревшего лидерства

Две группы лидеров Не так давно я разговаривала с потенциальным клиентом, давайте назовём его Стивом, который был заинтересован во внедрении гибких практик управления. Стив полагал, что он уже очень хорошо осведомлён об Agile. Он хотел, чтобы его организация «стала гибкой», ожидая более быструю поставку продукта, лучшую предсказуемость и лучшие показатели. Все это веские причины, по которым организации хотят стать гибкими. Но когда я спросила его, что он будет делать с улучшением показателей, он дал мне повод задуматься. Ответ Стива: «Мы хотим посмотреть, насколько хорошо работают команды, получаем ли мы от них то, за что им платят. Мы не можем позволить…

Сдвиг тестирования вправо. Возникновение TestOps

Понятие shift-left на протяжении некоторого времени является популярной тенденцией в практиках непрерывного тестирования. Неожиданно, в последнее время мы начинаем видеть в тестировании новый тренд: «shift right». Сдвиг вправо влечет за собой проведение дополнительного тестирования на этапах пререлизной и пострелизной версий (т.е. тестирование в продуктивной среде) жизненного цикла приложения. К ним относятся такие практики как: валидация релиза, деструктивное/хаос-тестирование, A/B и канареечное тестирование, CX-тестирование (например, корреляция поведения пользователя с тестовыми требованиями), публичное массовое тестирование, мониторинг сред эксплуатации, извлечение тестовых представлений и сценариев из данных продуктивных сред. Shift-right не только вводит такие методы тестирования, но также требует, чтобы тестировщики приобретали новые навыки, активно…

Новостной поток, 13 июля 2020, последний комментарий 13 июля 2020

Побыть в шкуре бизнеса

В некоторых компаниях есть замечательная практика. Почти любой новый сотрудник в первые же недели своей работы, в какое бы подразделение компании он не устроился, обязан некоторое время поработать “в бизнесе”. Насколько я помню, эту затею придумали японцы, затем распространили её по миру в составе бережливого производства (Lean). Мне известно минимум три примера такой практики в России: одна производственная компания отправляет многих новых сотрудников (включая ребят из ИТ) на сборочный конвейер, другая – на упаковку готовой продукции, третья – в свои розничные магазины. Эта действительно замечательная процедура даёт очень наглядное понимание – что есть бизнес конкретной компании и в чём он…

Олег Скрынник, 4 июля 2020, последний комментарий 10 июля 2020

Устойчивая цифровая трансформация

Цифровая трансформация для многих организаций означает улучшение качества обслуживания и пользовательского опыта за счёт технологических инноваций и соответствующего быстрого появления и развития новых продуктов и услуг с меньшими затратами на создание такого опыта из года в год. Оглянувшись лет на 10 назад, мы увидим, что пройден огромный путь в плане технологий и программного обеспечения. А насколько улучшился пользовательский опыт по сравнению с ростом технологических возможностей за тот же период? И если существенно не улучшился, то по каким причинам? Устаревшие лекала Многие компании оказались в ситуации, в которой им необходимо было немедленно начать модернизировать свои системы, чтобы оставаться конкурентноспособными, но они…

Опыт организации продуктовой команды

В этом вебинаре – разбор реального кейса из практики управления трансформацией действующей команды разработчиков при ориентации на продуктовый подход. Вопросы, которые затронуты в обсуждении: Зачем команде становится продуктовой? И что это вообще такое – продуктовая команда? С какими трудностями на начальных шагах пришлось столкнуться? Как планировать развитие команды в условиях рабочей загрузки? В чем выгода изменений для каждого участника, команды в целом и бизнеса? Какие полезные инструменты организационного управления можно применить? Ведущая: Светлана Сапегина, консультант Cleverics

Портал №1 по управлению цифровымии информационными технологиями

Agile, Scrum, разработка ПО

Портал №1 по управлению цифровыми
и информационными технологиями