Вопрос документирования в процессе разработки бесспорно заслуживает пристального внимания как один из наиболее важных. Мне столько раз приходилось слышать сетования на недостаточную документированность требований или технических решений, что наверно уже давно пора было бы принять решение "чем больше документации - тем лучше". Однако я бы с таким решением не спешил. Дело в том, что (как показывает практика) большинство софтверных проектов - это далеко не реализация точно заданных требований по заранее определённым техническим методикам. Такая удача - удел академической науки либо госзаказ для военной или космической программы. Большинство же современных коммерческих софтверный проектов активно эксплуатируют "софт"-составляющую процесса, а именно: и бизнес-, и технические требования к проекту как правило меняются очень динамично.

Ответом на это стало появление динамических методологий, основная масса которых относится к документированию приблизительно следующим образом: "Документирования нужно ровно столько, сколько решит команда и спонсор для данного конкретного проекта" [1].

Второе открытие динамических методологий заключается в том, что документирование может быть выражено в различных формах. Наследие инженерных дисциплин сводило документирование к узкому классу инженерных артифактов, а именно "инструкция (алгоритм)" и "чертёж (диаграмма)". Большинство же гибких методологий, протестуя против инженерной сути софтверной разработки, предлагает более вольное трактование понятия "проектная документация" и включают в него все возможные артифакты, способные служить метками, по которым можно восстановить суть ценной для проекта информации, начиная c салфеток с набросками пользовательского интерфейса и заканчивая фотографиями доски или даже видеозаписями митингов или дискуссий [2].

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

Из этой модели следуют и очевидные рамки её применимости:

 - Чем хуже коммуникации, тем больше нужно маркеров, например для эффективной работы удалённой команды этих маркеров нужно больше всего.

 - Чем строже формализм, тем больше нужно формальных документов взамен "распределённого знания", например для военных разработок роль "распределённого разума" незначительна.

 - Чем выше риск потери части "распределённого знания" (уход или долгое отсутствие сотрудников), тем выше должно быть дублирование этих знаний и тем больше маркеров приходится задействовать. 

 - Чем больше новичков приходится подключать к проекту, тем больше маркеров и тем подробнее эти маркеры.

Источники

1. Alistair Cockburn 'How many work products are needed in software development?'

2. Alistair Cockburn 'The end of software engineering and the start of economic-cooperative gaming'

К сожелению или к счастью, но оффшорный аутсорсинг и аутстаффинг уже стали неотъемлемой частью бизнес-модели современной разработки ПО. Ими пользуются компании всех "рангов" - от стартапов с командой из двух человек до софтверных гигантов. Обсуждение преимуществ и недостатков таких тенденций выходит за рамки данного поста, однако с учётом сложившейся ситуации мне представляется ценным сформулировать основные советы и рекомендации участникам процесса удалённой разработки. За последные несколько лет я побывал пожалуй во всех возможных ролях этого процесса, так что накопил некоторый собственный опыт в данной области, к тому же сегодня я буду апеллировать к наработкам ведущих мировых авторитетов [1].

Начну я с той ошибки, которую поначалу допускают многие: "В условиях нашей конкретной задачи переход на удалённую разработку ничего не меняет".  Каковы бы ни были условия вашей задачи, процесс удалённой работы радикально изменяет модели поведения участников такого процесса и их ощущения во время работы. Это не только подтвердит вам любой руководитель или разработчик, работавший удалённо, но и очевидно следует хотябы из того факта, что именно коммуникации (которые играют основную роль в процессе и несут основной вклад в успех) изменяются больше всего при переходе на удалённую работу.

Нужно заметить, что большинство приведенных ниже рекомендаций хорошо бы соблюдать не только для удалённой разработки, однако именно расстояние делает их особенно важными:

 - Старайтесь разделять команды по функциональности и модулям, а не по ролям - удалённая команда QA конечно тоже имеет право на существование, однако когда разработчик и тестировщих находятся близко друг к другу, эффективность растёт.

 - Если кодом совместно владеют удалённые команды, то ежедневно собирайте автоматические билды - это позволит сделать вносимые изменения более прозрачными, а также оперативно устранять "поломанные билды" и юнит-тесты.

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

 - Пользуйтесь тестовыми скриптами для лучшего понимания требований - нет ничего более понятного для разработчика, чем код.

 - Проводите совместные митинги по планированию итераций и регулярные статус-митинги.

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

 - Регулярно посылайте представителей от обеих сторон с личным визитом друг к другу - это позволяет улучшить комуникации, построить доверие и усилить обе команды.

 - Бойтесь недооценить культурные, региональные и языковые различия - сюрпризы могут поджидать вас там, где вы даже не подозреваете.

Источники 

1. Martin Fowler 'Using an Agile Software Process with Offshore Development'

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

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

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

Однако есть и хорошие новости, которые заключаются в том, что существуют предложенные разными авторами наборы паттернов, проверенных опытом реакций менеджера на возникновение определённых рисков. Естественно, эти паттерны не могут подойти в 100% ситуаций, более того, они всегда потребуют определённой интерпретации в условиях конкретного проекта и конкретного риска. Однако такие паттерны способны дать определённое нулевое приближение, начальную рекомендацию, которая уже может быть пропущена менеджером через призму ситуации и превращена в готовое решение.

Сегодня я приведу набор паттернов уменьшения рисков, предложенный Алистэром Коуберном в [1]:

1. Знания: Рассеивание тумана (Clear the Fog)
Если вы не знаете риски и трудности проекта достаточно хорошо для того, чтобы разработать хороший план - попытайтесь выпустить хоть что-то, это даст вам понять в чём реальные трудности.
Частные случаи: "Ранние и регулярные выпуски", "Прототип", "Микрокосм".

2. Знания: Ранние и регулярные выпуски (Early and Regular Delivery)
Вы не знаете какие проблемы вам встретятся в процессе разработки - выпустите что-то как можно раньше и выясните то, чего не знаете. Выпускайте регулярно совершенствуясь каждый раз.

3. Знания: Прототип (Prototype)
Вы не знаете как некотрые архитектурные решения себя поведут - разработайте отдельный испытательный прототип и понаблюдайте как он на самом деле работает.

4. Знания: Микрокосм (Microcosm)
Вам нужно разработать реальный план, но вы никогда не занимались проектами такого рода - запустите 8-12 недельный "пилотный" этап и соберите данные о продуктивности и т.п. для вашего плана.

5. Командная работа: Целостное многообразие (Holistic Diversity)
Разработка некоторого модуля требует разных умений, а люди имеют узкую специализацию - создайте команду из людей с разными умениями.

6. Продуктивность: Золотой рывок (Gold Rush)
У вас нет времени ждать утверждённых требований - начните разработку немедленно, корректируйте её по последним требованиям еженедельно.

7. Владение: Один ответственный на продукт (Owner per Deliverable)
Иногда над чем-то работает много людей, иногда никто - убедитесь что у каждого продукта (выпуска) есть ровно один ответственный.
Частные случаи: "Владельцы функциональности и компонент", "Одна команда на задачу"

8. Владение: Ответственные за функциональность и компоненты (Function Owners / Component Owners)
Если вы организовываете команду по компонентам, то страдает функциональность, и наоборот - убедитесь что за каждую функциональность и каждую компоненту кто-то отвечает.

