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

Гибкая команда разработчиков – это группа многофункциональных специалистов, которые могут работать с любой функцией, которую желает получить клиент, и превратить ее в готовый, рабочий программный компонент. В состав команды входят аналитики, разработчики, тестировщики, администраторы баз данных и все остальные специалисты, которые нужны для превращения пользовательских историй в программу, готовую для реального использования.
Как бы я ни обожал тот дух и те принципы, на основе которых работает гибкая команда, не имеющая формально распределенных ролей, должен признаться, что попытка пригласить глубоко консервативную команду разработчиков и сообщить ее членам, что им нужно «самоорганизоваться», на практике у меня никогда не срабатывала.
Чтобы чувствовать себя уверенно, нужна точность формулировок. Надо сразу ясно сказать, что в гибкой команде границы между отдельными ролями размыты и что от каждого участника требуется умение сражаться на нескольких фронтах. Но мне лучше удавалось придавать коллективам нужный вид, если я объяснял им гибкую методологию в понятных им выражениях.
Если ваша команда именно такая, то обратите внимание на следующие описания гибких ролей, которые помогут людям адаптироваться к новым условиям и понять, как изменятся их роли в гибком проекте.
Гибкий аналитик

Когда мы приступаем к разработке определенной функции, кто-то должен досконально с ней разобраться и описать все тончайшие детали ее работы. Это задача нашего гибкого аналитика.
Аналитик похож на неутомимого сыщика, задающего глубокие зондирующие вопросы и при этом испытывающего кайф от тесного сотрудничества с клиентом. В ходе совместной работы они пытаются понять, что же нужно от программы.
Аналитик выполняет в гибком проекте множество задач: помогает клиенту писать пользовательские истории (см. главу 6); выполняет глубокий анализ, когда дело доходит до разработки; помогает создавать имитационные объекты (mock-ups) и прототипы; использует в ходе анализа все доступные ему инструменты, чтобы донести до разработчика сущность пользовательских историй.
Подробнее о функционировании гибкого анализа мы поговорим в разделе 9.4.
Гибкий программист

Пока не написан код, все сводится только к конструктивным намерениям. Написанием кода занимаются наши гибкие программисты.
Гибкий программист – это профессионал, так как он очень серьезно относится к качеству программы. Лучшие из таких программистов одновременно являются увлеченными тестировщиками, гордящимися своей работой и всегда старающимися написать максимально качественный код.
Поэтому существуют определенные вещи, без которых не обойтись программистам, желающим регулярно создавать отличные многофункциональные продукты.
♦ Они пишут много тестов и часто пользуются ими при разработке (см. главы 12 и 14).
♦ Они постоянно дорабатывают и оптимизируют архитектуру программы по мере работы (см. главу 13).
♦ Они уверены, что базовый код всегда готов к использованию и может быть развернут по первому требованию (см. главу 15).
Программист также тесно сотрудничает с клиентом и другими членами команды и гарантирует, что написанный код работает, что он максимально прост и что внедрение программы для практического использования не составит никакого труда.
Гибкий тестировщик

Гибкие тестировщики знают, что одно дело – написать продукт, а другое – гарантировать, что он работает. Поэтому такой тестировщик подключается к проекту уже на ранних этапах, заблаговременно обеспечивая успешное выполнение пользовательских историй и то, что программа, запущенная в практическую работу, действительно не подведет.
Поскольку в гибком проекте тестировать нужно буквально все, ни один этап работы не обойдется без участия тестировщика. Он будет работать бок о бок с клиентом, помогая ему оформить предъявляемые требования в виде тестов.
Что, если начинать каждый проект вот так?
Предположим, в начале каждого проекта вы вместе с командой пытаетесь ответить на четыре простых вопроса о себе.
• В чем я особенно хорош?
• Как я привык работать?
• Что я ценю?
• Каких результатов можно от меня ожидать?
Затем, получив новые идеи, задайте те же вопросы коллегам, чтобы они рассказали вам, в чем они хороши, как работают, что ценят и какой результат могут выдать.
Читать дальшеИнтервал:
Закладка: