Юрген Аппело - Agile-менеджмент. Лидерство и управление командами
- Название:Agile-менеджмент. Лидерство и управление командами
- Автор:
- Жанр:
- Издательство:Литагент Альпина
- Год:2018
- Город:Москва
- ISBN:978-5-9614-0937-6
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Юрген Аппело - Agile-менеджмент. Лидерство и управление командами краткое содержание
Цель этой книги – дать понять, как работают Agile-команды. В ней нет кейсов, простых решений и банальных советов. Чего в ней в избытке, так это интересных идей, результатов экспериментов и поводов для размышления. В ней есть то, что действительно необходимо современным менеджерам: понимание общих подходов, с помощью которых вы сможете создать собственные рецепты, соответствующие именно вашим потребностям.
Agile-менеджмент. Лидерство и управление командами - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Простое и хорошо структурированное ПО может демонстрировать очень сложное поведение, в то время как неочевидным образом структурированное и довольно запутанно организованное ПО порой выдает упорядоченные и полностью предсказуемые результаты.
Еще раз об упрощении
Предлагаемая мною модель основана на противопоставлении структуры и поведения. Как мне представляется, она может упростить обсуждение вопросов, связанных с простотой, и снять ряд недоразумений.
Все следует упрощать до тех пор, пока это возможно, но не более того.
Альберт ЭйнштейнСвоим высказыванием Эйнштейн хотел сказать, что структура системы должна быть представлена в понятном виде. В терминах моей модели это предполагает вертикальный сдвиг сверху вниз (упрощение). Тем не менее оговорка «но не более того», по всей видимости, отсылает нас к поведению этой системы. Эйнштейн пытается предупредить нас, что следует избегать чрезмерного упрощения, поскольку это изменит сам характер данной системы (что в моей системе координат соответствует линеаризации, а не упрощению).
Простота – это миф, время которого прошло, если оно вообще когда-либо существовало [Norman 2007].
В своей интереснейшей статье «Простота сильно переоценена» Дон Норман обсуждает вопрос, насколько ценно с точки зрения пользователя добавление функциональных возможностей в тот или иной продукт по сравнению с их ограниченным количеством. Обилие функциональных возможностей подразумевает иное или более сложное поведение продукта, а зачастую и его иную структуру. В моей диаграмме этому соответствует движение по обеим осям – горизонтальной и вертикальной. (Например, когда Google добавил в почтовый сервис Gmail отдельный почтовый ящик для приоритетных сообщений, поведение Gmail усложнилось. Стал более запутанным и пользовательский интерфейс, хотя для меня он остался вполне понятным.)
К сожалению, Дон Норман использует термин «упрощение» как для обозначения линеаризации поведения (движение вдоль горизонтальной оси в моей модели), так и для обозначения упрощения структуры (движение по вертикальной оси). Тем самым он сделал свой тезис достаточно запутанным, и именно поэтому многие в нем не разобрались. Может быть, для иллюстрации своей мысли ему стоило бы воспользоваться рисунками:
Цель визуального мышления состоит в том, чтобы сделать сложные вещи понятными посредством визуализации, а не в том, чтобы упростить их [9].
В своем бестселлере «Визуальное мышление» Дэн Роэм предлагает использовать рисунки для представления идей в более понятном виде. Очевидно, что он говорит о сдвиге по вертикальной оси от запутанного к простому. Но даже в его предупреждении «не упрощать» присутствует терминологическая путаница. На самом деле Дэн имеет в виду, что при представлении в виде рисунков не должна утрачиваться сложность поведения системы, поскольку это помешает тем, кто пользуется данными рисунками, разобраться в существе вопроса.
Следовательно, если вам хочется упрощать, то, ради бога, упрощайте все, что трудно для понимания. Но при этом следует избегать линеаризации («упрощения») поведения системы, потому что это вводит в заблуждение.
Адаптивные и неадаптивные системы
Ни одна из представленных моделей не отражает способность многих систем самостоятельно перемещаться в интересной области, которая располагается между упорядоченностью и хаосом.
Когда я был маленьким мальчиком, сидел в ванне и вокруг плавали игрушки, меня завораживали воронки – они появлялись, когда вынимали сливную пробку. Играя с этими воронками, я постепенно обнаружил, что могу их остановить, заставить появиться вновь и вращаться в обоих направлениях. Этим воронкам приходилось терпеть мое присутствие, и они не могли адаптироваться к перепадам в моем настроении. Такие воронки – пример сложных неадаптивных систем. Они сложные, но не в состоянии адаптироваться [Lewin 1999: 15].
Несколько более интересны сложные адаптивные системы (САС). Они способны адаптироваться к внешней среде. В качестве примеров можно привести ребенка, который учится ходить; штамм бактерий, развивший резистентность к определенному антибиотику; водителей, пытающихся объехать пробку; колонию муравьев, обнаруживших недоеденный сэндвич, или команду разработчиков программного продукта, адаптирующихся к реальным потребностям заказчика.
Системы, о которых чаще всего идет речь в этой книге, включая команды разработчиков, будут сложными адаптивными . Они сами сдвигают себя в комфортную область между упорядоченностью и хаосом. Они способны обучаться и адаптироваться, а также двигаться по определенной траектории посредством «хаордических процессов», сочетающих в себе элементы хаоса и порядка, но никогда не являющихся ни полностью упорядоченными, ни действительно хаотическими [Highsmith 2002].
В той ванне десятки лет назад воронки были глупыми неадаптивными системами. Настоящей сложной адаптивной системой был я . Я адаптировал свои действия в зависимости от поведения воронок. И это помогало мне понять, как можно их контролировать.
Если исходить из представления, что команды разработчиков программных продуктов – это действительно системы, то можно ли считать такие системы сложными и адаптивными? Вправе ли мы сравнивать участников подобных команд с детьми, играющими в ванне?
Не злоупотребляем ли мы научным подходом?
При обсуждении гибких методологий разработки ПО мы регулярно слышим такие научные термины, как самоорганизация и эмерджентность .
Основная причина, почему теория сложных адаптивных систем актуальна при разработке программного обеспечения, это продвигаемая ею концепция эмерджентности и эмерджентных результатов [10].
Например, колония муравьев, мозг, иммунная система, Scrum-команды и город Нью-Йорк будут самоорганизующимися системами [11].
Scrum – это не методология, не четко расписанный процесс и не набор процедур. Это открытый фреймворк при разработке программного обеспечения. Применяемые правила ограничивают поведение сложной адаптивной системы, в результате чего система самоорганизуется и приходит в состояние, адекватное решаемой задаче [12].
Насколько оправданно применение теории сложности к разработке программного обеспечения? Согласны ли сами специалисты по сложным системам, что такие термины, как самоорганизация и эмерджентность, применимы не только к описанию муравейников, мозга и иммунной системы, но также и к Agile-командам?
Некоторые ученые уже обрушились с критикой на людей вроде нас за то, что мы заимствуем их научную терминологию. Они утверждают, что мы берем термины, не вникая в их значение, и используем научные понятия, не имея на то достаточных концептуальных оснований. И еще они говорят, что нас опьяняют сами слова вне связи с тем, что они на самом деле означают [Sokal 1998: 4].
Читать дальшеИнтервал:
Закладка: