Вы случайно не PHP Middle?
Максим Цепков
1249

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-манифеста не следуют из ценностей, они опираются на опыт ведения IT-проектов.

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

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

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

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

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

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

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

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

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

{ "author_name": "Максим Цепков", "author_type": "self", "tags": [], "comments": 6, "likes": 2, "favorites": 18, "is_advertisement": false, "subsite_label": "unknown", "id": 96264, "is_wide": true, "is_ugc": true, "date": "Sat, 07 Dec 2019 10:52:52 +0300", "is_special": false }
Трибуна
PDF Remote — Простой инструмент для презентаций
Привет, сегодня хочу рассказать про наш новый продукт для презентаций.
Объявление на vc.ru
0
6 комментариев
Популярные
По порядку
Написать комментарий...
0

Добрый день, Максим! 

Спасибо за статью. А можете подробнее рассказать про адаптацию ценностей Agile для образования, про опыт внедрения, если есть, в ВУЗах. С одной стороны, знаком с концепцией Agile на практике, с другой стороны, есть опыт преподавания в ВУЗе, но сам никак не могу представить, как Agile мог бы работать в ВУЗе.

Ответить
1

Добрый день! Про ВУЗ совершенно понятно, что разработка проектов может выполняться с использованием Agile-методов. В том числе и студенческих учебных проектов, обучать не только техникам выполнения работы, но и ее организации, навыкам командной работы и так далее. Насколько я знаю, это достаточно распространено и я слышал об этом в обсуждениях на конференциях. Хотя докладов я не слышал, и это всегда была частная инициатива преподавателей, а не предписанная организация процесса: они просто вместе с заданием на проект предписывали и обучали современным методам - спринты, демонстрации, таск-трекер и так далее. Тут дело в организации процесса образования в ВУЗе: часто учебные проекты выполняют в рамках курсов по специальности, а управлению проектами учат в других курсах. которые ведут другие преподаватели и часто на другом курсе. По-хорошему. методисты, которые увязывают курсы в учебный процесс, должны об этом подумать, плюс нужно междисциплинарное объединение, когда учебный проект курируют и тот, кто преподает специальный дисциплины и тот, кто преподает ведение проектов.

Что касается перестройки основного учебного процесса, то я слышал про опыты перестройки в школах по Agile, есть фреймворк eduScrum и
в Москве, говорят уже больше сотни школ процесс меняют. Такой опыт регулярно рассказывают на AgileDays, можно посмотреть мой отчет http://mtsepkov.org/AgileDays-2019 этого года, доклад Agile-школа, а в конце там ссылки на доклад предыдущего года, тоже очень интересный. А ВУЗы - нет, работают традиционно.

Вообще основная сложность применения, например, Kanban в ВУЗе для учебной программы в целом - в сильно отложенном результате, непонятно, как мерить поток создания ценности и его оптимизировать. Так что это будут какие-то другие методы, думаю.

Ответить
0

Меня больше интересовало не использование Agile в процессе преподавания предмета, например, выполнения учебного проекта и применение на нем Agile-методологии  - тут, действительно, много кто что делает по своей личной инициативе, а использование Agile в процессах управления ВУЗом, самого процесса преподавания - изменение подходов к обучению, обновлению материалов  и.т.д. 

Про школы интересно - спасибо!

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

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

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

Можно ли по Agile построить сам процесс преподавания предмета, скажем алгебры, чтобы адаптироваться под обучающихся? Известны ли такие примеры?

Ответить
1

В школах получается комбинированная конструкция для учеников, это хорошо рассказывал Павел Рабинович (в моем отчете http://mtsepkov.org/AgileDays-2018 ссылки, а вот здесь подробный конспект выступления, на котором я с ними познакомился http://mtsepkov.org/GosAgile-2017-06 Есть директивно установленная программа на год, например, по математике или химии, изложенная в учебнике и со своими точками контроля в виде контрольных или лабораторных работ. И это то, что менять нельзя. А вот в промежутках между ними, оказывается, способ обучения не нормирован. И дальше ученикам формируют бэклог материала и заданий, а они в командах решают, как именно будут изучать, и там как раз возможны различные варианты. То есть никакой рабочей программы, где все расписано по урокам - нет, хотя рамочно набор тем - обозначен. В принципе это похоже на Agile-разработку, если рассматривать тему как эпики, которые в целом надо сделать - декомпозиция на задачи и поиск способа выполнения происходит позднее.

Наверное, при известном вольном отношении в ВУЗе так тоже можно - ты делаешь рамочную программу, а содержание детализируешь и меняешь прямо в процессе обучения. И дальше вопрос, что ты этой рамочной программой несколько скован, но, наверное, не больше чем разработчики первоначальным ТЗ и договором. 

Ну и следующий вопрос - переход от индивидуальной работы, когда каждый преподаватель сам делает свою программу, к коллективной когда есть задача обучения готового специалиста, а содержание курсов может перераспределять относительно гибко. И организовывать по Agile уже работу преподавателей - операционку по Kanban, а проекты изменений по Scrum. Кстати, учителя на Agile-2019 (ссылки в предыдущем посте) говорили, что изменения учебного процесса они сами организуют по Agile. Но без подробностей.

Ответить
0

Спасибо за развернутый ответ!

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

А вот при проведении основных курсов, ничего не могу поделать с собой, вызывает определенную долю скепсиса - вся вариативность работает до первой жалобы студента, недовольного итоговой или промежуточной аттестацией - и такой преподаватель получит по шапке. Не пойму, в этом случае, мотивацию преподавателя - выстраивать по-новому процесс обучения, тратить на это много сил и энергии, при этом все может быть разрушено в любой момент одной единственной жалобой. Преподавателю очень быстро и доступно объяснят, что вот это не работает "Готовность к изменениям важнее следования первоначальному плану."  Да и ФГОСы нового поколения сильнее ограничивают вариативность содержания предметов, как мне кажется и реформа с лицензиями различных уровней, тоже снижает возможность вариативности, по крайней мере для большинства ВУЗов. Но это не вопрос, а просто мое брюзжание...

Спасибо! Получил для себя много полезной информации. 

Ответить
0

Евгений, добрый день! Меня зовут Екатерина, я - ведущий тренер eduScrum в России. С интересом читаю статьи Максима, и вдруг ваш вопрос. У нас в команде тренеров eduScrum есть Татьяна Аксенова https://www.facebook.com/tatyana.axenova.1/posts/2190286171083854 - она год преподавала в ВУЗе по eduScrum, провела три проекта, которые покрывали 3 семестра, и подробно писала о своем опыте в сообществе https://www.facebook.com/groups/eduscrum/ (к сожалению, не одним постом, а серией). Вы можете посмотреть в группе, можете поговорить с Татьяной если захотите подробностей. В целом, если в прошлом году все началось со школ, где проектное обучение требуется по ФГОС, а также необходимы практики, которые развивают межпредметные компетенции, то в этом году начали шевелиться и ВУЗы, пока точечно, но мы уже привыкли к движению небольшими шагами. :)

Ответить

Комментарии