9. Помехи: Кто-то всегда движется к цели (Someone Always Makes Progress)
Помехи постоянно прерывают работу команды - убедитесь что кто-то движется к цели что бы не случилось.
Частные случаи: "Одна команда на задачу", "Жертва", "Ежедневная забота"

10. Помехи: Одна команда на задачу (Team per Task)
От команды требуется серьёзное отвлечение от основной задачи - пусть этим займётся часть команды, а основная команда продолжает идти к цели.

11. Помехи: Жертва (Sacrifice One Person)
От команды требуется небольшое отвлечение от основной задачи - поручите это одному человеку.

12. Обучение: Ежедневная забота (Day Care)
Ваши експерты тратят всё свое время на обучение новичков - выделите одного эксперта курировать всех новичков, остальные разрабатывают систему.

В самой статье приводится детальное описание ситуаций с примерами и подробное объяснения механизма работы каждого паттерна, так что тем кто заинтересовался лучше ознакомиться со статьёй полностью.

Источники

1. Alistair Cockburn 'Project risk reduction patterns'

Когда в 1968 году на конференции НАТО впервые был введён термин “software engineering” для разработки ПО как одной из областей инженерии, эта классификация была скорее вызовом, стимулом для дальнейшей работы, чем основанной на реальном опыте моделью. Однако за неимением ничего лучшего она быстро прижилась, и на протяжении последующих 40 лет философы и методологи разработки ПО боролись с использованием этого подхода в основном по 4-м причинам:

• Такая классификация никак не отражает наиболее важные для успеха проекта вещи, такие как талант, мастерство, командное взаимодействие и коммуникация между людьми.
• Такой подход не соответствует историческим данным об успехах и провалах проектов, в частности противоречит более вероятному успеху проектов с менее строгими "церемониями" и с более "легковесным" с точки зрения правил и рамок процессом.
• После 40 лет использования разные люди и организации всё ещё трактуют термин и процесс "софтверной инженерии" совершенно по-разному.
• Ни термин, ни классификация не дают раельно эффективного направления работы в области разработки ПО, которое могло бы гарантированно (или хотябы вероятно) привести проект к успеху.

Многие авторы предлагают свой собственный подход к этой проблеме. В этом посте я хочу поделиться моделью, предложенной Алистэром Коуберном [1]:

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

Такая модель действительно раскрывает все важные для успеха проекта проблемы: сотрудничество, коммуникации (а особенно их стоимость, доля и необходимое количество), индивидуальные таланты и умения, отношения между людьми-как-индивидуумами в парах и группах, ценность сохранения устоявшихся команд, уменьшающаяся отдача от детального моделирования и документирования [2], важность обучения и применения различных стратегий для различных обстоятельств.

И хотя большинство словарей при определении термина 'игра' акцентируются на развлекательном аспекте (что и вызывает несогласие с игровой моделью Коуберна), смысл этого термина претерпел существенные изменения на протяжение последних десятилетий, так же как и отношение к удовольствию, получаемому участниками рабочего процесса от выполняемой ими работы. Именно необходимость получения этого удовольствия для успешной работы и приводит разработку ПО так близко к термину игры.

Опуская детальную классификацию игр, обсудим лишь категорию, в которую попадает разработка ПО: это конечная (ограниченная достижением конкретной цели) игра, основанная на сотрудничестве. В этой же категории находится, например, альпинизм: конкретной целью является достижение вершины, а участники игры не конкурируют, а сотрудничают для достижения этой цели. После достижения цели как правило происходит оценка удовольствия, полученного от процесса, и анализ ошибок, результаты которого невероятно ценны для достижения последующих целей. Это как две капли воды похоже на разработку софта, только цель там своя - получение и развёртывание работоспособной системы. Второстепенная цель при этом точно та же: в процессе и по окончанию игры извлечь максимальную пользу и тем самым как можно лучше подготовиться к следующей игре. При этом большинство проектных команд ограничено во времени, деньгах и людях, так что полное достижение обеих целей врядлм возможно. Это и делает протекание каждой игры таким чувствительным к личностным характеристикам участников и (как следствие) абсолютно неповторимым.

Источники

1. Alistair Cockburn 'The end of software engineering and the start of economic-cooperative gaming'

2. Alistair Cockburn 'How many work products are needed in software development?'

Для начала поговорим о понятиях: 

• Инкрементная (incremental) разработка - это стратегия планирования стадий проекта, при которой различные части системы разрабатываются в разное время, а затем интегрируются (в противоположность стратегии "большого взрыва", когда все части разрабатываются одновременно, а в самом конце разработки интегрируются). При инкрементной разработке вся система разбивается на отдельные компоненты или модули, разработка каждого из которых планируется и осуществляется отдельно во времени, с последующей интеграцией в систему по мере готовности.
• Итерационная (iterative) разработка - это стратегия планирования ревизий системы, во время которых система определённым образом дорабатывается или усовершенствуется (в противоположность стратегии, когда система планируется и создаётся сразу совершенной, идеальной). При итерационной разработке основным видом деятельности является усовершенствование, доработка существующей системы: не только производительности, качества кода и функциональных возможностей, но и требований, интерфейсов, технологий, архитектуры и алгоритмов.

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

Инкрементная разработка незаменима для больших систем, однако она сравнительно проста в планировании. Итерации сравнительно более сложно выделять и планировать, как следствие ими сложнее управлять (особенно для больших систем), однако например в условиях нечётких или изменчивых ребований они бесспорно необходимы. Таким образом, применение к сложной системе обоих подходов многократно усиливает каждый из них: разбивая всю систему на инкременты и применяя к каждому из них итерации, мы таким образом делаем процесс одновременно более управляемым и более гибким для переработок. Кроме того, самая рискованная и ответственная часть инкрементной стратегии - интеграция - перестаёт быть таковой как раз благодаря итерационному процессу.

Источники

1. Alistair Cockburn 'Using both incremental and iterative development'

Думаю, что методика "подрезания хвоста" (“trim the tail”) интуитивно используется многими менеджерами проектов, однако весьма полезно было бы ознакомиться с тем, как Алистэр Коуберн в своей статье [1] приводит довольно подробное описание и аргументацию эффективности этого подхода.

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

Согласно методике, стратегия работы над проектом состоит из двух основных стадий:

1. Как можно раньше определить наибольшие социальные и технические риски проекта (как правило, все и так это делают), разбить их на как можно более мелкие компоненты (задачи). Работать над этими "рискованными" задачами на как можно более ранней стадии проекта до перевода в статус "нерискованных". Таким образом происходит как можно более раннее накопление критических знаний о системе (рис.1).

2. Определить и расставить приоритеты самым ценным для бизнеса функциональным единицам проекта (как правило, все и так это делают) и работать над ними в порядке убывания приоритетности. Таким образом происходит максимально быстрое увеличение бизнес-ценности системы (рис.2).

Рисунок 1: раннее накопление критических знаний о системе.	Рисунок 2: быстрое увеличение бизнес-ценности системы.

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

Рисунок 3: отрезаем хвост.

Это и состовляет наибольшую ценность подхода: спонсор в реальном времени получает безопасную с точки зрения рисков возможность "отрезать хвост" (рис.3): найти оптимальный для бизнеса балланс между временем выпуска системы и её фунциональной наполненностью.

Источники

1. Alistair Cockburn 'From Agile Development to the New Software Engineering'

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

