Организации, разрабатывающие программное обеспечение, сегодня гораздо более осведомлены о значении эффективности процесса разработки, чем когда-либо раньше. Под словом эффективность здесь понимается свойство процесса, способствующее достижению организацией своих целей вследствие рационального управления риском, изменениями, планированием, качеством и прочими составляющими успеха проекта разработки ПО. В этом месяце мы рассмотрим, как реализовать такой процесс в вашей организации.
Однако мы подойдем к проблеме с необычной стороны. То есть вместо того, чтобы рассматривать позитивное поведение, которое помогает модернизировать процесс, мы разберем некоторые действия, которые, на первый взгляд, многое модернизируют, но на самом деле усугубляют положение вещей. Эти негативные действия обычно классифицируются термином анти-шаблоны.
Шаблоны представляют собой компоненты инструментария специалистов по программному обеспечению. В частности, мы изучали шаблоны проектов - способы проектирования программ, позволяющие сделать их более надежными, гибкими и правильными. Эрих Гамма (Erich Gamma) разработал основы принципа шаблонов проектирования программного обеспечения в своей диссертации на соискание ученой степени доктора философии в начале 90-х годов. Вдохновителем Эриха Гамма стал Кристофер Александер (Christopher Alexander), архитектор,который исследовал идею шаблонов в архитектуре (в обычной архитектуре, а не архитектуре программного обеспечения). Шаблоны ворвались в разработку программного обеспечения благодаря публикации в 1995 году книги Design Patterns (Шаблоны проекта).
Шаблон представляет собой проверенный подход к решению часто возникающих проблем. Шаблон не является конкретным решением, которое можно вырезать и вставить через буфер обмена, это принцип, который может помочь решить проблему. Шаблон - это не трафарет, с которым мы сталкиваемся, заполняя различные бланки.
Шаблоны не изобретают. Столкнувшись с проблемой, вы не садитесь специально за изобретение нового шаблона, который поможет решить эту проблему. Тот факт, что мы думаем о шаблонах как об элементах многократного использования, должен навести нас на мысль о том, что мы скорее открываем шаблоны, чем изобретаем их. Часто мы можем думать, что собираемся написать компонент программы многократного использования, на самом деле, многократное использование в первую очередь подразумевает использование . Поэтому до тех пор, пока кто-либо не использует наш компонент, а затем кто-либо еще снова не использует его, мы, по сути, не знаем, хорошо ли мы сделали свою работу по созданию некоего компонента многократного использования. Это же справедливо и в отношении шаблонов. Своим студентам я часто предлагаю простое правило большого пальца: Один раз - это случайность, два раза - совпадение, три раза - повод подумать, не открыли ли вы шаблон.
Шаблоны стали популярными, потому что они позволяют разработчикам говорить на одном языке. Разработчики используют термины наподобие "адаптер" или "фасад" примерно так же, как столяры используют термин "ласточкин хвост". Язык обогащает наш словарный запас словами, которые несут потрясающий объем семантического смысла. Как только в моду вошли шаблоны проектов, шаблоны стали появляться и в других областях разработки программного обеспечения, таких как процессы, анализ требований и т. д. Каждая область специализации хочет приобщиться к этому новому взгляду на мир. Шаблоны были "next big thing" 90-х. В данный момент существуют книги и статьи по шаблонам для процессов, управления требованиями, архитектуры программного обеспечения, тестирования, управления проектами и т. д. Практики и теоретики стремятся приложить хорошую идею ко всему, чем они занимаются. Я так любил свою объектно-ориентированную ручку в середине 80-х. Я просто говорил pen.write , и она, как по волшебству, делала свое дело.
Это необузданное стремление к поиску шаблонов привело, на мой взгляд, к классической ситуации: за деревьями мы не замечаем леса. Все вдруг оказалось шаблоном, от использования стандартного кода до пересмотра кода и выбора языка программирования. Применение шаблона требует осмысления, понимания проблемы, оценки последствий использования шаблона и опыта.
Одним из последствий открытия и применения шаблонов стало то, что шаблоны, как и лекарства, можно неправильно использовать. Другими словами, мы можем "прописать" приложению данный шаблон и обнаружить, что, к нашему сожалению, пациенту (в нашем случае, организации по разработке программного обеспечения), стало хуже, и он, возможно, даже умрет. Наблюдая это явление, мы открыли анти-шаблоны . Анти-шаблон возникает, если кажущийся подходящим подход к решению проблемы в действительности усугубляет проблему. Думаю, что первый анти-шаблон описал Фред Брукс (Fred Brooks), который обнаружил, что если добавить в проект, который не укладывается в сроки, больше сотрудников, то это приведет к еще большему отставанию проекта.
В предыдущих статьях рассказывалось о некоторых вещах, которые, по моему мнению, важно учитывать при реализации процесса в организации и коллективе. Но здесь я представлю некоторые анти-шаблоны, которых следует остерегаться, если вы решили заняться регулировкой процесса в своем коллективе.
Описание анти-шаблонов процесса разработки
Анти-шаблоны, как и шаблоны, имеют несколько форм, которые используются для того, чтобы их описывать. И, как и в отношении шаблонов, не существует универсального соглашения об их описании. Для наших целей мы будем использовать следующий формат описания анти-шаблонов, которые я обнаружил:
- Название. Название предоставляет краткую описательную этикетку для анти-шаблона;
- Контекст. Описывает проблему, которую вы пытаетесь решить;
- Доводы. Доводы описывают такие вещи в контексте организации, которые вынуждают рассматривать проблему в терминах ее преимуществ и недостатков и ведут к принципу решения проблемы;
- Решение. Это главная проблема анти-шаблона. После учета всех влияний выбирается подход. Вы делаете это, потому что все выглядит логично, как в примере Брукса о добавлении сотрудников в отстающий проект. Однако опыт показывает нам, что такое решение, в действительности, ведет нас к нарастанию проблем;
- Последствия. Описывает отрицательные эффекты использования выбранных шаблонов;
- Альтернативное решение. Это альтернативное решение, которое можно применить, чтобы избежать неприятных последствий.
Форма, которую я выбрал для представления описания анти-шаблонов, не является уникальной. Я попытался скопировать большую часть идей из книги Organizational Patterns of Agile Software Development (Организационные шаблоны динамической разработки программного обеспечения), авторы Коплин (Coplien) и Харрисон (Harrison). Я рекомендую эту книгу каждому, кто хочет узнать, как повысить эффективность разработки программного обеспечения в организации.
Хочу также пояснить, что мой список анти-шаблонов не был проверен эмпирически. Шаблоны отражают мои личные наблюдения, сделанные в организациях и проектах, в которых я принимал участие, был наблюдателем или изучал. С академической точки зрения, это просто исходная точка для более серьезного исследования. Коплин и Харрисон выполнили свою домашнюю работу и провели глубокое изучение шаблонов, которые были представлены в их книге. Я не намекаю, что моя статья заслуживает той же степени доверия, как их статья. Но я, тем не менее, предполагаю, что вы найдете некоторые примеры, которые окажутся созвучными вашему опыту и приведут к разумному решению.
Теперь к шаблонам...
| Название: | Примите сразу все таблетки |
|---|---|
| Контекст | Процесс, как лекарство - это благо. Он помогает привнести порядок и здоровье в организацию и способствует более равномерному ходу событий. В некоторый момент времени организация понимает, что необходимо модернизировать способ разработки программ и решает внести усовершенствования в свой производственный процесс. |
| Доводы | Процесс важен именно сегодня. Мы должны пережить проверки и соответствие техническим нормативам. Мы должны быть как можно более эффективными. Существует много компаний, консультантов и книг, которые помогут нам превратить наш хаотичный образ жизни в экономичный превосходный механизм для разработки программ на зависть всей отрасли. Наше руководство приобрело идею усовершенствования процесса и приказывает нам: "полный вперед!" |
| Решение | Мы приняли решение ввести во всей организации процесс по типу Software Development Life Cycle, SDLC (Жизненный цикл разработки программного обеспечения). Мы подготовили обучающие материалы, наняли лучших консультантов и сопровождение, которых только можно было найти за деньги, и назначили дату анонсирования нового процесса. С этого дня каждый будет думать непротиворечивым и предсказуемым способом, который можно измерять и постоянно улучшать. |
| Последствия | К сожалению, когда мы применили этот подход, дела не улучшились, они стали еще хуже. Перемены, особенно позитивные перемены, требуют времени. Отдельные сотрудники и организации могут воспринять небольшие порции перемен без крупных потрясений. Тем не менее, мы хотим верить, что если выпить целый пузырек лекарства под названием "процесс," то все наши болезни моментально улетучатся. Единственное, что происходит на самом деле - коллективы и их члены вынуждены тратить совершенно неоправданное количество времени и усилий, чтобы следовать процессу, и совсем незначительное время именно на решение тех проблем, которые они должны решать. В конце концов, люди перестают обеспечивать работу процесса и (или) создавать программное обеспечение. |
| Альтернатива: | Принимайте процесс в малой дозировке. Определите ключевые отрасли, в которых, как вы думаете, процесс может принести наибольшую пользу. Реализуйте, оцените результаты, а затем подготовьте следующий небольшой шаг. Если вы накопите полезную информацию о том, будут ли работать изменения и как они будут работать, то любой сможет понять преимущества и захочет принять следующее изменение. |
Я всегда удивляюсь, как часто проявляется этот анти-шаблон. Мне всегда казалось, что пошаговое введение изменений диктуется обычным здравым смыслом. Несмотря на это, в последние десять лет я наблюдал много организаций, которые пытались внести крупномасштабные изменения в свой способ работы. Причем совершенно не имеет значения, какой процесс они пытались реализовать. Аналогичный феномен я наблюдал в организациях, пытавшихся ввести Rational Unified Process, или RUP, модель технологической зрелости организации института программотехники (CMM) и динамичные процессы, например, eXtreme Programming (XP). Люди хотят верить, что лучший способ внедрить новый процесс - просто прекратить выполнять работу так, как они делали это раньше, и перескочить на новые способы работы. Слишком часто мы отказываемся от ценных методов работы в наших организациях только потому, что они не нашли отражения в новых, лучших, более современных процессах.
| Название: | Привлечение экспертов со стороны |
|---|---|
| Контекст | Когда мы переходим на новые методы работы, нам нужно убедиться, что мы правильно их понимаем. Мы не желаем тратить время, пытаясь использовать новые методы только для того, чтобы обнаружить, что мы делаем все неправильно, поэтому мы нанимаем консультантов, которые должны прийти к нам и немедленно запустить новый процесс. |
| Доводы | Время - деньги, и ввиду сроков, которые маячат перед нами, мы можем позволить себе потратить времени меньше, чем денег. Кроме того, эксперты досконально изучили процесс и знают, чего ожидать и как провести нас через опасные течения перемен, чтобы мы не разбились о скалы или не сели на мель. Наемные консультанты в наши дни стали образом жизни в корпоративном мире; поэтому это именно то, что мы можем доказать нашим руководителям. |
| Решение | Наймите экспертов-консультантов и обяжите их внедрить новые методы. |
| Последствия | Это решение может быть успешным, но шансы на то, что это будет не так, очень велики. Даже если все пройдет хорошо, то, вероятно, такое решение не окажет постоянного эффекта в организации. По сути, вы сняли с себя ответственность и возложили управление своим коллективом на консультантов. Члены коллектива могут работать лучше до тех пор, пока эксперт следит за ходом вещей, но когда эксперт уходит, все возвращается на исходные позиции. |
| Альтернатива: | Пригласите эксперта-куратора, который поможет членам коллектива выработать базу знаний и уверенность в самостоятельной реализации процесса перемен. |
У китайцев есть такая пословица: "Дай человеку рыбу, и ты накормишь его на весь день. Научи его ловить рыбу, и ты обеспечишь его пищей на всю жизнь." Аналогичную логику можно применить к модернизации процесса. Скажи сотруднику, как сделать что-то лучше, и он будет делать это, пока ты на него смотришь. Научи его как следует обдумывать и принимать решения по поводу того, какие изменения могут помочь, и он станет хозяином изменений и сделает все сам.
Кент Бек (Kent Beck) однажды заметил, что разработка программ - это просто слушание, тестирование, кодирование и проектирование, а тот, кто говорит что-то еще, просто пытается вам что-то продать. Хотя я не могу согласиться с тем, что набор действий по разработке программ исчерпывающий, думаю, что в этом утверждении есть определенная мудрость. Консультанты тоже делают бизнес и кое-что продают - себя. Чем больше вы продаете, тем больше зарабатываете, поэтому если им удастся доказать свою незаменимость, они продадут и заработают больше. Это один из возможных взглядов на положение вещей. Я думаю, что по-настоящему хорошие консультанты по процессам и методологии - это люди, которые хотят помочь вам и вашей организации изучить и усвоить знания, которые у них есть, и помочь вам овладеть ими. Они счастливы, уходя с успешной встречи, на которой вы стали самостоятельными. Такие консультанты работают с вами, а не только для вас.
| Название: | Планирование реализации процесса |
|---|---|
| Контекст | На реализацию нового процесса, даже если она выполняется понемногу, требуется время. Следует отвести для своего коллектива определенное время на изучение новых методов и обучение их правильному использованию. |
| Доводы | В жизни за все приходится платить. Любые действия отнимают время. Когда вы работаете над какой-либо важной задачей, вы составляете расписание. В конце расписания вы оставляете время на выполнение задачи. Почему же внедрение нового процесса должно отличаться от других задач, которые нужно решить коллективу? Выделите достаточно времени на реализацию процесса. |
| Решение | Запланируйте определенное количество времени на реализацию процесса. |
| Последствия | У реализации процесса много общего с разработкой программного обеспечения. И то, и другое требуют человеческих усилий и времени. Оба процесса также уязвимы против незапланированных изменений. Когда обучение и тренинги являются частью этой задачи, люди реагируют по-разному. Существуют различные стили обучения, и каждому человеку требуется разное время, чтобы чему-либо научиться, это зависит от его стиля обучения и способностей. Коллективы обладают такими же характеристиками. Каждый коллектив воспринимает новую информацию с разной скоростью. Если вы запланируете фиксированное количество времени на изучение нового процесса, то обязательно обнаружатся некоторые моменты, которые окажутся неизученными, а они могут быть важны для успеха проектов, над которыми работает коллектив. |
| Альтернатива: | Рассматривайте реализацию процесса как отдельный проект. Дайте коллективу возможность изучать новый процесс итеративно и поэтапно. Управляйте объемами работ по реализации так же, как если бы это был любой другой проект. |
Когда я носил прозвище "ворчун RUP," у меня была возможность посещать и наблюдать многих потребителей. Одним из самых запоминающихся стал визит на завод Volvo в городе Гетеборг, в Швеции. Борис Карлссон и его сотрудники отвечали за реализацию процесса в группе разработки программного обеспечения. Борис и его коллектив работали над реализацией процесса точно так же, как они выполняли проекты программ. Они собрали требования, запланировали действия, необходимые разработчику для понимания того, как использовать новый процесс, а затем запустили пилотные проекты для различных коллективов разработчиков. Они разработали обучающие модули и программы обучения точно по расписанию и курировали весь коллектив. Это было одно из самых успешных развертываний RUP, которое я когда-либо наблюдал.
| Название: | Коллективное право собственности |
| Контекст | Чтобы привлечь внимание членов коллектива к новому процессу, каждому предоставляется "право собственности" на процесс. |
| Доводы | Люди лучше реагируют на изменения, если они участвуют в процессе и имеют некоторый контроль над его изменением. Предоставляя отдельным членам коллектива право собственности на реализацию процесса, вы получаете их участие и желание принять процесс и работать несмотря на потрясения, которые, естественно, возможны при вводе новых методов. Организация хочет привлечь сотрудников к принятию решений. Вследствие важности внедрения процесса членам коллектива предоставляется возможность - а иногда и обязанность - определять специфику процесса и план реализации. Участие сотрудников в управлении действительно работает. Существует много примеров компаний, которые описывают успешные случаи коллективного управления, например, кружки качества. |
| Решение | Члены коллектива определяют процесс и согласны с введением самого процесса и с тем, как он будет вводиться, до того, как начнется его развертывание. |
| Последствия | У этого подхода есть два отрицательных последствия. Во-первых, может случиться, что новый процесс никогда не будет запущен. Люди считают, что у них есть право вето на все, что им не нравится, и они стремятся использовать его, чтобы вызвать раскол на собраниях, где может быть достигнут реальный прогресс. В результате они убивают инициативу, так же, как законодатели убивают законопроекты, рассматривая их на заседаниях комитетов. Во-вторых, если вводятся изменения процесса, они являются комбинацией излюбленных методов, которые просто не работают вместе и оказываются хуже, чем любой процесс, который имел место до введения изменений. |
| Альтернатива: | Специфические изменения процесса определяются небольшой группой сотрудников. Эта группа затем приглашает других членов коллектива, чтобы представить процесс и получить обратную связь и внести изменения, которые имеет смысл сделать до запуска изменений. |
Важный момент заключается в том, что каждому члену коллектива предоставляется возможность предложить свои идеи, при этом люди знают, что они будут услышаны. Самый эффективный способ реализовать изменение - это четко описать само изменение, объяснить, почему оно необходимо, и рассказать об ожидаемых преимуществах. Затем надо позволить людям обсудить услышанное, ведь изменение коснется именно их. Оказывается, люди часто имеют идеи, которые могут сделать изменение более эффективным, кроме того, они обнаружат проблемы, о которых вы могли не подумать. Вы должны суметь поблагодарить их за хорошие идеи и не побояться изменить свою точку зрения, столкнувшись с хорошей идеей. Если вам не хватает гибкости мышления, не следует реализовать изменение процесса - здесь нет места для самолюбия.
| Название: | Малые приращения, непродолжительные итерации |
|---|---|
| Контекст | Вы решили организовать усовершенствование процесса по образу проекта разработки программного обеспечения: сделать его итеративным и поэтапным. Кажется, проекты программного обеспечения получаются лучше, если эти приращения небольшие, а итерации делаются как можно менее продолжительными. |
| Доводы | Вам нужна модернизация, и вас заставляют провести изменения настолько быстро, насколько это возможно. Мы думаем, что если отдельные приращения будут меньше, то введем их быстрее. Как только мы закончили внедрение первого изменения, мы начинаем вводить следующее. Люди могут научиться за один раз только чему-то одному, и кажется справедливым, что этот подход действительно уменьшит общую продолжительность изменений процесса, и мы сможем пожинать преимущества, предоставляемые переменами, как только они будут реализованы. Результирующий эффект должен быть кумулятивным. |
| Решение | Вы создаете группы внедрения, обучающие материалы и обучающие сессии для каждого изменения, планируя их таким образом, что между отдельными волнами , или итерациями, которые вводят новый метод, остается очень короткий промежуток времени. |
| Последствия | Этот подход ведет к неразберихе. Если вы только что рассказали о чем-либо, это еще не означает, что люди это поняли и могут применить на практике. Людям требуются разные промежутки времени, чтобы хотя-бы частично стать компетентными в использовании новых методов. Если просто быстро и непрерывно подбрасывать им новые изменения, это в действительности увеличит время, необходимое для внедрения изменения, и может даже, как ни прискорбно это звучит, привести к общему провалу модернизации процесса. |
| Альтернатива: | Определите небольшие наборы изменений, которые направлены на конкретные области организации процесса. Например, научите людей применять полезные примеры для анализов требования, проектов систем и тестирования. Обучайте людей на курсах переподготовки все это время. Позвольте им использовать новые методики во всем проекте. Затем вводите следующий набор методов и изменений. На все нужно время. Пока вы не предоставите людям возможность усвоить новые методы, испробовать их, адаптировать к отдельным проектам и, наконец, окончательно научиться их использовать, у вас немного шансов на то, что они действительно справятся с ними. Это именно тот случай, когда поспешишь - людей насмешишь. |
Эти несколько анти-шаблонов дают нам понимание того, что может пойти не так, если хорошие идеи применяются ошибочным способом. Вы, вероятно, думаете, что их намного больше. Я хотел бы порекомендовать вам прочитать книгу "Организационные шаблоны динамической разработки программного обеспечения" и попытаться подобрать к представленным шаблонам анти-шаблоны. Как минимум, это заставит вас глубже разобраться в самих шаблонах.