» » » » Джонатан Расмуссон - Гибкое управление IT-проектами. Руководство для настоящих самураев


Авторские права

Джонатан Расмуссон - Гибкое управление IT-проектами. Руководство для настоящих самураев

Здесь можно купить и скачать "Джонатан Расмуссон - Гибкое управление IT-проектами. Руководство для настоящих самураев" в формате fb2, epub, txt, doc, pdf. Жанр: Управление, подбор персонала, издательство Издательство «Питер»046ebc0b-b024-102a-94d5-07de47c81719, год 2012. Так же Вы можете читать ознакомительный отрывок из книги на сайте LibFox.Ru (ЛибФокс) или прочесть описание и ознакомиться с отзывами.
Джонатан Расмуссон - Гибкое управление IT-проектами. Руководство для настоящих самураев
Рейтинг:
Название:
Гибкое управление IT-проектами. Руководство для настоящих самураев
Издательство:
неизвестно
Год:
2012
ISBN:
978-5-459-01205-7
Вы автор?
Книга распространяется на условиях партнёрской программы.
Все авторские права соблюдены. Напишите нам, если Вы не согласны.

Как получить книгу?
Оплатили, но не знаете что делать дальше? Инструкция.

Описание книги "Гибкое управление IT-проектами. Руководство для настоящих самураев"

Описание и краткое содержание "Гибкое управление IT-проектами. Руководство для настоящих самураев" читать бесплатно онлайн.



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

«Руководство для настоящих самураев» обходится без лишней теории, из-за которой другие книги совсем не отвечают духу гибкости. Она полна испытанных методов, невыдуманных историй, приятного юмора и прикладных упражнений-руководств, которые помогут вам делать правильные вещи наилучшим способом.






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

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

Кто унес мой сыр?

«Кто унес мой сыр?» (Who Moved My Cheese? [Joh98]) – это бизнес-притча о мышах, которые проснулись однажды утром и обнаружили, что большой кусок сыра, вокруг которого им вольготно жилось, куда-то исчез. Его унесли. И теперь мыши в растерянности размышляли, что делать.

Кому-то переход к гибкой разработке может показаться таким отлучением от сыра.

Аналитик, переходящий к гибкому проекту, осознает, что этап анализа никогда не закончится.

Разработчик должен быть готов к тому, что ему придется писать тесты (и немало!).

То есть нужно понимать, что, предлагая людям работать в таком режиме, вы отбираете у кого-то сыр. И все, что вы можете для них сделать, – помочь им найти новый сыр (показать, как должны измениться их роли).

Разумеется, основным достоинством многофункциональной команды является скорость, с которой она способна работать. Ей не нужно ждать одобрения или договариваться о ресурсах с другими отделами, а можно с первого же дня начинать работу, не останавливая ее ни на день.

Конечно, вы должны обрисовать людям, чего от них ожидаете, и рассказать о результатах, которых хотите добиться, набирая свою команду.

А теперь поговорим о ролях.

2.3. Роли, которые встречаются в типичной команде

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



Если у вас возникает вопрос: «А где все программисты, тестировщики и аналитики?» – не волнуйтесь, они никуда не исчезли. Просто при гибкой разработке не так важно, кто именно играет конкретные роли.


Начнем с рассмотрения самой важной роли в гибком проекте – клиента.


Клиент гибкого проекта



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

В идеале клиент должен ориентироваться в теме проекта. Это человек, глубоко погруженный в дело, ему действительно небезразлично, что делает программа, как она выглядит и функционирует. Кроме того, он с энтузиазмом направляет команду, отвечает на вопросы, словом, проявляет отдачу.

Кроме того, клиент устанавливает приоритеты. Он решает, что нужно создать и когда.

Все это не происходит в вакууме. Речь идет о совместной работе с командой разработчиков, ведь могут быть технические причины, по которым целесообразно сделать сначала одни элементы, а потом другие (иными словами, снизить технологический риск).

Однако обычно приоритеты расставляются с точки зрения бизнеса, а затем начинается работа с командой, которой нужно выполнить намеченный план, чтобы все получилось.

И именно клиентам приходится принимать решения относительно того, без чего можно обойтись, если поджимают сроки и начинают заканчиваться деньги.

Разумеется, чтобы все это получилось, требуется очень тесное сотрудничество клиента с командой (в идеале – в течение всего рабочего дня). В ранних версиях экстремального программирования было принято говорить о «заказчике в команде» (on-site customer). В скраме аналогичная роль называется «владелец продукта» (product owner).

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

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

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