Обычной реакцией на обнаружение несоответствия ценностей является попытка изменить сами культуры. Например, убедить руководителя отменить все митинги и просто дать программистам работать над проектом "пока они всё не сделают", или попросить пользователей стать экспертами в ООП, или дизайнеров использовать формальные нотации... Группы пытаются изменить друг друга.

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

Результаты такой работы дали бы возможность:
1. Распознать все культуры, вовлечённые в проект, и их ценности.
2. Найти людей, способных работать по обе стороны разных культур и которые бы способствовать эффективной коммуникации культур и сглаживанию основных противоречий.
3. Информировать каждую из групп о целях и ценностях других групп, относиться к ним с должным вниманием и уважением и в то же время знать и использовать всё, что другая культура может им предложить.
4. Применить наработанные этнографические и антропологические техники для изучения каждой группы и обнаружения их сильных и слабых сторон.

Коротко говоря, это дало бы возможность при организации работы над проектом использовать объективные факты вместо желаний и догадок, как это делается сейчас.

Источники

1. Alistair Cockburn 'What can OO programming learn from anthropology?'

Основой для данного поста послужила статья Jason'а Yip'а 'It's Not Just Standing Up: Patterns of Daily Stand-up Meetings', пропущенная через призму моего собственного опыта ежедневных Scrum-митингов в Microsoft.

Вот перечень нескольких основных принципов, без следования которым ваш Scrum-митинг наверняка потеряет львиную долю эффективности:

Цели:  

 - Поделиться обязательствами. Это самая важная цель ежедневного stand-up'а, более важная, чем поделиться прогрессом или состоянием задач.

 - Обсудить статус, прогресс и планы с командой и наблюдателями. Обсуждение статуса наиболее всего отличает stand-up от любого другого вида статус-митингов, т.к. во время stand-up'а члены команды сообщают статус друг другу, а не своему менеджеру. Обсуждение статуса также даёт возможность команде быть в курсе всего, чем занимается команда каждый день.

 - Выявить препятствия, чтобы команда могла предпринять шаги по их устранению. Хороший stand-up должен создавать ощущение поддержки, любой намёк на обвинение или осуждение быстро останавливает людей от оглашения своих проблем во время stand-up'а. Более того, оглашённые проблемы обязательно должны быть решены или поручены тем, кто их может решить.

 - Установить направление и приоритеты.

 - Тим-билдинг. Нельзя забывать, что основной фокус stand-up'а - это всё-таки не задачи, а люди, и stand-up призван решать именно человеческие проблемы и трудности.

Место и время:

 - Продолжительность ежедневных stand-up'ов - не более 15 минут, т.к. после 15 минут среднестатистический человек начинает терять состредоточенность. Недопустимо потакание некоторым любителям поболтать и их "рассказыванию историй". Также не нужно немедленно решать возникшие проблемы. Обсудите только вопросы, удовлетворяющие целям stand-up'а, все остальные вопросы обсудите после митинга или вынесите на отдельный митинг. Для того, чтобы митинг не затянулся, проводите его стоя, что также придаёт дополнительную энергетику.

 - Динамичность и энергетика, обусловленные короткой продолжительностью, должны давать заряд бодрости на весь день. Кроме того, желательно, чтобы конец митинга был тем-то чётко обозначен, например характерной фразой, т.к. это (в противовес постепенному осознаванию, что сказать больше нечего) позволяет сохранить энергетику и динамику митинга.

 - Проводите ежедневный stand-up в одном и том же месте в одно и то же время. Не ждите опаздывающих, даже если это менеджер или лидер, митинг проводится для всей команды а не для какой-то отделной персоны.

 - Проводите stand-up в начале дня. Если в команде гибкий рабочий график, проводите митинг в самом начале времени, к которому собираются все. Помните, что stand-up задуман как психологическое начало рабочего дня.

Участники: 

 - Все члены команды должны принимать участие в Scrum-митинге. Если кто-то не может учавствовать лично, он может поучавствовать по телефону или его статус должен огласить другой член команды.

 - К Scrum-митингам, как и к любым другим, нужно готовиться. “Что я делал вчера?... Не помню уже... Что я делаю сегодня?... Посмотрим по ходу...” - такого быть не должно, все должны чётко знать свои 'Вчера', 'Проблемы' и 'Сегодня'.

Управление:

 - Члены команды не рапортуют лидеру. Основа ежедневных stand-up митингов заключается в самоорганизации, хороший stand-up самоуправляемый, он больше похож на кофе-брейк, чем на митинг.

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

 - Все знают, кто должен говорить первым, для этого не нужна команда ведущего. Заведите правило наподобие "Первым говорит тот, кто пришёл последним" или любое другое.

К сожалению, многие менеджеры, особенно имеющие существенный опыт руководства до перехода к Scrum, подсознательно тяготеют к несоблюдению многих из приведенных принципов, тем самым существенно понижая эффективность Scrum-митингов. Однако ответственность за эффективные stand-up митинги (как и за всё в Scrum) несёт вся команда, поэтому все её участники должны приложить максимум усилий для соблюдения хотябы большей части перечисленных идей.

Сегодняшний пост пожалуй будет последним из короткого цикла о гибких (agile) методологиях. Сегодня у нас в гостях снова Martin Fowler (Мартин Фаулер), несдвигаемая глыба в области современного проектирования и архитектуры программных продуктов, со своей статьёй 'The New Methodology' ("Новые методологии программирования").

Статья является великолепным обзором истории и нынешного состояния мирового Agile течения (или точнее сказать потока).

Первая часть статьи приводит предпосылки возникновения Agile:

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

При строительстве моста на работы по проектированию уходит около 10% от всей стоимости работ. Остальное - затраты на конструирование. В программных разработках время, которое тратится на кодирование намного меньше. Отсюда вопрос о сущности проектирования при разработке программных продуктов и его отличиях от проектирования в других областях инженерной деятельности.

Каждый раз, когда я сталкиваюсь с проектом, в котором наблюдаются проблемы, я слышу одно и то же. Разработчики приходят и говорят: "Все проблемы из-за того, что заказчик постоянно меняет требования". В этой ситуации меня удивляет только одно - почему все этому удивляются. При разработке программных бизнес-приложений требования должны изменяться, это нормально. Вопрос только в том, что можно сделать по этому поводу.

Оценить длительность процесса разработки ПО тяжело по нескольким причинам. Во-первых, создание программных продуктов представляет собой работу по проектированию, которую трудно планировать и оценивать. Во-вторых, быстро меняются исходные материалы. В-третьих, очень многое зависит от конкретных людей, которые выполняют работу, а людей всегда сложно прогнозировать и подходить к ним с какими бы то ни было мерками. Это приводит к довольно ироническому умозаключению: все заказчики полагают, что требования можно менять. В конце концов, в слове "software" присутствует слово soft. Итак, требования не просто могут меняться - они должны меняться. Нужно положить много сил и энергии, чтобы заставить заказчика четко зафиксировать свои требования. Сделать это еще сложнее, если заказчики когда-то сами баловались разработкой ПО - тогда они знают, что изменить программу несложно. Впрочем, даже если вам удалось получить четкий список требований, все равно вы обречены. В современной экономике ценность тех или иных свойств программных продуктов меняется слишком быстро. То, что является достаточным набором требований сегодня, оказывается устаревшим уже через полгода. Даже если заказчики могут предоставить стабильный список требований, мир бизнеса от этого не замрет. А ведь многие изменения в мире бизнеса совершенно непредсказуемы (тот кто скажет, что я не прав, либо лжет, либо уже заработал миллион, играя на бирже).

