К онференция S tratoplan World. Kharkov edition К руглый стол «Методологический паззл»
Содержание  <ul><li>Марафон </li></ul><ul><li>Методологическое интро </li></ul><ul><ul><li>Сергей Поволяшко </li></ul></ul...
<ul><li>Методологическое интро </li></ul><ul><ul><li>Сергей Поволяшко </li></ul></ul>
<ul><li>Стаж в IT с 1996 года. </li></ul><ul><li>C  2001 года работаю в области управления IT подразделений и проектов </l...
Что это все значит? Что с этим делать? Стандарты Модели, фреймворки, своды знаний Типы контрактов Типы проектов Методологи...
Модели, фреймворки, своды знаний <ul><li>ISO </li></ul><ul><li>CMMI </li></ul><ul><li>PMBOK </li></ul><ul><li>Home grown <...
Стандарты <ul><li>Системы Менеджмента Качества (СМК) на основе  ISO ,  CMMI  и т.п. </li></ul><ul><ul><li>Процессы </li></...
Инженерные, управленческие практики <ul><li>Планирование проекта </li></ul><ul><li>Проектирование ( software design ) </li...
Методологии <ul><li>Waterfall </li></ul><ul><li>Итеративные </li></ul><ul><ul><li>Релизы, итерации </li></ul></ul><ul><ul>...
Взгляд Исполнителей Инженерные и управленческие практики
Взгляд Исполнителей Модели, фреймворки, своды знаний Что Инженерные и управленческие практики
Взгляд Исполнителей Внутренние и внешние стандарты, СМК Модели, фреймворки, своды знаний Что Как Инженерные и управленческ...
Взгляд Исполнителей Внутренние и внешние стандарты, СМК Методологии Модели, фреймворки, своды знаний Что Как Структура Инж...
Взгляд Исполнителей Внутренние и внешние стандарты, СМК Методологии Модели, фреймворки, своды знаний Что Как Структура Инж...
Взгляд Бизнеса, Продаж
Взгляд Бизнеса, Продаж Типы контрактов Типы проектов Фазы проекта Окружающая среда проекта
Окружающая среда проекта <ul><li>Бизнес цели </li></ul><ul><li>Ограничения </li></ul><ul><li>Способности </li></ul><ul><li...
Типы проектов <ul><li>Новый </li></ul><ul><li>Развитие </li></ul><ul><li>Поддержка </li></ul><ul><li>Сложность </li></ul><...
Фазы проекта <ul><li>Исследование ( Feasibility Study ) </li></ul><ul><li>Прототип </li></ul><ul><li>Требования + План </l...
Типы контрактов <ul><li>Fixed Price </li></ul><ul><li>Time & Material </li></ul><ul><li>Cost Reimbursable </li></ul>Типы к...
Конструктор Окружающая среда проекта Типы проектов
Конструктор Окружающая среда проекта Типы проектов Прототип Требования Проектирование Реализация Релизы Waterfall Fixed pr...
Конструктор Окружающая среда проекта Типы проектов Жизненный цикл проекта Прототип Сбор треб. Реализация Прототип Требован...
Конструктор Контракт:  CR  T&M  FP Риски 100% 0% Заказчик Исполнитель
Конструктор Контракт:  CR  T&M  FP Заказчик Исполнитель Управление проектом
Конструктор Контракт:  CR  T&M  FP Заказчик Исполнитель Формализм и ответственность управления требованиями
Конструктор Реализация Внедрение Требования Проектирование + Планы Исследования Прототип Типы проектов: Сложность, новизна...
Конструктор <ul><li>Взаимодействие :  (1 –  низкое , 5 - высокое )  коммуникации, вовлечение участников, партнерство </li>...
Конструктор <ul><li>Рекомендации </li></ul><ul><li>Контракт:  FP </li></ul><ul><li>Формальное упр. Требованиями </li></ul>...
<ul><li>Подборка материалов: </li></ul><ul><li>http :// www.it-tuning.com / wp-content / uploads /2011/06/ swke / Methodol...
<ul><li>Кейс №1 </li></ul><ul><ul><li>Глеб Рыбалко </li></ul></ul>
Глеб Рыбалко <ul><li>5 лет опыта в тестировании и обеспечении качества </li></ul><ul><li>Участник рабочей группы по перево...
<ul><li>30  клиентов </li></ul><ul><li>200 дисков в день </li></ul>ITERATIVE !
Project team
 
