Менеджери в Agile проектах

Всім привіт.

Після бурхливої ??дискусії про зарплати менеджерів і девелоперів мені стало очевидно, що тема побудови горизонтальних взаємовідносин у проекті зацікавила багатьох і відхилилася від початкового русла колонки Святослава. Тому я спробую розкрити її у своїй колонці.

(Тут була картинка для привернення уваги, але я вирішив обійтися без неї).

Трохи про себе: в IT з 2001 року, колишній девелопер, перейшов у бізнес-аналітики, тому що зрозумів, що «interactions and people» мені цікавіше і важливіше «processes and tools». Зараз працюю в Люксофт України. Детальніше, кому цікаво, в LinkedIn .

Проект

Тепер про проект, в якому я зараз працюю: розробка більшої системи для clearing and settlement (C & S) угод по цінних паперах (конкретно, cash equities) в інвестиційному банку UBS Investment Bank . У деталі системи і використовує її бізнесу я не можу вдаватися через NDA, зате про процеси можу розповісти все.

Над проектом працює 120 + людина в 5 локаціях, об'єднані в 12 Scrum-командах (кількість періодично змінюється, тому що деякі команди реформуються, деякі створюються, а деякі - припиняють роботу). Розробка йде 5-й рік, 99% необхідного функціонала вже в продакшені, зараз йде фінальна «обробка напилком».

Чим наш проект цікавий і показовий? Тим, що без жорсткої вертикальної структури менеджменту він зберігає фокус спонсорів програми, показує стабільні результати з короткими циклами релізів і швидко адаптується до змін вимог.

Процес

Команди кроссфункціональни, тобто, в кожній команді є люди з скіллом BA, QA і development. Навіть якщо роль BA або QA займає виділений людина, зазвичай він/вона виконує якісь суміжні активності. Це дозволяє, по-перше, підтримувати всю команду під «включеному» стані (тобто, члени команди активно спілкуються), по-друге, підвищити Truck Number (кількість членів команди, яких потрібно «задавити вантажівкою» для припинення ефективної роботи) .

Згідно з принципами Agile Manifesto , команди спілкуються із замовником (людьми з бізнесу) безпосередньо, причому робить це не тільки бізнес- аналітик, а й усі інші члени команди під час PBR (product backlog refinement workshops).

Команди, природно, працюють за якимось планом, і цей план - product backlog (у нас їх декілька, тому що є кілька напрямків роботи по продукту). У кожного беклога є Product Owner, над кожним беклогом може працювати одночасно кілька команд. Завдання розподіляються по командам під час Joint PBR, на якому PO коротко пояснює суть пріоритетних завдань і команди по черзі розбирають їх для подальшого вивчення, уточнення вимог, взаємозалежностей і т.д.

Таким чином, до початку чергової ітерації у кожної команди є цілком актуальний sprint backlog, в якому для кожної user story є:

вимоги (причому, зібрані самою командою)
definition of done (що має бути зроблено в рамках user story)
acceptance criteria (як саме це має в результаті працювати)

З технічної точки зору якість забезпечується:

TDD і, як наслідок, 100% покриттям unit tests
активним використанням BDD і specification by example, зрозумілих бізнесу і легко транслюються в behavioural tests
працюють практиками continuous integration

А тепер про те, хто ж це все менедж.

З чотирьох типів менеджерів у нас реально є лише дві ролі:

account manager в нашій термінології називається delivery manager і займається саме обговоренням нових проектів із замовником, утрясання Рейт, people management (включаючи питання звільнення і підвищення з/п; при цьому, природно, орієнтується на фідбек колег, замовників і т. д.)
менеджер продукту - це якраз класичний Product Owner, який знає користувачів, їх пріоритети та експертів у предметній області.

В принципі, частину функцій «менеджера проекту» лежить на PO, але це стосується тільки пріоритизації вимог і, частково, їх декомпозиції (зазвичай разом з командою). Розбиття на завдання, effort estimation та оновлення burndown charts - завдання команди (з якою вони справляються). Природно, в команді є ScrumMaster, який стежить за дотриманням процесу і, в потрібний момент, може підказати команді практику для більш ефективної роботи. З іншого боку, з часом необхідність в такій ролі в більшості команд відпала по ходу їх спільної роботи.

Крім того, ми активно залучаємо зовнішніх консультантів для аналізу та покращення наших процесів (таких, як Craig Larman, Portia Tung, Gojko Adzic і т.д.). Природно, питання виділення бюджету на такі речі, так само, як і на навчання/сертифікацію/участь у конференціях вирішують спільно delivery managers з боку як Люксофт, так і UBS. Але важливим фактором, що впливає на прийняття рішень, є, знову-ж, фідбек від команд.

Детальніше про проект можна подивитися у виступі моїх колег на QCon London 2011 .

Таким чином, ми підходимо до жартівливого питання, яке я озвучив в коментарях до колонки Святослава: Чи повинен у команди бути менеджер?

Я, звичайно ж, злукавив. Менеджер у проекту (не у команди!) Бути повинен. Але от чого він не повинен робити - так це «менедж», а саме - «мікроменеджіть».

Завдання хорошого менеджера, як і хорошого, наприклад, адміна, - організувати роботу таким чином, щоб він був не потрібен у повсякденних завданнях і міг займатися більш високорівневими завданнями (для аутсорсингу - залучення нових клієнтів, для продуктових компаній - участь у стратегічному плануванні).

Як це зробити? Підбирати правильних людей, вчитися самому і вчити їх. Не шкодувати коштів на поліпшення комунікацій (від відряджень до інтерактивних дощок). Слухати команди і чути їх. Загалом, inspect and adapt!

Буду радий вислухати ваші коментарі і відповісти на питання.

Опубліковано: 19/08/11 @ 03:46
Розділ Різне

SEO Блог