Далее Фаулер переходит к некоторым деталям и сложностям построения или перехда на гибкий процесс:  

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

Контракт с фиксированной стоимостью предполагает неизменность требований, а значит, использование предсказуемого процесса. Если использовать адаптивный процесс при нестабильных требованиях, обычная установка на фиксированную оплату уже не срабатывает. Попытка втиснуть адаптивный процесс в рамки фиксированной оплаты приводит к весьма неприятным конфликтам. При этом самое неприятное то, что заказчик пострадает ничуть не меньше компании-разработчика. В конце концов, заказчику не понадобился бы программный продукт, если бы того не требовал бизнес. Если он не получит этот программный продукт, бизнес пострадает. Итак, даже если заказчик не заплатит компании разработчику ничего, он все равно несет убытки. Более того, он теряет даже больше, чем если бы заплатил за готовую систему (зачем бы заказчику платить за нее деньги большие, нежели ее коммерческая стоимость?)

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

Другая ключевая идея заключается в том, что разработчики должны иметь возможность принимать все технические решения. Наибольшего выражения это достигает в ХР, где только разработчики могут устанавливать, сколько времени должно уйти на ту или иную работу. Многие руководители воспринимают такое управление техническим процессом как нечто совершенно невероятное. Адаптивный процесс требует равного разделения ответственности за осуществление проекта между разработчиками и руководством. Обратите внимание, я сказал "равного". Руководство продолжает играть свою роль, однако при этом отдает должное мнению разработчиков.

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

Далее в статье приводится замечательный пересказ истории возникновения различных направлений Agile (XP, Scrum, Crystal, Lean, RUP) и их объединения в единый термин Agile.

Статья непременно должна быть прочитана теми, кто работал, работает или собирается работать согласно Agile.

Как и большинство статей по agile, статья строится на том факте, что методологии разработки программного обеспечения могут и должны быть не менее изменчивыми, чем бизнес требования, технологии и сами люди:

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

Автор приводит основы разработанной им адаптивной методологии ASD (Adaptive Software Development), которая позволяет изменять многие параметры процесса прямо по ходу проекта, адаптируясь к новым условиям и обучаясь на ошибках и недостатках:

В ASD обычный статический жизненный цикл Plan-Design-Build (Планирование - Проектирование - Конструирование) заменен на динамичный - Speculate-Collaborate-Learn (Обдумывание - Взаимодействие - Обучение). Этот цикл ставит своей целью непрерывное обучение. Он связан с постоянными изменениями, повторными оценками, попытками предугадать неизвестное на текущий момент будущее проекта и требует тесного взаимодействия между разработчиками, тестировщиками и заказчиками. (Обратите внимание, что весь этот цикл не всегда представляет собой правильный круг. Даже при итеративном процессе можно иногда отклоняться в сторону, чтобы изучить неисследованные до сих пор области). Методология ASD построена на концептуальной базе теории сложных адаптивных систем. Она рассчитана на использование в экстремальных проектах, в которых превалируют быстрый темп разработок, непредсказуемость и частые изменения. Есть проекты, которые не могут считаться экстремальными, однако для всех остальных ASD подходит гораздо лучше, чем любой традиционный подход к разработке ПО.

Такой подход меняет традиционную последовательность действий и приоритеты при выполнении проекта, ставя во главу угла обучение:

Так, например, постмортемы (переводчик использовал это слово, я бы подобрал более литературный вариант вроде "разбор полётов") проекта очень просты по сути. Они служат исключительно для того, чтобы определить, что прошло хорошо, где были сбои, и, наконец, какие изменения необходимо произвести. Как ни странно, многие организации не делают постмортемы, поскольку подобный обзор проделанной работы непременно превращается у них в политические игры и взаимные обвинения. Очень часто, вместо того, чтобы спросить себя "чему нам надо научиться?" мы начинаем искать ответ на вопрос "кто в этом всем виноват?". Запомните, чтобы ваша организация стала адаптивной и гибкой, ей нужно в первую очередь стать организацией, где умеют и любят обучаться.

Это и радикально преобразуют весь стиль управления: 

Команды разработчиков должны взаимодействовать при решении технических проблем и при определении требований к системе. Им необходимо улучшать свою способность принимать совместные решения. Руководству, кстати, пора передать командам больше прав для принятия решений, так как постоянные изменения (и жесткий график работ) совершенно исключают традиционный стиль управления - Command - Control (Приказ - Контроль).

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

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

Изложенный подход очень органично перекликается с подходами Мартина Фаулера к необходимости постоянного рефакторинга:

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

Примечательно аргументируется необходимость жёстких временных рамок для успешного протекания процесса:

... говоря о жестких временных рамках, мы должны иметь в виду не столько время и сроки, сколько принятие сложных компромиссных решений. Когда тебя окружают постоянные изменения, нужно периодически задействовать некий фактор, который будет заставлять доводить начатое до конца. Кроме того, существование временных рамок заставляет команду разработчиков и клиентов постоянно пересматривать основные показатели проекта: его границы, расписание работ и поставок очередных версий, ресурсы, дефекты и т.д. Те команды, которые не могут (или не хотят) принимать быстрые решения и делать выбор, никогда не добьются успеха в экстремальных условиях.

На закуску пару весьма красивых фраз из статьи, призванных убедить всех в необходимости перехода к новым методикам работы: 

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

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

Сколько себя помню - всегда руководствовался принципом Алистэра Коуберна (Alistair Cockburn) "Каждому проекту своя методология" ( 'Methodology per project'). Неудивительно, что "продолжение" этого принципа в виде статьи "Каждой методологии - свое время" ('Just-in-time methodology construction') вызвало у меня немалый интерес. Русский перевод названия на мой взгляд немного неточен, я бы перевёл как "Построение методологии по ходу проекта", однако существующий перевод весма оправдан своей созвучностью со статьёй-предшественницей.

Данная статья базируется на ещё одной известнейшей статье Алистера - "Люди как наиболее важные компоненты процесса разработки ПО" ('Characterizing people as non-linear, first-order components in software development'), о которой я уже писал

Идея статьи проста, очень логична, и в то же время революционна:

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

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

Ответ на этот вопрос, конечно же, существует не один. Коуберн выделяет следующие ключевые моменты:

 - Разработка ведется инкрементным методом. Насколько я могу судить, это единственное необходимое методологическое условие.
 - После каждого инкремента проводите общее собрание, на котором задавайте один-единственный вопрос: "Что мы могли бы делать лучше?"
 - Берите за основу сильные стороны человеческой натуры

Результатом работы Коуберна стала разработка целого семейства методологий Crystal. Метологии внутри этого семейства различаются по 3-м критериям: люди, критичность, приоритетность.

Все методологии Crystal различаются по цвету, причем каждый цвет предназначен для определенных проектов и имеет свои собственные характеристики: Clear ("Прозрачная") для самых легких и небольших проектов, затем Yellow ("Желтая"), Orange ("Оранжевая"), Red ("Красная") и т.д., для больших команд, использующих более тяжелые методологии. Методология каждого цвета обладает своими собственными правилами и базовыми элементами. При этом каждая легка настолько, насколько это хорошо и правильно для данного типа проектов.

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

