Привет!
Всем зарегистрированным участникам PMI доступен полный PMBOK Guide четвёртого издания на английском языке. На русском – только часть.
Я уже скачал и уже читаю. Примечательно, что скаченный PDF-файл именной и запаролен моим паролем от сайта PMI.
Да, чуть не забыл, PMBOK Guide 4th Edition на английском, русском и других языках можно скачать отсюда:
http://www.pmi.org/Resources/Pages/Members/Library-of-PMI-Global-Standards-Projects.aspx
Скачивайте и наслаждайтесь (те, у кого есть доступ =)
Привет!
Прошедшие два месяца занимались с командой переходом на “методологию” SCRUM. Не забавы ради, а по необходимости.
Основное ядро системы мы уже выпустили в прошлом году, и последние полгода занимаемся наращиванием функциональности по требованиям наших заказчиков. При этом представителей заказчика достаточно много – это и маркетологи, и аналитики, и люди от бизнеса, и внешние эксперты по UI и usability, и субподрядчики и кого только нет! И всеми этими людьми, их требованиями на изменение системы и на её доработку нужно управлять. Чем я и занимаюсь по сей день =)
Мы решили перейти от того процесса, который был принят у нас на этапе разработки первой версии продукта (фактически самой платформы, ядра системы). Раньше я применял что-то очень похожее на то, что описано в PMBOK третьего издания, только адаптированное под мой проект. Теперь, когда требований на доработки стало очень много, и когда бизнес стал требовать, что бы мы реагировали на изменения очень оперативно, прежний подход к управлению проектом перестал удовлетворять как меня, так и мою команду. Поэтому мы решили измениться.
Проанализировав сложившуюся ситуацию мы решили – SCRUM спасёт отца русской демократии!
Начал я с того, что разослал всем членам команды на прочтение замечательную книгу “Scrum и XP: заметки с передовой”. Сам прочитал её три раза. Вообще говоря, эта книга в первый месяц была моей настольной и очень мне помогла не наступить на различные грабли, которые валялись то тут, то там на нашем пути ) Спасибо авторам и переводчикам!
В итоге мы успешно завершили два спринта, и я начал приучать наших заказчиков к периодичности выпуска версий – раз в три недели. Сейчас получается так, что я являюсь и SCRUM-мастером и product-owner’ом в одном флаконе. Собираю требования со всех стейкхолдеров, аккумулирую их, организую серию встреч на которых проставляется Важность каждого требования (user story). Затем, всё по писанному…
Более того, мне, наконец, удалось подвести команду к тому, что бы они сами предложили внедрить две замечательные, на мой взгляд, практики из экстремального программирования – парное программирование и TDD. Верите или нет, но у нас получилось внедрить парное программирование! =) Сам до сих пор поверить не могу =) С TDD тоже дело идёт на лад.
Следующая задача для меня – внедрить SCRUM в головы членов команды. Вот что я имею в виду. Раньше, при прежнем процессе, в команде было очень чёткое распределение ролей – дизайнеры, тестировщики, аналитики, архитектор, разработчики, менеджер. В случае, если аналитики что-то не успевали описывать для разработчиков или описывали не полностью, то разработчики кивали на аналитиков, дескать, они нам не подготовили, и сидели, ждали, когда будет обновлена спецификация (ТЗ). По SCRUM’у – вся команда ответственна за результаты спринта. Разделение ролей у нас сохранилось, пока сохранилось и отношение, с чем я всеми силами борюсь. Т.е. не должно быть ситуации, когда на мой вопрос (как product owner’a =) “почему до сих пор не готова эта user story в самой большой важностью” дев лид отвечает “тестировщики поганцы, не протестили! Иди (менеджер) попинай их!”. Я глубоко уверен в том, что за тестирование должен нести ответственность главный тестировщик, за архитектуру – архитектор, за аналитику – аналитик, за весь проект в целом – менеджер (это убеждение как-то глубоко во мне укоренилось и расставаться с ним я пока не спешу =). Но вот отношение к своим обязанностям, я считаю, нужно менять. Если нужно – я сам сижу и занимаюсь аналитикой, пишу техническую документацию для разработчиков, обсуждаю архитектуру, тестирую, помогаю с простой вёрсткой. Но со мной понятно – я менеджер. А вот когда внутри команды разработчики, видя прорехи в тестировании, самостоятельно предлагают помощь тестировщикам или, зная о системе больше юзабилити аналитика, подкидывают ему идеи, как можно реализовать то или иное требование более изящно и просто – это есть счастье для любого менеджера!
Вот к этому и идём =)
