Планирование и запуск проекта в условиях ‘нулевой’ видимости: практический опыт
•Download as PPTX, PDF•
1 like•577 views
Михаил Ганчиков -
Recommended
Recommended
More Related Content
More from SQALab
More from SQALab (20)
Планирование и запуск проекта в условиях ‘нулевой’ видимости: практический опыт
- 1. ПЛАНИРОВАНИЕ И ЗАПУСК ПРОЕКТА ПРИ НУЛЕВОЙ ВИДИМОСТИ – ПРАКТИЧЕСКИЙ ОПЫТ Михаил Ганчиков, руководитель проекта First Line Software 2011 Think Results.
- 2. О ЧЁМ ЭТА ПРЕЗЕНТАЦИЯ? ■ Нулевая видимость – это когда о проекте неизвестно ничего, кроме сроков ...и требования выполнить все требования ■ Есть масса способов избежать такой ситуации но мы не будем их обсуждать ■ Что делать, если не удалось избежать? управлять бюджетом 2
- 3. СОДЕРЖАНИЕ ■ 1. Оценка проекта, планирование бюджета и роста команды ■ 2. Работа с требованиями и отслеживание изменений ■ 3. Контроль за состоянием проекта, внесение корректировок ■ 4. Недостатки подхода ■ 5. Полученные результаты и выводы 3
- 4. 1. АНАЛИЗ И ОЦЕНКА ТРЕБОВАНИЙ ■ Трата времени на сбор требований может не дать желаемого результата ■ Для старта проекта достаточно понимать функционал на концептуальном уровне и иметь несколько детализированных историй ■ Оценка историй относительно друг друга позволяет абстрагироваться от человеко-дней 4
- 5. ПРОБЛЕМЫ И РЕШЕНИЯ ■ Пробелы в требованиях заполняются предположениями команды ■ Неясность технической реализации определяет степень риска для каждой истории риски влияют на длительность проекта 5
- 6. ОЦЕНКА ПРОЕКТА ■ Общий объём работ: ������ N������������������������������������ ������������������������ = Story PointsSt ∗ Risk St ������������=0 , где St – история, M – общее кол-во историй, Risk – коэффициент риска ■ Проектная норма риска (SP в день): Story Points Ratio = N������������������������������������ ������������������������ 6
- 7. ПЛАНИРОВАНИЕ РОСТА КОМАНДЫ ■ Наличие полной команды в начале проекта может замедлить ход и демотивировать людей ■ Строительство команды лучше вести итеративно, наращивая ядро вокруг lead’ов и senior’ов 7
- 8. ПРОИЗВОДИТЕЛЬНОСТЬ КОМАНДЫ ■ Лишь часть команды влияет на её производительность ■ При росте числа людей сокращается производительность ядра ■ Новые члены команды не могут работать с той же скоростью, что и все остальные 8
- 9. ПЛАН ВЫПОЛНЕНИЯ РАБОТ ■ Плановая норма на sprint (Target burn-up): S������������������������������ ������������������������������������ = NDevelopers ∗ Ratio , где N – “производящая” часть команды 700 600 500 Story Points 400 300 Actual Scope, SP 200 100 0 11/11/11 17/06/11 08/07/11 29/07/11 19/08/11 09/09/11 30/09/11 21/10/11 Weeks 9
- 10. 2. РАБОТА С ТРЕБОВАНИЯМИ ■ Technical Product Owner ищет простые решения формулироует технические задачи для команды анализирует результаты приёмки и тестирования заказчиком определяет изменения (change requests) функционала 10
- 11. РАБОТА С ТРЕБОВАНИЯМИ - 2 ■ Команда может помочь TPO в поиске технического решения выполненяя исследовательские задачи ■ Product Owner должен следить за приоритезацией историй в backlog’е и помнить о фиксированном количестве story points, которые может сделать команда 11
- 12. 3. КОНТРОЛЬ СОСТОЯНИЯ ПРОЕКТА ■ Анализ состояния проекта по 3 параметрам (story points): плановая норма на спринт (Target burn-up) фактический объём выполненных историй (Completed scope) общий объём product backlog’а (Actual scope) 12
- 13. КОНТРОЛЬ СОСТОЯНИЯ ПРОЕКТА - 2 700 600 500 Story Points 400 300 200 100 0 19/08/11 17/06/11 08/07/11 29/07/11 09/09/11 30/09/11 21/10/11 11/11/11 Completed Scope, SP Week Completed Scope Extrapolation, SP Actual Scope, SP Planned Scope, SP 13
- 14. ЧТО ДАЛЬШЕ? ■ Почему нужна переоценка бэклога в середине проекта? появление новых историй – change request’ов детализация требований для существующих историй может повлиять на их оценку полученные знания о предметной области позволяют сделать оценку более точной ■ В случае роста бэклога – эскалировать руководству 14
- 15. 4. НЕДОСТАТКИ ПОДХОДА ■ Снижение производительности ■ Снижение качества продукта Ratio (bugs/SP) 1.4 1.2 1 0.8 0.6 0.4 0.2 0 0 1 2 3 4 5 6 7 15
- 16. СПОСОБЫ БОРЬБЫ ЗА КАЧЕСТВО ■ TDD (test driven development) ■ Автоматизированное регресс-тестирование ■ Acceptance тестирование на стороне заказчика cоставление сценариев на основе acceptance-тестов 16
- 17. 5. ВЫВОДЫ И РЕЗУЛЬТАТЫ ■ Закладка рисков в оценку залог того, что проект не останется без запаса по времени ■ Факторы роста команды, нагрузки на ключевых игроков должны учитываться при расчете объема работ ■ Работа с требованиями должна продолжаться до конца проекта ■ Мониторинг плановых и фактических показателей позволяет не упустить момент, когда нужно просить заказчика остановиться и пересмотреть требования 17
- 18. СПАСИБО ЗА ВНИМАНИЕ ■ Вопросы? ■ mganchikov@1st-sw.com 18
Editor's Notes
- Мы много размышляем и рассуждаем о техниках оценки, преимуществах того или иного подхода к разработке, полезности инструментария, помогающего управлять проектами. Но рано или поздно, каждый из нас сталкивается с классической проблемой для менеджера – как сдать проект к обозначенному сроку и с зафиксированным набором функций? Согласно проектному треугольнику, в тех случаях, когда время и требования зафиксированы, в нашем распоряжении остаётся стоимость проекта. Это означает, прежде всего, возможность увеличения числа людей в команде для того, чтобы повысить её скорость. А иногда это еще и возможность работать в овертайм. Впрочем, оба средства неблагоприятно влияют на качество – четвертую грань треугольника, и нужно помнить об этом.В своём докладе я не буду рассуждать о причинах, которые могли привести к такой ситуации, а расскажу о тех действиях, которые были предприняты нами для того, чтобы обеспечить нормальное развитие и ход выполнения проекта.
- Основные вопросы, затрагиваемые в докладе, это:Техника первоначальной оценки стоимости проекта в условиях ограниченной информации и сжатых сроковПланирование роста команды и её производительностиУправление требованиями, удержание роста объёма работНаблюдение за состоянием проекта, сравнение плановых и реальных показателейКорректировка плана Еще пара слов, прежде чем перейти к деталям – мы работаем по методике SCRUM, поэтому далее по тексту будет часто встречаться соответсвующая терминология.
- Думаю, большинство согласится с тем, что зачастую трата времени на сбор требований до начала работы над проектом может оказаться напрасной. Так было и в нашем случае. На момент, когда мы получили этот проект, на него уже было потрачено несколько человеко-месяцев для сбора и анализа требований. Собственно, то что мы делаем – это не технологии rocket science, мы строим новостной портал. Довольно крупный скандинавский новостной портал. За основу берётся существующий сайт, его функциональность переносится с необходимыми изменениями на новую CMS платформу, рисуетсяновый дизайн, после чего выполняется миграция данных и вывод нового сайта в лайв. За несколько месяцев produсt owner’у удалось собрать лишь поверхностные требования о работе сайта и составить product backlog на очень высоком уровне. Большая часть требований была сформулирована в виде “эпиков”, а не историй. Безусловно, чтобы вникнуть в механику работы и взаимодейстие с другими сайтами, нужно был больше, чем просто видеть и понимать, как работает существующий сайт. Вся собранная информация была “закачана” в нас за неделю, столько же времени нам дали на то, чтобы выполнить оценку общего объёма работ. Было понятно, что мы рискуем, называя любые цифры. Тем не менее, оценка для каждой истории была нужна для того, чтобы истории можно было сравнивать друг с другом и в случае необходимости заменять на равные по величине. Особенно крупные эпики дробились на более мелкие истории (при этом мы информировали product owner’а), прежде чем дать для них оценку. В оценке принимали участие тех-лид и QA лид, попутно задавая наводящие вопросы, которые могли прояснить новые детали в требованиях. В качестве меры оценки мы использовали story points. Во время оценки мы исходили из допущения, что история, оцененная в один story point, может быть сделана и протестирована за день, при условии, что известна техническая реализация и она достижима. Истории оцененные в 1 story point – эталонные истории. Оценки других историй базируются на сравнении с эталонными. Исключением были только очень большие истории, в таких случаях команда мысленно дробила историю на несколько мелких для того, чтобы дать суммарную оценку.Во время проведения оценки мы сталкивались с двумия типами проблем. Первый – нехватка деталей по требованиям. Поскольку многое на тот момент не знал и сам product owner, команда делала предположенийдля каждой из историй (assumptions), на которых базировалась оценка. Затем список предположений по каждой истории отправлялся PO, и тот выяснял, верны ли они или нет. В тех редких случаях, когда наши допущения оказывались не верны, мы меняли оценку исходя из полученных данных.Второй проблемой было отсутствие информации, связанной с возможностями технической реализации (или проще говоря, девелоперы еще не знали, как будут реализовывать функционал). Данный риск учитывался для каждой истории и, в зависимости от выбранной величины (Low, Med, High), мог увеличить общее время на реализацию истории с 10 до 50% процентов.
- По результатам проведенной оценки было получено общее количество story points, необходимых на реализацию всего бэклога. Далее, считалось количество человеко-дней на реализацию всего бэклога, как сумма произведений стори поинтов на риск для каждой истории. Имея на руках две цифры (N days и SP), можно было посчитать такжепроектную норму риска. В нашем случае contingencyсоставил ~ 30%, что является нормойдляagile fixed price проектов.
- Нашей следующей задачей стала необходимость роста численности команды для того, чтобы увеличить её скорость так, чтобы к концу проекта мы могли сделать всёимеющееся количество стори-поинтов. Структура нашей команды похожа на ‘классическую’ структуру agile проекта. Во главе SM, Tech Lead и QA Lead, число девелоперов в двое больше числа тестеров. Ростить команду было нужно в той же пропорции, чтобы соблюдался баланс в отношении времени на разработку и тестирование функционала (в среднем, время на тестирование = ½ времени на разработку). Для того, чтобы составить план роста команды, мы поделили всё отведенное на проект время на равные отрезки – спринты (в нашем случае это были 3-х недельные спринты). Последний спринт был зарезервирован под стабилизацию кода и исправление ошибок. Каждый спринт был поделен на недели. В каждую неделю мы считали общее количество людей в команде (отдельно девелоперов и тестеров), а также количество “работающих” людей, т.е. тех, кто “сжигает” стори-поинты. Первая цифра была нужна для того, чтобы прикинуть общую стоимость проекта, вторая – для планирования скорости команды. Здесь же учитывались отпуска исходя из имеющегося плана отпусков в компании.Мы использовали простые правила для подсчета “работающих” людей. Девелопер не работает, если он менее двух недель на проекте, поскольку это время тратится на то, чтобы войти в курс дела, получить необходимый набор базовых знаний, пройти курс по изучению возможностей CMS. Для тех девелоперов, которые присоединялись к команде с других, похожих проектов, этот срок был много меньше и составлял несколько дней, необходимых на развертку системы и всех необходимых инструментов на локальной машине для того, чтобы приступить к работе. Кроме того, учитывалась также нагрузка на тех лида, вокруг которого формировалась команда. Так, поначалу техлид считался на 100% работающим девелопером, однако, с ростом команды, нагрузка на него увеличивалась. Когда число программистов выросло до 4 человек, время работы техлида стало составлять лишь 50%. Когда число программистов превысило 8 человек, оно стало равняться 0%. Число тестеров росло пропорционально и было вдвое меньше количества разработчиков.
- Следующая задача – составить план по выполнению работ на каждый спринт. Имея на руках данные о соотношени story points и общего количества человеко-дней (ratio), мы считали эту цифру исходя из усредненного кол-ва работающих программистов в команде на спринт. Другими словами, кол-во девелоперов умножалось на ratio, полученная цифра бралась в качестве базового (планового) объема работ, который было необходимо выполнить в спринт, чтобы проект оставался на треке.
- Несмотря на то, что формально объём работ оставался зафиксированным в контракте, в реальности требования менялись постоянно, а после первого пройденного спринта стало понятно, что множество деталей, неизвестных на момент первоначальной оценки требований, неизбежно приведут к итоговому росту объема работ. Единственным возможным способом удержать рост объема работ под контролем для нас являлся постоянный поиск решений, минимизирующих затраты на разработку, опирающихся на возможности платформы, либо требующие чуть больше рутинных операций от пользователей (естественно, только с их согласия).Для того, чтобы иметь возможность направлять мышление заказчика в нужное русло, в нашей команде был выделен отдельный человек (талантливый разработчик и тех лид) на роль, которую мы назвали Technical Product Owner. В его обязанности входило постоянное общение с командой заказчика, выяснение деталей по требованиям, поиск самого простого решения и убеждения заказчика в том, что решение применимо к поставленным требованиям. После окончания первого спринта к этим обязанностям добавилось также анализ фидбека, определение, что из этого баги, а что change request’ы. Кроме того, будучи опытным разработчиком, TPO постоянно думал об архитектуре приложения, следил за тем, чтобы требования не противоречили ей, а также, совместо с тех-лидом проекта, формулировал технические решения для того, чтобы команда не тратила на это время, а занималась непосредственно реализацией. Иногда для этого требовалась помощь программистов,для этого в бэкло добовлялисьtechnical spike задачи с целью найти несколько вариантов реализации, из которых TPO и TL затем выбирали оптимальный. Работа с требованиями являлась ключевым фактором успеха проекта и продолжалась вплоть до последнего спринта. Поскольку вновь появляющиеся change request’ы постоянно увеличивали общий объем работ, product owner занимался change management’ом – поддержанием общего объема работ на уровне, зафиксированном в контракте (кол-во стори-поинтов), замещаяя менее приоритетные истории более приоритетными change request’ами.
- Одной из моих основных задач являлось устранение препятствий, мешающих исполнению задуманного плана и контроль за его исполнением путем сравнения фактических результатов, достигнутых по окончании спринта с запланированными показателями по объему работ.Для этого еще до начала проекта был составлен график, на котором наглядно отображалась кривая планового выполнения работ, кривая фактически выполненного объема работ за прошлые спринты и экстраполяция выполнения объема работ на оставшиеся спринты, а также кривая общего объема работ.
- О том, как строилась кривая планового выполнения работ, я уже рассказал во второй части своего доклада. Кривая фактичесик выполненного объема работ строилась по окончании каждого спринта, как общее количество историй (в story points), которые мы смогли передать на тестирование заказчику. В тестирование мы передавали лишь те истории, по которым были выполнены все девелоперские и тестерские задачи (за исключением задач по автоматизации, которые иногда переносились на следующий спринт) и у которых отсутствовали критические (blocking) баги, мешающие выполнению приёмочных тест-кейсов. Экстраполяция по объему работ на оставшиеся спринты строилась из усредненной фактической скорости работы команды за прошедние спринты в расчете на одного девелера, помноженной на количество ‘работающих’ девелоперов в каждый из оставшихся спринтов.Наконец, кривая общего объема работ считалась как сумма всех стори поинтов для историй в бэклоге. Имея на руках все эти цифры, строился такой график:
- С течением времени, многие из требований подвергались переосмыслению и дополнениям, поэтому было необходимо произвести переоценку оставшегося объёма работ на середине проекта, для того, чтобы понять, насколько сильно он отличается от первоначального. В ходе переоценки команда (TPO, PO, тех лид и QA лид) еще раз обсуждала все неареализованные истории, обсуждали новые детали, спрашивание мнение заказчика (иногда требования сильно менялись после того, как заказчик мог видет “вживую” работу нового сайта). Для тех историй, где оценка отличалась от первоначальной, командой приводились аргументы, объясняющие, чем вызвано изменение в оценке. В остальном процесс переоценки совпадал с тем, что мы использовали в начале проекта, также давались риски и делались предположения. Их, разумеется, было уже много меньше, так как большая часть деталей была нам уже известна. По результатам переоценки стало понятно, что общий объём работ вырос примерно на 20%. Имея перед глазами график экстраполяции объема работ, стало понятно что команда не успеет сделать все истории до конца проекта. Эти данные были показаны руководству компании заказчика, после чего количство историй было уменьшено до уровня, который было под силу выполнить команде.
- Стоит отметить, что подход, описанный в докладе, конечно же, имеет свои недостатки. Два наиболее важных из них – снижение производительности и падение качества, связанные с ростом численности команды. Если посмотреть на диаграмму отношения кол-ва дефектов на 1 SP, то станет видно, что к концу проекта эта величина неуклонно росла. Это было вызвано в первую очередь большим объёмом UI составляющей сайта, которая постоянно перекраивалась, в результате чего тут и там “ползла разметка”, особенно когда речь касается работы сразу в нескольких браузерах разных версий.
- В качестве основных методов предотвращения падения качества проекта использовалась автоматизация тестирования, которая включала в себя написание unit и integration тестов разработчиками, а также automation тестов тестировщиками. Для автоматизированного запуска тестов было выделенно несколько серверов, связанных с build и CI серверами. Туда ежедневно в полночь деплоилась сборки, на которых запускались integration и automation тесты. Unit-тесты запускались каждый раз после чек-ина, который также служил триггером для запуска CI билда. Наконец, ближе к концу фазы разработки на стороне заказчика была организована команда, которая занималась acceptance тестированием продукта, используя сценарии, базирующиеся на acceptance test –кейсах, и представлюящие из себя их различные комбинации с целью выявить слабо протестированные места до выхода в live.
- Сегодня уже можно говорить о том, что предложенный подход себя оправдал – мы выполнили требуемое количество story points, даже немного больше. Однако же, не все истории из бэклога оказались в итоге реализованными – уже в ходе проекта было добавлено много Change request’ов, которые в итоге вытеснили наименее приоритетные истории.В данный момент проект находится на заключительном этапе – Maintenance, а неделю назад заказчик выступил с предложением продлить фазу стабилизации для того, чтобы команда могла выполнить еще несколько важных change request’ов, а также провести работу над качеством продукта перед выходом в live.Вместо заключения, еще раз кратко перечислю выводы, сделанные мною: