Agile & Fixed Price
•Télécharger en tant que PPTX, PDF•
4 j'aime•1,151 vues
http://agiledays.ru
Recommandé
Contenu connexe
Tendances
Tendances (14)
Similaire à Agile & Fixed Price
Similaire à Agile & Fixed Price (20)
Plus de Nikita Filippov
Plus de Nikita Filippov (20)
Agile & Fixed Price
- 1. SCRUM в FIXED PRICE проектах ГанчиковМихаил, Exigen Services
- 2. Fixed Price Продукт Продукт Требования SCRUM
- 3. ПЛАН Оценка требований, определение сроков и стоимости SCRUM процесс и роль Project Manager Мониторинг состояния проекта, управление изменениями Выводы и вопросы
- 5. Концепция СИСТЕМЫ Сфера деятельности Проблема Искомое решение Существующие способы решения, недостатки
- 6. Требования К Системе Технические Функциональные (бизнес)
- 7. Оценка требований Детализация Раскладка на истории и задачи Выбор единицы оценки 3-5 человек в команде Не забудьте учесть: Технические требования Нефункциональные задачи
- 9. Риски и их учет в оценке проекта Требования – основной источник рисков Корректировки: Оценок задач Длительности проекта Размера команды
- 10. Определение срокови стоимости проекта Rate Стоимость проекта
- 11. Контракт Бизнес требования и технические ограничения Product backlog (история – оценка) Состав поставки (деливери) Сроки и порядок внесения изменений Гарантийные обязательства
- 12. 2. SCRUM и Project Manager
- 13. Фазы и спринты Pre-sale
- 14. PROJECT MANAGER IN SCRUM Product Owner SCRUM Master Project Manager
- 15. Детализация требований. Acceptance test cases Acceptance test case - действие и ожидаемый результат Цели Минимизация двойного толкования Формирование базы знаний
- 17. Atc. РЕКОМЕНДАЦИИ Своевременно готовить Согласовывать с командой и заказчиком Держать в up to date состоянии
- 18. Совещания (meetings) Планирование/ретроспектива спринта (sprint planning/retrospective) Утренние (stand up) Вечерние (daily sprint status) Ответы на вопросы Обсуждение требований Демонстрация приложения
- 19. Конспект status meeting (минутки) Документируют митинг Ответы на вопросы Обратная связь Достигнутые договоренности Дополняют базу знаний проекта Советы Писать сразу после митинга Должны легко читаться Хранить в одном месте
- 20. Emergency procedures Смена приоритетов Требование неактуально Новые детали требуют переоценки Неверная оценка EMERGENCY STOP!
- 21. III. Мониторинг состояния. Управление изменениями. Приемка функционала
- 22. Приборная панель Размер проекта (Total Scope) Скорость разработки (Team velocity) Скорость приемки (UAT velocity) График разработки (development burn down) График приемки (acceptance burn down)
- 24. ОБРАТНАЯ СВЯЗЬ
- 25. Документирование изменений Неформальные документы Приемочные тест-кейсы Минутки Формальные документы (требуется подпись обеих сторон) Контракт Требования CR формы Изменения должны быть отражены в формальных документах
- 26. Project Change Request Form Customer Name: ________________ Project Name: CFF SOW #: ___________________ Change Request No.:_11_ Change Requested by:______ _ Phone/email: ________________ Description of Change: Support for Region Admin role – Daily Forecast Account List/Details pages, Monthly Forecast Account List/Details pages; DCFF Submission Status List/Details pages, MCFF Submission Status List/Details pages, Holiday List/Details pages Impact of Change: 15 i. h. Agreed Charges: $0 Change Approval (Exigen Services): Project Manager: Mikhail Ganchikov Date: 20-Jul-2009 Delivery Director: Date: 20-Jul-2009 Account Manager: Date: 20-Jul-2009
- 27. Delivery Accepted Delivery Приемка функционала
- 28. Story Sign-off Form Customer Name: Project Name: CFF SOW #: The following stories are considered to be delivered and complete:
- 29. IV. Выводы. Agile + Fixed price = УспехN, где N зависит от: Проработки требований Детальности оценки Учтенных рисков Управления изменениями (отслеживание, документирование) Своевременных мер
- 30. Спасибо За внимание. Ганчиков Михаил migan@exigenservices.com
Notes de l'éditeur
- Решение о том что это будет именно fixed price проектбыло принято заказчиком в виду ограниченного количества средств и времени. К тому же, заказчик полагал что довольно точно понимает то, что он хочет получить.Однако, не он не мы не хотели лишать себя преимуществ гибкого процесса разработки перед традиционным ватерфольным. Поскольку заказчик уже имел опыт ведения SCRUM проектов, нами был использован именно этот подход. Итак, какие преимущества мы видели в его использовании:Во-первых, это короткие сроки предварительной оценки проекта и возможность быстрого старта даже при учете того, что требования были неполными и местами очень абстрактными. При этом заказчик понимал что платит вдвое (а то и втрое) больше не за весь проект, а лишь за темные его куски. Благодаря прозрачности итеративного процесса разработки заказчик мог расставлять и менять приоритеты, видеть работающее приложение уже через несколько недель после старта проекта и оперативно вносить изменения в его работу.
- В своем докладе я уделю внимание трем основным проблемам с которыми я столкнулся. Первая важная проблема это продажа проекта. Это неоплачиваемая деятельность поставщика, которой он занимается получив коммерческое предложение от заказчика (RFP). Как оценить требования, спланировать сроки и рассчитать стоимость проекта? Как составить контракт таким образом чтобы учесть в нем все имеющиеся требования и ограничения чтобы тем самым избавить себя от необходимости делать бесплатно неучтенные вещи в дальнейшем? Об этом я расскажу в первой части своего доклада.Вторая проблема это организация самого процесса разработки. Здесь я расскажу о том, как были определены роли в команде, как мы готовили детальные требования для разработки, делали их оценку. Кроме того я расскажу о наших митингах с командой и заказчиком а также о простом способе документировать все сказанное на этих митингах.В третьей части я расскажу о тех инструментах, которые использовались для определения состояния проекта. Кроме того, я расскажу о том, как был построен процесс управления изменениями на проекте и о том, как проводилась приемка функционала.В завершении своей презентации я постараюсь сформулировать несколько выводов, которые я сделал для себя, а кроме того, по возможности, отвечу на Ваши вопросы.Есть ли у вас вопросы по содержанию презентации перед тем как мы начнем?
- Метафора системыНаш проект начался с письма от заказчика, в котором было кратко изложено описание будущей системы. С помощью этого письма а также дополнительной информации, которую нам удалось собрать до начала обсуждения требований, я постарался определить метафору будущей системы (которую я уже попытался изложить в предыдущем слайде). Понимание метафоры для меня как product owner’а было очень важным потому что позволяло делать выводы о необходимости тех или иных функций не получив еще подтверждения от заказчика. Пониманию метафоры мне помогли ответы на следующие вопросы: Область деятельности, чем занимается заказчик? Какую продукцию, услуги он предлагает?Что заказчик хочет получить (critical success factors)? Вывод нового продукта, привлечение новых клиентов, увеличение прибыли, снижение затрат на поддержку внутренних бизнес процессов?Каким образом заказчик хочет этого добиться?Есть ли уже у заказчика инструментарий, позволяющий решать поставленные задачи? Если да, то какими недостатками обладает?Наконец, как определить эффективность решения поставленной задачи (key point indicators)? Увеличение доли рынка на 10%, возможность работать одновременно с системой 5000 пользователям, возможность сократить время на обработку данных по сравнению с ручым процессом до 15 минут и тд.
- Требования к любому приложению могут быть функциональными и техническими – крайне важным было учесть оба типа требований. Функциональные требованияТребования описывающие поведение системы (business requirements), были составлены аналитиками заказчика и переданы нам в виде юз кейсов. Каждый юз кейс описывал одну высокоуровневую функцию приложения, например:Управление пользователямиВозможность давать прогнозыПостроение отчетовК сожалению, даже при наличии определенной структуры юз-кейса внутри него описание было слабоструктурированным и напоминало больше поток мыслей. Кроме того, уже на этапе высокоуровневой оценки нам было понятно что требования неполные и неточные и нуждаются в уточнениях перед тем как можно дать оценку.Технические требованияТехнические требования представляют их себя список технологий и компонентов, доступных для использования в системе. Это требования к быстродействию, количеству одновременных пользователей и железу, кросс-платформенности, а также к качеству коду (продуктовые метрики). К сожалению, мы не учли часть технических требований, особенно то, что касалось библиотек, разрешенных к использованию IT департаментом заказчика, а также, требований к быстродействию приложения. Первая ошибка откликнулась почти сразу же после старта проекта - первый же спринт был остановлен и пришлось переделывать то что уже было написано без использования компонентов, выбранных нами и не согласованных с заказчиком. Вторая ошибка была гораздо больнее для нас – уже после сдачи всего функционала и завершению основной части разработки приложения, после того как заказчик импортировал данные из старой системы и с приложением одновременно начала работать сотня пользователей. Оказалось, что приложение работает крайне медленно. В результате, нам пришлось рефакторить большие объемы кода, запускать лоад тесты и оптимизировать самые важные функции, причем, как вы наверно уже догадались, делали мы это за свой счет.
- Для того чтобы требования можно было оценить, мы разбивали юз кейс на истории и инженерные задачи (work breakdown structure). Каждая история представляла из себя законченную функцию приложения, разрабатываемую и тестируемую независимо от других. Инженерные задачи делились на задачи разработчиков (development tasks) и тестировщиков (test tasks), кроме того, они классифицировались по уровням трехзвенной архитектуры приложения (база данных, бизнес и пользовательский интерфейс).В качестве единицы оценки заказчик предложил использовать идеальный час. Коротко говоря – это то время, которое программист посвящает работе над поставленной задачей в отсутствии внешних раздражающих факторов и других задач. В оценку должны быть обязательно включены технические требования, которые обсуждались слайдом выше. Так например, если оценивается часто используемая функция, быстродействие которой критично для успеха всей системы, имеет смысл добавить задачу по нагрузочному тестированию и оптимизации быстродействия. При оценке необходимо помнить о том, что какое то время будет потрачено на разработку юнит-тестов или скриптов автоматизации.Помимо задач входящих в состав бизнес требований существуют еще т.н. подготовительные задачи, которые делаются раз при старте проекта, такие как настройка сервера, подготовка билд-процедуры, создания фреймворка для автоматизации приложения. Время, необходимое на эти задачи мы учитывали но в стоимость проекта оно не включалось – всю подготовительную работу мы делали до старта проекта.
- Безусловно, мы понимали, что берем на себя бОльшую часть рисков проекта, и прежде всего это были риски, связанные с управлением требованиями (Software engineering institute):Completeness (полнота)Clarity (точность)Validity (верность)Feasibility (выполнимость)PrecedentScale (мастшабируемость) Учесть возможные риски мы старались с помощью корректировок, которые давались на три вещи:Оценка задач (scope)Длительность проекта (schedule)Стоимость (cost)О том, как корректировалась оценка отдельных задач я уже упоминал выше. В случае, если требование было не до конца понятно, мы формулировали предположения и делали оценку на их основе. В случае если заказчик опровергал какое либо из предположений, мы имели возможность скорректировать оценку отдельных задач. Кроме того, мы могли специально завысить оценки отдельных задач в случае, если требование было непонятным, а заказчик не мог дать достаточное количество деталей.Корректировка длительности проекта - это самый простой способ учесть риски. Как правило, в среднем по индустрии срок выполнения превышает изначально запланированный на 30%. Однако в случае, когда оценка проекта должна быть прозрачной (как это было у нас), заказчику сложно объяснить, почему длительность и стоимость проекта на 30% больше чем посчитанная. Кроме того, в случае когда у заказчика жесткие ограничения по срокам (а так бывает в большинстве fixed price проектов), использовать данную корректировку не получится. Если в вашем случае вы диктуете сроки проекта и имеете возможность заложить корректировку на длительность проекта (тем самым увеличив и его стоимость) – рекомендую ей воспользоваться.В случае, если такой возможности нет, можно включить корректировку в цену проекта, например, заложив в стоимость нормо-часа. Таким образом вы сможете учесть затраты на расширение команды, тем самым повысить её скорость, а следовательно, увеличить шансы уложиться в отведенные сроки в ситуации, когда начнут осуществляться риски. Однако следует помнить, что на расширение команды всегда требуется время, поэтому нельзя ожидать что скорость команды увеличится в полтора раза если увеличить команду во столько же раз. Как правило, на то чтобы новые люди влились в коллектив потребуется от нескольких недель до месяца, в зависимости от квалификации конкретного человека. Кроме того, надо учитывать и максимальный размер команды. Так например, я считаю оптимумом 4+2+1 а максимумом 6+3+1. Дальнейшее вливание людей в команду уже не даст прироста в скорости (а скорее повлечет к её снижению), потому что бОльшая часть времени будет тратиться на коммуникации.КорректировкиОпытный PM знает, что оценку девелопера лучше всего умножать вдвое. Однако, такой проект скорее всего останется на бумаге, потому что найдется поставщик, готовый рискнуть и предложить решение за меньшие сроки/стоимость. Кроме того, такой подход не работает когда заказчик требует прозрачности оценки, как это было в нашем случае. В случае с fixed price у компании поставщика больше гибкости скорректировать оценку с учетом рисков. Корректировки могут производиться следующим образом: Корректировка времени на выполнение отдельных задач. После того как оценен весь проект, сформирована база знаний и общее видение, команда может еще раз пройтись по каждой из задач на предмет возможных рисков и скорректировать оценку. Данный подход трудоемок, кроме того он требует аргументации в случае, если заказчик требует оценку по каждому юз кейсу отдельно, как это было в нашем случае. Мы использовали его для корректировки оценок отдельных тасок после уточнения предположений. Корректировка суммарного времени выполнения проекта (scope contingency) – наиболее простой способ учесть риски на основе предыдущего опыта (а именно, на сколько был превышен бюджет выполнения проекта). На нашем проекте с заказчиком удалось согласовать 10% от скоупа на реализацию фидбека.Корректировка суммарной стоимости выполнения проекта (price contingency). В итоговую стоимость заложена вероятность увеличения команды. В нашем случае была посчитана стоимость человеко-часа, в которую была заложена минимальная прибыль в случае раширения команды в 1,5 раза. Данная корректировка была произведена уже на финальной стадии при-сейла, когда была озвучена стоимость проекта. Самым предпочтительным способом корректировки на мой взгляд является #2, поскольку позволяет увеличить сроки сдачи проекта при неизменном составе команды. Расширение команды это в любом случае дополнительный оверхед и провис по скорости на первых порах.
- На этой диаграмме показано, как мы определяли сроки и стоимость проекта.Во-первых, считается общий объем реализуемого функционала (скоуп) в тех единицах, в которых давалась оценка.Далее, полученная сумма преобразуется в командо-дни. Для этого нужно знать плановую скорость работы команды. Мы отталкивались от команды размером в шесть человек, каждый из которых закрывает по 6 идеальных часов в день. Таки образом была посчитана длительность разработки в командо-днях. Далее, мы учитывали, сколько потребуется дней на проведение sprint planning митингов (по дню на каждый спринт), добавляли их к длительности проекта. Сюда же можно добавить время на стабилизацию после каждого спринта либо по завершении фазы, при условии что стабилизацию делает та же команда. В нашем случае стоимость стабилизации считалась отдельно исходя из условия половины команды и длительности в 4 недели после завершения проекта.Длину проекта перемножали на 8 тем самым получая число оплачиваемых человеко-часов, туда же добавлялись часы на менеджмент проекта (management effort). Полученную сумму человеко-часов мы перемножали на посчитанную предварительно ставку нормо-часа (в которую была заложена минимальная прибыль компании при условии расширения команды в два раза).Все шаги расчета сроков и стоимости (кроме расчета ставки нормо часа) были показаны заказчику, таким образом он знал за что он платит.
- В контракте должны быть учтены ваши обязанности (определенные бэклогом и сроками), обязанности заказчика (сроки приемки и подачи фидбека, график оплат и тд) и условия при которых вы работаете, включая нефункциональные требования, описание процесса, график работ и тд.Вот ряд моментов, которые следует указатьв контракте (помимо сроков и стоимости):Описание бизнес-требований с теми деталями, которые были прояснены в ходе обсуждений, и на которых базируется оценкаProductBacklog в виде историй и оценок. Он будет нужен в дальнейшем для того чтобы иметь возможность приоритизировать, планировать релизы, заменять истории на другие.Описание нефункциональных требований, которым должен соответствовать выпускаемый продуктФорма выпуска продукта (инсталлятор, документация, скрипты и тд)Приемка продукта - сроки учета пожеланий заказчика, которые мы будем обязаны реализовать бесплатноПроцесс управления изменениями, за которые заказчик будет обязан заплатить либо заменить им какую-либо из историй в product backlog’е.Подробнее об отличиях feedback и change request я расскажу в третьей части своего доклада.Гарантийные обязательства поставщика (сроки и что подпадает под определение гарантия)В нашем контракте мы не учли часть нефункциональных требований (о чем уже было сказано ранее). В контракте не было четких формулировок feedback и change request, что позволяло заказчику использовать неточность формулировки требований для бесплатной имплементации его хотелок даже тогда, когда они противоречили его словам, сказанным ранее (которые опять таки, не были в контракте и не имели формального статуса). В контракте не были прописаны сроки в течении которых заказчик обязуется протестировать реализованный функционал и дать указания по его доработке. В результате подписание актов приемки работ растянулось на несколько месяцев а мы еще долго делали забесплатно хотелки заказчика.
- Во второй части своего доклада я расскажу о том, как строился процесс разработки и о моем участии в нем
- Раньше я считал что роль PM-ав СКРАМ команде несет на себе SCRUM мастер, потому что он обеспечивает процесс выполнения проекта. Однако, мое понимание было ошибочным, потому что SM не отвечает за успех проекта. Вот неточный перевод определения роли PM из PMBOK – это человек выбранный или назначенный исполнительной организацией для достижения цели проекта. Думаю, можно смело утверждать что основная цель большинства ИТ проектов – удовлетворить потребности заказчика реализовав поставленные им требования в полном объеме и в оговоренные сроки и стоимость. Лицом, отвечающим за реализацию требований заказчика в SCRUM проекте является Product Owner. Именно поэтому мы пришли к выводу, что PM-а правильнее ассоциировать именно с PO а не со SM. Как Product owner я обеспечивал постановку задач для команды в соответствии с требованиями и приоритетами заказчика. Помимо этого, в мои задачи как менеджера проекта входило соблюдение сроков и стоимости проекта (об этом я расскажу в третьей главе). Я не вмешивался в работу команды (не занимался микроменеджментом) определяя кто что будет делать, хотя и мог бы это сделать. Тем самым был бы нарушен один из основных принципов СКРАМА – команда должна оставаться самоорганизующейся. PM (PMBOK): “The project manager is the person assigned by the performing organization (ed: business) to achieve the project objectives”Product Owner’ (Ken Schwaber): “the person who is responsible for what the Scrum team builds and for optimizing the value of it” and “The Product Owner is responsible to those funding the project to deliver the vision…” SCRUM MASTERSchwaber (Agile Project Management with Scrum, 2004), “the ScrumMaster is responsible for the Scrum process, its correct implementation, and the maximization of its benefits” (pg 142)”.
- Одной из моих основных задач было постоянное прояснение и уточнение требований. В качестве формата для детальных требований был выбран формат Acceptance Test Cases. В большинстве случаев каждый ATC описывал действия, которое нужно выполнить и ожидаемый результат. Результатом как правило была реакция системы на определенное действие пользователя. Каждой функциональности приложения соответствовал набор ATC, по которому, как по чек-листу, можно было пройтись и проверить, работает ли приложение в соответствии с поставленными требованиями.Часть ATC дополнялась набором эскизов приложения (мокапов), особенно это касалось дизайна экранов или формата отчетов. Внедряя ATC мы преследовали следующие цели:Сформулировать требования на едином языке доступном командеи заказчику тем самым минимизировав их двойное толкование. Сформировать базу знаний проекта которая позволяла определить как должно функционировать приложение даже после нескольких месяцев.К сожалению, мы испытывали определенные трудности с формированием и поддержкой ATC, потому что не соблюдали три простые вещи:Готовить ATC своевременно – желательно до Sprint Planning митинга, либо в первые дни спринта. Согласовывать с командой и заказчиком, тем самым ликвидируя темные и неясные описания требованийДержать в up to date состоянии, постоянно дополняя деталями, уточняемыми заказчиком (это могут быть вопросы команды возникающие по ходу реализации функциональности или фидбек заказчика)
- Одной из моих основных задач было постоянное прояснение и уточнение требований. В качестве формата для детальных требований был выбран формат Acceptance Test Cases. В большинстве случаев каждый ATC описывал действия, которое нужно выполнить и ожидаемый результат. Результатом как правило была реакция системы на определенное действие пользователя. Каждой функциональности приложения соответствовал набор ATC, по которому, как по чек-листу, можно было пройтись и проверить, работает ли приложение в соответствии с поставленными требованиями.Часть ATC дополнялась набором эскизов приложения (мокапов), особенно это касалось дизайна экранов или формата отчетов. Внедряя ATC мы преследовали следующие цели:Сформулировать требования на едином языке доступном командеи заказчику тем самым минимизировав их двойное толкование. Сформировать базу знаний проекта которая позволяла определить как должно функционировать приложение даже после нескольких месяцев.К сожалению, мы испытывали определенные трудности с формированием и поддержкой ATC, потому что не соблюдали три простые вещи:Готовить ATC своевременно – желательно до Sprint Planning митинга, либо в первые дни спринта. Согласовывать с командой и заказчиком, тем самым ликвидируя темные и неясные описания требованийДержать в up to date состоянии, постоянно дополняя деталями, уточняемыми заказчиком (это могут быть вопросы команды возникающие по ходу реализации функциональности или фидбек заказчика)
- Другими моими задачами являлись участие и проведение митингов.Во первых это были sprint planning митинги.На них я выступал в роли представителя заказчика вынося на суд команды требования, отвечая на вопросы и расставляя приоритеты. Очень часто я конечно же не знал ответов потому что не являлся business owner’ом проекта и не знал всех тонкостей бизнес процессов. Требования, которые нельзя было детально оценить либо дробились на подзадачи, либо переносились на следующий спринт. Я же накапливал вопросы которые затем прояснял с заказчиком.Ежедневно мы проводили утренние standup митинги, посещение которых было обязательным для всех членов команды . У нас было правило в команде – опоздавший должен проставиться. При этом неважно, было ли это печенье, фрукты или пиво по пятницам) На утренних митингах каждый член команды отвечал на три вопроса. Кроме того, я собирал статус по задачам в спринте, а именно, сколько по мнению команды осталось времени на их завершение.Наконец, я ежедневно участвовал в телефонных митингах с заказчиком. На них я задавал вопросы от команды, на которые не в состоянии ответить сам. Также на них обсуждались новые требования и уточнялись детали по уже реализованной функциональности (фидбек). В случае возникновения проблем у заказчика он имел возможность продемонстрировать работу приложения через web митинг и указать на проблему.
- Очень важно было документировать основные положения переговоров с заказчиком, такие как ответы на вопросы, описание поведения системы (часто для этого требовались дополнительные примеры), фидбек заказчика (предложения по изменениям) и обещания, данные обеими сторонами.В качестве простого и быстрого способа документирования мы использовали минутки. Минутки – это набор положений, что то вроде стенограммы.В минутках хранилась важная информация связанная с детализацией требований. ATC и минутки формировали базу знаний проекта.Вот несколько советов по ведению минуток:Писать по горячим следам, желательно сразу после митингаИспользовать простой язык, без сложных конструкций и длинных предложений. Минутки должны легко читаться и быть понятными не только вам и заказчику, но и команде.Оформлять каждые минутки отдельным документом и хранить в одном месте – для удобства поиска нужной информации по ним.По завершении вечерних митингов мною писались минутки, которые затем отправлялись команде заказчика и нашей команде. Формат минуток очень прост – в них по пунктам расписаны все вопросы,предложения, утверждения и обещания (как мои так и заказчика).Минутки –инструмент который необходимо использовать. В случае неточных UC и неактуальных ATC (как это было у нас), минутки могут стать единственным документом, на который можно сослаться при разрешении споров. Вот несколько советов:Писать сразу после митингаДолжны легко читататьсяИспользовать примерыХраните все минутки в одном месте (например, папка в аутлуке), чтобы поиск по ним был как можно более простым.Оформляйте каждые минутки отдельным письмомСтарайтесь формулировать каждую озвученную мысль максимально доступным языком, понятным как заказчику так и разработчику. Сложные бизнес кейсы полезно дополнять простыми примерами. Например так: Отчет должен выводить значения для всех дат в прошлом только в случае, если в эти дни давались прогнозы. Прим.: прогноз был составлен последний раз 29 октября и содержит значения на 10 дней вперед. Сегодня 5 ноября и пользователь строит отчет по этому прогнозу. В построенном отчете должно быть выведено только значение данное пользователем 29 октября на 29 октября так как последующие 10 дней прогноз не давался.
- Ранее я уже говорил о том что не вмешивался в деятельность команды - SCRUM мастер оберегал её от моего вмешательства. Получив задачи на спринт, команда выполняла их в точном соответствии с теми требованиями, которые обсуждались на sprint planning’е. В случае, если что то менялось, я мог сделать две вещи – позволить команде закончить спринт с теми знаниями, которые мы имели до его начала ли экстренно остановить его, применив т.н. emergency procedure.Итак, в каких случаях мы применяли emergency procedure (а мы применяли):-Смена приоритетов либо неактуальность требований – наш первый же спринт был остановлен через 3 дня после старта когда оказалось, что требования в PBL больше неактуальны и данная функциональность уже реализована заказчиком – хорошее начало проекта.-Всплыли новые детали, которые делают текущий подход к реализации требований невалидным – благодаря этому был остановлен второй спринт. Я уже упоминал об этом инциденте в начале своего доклада – мы не учли то, что заказчик не может использовать определенные программные компоненты 3-их фирм. Как мы применяли emergency proc?-Во-первых – это остановка спринта – самое болезненное действие-Проведение нового sprint planning митинга с тем чтобы сформировать новый набор задач на спринт-Запуск нового спринта-Корректировка планов проекта – расписание спринтов и их привязка к фазам.-Оформление CR форм – подробно о них я расскажу в третьей части доклада, пока лишь отмечу что все что меняет изначальный Product Backlog, требует фиксации в контракте.
- В третьей части своего доклада я расскажу о том, каким образом происходило управление проектом – какие показатели мы использовали, как учитывался фидбек заказчика, как выполнялась приемка функционала.
- Для того, чтобы следить за состоянием проекта, в нашей компании использовался простой набор метрик, Во первых, это суммарный объем работ (scope) в тех единицах, которые использовались для оценки product backlog – т.е., в идеальных часах. По окончании каждого спринта мы отмечали, какие истории были отгружены заказчику. На основании объема этих историй мерилась производительность команды в идеальных часах - синий график. Наш проект был разделен на 3 фазы разработки а также фазу поддержки/доработки приложения. По завершении каждой из трех фаз заказчику отсылался акт о выполненных работах с описанием реализованных историй после чего заказчик в течение двух недель должен был эти работы принять или указать на все неточности/неисправности.Так по крайней мере мы планировали.График в данном слайде был взят из состояния нашего проекта на июль 2009 года. На нем видно что в отличии от скорости разработки, которая позволяет закончить разработку функционала в требуемые сроки, наблюдается заметное отставание в приемке отгруженной функциональности - примерно 1 месяц. К сожалению, реальность оказалась гораздо хуже - акт приемки работ по третьей фазе проекта был подписан лишь через два месяца после её завершения. В течение месяца после окончания третьей фазы мы продолжали исправлять замечания заказчика и дополнительные требования, еще полмесяца фиксилибаги уже в рамках гарантийного обслуживания, еще полмесяца пребывали в ожидании, пока заказчик проведет тестирование на своей стороне. К сожалению, пока что у меня нет ответа, как можно учесть такого рода риск, кроме как использовать contingency на длину проекта.
- Обратная связь от заказчика стала поступать сразу же как они установили у себя первую рабочую версию нашего приложения и начали тестирование. Очень часто между мною, скрам мастером и заказчиком возникали разногласия о том, как классифицироватьфидбек заказчика, что мы должны сделать бесплатно а что нет. Вот мой вариантклассификации фидбека:Бага – свойство/поведение объекта отличается от требуемого, задокументированного в UC/ATC/TC. Делается бесплатно.Feedback – неучтенное свойство/поведение объекта, которое не противоречит задокументированным в UC/ATC/TC и логично дополняет их. Делается бесплатно. Пример – навести красоту в формате отчета – задав стили шрифтов, размеры колонок и тд. Change Request – неучтенное свойство/поведение объекта, которое противоречит задокументированным в UC/ATC/TC или отстуствует. Замещает имеющийся скоуп или требует увеличения срока/стоимости.Пример – добавить в приложение функциональность архивации данных. Большинство багов было выявлено нашей командой QA, однако самые сложные были выявлены лишь после ввода системы в эксплуатацию. В тех случаях, когда для устранения неисправностей требовалось существенное время (более часа) производилась оценка времени на исправление, после чего такая задача наряду с другими включалась в бэклог спринта. Анализируя время на выполнение задачи, оцененное на этапе продажи проекта с реально потраченным, я прихожу к выводу, что время на исправление багов покрывалось той оценкой, которую мы делали (scope).На предыдущем слайде я уже говорил об объемах фидбека, который мы были вынуждены реализовывать и как он влиял на сроки проекта. По существу можно сказать что фидбек – это хотелки заказчика, некоторые из них важнее, другие не очень. Однако заказчик может оценить их важность только после того, как увидит работающее приложение – вот почему так трудно учесть их на этапе оценки сроков проекта.В случае когда заказчик был согласен с тем что его хотелка противоречит требованиям или полностью отсутствует в них, мы оформляли CR формы. Такие изменения замещали собою равные по отбъему задачи в PBL, либо оплачивались отдельно.
- Все изменения функциональности, противоречащие описанию требований в контракте, мы документировали. Делалось это по нескольким причинам. Во-первых для того, чтобы поддерживать требования к системе в актуальном состоянии – для этого писались ATC и минутки. Во-вторых, для того, чтобы придать изменению статус формального документа с обязательной подписью заказчика. В этом случае последний не мог предъявить нам претензии по завершении проекта о том, что приложение не соответствует первоначальным требованиям.В качестве формального документа, отражающего изменения в требованиях, выступали CR-формы. В них подробно описывалось изменение и его высокоуровневая оценка (наподобие того, как требования и оценка были зафиксированы в контракте).
- В завершении своей презентации я постараюсь сделать несколько выводов.