1. К онференция S tratoplan World. Kharkov edition К руглый стол «Методологический паззл»
2.
3.
4.
5. Что это все значит? Что с этим делать? Стандарты Модели, фреймворки, своды знаний Типы контрактов Типы проектов Методологии Инженерные и Управленческие практики Фазы проекта
12. Взгляд Исполнителей Внутренние и внешние стандарты, СМК Модели, фреймворки, своды знаний Что Как Инженерные и управленческие практики
13. Взгляд Исполнителей Внутренние и внешние стандарты, СМК Методологии Модели, фреймворки, своды знаний Что Как Структура Инженерные и управленческие практики
14. Взгляд Исполнителей Внутренние и внешние стандарты, СМК Методологии Модели, фреймворки, своды знаний Что Как Структура Инженерные и управленческие практики Адаптация под проект ( Tailoring )
22. Конструктор Окружающая среда проекта Типы проектов Прототип Требования Проектирование Реализация Релизы Waterfall Fixed price T&M CR SCRUM
23. Конструктор Окружающая среда проекта Типы проектов Жизненный цикл проекта Прототип Сбор треб. Реализация Прототип Требования Проектирование Реализация Релизы Waterfall Fixed price T&M CR SCRUM
Меня зовут Тимофей Еграшин и я занимаюсь управлением проектами уже около девяти лет. Я пробовал разные подходы и всегда стремился не повторять своих ошибок. Года четыре назад, я понял, что лучшие мои проекты имели все характеристики Agile проектов, а с тех пор как я узнал больше о Scrum , я использую его как основу для организации проектов с которыми я работаю.
Несколько слов о нас. Все команды являются внутренними командами разработки крупной скандинавской медиа корпорации. Будучи внутренними командами мы получили очень тесное сотрудничество с заказчиками. Зачастую разработчики и заказчик могут сидеть в соседних комнатах. В тоже время, будучи частью корпорации мы должны считаться с корпоративными правилами и зачастую для установки внутреннего сервиса типа вики, команда обращается к корпоративному IT департаменту как обычный заказчик, со всеми вытекающими взаимодействиями и возможными задержками такого, казалось бы простого дела. Когда команды только собирали, руководство отдела разработки оказало поддержку идеи использовать Scrum как основную методологию организации взаимодействия и управления командами. Мы уже сегодня могли слышать, что «поддержка сверху» всегда помогает на старте. В тоже время, команды выделены под конкретные бизнес-подразделения и это не освобождает нас от необходимости выстроить взаимоотношения заказчик-подрядчик и по дороге объяснить как мы будем работать, кто что делает и т.п.
Команда Б: +Занимается разработкой серии схожих он-лайн проектов. Это по сути интернет-газеты, думаю многие читают Корреспондент. net , который можно частично использовать как аналогию +Такие контент-ресурсы всегда связаны с разными источниками информации и кроме внутренней редакции есть еще много партнеров с которыми необходимо интегрироваться. Иногда незаметно, сопровождая это соответствующим брендингом разделов и так далее +Любой газетный бизнес, особенно Интернет-газета это быстрая смена приоритетов и требований. Иногда граничащий с хаосом. +Веб проекты в целом и такой бизнес в частности, очень требовательны к регулярной публикации результатов работы. Т.е. Тут действительно идет речь о выпуске в он-лайн результатов каждого спринта, а иногда и чаще. Сама Scrum команда изначально была распределена между двумя странами. Команда действительно кросс-функциональная и включает как разработчиков так и тестеров
Прежде чем идти дальше, я хочу вкратце рассказать как мы начинали: 1. Как я говорил, мы изначально решили строить все процессы на основе Scrum – это было объявлено бизнесу в целом и каждому кандидату в частности 2. Каждая команда со старта получила ScrumMaster’ а, который кроме того, что имел уже опыт лидера команды, так же прошел курс Certified ScrumMaster , что позволило говорить о хорошем начальном уровне СкрамМастеров 3. Более того, сразу как только команды были укомплектованы, они прошли совместный вводный тренинг, где члены команды и владельцы продукта узнали о том «зачем» мы работаем по Scrum и как именно мы собираемся его делать. 4. Ну и при поддержке руководства мы получили выделенных Владельцев Продукта, которые с самого начала знали об ожидаемых обязанностях и ответственности, которые подразумевает эта роль
Если первая команда была крайностью в отношении релизов, то у второй команды работа идет постоянно, вне зависимости от наличия хоть сколь-нибудь сфокусированных проектов Как я говорил, проекты у этой команды очень маленькие и максимум длятся пару спринтов Каждый спринт заканчивается не просто демонстрацией, а публикацией результатов в «лайв», где сайты посещают тысячи людей каждый день. Это ведет к тому, что все, что команда заявляет как «Сделано», должно быть готово к публикации без дополнительных работ. В таких условиях, необходимости планировать долгосрочные релизы просто нет. Для тех мини-«проектов», которые я упомянул достаточно наглядно можно отследить отношение Сделано/не Сделано, что дает ВП ясное представление о ситуации.
Жизнь второй команды сложно назвать размеренной Сам по себе газетный бизнес подвержен очень быстрым изменениям К тому же, реализация может отличатся от ожидаемой сложности, так как есть много маленьких факторов каждодневного риска. Например, внешний поставщик информации еще не готов к интеграции и команде приходится строить решения с разного рода заглушками. Или наоборот, казалось бы простая функция потребовала изменения других областей или обобщения существующих функций в единую библиотеку. Бывают и хорошие ситуации, когда команда делает сложную работу быстро О, а еще бывают «пожары», когда происходят сбои на он-лайн серверах. Система достаточно сложная и бывают ситуации, когда администраторы из поддержки обращаются за помощью к разработчикам и тогда команда откладывает свои планы и разбирается в ситуации. Лучший совет в такой ситуации, это расслабиться и получать удовольствие. Самый главный шаг был сделан ВП – он поинмает ситуацию и всегда готов к диалогу, если команда в силу объективных причин не успевает сделать первоначальный план
У команды Б, ретроспективы проходят между разработчиками, так как только они отвечают за совершенствование своих методов и подходов Несмотря на все описанное мной тесное взаимодействие между ВП и командой, не стоит забывать, что он все-таки человек бизнеса и не всегда хорошо понимает «технический язык» Ретроспективы проходят как анализ последних значимых событий или как тематические обсуждения долгосрочных планов развития и улучшения. Обычно выбирают договариваются об 1-2 изменениях на следующий спринт, формируют план действий И результаты сообщают ВП, особенно если требуются инвестиции времени во внутренние технические работы Кроме регулярных встреч, раз в год команда старается проводить глобальную ретроспективу, чтобы проанализировать чего успели добиться за год и какие основные цели должны быть достигнуты
![Содержание ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)