Гибкое управление IT-проектами. Руководство для настоящих самураев. Джонатан Расмуссон
Читать онлайн книгу.выполняет в гибком проекте множество задач: помогает клиенту писать пользовательские истории (см. главу 6); выполняет глубокий анализ, когда дело доходит до разработки; помогает создавать имитационные объекты (mock-ups) и прототипы; использует в ходе анализа все доступные ему инструменты, чтобы донести до разработчика сущность пользовательских историй.
Подробнее о функционировании гибкого анализа мы поговорим в разделе 9.4.
Гибкий программист
Пока не написан код, все сводится только к конструктивным намерениям. Написанием кода занимаются наши гибкие программисты.
Гибкий программист – это профессионал, так как он очень серьезно относится к качеству программы. Лучшие из таких программистов одновременно являются увлеченными тестировщиками, гордящимися своей работой и всегда старающимися написать максимально качественный код.
Поэтому существуют определенные вещи, без которых не обойтись программистам, желающим регулярно создавать отличные многофункциональные продукты.
♦ Они пишут много тестов и часто пользуются ими при разработке (см. главы 12 и 14).
♦ Они постоянно дорабатывают и оптимизируют архитектуру программы по мере работы (см. главу 13).
♦ Они уверены, что базовый код всегда готов к использованию и может быть развернут по первому требованию (см. главу 15).
Программист также тесно сотрудничает с клиентом и другими членами команды и гарантирует, что написанный код работает, что он максимально прост и что внедрение программы для практического использования не составит никакого труда.
Гибкий тестировщик
Гибкие тестировщики знают, что одно дело – написать продукт, а другое – гарантировать, что он работает. Поэтому такой тестировщик подключается к проекту уже на ранних этапах, заблаговременно обеспечивая успешное выполнение пользовательских историй и то, что программа, запущенная в практическую работу, действительно не подведет.
Поскольку в гибком проекте тестировать нужно буквально все, ни один этап работы не обойдется без участия тестировщика. Он будет работать бок о бок с клиентом, помогая ему оформить предъявляемые требования в виде тестов.
Что, если начинать каждый проект вот так?
Предположим, в начале каждого проекта вы вместе с командой пытаетесь ответить на четыре простых вопроса о себе.
• В чем я особенно хорош?
• Как я привык работать?
• Что я ценю?
• Каких результатов можно от меня ожидать?
Затем, получив новые идеи, задайте те же вопросы коллегам, чтобы они рассказали вам, в чем они хороши, как работают, что ценят и какой результат могут выдать.
Эта идея называется упражнением Друкера[4]. При всей простоте оно очень помогает сплотить команду, наладить необходимую коммуникацию и уровень доверия, необходимый для любой высокопроизводительной команды.
Тестировщик будет тесно
4
http://agilewarrior.wordpress.com/2009/11/27/the-drucker-exercise.