Pull to refresh
8
0

Пользователь

Send message

How to conduct a Distributed Paperless quarterly planning and not screw it up?

Reading time 10 min
Views 3.9K
Given: A company which uses the Scaled Agile Framework (SAFe) to scale Agile development across the organization; 10 development teams combined into one big team (Agile Release Train, according to SAFe terminology) to deliver a common product; the need for a two-day quarterly planning (PI Planning) to determine the work plan of IT teams for the next 3 months *; three development offices with the distance between the most remote ones exceeding 6 thousand kilometers and corresponding working time difference of 5 hours; previous planning experience which implied usage of analogue boards / whiteboards / highlighters / sticky notes and respective physical presence of all key employees in the same room.

* This heavyweight construct “The work plan of IT teams for the next 3 months” threatens to increase the size of the text significantly, so hereinafter I’m going to replace it with “the commitment”. Accordingly, to draw up and adopt a work plan will be “to commit”.

Why do we need this?


1) Fatigue with analog methods of work. While spaceships are plowing the Space, and Elon Musk is boring his tunnels, we, the IT guys, have been persistently writing with highlighters on sticky notes sticking them on the boards — there is really some kind of dissonance in this, isn’t there? That’s what our commitment looked like a while ago:

image
Read more →
Total votes 7: ↑5 and ↓2 +3
Comments 0

Как провести распределённое безбумажное квартальное планирование и не облажаться?

Reading time 10 min
Views 10K
Дано: Компания, использующая фреймворк Scaled Agile (SAFe) для масштабирования Agile-разработки в рамках всей организации; 10 команд разработки, объединённых в одну большую команду (Agile Release Train, согласно терминологии SAFe), доставляющую общий продукт; необходимость проведения двухдневного квартального планирования (PI Planning) для определения плана работы ИТ-команд на ближайшие 3 месяца*; три офиса разработки, расстояние между самыми удалёнными превышает 6 тысяч километров с соответствующей разницей в 5 часов рабочего времени; предыдущий опыт планирования, предусматривавший физическое присутствие ключевых коллег в одном помещении и использование аналоговых досок/вайтбордов/маркеров/липких бумажечек.

* Тяжеловесный конструкт “План работы ИТ-команд на ближайшие 3 месяца” грозит серьёзно увеличить объем текста, поэтому в дальнейшем я планирую вместо него писать просто – “коммитмент”. Соответственно, составить и принять план работы – “закоммититься”.

Зачем это понадобилось?


1) Усталость от аналоговых методов работы. В то время, как космические корабли бороздят просторы, а Илон Маск роет тоннели, мы, «айтишники», упорно пишем маркерами на липучих бумажках и лепим их на доски – есть в этом некий диссонанс. Так выглядел наш коммитмент некоторое время назад:
image
Читать дальше →
Total votes 17: ↑16 and ↓1 +15
Comments 3

Использование Канбана для подготовки Скрам-бэклога

Reading time 4 min
Views 14K
Предлагаю перевод небольшой статьи Андерса Абеля на волнующую меня в данный момент тему — качественный и формализованный процесс подготовки задач к передаче в разработку при условии, что разработка ведется по скраму. Если у кого-то есть опыт использования описанного данным автором подхода, итересно было бы, если бы вы поделились нюансами. Оригинал статьи: «Using Kanban for Scrum Backlog Grooming».

картинка по запросу grooming:


image

***

Поддержка бэклога в скрам-проектах – это важная задача. Он очень быстро разрастается до сотен задач, находящихся на разных стадиях готовности для включения в спринт. В моём текущем проекте мы подключили Канбан-доску для помощи в поддержке бэклога и повышения эффективности груминга.
Читать дальше →
Total votes 16: ↑14 and ↓2 +12
Comments 7

Разбиение пользовательских историй – метод гамбургера

Reading time 5 min
Views 24K
Предлагаю вашему вниманию перевод небольшой статьи Гойко Аджича на тему разделения пользовательских историй от 2012 года, с иллюстрациями и примерами автора: "Splitting User Stories: The Hamburger Method" — сделал его, в первую очередь, для себя.

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

Решение: Метод гамбургера

image
Читать дальше →
Total votes 10: ↑9 and ↓1 +8
Comments 1

Information

Rating
Does not participate
Location
Подгорица, Подгорица, Черногория
Date of birth
Registered
Activity