Все потоки
Поиск
Написать публикацию
Обновить
26.96

Agile *

Гибкая методология разработки

Сначала показывать
Порог рейтинга
Уровень сложности

Делегировать нельзя участвовать. Где запятая? Должен ли продакт участвовать в UX-ах?

Уровень сложностиПростой
Время на прочтение4 мин
Количество просмотров599

Кому будет полезна статья?

В ходе недавнего UX-теста узнал от команды исследователей, что далеко не все продакты ходят на UX-ы ? 

Да и сам, каюсь, посетил далеко не все из-за параллельных встреч и кучи других задач. Это натолкнуло меня на мысль разобраться, а должен ли продакт вообще участвовать в UX-ах или он, как менеджер, должен делегировать эту задачу другим членам дискавери команды? 

Разобрали этот вопрос вместе с коллегами в этой статье. 

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

Читать далее

Продуктовый подход и проверка гипотез – основа экспоненциального развития банка

Время на прочтение7 мин
Количество просмотров2K

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

Читать далее

Аналитик в огне! Как построить процесс постановки задач в условиях нехватки ресурса

Уровень сложностиПростой
Время на прочтение3 мин
Количество просмотров2.1K

Кому будет полезна статья?

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

продактам, которые устали от того, что бизнес-заказчики двигают свои задачи вперед и нарушают планы продуктовой команды;

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

Читать далее

Как перестать играть в спринты или “тойоту” и начать становиться командой

Уровень сложностиСредний
Время на прочтение5 мин
Количество просмотров4.4K

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

Разработчикам закидывают много разных задач и даже проектов “в параллель”. Часто довольно плохо понятно, ЧТО и КАК надо сделать. Ты долго разбираешься: и хорошо ещё, если есть какая-то актуальная документация, и не надо пытаться понять, то ли в доке ошибка, то ли ты тупой. А еще мир не идеален и регулярно что-то где-то ломается, а разработчиков, которые писали тот код, давно уже нету. Давать какие-то оценки сроков в таком формате практически нереально, а начальство уже нарисовало дедлайны и запуски, — и ходит недовольное.

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

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

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

Читать далее ?

Ретроспектива по итогам PI-планирования

Уровень сложностиПростой
Время на прочтение4 мин
Количество просмотров1.9K

Эта статья будет полезна для тех, кто работает с форматом PI планирования и проводит командное ретро по итогам квартала.

Каждый раз по завершению PI мы в сегменте проводим ретроспективы и делаем это в два этапа:

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

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

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

План работы:

Открытие

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

Читать далее

Покер планирование: Коллективная оценка трудоемкости задач в Agile (Planning Poker)

Уровень сложностиПростой
Время на прочтение2 мин
Количество просмотров8.6K

В 2002 году Джеймс Греннинг представил миру концепцию Покера планирования (Planning Poker) в своей публикации. Стоит отметить, что он является соавтором Agile-манифеста, который по сей день является одним из фундаментальных принципов разработки программного обеспечения.

Итак, что такое Покер планирования?

Покер планирования – это техника, применяемая в Scrum-командах в рамках Agile-разработки для коллективной оценки трудоемкости задач.

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

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

Если вам нужен онлайн-сервис для покер планирования на русском языке, рекомендуем обратить внимание на https://pplanning.ru.

Но также существуют зарубежные сервисы для покер планирования:

Читать далее

Технический бекграунд и образование для IT менеджера. Необходимость или преимущество?

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров5.1K

На старте карьеры в IT меня очень волновал этот вопрос. Настолько волновал, что в первой же команде, куда я попал, я стал изучать стек технологий, который использовала команда. Начал писать какой-то простой проект на PHP, потом на Java и даже просил дать мне какие-то простые задачки, связанные с тестированием API через Postman и оформлением документации в Swagger. Правильно ли я тогда поступил или нет? И стоит ли всем, сломя голову, погружаться технику?

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

Дальше предлагаю пройтись по аргументам «за» и «против».

Читать далее

Как организовать процесс тестирования гипотез в команде и сэкономить несколько десятков миллионов рублей

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров5.6K

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

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

Читать далее

Отзывы от клиентов об agile-трансформации hardware стартапа

Уровень сложностиПростой
Время на прочтение16 мин
Количество просмотров576

Здравствуйте, коллеги! В предыдущих статьях я рассказывал об общих принципах agile-подхода в разработке электроники, теперь я хотел бы перейти к более сутевой части. На сайте www.scrum4rnd.ru вы найдёте полную информацию с описанием моей работы методическими рекомендациями (scrum guide, agile-hardware manifest) а также списком рекомендуемой литературы.

Читать далее

Системный подход в Канбан-методе. STATIK — сервисная археология

Уровень сложностиСредний
Время на прочтение11 мин
Количество просмотров11K

