PMI-Agile Certified Practitioner (PMI-ACP)

PMI начал приём заявок на сдачу экзамена на сертификат PMI-Agile Certified Practitioner (PMI-ACP). Первые экзамены начнутся в конце ноября этого года.
Доступны следующие материалы для подготовки:
✔ Review the PMI-ACP credential handbook.
✔ Review the PMI-ACP Examination Content Outline
✔ Review the current reference list for the PMI-ACP certification

Интересно, что будет с "сертификатами" от Scrum-альянса через года полтора-два?



- iЗаписка на ходу

Best practices check list

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

После того, как некое улучшение было выбрано, опробовано и одобрено командой, мы «обкатываем» его ещё пару-тройку спринтов. После этого, если это улучшение нам действительно помогает и нравится, то мы переводим его в разряд best practices и переносим в отдельный список в Confluence проекта, который называется «Что  прижилось и работает (продолжаем использовать)» =)

Т.к. best practices не являются священными и неприкосновенными, мы на каждой ретроспективе пробегаем по этому списку и:

1. Проверяем, что мы не забыли следовать практикам из этого чек-листа, а если забыли, то анализируем почему.
2. Обсуждаем (быстро-быстро), действительно ли каждая практика из этого списка всё ещё является «best» и если нет, то убираем её из этого списка.

Таким образом мы следуем принципам кайдзен, который, вообще говоря, «косо смотрит» на best practices в привычном их понимании.

Небольшой пример того, что у нас может попасть в список «Что  прижилось и работает (продолжаем использовать)»:

• Ограничить количество задач, которые могут находиться в состоянии WIP (N-1) - вынужденное парное программирование, нацеленность на скорейший резуьтат. Если фича в тестировании и найдена ошибка - переходит обратно в процесс, одна фича из процесса уходит (прокачиваем: уменьшение времени, необходимого для подготовки фичи к приёмки заказчиком на стейдже, коллективное владение кодом, кросфункциональность команды).
  
• Деплой не может начаться позднее 15:00. Т.е. если заказчик требует внести изменения после 15:00 или до 15:00 не даёт отмашку на деплой - выкат переносится на следующий день. Это согласовано с заказчиком. Мы, в свою очередь, уведомляем заказчика о реализованных фичах сразу после их исполнения.
  
• Дважды в неделю проводим технический standup meeting на котором каждый рассказывает про то, как именно он реализовал, реализует и собирается реализовать тот или иной функционал (архитектура, подход и т.д.). Командное ревью архитектуры и кода. Длительность не более получаса. Привлекаем разработчиков и архитекторов из других команд. Заранее планируем, чтобы люди приходили (прокачиваем: качество кода, коллективное владение кодом, кросфункциональность команды).
  
• Деплойментом занимается каждый член команды по очереди и в паре с кем-то (прокачиваем: кросфункциональность команды).

Бэклог улучшений

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

А что делать с теми улучшениями, которые набрали меньше голосов, но при этом являются так же важными и интересными? Мы стали их записывать в отдельный список в Confluence проекта. К этому списку имеет доступ вся команда (да и вся компания) и в любое время дня и ночи любой член команды может дополнить данный список любым своим предложением.

На каждой ретроспективе мы просматриваем наш бэклог улучшений и выбираем те, которые мы будем пробовать в следующем спринте.

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

Небольшой пример того, что у нас находится в бэклоге:

• В дополнению к фокус-фактору и качеству кода добавить ещё один показатель для оценки процессов - субъективную удовлетворенность работой команды.
• Составлять план демо самостоятельно во время работы над спринтом каждым участником комманды.
• Тренировка действия в случаях крит. ситуаций на проде.
• Составить RoadMap по рефакторинга всего кода и выделению модулей из продукта.
• Расшарить знания по JS - вернуть уроки по JS.

Презентация тест плана в начале каждой итерации

Давно используем одну интересную практику в наших проектах – на следующий день после планирования очередной итерации тестировщик презентует всей команде тест-план на данную итерацию.

Презентация проходит следующим образом. У тестеровщика в TestLink на каждую итерацию (версию) имеется свой набор тестовых сценариев. При этом каждая история из бэклога (если это SCRUM-команда) или каждый вариант использования из спецификации должен быть покрыт тестовым сценарием. Тестировщик рассказывает команде, как именно он собирается тестировать тот или иной вариант использования, перебирая по очереди все тестовые сценарии. При этом у команды возникает масса пожеланий на расширение тестовых сценариев, оговорок, а так же уточнений по функционалу. По результатам такого ревью тестировщик обновляет тестовые сценарии, а аналитик, если требуется, корректирует спецификацию.

Данная практика способствует тому, что вся команда (и product owner, если он присутствует) одинаково понимает, что именно будет сделано и в чём суть каждой задачи. Так же снижаются риски связанные с поздним тестированием.

