Chaos Management: 2009

среда, 18 ноября 2009 г.

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

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

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

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

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

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


вторник, 17 ноября 2009 г.

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

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

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

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

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

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

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

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

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


вторник, 3 ноября 2009 г.

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


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

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

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

  1. Улучшить процедуру планирования ресурсов компании на ближайший месяц.
    Т.к. часть проектов работает по схеме fixed price, а часть по time and material, необходимо очень чётко понимать, когда, кто и сколько будет работать на каком проекте и кто будет за него платить.

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

  3. Наладить надёжный процесс перехода работников из проекта в проект (от менеджера к менеджеру), что бы исключить ситуации, при которых разработчики, аналитики, тестировщики и т.д., закончившие работать над задачами в одном проекте, «простаивают» какое-то время из-за того, что не знают, чем им дальше заниматься. А такое хоть и редко, но случается.

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

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

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

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

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

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



среда, 27 мая 2009 г.

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

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

Недавно меня пригласили на конференцию 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/


среда, 20 мая 2009 г.

PMBOK Guide 4th Edition уже доступен в виде PDF файла для участников PMI

pmbok4

Привет!

Всем зарегистрированным участникам PMI доступен полный PMBOK Guide четвёртого издания на английском языке. На русском – только часть.

Я уже скачал и уже читаю. Примечательно, что скаченный PDF-файл именной и запаролен моим паролем от сайта PMI.

Да, чуть не забыл, PMBOK Guide 4th Edition на английском, русском и других языках можно скачать отсюда:

http://www.pmi.org/Resources/Pages/Members/Library-of-PMI-Global-Standards-Projects.aspx

Скачивайте и наслаждайтесь (те, у кого есть доступ =)


вторник, 19 мая 2009 г.

SCRUM и XP - успехи внедрения и планы на будущее

Привет!

Прошедшие два месяца занимались с командой переходом на “методологию” SCRUM. Не забавы ради, а по необходимости.

Основное ядро системы мы уже выпустили в прошлом году, и последние полгода занимаемся наращиванием функциональности по требованиям наших заказчиков. При этом представителей заказчика достаточно много – это и маркетологи, и аналитики, и люди от бизнеса, и внешние эксперты по UI и usability, и субподрядчики и кого только нет! И всеми этими людьми, их требованиями на изменение системы и на её доработку нужно управлять. Чем я и занимаюсь по сей день =)

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

Проанализировав сложившуюся ситуацию мы решили – SCRUM спасёт отца русской демократии!

Начал я с того, что разослал всем членам команды на прочтение замечательную книгу “Scrum и XP: заметки с передовой”. Сам прочитал её три раза. Вообще говоря, эта книга в первый месяц была моей настольной и очень мне помогла не наступить на различные грабли, которые валялись то тут, то там на нашем пути ) Спасибо авторам и переводчикам!

В итоге мы успешно завершили два спринта, и я начал приучать наших заказчиков к периодичности выпуска версий – раз в три недели. Сейчас получается так, что я являюсь и SCRUM-мастером и product-owner’ом в одном флаконе. Собираю требования со всех стейкхолдеров, аккумулирую их, организую серию встреч на которых проставляется Важность каждого требования (user story). Затем, всё по писанному…

Более того, мне, наконец, удалось подвести команду к тому, что бы они сами предложили внедрить две замечательные, на мой взгляд, практики из экстремального программирования – парное программирование и TDD. Верите или нет, но у нас получилось внедрить парное программирование! =) Сам до сих пор поверить не могу =) С TDD тоже дело идёт на лад.

dashboard

Следующая задача для меня – внедрить SCRUM в головы членов команды. Вот что я имею в виду. Раньше, при прежнем процессе, в команде было очень чёткое распределение ролей – дизайнеры, тестировщики, аналитики, архитектор, разработчики, менеджер. В случае, если аналитики что-то не успевали описывать для разработчиков или описывали не полностью, то разработчики кивали на аналитиков, дескать, они нам не подготовили, и сидели, ждали, когда будет обновлена спецификация (ТЗ). По SCRUM’у – вся команда ответственна за результаты спринта. Разделение ролей у нас сохранилось, пока сохранилось и отношение, с чем я всеми силами борюсь. Т.е. не должно быть ситуации, когда на мой вопрос (как product owner’a =) “почему до сих пор не готова эта user story в самой большой важностью” дев лид отвечает “тестировщики поганцы, не протестили! Иди (менеджер) попинай их!”. Я глубоко уверен в том, что за тестирование должен нести ответственность главный тестировщик, за архитектуру – архитектор, за аналитику – аналитик, за весь проект в целом – менеджер (это убеждение как-то глубоко во мне укоренилось и расставаться с ним я пока не спешу =). Но вот отношение к своим обязанностям, я считаю, нужно менять. Если нужно – я сам сижу и занимаюсь аналитикой, пишу техническую документацию для разработчиков, обсуждаю архитектуру, тестирую, помогаю с простой вёрсткой. Но со мной понятно – я менеджер. А вот когда внутри команды разработчики, видя прорехи в тестировании, самостоятельно предлагают помощь тестировщикам или, зная о системе больше юзабилити аналитика, подкидывают ему идеи, как можно реализовать то или иное требование более изящно и просто – это есть счастье для любого менеджера!

Вот к этому и идём =)