Сказать, что «гибкие методологии разработки программного обеспечения в наше время набирают популярность», значит показать себя не самым сведущим человеком в мире технологий (так можно было бы сказать про блокчейн, да и то уже поздновато). Такая фраза была актуальна примерно 10 лет назад, а сейчас применение Agile командами уже совсем не ново и вполне обыденно. Этот подход по-прежнему спорный и обсуждаемый в научных и профессиональных кругах с точки зрения его применимости и сравнения его с классическим водопадным подходом к разработке. Бесспорно, этот подход хорош. Команде не нужно писать тонны документации, заказчику не нужно ее читать. Команде не нужно взрывать себе мозг, пытаясь досконально понять, что хочет заказчик, заказчику не нужно переживать, что все требования нужно выставить здесь и сейчас, иначе потом будет поздно. Плюсов много, но много и минусов. Но сегодня речь не о них, а речь об окружении проектов, а точнее о человеческих аспектах этого окружения. Ведь в Agile главное не процессы и инструменты, а люди.
Мы решили с вами поделиться факторами, которые могут стать по-настоящему опасными для Agile проектов, собранные с двух разных кейсов.
Участники команды имеют существенные различия в уровне своих профессиональных качеств.
Многие исследования, направленные на анализ эффективности Agile методологий, упоминают такую фразу, как «premium people». Существует мнение, что когда Agile подход описывается в позитивном ключе, авторы очень редко упоминают, что на самом деле есть определенные требования к уровню профессиональных компетенций участников команды. Действительно, люди такого уровня требуются как для того, чтобы создать более менее правдивую первую версию продукта, так и для того, чтобы в дальнейшем выстраивать коммуникацию с заказчиком. Более того, Agile требует практически равнозначной включенности в процесс всех участников команды, а это практически неосуществимо, если компетенции участников сильно отличаются.
Это не означает, что гибкие методологии требуют, чтобы в команде были люди только с высоким уровнем компетенций. Многие гибкие проекты были успешными, когда в команде сочетались специалисты с разным уровнем компетенций. Однако основное отличие гибких подходов от классических заключается в том, что гибкие методы получают большую часть этой самой гибкости за счет интуитивных познаний, которые являются следствием опыта команды.
Недостаток опыта руководителя в совокупности с низким уровнем дисциплины.
В одном исследовании о неоднозначности эффективности методологий Agile прозвучала интересная фраза — «Balancing Agility and Discipline». Действительно, гибкость и дисциплина — это не совсем противоположные вещи, но довольно часто вступающие в конфликт. Особенно этот конфликт усугубляется, если руководитель/лидер команды — это человек недостаточно опытный. Причем профессиональный опыт здесь играет минимальную роль, речь скорее даже о неком жизненном опыте и умении общаться с людьми. Зачастую приходится выбирать (или искать баланс) между необходимостью «построить» команду и важностью сохранения творческого подхода к работе в сумме с отлично выстроенной коммуникацией. Зачастую это практически невозможно, если отсутствуют лидерские качества и способность к организации команды.
Подытоживая наше рассуждение, в очередной раз можем только отметить, что любой метод, любой подход, техника, стандарт, инструмент — хорош. Хорош, пока не появляется человеческий фактор. Без него — никуда, поэтому остается только научиться им управлять или с ним бороться, это кому что нравится.
