Файл: Кафедра ивс курсовой проект дисциплина Управление программными проектами Тема Agile в it приняла Головачёва В. Н.. (оценка) (фамилия, инициалы).docx

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

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

Чаще всего в этот момент оценки различаются очень сильно. На деле это совсем неплохо. Когда оценки различаются, оценщики с максимальным и минимальным результатами объясняют причину своего выбора. Очень важно, чтобы здесь на оценщиков не обрушилась критика. Нам нужно лишь выяснить, что заставило их прийти к такому мнению. Например, оценщик с максимальным результатом может сказать: «Ну, чтобы протестировать эту историю, нам нужно создать мок-объект. На это может уйти целый день. Кроме того, я не уверен, что стандартный алгоритм сжатия будет эффективен, а раз так, то нам, возможно, придется писать новый». Оценщик с минимальным результатом может сказать: «Я полагал, что мы будем хранить эту информацию в XML-файле — это было бы легче, чем создавать базу данных. К тому же я не подумал об увеличении объема данных — это может стать проблемой».

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

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

Правильная продолжительность дискуссии

Предварительное обсуждение дизайна всегда полезно для оценки. Вместе с тем чересчур длительное обсуждение приводит к слишком сильному смещению команды вправо по кривой «усилия/точность» (рис. 6.1). Существует простой способ поддержать дискуссию, но не дать ей затянуться.

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

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

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

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

Во-первых, покер планирования сводит вместе мнения нескольких экспертов и позволяет получить общую оценку. Поскольку эти эксперты образуют кроссфункциональную команду, представляющую все дисциплины софтверного проекта, они более компетентны в сфере оценки, чем кто-либо другой. На основе тщательного анализа литературы по оценке программного обеспечения Йоргенсен (Jørgensen, 2004) пришел к выводу, что «оценивать задачи должны те, кто наиболее компетентен в их выполнении».

Во-вторых, в процессе игры в покер планирования возникает живой диалог, и оценщики обращаются к мнению коллег для подтверждения своих оценок. Это повышает точность оценки, особенно когда дело касается объектов со значительным уровнем 54 неопределенности (Hagafors and Brehmer, 1983). Обращение за подтверждением оценок в определенной мере компенсирует недостаток информации (Brenner at al., 1996). Это очень важно в agile-проекте, поскольку оцениваемые пользовательские истории нередко намеренно составляются нечетко.

В-третьих, исследования показывают, что усреднение индивидуальных оценок дает лучшие результаты (Hoest and Wohlin, 1998), как и коллективное обсуждение оценок (Jørgensen and Moløkken, 2002). Коллективное обсуждение является основой покера планирования, а такие обсуждения ведут к усреднению различных индивидуальных оценок.

Наконец, покер планирования работает, потому что это занятие доставляет удовольствие.

Практическая часть

3.1. Внедрение Agile в работу компании

Так как я являюсь сотрудником одной из IT компаний в нашем городе. Могу на собственном примере донести процесс изменения механизмов работы компании с внедрением Agile в наши проекты, а также на уровне всей компании.
Проблемы, которые предстояло решить:

Устаревшее программное обеспечение, заменить которое казалось практически невозможным из-за сложной работы сервисов.

«Сакральные» знания о проекте сосредоточены в руках нескольких сотрудников. Это делало их практически незаменимыми: когда люди уходили, компания сталкивалась с трудностями.

Низкая скорость разработки и низкое качество продуктов.

Отставание от конкурентов в технологическом плане и потеря ключевых клиентов.

Текучка среди разработчиков. Молодые специалисты зачастую уходили, не проработав в компании даже года. Это проблема всего рынка.

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

3.2. Изменения в работе компании

В Agile как таковых руководителей нет, но у каждой команды есть ответственное лицо — Product Owner.

«Расстались с руководителями»

Они оказались не нужны в чистом виде. Им нужно было или быть разработчиками, или становиться Product Ownerʼами.
Важно!

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

Например, сервис отчетов, которым пользуются клиенты компании, устарел; решили создать новый и красивый. Раньше руководитель мог отдать приказ: сделайте новый сервис отчетов. Но теперь в компании стали работать иначе. Сперва Product Owner обсуждает с клиентами разные гипотезы — например, как может выглядеть новый сервис отчетов. То есть осуществляет сбор пожеланий пользователей.

Дальше команда делает маленькие шаги. К примеру, принимает решение сделать backend — разобраться, как эти данные будут храниться и показываться, как будет выглядеть меню. То есть разрабатывается простой, примитивный продукт, с которым тем не менее уже могут взаимодействовать пользователи. После этого приступают к следующему шагу разработки.

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

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

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

В Agile нет места хаосу, каждое нововведение должно быть четко обосновано

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

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

3.3. 3 принципа найма новых людей в команду

Мотивация

Человек должен объяснить, почему хочет работать в компании. Если у него нет никакой цели в жизни, никакого плана — это плохой знак, его надо будет «качать».

Насколько вписывается в ценности компании

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

Достаточно ли у него знаний, навыков

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

3.4. Внедрение кросс-дисциплины t-shape

Этот элемент Agile, он означает осваивание новых знаний. Все в команде должны «говорить на одном языке», каждый должен стремиться расширить свой бэкграунд. Участники проекта должны быть специалистами в какой-то области, но при этом хорошо понимать кросс-дисциплинарные вещи.

Схематическое отображение t-shape

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

3.5. Обучение Product Owner

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