Теория для победителя

&laquoЭкспресс-Электроника&raquo

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

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

Как правило, под термином «проект» подразумевается ограниченный во времени организационный стратегический план для создания уникального продукта или услуги, который может выполняться как одним человеком, так и коллективом. Данное определение проекта ничего не говорит о длительности выполнения работ – оно может варьироваться в самых широких пределах. Неизменным остается лишь конечная цель проекта – получение прибыли или некоего стратегического результата, а также инструмент оптимизации хода выполнения работ – Project Management. Последний подразумевает использование определенных знаний, умений, средств и методов для достижения поставленных целей.

Приведенное определение, позаимствованное из руководства по основам управления проектами (A Guide to the Project Management Body of Knowledge), созданного Project Management Institute, к сожалению, не отражает тех трудностей, с которыми приходится сталкиваться большинству компаний при реализации даже относительно несложных проектов. На наш взгляд, все они связаны с отсутствием у исполнителей современных знаний в области оптимального ведения проекта, а также неумения создать или организовать по-настоящему действенную функциональную команду.
И если первая проблема решается достаточно просто – обучением имеющегося персонала или наймом квалифицированного, то решение второй куда сложнее. Дело в том, что принцип формирования команды, принятый в нашем обществе, не правилен, и преодоление стереотипов, связанных с ним, вызывает непонимание у руководства большинства компаний. Иногда дело доходит до саботажа в рядах менеджеров верхнего уровня (не являющихся владельцами компании). Не стоит забывать и об особенностях национального менталитета. К слову, они почему-то полностью нивелируют преимущества использования средств ускоренной разработки программных продуктов, зарекомендовавших себя с наилучшей стороны в западных компаниях.

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

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

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

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

В то же время диаграммы Гантта имеют ряд недостатков. Например, с их помощью довольно сложно планировать многовариантные взаимосвязанные цепочки работ (в строительных, военных, государственных проектах и на производстве). Для таких задач в военном ведомстве США в 1950-е годы были предложены методы сетевого планирования, или методы выбора «критического пути». Кроме того, диаграммы Гантта удобно применять только для одного критического ресурса — времени. При необходимости учитывать еще несколько ресурсов, например технологическую оснастку, диаграммы Гантта надо воспринимать как объемные, приобретающие ряд измерений по числу учитываемых ресурсов. Это имеет смысл для визуальной интерпретации планов, но затрудняет их анализ. Для управления ходом проекта используются более мощные средства – CPM, PERT и некоторые другие. Ниже дается их описание.

В 1956 году М. Уолкер из фирмы DuPont, исследуя возможности более эффективного использования принадлежащей фирме вычислительной машины Univac, объединил свои усилия с Д. Келли из группы планирования капитального строительства фирмы «Ремингтон Рэнд». Они попытались использовать ЭВМ для составления планов-графиков крупных комплексов работ по модернизации заводов фирмы DuPont. В результате был создан рациональный метод описания проекта с использованием ЭВМ. Первоначально он получил название метода Уолкера-Келли, а позже переименован в метод критического пути (Critical Path Method — CPM). Данный метод имеет три достоинства — позволяет получить графическое представление проекта, определяет ориентировочное время, требуемое для его выполнения, и показывает, какие действия критичны, а какие не столь важны для соблюдения всего графика работ.

При использовании СРМ действия, составляющие проект, моделируются как сеть, разбитая на узлы завершения этапов работ. События, которые находятся между этими условными узлами, не выделяются и на диаграмме показаны как объединительные дуги. Построение самой сетевой диаграммы осуществляют на основании данных о перечне и последовательности действий. Обычно начинают с узлов-действий, соединяя их впоследствии дугами-событиями. Над дугами указывается число, отражающее длительность выполнения проекта. Именно выставление длительности хода выполнения проекта, которая может быть вычислена путем суммирования самой длинной (в хронологическом отношении) ветви, позволяет оперировать оригинальной величиной — критическим путем (максимальная длительность выполнения проекта).

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

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

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

Для задач, связанных с интеллектуальным трудом и другими вопросами, в которых стоимость оптимизируемого параметра не известна наверняка, используется метод PERT-анализа (Program Evaluation Review Technique).

