В прошлом году я руководил проектом для научно-исследовательского института. Требования выполнялись на протяжении всего проекта, и у меня было много проблем при планировании, составлении бюджета и предоставлении других оценок.
Теперь, в 2011 году, заказчик просит предложение по фиксированной цене для развития поставленной системы. Опять же, требования настолько неопределенны, что на первом этапе я планирую задачу анализа на два месяца или около того, чтобы просто ОПРЕДЕЛИТЬ требования.
После некоторых размышлений я почти убежден, что гибкий подход был бы ответом, чтобы удовлетворить такого клиента (и не иметь еще один мучительный год ;)). Мои вопросы:
Я понимаю, что на эти вопросы не так просто ответить. Спасибо
На самом деле, в отличие от других, я думаю, что Agile может быть здесь хорошим ответом. Сказав это, я считаю, что вы подписываете какой-то гибкий контракт с заказчиком, что означает, что они могут расторгнуть контракт после каждого спринта. Конечно, договориться о такого рода контрактах не так-то просто — вы можете найти презентацию Пола Клиппа о продажах agile очень полезной, если вы хотите пойти по этому пути ( там тоже есть слайды ).
Классический контракт с фиксированной ценой и нечеткими требованиями должен вызывать тревогу, как указывает Дейв Парилло, поэтому я бы сосредоточился либо на четко определенных спецификациях, либо убедил клиента переключиться на контракт, который ограничивает риски для обеих сторон в этой ситуации.
Использование agile-подхода внутри проектной команды — это отдельная история, которая не так тесно связана с формой контракта. Вы можете использовать гибкий подход в проекте с фиксированной ценой, и он может работать очень хорошо. Если клиент готов взять на себя свою часть процесса, например, демонстрация продукта после каждого спринта или повторная расстановка приоритетов функций, вероятно, это хорошая идея. Итак, мой ответ на вопрос 1: да, Agile может вам помочь.
Переход на agile без участников, имеющих опыт работы с agile, скорее всего, будет трудным. Разумный минимум — это кто-то, у кого есть опыт работы в разных проектах и в разных организациях, чтобы они знали, что может сработать, а что нет. Кроме того, команда должна быть очень открыта для обучения и самосовершенствования с течением времени.
Конечно, было бы намного лучше, если бы вы смогли найти тренера, который помог бы вам с толчком. В противном случае вполне возможно, что вы зайдете в тупик, прежде чем найдете способ, который хорошо работает для вашей команды.
Нет простого общего ответа, сколько времени потребуется, чтобы перейти на новый метод, независимо от того, agile он или нет. Это сильно зависит от людей, ситуации, проекта, сроков и т. д. Могу привести пример, когда мы переходили на Канбан — подход, которого никто из нас раньше не знал из практики. Потребовалось около полугода, чтобы достичь того момента, когда мы довольно свободно освоили то, как мы работали, однако это не было единовременным моментом — мы увидели первые улучшения всего через несколько недель после начала. У нас был человек, знакомый с разными подходами, и команда была готова учиться и адаптироваться. На самом деле сложно ответить точно, но я думаю, что где-то между месяцем и двумя месяцами дела у нас шли лучше, чем до изменений.
Agile — это не ответ. Попробуйте планирование набегающей волны с достаточными резервами в контракте.
Не позволяйте им уговорить вас на фиксированную цену, не предоставив себе достаточных ресурсов для выполнения итераций, необходимых для лучшего определения проекта. Исследования полны неизвестных.
Этот пост и комментарии могут оказаться полезными.
Вы планируете заключить контракт с фиксированной ценой, чтобы «развить» что-то с минимальными или нулевыми требованиями? Фиксированная цена + неопределенные требования — плохая комбинация. Это должно быть признаком опасности, и нет, agile — это не какая -то волшебная пуля , которая волшебным образом облегчит вам эту проблему в 2011 году. Весь проект рискован — добавление обязательства «переключиться на agile» мало что изменит. хуже, чем уже есть. Сожалею.
Не знаю, каковы ожидания ваших клиентов, но взгляните на Agile Manifesto . Если вы считаете, что ваш будущий проект может выиграть от смещения фокуса с элементов справа на элементы слева, возможно, вам помогут некоторые гибкие методы.
Судя по вашему вопросу, похоже, что ни у кого в команде проекта нет опыта гибкой разработки, и вы не планируете платить за обучение. Еще один знак опасности. Вам нужен как минимум коуч или ментор — человек, который действительно понимает модель процесса, которую вы пытаетесь внедрить. Если вы отправляете одного из своих сотрудников для прохождения такого рода обучения, у вас есть преимущество в том, что у вас есть наставник, прекрасно понимающий потребности и ограничения вашей организации. Вы по-прежнему можете получать пользу от внешних консультантов, поскольку доморощенные наставники могут быть менее объективны, чем консультанты.
Вместо того, чтобы переключаться на Agile (или нет) только потому, что кто-то на этой странице говорит, что вы должны (или нет), я предлагаю вам внимательно изучить проблемы, с которыми вы столкнулись в прошлом году, и разработать стратегии для их устранения или минимизации. Например:
Подумайте о семинаре-размышлении или ретроспективе . Делайте это независимо от того, соглашаетесь ли вы на работу с фиксированной оплатой или нет. Похоже, вам есть чему поучиться из прошлого проекта, который оказался для команды сложнее, чем вам хотелось бы.
Я думаю, это может зависеть от проекта. Agile работает очень хорошо, когда вы можете начать предоставлять пошагово — и, честно говоря, это могут быть даже документы с вашими требованиями.
Я бы посоветовал не просто пытаться «быть гибким» — убедитесь, что вы начинаете с проверенного и проверенного подхода, такого как схватка, когда вы только начинаете и не имеете опыта. Сначала мы пытались быть гибкими и попали в затруднительное положение, пока не сделали шаг назад и не внедрили правильную структуру. Вы всегда можете адаптировать его к вашим потребностям с течением времени.
спасибо всем за отзывы
Фиксированная цена является обязательной для клиента, и мы уже стремимся к максимально возможной цене, чтобы сохранить более высокую маржу для неизвестного.
Проблема в ожиданиях клиентов, которые слишком часто менялись в прошлом году. В моей идее внедрение Agile означало бы «заставить» клиента сосредоточиться на итерациях и на том, что мы будем выпускать на каждой из них, отслеживать невыполненную работу и корректировать приоритет в зависимости от их отзывов. Таким образом, я думаю/надеюсь, что смогу добиться того, чтобы ожидания клиентов были более привязаны к масштабу проекта, ограничивая их исследовательский подход, который, как правило, делает проект настолько рискованным.
Действительно, здесь скрывается большой политический вопрос, потому что заказчик хочет исследования, а проект создаст портал услуг для граждан от имени правительства.
Я не могу заниматься политикой, но мне нужен способ держать проект под контролем
На мой взгляд, гибкие методы меняют ваши отношения с клиентами, когда вы являетесь поставщиком ИТ-услуг. Ценообразование и выставление счетов могут стать своего рода проблемой.
Я думаю, что решение состоит в том, чтобы действовать по пакетам. Я думаю, что это должно быть особенно подходящим для Scrum: вы определяете набор историй для каждого спринта и выставляете счет за каждый спринт, поэтому проект движется вперед, вы сохраняете видимость (объем спринта не может быть изменен, пока он находится в разработке) , но проект открыт для изменений и в нем участвует заказчик.
йода
Тодд А. Джейкобс