Всем привет! Я Евгений Степченко, деливери-менеджер в Тинькофф. Расскажу про подход к анализу и улучшению процессов, который называется STATIK, System Thinking Approach To Introducing Kanban — применение системного мышления при анализе и проектировании канбан-систем. Поговорим о том, как устроен этот подход и как он помогает запускать эволюционные изменения.

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

Читать далее

Краткосрочное и долгосрочное планирование в Scrum и agile

Уровень сложностиСредний
Время на прочтение27 мин
Количество просмотров20K

Эта статья помогает понять, как команды в Scrum и agile могут давать гарантии и сроки, сохраняя гибкость в планировании. Она будет полезна тем, кто заинтересован в четких сроках реализации доработок: заказчикам, пользователям, владельцам продукта, другим командам и отделам. А также разработчикам — для понимания, почему сроки так важны стейкхолдерам и как можно вести диалог о сроках, сохраняя при этом гибкость.

Читать далее

Поиск  программного решения — первое интервью с потенциальным клиентом по продукту

Уровень сложностиСредний
Время на прочтение6 мин
Количество просмотров1.1K

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

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

Итак, процесс интервьюирования может быть достаточно сложным, особенно в случаях, когда у клиента:

несколько заинтересованных сторон;

интеграционные решения внутри своей системы;

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

Читать далее

Источники знаний PM — must have от ЕАЕ-Консалт: документы, книги, стандарты

Время на прочтение6 мин
Количество просмотров4.1K

Этот пост — обзор полезных в практике PM источников знаний, созданный на основе рекомендаций специалистов и руководителей ЕАЕ-Консалт. В материале постарались отразить не только специфическую литературу и документы для PM, но также книги из смежных отраслей знания, ценных, а иногда и необходимых в проектном управлении.

Читать далее

Ближайшие события

Как наладить предсказуемую и управляемую поставку в масштабе 200+ человек и 20 продуктовых команд

Уровень сложностиСредний
Время на прочтение9 мин
Количество просмотров2.2K

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

Читать далее

DevOps: методология, принципы, подходы и технологии

Уровень сложностиПростой
Время на прочтение13 мин
Количество просмотров25K

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

Читать далее

Скрам для электронщиков (Scrum for Hardware)

Уровень сложностиПростой
Время на прочтение2 мин
Количество просмотров1.9K

Так в моём вольном переводе называется книга, написанная Паоло Саммикели и Джо Джастисом.

Scrum for Hardware. Paolo Sammicheli

Читать далее

ZenTao для всех, и все для комфорта: опыт успешного внедрения ZenTao в Skechers China

Уровень сложностиПростой
Время на прочтение6 мин
Количество просмотров926

Привет, Habr! На связи Алексей Пешков, старший менеджер по развитию направления в GlowByte. Не так давно я рассказал о ZenTao – новом интересном решении для команд разработки, которое может успешно заменить Jira. Сегодня хочу поделиться кейсом внедрения этого ПО в известной обувной компании Skechers China. Из этой статьи вы узнаете о том, как ZenTao повысил операционную эффективность ИТ-отдела Skechers и открыл новые возможности для роста прибыли компании.

Читать далее

Нужен ли в архитектуре скрам-мастер: история одной команды

Уровень сложностиСредний
Время на прочтение8 мин
Количество просмотров5.1K

«Да кто такой этот ваш аджайл?! Мы же не продуктовая команда!», «И как меня угораздило в это вляпаться?!» — такие выражения (и много чего еще) я слышала на командных встречах архитекторов компании в роли агента изменений.

Всем привет! Я – Мадина, скрам-мастер в Департаменте управления технологиями МТС, у нас это подразделение называют Департаментом Technology Governance (TechGov).

Одно дело — внедрять скрам или канбан в командах разработки и совсем другое — внедрять гибкие подходы в Центрах компетенций или практик. Таких, например, как архитектура, управление производственным процессом, R&D или даже сам Центр практик Agile.

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

Читать далее

Как PI-планирование помогло выполнять задачи государственной важности и иногда немного спать

Уровень сложностиПростой
Время на прочтение8 мин
Количество просмотров4.6K

Каждый, кто сталкивался с внедрением новых подходов, испытывал весь спектр эмоций. Особенно, если дело касается государственного сектора. РТЛабс использует практики SAFe® с 2022 года. Как мы провели продуктовую трансформацию — подробно в другой статье

Здесь расскажем про важную часть SAFe® — PI-планирование: как мы готовимся к нему, проводим и как управляем планом в течение квартала. С какими ограничениями сталкиваемся и как обеспечиваем работу 1 500 человек в квартальном цикле.

Будет полезно тем, кто хочет изменить подходы к производству ПО, начинает или уже работает с государственным сектором. Мы — самый большой кейс внедрения практик SAFe® в России.

Читать далее

Путеводитель по оценкам задач и котики

Уровень сложностиСложный
Время на прочтение11 мин
Количество просмотров16K

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

Читать далее