Он был разработан сотрудниками Военно-морского флота США в 1957 году для обеспечения создания ракеты «Поларис». Применяя PERT-анализ, они попытались сымитировать график выполнения работ по созданию ракеты путем построения логической сети взаимозависимых последовательных событий. На начальной стадии PERT-представление было сфокусировано на контроле временных характеристик графика и прогнозировании вероятности успешного завершения программы. Но прежде чем PERT-представление было окончательно принято руководителями программ в промышленности, Военно-воздушные силы США внесли дополнение в методику, добавив к логической сети функцию ресурсной оценки. Таким образом, в 1962 году появилась PERT/Cost-методика (PERT-анализ с целью стоимостного прогнозирования), в то время как первоначально PERT-анализ был известен под названием PERT/Time (PERT-анализ для определения времени реализации проекта).

Использование метода PERT позволило руководству программы точно знать, что требуется делать в каждый момент времени и кто именно должен это делать, а также какова вероятность своевременного завершения отдельных операций. Руководство программой оказалось настолько успешным, что проект удалось завершить на два года раньше запланированного срока. Благодаря такому впечатляющему началу, данный метод управления вскоре стал использоваться для планирования проектов во всех вооруженных силах США. Методика отлично себя зарекомендовала при координации работ, выполняемых различными подрядчиками в рамках крупных проектов по разработке новых видов вооружения.

Типичный период времени, применяемый в PERT — одна неделя, но при необходимости может использоваться и любой другой промежуток. Для каждого действия указывают три оценки его длительности — оптимистическая (О), наиболее вероятная (В) и пессимистическая (П). Ожидаемое время продолжительности каждого действия может быть приблизительно оценено как (О + 4В + П)/6. Это расчетное время и указывается на сетевом графике.

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

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

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

Позже, для получения еще более точных оценок, стали использовать некоторые специальные математические методы, например «рулетка случайных чисел Монте-Карло» или методы статистического моделирования. Хотя первые методики используются и по сей день. Так, работы Гарри Гантта легли в основу научных дисциплин, возникших в середине ХХ века, — промышленной инженерии, занимающейся управлением и организацией производства, а также исследования операций. С исследованием операций связаны работы по применению математических методов формализации человеческой деятельности, в том числе в производстве и планировании. Разработаны многие статистические и оптимизационные алгоритмы планирования, используемые в современных системах. Например, в SAP R/3 для прогнозирования потребностей в продукции (функция Forecast) с учетом информации о фактическом спросе за предыдущие периоды, применяются статистические и эвристические методы (расчеты сезонных колебаний спроса, расчеты по трендам). Еще один пример — методы оперативного планирования (функция Scheduling), подсистемы планирования производства SAP R/3, в которых использованы алгоритмы расчета даты выполнения заказа, сокращения длительности производственного цикла, минимизации переналадок оборудования и прочие.

Групповое авторство

Одной из проблем программирования является недоступность по той или иной причине разработчика определенного фрагмента кода, в результате чего его поддержка становится сложной или невозможной. Многие заказчики и группы попадали и попадают в зависимость от "гуру" — и всегда с негативными последствиями.

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

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

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

Куда двигаться дальше? Первое — ознакомьтесь с сайтом, материалы которого положены в основу этой статьи. Прочитайте также замечательную книгу "Быстрая разработка программ: принципы, примеры, практика" Роберта Мартина. Она снабжена многими примерами — однако не стоит воспринимать ее как справочник по Java. За техническими деталями кроются эфемерные флюиды хода мысли экстремального программиста. Даже самые опытные из вас смогут почерпнуть там новые идеи — и, я думаю, не согласиться с этими идеями будет сложно, поскольку они привнесены в практику из практики и теорией стали только на время.

Идеальный день разработчика и фактор загрузки

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

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

Другим временным фактором является скорость проекта.

История пользователей

История пользователей — это аналог Use Case, но имеющий несколько другой оттенок. История пользователя — это компактный документ (предположительно около трех предложений) составленный пользователем и описывающий одну отдельную операцию для данного пользователя в духе "я захожу в программу и...". В отличие от глобальных Use Case, где рассматриваются целые классы пользователей, историю пользователя легко определить, спланировать на конкретный цикл и реализовать в определенный срок. Скажем, "ввод накладной" значительно более ясен и детерминирован, чем "обработка входных документов".

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

Считается, что 80?20 историй пользователей являются идеальным числом для составления плана нового релиза.

Экстремальное программирование и быстрая разработка ПО

Арсений Чеботарев
"Компьютеры + Программы",

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

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

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

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

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

