Agile – ответ IT на вызовы цифрового мира

Agile появился в IT рубеже 21 века в IT как альтернатива регулярному менеджменту в ответ на вызов цифрового мира: обеспечить организацию проектов умственного труда при дефиците кадров и высокой динамике развития. Я хочу подчеркнуть, что Agile – он не про то, как сформировать индивидуальную траекторию развития компании, о необходимости которой я писал в заключительной статье первого блока «Три вызова цифрового мира», он про то, как по этой траектории двигаться. Потому что старые способы движения, которые предлагал говорил регулярный менеджмент – точно не подходят, принципиальную неспособность регулярного менеджмента организовать умственный труд я подробно рассматривал ранее в статье «Цифровой мир: от физического труда — к умственному», а в предыдущей статье «Развитие и провал регулярного менеджмента в IT» я подробно разобрал это на истории IT-отрасли. В этой статье мы рассмотрим логику появления Agile и его принципиальную конструкцию, включающую ценности, принципы и методы. Это – восьмая статья серии «Менеджмент цифрового мира».

Итак, в 1980-х при анализе опыта IT было осознано, что ключевым фактором успеха IT-проектов является человеческий фактор, а не организация процессов. Об этом – классическая книга Тома ДеМарко «Peopleware» (1987). В 1990-х была предпринята попытка найти решение хотя бы для крупных проектов, в которых стоимость не имеет принципиального значения, гуру IT разработали Rational Unify Process (RUP), но даже для них гарантировать успешную реализацию в соответствии с планами не получилось. Параллельно в с 1980-х шло интенсивное развитие персональных компьютеров, которые стали доступны средним и мелким фирмам. Это вызвало большую потребность в разработке софта для автоматизации бизнес-процессов. учитывающих специфику конкретного бизнеса – обобщенных конфигурируемых решений, подобных 1C тогда не существовало. При этом такие проекты обладали значительно более скромными ресурсами. Кризис доткомов также ярко показал необходимость найти решение для скромных проектов и стартапов.

Отметим, что автоматизация мелкого и среднего бизнеса, а также разработка для стартапов имеют принципиальную особенность: среда, в которой должен работать софт, сильно изменяется за время разработки. Если вы принесли продукт, разработанный по требованиям годовой давности он оказывается никому не нужен, в отличие от военных или научных проектов, касающихся моделирования физического мира или автоматизации крупных корпораций, процессы в которых относительно стабильны. По сути, это – можно рассматривать как предвестие VUCA-мира, в котором IT начал существовать.

Каким же образом Agile удалось ответить на вызовы организации умственного труда и разработке для VUCA-мира? А очень просто: раз ключевым фактором успеха IT-проектов является человеческий фактор, значит не надо ставить на процессы, а надо сделать ставку на команду, которая сама организует свою работу. А чтобы команда объединилась в движении к общим целям, необходимы ценности, которые послужат основой. Так появился Agile-манифест (2001, на русском). Заметим, что ответ ассиметричный: проблема лежит в области процессов, а решение – в области культуры. Это явно видно на схеме, приведенной ниже, где конструкция Agile помещена на схему кораблика, рассмотренную мной ранее в этой статье.

Итак, ценности Agile-манифеста:

Что тут важно? Как я показывал в предыдущей статье «Развитие и провал регулярного менеджмента в IT», есть системные причины, по которым IT-проекты не развиваются в соответствии с планами. Столкнувшись с такими ситуациями, менеджеры шли по понятному им пути – пробовали взять под контроль все что только можно. Но это – не помогало. И в результате в других проектах жесткий контроль пробовали вести с самого начала. И Agile-манифест родился именно как противодействия этим бессмысленным попыткам тотального контроля. И поэтому он делает особый акцент как раз на ценности сотрудничества и результативности, в противовес тем формальным вещам, на которые делали акцент менеджеры озабоченные, быть может, не столько успехом проекта, сколько попытками избежать ответственности за неудачу.

Есть еще один аспект, связанный с американским концептом универсального менеджмента, не зависящего от предметной области, который лучше всего выразил MBA. Правая, менее важная часть ценностей представляют собой то, что не зависит от предметной области, и с чем менеджеров учили работать. В то время как левая представляет значительно более зыбкие понятия, следование которым, к тому же, во многом противоречит урокам менеджмента. И в результате в условиях ограниченных ресурсов и сроков менеджеры реально выделяли ресурсы на документацию и работу с условиями контракта, а не на решение вопросов работоспособности софта или совместному с заказчиком решению проблем. А опыт IT-проектов однозначно говорит, что если делать акцент на вторую часть ценностей в ущерб первой, то проект точно не будет успешен.

Понятно, что когда качаешь маятник, то он качается гораздо дальше, чем хотелось бы. С ценностями Agile-манифеста это тоже произошло, в некоторых командах начали вести проект без документации и процессов вообще, не работать с условиями контракта и откликаться на любые изменения мгновенно так, что к ходу проекта вполне возможным было применить поговорку «нас невозможно сбить с пути – нам все равно, куда идти». И потому в современных условиях обязательно надо помнить о ценности обоих частей, но не забывать о сравнительной важности, которую задает манифест, она по-прежнему актуальна.