Martin Fowler (Мартин Фаулер) бесспорно является одним из самых уважаемых авторов в области современного проектирования и архитектуры программных продуктов. Его бестселлеры 'Refactoring: Improving the Design of Existing Code' и 'Patterns of Enterprise Application Architecture' - это, пожалуй, наиболее ценные книги, прочитанные мною за всю мою профессиональную жизнь.

Недавно мне в руки попала замечательная статья Мартина с броским названием 'Is Design Dead?' (в русском переводе "Проектирования больше нет?"), о которой сегодня и пойдёт речь.

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

Методология XP бросила вызов многим устоявшимся представлениям о разработке программного обеспечения. Пожалуй, наиболее противоречивой идеей является отказ от предварительного проектирования в пользу более эволюционного подхода. Для приверженцев новой методологии, это отказ от техник проектирования (например, UML), их принципов и паттернов. Незачем беспокоиться о проектировании, считают они. Достаточно внимательно "вслушиваться" в свой код, и проектирование образуется само собой.

Фаулер, как выдающийся специалист в области проектирования, конечно же не соглашается с таким утверждением:

В большинстве случаев, эволюционное проектирование - это нечто ужасное. В конце концов, все равно вместо дизайна системы вы получаете просто набор из специфических решений, каждое из которых затрудняет дальнейшие изменения в программном коде. Часто это вообще нельзя считать дизайном (и, уж конечно, такой дизайн никак нельзя назвать хорошим). Как говорит Кент, дизайн существует для того, чтобы дать возможность оперативно вносить в систему любые изменения. Если дизайн плох, то такая возможность исчезает. В результате вы будете иметь дело с энтропией программного продукта, и со временем и без того плохой дизайн системы станет еще хуже. Теперь вам будет не только сложнее вносить в систему изменения, но и отыскивать и исправлять ошибки, которые начинают множиться с катастрофической быстротой. Все это - кошмар разработок в стиле "code and fix", когда с течением времени исправление ошибок обходится все дороже и дороже.

Однако одновременно являясь ярым приверженцем Agile и автором "библии" рефакторинга, Фаулер признаёт и рекламирует их эффективность:

В методологии XP имеется много спорных моментов. Одним из ключевых таких моментов является то, что она базируется на эволюционном, а не предварительном проектировании. В основе этого утверждения лежит кривая стоимости изменений в программном продукте. XP строится на предположении, что эту кривую можно сгладить до такой степени, чтобы можно было применять эволюционное проектирование. Такое сглаживание, с одной стороны, возникает при использовании методологии XP, а с другой, оно же в ней и используется. Это еще раз подчеркивает тесную взаимосвязь между практиками ХР: нельзя использовать те части методологии, которые предполагают существование сглаживания, не используя те практики, которые это сглаживание осуществляют. У практик, с помощью которых осуществляется сглаживание, есть множество составляющих. В основе всех их лежит Тестирование и Непрерывная интеграция. Именно надежность кода, которую обеспечивает тестирование, делает возможным все остальное в этой методологии. Подобный эффект имеет и рефакторинг.

В статье Фаулер пытается найти компромис, балланс между традиционными (и бесспорно необходимыми) методиками проектирования с одной стороны и Agile с другой:

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

Собственно, вся статья и посвящена нахожденю этого компромисса. Показывается полезность и органичность предварительного проектирования в XP, преимущества и критерии простого дизайна перед сложным при условии следования всем остальным практикам XP, показывается эффективное сосуществование принципа YAGNI ("You Aren't Going to Need It" - "Это вам не понадобится") и рефакторинга, применимость и ценность паттернов проектирования и даже UML в XP.

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

В этом посте я хотел бы обсудить широко известный принцип Питера (Peter Principle), который гласит: В иерархической системе любой работник поднимается до уровня своей некомпетентности.

Нужно признать, что несмотря на кажущуюся шуточность и ироничность, этот принцип имеет достаточно строгие обоснования:

 - (1) Компетентные повышаются. Как правило, при появлении вакансии руководство выбирает кандидата из числа тех нижестоящих сотрудников, к которым нет претензий на их нынешней должности.

 - (2) Некомпетентные не понижаются. На первый взгляд, может показаться, что никакой проблемы нет; достаточно просто возвращать сотрудников, не справляющихся с должностью, на предыдущее место. На практике же это обычно невозможно. Во-первых, это противоречит интересам руководителей, предложивших повышение сотрудника либо согласившихся с ним, — признав некомпетентность выдвиженца, они тем самым вынуждены будут признать свою ошибку. Во-вторых, предыдущая должность на момент обнаружения некомпетентности обычно уже бывает занята, так что возврат в исходное положение одного сотрудника приведёт к необходимости понижения или увольнения других, что обычно слишком сложно и тоже невыгодно. В результате, хотя некомпетентность сотрудника на новой должности может быть очевидна, его не понижают.

 - (3) Отказ от повышения маловероятен.

Кроме того, на принцип Питера ссылается немало серьёзных авторов и этот принцип повсеместно подтверждается на практике.

Однако мне, к счастью, приходилось работать в компаниях (или командах), где этот принцип не соблюдается, поэтому на мой взгляд, принцип Питера сродни закону Мёрфи (Murphy's law) и закону Паркинсона (Parkinson's Law): и тот и другой упоминается тогда, когда необходимо убедительно аргументировать ошибки или провалы, просто сославшись на некий общеизвестный "всемирный закон неудачи".

Я бы переформулировал принцип Питера в более оптиместичный признак Питера: Если в некоторой иерархической системе выполняется принцип Питера, то данная иерархическая система (или какие-то её подсистемы) находится в неоптимальном состоянии и требует реформирования. Или так: Достаточным признаком неоптимальности иерархической системы является выполнение в ней принципа Питера.

Под оптимальностью здесь понимается что целью системы является эффективная работа (что верно далеко не для всех систем в этом суровом мире :-) )

Общеизвестно из литературы, что переключение между задачами не только отнимает время, необходимое для того, чтобы вспомнить тебования, степень готовности задачи и детали реализации, но и пагубно сказывается на так называемом "потоке мышления", который прерывается при любом переключении внимания (в том числе и при переходе на другую задачу) и затем требует от 15 до 30 минут на восстановление. Исследования показывают, что, отвлекая разработчика каждые 15 минут, его продуктивность можно свести к нулю.

Однако суровая правда жизни заключается в том, что очень часто бизнес диктует разработчику острую необходимость именно параллельного выполнения нескольких задач или как минимум регулярного переключения между задачами. В моей профессиональной практике бывали периоды, когда от меня требовалось работа над более чем 5 проектами одновременно, т.е. прогресс по каждому из проектов дожен был быть виден не реже, чем раз в два дня. Согласно общепринятому мнению, моя продуктивность в такие периоды должна была быть мизерной. Однако она была далека от мизерной. Более того, сравнивая мою суммарную продуктивность в эти периоды и в периоды "затишья" (работа над одной областью задач в течение недели или более), я каждый раз с удивлением обнаруживал, что суммарная продуктивность в периоды параллельной работы оказывалась даже несколько выше! Долгое время я приписывал этот эффект к своей "уникальности", т.к. для других разработчиков переключение между задачами действительно оказывалось губительным.

