Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

Первый шаг – поиск сотрудника, который создаст студию по разработке программного обеспечения и будет ею управлять. Менеджер студии также и Scrum-мастер, в его функции входит поддержка работы студии с теми техническими средствами, которые есть в его распоряжении. Менеджер студии обязан:

• иметь за плечами несколько лет опыта работы Scrum-мастером, менеджером в Scrum-среде;

• понимать процесс разработки программного обеспечения;

• иметь квалификацию и опыт по внедрению изменений и упрощению процедур;

• обеспечивать обучение и инструктаж разработчиков в студии;

• быть уверенным, что Scrum-мастера, работающие над проектами, хорошо делают свою работу;

• помогать оптимизировать результаты проектов;

• постоянно совершенствовать технические средства студии, чтобы последующие проекты становились более экономичными и эффективными.

Менеджер студии изучает индустрию программного обеспечения для поиска лучших, наиболее экономически оправданных методов автоматизированных средств и программного обеспечения. Приложения и инструменты могут варьироваться от элементарных до сложных, в зависимости от того, как долго работает и улучшается студия.

Цель менеджера студии – обеспечить рабочую обстановку с максимально возможной стоимостью. Как минимум цель студии – сделать более легким запуск новых Scrum-проектов.

Обучение чему-то отличающемуся от привычного, такому как Scrum, может быть трудным. Люди должны иметь желание учиться новому подходу к управлению и разработке программного обеспечения. Обучение будет успешным только для тех, кто хочет и стремится изучить и потратить на это усилия. Если департамент планирует проводить все свои проекты в студии разработки, все, кто связан с этим, обязаны научиться работать по-другому.

Пользователи, столкнувшиеся со Scrum впервые, должны пройти двухдневный базовый курс обучения. Они обучаются Scrum и теории и принципам, лежащим в его основе. Они проходят через многочисленные симуляции различных ситуаций, пока не поймут ощущение и движение Scrum-проекта. Устанавливаются основные правила, расписание мероприятий, длина спринта и тому подобное.

Способы работы оформляются и объясняются. Новые техники могут потребоваться для следующего:

• увеличение вклада в работу команды по сравнению с личной производительностью;

• создание структуры отчетности и проверки производительности;

• разрешение конфликтов;

• урегулирование отношений с проблемными членами команды;

• преодоление препятствий и потребностей.

Также проводится обзор оборудования и технических средств студии, чтобы члены команды знали, какие имеются средства, как их использовать и как получить помощь.

Проводятся мероприятия по тимбилдингу, члены команды учатся работать друг с другом, занимаются упражнениями по совместному решению проблем и учатся преодолевать конфликты, которые нередко случаются в самоорганизованных командах, где различные идеи имеются в большом количестве.

Сотрудники, участвующие в Scrum-командах, подписывают соглашение об условиях использования технических средств студии. Соглашение обеспечивает их пониманием того, чего от них ждут. На рисунке 7.1 перечислены типичные условия использования Scrum.

1. Каждый проект должен быть основан на процессе Scrum и его принципах: эмпиризме, накоплении знаний и самоорганизации.

2. Каждый проект будет реализован отдельной Scrum-командой, состоящей из владельца продукта, Scrum-мастера и не более чем девяти разработчиков.

3. Scrum-мастер должен иметь опыт управления Scrum-проектами. Если его опыта недостаточно, он должен не стесняться принимать помощь и проходить обучение у старших Scrum-наставников.

4. Владелец продукта будет активно сотрудничать со Scrum-командой по вопросам формулирования требований, оценке проделанной работы, оценке инкремента, а также будет оптимизировать ценность проекта на основе постоянных практических проверок и тестов.

5. Scrum-команда (команда разработки) будет состоять из разработчиков программного обеспечения, обладающих всеми навыками, необходимыми для создания инкремента потенциально пригодной к использованию функциональности, основываясь на требованиях владельца продукта.

6. На протяжении всего проекта внешние связи и подчиненность должны быть приостановлены.