Метрики – качество оценки

Одна из полезных метрик, которую мы собираем на проектах, которые идут у нас по SCRUM – это подсчёт отношения запланированного на реализацию задачи времени к реально потраченному на них времени.

На ретроспективе, при рассмотрении того, что как шло в спринте, мы обращаем особенное внимание на задачи, у которых это отношение равно или превышает 1,5 или меньше или равно 0,6. Понимая, почему на реализацию той или иной задачи у нас ушло гораздо больше/меньше времени, чем планировалось, мы придумываем что-то, что в будущем делает наши оценки подобных задач более точными или уменьшает неопределённость на ранней стадии работ над задачей, что позволяет сделать переоценку как можно быстрее.

Пример такие действий: выделение отдельной задачи на интеграционное тестирование или включение в историю задачи по предварительному исследованию предметной области.

Kanban – ещё раз о том, когда и где применять

Здравствуйте!

Недавно на сайте Константина Быченкова прочёл заметку под названием «Обратная сторона канбан», в которой Константин описывает то, что обязательно нужно учитывать при выборе данного подхода УП.

Согласен со всеми, что описал Константин в случае, если речь идёт о работе над проектом (в классическом его понимании). В этом случае решение о применении Kanban должно быть очень взвешенным и продуманным.

Но, хочу поделиться небольшим опытом применения Kanban в компании, в которой я сейчас работаю. Нам удалось успешно использовать Kanban на проекте, который больше похож на операционную деятельность: постоянные небольшие доработки уже внедрённого продукта. При этом заказчик хорошо знает, что он хочет, знает с какими ограничениями и рисками работает команда проекта, знает и принимает правила, по которым идёт “игра”, а главное, что между командой и заказчиком есть доверие. К тому же на этом проекте мы с заказчиком работаем по схеме "time and material", поэтому заказчик волен в любое время менять приоритеты своих запросов на изменения и доработку, а у разработчиков и менеджера нет истерии по поводу выхода за рамки бюджета или срыва сроков. Все довольны.

Так что применение Kanban, на мой взгляд, может быть вполне оправданным и эффективным в одних случаях, и крайне опасным и даже вредным в других… собственно, как и любой другой подход или методология УП =)

“Синтетические” методы оценки программных проектов

Здравствуйте!

В прошлой заметке я писал о том, что перед недавно созданным офисом управления проектами (PMO) были поставлены ряд задач. С задачами 1 и 3, а именно планированием ресурсов и переходом сотрудников из проекта в проект, мы временно разобрались. Вернее сделали первые простые шаги, в конце месяца по результатам сделаем корректировку.

Далее я решил замахнуться на то, что до меня так никто и не осилил – освоить, внедрить и научить других, применять одну из методик численной оценки программных проектов с которыми нам приходится работать (особенно на этапах пресейла, когда высокой точности достигнуть невозможно в принципе). Необходимость наличия такой методики я описывал в пункте 4 предыдущей заметки. Вообще говоря, для некоторых новых проектов, которые по своей сути были очень похожи на те, что мы уже реализовывали ранее с командой, и в которых технологические риски были минимальны, я вполне точно делал и продолжаю делать оценки на основании исторических данных. Зная производительность конкретно взятой команды, а так же метрические показатели других схожих проектов соотнесённые с фактическими трудозатратами и длительностью, получается достаточно точно оценить будущий проект (итоговое расхождение оценки и фактических затрат зачастую равняется +/- 10%). Но для проектов, в которых планируется использовать новые технологии, команда для которых ещё не сформирована и при этом приходится вникать в предметную область бизнеса нового заказчика, такой подход не подходит по понятным причинам.

Так вот… Собрал я всё PMO, помозгоштурмили, подумали с какого конца подойти к решению данной задачи и на каких методиках остановиться. В итоге решили следующее: взять три уже законченных проекта, по которым имеется хорошие исторические данные, а именно:

• начальные требования заказчика в том виде, в котором они к нам поступили, когда мы делали оценку;
• наша начальная оценка;
• реальные трудозатраты и время, потраченное на реализацию и закрытие проекта с разбивкой по задачам и людям;
• извлечённые уроки;

Каждый менеджер берёт по проекту (только не тому, над которым он сам работал) и на основании первоначальных требований от заказчика рассчитывают ожидаемую трудоёмкость по двум методикам: классический метод оценки по функциональным точкам и его модификация - Mark 2. Затем на очередной встрече PMO мы посмотрим как “синтетические” оценки соотносятся с оценками, сделанными нами ранее до начала проекта, а так же с фактическими результатами. По результатам такого сравнения и анализа того, как были сделаны “синтетические” оценки, можно будет откалибровать расчётные коэффициенты и, возможно, немного модифицировать методику под специфику наших проектов.