Однако со временем я начал встречать других девелоперов, которые предпочитали работать над несколькими разнородными задачами или проектами, переключаясь между ними, нежели работать долгое время над одной задачей/проектом. Как правило, объяснение сводилось к тому, что долгая работа над одной задачей быстро становится скучным, утомительным занятием, и продуктивность резко падает, в то время как возможность переключения на другую задачу позволяет прогнать скуку и быстро отдохнуть от первой задачи. Крайнее проявление этого эффекта общеизвестно: засадите своих разработчиков за выполнение одноообразных (пусть даже и кажущихся поначалу интересных) задач одного и того же долгоиграющего проекта - и на втором году такой работы от вас сбежит 90% команды.

Таким образом я утвердился во мнении, что регулярное переключение между выполняемыми задачами не только не вредно для продуктивности разработчика (при соблюдении определённых правил), но зачастую даже полезно. Видимо, для усталости мозга применим принцип суперсетов, общеизвестный среди спортсменов-тяжелоатлетов по отношению к мышечной усталости. Принцип этот заключается в том, что переключение нагрузки на другую группу мышц позволяет быстрее восстановиться, чем при обычном отдыхе, т.к. такое переключение уводит "центр усталости" в другое место, что значительно быстрее, чем просто ждать затухания этого центра со временем.

Осталось только сформулировать те правила, которые позволят избежать падения продуктивности при таком переключении:

1. Не прерывайте поток мышления. Идея этого правила в том, что у мозга разработчика есть периоды "просветления", когда решение задачи складывается в единое целое. Прервите разработчика во время этого периода срочным вопросом или задачей - и скорее всего вы отбросите его работу на пару часов назад. Дайте ему возможность самому решать когда прерваться, это наступит достаточно скоро, т.к. после периода просветления всегда наступает период отдыха. Говоря проще, не звоните разработчику когда он занят задачей и не прерывайте его личным разговором, напишите ему письмо с пометкой "срочно" или оставьте сообщение иного рода. Во время периода отдыха он сам полезет проверять почту.

2. Дайте мозгу выбор. Не навязывайте жёстко порядок или время выполнения задач. Если вам нужно, чтобы нескольно задач было сделано - дайте разработчику самому выбрать к какой из них у него "лежит душа" именно сегодня и именно сейчас. Если речь идёт о прогрессе в нескольких проектах одновременно - не требуйте прогресса в каждом из них каждый день, задайте интервал в 2-3 дня, чтобы разработчик мог сам решить: разделить ли какой-то день между проектами/задачами или посвятить целиком одному проекту/задаче. Помните, что очень многое в вопросе эффективности зависит не только от сложности и специфики задачи, но и от настроения (физического и духовного состояния разработчика).

3. Минимизируйте давление и бюрократию. Не терроризируйте разработчика частыми вопросами о том, как идут дела, скорее всего это его будет только раздражать и отвлекать. Действуйте как в правиле 1 - дайте ему самому решить когда наступил удачный момент сообщить о своём прогрессе. По максимуму избавьте такого загруженного разработчика от бюрократии вроде детальных отчётов или двухчасовых командных митингов. В вялотекущих проектах это всё необходимо, чтобы держать руку на пульсе прогресса и направлять поток разработки в нужное русло, но для разработчика в режиме многозадачности это менее актуально: его задачи как правило более ясны и обозримы, его сложность другого рода - работать над этими задачами параллельно.

4. Повышайте нагрузку постепенно. Не бросайте разработчика, работавшего 3 месяца над одним проектом, сразу ещё на 3 других. Дайте один, через две недели ещё один. Дайте ему время настроиться и подрегулировать свой ритм.

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

Alistair Cockburn - это один из моих любимейших авторов в области управления процессом разработки программного обеспечения, а его статья "Characterizing people as non-linear, first-order components in software development" - несомненная жемчужина в сокровищнице мирового достояния по этому вопросу (русский перевод статьи доступен здесь).

Автор, эксперт в области методологий разработки ПО, более 20 лет посвятивший изучению этого вопроса, пришёл к выводу, что на пути любой методологии стоит 2 основных проблемы:

1. Людям, занятым в проекте, как правило совершенно неинтересно изучать новую методику.
2. Они вполне могут обойтись и без методологов, и при этом успешно создавать программное обеспечение.

Проанализировав около сорока проектов из своей практики, автор сделал следующие важные выводы:

1. Практически любую методологию можно с успехом применять в каком-нибудь проекте.
2. Любая методология может привести к провалу проекта.
3. Тяжеловесные методологии тоже могут успешно применяться в работе.
4. Облегченные методологии чаще приводят к успеху, и, что более важно, разработчики сами говорят, что успех проекта был обеспечен именно методологией.

Я не нашел ни одной теории, которая объяснила бы, почему облегченные методологии (те, в которых мало места уделяется всяческим формальностям), чаще приводят к успешному завершению проекта, нежели тяжелые методологии, где формальности играют очень большую роль. И тут я наконец-то понял, что прямо перед нами всегда находится нечто, чего мы не замечаем: люди. Именно человеческие качества обеспечивают успех тому или иному проекту, именно они являются фактором первостепенной важности, основываясь на котором надо строить прогнозы о проекте. Теперь я рассматриваю все в обратном порядке - сначала люди, а потом методология, как второстепенный показатель.

Какие же человеческие качества делают людей одновременно и столь важной, и столь непредсказуемой компонентой процесса разработки? Автор выделяет следующие:

1. Человек - существо, которому необходимо общение. Причем общаться он предпочитает в режиме непосредственного диалога, лично, по типу "вопрос-ответ".
2. Человеку трудно постоянно работать сверхурочно.
3. Человек - существо изменчивое, он меняется в зависимости и от времени, и от пространства.
4. Как правило, у человека есть чувство гражданского долга, он может хорошо ориентироваться в ситуации, брать инициативу в свои руки и делать "все, что необходимо" для того, чтобы проект завершился успешно.
5. Человеку нужно время, как на размышление, так и на общение.
6. Человек хорошо работает, опираясь на примеры.
7. Человек предпочитает скорее потерпеть неудачу из-за своего консерватизма, нежели рискнуть, но сделать что-то необычным образом; ему больше нравиться изобретать, а не находить готовые решения, он может одновременно держать в голове совсем немного сведений, он делает ошибки и с трудом меняет привычки.
8. Отдельная личность может легко возобладать над проектом.
9. Способность человека выполнять те или иные задания в большей степени определяется его личными качествами.

Когда я провожу опрос по какому-нибудь проекту, я всегда спрашиваю людей, что, по их мнению, привело к конечному успеху работы. Чаще всего я получаю один и тот же ответ: "В ключевой момент разработки несколько человек взяли на себя инициативу и сделали все от них зависящее, чтобы выполнить проект".

Приведу ещё парочку важных на мой взгляд заключений, изложенных автором в статье: 

 - Я прихожу к заключению, что большинство проектов вполне можно вести, руководствуясь (верными) не очень точными описаниями: не очень точную документацию по проекту легче читать, приводить в порядок и обсуждать. Архитектуру системы, изображенную с невысокой степенью точности, легче запомнить; в таблицах с не очень точно описанными требованиями легче расставлять приоритеты и легче оценивать масштабы сделанной работы на ранних стадиях проекта. Выполненная не очень точно проектная документация лучше передает "идею" проекта, после чего читатель может начать "ориентироваться в ситуации".

 - Вариации поведения культур методологу учитывать еще труднее, чем вариации каждодневного поведения отдельных индивидуумов. На сегодняшний день я не знаю ни одной методологии, при создании которой принимались бы во внимание культурные особенности (моя методология - не исключение). Впрочем, я знаю людей, которые учитывают местные культурные особенности при формулировании методологических рекомендаций.

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

