Усвоенные уроки одной кросс-функциональной команды
Сергей Рогачев, Астерос Лабс (Москва) Алексей Воронин, Астерос Лабс (Москва) Сергей Рогачев работает в сфере разработки программного обеспечения последние 10 лет. Основные роли, в которых выступал Сергей: разработчик, архитектор и менеджер. За это время Сергей успел поработать в таких крупных компаниях как Лукойл-Информ и Лаборатория Касперского. Последнее время Сергей занимается вопросами организации подразделений исследований и разработки (R&D), постановки в них процессов разработки продуктового программного обеспечения, способного достойно конкурировать с аналогами на рынке. А способны ли вы оглянуться на год назад и признаться себе, что то, как вы смотрели на мир год назад, абсолютно отличается от того, как вы смотрите на мир сейчас? А, главное, понять, какие причины повлияли на это изменение? Это история о том, какие принципы, интуитивно заложенные основу построения нашей команды в начале проекта, помогли ей пройти путь от аборигенов, повторяющих ритуалы Scrum, до состояния осознанного применения готовых, адаптации и поиска новых гибких методик для эффективного достижения целей и постоянного развития. Об этих принципах и изменениях мы расскажем на примере уроков, которые мы усвоили за год работы над проектом.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
More from Magneta AI
More from Magneta AI (20)
Recently uploaded
Recently uploaded (9)
Editor's Notes
- Сергей Рогачев: Теперь случай поинтереснее… А в другой команде мы наблюдали проблему накопления долга по тестированию. Как у нас издревле заведено: сначала разработать функционал, а потом только его тестировать. Это правило вполне объяснимо: действительно, невозможно ведь проверить работу того, чего еще нет. Но зачастую как происходит? Программисты завершили свою работу, а тестировщики еще не приступили к своей. В итоге, в продукте начинает накапливаться незавершенный функционал: разработан, но еще не проверен. Этот долг тестировщика неуклонно растет: как только он добирается до тестирования разработанного ранее функционала, программисты уже добавляют в его очередь новую пачку реализованных требований. Пока этот долг не устранен, выпускать продукт нельзя.К чему это все приводит? Менеджер все свое внимание акцентирует на разработке функционала к желаемому сроку выпуска, но в итоге из-за аврала по тестированию, неожиданно обнаруженного незадолго перед выпуском, вынужден или отложить выпуск, или выпускаться, жертвуя качеством.В итоге, клиент был то недоволен сроками поставки (когда тестировали, задерживая выпуск), то качеством (когда плевали на тестирование, выпускаясь в срок).Алексей Воронин:Тогда команда решила внедрить Scrum: эта таблетка всем помогает, поможет и нам!Но почему-то исполнение ритуалов регулярных встреч не помогло: клиент по-прежнему получал или не вовремя, или не то.Тогда внешние консультанты провели аудит работы этой команды, который выявил, что проблемы команды связаны с физической неспособностью команды изменяться, адаптируясь под условия проекта: они не могли решить проблему накопления долга по тестированию самостоятельно – хотя в соседней команде аналогичная проблема была успешно решена, и они знали об этом.