Экстремальный цикл

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

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

Как следствие постоянно изменяющихся требований следует другой принцип — позднее принятие решений.

Кодирование в глубину

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

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

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

Помимо концентрации на одной задаче в каждом конкретном цикле важное значение имеют также скорость проекта и фактор загрузки.

План итераций

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

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

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

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

План релиза

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

Выбранные истории являются основой для планов итераций.

Позднее принятие решений

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

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

Представители заказчиков

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

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

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

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

Простота и эффективность используемого кода

Часто предоставленный сам себе разработчик решает использовать новую технологию или инструмент, который, по его мнению, обещает дополнительную производительность или выгоду. На самом деле это редко оправдывается, а в атмосфере, когда ваш код завтра будет прочитан и использован партнерами по команде, у вас просто не остается возможностей для экспериментов за чужой счет. Фактически, все члены команды изначально должны выбрать технологии, которыми владеют все или большинство членов команды. Например, любой разработчик должен уметь программно обрабатывать текстовые файлы, многие знают C++, Java, Perl, SQL и подобные инструменты. Использование редких технологий и инструментов, например сложных, особенно заказных RAD и т.п., может вызвать не только проблемы понимания, но и впоследствии проблемы поддержки. Учитывайте, что освоение сложного инструмента может занять больше времени, чем вся разработка проекта.

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

Рефракторинг

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

Скорость проекта

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

Структура группы разработчиков

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

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

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

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

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

Тестирование модулей

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

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

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

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

Тесты приемки

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

Тестирование — не приложение к приложению, а, скорее, наоборот. Часто контроль качества (QA) и составление тестов возлагается на отдельную группу, в состав которой входят представители заказчиков.

Быстрый выпуск версий

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

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

Игра в планирование

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

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

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

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

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

Экстремальное программирование: новые возможности

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

Что же такое eXtreme Programming: набор отдельных правил и методик или полноценная методология? Давайте попробуем XP "на зуб", не отрывая глаз от страниц журнала.

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

В основе экстремального программирования лежат не конкретные методики, как принято считать, а лишь четыре базовых принципа: общение, простота, обратная связь и храбрость. Именно с них необходимо начинать.

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

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

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

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

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

Коллективное владение кодом

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

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

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

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

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

Метафора системы

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

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

Парное программирование

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

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

Постоянная переработка

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

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

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

Продолжающаяся интеграция

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

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

Программист или интерэкшн-дизайнер?

VP Design and General Manager, Cooper Ltd.

Оригинал: Can Programmers Do Interaction Design? by Kim Goodwin
Перевод: , сайт maxkir.com

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

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

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

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

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

Такой дизайн не эффективен, потому что изначально у программиста нет описания поведения программы.

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

"Но ведь мы же дали им спецификации!" - восклицают маркетологи. "Они просто не делают то, о чем мы их просим!". Если честно, самим программистам тоже не очень-то нравится постоянно переделывать свою работу.

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

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

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

Проблема усложняется еще и тем, как мыслит разработчик: у него никогда нет достаточного количества времени - ни на то, чтобы писать код, ни на то, чтобы следовать процессу, ни на что. Если маркетолог подойдет к нему с вопросом: "А нельзя ли вот тут сделать поддержку функции "перетащить и оставить"?", то программист обязательно ответит: "Нет, это практически невозможно". Однако по-настоящему он имеет в виду: "Это невозможно сделать за тот ничтожный период времени, который вы мне отвели. Я не могу выполнить те двадцать запросов, которые вы уже дали, и еще вот этот".

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

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

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

Об авторе
Ким Гудвин (Kim Goodwin) является вице-президентом по дизайну и генеральным менеджером компании "Cooper". Если у вас есть вопросы, комментарии или предложения, вы можете написать ей письмо на адрес kim@cooper.com

1) Для термина "interaction designer" пока еще не существует устоявшегося русского перевода.Именно поэтому здесь этот термин просто транскрибируется. "Интерэкшн-дизайнер" - возможно, не лучший вариант, но по крайней мере, звучит привычно в профессиональной среде и не создает вопросов относительно его значения. Другие варианты перевода: "дизайнер взаимодействия", "проектировщик взаимодействия", "дизайнер интерактивных систем".

© Copyright Cooper Ltd., все права защищены

© Copyright , перевод, 2004

Простота разработки

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

