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

Три мифа и три совета

Три мифа и три совета

Мне посчастливилось в этом году работать и общаться в интернациональной среде. Могу вам сказать, что почти везде, где я бываю, некий менеджер, или менеджер проекта отводит меня в сторонку со словами: «Джоанна, можно ли задать вам дурацкий вопрос?». Я всегда отвечаю, что уверена в том, что этот вопрос вовсе не дурацкий. . Этот менеджер, он или она, кивает в ответ, убежденный в том, что такая проблема есть только у него. «Все так быстро меняется. Я просто не знаю, как мне за этим угнаться, как это все контролировать. Как правильно распределить людей по проектам? Мне кажется, что не нужно постоянно переводить их с места на место, но ведь задействовать экспертов в проектах все-таки стоит, не правда ли? Оказывается, некоторые проекты не требуют постоянного участия такого количества сотрудников. Поэтому я не хочу перенасыщать такие проекты персоналом. С другой стороны, недостаток сотрудников тоже нежелателен. Иногда выиграть невозможно». Дорогие менеджеры, интуиция вас не подвела. Вы столкнулись с серьезными проблемами. Кроме того, они взаимосвязаны, поэтому давайте разберем их по очереди и снабдим вас необходимыми советами.

МИФ ПЕРВЫЙ: «Если в соответствующие моменты задействовать в проектах соответствующие ресурсы, эти проекты будут работать». 
Люди – это не ресурсы. Деньги – ресурс, письменные столы – тоже. Оснащение офиса – это ресурс. Программное обеспечение тоже может выступать в таком качестве. Ресурсы можно задействовать в другом месте, и они не станут жаловаться. Ну а люди? Люди – участники команд. Если вывести человека из одной команды и попытаться «воткнуть» его в другую, вам может очень повезти, если эта вторая команда примет его, и работа пойдет без сбоев. Однако не рассчитывайте на это. Люди – не ресурсы. Это чудесные человеческие существа, которые живут и дышат. 

СОВЕТ ПЕРВЫЙ: Обеспечьте плавность рабочего процесса внутри команд. Если ваши команды работают хорошо, это великолепно. Старайтесь сохранить их. Проекты должны задействовать всю команду и поступать в разработку по одному. Не волнуйтесь, если в командах нет экспертизы (см. Миф Второй). Люди либо выполнят работу, либо попросят помощи – но как команда. 

МИФ ВТОРОЙ: «Такая работа под силу только эксперту».
У нас в ходу множество мифов о том, что для выполнения определенной работы нужны «эксперты и только эксперты». Конечно, есть работа, которую могут выполнить только они. Реальный вопрос таков: сколько ее? Я вовсе не хочу, что разработчики стали тестерами, и наоборот. Кроме того, не жду, что дизайнеры пользовательского интерфейса превратятся в экспертов по безопасности. Однако, как менеджер проекта, я хочу, чтобы каждый участник проекта изучил его целиком и хорошо в нем разбирался. И что самое главное, эксперты должны работать вместе с другими, чтобы поделиться своими знаниями.

СОВЕТ ВТОРОЙ: Никогда не позволяйте экспертам работать в одиночку. 
Когда эксперты работают в своих областях экспертизы, я всегда прошу их объединиться в пары не-экспертами. Если они отказались, я переводила их в другой проект, где экспертизы у них нет. Держу пари, кто-то наверняка считает меня сумасшедшей. Но вот почему я так поступаю. Если эксперт продолжает работать в вашей организации над другим проектом, он все равно вам доступен. Если же он выиграл лотерею и находится на Фиджи, наслаждаясь там коктейлями с зонтиками, он вам недоступен. Когда вы захотите проводить экспертизу? Я хочу проводить ее в условиях доступности эксперта. Готова биться об заклад, что некоторые из вас, менеджеры, обеспокоены ритмом проекта. Ну что ж, удалив из команды эксперта, вы увидите забавную вещь. Команда объединяется и работает как единое целое, а не как разобщенная группа людей. Хотите, чтобы команда работала быстрее? Удалите из нее экспертов. Команда будет работать вместе, и люди быстро поймут, чего они не знают. А тем, что они знают хорошо, они поделятся с вами. 

МИФ ТРЕТИЙ: «Это проект для одного человека». 
Вам кажется, что этот проект действительно небольшой. Похоже, что один человек справится с ним за несколько месяцев. Не попадайтесь на это! Такой вещи, как «проект для одного человека» просто нет. Разработчику нужно общаться с заказчиком или человеком, отвечающим за соблюдение требований заказчика. Разработчику может понадобиться помощь в развертывании проекта, или же ему нужна помощь DBA, или небольшое тестирование. Дело здесь в том, что разработка программного обеспечения - это социальная проблема. Даже интровертам нужно проговаривать некоторые вещи, а еще вероятнее – прорабатывать проблемы с другим человеком.

СОВЕТ ТРЕТИЙ: Всегда ставьте на проект двоих сотрудников. 
Если вы всегда ставите на проект двоих сотрудников, они работают в паре. Они могут протестировать друг у друга коды, обменяться идеями, помочь друг другу в развертывании. Если им непонятно, почему что-то не работает, они могут оказать друг другу моральную поддержку. Поэтому никогда не попадайтесь на удочку мифа о «проекте для одного человека».

Перевод с английского, автор оригинальной статьи - Джоанна Ротман

ПОПУЛЯРНОЕ

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

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


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

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

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


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

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

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

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


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

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

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

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

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



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

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