Теперь поговорим о команде разработчиков.


Команда разработчиков



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

Как бы я ни обожал тот дух и те принципы, на основе которых работает гибкая команда, не имеющая формально распределенных ролей, должен признаться, что попытка пригласить глубоко консервативную команду разработчиков и сообщить ее членам, что им нужно «самоорганизоваться», на практике у меня никогда не срабатывала.

Чтобы чувствовать себя уверенно, нужна точность формулировок. Надо сразу ясно сказать, что в гибкой команде границы между отдельными ролями размыты и что от каждого участника требуется умение сражаться на нескольких фронтах. Но мне лучше удавалось придавать коллективам нужный вид, если я объяснял им гибкую методологию в понятных им выражениях.

Если ваша команда именно такая, то обратите внимание на следующие описания гибких ролей, которые помогут людям адаптироваться к новым условиям и понять, как изменятся их роли в гибком проекте.


Гибкий аналитик



Когда мы приступаем к разработке определенной функции, кто-то должен досконально с ней разобраться и описать все тончайшие детали ее работы. Это задача нашего гибкого аналитика.

Аналитик похож на неутомимого сыщика, задающего глубокие зондирующие вопросы и при этом испытывающего кайф от тесного сотрудничества с клиентом. В ходе совместной работы они пытаются понять, что же нужно от программы.

Аналитик выполняет в гибком проекте множество задач: помогает клиенту писать пользовательские истории (см. главу 6); выполняет глубокий анализ, когда дело доходит до разработки; помогает создавать имитационные объекты (mock-ups) и прототипы; использует в ходе анализа все доступные ему инструменты, чтобы донести до разработчика сущность пользовательских историй.

Подробнее о функционировании гибкого анализа мы поговорим в разделе 9.4.


Гибкий программист



Пока не написан код, все сводится только к конструктивным намерениям. Написанием кода занимаются наши гибкие программисты.

Гибкий программист – это профессионал, так как он очень серьезно относится к качеству программы. Лучшие из таких программистов одновременно являются увлеченными тестировщиками, гордящимися своей работой и всегда старающимися написать максимально качественный код.

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

♦ Они пишут много тестов и часто пользуются ими при разработке (см. главы 12 и 14).

♦ Они постоянно дорабатывают и оптимизируют архитектуру программы по мере работы (см. главу 13).

♦ Они уверены, что базовый код всегда готов к использованию и может быть развернут по первому требованию (см. главу 15).

Программист также тесно сотрудничает с клиентом и другими членами команды и гарантирует, что написанный код работает, что он максимально прост и что внедрение программы для практического использования не составит никакого труда.


Гибкий тестировщик



Гибкие тестировщики знают, что одно дело – написать продукт, а другое – гарантировать, что он работает. Поэтому такой тестировщик подключается к проекту уже на ранних этапах, заблаговременно обеспечивая успешное выполнение пользовательских историй и то, что программа, запущенная в практическую работу, действительно не подведет.

Поскольку в гибком проекте тестировать нужно буквально все, ни один этап работы не обойдется без участия тестировщика. Он будет работать бок о бок с клиентом, помогая ему оформить предъявляемые требования в виде тестов.


На Facebook В Твиттере В Instagram В Одноклассниках Мы Вконтакте
Подписывайтесь на наши страницы в социальных сетях.
Будьте в курсе последних книжных новинок, комментируйте, обсуждайте. Мы ждём Вас!

Похожие книги на "Гибкое управление IT-проектами. Руководство для настоящих самураев"

Книги похожие на "Гибкое управление IT-проектами. Руководство для настоящих самураев" читать онлайн или скачать бесплатно полные версии.


Понравилась книга? Оставьте Ваш комментарий, поделитесь впечатлениями или расскажите друзьям

Все книги автора Джонатан Расмуссон

Джонатан Расмуссон - все книги автора в одном месте на сайте онлайн библиотеки LibFox.

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Отзывы о "Джонатан Расмуссон - Гибкое управление IT-проектами. Руководство для настоящих самураев"

Отзывы читателей о книге "Гибкое управление IT-проектами. Руководство для настоящих самураев", комментарии и мнения людей о произведении.

А что Вы думаете о книге? Оставьте Ваш отзыв.