Сергей Рогачев, Астерос Лабс (Москва)

Сергей Рогачев

Где найти:

Должность:
Руководитель управления платформенной разработки

О себе:

Сергей Рогачев работает в сфере разработки программного обеспечения последние 10 лет. Основные роли, в которых выступал Сергей: разработчик, архитектор и менеджер. За это время Сергей успел поработать в таких крупных компаниях как Лукойл-Информ и Лаборатория Касперского.

Последнее время Сергей занимается вопросами организации подразделений исследований и разработки (R&D), постановки в них процессов разработки продуктового программного обеспечения, способного достойно конкурировать с аналогами на рынке.


Выступает с докладом

Усвоенные уроки одной кроссфункциональной команды разработки

А способны ли вы оглянуться на год назад и признаться себе, что то, как вы смотрели на мир год назад, абсолютно отличается от того, как вы смотрите на мир сейчас? А, главное, понять, какие причины повлияли на это изменение?
Это история о том, какие принципы, интуитивно заложенные основу построения нашей команды в начале проекта, помогли ей пройти путь от аборигенов, повторяющих ритуалы Scrum, до состояния осознанного применения готовых, адаптации и поиска новых гибких методик для эффективного достижения целей и постоянного развития.
Об этих принципах и изменениях мы расскажем на примере уроков, которые мы усвоили за год работы над проектом.
--
Во время второй мировой войны США построили множество военных баз на различных островах Тихого океана. Продовольствие, одежда и прочие товары доставлялись туда самолетами, при этом часть груза иногда просто сбрасывалось вниз. И часто кое-что из этого доставалось диким племенам, живущим на этих островах: бывало так, что аборигены полностью задвигали на свое сельскохозяйственную деятельность и скотоводство. Туземцы быстро уловили, что американцы сами не трудятся, им все достается с неба за веру в богов. Потом война закончилась, и американцы свернули базы. Но каково было их удивление, когда по прошествии 20 лет они обнаружили на островах негров, марширующих с муляжами ружей и деревянными наушниками по потешным соломенным аэродромам мимо копий самолетов из бамбука в натуральную величину. Можно сказать, что туземцы довольно четко копировали действия американцев, но боги почему-то не спешили больше сбрасывать с небес дары.
С подобным проявлением культа Карго мы часто сталкиваемся сейчас и в отрасли разработки программного обеспечения. Популярные гибкие методологии (XP, Scrum, Kanban и прочие) часто внедряются командами разработки на уровне такого же бессмысленного, как и у туземцев, повторения заученных ритуалов: «Мы ругаемся и играем в карты на планировании, клеим бумажки на стену и потом отчитываемся о них менеджеру каждое утро и на демонстрации, поэтому у нас Scrum!» Но, как и у аборигенов, через некоторое время приходит отрезвляющее понимание, что кроме игры никакой пользы это действо не приносит. Так как же перестать быть неграми, поклоняющимися самолетам, или как стать теми парнями, у которых есть свои самолеты?
Начало распространению гибких методологий положил манифест гибкой методологии разработки программного обеспечения, известный большинству своими 12 принципами. Но редко кто обращает внимание на первые слова манифеста: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value (Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что…). Таким образом, авторы манифеста заявили, что именно стремление к постоянному профессиональному развитию позволило им вывести определенные принципы эффективной работы. Так, быть может, мы только повторяем эти принципы в виде упрощенных готовых методик вроде регулярных собраний Scrum, но не понимаем их цели, о которой говорили авторы манифеста? Именно стремление к постоянному развитию приводит нас к пониманию истинных целей применяемых в гибкой разработке ритуалов. К примеру, итеративность нужна не столько для размеренности работы команды, как пропагандирует Scrum, сколько для возможности обеспечения регулярности прохода команды по циклу Деминга-Шухарта (PDCA), в котором частое взаимодействие с действительностью посредством обратной связи обеспечивает возможность адаптивного достижения целей и развития. Возможно, единственная проблема туземцев в том, что они остановили свои эксперименты после того, как их покинули американцы, и не получали какую-либо обратную связь?
В этом докладе будет описана история о том, какие принципы, интуитивно заложенные основу построения нашей команды в начале проекта, помогли ей пройти путь от аборигенов, повторяющих ритуалы Scrum, до состояния осознанного применения готовых, адаптации и поиска новых гибких методик для эффективного достижения целей и постоянного развития. Таким образом, мы практически повторим манифест гибкой методологии, но в своей практической интерпретации: опишем, какие цели мы преследовали изначально, и только затем, каких результатов нам удалось благодаря этому достичь. Мы приведем конкретные усвоенные нами уроки (lessons learned), но только в качестве примера успешной работы команды, нацеленной на собственное развитие. Соответственно, мы будем рекомендовать к внедрению не усвоенные уроки, многие из которых, возможно, специфичны для нашего проекта, компании и прочего, но принципы, которые могут обеспечить постоянное развитие командам и, как следствие, самостоятельное достижение необходимых принципов эффективной работы.
Доклад основан на заметке «Усвоенные уроки одной кроссфункциональной команды разработки», опубликованной в персональном блоге: http://rsn81.wordpress.com/2013/01/18/lessons_learned_2012.

http://www.slideshare.net/agiledays/ss-19545532

Доклады, интересные пользователю:

 

Организаторы конференции

Scrumtrek.ru
Agilerussia.ru
CodeCrafting
 

Специальный партнер

3м
Atlassian Bar
 

Платиновые партнеры

Atlassian
microsoft
Дойче Банк
IBM
GameTrek
SkillTrek
 

Золотой партнер

Devprom
ЛЮКСОФТ