Как стать автором
Обновить
36.2

Agile *

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

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

Спринт с багами, или как (не) создать себе проблем

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

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

Читать далее
Всего голосов 15: ↑10 и ↓5 +5
Комментарии 22

Новости

Передача контекста и знаний в IT команде

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

Всем привет и добро пожаловать! Данная статья не является научной и не относится к разряду технических, она больше про коммуникации и командные процессы в IT. Это попытка систематизировать реальные практики по передаче контекста и знаний в IT команде, показать их актуальность и важность. Я уверен, что про что‑то из статьи вы уже слышали, видели, читали, или даже сами использовали. И для начала давайте определим основные понятия.

Контекст — совокупность различных факторов и/или сведений, необходимых для понимания или объяснения какого‑либо явления действительности.

Знание — проверенный практикой результат познания, то есть научные сведения, которые были проверены практикой и отражены в сознании человека.

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

С контекстом, на мой взгляд, всё сложнее. Контекст — это не то, что вы можете изучить где‑то, прочитать статью, пройти курсы. Контекст плотно привязан к историческому наследию компанию. Это из разряда «так исторически сложилось». Я думаю, вам приходилось слышать эту фразу. Но даже в компании контекст от команды к команде может сильно отличаться, для каждой команды контекст тоже уникален.

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

Читать далее
Всего голосов 10: ↑8 и ↓2 +6
Комментарии 0

Методы декомпозиции функциональности приложения

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

Одной из важных стадий формирования UX (User experience) диджитал-продукта является релиз MVP (Minimal Viable Product, он же минимально жизнеспособный продукт). Эта такая версия вашего приложения или программы, которая подразумевает минимальное количество реализованных в продукте функций, достаточное при этом для формирования пользовательского опыта и фидбека. Это помогает понять, устраивают ли пользователей имеющиеся функции и как его улучшить.

Однако даже после выделения MVP оставшиеся функции могут оказаться многосоставными - раскладывающимися на более мелкие. Отличный метод декомпозиции функциональности — картирование пользовательских историй (User Story Mapping).

Читать далее
Всего голосов 3: ↑3 и ↓0 +3
Комментарии 0

Книга «Жемчужины разработки. Чему мы научились за 50 лет создания ПО»

Время на прочтение 16 мин
Количество просмотров 3.3K
imageПривет, Хаброжители!

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

Опыт — главный учитель, но медленный и нередко болезненный. Но зачем же нам повторять ошибки? Книга «Жемчужины разработки» поможет совершенствоваться быстрее и избежать многих проблем, обучаясь на опыте других людей, которые уже поднялись по кривой обучения. Карл Вигерс сформулировал 60 кратких практических уроков, которые подойдут для любых проектов, независимо от роли, отрасли, технологии или методологии.

Идеи и конкретные рекомендации охватывают шесть важнейших элементов успеха: требования, дизайн, управление проектами, культуру и командную работу, качество и совершенствование процессов. Для каждого из направлений Вигерс предлагает «первые шаги», позволяющие осмыслить собственный опыт, уроки с основными идеями, реальными примерами и действенными решениями и «следующие шаги» для внедрения опыта в вашем проекте, команде или организации. Эти знания нельзя получить в университете!
Читать дальше →
Всего голосов 15: ↑13 и ↓2 +11
Комментарии 7

Истории

Как провести PI-планирование на 100+ человек: от глобальных целей до точечных задач

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

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

Привет, Хабр! Я Ирина Бобрихина, один из скрам-мастеров IT-компании RDP. Хочу поделиться подробным кейсом проведения PI-планирования в крупной компании с помощью сервиса Kaiten.

Ещё больше интересных материалов читайте в нашем блоге.

Читать далее
Всего голосов 11: ↑10 и ↓1 +9
Комментарии 4

User Story Mapping или Карты Пользовательских сценариев

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

