В этой статье постараюсь описать своё видение планирования спринта с учетом тестирования спринтовых задач и исправления багов по итогам тестирования. Внезапно для меня тема вызвала дискуссию на проекте, в разработке которого я участвую.
Agile *
Гибкая методология разработки
Новости
Передача контекста и знаний в IT команде
Всем привет и добро пожаловать! Данная статья не является научной и не относится к разряду технических, она больше про коммуникации и командные процессы в IT. Это попытка систематизировать реальные практики по передаче контекста и знаний в IT команде, показать их актуальность и важность. Я уверен, что про что‑то из статьи вы уже слышали, видели, читали, или даже сами использовали. И для начала давайте определим основные понятия.
Контекст — совокупность различных факторов и/или сведений, необходимых для понимания или объяснения какого‑либо явления действительности.
Знание — проверенный практикой результат познания, то есть научные сведения, которые были проверены практикой и отражены в сознании человека.
В IT существует множество технологий, методологий, подходов, технических решений. Их комбинация определяет стек технологий компании, которых тоже оказывается множество. Найти специалиста с 100% совпадением по стеку технологий фактически очень сложно, да и знать всё на свете нереально. На самом деле это и не нужно, но статья немного про другое.
С контекстом, на мой взгляд, всё сложнее. Контекст — это не то, что вы можете изучить где‑то, прочитать статью, пройти курсы. Контекст плотно привязан к историческому наследию компанию. Это из разряда «так исторически сложилось». Я думаю, вам приходилось слышать эту фразу. Но даже в компании контекст от команды к команде может сильно отличаться, для каждой команды контекст тоже уникален.
Теперь представьте, у вас есть инфраструктура, проект, продукт, сервис, люди приходят и уходят, а вам нужно это сопровождать, чтобы всё работало стабильно, да ещё желательно, чтобы всё это не было завязано на одного человека. Именно поэтому важно делиться контекстом и знаниями в команде, а иногда даже и между командами.
Методы декомпозиции функциональности приложения
Одной из важных стадий формирования UX (User experience) диджитал-продукта является релиз MVP (Minimal Viable Product, он же минимально жизнеспособный продукт). Эта такая версия вашего приложения или программы, которая подразумевает минимальное количество реализованных в продукте функций, достаточное при этом для формирования пользовательского опыта и фидбека. Это помогает понять, устраивают ли пользователей имеющиеся функции и как его улучшить.
Однако даже после выделения MVP оставшиеся функции могут оказаться многосоставными - раскладывающимися на более мелкие. Отличный метод декомпозиции функциональности — картирование пользовательских историй (User Story Mapping).
Книга «Жемчужины разработки. Чему мы научились за 50 лет создания ПО»
Совершенное программное обеспечение невозможно создать без изучения накопленного опыта.
Опыт — главный учитель, но медленный и нередко болезненный. Но зачем же нам повторять ошибки? Книга «Жемчужины разработки» поможет совершенствоваться быстрее и избежать многих проблем, обучаясь на опыте других людей, которые уже поднялись по кривой обучения. Карл Вигерс сформулировал 60 кратких практических уроков, которые подойдут для любых проектов, независимо от роли, отрасли, технологии или методологии.
Идеи и конкретные рекомендации охватывают шесть важнейших элементов успеха: требования, дизайн, управление проектами, культуру и командную работу, качество и совершенствование процессов. Для каждого из направлений Вигерс предлагает «первые шаги», позволяющие осмыслить собственный опыт, уроки с основными идеями, реальными примерами и действенными решениями и «следующие шаги» для внедрения опыта в вашем проекте, команде или организации. Эти знания нельзя получить в университете!
Истории
Как провести PI-планирование на 100+ человек: от глобальных целей до точечных задач
Когда над созданием продуктов работает множество команд (в нашем случае 16) возникают сложности в их синхронизации. Это приводит к задержкам поставки и неудовлетворенности заказчика. Решить проблему можно с помощью планирования, на котором владельцы бизнеса и все команды определяют высокоуровневые цели и согласно этим целям планируют свою работу на квартал.
Привет, Хабр! Я Ирина Бобрихина, один из скрам-мастеров IT-компании RDP. Хочу поделиться подробным кейсом проведения PI-планирования в крупной компании с помощью сервиса Kaiten.
Ещё больше интересных материалов читайте в нашем блоге.
User Story Mapping или Карты Пользовательских сценариев
User Story Mapping или КАРТЫ ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ - это способ визуального планирования и приоритизации задач. Способ хорош тем, что заставляет нас думать о своих software решениях с позиции ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ(User Story).
Прежде чем мы перейдём к знакомству с методом, важно разобраться с тем, а что такое вообще ПОЛЬЗОВАТЕЛЬСКАЯ ИСТОРИЯ.
Портфель ИТ-проектов: учимся управлять не формально, а эффективно
Поделюсь личным опытом работы в ИТ-компании, использующей проектное управление. Постараюсь выделить важные вещи в эффективной работе, которые, на первый взгляд,как будто не видны и с которыми пришлось столкнуться. Углубляться в project managment не имею цели. Для этого существуют стандарты PMI The Standard for Portfolio Management, ГОСТ Р 54870-2011 «Требования к управлению портфелем проектов». Хотелось бы отметить, что работаю в госсекторе, но возможно опыт будет полезен всем.
Немного о себе. Петряшова Оксана Николаевна - 5 лет руководитель отдела развития, с большим багажом опыта. Всё нижесказанное является личным опытом и субъективным мнением.
Как построить дом по Agile. Пример успешного применения гибкой методологии для самого классического Waterfall-проекта
Хочется начать с тезиса: все методологии хороши, главное – правильно их применять. Однако несмотря на все усилия, я все еще встречаю скепсис у технических специалистов и иногда бизнеса, что Agile методологии не применимы к большим и сложным проектам. Фразы из серии «давайте сначала все продумаем», «у вас не будет второго шанса произвести первое впечатление», «мы не принесем ценности пока не сделаем все фичи», «UI/UX должен быть самый лучший на старте» все еще звучат, и данная статья в легкой форме покажет, что они не всегда актуальны 😊
Меня зовут Сергей Солдатов, я занимаюсь развитием продуктов в ЕДИНОМ ЦУПИС, поэтому статья будет построена в плоскости управления продуктом, но, надеюсь, будет интересна и техническим специалистам, командным лидам, проектным менеджерам и возможно тем, кто планирует строительство дома 😊
Еще один важный момент: моя дорожная карта не подразумевает привязки ко времени, так как в моем рассказе важнее ключевые этапы развития продукта (дом), определение MVP и масштабирование, а дедлайны оставим к темам KPI и построения временных планов.
Когда говорят 'Сделай хорошо': Рекомендации для разработчиков по улучшению процесса
В предыдущей статье, где я затронул тему отмены задач, возникли оживленные дискуссии. Некоторые утверждали, что достаточно найти тим лида с "стальными яйцами", и проблемы с непонятными задачами исчезнут. Но действительно ли это так просто? И правда ли, что решение этих проблем не входит в нашу компетенцию? Как руководитель разработки, я часто вижу, как команды берут на себя задачи, которые кажутся им неправильными, тратят часы на их разъяснение и еще больше времени на доработку перед сдачей.
Может показаться, что работа по формулировке задач лежит за пределами нашей ответственности, но если мы продолжим брать непонятные задачи, для продуктовых менеджеров это будет сигналом, что все идет хорошо. Но мы знаем, что это не так. Не стоит ждать, что ситуация изменится сама по себе или кто-то внезапно решит все проблемы за нас. Пора задуматься о том, как мы можем влиять на этот процесс и сделать нашу работу более эффективной. Ведь в любом случае время на эти задачи уходит, так давайте по крайней мере потратим его с пользой.
Я ожидаю, что некоторые из вас скажут: "Всё это очевидно, просто возьми и сделай". Но давайте не будем забывать, что целые книги написаны о том, как правильно описывать требования и структурировать работу, существуют стандарты, но проблема всё ещё актуальна. Понимание того, что перед нами не простая задача, приходит с опытом в разработке, и именно поэтому я отношу её к категории средней сложности. Я старался изложить её как можно проще, но уверен, что ваши конструктивные комментарии помогут сделать изложение идеальным. Спасибо вам заранее за это.
Ленивый продакт: как собирать готовые идеи для развития продукта от коллег
Когда продукт входит в фазу эксплуатации, продакт-менеджер занимается его поддержкой и развитием. Для этого есть много каналов пополнения бэклога идеями: анализ запросов в поддержку, интервью с пользователями, анализ данных продуктовой аналитики, анализ конкурентов и пр. Но есть еще один, который недооценен – это сотрудники всей компании.
Меня зовут Артём Трубин, я директор продуктового портфеля в облачном провайдере ActiveCloud. Расскажу, как мы наладили пополнение продуктового бэклога идеями от коллег из разных департаментов компании, дали им почувствовать свою важность и сэкономили силы продакт-менеджеров с помощью Kaiten.
Как Agile трансформация бизнеса помогает компаниям становится гибче и быстрее и почему это актуально?
Многие основатели и ТОП-менеджеры компаний, а также те, кто отвечают за рост продуктов в компаниях, рано или поздно задумываются о том, как вырастить бизнес, увеличить продажи, получить больше лояльных пользователей, обогнать конкурентов, как сделать бизнес и продукты внутри такими чтобы их больше покупали?
- И всегда встают резонные вопросы:
- Как делать больше за меньшее количество ресурсов?
- Как успевать и обгонять конкурентов?
- Как достигать тех целей которые ставим?
- Как кратно масштабировать бизнес и продукты?
Как правило в компаниях запускается множество проектов, которые направлены на рост бизнеса, однако более 75% не приносят тех эффектов, которые мы от них ожидали. Более того, сроки и бюджеты проектов могут растягиваться в разы. И это происходит повсеместно, и в среднем и в крупном бизнесе.
Технический долг — тихий убийца
Технический долг – это термин, который вызывает тревогу в рядах IT-специалистов по всему миру. Он способен уничтожить любой успешный проект. В мире, где время – это деньги, а сроки разработки постоянно сокращаются, очень высок соблазн пойти на компромисс с качеством в погоне за поощрением руководства за скорость релизов. Но какова реальная цена этих компромиссов? Как бороться с этим невидимым врагом, который медленно но верно, подрывает все усилия по достижению прогресса?
Конфликтология в it
Конфликтология – это дисциплина, изучающая конфликты, их структуру, динамику, методы разрешения и предотвращения. В IT-сфере, как и в любой другой области, где работает множество людей с разными интересами и точками зрения, конфликты неизбежны.
Ближайшие события
Чистые трудозатраты по фиче. Миф или реальность?
На моем текущем месте работы руководство очень трепетно относится к внесению трудозатрат. Необходимость ведения трудозатрат при продуктовой разработке - вопрос дискуссионный, но кто бы что не говорил, статистические данные могут быть полезны при планировании.
Как правило, если мыслить категориями гибких методологий задачи имеют иерархическую структуру, самые крупные - эпики, своеобразные вехи продукта, которые задают направление развития. Далее идут истории / фичи - законченные фрагменты функционала представляющие ценность. Внизу иерархии располагаются уже задачи предназначенные для конкретных исполнителей (аналитиков, дизайнеров, разработчиков). С моей точки зрения наибольшую ценность представляют исторические данные от том, на сколько точно команда попадает в оценку той или иной фичи. Однако точно оценить фичу целиком очень сложно, поэтому мы оцениваем только задачи нижнего уровня.
Большинство современных систем ведения задач позволяют не только фиксировать оценки и трудозатраты по конкретным задачам, но и агрегировать оценки подзадач в задачах верхнего уровня.
И вот в какой-то момент мы обратили внимание, что несмотря на то, что мы вроде бы достаточно точно оцениваем задачи нижнего уровня агрегированные трудозатраты по фиче все равно сильно уезжают за первоначальную оценку. Причина оказалась в том, некоторые участники команды вносили трудозатраты не в задачи нижнего уровня, а непосредственно в эпики и истории, размывая тем самым показатели.
Для ведения задач в компании используется продукт JetBrains YouTrack, поэтому для решения проблемы трудозатрат списываемых в верхнеуровневые задачи было решено воспользоваться механизмом пользовательских рабочих процессов (в YouTrack можно писать свои собственные рабочие процессы на JavaScript).
Правила работы с задачами, до которых не доходят руки
Я размышлял о недавнем разговоре с руководителем одной из моих команд о важности поддерживать наши бэклоги в чистоте. Мы обсудили как поступать с задачами, которые постоянно откладываются.
Я записал свои мысли и делюсь ими с вами. Это довольно распространенная проблема. Задачи висят без движения, их всё время откладывают. В статье поговорим о последствиях такого беспорядка, и как правильно с этим справляться.
Я изложу мой подход поддержания гигиены бэклога. Поверьте мне, ваша команда будет вам за это благодарна.
Дефективное управление временем
Изначально публикация должна была называться "Гре****е управление временем", что должно символизировать боль и проблемы связанные с этой активностью. Неумение решать тучу задач это очень неприятный ком в горле, мешающий находится на волне развития. Собрал методики, статьи и материалы, которые помогают мне в моем маленьком старте исследования.
Какие важные аспекты Agile не учитывают компании?
В мире жесткой конкуренции и борьбы за опыт клиентов, многие компании сталкиваются с тем, что их операционная модель и процессы не успевают за скоростью изменений.
Поэтому многие компании стали рассматривать трансформацию своей модели управления на Agile, создавая автономные и универсальные команды сфокусированные вокруг продуктов, которые могут смотреть на метрики продукта, работать короткими итерациями и проводить много экспериментов с целью быстро улучшать ценность продукта и увеличить скорость обратной связи с рынка.
Однако вокруг массового перехода компаний на Agile сложилось поверхностное понимание и неправильная интерпретация Agile подходов и философии.
Более того, у многих компаний Agile превратился в карго-культ, который не просто не приносит ценности, а мешает.
В данной статье мы рассмотрим то, какой фундамент должен закладываться в компании, чтобы ей извлечь реальную выгоду от Agile.
Может ли Скрам-команда работать без Скрам-мастера?
В моей жизни произошло несколько событий, которые смотивировали меня создать самоорганизованную команду, которая могла бы самостоятельно следовать Скраму, соблюдать все события, эффективно работать и выполнять все задачи инкремента, не привлекая Product Owner для решения текущих проблем. Вот в таком случае мы можем говорить о Скрам-мастере как о сервисе. То есть Скрам-мастер как сервис — это когда ты приходишь в команду по какому-то запросу, помогаешь и уходишь. А команда остается одна, совсем одна, и ей должно быть абсолютно нормально. Всё так работает в идеальном мире, по крайней мере, должно так работать.
Как мы упаковали управление аджайл проектов в стандартную версию GitLab
Привет, меня зовут Анастасия, я руководитель проектов в команде разработки Ареал.
Моя ежедневная среда для управления проектами — задачник, оперативник, баг-репорт, gitlab с описаниями задач программистов, kaiten с описанием задач дизайнеров и проектировщиков. Мои коллеги сталкиваются с таким же “зоопарком” площадок, поэтому мы решили поэкспериментировать и свести управление в один инструмент — gitlab. Большинство команды знакомо с gitlab — программисты работают с кодом, проджекты ставят задачи.
Горизонтальные связи и ролевая модель большой команды
Когда коллега уходит в отпуск или увольняется — работа часто буксует или останавливается даже в большой команде. Происходит это, так как внезапно выясняется, что ушедший был «узким местом» или «критичным звеном».
Мне удалось снизить влияние этих «узких мест» и «критичных звеньев» за счёт налаживания горизонтальных связей, построения ролевой модели большой команды и ещё нескольких приёмов.
Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1.
Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.
Сейчас расскажу, как мне удалось этого добиться.
Вклад авторов
-
nmivan 524.0 -
AgileChange 258.0 -
Shapelez 206.0 -
zevvssibirix 204.0 -
romas1982 156.0 -
Superslon 145.0 -
AlexanderByndyu 140.0 -
bevzuk 136.0 -
vryashentsev 132.0 -
grumbler70 127.0