Рассмотрим такой пример. Можете ли вы сходу сказать, что делает следующий код C++ и результат какой математической операции с переменной x отражен в переменной f?

int x = 5; for (int i = 1, f = 1; i < x; i++, f *= i); cout<<f<<endl;

А если бы код выглядел так:

int x = 5; int f = 1; for (int i = 1; i < x; i++) { f *= i; } cout<<f<<endl;

Наверное, со второго раза все узнали алгоритм подсчета факториала (3! = 1*2*3). Компьютер безболезненно воспримет оба варианта, но человека сложный код может поставить в тупик.

Сорокачасовая рабочая неделя

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

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

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

Стандарты кодирования

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

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

Тестирование до начала разработки

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

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

Мне возразят: но ведь тест тоже может не работать. Что же, писать тест для теста? А потом тест для теста теста и так далее до бесконечности? Вовсе нет. Тест для теста заменит код. Как так? А вот смотрите: представьте себе, что нужно зафиксировать гайку посередине болта так, чтобы она не проворачивалась. Что для этого делают? Прикручивают вторую гайку вплотную к первой, так что каждая гайка не дает соседней проворачиваться. Так и в программировании: тест тестирует код, а код тестирует тест.

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

Управление проектами

Иван Селиховкин

Сергей Архипенков

Семенов В.А., Морозов С.В., Тарлапан О.А., Энкович И.В.
Труды Института системного программирования РАН

Труды Института системного программирования РАН

Сергей Архипенков

Перевод: Сергей Кузнецов

Оригинал: A Conversation with Bruce Lindsay, ACM Queue, Vol. 2, No. 8 - November 2004.

В.А. Семенов, С.Г. Ерошкин, А.А. Караулов, И.В. Энкович,
Труды Института системного программирования РАН

Е. Д. Волкова, А. Д. Страбыкин,
Труды Института системного программирования РАН

. Лекция из курса «Введение в технологию программирования»

Терехов Андрей Николаевич, Интернет-Университет Информационных Технологий, INTUIT.ru

, Компания
Источник:

, Труды Института системного программирования РАН

Волкова Е.Д., Страбыкин А.Д., Труды Института системного программирования РАН

Скотт Амблер, Ambysoft Inc.

Перевод - Сергей Кузнецов

, Препринт Института Системного Программирования РАН

Наталья Чернявская, Юрий Чернявский,

Алистэр Коуберн

()

Перевод: , maxkir.com

Мартин Фаулер, Chief Scientist, ThoughtWorks

Перевод: , http://maxkir.com/

VP Design and General Manager, Cooper Ltd.

Перевод: , сайт maxkir.com

Алистэр Коуберн, Humans and Technology, 4-ое октября 2003
Перевод: , сайт maxkir.com

Евгений Марков

Ксензов Михаил, Труды Института Системного Программирования РАН

Буздин К.В., Труды Института Системного Программирования РАН

, Softline Company

С.Архипенков

, , www.cmcons.com

Арсений Чеботарев,

К.В. Халимов, М.В. Резник, ЗАО "ПМСОФТ"

Гаврилов Н.Н., РЭА им. Г.В. Плеханова

Козлов А.С., ГУУ

Матвеев А.А., ЗАО "ПМСОФТ"

В.Н. Михеев,,
Е.О.Пужанова, ЗАО "ПМСОФТ"

, ООО ИК СИБИНТЕК

, "Экспресс-Электроника"

Наталья Дубова,

К.В. Ахтырченко, Т.П. Сорокваша, Труды

Джеймс Уайттеккер, Джеффри Воас
20.03.2003

Евгений Игумнов

В. Сухомлин, НИВЦ МГУ, учебные материалы конференции ,

Александр Родыгин

document.write('');

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

У нас проходит . Торопитесь!

РусбизнесАвто предлагает к продаже и КАМАЗ, предающие так необходимое ощущение легкости в работе.

Заказчик на рабочей площадке

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

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

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

Эти методики собраны воедино не

Эти методики собраны воедино не случайно. Их непротиворечивая совокупность способна ввести процесс разработки в интеллектуальный резонанс, заметно повысив качество продукта и приблизив время его выпуска. Основная прелесть всего экстремального программирования - прогнозируемость и сведение к минимуму затрат на разработку; предоставление заказчику того продукта, который он желает получить на момент выпуска; и конечно же общение и обучение разработчиков без отрыва от производства.