User Story Mapping или КАРТЫ ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ - это способ визуального планирования и приоритизации задач. Способ хорош тем, что заставляет нас думать о своих software решениях с позиции ПОЛЬЗОВАТЕЛЬСКИХ ИСТОРИЙ(User Story).

Прежде чем мы перейдём к знакомству с методом, важно разобраться с тем, а что такое вообще ПОЛЬЗОВАТЕЛЬСКАЯ ИСТОРИЯ.

Читать далее
Всего голосов 7: ↑7 и ↓0 +7
Комментарии 2

Портфель ИТ-проектов: учимся управлять не формально, а эффективно

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

Поделюсь личным опытом работы в ИТ-компании, использующей проектное управление. Постараюсь выделить важные вещи в эффективной работе, которые, на первый взгляд,как будто не видны и с которыми пришлось столкнуться. Углубляться в project managment не имею цели. Для этого существуют стандарты PMI The Standard for Portfolio Management, ГОСТ Р 54870-2011 «Требования к управлению портфелем проектов». Хотелось бы отметить, что работаю в госсекторе, но возможно опыт будет полезен всем.

Немного о себе. Петряшова Оксана Николаевна - 5 лет руководитель отдела развития, с большим багажом опыта.  Всё  нижесказанное является личным  опытом и субъективным мнением.

Читать далее
Всего голосов 10: ↑7 и ↓3 +4
Комментарии 4

Как построить дом по Agile. Пример успешного применения гибкой методологии для самого классического Waterfall-проекта

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

Хочется начать с тезиса: все методологии хороши, главное – правильно их применять. Однако несмотря на все усилия, я все еще встречаю скепсис у технических специалистов и иногда бизнеса, что Agile методологии не применимы к большим и сложным проектам. Фразы из серии «давайте сначала все продумаем», «у вас не будет второго шанса произвести первое впечатление», «мы не принесем ценности пока не сделаем все фичи», «UI/UX должен быть самый лучший на старте» все еще звучат, и данная статья в легкой форме покажет, что они не всегда актуальны 😊

Меня зовут Сергей Солдатов, я занимаюсь развитием продуктов в ЕДИНОМ ЦУПИС, поэтому статья будет построена в плоскости управления продуктом, но, надеюсь, будет интересна и техническим специалистам, командным лидам, проектным менеджерам и возможно тем, кто планирует строительство дома 😊

Еще один важный момент: моя дорожная карта не подразумевает привязки ко времени, так как в моем рассказе важнее ключевые этапы развития продукта (дом), определение MVP и масштабирование, а дедлайны оставим к темам KPI и построения временных планов.

Читать далее
Всего голосов 11: ↑8 и ↓3 +5
Комментарии 33

Когда говорят 'Сделай хорошо': Рекомендации для разработчиков по улучшению процесса

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

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

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

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

Читать далее
Всего голосов 7: ↑4 и ↓3 +1
Комментарии 4

Ленивый продакт: как собирать готовые идеи для развития продукта от коллег

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

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

Меня зовут Артём Трубин, я директор продуктового портфеля в облачном провайдере ActiveCloud. Расскажу, как мы наладили пополнение продуктового бэклога идеями от коллег из разных департаментов компании, дали им почувствовать свою важность и сэкономили силы продакт-менеджеров с помощью Kaiten.

Читать далее
Всего голосов 10: ↑9 и ↓1 +8
Комментарии 2

Как Agile трансформация бизнеса помогает компаниям становится гибче и быстрее и почему это актуально?

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

Многие основатели и ТОП-менеджеры компаний, а также те, кто отвечают за рост продуктов в компаниях, рано или поздно задумываются о том, как вырастить бизнес, увеличить продажи, получить больше лояльных пользователей, обогнать конкурентов, как сделать бизнес и продукты внутри такими чтобы их больше покупали?

- И всегда встают резонные вопросы:
- Как делать больше за меньшее количество ресурсов?
- Как успевать и обгонять конкурентов?
- Как достигать тех целей которые ставим?
- Как кратно масштабировать бизнес и продукты?