На написание этой заметки меня вдохновило известное философское эссе Harry Frankfurt'а 'On Bullshit'. На самом деле это эссе не имеет никакого отношения к разработке ПО, однако, как и любая философская теория, оно имеет оношение ко всему.

На русский язык я бы лично перевёл название как "О лапше" в том смысле, что современное общество просто-таки захлёбывается в лапше, которую люди постоянно вешают на уши друг другу. Зачастую это преподносится и интерпретируется не как явная вопиющая ложь, а скорее как хитрость, некоторое привирание, без которого якобы никак не выжить и не пробиться. Давайте пронаблюдаем это на примере процесса разработки ПО.

 Начнём с первого контакта заказчика и испольнителя. Ставлю десять к одному, что каждый из них сознательно себя презентует лучше чем он есть. Т.е. заказчик наверняка привирает о своей солидности и стабильности. Но это ещё цветочки по сравнению с тем, какие, мягко говоря, преувеличения можно иногда услышать от компаний-исполнителей. Яркие примеры из моей практики:
- У нас команда из 20 разработчиков (реально 4)
- Мы профессионально владеем следующими технологиями ... (реально специалистов по половине из них нет на данный момент совсем, их наймут только если проект стартует, а в другой половине большинство персонала - новички)
- У нас работают специалисты со стажем от 7 до 15 лет (реально от 0 до 6)

Предположим, первая лапша успешно развешена и процесс переходит на стадию обсуждения условий сотрудничества. Здесь очковтирательство идёт по нарастающей:
- Мы сделаем этот проект за N недель (реально все знают, что не быстрее, чем 2xN + M)
- ответная лапша заказчика: мне этот проект нужен в мае, крайний срок в июне  (реально в сентябре, но может и годик подождать)
- ещё один сногсшибательный трюк, который глава одной софтверной компании , где мне приходилось работать, неоднократно проворачивал с потенциальными заказчиками: "а у нас такая функциональность уже есть готовая!" (а реально, если заказчик "повёлся", то на написание этой "готовой" функциональности абсолютно с нуля и в нереальные сроки будет срочно выделена штурмовая команда, которая в лучшем случае даст эту функциональность через месяц)

Однако все эти хитрости просто детские игры по сравнению с тем, какую лапшу вешают на уши друг другу компания и нанимаемый сотрудник, руководитель и подчинённый:
- вы возглавите команду / будете руководить / займёте позицию ведущего ... и т.п. (не поверите, я знаю команду, в которой из 5 разработчиков 4-х брали на позицию тим-лидера )
- зарплата у нас не такая большая, но в конце проекта будет солидный бонус (либо не будет совсем, либо будет, но совсем не солидный)
- сначала будет пару месяцев сопровождение старого проекта, потом начнём новый (скорее через пару лет)
- мы собираемся переехать на новый оффис, ввести страховки сотрудникам, обновить технику и т.п. (конечно собираетесь... собираться - это не дорого)
и т.п. (про поведение работников я совсем умолчал, иначе пост мог бы превратиться в целую книгу)

Естественно, вся эта лапша имеет под собой реальные и вполне понятные основания: когда очень хочется что-то сделать, а это не получается, "приходится" идти на уловки, чтобы добиться желаемого.

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

И более того, некоторые даже осуждают честность и открытость как признак слабости или неопытности.

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

Это последний пост из серии постов по книге Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”. И вопрос в нём поднимается, пожалуй, самый сложный.

Итак, вы успешно наняли подходящих людей и сфоримировали настоящую команду. К сожалению, на этом всё только начинается. Как сохранить эти непростые достижения подольше? Как удержать программистов от ухода?

Я уже написал об этом несколько постов, раскрыв некоторые моменты: мотивация, антипаттерны руководства и сбаллансированные отношения руководитель-подчинённый.

Однако ввиду важности, сложности и неоднозначности вопроса, хочется процитировать ещё несколько интересных моментов, касающихся аттестации и зарплаты:

• Не думайте, что, наняв сотрудника, вы заключили с ним договор раз и не всегда. Вы должны нанимать сотрудника постоянно. Успешно работая в своей области, сотрудник приобретает новые знания и опыт, следовательно, стоимость его услуг растет. Поэтому его необходимо перекупать, пока это не сделали конкуренты, если, конечно, вы не стремитесь стать для них «кузницей кадров».

• Пересмотр договора о найме, «по договоренности», без прозрачной процедуры дезориентирует и демотивирует сотрудников. В силу своей интроверсии, программист, как правило, предпочтет найти повышение зарплаты в другой компании вместо того, чтобы просить об этом свое начальство. Поэтому, настоятельно рекомендую, проводите периодический пересмотр условий договора - аттестацию.

• Кто оценивает? В первую очередь, руководство: линейный руководитель и менеджеры проектов, в которых участвовал данный сотрудник. Однако, не менее важны экспертные оценки, которые ставят люди, взаимодействующие с этим сотрудником на разных уровнях, коллеги, смежники, подчиненные, клиенты. В западной литературе этот подход называется оценка по методу «360 градусов»

• Еще один важный и необходимый результат аттестации – план развития, - какую новую ступень карьерной лестницы будет достигать сотрудник и что ему необходимо сделать, чтобы на нее перейти. Что изучить и освоить: новые технологии (согласуем с личными целями и стратегическими потребностями компании), смежные специальности (снижаем риск в случае увольнения коллеги). Каких результатов добиться. Поставленные цели должны соответствовать широко известному в западном менеджменте критерию SMART, представляющему собой аббревиатуру из пяти английских слов: Specific (конкретный), Measurable (измеримый), Achievable (достижимый), Relevant (сопоставимый) и Timebound (определенный во времени).

• При решении вопроса "Сколько надо платить программисту?" необходимо помнить, что участник команды это не «винтик», как думают некоторые CEO, который можно легко заменить, купив на рынке аналогичный. Я не утверждаю, что программисты незаменимы. Заменимы и еще как. На сегодняшний день средняя текучесть кадров в ИТ составляет по моим оценкам 20-30% в год, однако, отрасль не только не рухнула, но и успешно развивается.

• Как правило рыночная «вилка» вознаграждения для данной квалификации известна, допустим от X до 1.5*X. Можно рискнуть и платить по нижней планке X. Однако, возможность получать в 1.5 раза больше за ту же работу, скорее всего перевесит все остальные стимулы, для удержания специалиста в данной компании. Эта ситуация усугубляется еще и тем, что «охотники за головами» делают разрыв в вилке еще больше, чтобы побыстрее перекупить квалифицированные кадры.

Далее в книге идёт очень скурпулёзный рассчёт стоимости замены уволившегося сотрудника. Итоги этого рассчёта впечатляют: даже не учитывая затрат на оплату услуг рекрутеров (которые до недавнего времени стоили весьма немалых денег) для компании с доходностью 25% "мгновенная" замена специалиста с зарплатой $2000 может стоить до $27,000. В статье берётся "время адаптации" равным 6 месяцев, но даже если принять более реалистичные для нашего аутсорса 2-3 месяцев и компанию с меньшими накладными расходами, то всё равно затраты на замену специалиста составят не менее полугодовой зарплаты этому сотруднику, что совсем не легко понять "интуитивно". Какой отсюда следует вывод - каждый может решить для себя сам, однако даже просто обладание такой информацией, на мой взгляд, может повлиять на отношение к этому вопросу.

