Просмотр исходного текста страницы Максим Цепков - AgileDays-2011/Enterprise Scale Agile. Lessons learned

Руководит развитием agile в люксофт. В целом понятный [[Enterprise Scale Agile. Lessons learned (Константин Гурнов, AgileDays-2011)|доклад]] обернутого в науку agile — не примеры, а общие слова и хорошие метрики.

'''Заметки'''

Люксофт success story хорошей разработки. Развитие от функциональных команд к кроссфункциональным и далее к бизнес-командах.

Рассказ, что применяют крутой agile (Enterprise Scale) — масштаба предприятия. Процесс непрерывного улучшения — главное. Через метрики. Три группы — требования, дизайн+архитектура+техника, инфраструктура. Проблема идентифицируется, гипотеза по исправлению, эксперимент, метрики результата и решение по нему.

Пример истории — 100 % автоматизация в одной группе дала кучу плюсов, и не оверхед.

Источники — поддержка менеджмента с одной стороны и системное мышление — с другой.

Говорит, что все осознали и он прошел пропасть. Только Книберг при этом говорит, что реально не итеративно.

Слова — надо решать. И не свои проблемы, а проблемы заказчика. Если заказчик — ит-департамент заказчика, то ему не интересны проблемы с подрядчиком, ему надо решить проблемы бизнес департаментов.

Все коммуницируют примерами, аналитик по ним создает user story, по которым команда создает свои а тестеры свои.
spec by example настаивает на использовании примеров пользователя. У них — хорошо. Из зала пошли вопросы с завалом — мол, пользователи не знают, что делают.

Успешный 5-летний проект с инвестбанком (интересно, с каким, дойч?). Начали Time&Material, потом перешли на Fixprice потому, что заказчик менял у себя процессы в эту сторону.

Основная штука успеха — системное мышление. Чтобы оптимизировать, где надо, а не где видны возможности.
И работать на результат, а не локальную оптимизацию — я: это как у Голдратта.

Второе — уважение к людям. Не только к своим сотрудникам, но и к культуре заказчика.