Как правило в компаниях запускается множество проектов, которые направлены на рост бизнеса, однако более 75% не приносят тех эффектов, которые мы от них ожидали. Более того, сроки и бюджеты проектов могут растягиваться в разы. И это происходит повсеместно, и в среднем и в крупном бизнесе. 

Читать далее
Всего голосов 14: ↑9 и ↓5 +4
Комментарии 4

Технический долг — тихий убийца

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

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

Читать далее
Всего голосов 8: ↑6 и ↓2 +4
Комментарии 7

Конфликтология в it

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

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

Читать далее
Всего голосов 12: ↑8 и ↓4 +4
Комментарии 4

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

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн

Чистые трудозатраты по фиче. Миф или реальность?

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

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

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

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

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

Для ведения задач в компании используется продукт JetBrains YouTrack, поэтому для решения проблемы трудозатрат списываемых в верхнеуровневые задачи было решено воспользоваться механизмом пользовательских рабочих процессов (в YouTrack можно писать свои собственные рабочие процессы на JavaScript).

Читать далее
Всего голосов 6: ↑3 и ↓3 0
Комментарии 5

Правила работы с задачами, до которых не доходят руки

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

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

Я записал свои мысли и делюсь ими с вами. Это довольно распространенная проблема. Задачи висят без движения, их всё время откладывают. В статье поговорим о последствиях такого беспорядка, и как правильно с этим справляться.

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

Читать далее
Всего голосов 30: ↑26 и ↓4 +22
Комментарии 37

Дефективное управление временем

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

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

Потратить время
Всего голосов 11: ↑10 и ↓1 +9
Комментарии 7

Какие важные аспекты Agile не учитывают компании?

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

 

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

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

Однако вокруг массового перехода компаний на Agile сложилось поверхностное понимание и неправильная интерпретация Agile подходов и философии. 

Более того, у многих компаний Agile превратился в карго-культ, который не просто не приносит ценности, а мешает.

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

Читать далее
Всего голосов 17: ↑13 и ↓4 +9
Комментарии 10

Может ли Скрам-команда работать без Скрам-мастера?

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

В моей жизни произошло несколько событий, которые смотивировали меня создать самоорганизованную команду, которая могла бы самостоятельно следовать Скраму, соблюдать все события, эффективно работать и выполнять все задачи инкремента, не привлекая Product Owner для решения текущих проблем. Вот в таком случае мы можем говорить о Скрам-мастере как о сервисе. То есть Скрам-мастер как сервис — это когда ты приходишь в команду по какому-то запросу, помогаешь и уходишь. А команда остается одна, совсем одна, и ей должно быть абсолютно нормально. Всё так работает в идеальном мире, по крайней мере, должно так работать.

Читать далее
Всего голосов 28: ↑14 и ↓14 0
Комментарии 29

Как мы упаковали управление аджайл проектов в стандартную версию GitLab

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

Привет, меня зовут Анастасия, я руководитель проектов в команде разработки Ареал. 

Моя ежедневная среда для управления проектами — задачник, оперативник, баг-репорт, gitlab с описаниями задач программистов, kaiten с описанием задач дизайнеров и проектировщиков. Мои коллеги сталкиваются с таким же “зоопарком” площадок, поэтому мы решили поэкспериментировать и свести управление в один инструмент — gitlab. Большинство команды знакомо с gitlab — программисты работают с кодом, проджекты ставят задачи. 

Читать далее
Всего голосов 6: ↑4 и ↓2 +2
Комментарии 1

Горизонтальные связи и ролевая модель большой команды

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

Когда коллега уходит в отпуск или увольняется — работа часто буксует или останавливается даже в большой команде. Происходит это, так как внезапно выясняется, что ушедший был «узким местом» или «критичным звеном».

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

Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1.

Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.

Сейчас расскажу, как мне удалось этого добиться.

Читать далее
Всего голосов 16: ↑14 и ↓2 +12
Комментарии 9

Вклад авторов