Project
<ul><li>Scrum Master </li></ul><ul><li>Product Owner/Proxy Product Owner </li></ul><ul><li>Backlogs </li></ul><ul><li>Spri...
Tips&Tricks <ul><li>Перепланирование </li></ul><ul><li>Буфер </li></ul>
Что сейчас <ul><li>10% новой функциональности </li></ul><ul><li>90% поддержка и интеграция клиентов </li></ul><ul><li>80  ...
Что дальше? KANBAN ?
<ul><li>Кейс №2 </li></ul><ul><ul><li>Тимофей Евграшин </li></ul></ul>
Тимофей Евграшин <ul><li>Agile  коуч </li></ul><ul><li>Тренер по внедрению гибких методологий управления проектами ( Agile...
О ком пойдет речь <ul><li>Крупная медиа корпорация </li></ul><ul><li>Внутренний отдел разработки </li></ul><ul><ul><li>Тес...
Команда <ul><li>Много схожих коротких он-лайн  проектов </li></ul><ul><li>Внутренние и внешние поставщики информации </li>...
Важно <ul><li>Все процессы на основе  Scrum </li></ul><ul><li>Обученные Скрам мастера </li></ul><ul><li>Совместные вводные...
Как планирует релизы команда Б <ul><li>Работа идет  постоянно , независимо от «проектов» </li></ul><ul><li>Выпуск в « live...
Изменения требований в команде Б <ul><li>Быстрые изменения – естественное свойство бизнеса </li></ul><ul><li>Реализация от...
Ретроспективы в команде Б <ul><li>Проходят между разработчиками </li></ul><ul><li>Иногда это тематические обсуждения и дол...
<ul><li>Кейс №3 </li></ul><ul><ul><li>Татьяна Голубева </li></ul></ul>
ТАТЬЯНА ГОЛУБЕВА <ul><li>Около 9 лет в ИТ, более 4 лет в управлении людьми </li></ul><ul><li>Engineering Project Manager –...
Вводные <ul><li>Fixed price </li></ul><ul><li>Совокупная длинна подпроектов 3-5 недель </li></ul><ul><li>Однотипные подпро...
ИЗНАЧАЛЬНОЕ РЕШЕНИЕ <ul><li>Пирамидальная структура </li></ul><ul><li>За основу взято  ISO 9001 </li></ul><ul><li>Все проц...
К ЧЕМУ МЫ ПРИШЛИ ЗА 2 ГОДА <ul><li>Пирамидальная структура </li></ul><ul><li>Процессы периодически пересматривались, все ч...
МЕТОДОЛОГИЯ <ul><li>Это не  waterfall, RUP, v-model </li></ul><ul><li>Это не  CMMI, … </li></ul><ul><li>Это не  Agile ,… <...
Спасибо за внимание!
Upcoming SlideShare
Loading in …5
×

Слайдкаст. Stratoplan Kharkov. Методологический паззл.

2,938 views

Published on

Published in: Education, Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,938
On SlideShare
0
From Embeds
0
Number of Embeds
1,289
Actions
Shares
0
Downloads
1
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • Меня зовут Тимофей Еграшин и я занимаюсь управлением проектами уже около девяти лет. Я пробовал разные подходы и всегда стремился не повторять своих ошибок. Года четыре назад, я понял, что лучшие мои проекты имели все характеристики Agile проектов, а с тех пор как я узнал больше о Scrum , я использую его как основу для организации проектов с которыми я работаю.
  • Несколько слов о нас. Все команды являются внутренними командами разработки крупной скандинавской медиа корпорации. Будучи внутренними командами мы получили очень тесное сотрудничество с заказчиками. Зачастую разработчики и заказчик могут сидеть в соседних комнатах. В тоже время, будучи частью корпорации мы должны считаться с корпоративными правилами и зачастую для установки внутреннего сервиса типа вики, команда обращается к корпоративному IT департаменту как обычный заказчик, со всеми вытекающими взаимодействиями и возможными задержками такого, казалось бы простого дела. Когда команды только собирали, руководство отдела разработки оказало поддержку идеи использовать Scrum как основную методологию организации взаимодействия и управления командами. Мы уже сегодня могли слышать, что «поддержка сверху» всегда помогает на старте. В тоже время, команды выделены под конкретные бизнес-подразделения и это не освобождает нас от необходимости выстроить взаимоотношения заказчик-подрядчик и по дороге объяснить как мы будем работать, кто что делает и т.п.
  • Команда Б: +Занимается разработкой серии схожих он-лайн проектов. Это по сути интернет-газеты, думаю многие читают Корреспондент. net , который можно частично использовать как аналогию +Такие контент-ресурсы всегда связаны с разными источниками информации и кроме внутренней редакции есть еще много партнеров с которыми необходимо интегрироваться. Иногда незаметно, сопровождая это соответствующим брендингом разделов и так далее +Любой газетный бизнес, особенно Интернет-газета это быстрая смена приоритетов и требований. Иногда граничащий с хаосом. +Веб проекты в целом и такой бизнес в частности, очень требовательны к регулярной публикации результатов работы. Т.е. Тут действительно идет речь о выпуске в он-лайн результатов каждого спринта, а иногда и чаще. Сама Scrum команда изначально была распределена между двумя странами. Команда действительно кросс-функциональная и включает как разработчиков так и тестеров
  • Прежде чем идти дальше, я хочу вкратце рассказать как мы начинали: 1. Как я говорил, мы изначально решили строить все процессы на основе Scrum – это было объявлено бизнесу в целом и каждому кандидату в частности 2. Каждая команда со старта получила ScrumMaster’ а, который кроме того, что имел уже опыт лидера команды, так же прошел курс Certified ScrumMaster , что позволило говорить о хорошем начальном уровне СкрамМастеров 3. Более того, сразу как только команды были укомплектованы, они прошли совместный вводный тренинг, где члены команды и владельцы продукта узнали о том «зачем» мы работаем по Scrum и как именно мы собираемся его делать. 4. Ну и при поддержке руководства мы получили выделенных Владельцев Продукта, которые с самого начала знали об ожидаемых обязанностях и ответственности, которые подразумевает эта роль
  • Если первая команда была крайностью в отношении релизов, то у второй команды работа идет постоянно, вне зависимости от наличия хоть сколь-нибудь сфокусированных проектов Как я говорил, проекты у этой команды очень маленькие и максимум длятся пару спринтов Каждый спринт заканчивается не просто демонстрацией, а публикацией результатов в «лайв», где сайты посещают тысячи людей каждый день. Это ведет к тому, что все, что команда заявляет как «Сделано», должно быть готово к публикации без дополнительных работ. В таких условиях, необходимости планировать долгосрочные релизы просто нет. Для тех мини-«проектов», которые я упомянул достаточно наглядно можно отследить отношение Сделано/не Сделано, что дает ВП ясное представление о ситуации.
  • Жизнь второй команды сложно назвать размеренной Сам по себе газетный бизнес подвержен очень быстрым изменениям К тому же, реализация может отличатся от ожидаемой сложности, так как есть много маленьких факторов каждодневного риска. Например, внешний поставщик информации еще не готов к интеграции и команде приходится строить решения с разного рода заглушками. Или наоборот, казалось бы простая функция потребовала изменения других областей или обобщения существующих функций в единую библиотеку. Бывают и хорошие ситуации, когда команда делает сложную работу быстро  О, а еще бывают «пожары», когда происходят сбои на он-лайн серверах. Система достаточно сложная и бывают ситуации, когда администраторы из поддержки обращаются за помощью к разработчикам и тогда команда откладывает свои планы и разбирается в ситуации. Лучший совет в такой ситуации, это расслабиться и получать удовольствие. Самый главный шаг был сделан ВП – он поинмает ситуацию и всегда готов к диалогу, если команда в силу объективных причин не успевает сделать первоначальный план
  • У команды Б, ретроспективы проходят между разработчиками, так как только они отвечают за совершенствование своих методов и подходов Несмотря на все описанное мной тесное взаимодействие между ВП и командой, не стоит забывать, что он все-таки человек бизнеса и не всегда хорошо понимает «технический язык» Ретроспективы проходят как анализ последних значимых событий или как тематические обсуждения долгосрочных планов развития и улучшения. Обычно выбирают договариваются об 1-2 изменениях на следующий спринт, формируют план действий И результаты сообщают ВП, особенно если требуются инвестиции времени во внутренние технические работы Кроме регулярных встреч, раз в год команда старается проводить глобальную ретроспективу, чтобы проанализировать чего успели добиться за год и какие основные цели должны быть достигнуты
  • Слайдкаст. Stratoplan Kharkov. Методологический паззл.

    1. 1. К онференция S tratoplan World. Kharkov edition К руглый стол «Методологический паззл»
    2. 2. Содержание <ul><li>Марафон </li></ul><ul><li>Методологическое интро </li></ul><ul><ul><li>Сергей Поволяшко </li></ul></ul><ul><li>Кейс №1 </li></ul><ul><ul><li>Глеб Рыбалко </li></ul></ul><ul><li>Кейс №2 </li></ul><ul><ul><li>Тимофей Евграшин </li></ul></ul><ul><li>Кейс №3 </li></ul><ul><ul><li>Татьяна Голубева </li></ul></ul>
    3. 3. <ul><li>Методологическое интро </li></ul><ul><ul><li>Сергей Поволяшко </li></ul></ul>
    4. 4. <ul><li>Стаж в IT с 1996 года. </li></ul><ul><li>C 2001 года работаю в области управления IT подразделений и проектов </li></ul><ul><li>Принимал лидирующее участие во внедрении CMMI L3 </li></ul><ul><li>Сертификации: Project Management Professional (PMP), ITIL Foundation V3 </li></ul>Сергей Поволяшко Веду проект ИТ Тюнинг, www.it-tuning.com . Управление проектами и организацией Тренинги, семинары, консалтинг , доклады Работаю в должности CTO в компании TEAM International, www . teaminternational . com .
    5. 5. Что это все значит? Что с этим делать? Стандарты Модели, фреймворки, своды знаний Типы контрактов Типы проектов Методологии Инженерные и Управленческие практики Фазы проекта
    6. 6. Модели, фреймворки, своды знаний <ul><li>ISO </li></ul><ul><li>CMMI </li></ul><ul><li>PMBOK </li></ul><ul><li>Home grown </li></ul><ul><li>И т.п. </li></ul>Определяют общий подход, т.е. ЧТО делать Модели, фреймворки, своды знаний
    7. 7. Стандарты <ul><li>Системы Менеджмента Качества (СМК) на основе ISO , CMMI и т.п. </li></ul><ul><ul><li>Процессы </li></ul></ul><ul><ul><li>Руководства </li></ul></ul><ul><ul><li>Шаблоны </li></ul></ul><ul><li>Стандарты кодирования </li></ul><ul><li>Стандарты usability </li></ul><ul><li>Стандарты предметной области </li></ul><ul><li>И т.п. </li></ul>Конкретизация подхода, т.е. КАК делать Стандарты
    8. 8. Инженерные, управленческие практики <ul><li>Планирование проекта </li></ul><ul><li>Проектирование ( software design ) </li></ul><ul><li>Анализ требований </li></ul><ul><li>Инспекции ( review ) </li></ul><ul><li>Оценки работ </li></ul><ul><li>Кодирование </li></ul><ul><li>Модульное тестирование ( unit tests ) </li></ul><ul><li>Измерения </li></ul><ul><li>Функциональное тестирование </li></ul><ul><li>Управление рисками </li></ul><ul><li>Управление людьми </li></ul><ul><li>И т.д. </li></ul>В разном виде и комбинациях применяются всегда. Инженерные и Управленческие практики
    9. 9. Методологии <ul><li>Waterfall </li></ul><ul><li>Итеративные </li></ul><ul><ul><li>Релизы, итерации </li></ul></ul><ul><ul><li>RUP </li></ul></ul><ul><ul><li>SCRUM </li></ul></ul><ul><li>Kanban </li></ul>Структурируют применение практик, учитывая фреймфорки и стандарты Методологии
    10. 10. Взгляд Исполнителей Инженерные и управленческие практики
    11. 11. Взгляд Исполнителей Модели, фреймворки, своды знаний Что Инженерные и управленческие практики
    12. 12. Взгляд Исполнителей Внутренние и внешние стандарты, СМК Модели, фреймворки, своды знаний Что Как Инженерные и управленческие практики
    13. 13. Взгляд Исполнителей Внутренние и внешние стандарты, СМК Методологии Модели, фреймворки, своды знаний Что Как Структура Инженерные и управленческие практики
    14. 14. Взгляд Исполнителей Внутренние и внешние стандарты, СМК Методологии Модели, фреймворки, своды знаний Что Как Структура Инженерные и управленческие практики Адаптация под проект ( Tailoring )
    15. 15. Взгляд Бизнеса, Продаж
    16. 16. Взгляд Бизнеса, Продаж Типы контрактов Типы проектов Фазы проекта Окружающая среда проекта
    17. 17. Окружающая среда проекта <ul><li>Бизнес цели </li></ul><ul><li>Ограничения </li></ul><ul><li>Способности </li></ul><ul><li>Коммуникации </li></ul><ul><li>Ресурсы </li></ul><ul><li>Тип проекта </li></ul><ul><li>Состояние требований </li></ul><ul><li>«Политические» факторы </li></ul>Окружающая среда проекта
    18. 18. Типы проектов <ul><li>Новый </li></ul><ul><li>Развитие </li></ul><ul><li>Поддержка </li></ul><ul><li>Сложность </li></ul><ul><li>Специфика </li></ul>Типы проектов
    19. 19. Фазы проекта <ul><li>Исследование ( Feasibility Study ) </li></ul><ul><li>Прототип </li></ul><ul><li>Требования + План </li></ul><ul><li>Проектирование + План </li></ul><ul><li>Реализация </li></ul><ul><li>Внедрение </li></ul><ul><li>Сопровождение </li></ul>Фазы проекта
    20. 20. Типы контрактов <ul><li>Fixed Price </li></ul><ul><li>Time & Material </li></ul><ul><li>Cost Reimbursable </li></ul>Типы контрактов
    21. 21. Конструктор Окружающая среда проекта Типы проектов
    22. 22. Конструктор Окружающая среда проекта Типы проектов Прототип Требования Проектирование Реализация Релизы Waterfall Fixed price T&M CR SCRUM
    23. 23. Конструктор Окружающая среда проекта Типы проектов Жизненный цикл проекта Прототип Сбор треб. Реализация Прототип Требования Проектирование Реализация Релизы Waterfall Fixed price T&M CR SCRUM
    24. 24. Конструктор Контракт: CR T&M FP Риски 100% 0% Заказчик Исполнитель
    25. 25. Конструктор Контракт: CR T&M FP Заказчик Исполнитель Управление проектом
    26. 26. Конструктор Контракт: CR T&M FP Заказчик Исполнитель Формализм и ответственность управления требованиями
    27. 27. Конструктор Реализация Внедрение Требования Проектирование + Планы Исследования Прототип Типы проектов: Сложность, новизна, неопределенность требований Планирование, коммуникации, контракты, документация Фазы
    28. 28. Конструктор <ul><li>Взаимодействие : (1 – низкое , 5 - высокое ) коммуникации, вовлечение участников, партнерство </li></ul><ul><li>Изменения : от формальных процедур (1) до восприимчивости (5) </li></ul><ul><li>Ресурсы : наличие и уровень профессионализма, зрелости (1 – ниже, 5 - выше) </li></ul><ul><li>Осознание : всеми участниками как работает разработка ПО (1 – низкое, 5 - высокое) </li></ul><ul><li>Требования : определенность требований, ожиданий по продукту, проекту (лучше определены – 1, хуже - 5) </li></ul>
    29. 29. Конструктор <ul><li>Рекомендации </li></ul><ul><li>Контракт: FP </li></ul><ul><li>Формальное упр. Требованиями </li></ul><ul><li>Длиннее итерации </li></ul><ul><li>Больше риска на исполнителе </li></ul><ul><li>Более тщательное планирование </li></ul><ul><li>Рекомендации </li></ul><ul><li>Контракт: T&M, CR </li></ul><ul><li>Предпочтение Agile методологиям </li></ul><ul><li>Короче итерации </li></ul><ul><li>Больше коммуникаций </li></ul><ul><li>Определенность требований вторична </li></ul>1 5
    30. 30. <ul><li>Подборка материалов: </li></ul><ul><li>http :// www.it-tuning.com / wp-content / uploads /2011/06/ swke / MethodologyPuzzle.zip </li></ul><ul><li>Особенно рекомендую: </li></ul><ul><li>SEPG_CMMI and Agile </li></ul><ul><li>Agileorpmbok </li></ul><ul><li>scrum_xp-from-the-trenches-rus-final </li></ul>www.it-tuning.com [email_address]
    31. 31. <ul><li>Кейс №1 </li></ul><ul><ul><li>Глеб Рыбалко </li></ul></ul>
    32. 32. Глеб Рыбалко <ul><li>5 лет опыта в тестировании и обеспечении качества </li></ul><ul><li>Участник рабочей группы по переводу TMMi </li></ul><ul><li>Веду свой блог о тестировании и QA </li></ul><ul><li>www.QAConsulting.ru </li></ul><ul><li>Докладчик на различных конференциях </li></ul>
    33. 33. <ul><li>30 клиентов </li></ul><ul><li>200 дисков в день </li></ul>ITERATIVE !
    34. 34. Project team
    35. 36. Project
    36. 37. <ul><li>Scrum Master </li></ul><ul><li>Product Owner/Proxy Product Owner </li></ul><ul><li>Backlogs </li></ul><ul><li>Sprints </li></ul><ul><li>Planning Poker </li></ul><ul><li>Demo </li></ul><ul><li>Retrospectives </li></ul>SCRUM !
    37. 38. Tips&Tricks <ul><li>Перепланирование </li></ul><ul><li>Буфер </li></ul>
    38. 39. Что сейчас <ul><li>10% новой функциональности </li></ul><ul><li>90% поддержка и интеграция клиентов </li></ul><ul><li>80 клиентов </li></ul><ul><li>10000+ дисков в день </li></ul>
    39. 40. Что дальше? KANBAN ?
    40. 41. <ul><li>Кейс №2 </li></ul><ul><ul><li>Тимофей Евграшин </li></ul></ul>
    41. 42. Тимофей Евграшин <ul><li>Agile коуч </li></ul><ul><li>Тренер по внедрению гибких методологий управления проектами ( Agile/Scrum ) </li></ul><ul><li>Менеджер проектов с Agile уклоном </li></ul><ul><li>Certified ScrumMaster , Scrum практик </li></ul><ul><li>Автор блога « The Improved Methods » http:// tim.com.ua </li></ul>
    42. 43. О ком пойдет речь <ul><li>Крупная медиа корпорация </li></ul><ul><li>Внутренний отдел разработки </li></ul><ul><ul><li>Тесное сотрудничество </li></ul></ul><ul><ul><li>Следование корпоративным правилам </li></ul></ul><ul><ul><li>Поддержка Scrum при старте проекта </li></ul></ul><ul><ul><li>Команды выделены под конкретные бизнес подразделения </li></ul></ul>© 123RF Limited . © 123RF Limited . © 123RF Limited .
    43. 44. Команда <ul><li>Много схожих коротких он-лайн проектов </li></ul><ul><li>Внутренние и внешние поставщики информации </li></ul><ul><li>Смена приоритетов и требований </li></ul><ul><li>Выпуск в «он-лайн» каждую неделю/две </li></ul><ul><li>Распределенная Scrum команда </li></ul>
    44. 45. Важно <ul><li>Все процессы на основе Scrum </li></ul><ul><li>Обученные Скрам мастера </li></ul><ul><li>Совместные вводные тренинги </li></ul><ul><li>Выделены Владельцы Продуктов </li></ul>© 123RF Limited .
    45. 46. Как планирует релизы команда Б <ul><li>Работа идет постоянно , независимо от «проектов» </li></ul><ul><li>Выпуск в « live » идет после каждого спринта </li></ul><ul><li>«Проекты» длятся максимум 2-3 спринта </li></ul>© 123RF Limited.
    46. 47. Изменения требований в команде Б <ul><li>Быстрые изменения – естественное свойство бизнеса </li></ul><ul><li>Реализация отличается от ожидаемой сложности </li></ul><ul><li>А еще есть «пожары» </li></ul>© 123RF Limited. © 123RF Limited.
    47. 48. Ретроспективы в команде Б <ul><li>Проходят между разработчиками </li></ul><ul><li>Иногда это тематические обсуждения и долгосрочные планы </li></ul><ul><li>Результаты сообщаются ВП </li></ul><ul><li>Раз в год – глобальная ретроспектива </li></ul>© 123RF Limited.
    48. 49. <ul><li>Кейс №3 </li></ul><ul><ul><li>Татьяна Голубева </li></ul></ul>
    49. 50. ТАТЬЯНА ГОЛУБЕВА <ul><li>Около 9 лет в ИТ, более 4 лет в управлении людьми </li></ul><ul><li>Engineering Project Manager – Testing </li></ul><ul><li>Тренер в сфере тестирования ПО и менеджменте </li></ul><ul><li>Участник и докладчик профильных конференций </li></ul><ul><li>Автор проекта http :// okprocess . net </li></ul><ul><ul><li>E-mail: [email_address] </li></ul></ul><ul><ul><li>Skype : tgolubeva83 </li></ul></ul>
    50. 51. Вводные <ul><li>Fixed price </li></ul><ul><li>Совокупная длинна подпроектов 3-5 недель </li></ul><ul><li>Однотипные подпроекты </li></ul><ul><li>Нет четкого процесса у заказчика </li></ul><ul><li>Команда из Junior Engineers </li></ul><ul><li>3 + под команд ы </li></ul>
    51. 52. ИЗНАЧАЛЬНОЕ РЕШЕНИЕ <ul><li>Пирамидальная структура </li></ul><ul><li>За основу взято ISO 9001 </li></ul><ul><li>Все процессы максимально описаны </li></ul><ul><li>Документирование: все решения проходят через почту </li></ul><ul><li>Обучение начальной команды, разъяснения процессов </li></ul><ul><li>Готовность к текучке кадров </li></ul><ul><li>Заказчик не уверен, что что-то получится </li></ul>
    52. 53. К ЧЕМУ МЫ ПРИШЛИ ЗА 2 ГОДА <ul><li>Пирамидальная структура </li></ul><ul><li>Процессы периодически пересматривались, все что не прижилось меняли и меняем </li></ul><ul><li>Документирование: все решения проходят через почту </li></ul><ul><li>Высокая текучка кадров </li></ul><ul><li>Процессы не завязаны на конкретных людей, привязка к ролям </li></ul><ul><li>Команда отвечает за результат (в основном это команда тестирования  ) </li></ul><ul><li>Налаженный процесс обучения </li></ul><ul><li>Заказчик happy  , высокая степень доверия, заказчик работает по налаженным процессам </li></ul>
    53. 54. МЕТОДОЛОГИЯ <ul><li>Это не waterfall, RUP, v-model </li></ul><ul><li>Это не CMMI, … </li></ul><ul><li>Это не Agile ,… </li></ul><ul><li>Это то, что подходит нам и работает для нас: </li></ul><ul><li>Урезанная v-model + итеративность + гибкость </li></ul>
    54. 55. Спасибо за внимание!

    ×