Всем привет! В этом видео мы поговорим о том зачем Agile нужен команде разработки. На мой взгляд, самая большая ценность любого Agile подхода и в частности Scrum - это возможность разработчиков увидеть, какую ценность приносят результаты их труда конечному пользователю или заказчику. Само по себе, это может очень сильно мотивировать. Представьте, раньше вы работали допустим в отделе программирования и вам просто поступали задачи из разных проектов, то теперь вы каждый спринт видите, какую пользу приносит ваш вклад в продукт конечному пользователю. Еще одним плюсом является фокус на один продукт, когда вас не отвлекают и не дергают на задачи из разных проектов и вы можете полностью сосредоточиться, сфокусироваться на одном продукте. Очень многих участников команд разработки или Scrum команд, мотивирует сама по себе эффективная работа в команде, когда участники команды начинают помогать друг другу, это как знаете в спорте, как спортивная игра, например, в футбол или баскетбол. А также многих мотивирует отсутствие бюрократии, многие отмечают это как большой плюс, потому что у нас теперь общение face-to-face напрямую с владельцем продукта, заказчиком на обзорах спринта. Ну и разумеется в самой команде, потому что команда работает в одном помещении. А документы мы конечно же используем, но теперь они несут большую ценность чем раньше. Это не просто формальная какая-то вещь, которую нужно соблюсти, а документы служат конкретным целям. Также большим плюсом является возможность развиваться в смежных направлениях. Представьте, что вы, например, дизайнер и всегда хотели научиться программировать front-end, например. Теперь у вас появляется такая возможность, потому что вы работаете в кросс-функциональной команде, у вас есть отдельный специалист фронтендер, которому вы можете предложить свою помощь, взамен на то, что он будет вас учить - это очень поощряется в scrume, потому что это делает более эффективной всю команду. Когда мы говорим про плюсы от Agile подходов нельзя не сказать про риски с которыми мы возможно столкнетесь при попытке использования Agile подходов или в частности scruma в команде разработки. Первый риск, он заключается в том, что далеко не все люди готовы вот так сходу стать, что называется T-Shape people концепция, про которую вам рассказывал Алексей. Зачастую вы можете услышать такие фразы, что я например аналитик, это не моя задача программировать front-end и люди будут совершенно правы. Вот эту T-Shape концепцию нужно воспитывать в людях постепенно. Также, не все готовы нести командную ответственность, человек говорит, но я как бы свою часть выполнил, свои задачи сделал, но как я могу нести ответственность за какого-то другого человека. Также, когда мы начинаем быстро поставлять продукт, быстро его разрабатывать, это зачастую перед командой разработки ставит повышенные требования к качеству, к техническому качеству реализации, к техническому качеству кода или архитектуры. Действительно, если раньше мы могли раз в год выпустить продукт, а сейчас выпускаем, например, каждые две недели, то наш код должен быть гораздо лучше и архитектура тоже должна позволять вносить изменения быстрые. А как же нам бороться с сопротивлением команды, если она имеется? Если вы столкнулись с таким сопротивлением со стороны команды разработки, никогда не нужно пытаться это сопротивление сломать в лоб. Всегда нужно представлять новые изменения предложения, не как новую догму, а как предложение, как эксперимент. А давайте попробуем в течение определенного времени и посмотрим как пойдет, понравится или нет. Если не понравится, то отменим. Естественно можно работать с сопротивлением через обучение, отправить людей на тренинги, мастер класс или предложить прочитать какие-нибудь книги. Но вот, что я хотел бы отметить. Зачастую в корпорациях, особенно в корпорациях скульптуры контроля, там где процессы все сильно забюрократизированы. Когда мы запускаем Agile команду, очень часто можно отметить повышенный интерес к этой команде со стороны тех сотрудников, которые в нее не попали. Этот интерес не случаен. Действительно представьте, в такой команде она колацирована, они каждый день взаимодействуют face-to-face. Они, как правило меньше, либо вообще не перерабатывают в отличие от других сотрудников и самое главное они дают ценный результат в конце каждого спринта, каждой короткой итерации. Очень часто это вызывает повышенную мотивацию тоже поработать в этой команде или в другой Agile команде. В следующем видео мы поговорим о том, как продать Agile руководству.