Но ценности остаются пустыми декларациями, если организация работы не позволяет их достигнуть. И потому помимо ценностей Agile-манифест включает принципы организации работы.

Принципы несут довольно много специфике отрасли. С этим связана сложность при переносе Agile-методов в другие отрасли: ценности перенести относительно просто, в их основе лежит результативность и сотрудничество, которые носят общезначимый характер. И я видел адаптации ценностей Agile-манифеста для продаж, маркетинга, образования и ряда других отраслей. А вот принципы, по которым следует организовывать работу для достижения успеха, могут значительно отличаться из-за специфики отрасли. Именно из-за отраслевой специфики я не разбираю принципы подробно: IT-шники их и так знают, а остальных надо будет излишне погружать в контекст отрасли, обосновывая их.

Однако, необходимо отметить самую главную составляющую принципов – постоянную оценку достигнутого результата, продвижения проекта к намеченным целям и актуальности этих целей, соответствия ожиданиям заказчиков и пользователей. Именно в этом состоит замена традиционной концепции подробного планирования и далее – просто оценке следования плану, которую можно проводить механистично. Вместо этого мы постоянно смотрим: получено ли в результате разработки то, что действительно несет ценность и решает проблемы, как задумано? Как далеко мы продвинулись и сколько еще осталось? Каков прогноз достижения результата к бизнес-срокам, не пора ли существенно пересматривать состав работ? В целом, это достаточно естественный подход к ведению проектов со значительной долей неопределенности и Agile просто фиксирует, что IT-проекты именно таковы.

И, наконец, самая известная часть Agile – конкретные методы организации работы, такие как Scrum. Они дают способ воплощения принципов в виде некоторых процессов. Они обладают простотой и наглядностью, и потому привлекательны. Казалось бы, ничего сложного: берешь руководство и воплощаешь в организацию компании. Однако, будучи конкретной реализацией принципов, они обладают ограничениями, касающимися класса проектов, для которых они эффективны. Про это часто забывают, пытаясь применить их для совсем других категорий проектов. А еще забывают о том, что применение организационных фреймворков типа Scrum в IT поддержано большим количеством инженерных средств и практик, таких как Continious Integration, автоматические тесты, Task tracker и многих других. Если мы переходим в другую область, то эти средства тоже следует забирать. Одни из них забрать легко, например, Task tracker или доски, Jira сейчас применяется для любых задач, а не только в IT. Другие перенести невозможно, и надо вырабатывать альтернативные способы, чтобы обеспечить организационному фреймворку необходимую поддержку.

Так что простота Agile-методов – кажущаяся.

Для самостоятельной работы надо разбираться в их конструкции глубже. Это и будет предметом следующих статей. Естественно, это теоретическое знание все равно не заменит практического опыта, который есть у Agile-коучей. Но, я думаю, он позволит вам лучше разобраться в спектре Agile-методов и разумно выбирать варианты и стать квалифицированным заказчиком внедрения Agile. Тем более, что универсальных специалистов, знающих и способных внедрять все Agile-методы, практически не существует, а значит необходимо выбирать того, кто владеет методами, подходящими для вашей организации. Особенности вашего бизнеса знаете вы и потому конкретные решения принимать вам самому или совместно с ним. Вариант трансформации по готовому решению тут не работает.

На этом я заканчиваю рассказ про общую конструкцию Agile. В нескольких следующих статьях мы будем рассматривать Scrum – метод организации работы команды, который определил успех Agile-подхода. Да, он – не единственный, не самый первый, и далеко не самый общий, но именно его эффективность привела к широкому распространению Agile. Одна из причин – оказалось, что за счет разделения ответственности менеджера и командной работы в Scrum удается преодолеть дефицит компетентных руководителей групп и компетентных разработчиков. С появлением персоналок, доступных мелким и средним компаниям, и вызвавший большую потребность в IT-проектах этот дефицит был очень острым и именно он, на мой взгляд, способствовал быстрому распространению Agile-подходов на Западе. На постсоветском пространстве появление персоналок совпало с развалом оборонки и в IT пришло очень много квалифицированных инженеров, поэтому потребность была не столь острой. Следы этого сохранились и сейчас, но в целом современная IT-разработка основана на Agile-методах и на Западе и в России. Более того, если кто помнит статью о развитии IT-менеджмента в целом, с тех пор произошел еще один сдвиг культуры, о котором мы тоже будем говорить в серии статей.

Еще один фактор состоит в том, что в Scrum вставлены специальные предохранители против возврата к обычному менеджменту, и потому он способствует пониманию командой ценностей и принципов Agile. Но по этой причине его внедрение – всегда революция. В отличие от Kanban, который имеет гораздо более широкий диапазон применения. Он внедряется эволюционно, и его удерживает культура, а не процессы, а это всегда сложнее. Kanban мы тоже рассмотрим в этой серии статей, как и другие, более сложные конструкции. А дальше рассмотрим варианты применения для решения разных задач, выбор конкретных методов в разных ситуациях Agile-трансформации и конкретные кейсы Agile-трансформации.

Продолжение следует…