Джонатан Расмуссон - Гибкое управление IT-проектами. Руководство для настоящих самураев
- Название:Гибкое управление IT-проектами. Руководство для настоящих самураев
- Автор:
- Жанр:
- Издательство:Array Издательство «Питер»
- Год:2012
- Город:Санкт-Петербург
- ISBN:978-5-459-01205-7
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Джонатан Расмуссон - Гибкое управление IT-проектами. Руководство для настоящих самураев краткое содержание
«Руководство для настоящих самураев» обходится без лишней теории, из-за которой другие книги совсем не отвечают духу гибкости. Она полна испытанных методов, невыдуманных историй, приятного юмора и прикладных упражнений-руководств, которые помогут вам делать правильные вещи наилучшим способом.
Гибкое управление IT-проектами. Руководство для настоящих самураев - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Командные игроки, умеющие подавлять свое эго
Звучит избито, но для гибкой разработки лучше подойдут люди, которые умеют работать слаженно и подавлять собственное эго.
Не всем по вкусу расплывчатость ролей, принятая в гибкой методологии. Некоторые люди стараются защищать область, которую считают своей епархией.
Просто ищите тех, кто не имеет противоречий с самим собой, не боится делиться знаниями и искренне наслаждается взаимным обучением и ростом.

УЧЕНИК: Мастер, я запутался. Если в гибком проекте нет предопределенных ролей, то как же он работает?
МАСТЕР: Команда сделает то, что должно быть сделано.
УЧЕНИК: О да, Мастер, но если нет специальной роли тестировщика, как можно быть уверенным, что все необходимые тесты будут проведены?
МАСТЕР: Без тестирования никак не обойтись, поэтому команда будет им заниматься. Команда решает, сколько нужно тестов и сколько сил на это потратить.
УЧЕНИК: А если никто не хочет заниматься тестированием? Что, если всем нравится просто сидеть и писать код?
МАСТЕР: Тогда нужно найти людей, которым нравится тестировать, и самому убедиться, какими ценными членами твоей команды они станут.
УЧЕНИК: Благодарю тебя, Мастер. Я подумаю над этим.
Что дальше?
Мы рассмотрели, как в гибких проектах исчезают четкие границы между ролями, почему команда будет работать наиболее успешно, если все соберутся в одном месте, и как, подыскивая людей в команду, находить специалистов-универсалов и тех, кто не боится неопределенности.
Теперь мы готовы сделать, пожалуй, один из важнейших шагов, чтобы отправить наш гибкий проект в свободное плавание. Поговорим об этапе, о котором почти ничего не сказано в большинстве гибких методологий, – как зарождается гибкий проект.
Из второй части книги вы узнаете, как с самого начала сориентировать свой проект на путь к успеху и гарантировать, что вы подобрали для работы нужных людей.
Часть II
Концептуализация проекта при гибкой разработке
Глава 3
Главное – никого не забыть

Многие проекты умирают в зачаточном состоянии. Обычно это происходит по одной из следующих причин:
♦ неумение задавать правильные вопросы;
♦ боязнь задавать сложные вопросы.
В этой части мы поговорим о мощной методике построения перспектив, которую условно назовем стартовой колодой (inception deck). Она помогает найти ответы на 10 вопросов, без которых лучше не начинать какой-либо софтверный проект. Испытав команду на данном этапе, вы узнаете, все ли нужные люди подобраны для проекта и в правильном ли направлении вы движетесь. Это произойдет еще до написания самой первой строки кода.
3.1. Из-за чего погибает большинство проектов
В начале любого нового проекта люди обычно имеют поразительно разные представления об общей цели.

Для проектов это может быть губительно. Ведь, хотя мы и описываем наше видение общего дела на одном и том же языке, стоит нам приступить к работе – и мы понимаем, что думали о совершенно разных вещах.
И проблема не в том, что нам не удалось прийти к общему мнению уже на старте (это естественно). Проблема в том, что проекты начинаются еще до того , как найдены все нужные люди.
Ошибочное мнение о том, что консенсус достигнут там, где его нет и в помине, губит большинство проектов.
Нам нужно сформулировать план, который:
♦ позволяет сообщить команде цели, суть проблемы и контекст, в котором реализуется проект, так, чтобы при работе сотрудники могли принимать осознанные решения;
♦ предоставляет владельцам информацию, помогающую им решить, браться или не браться за дело, начинать проект или нет.

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

Как видите, начиная любое новое дело (то есть проект), вы имеете большой простор для постановки вопросов и при этом ничего не теряете. Можно задавать общие вопросы, например, как приведенные ниже.
♦ Насколько опытна ваша команда?
♦ Занимались ли вы такими вещами ранее?
♦ Сколько денег у нас в распоряжении?
♦ Кто отдает приказы в этом проекте?
♦ Не смущает ли вас ситуация, когда в проекте участвуют два аналитика и тридцать разработчиков?
♦ Перечислите проекты, для работы над которыми вам пришлось пригласить команду молодых специалистов, практически незнакомых с объектно-ориентированным программированием, и успешно переделать устаревшую систему мейнфрейма для работы с Ruby on Rails – и сделать все это с помощью гибкой методологии.
Такие же вопросы необходимо задавать при запуске гибкого проекта. Нужно прояснить все щекотливые моменты с самого начала. Это нужно делать на этапе концептуализации проекта.
3.3. Знакомство со стартовой колодой

На этом уровне мы словно включаем прожектор, рассеивающий неясность и таинственность, окружающие ваш гибкий проект. Здесь мы прорабатываем 10 сложных вопросов и ситуаций, которые просто необходимо разрешить еще до начала проекта.
В компании ThoughtWorks такой подход часто используется для анализа той части первичных работ над проектом, о которой практически ничего не говорится ни в экстремальном программировании, ни в скраме. Речь идет о закладке проекта (project chartering). Мы знали, что глубокий шестимесячный анализ и упражнения в сборе требований нам не подходят, но не могли придумать какую-нибудь более легковесную альтернативу. И именно в таких условиях Робину Гиббонсу пришла в голову мысль о стартовой колоде: быстром, легком способе извлечения из проекта самой его сути и рассказа об общем понимании задачи всей команде и другим участникам проекта.
Читать дальшеИнтервал:
Закладка: