Один из основных принципов agile требует итеративной разработки и частых поставок. Все agile методы применяют эту идею, различаясь в предписаниях длительности итераций. Для обозначения этих итераций широко используется термин, введенный Scrum, – спринт (sprint).
Цель спринта – существенно продвинуться в разработке проекта, выполняя задачи из списка, известного как бэклог спринта. В большинстве agile подходов каждая задача из списка представляет реализацию пользовательской истории.
Cпринт в Scrum обычно длится месяц. Многие команды используют другие сроки, не Scrum авторы рекомендуют итерации различной длительности, хотя нигде этот срок не превышает нескольких недель в соответствии с фундаментальной agile идеей итеративной разработки с короткими циклами.
Эта идея нарезать разработку на короткие интервалы, длящиеся месяц или около этого, определяет понятие спринта. Не менее важна еще одна идея, заложенная в Scrum, – правило, требующее, чтобы во время спринта список задач не мог возрастать. Правило носит абсолютный характер; никто (ни работник, ни барон, ни император – менеджер проекта) не может ничего добавить, пока не закончится спринт.
Это правило реалистично благодаря коротким итерациям. Ясно, что, если бы спринт длился шесть месяцев, то невозможно было бы подавить естественное желание заказчиков и менеджеров добавить функциональность. Если возникает реальная потребность, то нетрудно дождаться конца спринта, а затем проанализировать возможное включение новинки в следующий спринт. Если речь не идет о чем-то, требующем немедленного прекращения работ, то единственное экстремальное решение (подобное возникновению исключительной ситуации в ходе выполнения программы) – это решение владельца продукта о досрочном завершении спринта. Это довольно драматичное решение, и, если владелец продукта не чувствует драматичность ситуации, он, как и все, дожидается начала следующего спринта.
Правило запрета добавлений функциональности в период спринта следует из одного из принципов, упомянутых в предыдущих главах. Кажется, что оно не имеет устоявшегося имени, но оно так важно, что вполне его заслуживает. Будем называть его правилом закрытого окна: окно внесения изменений закрывается, когда спринт начинает выполняться.
Это правило позволяет справиться с одной из важных помех на пути успешной разработки – пагубным разрастанием свойств. Если быть более точным, то правило позволяет бороться с заказчиками и менеджерами, индуцирующими разрастание свойств. Заказчики и менеджеры полны идеями и мечтают о новых и новых свойствах. Демонстрация им системы на начальных этапах работы (что само по себе неплохо и усиленно пропагандируется в agile) стимулирует процесс добавления новых свойств, поскольку демонстрация явно показывает, какая функциональность опущена. Сам по себе феномен разрастания свойств неизбежен и во многих отношениях полезен. Успешная система хорошо служит бизнесу, если ключевые игроки сказали свое слово. Проблема пагубного разрастания часто возникает из-за людей, в чьей власти изменять приоритеты. Он или она приходят с суперидеей, настолько "супер", что ее следует реализовать немедленно в ущерб текущим задачам. Такие прерывания могут быстро свернуть проект с правильного пути: приоритеты меняются, важные работы задерживаются, разработчики деморализуются. Но без четкого процесса управления изменениями такие запросы трудно игнорировать по политическим соображениям.
Гениальность правила закрытого окна в том, что разрастание свойств не игнорируется, не делаются попытки сражаться с ним в открытую. Все направляется в строго лимитированное русло планирования очередного спринта. Практическим следствием является естественный отбор конкурирующих свойств. По прошествии нескольких дней многие великолепные предложения теряют свой блеск. Когда приходит время отбора задач на следующий спринт, они уже не кажутся столь неотложными. Удается избежать срывов, и шум затихает сам по себе. Идеи, истинно заслуживающие рассмотрения, получают приоритет по отношению к другим задачам.
Одной из центральных agile практик являются ежедневные встречи, называемые также "встречи стоя", или ежедневный Scrum. "Встречи стоя" называются так по той причине, что они короткие – пятнадцать минут, и требуется, чтобы все стояли. Последнее непрактично и обычно не применяется. Их называют Scrum встречами, поскольку многие группы используют некоторое приближение к версии, провозглашенной в Scrum.
Обоснование встреч в начале каждого дня исходит из общего agile принципа – прямые контакты критичны для успеха проекта. Это согласуется с общим недоверием agile к тяжелым процессам и таким затратным практикам, как долгие встречи. В данном подходе акцент делается как на частоту, так и на строго ограниченное время встречи. В частности, твердо устанавливается, что не должно происходить на этих встречах – здесь не должны искать решения проблем, затевать глубокие технические обсуждения. Фокус встреч определен точно – получить ответы на "три вопроса": что каждый сделал в предыдущий день, что он собирается делать сегодня, какие есть препятствия в работе?
Первые два вопроса дают возможность членам команды работать согласованно, содействуя прогрессу проекта и его ближайшему будущему. Они также позволяют убедиться, что члены команды берут на себя реалистичные обязательства, поскольку ответ на второй вопрос – это обязательство, за которое придется отвечать завтра, в ответе на первый вопрос. Как пишет Кон, это не упражнение на то, как обмануть босса, а взятие членами команды взаимных обязательств.
В ответе на третий вопрос указывается любая помеха для члена команды, мешающая ему реализовать поставленные цели. Это могут быть технические препятствия, такие как проблемы с техникой, это могут быть организационные помехи, например, отсутствие члена команды, чьи данные необходимы для работы. Встреча должна устранить препятствия, если это не требует времени, или установить лицо, ответственное за преодоление помехи. В Scrum удаление препятствий – одна из главных обязанностей Scrum-мастера.
Как отмечают многие авторы, нужно быть начеку, чтобы не нарушались цели встречи, угрожающие ее эффективности. Двумя главными угрозами являются члены команды, вступающие в споры или начинающие длинные технические обсуждения. Когда эти риски обнаруживаются, устранить их просто – достаточно иметь ответственное лицо. В традиционном подходе – менеджер проекта, в Scrum – мастер, который может:
Ежедневные встречи с концентрацией на трех вопросах, со строгими рамками на предмет обсуждения и длительность – блестящая идея. Как и в случае с другими agile идеями, можно перестать прислушиваться к советам, когда они становятся догматичными. В частности, такие обстоятельства, как географически распределенная команда, естественно требуют вариации базисной схемы.
Распределенная команда, которую я знаю, расположенная на трех континентах и оттачивающая процесс взаимодействия в течение нескольких лет, имеет две встречи в неделю – в понедельник и в четверг во время, приемлемое для всех временных зон. Обе встречи продолжаются по часу по вышеупомянутым причинам. При встречах у них возникают и дополнительные цели.
Эта конкретная процедура выработана методом проб и ошибок (а также чтением agile и не agile литературы). Она хорошо работает для этой конкретной группы. Команде удалось введением различных ограничений настроить свой собственный вариант "ежедневных встреч". Свободная от догматизма, адаптированная к распределенному способу построения команды, к гибкому рабочему расписанию членов группы, к стилю современных компаний, эта идея, уделяющая особое внимание "трем вопросам", является одним из главных вкладов agile школы. Со временем так будет работать вся индустрия и никому не придет в голову, что можно работать иначе.
Следующие две практики, которые будут рассмотрены в этом и следующем разделах, связаны с одной из наиболее сложных проблем управления и разработки программных систем: оценки стоимости системы, которую следует разработать, или отдельной ее части. Игра в планирование пришла из экстремального программирования, покер планирования – из Scrum. Оценка стоимости является целью в обоих случаях. Представляя лишь подмножество того, что обычно покрывает планирование, эта ограниченная область находится в полном соответствии с общим agile убеждением, не приемлющем предваряющий анализ.
Единицей стоимости при оценке была единица затрат времени на работу: человеко-месяц или как минимальный по уровню гранулярности – день разработчика (один программист работает один день). Более изощренные метрики придуманы в настоящее время, в частности, баллы, начисляемые "истории", что предстоит нам изучать при обсуждении артефактов. Дискуссия в этом и следующем разделах не связана с выбором частных метрик.
Игра в планирование в XP не является "игрой", носящей характер соревнования, где есть победители и проигравшие. Она соответствует кооперативным играм теории игр, где два игрока пытаются достичь максимизации различных критериев и ищут компромисс между ними. Двумя игроками в данном случае являются "бизнес" и "разработка" в терминах Бека, или проще – потребители и разработчики. Потребители пытаются максимизировать функциональность и минимизировать время ее достижения. Разработчики оценивают уровень трудности, связанный с каждым элементом функциональности, и требуемое для реализации время, которое невозможно сократить. В этой игре
Играя в планирование, обе группы проводят переговоры по поводу оценок. Потребители сортируют истории на основе приоритетов. Игра завершается, когда обе группы приходят к согласию, позволяющему выбрать истории с максимальным приоритетом с общей стоимостью, позволяющей уложиться в отведенное время при данном числе разработчиков. Как вариант этой игры результат не так строго связывается с циклом релизов, а просто состоит из списка историй с указанными приоритетами и стоимостью.
Покер планирования в Scrum играет ту же роль, что и игра в планирование в XP. Его задача – заранее оценить стоимость пользовательских историй. И снова обсуждение не зависит от меры стоимости: то ли это человеко-дни, то ли баллы, начисляемые истории.
В покере планирования используются две идеи:
В качестве такого множества обычно выбираются числа Фибоначчи: 0, 1, (снова 1) 2, 3, 5, 8, 13, 21, 35,…
Я уже слышу ваши возгласы: "Это не числа Фибоначчи! Последнее число должно быть 34!" Действительно. Поздравляю вас с хорошей математической подготовкой. Но в нашем случае все разумно и изменение имеет свою причину. Один известный agile консультант организовал блестящий бизнес по производству и продаже колод карт для покера в Scrum. Чтобы не иметь проблем с правами на использование чисел Фибоначчи, он слегка изменил последовательность. Напомню, что числа Фибоначчи были предложены итальянским ученым Фибоначчи в 1202 году (в Индии они появились тысячелетием ранее). Для Scrum покера не имеет особого смысла давать точную оценку, поэтому и 34, и 35 одинаково хороши.
Если оценки стоимости даются в человеко-днях, то второй член последовательности может заменяться значением 0,5, поскольку могут быть легкие истории, реализуемые меньше чем за день. Соседние числа для оценок серьезных работ существенно отличаются, например 13 и 21, что облегчает выбор между этими двумя вариантами. Целью планирующего покера является получение грубых оценок, что разумно, поскольку получение точных оценок на этом этапе не представляется возможным.
Некоторые варианты планирующего покера в качестве множества оценок выбирают еще меньшие множества, например множество из 5 оценок, соответствующих размеру некоторых видов одежды от X small до X large. Многие варианты включают в это множество и значение, задаваемое знаком вопроса (?), применяемое, когда член команды затрудняется оценить стоимость рассматриваемого элемента, не имея достаточной информации.
Панель оценок, используемая в покере, заполняется командой разработчиков, но в обсуждениях участвуют владелец продукта и представители потребителей. Работа по оцениванию строится в форме "Delphi" – метода принятия решения, основанного на достижении консенсуса экспертов. Этот метод десятилетиями применялся в вооруженных силах США. Он также отвечает более современной концепции "мудрости толпы", в соответствии с которой группа в среднем может коллективно достичь лучшего решения, чем решение, данное лучшим индивидуальным экспертом. Целью метода является достижение консенсуса, но при этом следует избегать возможности подавления мнения меньшинства.
Процесс оценки стоимости элемента функциональности включает следующие шаги:
Кон полагает, что планирующий покер позволяет получить команде более точные оценки, чем любой другой метод, который они использовали до этого.
Однако он не ссылается на систематическое изучение этого вопроса. Мой собственный опыт, также индивидуальный и также не основанный на тщательном изучении, менее сенсационен. Я вижу проблему в давлении большинства. Если вы действительно эксперт и ваша оценка существенно расходится с оценкой остальной части группы, трудно спорить достаточно долго, не проявляя некоторой степени заносчивости. Для сохранения гармонии вы соглашаетесь с другой точкой зрения, особенно, если знаете, что эта задача вам не достанется. Этот компромисс может вредить проекту, особенно, когда эксперт знает, насколько трудна в реальности обсуждаемая задача, но неспособен убедить в этом других, не имеющих опыта решения подобных задач и полагающих, что это "пустячок".
Все agile методы, как мы видели, рекомендуют включать заказчиков или их представителей в проект. XP имеет, в частности, понятие "активного потребителя", также известного как встроенный потребитель. Это напоминание, поскольку в предыдущей главе обсуждались соответствующие роли потребителя и владельца продукта.
Методы agile уделяют внимание физической организации рабочего пространства.
Многие команды разработчиков традиционно используют, по крайней мере в США, личные офисы для ведущих сотрудников и кабинки для остальных. (В Европе кабинки менее распространены, более экстремальные форматы несовместимы с трудовым законодательством; в некоторых странах, например, требуется, чтобы каждый офисный работник имел доступ к дневному свету.)
Закрытые офисы и кабинки предаются анафеме в agile. Поскольку коммуникациям отводится главная роль, то, в соответствии с принципами, разработчики должны работать в открытом пространстве. Вот типичное высказывание на эту тему [Schwaber 2002]:
Используйте открытое рабочее пространство. Такое окружение позволит людям общаться более просто, что облегчает самоорганизацию. Когда я вхожу в открытую область, я могу непосредственно определить, как работается команде. Молчание всегда плохой признак. Слыша обсуждения, я понимаю, что люди сотрудничают. Когда я вхожу в помещение, разделенное на кабинки, то часто молчание указывает на отсутствие взаимодействия. Кабинки – это бич современного рабочего пространства. Они буквально разъединяют людей и разрушают команду.
Вот рекомендации agile:
Многим разработчикам, по моему опыту, нравится такое окружение, противоречащее стереотипу программиста как погруженного в себя зануды. Многие – не означает все; свидетельством является то, что многие ходят в наушниках, препятствующих шуму. Некоторые agile авторы говорят о необходимости хотя бы временного уединения – конуса тишины в терминах Кокбурна.
В самом деле, хотя основная идея звучит прекрасно и кабинки достойны всяческого презрения, хорошо, когда каждый может последовать примеру Кокбурна. Открытое пространство не является решением для всех людей и на все времена. Невозможно принять утверждение Швабера "Тишина – всегда плохой признак" как серьезное.
Программная разработка – это сложная интеллектуальная деятельность. Здесь есть инженерная часть, требующая интенсивной коммуникации, взаимодействия, обсуждений. Есть исследовательская часть, которая во многих отношениях близка к математике, требующая размышлений. Должно быть время для бесед и время для концентрации. Некоторым при размышлениях нравится излагать коллеге ход своих мыслей – стиль парного программирования, другим требуется ходить при размышлениях (подобно Наполеону), третьи погружаются в себя и на время не замечают, что происходит вокруг.
Нам всем знакомы примеры молчаливых программистов – интровертов, от которых на встречах не добьешься слова, но которые в одно прекрасное утро приходят с прекрасно спроектированной и реализованной подсистемой, которую все разговоры в мире не могли бы создать. Достойный труд рождает уважительное отношение к программистам (за которое решительно выступает Crystall). Следует принять, что люди различны и единая схема для всех не подходит. Уверен, можно молчаливого гения попросить пообщаться немного. Но если заставлять его участвовать во всех дискуссиях, то в результате он со своим талантом найдет более подходящее окружение.
Мягкое подталкивание, кстати, должно применяться в обеих ситуациях. Неумолкающий коллега, возможно, соответствует идеалу agile, представляя образец "значимого взаимодействия", но может стать серьезной помехой прогрессу проекта; вполне справедливо заставить его помолчать и хоть что-нибудь сделать самому.
Если "молчание – всегда плохой признак", то что можно сказать об обратной ситуации: рабочем пространстве, наполненном сплошным шумом? Это просто вызывает тревогу. Здоровое окружение, по моему опыту, то, в котором люди иногда говорят, а иногда молча читают, или пишут, или просто думают. Когда "входишь внутрь" рабочего пространства и видишь программиста, уставившегося в потолок, то только наивный (и, уверяю вас, некомпетентный) менеджер приходит к немедленному заключению, что программист зря тратит деньги компании.
Необходимость гибкости связана не только с различием характеров программистов, но и с природой самих задач. Определение требований вызывает необходимость широкого взаимодействия, привлечения многих людей, хотя даже здесь в основе лежит способность размышлять, классифицировать и абстрагировать приходящую информацию. Проектирование и реализация требуют большей сосредоточенности, хотя даже здесь необходимо взаимодействие с другими разработчиками.
Все эти справедливые замечания не отрицают основу высказанной точки зрения agile – открытое пространство хорошо работает. Просто не следует хорошую идею превращать в догму. Различные люди, различные обстоятельства, различное время в ходе разработки проекта требуют различных решений.
Тренировки для освоения agile часто используют технику, которую Кокбурн называет "процессом в миниатюре". Суть ее в том, чтобы освоить приемы agile, решая задачи, далекие от программирования, в течение короткого периода – день, час или десяток минут. Учебные сессии Scrum прославились тем, что предлагают участникам спроектировать бумажные самолетики, применяя роли, принципы и практики Scrum. Запускать в полет изготовленные бумажные самолетики – забавное дело.
Процессы в миниатюре, возможно, хороший способ визуализации практик, которые в противном случае могут показаться абстрактными, прием, помогающий понять взаимодействие группы, ее объединение в самоорганизуемую команду. Только не следует забывать, что это просто моделирование и что наиболее серьезные проблемы, технические и индивидуальные могут материализоваться лишь в гуще настоящего проекта. Проектирование и запуск бумажных самолетиков отнюдь не то же, что проектирование самолетов.
Некоторые agile практики предполагают проведение регулярных встреч. Мы уже познакомились с "ежедневными встречами", но есть и другие, кодифицируемые, в частности в Scrum.
В начале итерации (спринт в Scrum) должна быть встреча, посвященная планированию итерации. На этой встрече должны быть выработаны три главных результата:
Заметьте, отсутствуют такие цели, как
Обычно резервируется встреча команды и владельца продукта. Поскольку команда берет на себя ответственность за реализацию бэклога в отведенное время, наблюдатели в этот период отсутствуют.
Формирование бэклога представляет двухэтапный процесс. На первом шаге выбираются пользовательские истории из бэклога продукта. На втором – истории преобразуются в задачи, требующие выполнения.
Процесс также требует оценки стоимости каждой задачи. Здесь используются такие техники, как игры в планирование и планирующий покер, обсуждаемые ранее в этой главе. Поскольку на этом этапе определяется число задач, которые должны быть реализованы, владельца продукта могут попросить покинуть собрание на время оценки стоимости задач.
Во избежание бесконечных дискуссий встреча имеет ограниченный лимит времени, обычно один день (восемь часов), иногда разделяемый на две части: одна – для выбора пользовательских историй, другая – для формирования задач.
Заключающая итерацию встреча является зеркальным отображением начальной встречи планирования итерации. Ее цель – оценить полученные результаты итерации.
На встрече команда представляет полученные результаты потребителям, в частности владельцу продукта в Scrum. Обсуждается, что достигнуто из запланированного, что нет; соответствие критериям приема задач, реальная стоимость задач.
Обзорная встреча фокусируется на результатах, а не на процессе. Конец спринта – хорошая точка для рассмотрения не только того, что было сделано, но и как это было сделано. В Scrum для этих целей резервируется специальная встреча, называемая ретроспективой.
На этой встрече обсуждается, что прошло хорошо, а что менее удачно, с упором на то, что можно улучшить, выполняя последующие итерации. Цель похожа на то, что можно найти на 5-м уровне CMMI – "Оптимизация": интегрирование обратной связи в процесс разработки, чтобы можно было улучшить сам процесс.
В то время как на итоговой встрече требуется присутствие владельца продукта (в Scrum или представителя потребителей для других подходов), ретроспектива предназначена для рассмотрения внутренних целей, поэтому здесь присутствуют команда и тренер (Scrum-мастер), хотя владелец продукта также может присутствовать.
Основные agile приемы применимы для небольших команд, до 10 человек. Возникает вопрос, как масштабировать процесс разработки на большие проекты. Вот как на этот вызов отвечает Scrum. Подход называется "Scrum of Scrums" (Scrum Скрумов) и определяется следующим образом:
Ежедневный Scrum, на котором присутствуют по одному человеку из каждой команды в многокомандном проекте.
Такие встречи необязательно проводятся каждый день, чаще два-три раза в неделю. Целью таких встреч является координация, позволяющая выяснить:
Регулярные встречи являются эффективным способом решения первой проблемы. Если вы знаете об изменениях в API, которые могут стать причиной ошибок в клиентском коде, если эти изменения документированы (а, возможно, обсуждены заранее), то это позволяет избежать серьезных трудностей в работе.
Что касается второй проблемы, то лучший agile ответ, который я видел, состоит в том, что зависимостей следует избегать. В соответствии со Швабером [Schwabber 2004]:
Прежде чем проект официально начнется, команды разбирают работы, минимизируя зависимости между ними. Команды затем работают над ортогональными частями архитектуры проекта. Этот механизм эффективен только тогда, когда требующие согласования связи между частями минимальны.
Совершенно верно, разделение проекта на "ортогональные" части работает, только если имеет место аддитивная сложность. Но по-настоящему "большой" проект является большим из-за его мультипликативной сложности. Хотя agile литература приводит примеры больших проектов и убеждает, что Scrum, XP и другие подходы допускают масштабирование, реальных подходов к решению возникающих проблем не дается. Как написано в их собственных текстах, agile подходы применимы, главным образом, для команд, включающих небольшие группы разработчиков.
Закончим этот обзор agile практик, связанных с процессом производства продукта, agile предписанием, которое можно рассматривать как принцип, хотя оно не имеет ни той же важности, ни общности применения, как принципы предыдущей главы.
Во многих проектах за каждый модуль проекта, за каждую подсистему несет ответственность один человек. Типичный комментарий, характерный для команд Майкрософт: "Если вы хотите изменить нечто в этом API, вы должны связаться с Лизой, поскольку она владеет этим элементом". Здесь не имеется в виду, что Лиза – "собственник" кода, владелец интеллектуальной собственности; речь идет лишь о технических аспектах, она тот, кто решает все вопросы, связанные с изменениями этой части кода. Владение кодом в этом смысле характерно не только для коммерческого ПО: многие проекты с открытым кодом, такие как Mozilla, также применяют подобную модель, где требуется разрешение владельца модуля на просмотр кода модуля. В обмен на это мы ожидаем, что владелец модуля несет ответственность за корректную работу, рассматривает заплатки, предлагаемые другими, и способен оценить код, разработанный другими людьми.
Индивидуальное владение кодом имеет ясные достоинства. Кто-то несет ответственность за каждый модуль, что обеспечивает согласованность и целостность общего продукта. Один из наиболее серьезных рисков эволюции программной системы – это ее деградация вследствие несогласованных расширений ("ползучий фьючеризм"). Наличие четких ответственностей позволяет снизить этот риск.
Индивидуальное владение кодом может иметь, с другой стороны, отрицательные последствия, отмечаемые аджилистами, в частности, сторонниками XP. В этом случае с системой может происходить так называемая "балканизация", когда каждая часть кода становится отдельным "государством". Когда вся экспертиза отдельной части системы проводится одним человеком, возникает серьезный риск, связанный с уходом этого человека. Помимо этого, возникают проблемы "барьеров": эксперт может быть недоступен или просто не всякий может отважиться обратиться к нему.
XP предлагает коллективное владение кодом [Back 2005]:
Каждый член команды может улучшить любую часть системы в любое время. Если в системе что-то не так и исправление ситуации не выходит за пределы той области, с которой вы работаете, то внесите исправления в систему.
В этом утверждении нюансов больше, чем в его предшественнике [Back 2000]:
Любой, кто видит возможность внести улучшения в любую часть любого кода, должен это сделать в любой момент.
Обе версии удивительным образом игнорируют роль другой практики – парного программирования, изучаемой в следующей главе. В фактическом применении XP, как описано у Кокбурна [Cockburn 2005], парное программирование сдерживает практику "свободно-для-всех":
Любых два человека, работающих вместе и соглашающихся с необходимостью изменений могут изменить любую строчку кода в системе.
Это ограничение кажется минимально необходимым, чтобы коллективное владение кодом было разумным. Даже в компетентной и самоорганизуемой команде было бы опасно допускать произвольные изменения без еще одной пары глаз, по меньшей мере. Политика "свободно-для-всех" может быть успешной в Википедии. Но там существует многочисленная охрана в лице бдительного сообщества, миллионы редакторов и тысячи администраторов.
В методе Crystall применяется более умеренный подход:
Большинство из проектов Crystall, с которыми пришлось познакомиться, применяют политику "измени, но дай мне знать".
При оценивании различных политик – персонального владения, коллективной собственности, нечто среднего – следует заметить, что сохранение корректности – не единственная проблема. Agile методы требуют регулярного выполнения набора регрессионных тестов, так что, если в результате "свободно-для-всех" кто-то добавит неверный код, существует хороший шанс, что проблема будет немедленно обнаружена. Потенциально более серьезной проблемой является деградация кода, описанная Кокбурном:
Каждому разрешается добавлять код в любой класс. Но никто не испытывает желания удалять чей-то код из непомерно раздутого класса. Ситуация подобна холодильнику в комнате с несколькими сожителями: со временем там все больше плохо пахнущих продуктов, но никто не решается их выбросить.
На самом деле этот вопрос более важен, чем контроль изменений при владении кодом. При наличии современных средств конфигурации возможно автоматическое применение правил, запрещающих, например, внесение изменений до тех пор, пока другой человек не санкционирует их применение. Google имеет такое правило. Более формальная версия требует "обзора кода прежде чем он будет изменен"; правило известно как правило RTC (Review Then Commit) – "Осмотри Потом Выполни). Этому правилу отвечала начальная политика Apache. После жалоб на то, что оно слишком строгое, в 1998 году Apache ввел правило CTR (Выполни Потом Осмотри), когда изменения сдерживаются редко используемой, но заставляющей программиста быть начеку возможностью наложения запрета на изменения.
Каждый проект должен определить свою политику по фундаментальному вопросу контроля изменений, выбирая нечто среднее между экстремальными позициями: "слишком много свободы", что чревато "гнилым кодом и жучками", и "слишком много ограничений", что приводит к замиранию процесса. Решение по владению кодом должно следовать из более общей фундаментальной политики. Оно зависит от разных аспектов, например, выпускает ли компания продукты с открытым кодом. Опять-таки повторим неоднократно сказанное: не следует иметь единое правило на все случаи жизни, как предписывает XP.
Экстремальное предложение, позволяющее каждому изменять все что угодно, становится менее удивительным, когда оно анализируется в свете другой общей agile практики – присваивать очередную задачу из бэклога итерации первому освободившемуся разработчику. Такой подход может работать только тогда, когда все разработчики взаимозаменяемы, каждый может выполнять любую работу. В этом состоит предположение agile о кроссфункциональности команды. Разработчики не должны быть специалистами в узкой области в ущерб универсальности.
Аргументы за и против кроссфункциональности примерно такие же, как и аргументы за и против индивидуального владения кодом. Риск специализации в том, что специалист может ревностно защищать свои владения, может уйти или какое-то время быть недоступным. С другой стороны, сложный проект требует специальных знаний, которыми каждый обладать не может. Поручать неспециалисту подобную задачу означает, что либо он будет осаждать эксперта, либо испортит работу. Как правило, разумнее дождаться освобождения специалиста и поручить ему выполнение такой работы.
Кажется, что на эти рассуждения оказала влияние предполагаемая проблемная область. Когда читаешь agile рекомендации иметь кроссфункциональные команды, создается впечатление, что они базируются на опыте консультантов, привыкших иметь дело с массовыми типовыми коммерческими разработками. В технически продвинутых областях специализация жизненно необходима. Если вы строите операционную систему и следующая задача включает схему обновления памяти, то не просите кого угодно заняться этой задачей, а отдайте ее специалисту, который лет пять своей жизни потратил на то, чтобы стать мастером в данной области.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.