К основному контенту

Аджайл Менеджер Проектов – кто это?

Автор: Карлтон Неттлетон (Carlton Nettleton)
Переведено с английского проектом Agile Translations.



Несколько недель назад я получил сообщение от своего бывшего ученика с печальными новостями – его компания уволила всех Скрам-мастеров и заменила их на “Аджайл Менеджеров Проектов”. Теперь он остался без работы, а Cкрам потерпел серьезную неудачу в их организации. Это было довольно грустно :(

Когда я первый раз прочитал это сообщение, я задался вопросом: "А кто же такие Аджайл Менеджеры Проектов?” Поэтому я решил поискать различные статьи о том, когда этот термин появился (примерно в начале 2008) и почему компании отдают предпочтение им, а не Скрам-мастерам.

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

Лично я никогда не понимал, почему кто-то вообще берет на себя такую ответственность. Обычно менеджеры проекта не занимаются непосредственно разработкой, так как они могут отвечать за качество или сроки? Менеджеры проекта не определяют бизнес-цели, так как они реально могут управлять границами проекта? И должны ли они в принципе принимать решения по границам проекта, если бизнес-область подвержена постоянным стремительным изменениям? Менеджеры проекта обычно не являются функциональными менеджерами, так как они могут отвечать за персонал или его производительность? Я понимаю, что, возможно, Институт управления проектами (PMI) хочет определить роль менеджера проекта именно так, но я тоже много чего хочу, например, чтобы у меня был пони, но это не значит, что я действительно собираюсь его покупать.

Из своего опыта, я склонен считать, что менеджеры проекта и Скрам часто взимоисключают друг друга. Если вы читали Кена Швабера, то он говорит нам о том, что менеджеры проекта нарочно не были добавлены в Скрам. По его мнению, менеджеры проекта пагубно влияют на умственную работу, а также снижают творческий потенциал и интеллект команды (мне кажется, я слышу дружное “Гип-гип-ура!” от людей, поддерживающих данное высказывание, и не менее дружное “Что за бред!” от людей, которые не согласны с Кеном). Строгое следование определению менеджера проекта по версии PMI, скорее всего сделает из менеджера либо человека, который говорит людям, как нужно делать их работу, либо няньку для проектной команды. Оба варианта крайне негативно воспринимаются высококвалифицированными профессионалами и сводят на нет уважение, доверие и самоорганизацию в команде, а также принятие командой обязательств и фокусирование на главном. Когда люди говорят мне, что их компания сократила Скрам-мастеров в пользу Аджайл Менеджеров Проектов, то мне становится очевидно, что в компании хотят обозначить одного определенного человека, которого можно обвинить в случае неудачи проекта.

Разумеется, было бы хорошо посмотреть на схему, увидеть чье-то имя в рамке наверху пирамиды и сказать “Конечно же … Карлтон. Вот причина провала проекта – плохой менеджер.” Это было бы просто замечательно (также, как и иметь пони), но далеко не всегда это соответствовало бы истине. Проекты терпят неудачу по многим причинам. Среди них довольно много факторов, которые я называю начальными условиями проекта: как был начат проект (нехватка времени или ресурсов), отсутствие доступа к лицам, уполномоченным принимать решения, или организационные ограничения, такие, как бюрократия и ориентированность на неудачи.

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


Переведено с английского проектом Agile Translations  
Алина Проскурина, Дарья Ершова, Тимофей Евграшин

Оригинальная статья: "What is an Agile Project Manager?"  by Carlton Nettleton

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations


Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко.


Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности.

Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь):
«Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы приблизиться…

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn)
Перевод с английского


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

Какие проекты лучше всего подходят для применения Agile

Автор: Майк Кон (Mike Cohn)
Переведено с английского проектом Agile Translations.



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

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

Об agile по-русски: User Stories, часть 1

«Разработка ПО - это игра изобретательности и кооперации»
Элистер Коуберн (1)
О чем эта статья? Это одна из статей серии «Про agile по-русски» (см. сноску внизу про значение термина «agile»), идея которых поделиться опытом использования agile принципов (2) в разработке программного обеспечения. Основная суть этих подходов – кооперация между всеми членами проекта и адаптивность процесса разработки к неизбежным изменениям. Также важным аспектом Agile является принятие человеческого фактора в проекте как неотъемлемой части и более того – как наиважнейшей причиной прогресса. Agile акцентирует важность поддержания человеческих отношений и учета человеческих особенностей для успеха проекта.Эта статья рассказывает о применении «userstories» («пользовательских историй») - одной из практик agile. Далее для краткости я буду называть их просто «историями». Для кого эта статья? Эта статья для профессионалов по разработке программного обеспечения: менеджеров продуктов, менеджеров верхнего и среднег…