Это ещё один пост из серии наиболее интересных для меня глав книги Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”.

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

• Необходимо помнить, что мотивация разработчиков ПО начинается с приема на работу. В старой экономике людей нанимали за умения и обучали нужному отношению к делу. В новой экономике необходимо поступать с точностью до наоборот: нанимать за нужное отношение к делу и учить необходимым умениям.

• В настоящее время нет каких-либо достоверных формальных методик определения квалификации программиста. Мой опыт показывает достаточно значимую корреляцию хороших способностей к программированию и сверхвысокого значения IQ . Высокий балл диплома и престижное математическое или техническое образование свидетельствует об общих способностях кандидата успешно осваивать новый материал. Диплом о престижном высшем образовании немаловажен для хорошего программиста, хотя и не является необходимым условием.

• Отдельно остановлюсь на тестах и практических заданиях по специальности. Относительно их необходимости у меня имеются большие сомнения. Как правило, технические тесты ориентированы на проверку узкоспециальных знаний: структур данных, алгоритмов, конкретных стандартов и API, и т.д. Правильный/неправильный ответ на вопрос: «i=1; i = i++ + ++i; чему равно i?», - мало о чем свидетельствует. Попытки давать кандидатам олимпиадные задачки по программированию, или задачки из книжки «Математические головоломки», у меня, как правило, ассоциируются со стремлением, возможно, не очень успешных вчерашних студентов к самоутверждению или с желанием продемонстрировать кандидату его несостоятельность, чтобы затем снизить предложение по зарплате. Я применял тесты по специальности - несколько десятков простых вопросов на 15-20 минут по базовым понятиям стека технологий таких, которые просто невозможно не знать, если ты имеешь практический опыт в данной области. Результаты этого теста использовались только для того, чтобы выяснить, в какой области кандидат более уверенно ориентируется и адекватнее позиционировать его среди имеющихся направлений разработки.

• Технические тесты могут продемонстрировать уровень IQ и эффективность левого полушария, возможности которого подтверждены, как правило, дипломом о высшем образовании и всем успешным опытом предыдущей работы. Часто при обсуждении данного тезиса меня спрашивали: «А вдруг кандидат наврал о прошлом опыте?» На мой взгляд, одного двух вопросов с просьбой уточнить некоторые конкретные технические детали достаточно, чтобы рассеять или подтвердить подобные сомнения. И еще, если вы не в состоянии распознать то, что человек выдает себя не за того, кто он есть на самом деле, возможно, вам еще рано руководить людьми.

• Креативность и эффективность человека в командной разработке зависят в первую очередь от уровня его эмоционального интеллекта, EQ и деятельности правого полушария: целеустремленность, воля, эмпатия, интуиция, способность к эвристическим суждениям. Я, к сожалению, пока не встретил достоверных тестов правого полушария. Поэтому слушаем, слушаем и еще раз слушаем. А главное слышим! При отборе кандидатов только очное интервью «глаза в глаза» и личный опыт работы с людьми позволят вам создать эффективную программистскую команду.

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

• Проводить интервью, желательно вдвоем с человеком, который будет непосредственно руководить или работать с кандидатом. Это позволит быть более объективным, посмотреть на кандидата с «разных сторон» и лучше его понять. Ваша задача при проведении интервью - получить ответ на 3 вопроса:
1. Знает дело?
2. Умеет его делать?
3. Хочет его делать?
От себя: это как раз то, что я называю опыт, талант и старание.

• Смена работы это всегда «стресс», который, по мнению психологов, занимает по значению 3-е место после развода семьи и пожара. Помогите кандидату прийти в себя. В противном случае вы будете беседовать с другим человеком.

• Принимать решение следует сразу. Возможно, понадобится 5 мин. посоветоваться с коллегой. Не стоит откладывать решение. «Я могу предложить Вам…» Далее должны следовать описание позиции, должностных обязанностей и размера компенсации. Возможно, эта будет другая позиция, а не та, на которую, кандидат изначально позиционировал себя, если, на ваш взгляд в этой роли он будет более эффективен. Обсудите с кандидатом ваше видение его места в проекте.

•  Если вы не смогли в ходе интервью снять все сомнения, не берите. Доверяйте своей интуиции. Лучше ошибиться и не взять достойного кандидата, чем рискнуть и получить «проблему». Будьте честны. Имейте волю отказывать: «Я могу предложить Вам…» Далее перечень конкретных отсутствующих знаний и навыков, приобретение которых позволит кандидату, занять данную позицию в будущем. Кандидаты возвращаются! Не стоит отказывать в стиле «Если будет принято положительное решение, мы Вам обязательно позвоним». Это, скорее всего, ложь. Не стоит подрывать доверие к своей компании.

Сегодня я продолжу знакомить вас с идеями полюбившейся мне книги Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”.

Довольно интересным и поучительным мне показался раздел о различной мотивации программистов в зависимости от их опыта. Само это утрверждение отнюдь не ново и, я думаю, очевидно для большинства менеджеров. Однако впервые я встретил цифровые значения (пусть и отражающие грубые оценки), благодаря которым можно учитывать долю различных стимулов в мотивации сотрудника:

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

Приведу также и авторские комментарии к этой таблице: 

• Для начинающих программистов хорошим стимулом является само участие в успешном проекте (может быть в первом в их жизни), возможность учиться ремеслу у более опытных и искушенных коллег.

• Для опытных программистов хорошим стимулом может служить новизна и востребованность на рынке труда технологий, используемых в проекте (потребность безопасности). Для них также существенны сложность и самостоятельность (потребность самоуважения) в решении поставленных задач. Как правило, я стремлюсь ставить задачи примерно в 1,5 раза сложнее, чем те которые данный программист решал ранее. Для опытного программиста каждая новая задача должна предоставлять дополнительную возможность доказать свой профессионализм.

• Сложнее дело обстоит с суперпрограммистами. Их главным мотивом, как правило, служит самоактуализация, поэтому они стремятся решать задачи, которые до них еще никто не делал. Оптимальное их место в проекте - системная архитектура и реализация архитектурно значимых компонентов - скелета системы. При правильной мотивации оставшаяся часть их потребностей принадлежности и самоуважения реализуется через обучение коллег и передачу им своего опыта. На эту деятельность следует планировать до 50% времени суперпрограммиста. Суперпрограммист в проекте должен играть роль технического лидера, который ведет за собой остальных участников под лозунгом: «Делай как я!». Он всегда должен быть готов продемонстрировать, как можно решить эффективно любую задачу в проекте. Вывод, который отсюда следует это то, что на серьезный проект, надо набирать программистов разной квалификации. И начинающих, и звезд. Если вы берете в проект суперпрограммиста, то должны быть уверенным, что вы сможете эффективно использовать его опыт и найдете достойную задачу, которая его заинтересует.

Это ещё один пост из серии наиболее интересных для меня глав книги Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”.

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

Также весьма полезно знать стадии, которые проходит на этапе своего формирования Команда:

• Forming (Объединение)
• Storming (Разногласия и конфликты)
• Norming (Становление)
• Performing (Отдача)
• Reforming (Расформирование)

И ещё много всего полезного и поучительного о Командах есть в этой книге, обязательно прочтите её.