Как создаёт Продукт Скрам-команда?
Разработчики и бизнес работают сообща. Команда как можно чаще показывает бизнесу Продукт и вместе с ним устраняет проблемы.
Как разрабатывает большие продукты обычная компания?
Одно подразделение создаёт спецификацию и передаёт другому подразделению. Затем разработчики торгуются с менеджерами вместо того, чтобы общаться с конечными пользователями. Из-за этого люди в организациях слабо влияют на разработку и забывают, для кого создают продукты.
Почему разрабатывать небольшие продукты эффективнее, чем большие?
В небольших продуктах рабочие процессы минимальны. Они основаны на эмпирическом подходе, когда Команда регулярно сверяется с реальностью. Такой подход ориентирован на клиента, и Продукт видно целиком, поэтому получается эффективно.
Можно ли применить те же принципы в масштабируемой разработке больших продуктов?
Крэйг Ларман и Бас Водда разбирались в этом вопросе 10 лет. Они провели сотни экспериментов и в итоге создали LeSS — фреймворк для масштабируемой разработки. Его успешно применяли в компаниях даже из тысяч человек. C помощью LeSS создавали продукты в банковской сфере, телекомах, разрабатывали игры и программное обеспечение для радаров.
Как работает LeSS?
LeSS — это Скрам для нескольких команд. Вот как он работает:
LeSS подходит, если у вас менее восьми команд на Продукт. Если команд больше, используйте фреймворк LeSS Huge.
У LeSS не много правил, но они требуют глубинных изменений в организации. На избавление от лишних процессов, смену ролей и внедрение технических и управленческих практик уйдут годы, но это необходимо.
Представим, что Продукт завалился из-за недостаточного тестирования. Менеджер обычной компании первым делом создаст детальный процесс и закрепит за ним ответственного или целый департамент. Но тогда ответственности лишится Команда.
Мы верим, что излишнюю сложность в структурах и процессах надо убирать, извлекая большее из меньшего: отказываться от подготовительных и стабилизационных Спринтов, выделенных команд анализа требований, архитекторов и очередей из задач для каждой команды.
В LeSS команды кросс-функциональные. Они разбираются в бизнес-домене, дизайне и архитектуре, делят между собой общую кодовую базу для всех компонентов, сами анализируют требования заказчиков и конечных пользователей. В итоге они доставляют полноценную функциональность, а не внутренние компоненты или данные.
Условия для наращивания кросс-функциональных навыков создают Скрам-мастера и менеджеры. А ещё есть мы — быстрорастущее комьюнити практиков и коучей LeSS. Мы призываем вас превратить машинообразные бездушные организации в организации со смыслом, где людям будет приятно работать.
Не ожидайте, что этот процесс будет безболезненным. Но если вы возьмёте курс на гибкость, то упростите организацию, адаптируете её к быстро меняющимся условиям и реализуете скрытый потенциал.
Проблема в том, что на философском и практическом уровне иерархия со своими управленческими процессами противоположна переменам. Она стремится уничтожить аномалии, стандартизировать процессы, решить краткосрочные задачи и добиться быстрой работы при текущем режиме.Некоторые оптимизационные цели иерархии подразумевают использование контроля и ресурсов или попросту «время, проведённое сидя в кресле». Иерархия выстраивает такой дизайн организаций, при котором они становятся группами одной функции. Работу групп по ключевым показателям тоже оценивают менеджеры одной функции.
Например, существуют группы, которые специализируются только на заключении контрактов или выставлении счётов. Другие группы специализируются на технологиях типа Java, .NET, Oracle. Есть группы со специализацией на тестировании, архитектуре, безопасности и проектном менеджменте.В иерархии нет ничего плохого, если оптимизационные цели соответствуют задачам. Но если вы хотите стать гибким, цели нужны другие: