Цитаты из книги «Гибкое управление IT-проектами. Руководство для настоящих самураев»

Ниже перечислены основные вопросы и упражнения, прорабатываемые на этапе концептуализации проекта. 1. Зачем мы здесь собрались? Это быстрое напоминание о нашей цели, наших клиентах, а также о том, почему мы решили заняться данным проектом в первую очередь. 2. Составление блицрезюме. Если бы у нас было 30 секунд, за которые нужно описать наш проект в двух фразах, что бы мы о нем сказали? 3. Разработка оформления продукта. Если бы мы быстро листали журнал и наткнулись на рекламу нашего продукта или услуги, то что бы она нам сообщила, и еще важнее – согласились ли бы мы за это заплатить? 4. Составление списка того, что мы не собираемся делать. Вполне ясно, что мы собираемся делать при реализации нашего проекта. Давайте еще точнее опишем ситуацию и подчеркнем, чего мы ни в коем случае делать не будем. 5. Встреча с коллегами. Сообщество специалистов, занятых в проекте, всегда больше, чем кажется. Почему бы не пригласить их на кофе, чтобы все могли познакомиться друг с другом?

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

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

Здесь может возникнуть вопрос: нужно ли постоянно оценивать заново имеющиеся истории? Ответ – да

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

о пользовательские истории – это просто краткие описания функций, которые клиенты хотят видеть в программе

Просто умножьте количество членов команды на ориентировочную длительность проекта, с реальной процентной ставкой

Даже если вы думаете, что знаете, кто командует, все равно задайте данный вопрос.

Сможет ли клиент уделить этому время? Уполномочен ли клиент принимать необходимые решения? Желает ли клиент направлять развитие проекта и руководить им?

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