О результатах напишу позже.

Кстати, если у читателей данной заметки есть опыт применения такого рода методик оценки – поделитесь, пожалуйста, опытом, посоветуйте что-нибудь – буду премного благодарен =)

Офис управления проектами - начало

Здравствуйте!

Совсем недавно меня назначили руководителем офиса управления проектами… В связи с этим передо мной возникла задача построения самого офиса управления проектами, т.к. до сих пор такой структуры в нашей компании не было. Исходя из всего того, что я читал про офис управления проектами (project management office или кратко PMO) я начал по методу набегающей волны разрабатывать планы по построению этого самого PMO внутри нашей компании.

Первое, что я сделал, это подошёл к начальству и менеджерам и спросил, что именно они ждут от PMO в первую очередь. Выяснилось, что примерно в следующем порядке необходимо оптимизировать прежде всего следующие активности:

1. Улучшить процедуру планирования ресурсов компании на ближайший месяц.
   Т.к. часть проектов работает по схеме fixed price, а часть по time and material, необходимо очень чётко понимать, когда, кто и сколько будет работать на каком проекте и кто будет за него платить.
   
   
2. Собрать метрики по всем существующим проектам в одно место и привести их, по возможности, к единому виду.
   Это значительно упростит и ускорит их использование при оценке новых проектов (пресейлы), а так же при извлечении уроков по проекту после его завершения.
   
   
3. Наладить надёжный процесс перехода работников из проекта в проект (от менеджера к менеджеру), что бы исключить ситуации, при которых разработчики, аналитики, тестировщики и т.д., закончившие работать над задачами в одном проекте, «простаивают» какое-то время из-за того, что не знают, чем им дальше заниматься. А такое хоть и редко, но случается.


4. Создать единую для компании методологию для оценки новых проектов.
   Это нужно, прежде всего, для того, что бы на этапе пресейла минимизировать время, которое затрачивается ведущими разработчиками, архитекторами и менеджерами для оценки потенциального проекта. Порой на это тратится неоправданно много времени.
   
   
5. Наладить постоянный надёжный процесс обмена положительным и отрицательным опытом между всеми командами в компании.
   Сейчас некоторые менеджеры после сдачи проекта проводят, как это называется в SCRUM’е, demo-показы, на которые приглашаются все желающие и на которых показывается продукт, над которым работала команда, рассказывается вкратце о его функционале, применённых технологиях, об успешном опыте и возникших проблемах. Думаю внедрить эту практику во всех командах.

И далее уже идёт список задач более общего характера и менее высокого приоритета.

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

Если у вас есть опыт по решению проблем, описанных мной в этих пяти пунктах – пишите, буду рад советам!

Да, забыл сказать, речь идёт о небольшой (менее 50 чел.), но давно работающей и стабильной компании с проектной структурой. Поэтому все в компании являются сторонниками небольших, но постоянных, изменений, нежели глобальных реформ за короткое время. Такой подход позволяет быстро вносить изменения в процессы на основании постоянно получаемой обратной связи, а так же достаточно быстро и эффективно подстраиваться под потребности заказчика.

Конференция Software People 2009

Здравствуйте!

Недавно меня пригласили на конференцию Software People 2009, которая проходила 21-22 мая.

Если кратко, то лично я ожидал от этого мероприятия большего.

Мне понравился доклад, описывающий возможности Windows Azure для разработчиков, а так же перспективы использования Windows Azure для бизнеса.

После рассказа про возможности интеграции TFS с MS Project я понял для себя, что пока точно не буду использовать эти два продукта в связке – сыровато и неудобно.

Из доклада по Continues Integration узнал несколько полезных штук. Например, о том, что в систему автосборки можно вставить модуль от BlackDuck по проверке кода, используемых модулей и библиотек на предмет их лицензии – полезно для тех, кто разрабатывает коммерческие продукты при этом используя open source. Подробнее смотри на http://www.blackducksoftware.com/. Из того же доклада я почерпнул идею о т.н. fly builds. Идея в том, что перед тем, как система хранения кода разрешает разработчику сделать check in в общий репозиторий, проводится билд модуля, в который внесены изменения и в случае, если билд не прошёл, код не чекинится.

Доклад под названием “Эффективное определение и описание требований как необходимое условие успеха проекта” оказался обычной (по правде говоря, скучноватой) демонстрацией продукта IBM Rational Requirements Composer, который позволяет собирать требования и прототипировать GUI будущего приложения.

Было несколько рассказов и докладов по Agile, но ничего нового для себя на них я, к сожалению, не услышал.

Резюмируя, могу сказать, что скучно не было, но и ничего сверх интересного тоже.

С программой конференции, некоторыми материалами и презентациями можно ознакомиться на сайте http://www.softwarepeople.ru/