Гибкое (Agile) планирование в реальной жизни

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

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

Стефан Сурдек (Steffan Surdek), руководитель группы по работе с пользователями, IBM  

Стефан Сурдек (Steffan Surdek) – руководитель группы по работе с пользователями и добровольный пропагандист Agile-подхода, работающий в WebSphere® в команде по организации бизнес-сервисов (Business Services Fabric). Он проводит двухдневные семинары Software Group по Agile-разработке, помогая своей команде совершенствовать гибкие процессы работы.



30.07.2009

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

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

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

Коротко о гибкой (Agile) разработке ПО

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

На схожих фундаментальных концепциях основаны следующие современные способы анализа и операционного управления:

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

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

  • Предложения по облегчению перехода команды к применению гибкого планирования.
  • Советы по организации итераций. Насколько длинными они должны быть? Должна ли команда работать итеративно только во время работы над очередным релизом продукта? Чем следует заниматься команде в перерывах работы над релизами?
  • Понимание роли владельца продукта (product owner) и рекомендации по созданию пользовательских историй. Что такое пользовательские истории (user story)? Кто должен их создавать? В чем разница между эпопеей (epic) и пользовательской историей? Какой объем работы должна заключать в себе пользовательская история? Кто такой владелец продукта? Какова роль владельца продукта в рабочем процессе?
  • Практические советы по планированию и управлению резервом работ (backlog - объемом запланированной на выполнение работы) на уровне продукта, релиза и итерации. Каждому уровню планирования соответствует свой резерв работ. Что должны содержать эти разные резервы работ? Какой уровень точности оценок необходим для каждого уровня планирования?
  • Приемы измерения и интерпретации производительности команды. Какие прогнозы вы можете делать на основе данных о производительности команды?

Облегчаем переход

Перед переходом на новый процесс следует обратить внимание на следующее:

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

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


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

Начнем с популярного вопроса: «Насколько длинной должна быть итерация?». Цель работы итерациями - налаживание регулярного взаимодействия со сторонами, заинтересованными в вашем продукте (клиентами, владельцем продукта и т.д.)

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

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

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

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

В качестве альтернативы укороченной последней итерации мы можете сделать короткими (например, 2 недели) все итерации. При таком подходе, если дата релиза продукта не будет совпадать с концом итерации, вы сможете завершить работу над релизом на неделю раньше.

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


Создание пользовательских историй

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

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

Как <роль>, я хочу <цель>, чтобы <деловая выгода>.

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

Рисунок 1. Разбиение эпопеи на пользовательские истории
An image of an epic broken into multiple user stories

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

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

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

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

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


Выявление владельца продукта

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

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

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

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

Резерв продукта

Владелец продукта отвечает за резерв продукта (product backlog) – набор пользовательских историй, которые должны быть реализованы в продукте. Для каждой истории должен быть выставлен приоритет.

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

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

Рисунок 2. Резерв продукта служит источником для заполнения остальных резервов
Image showing how the product backlog feeds the release backlogs and the iteration backlogs.

Команда должна оценить размеры высокоуровневых историй в резерве продукта в баллах (так называемых story points). В процессе оценки участвуют все команды, вовлеченные в реализацию истории (разработчики, тестеры, технические писатели). Эти оценки дают владельцу продукта представление об относительной стоимости каждого куска функциональности.

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

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

Резерв релиза

Перед началом работы над очередным релизом продукта владелец продукта просматривает резерв продукта, выявляет истории, которые должны быть реализованы в этом релизе, и переносит их в резерв релиза (release backlog).

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

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

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

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

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

Резерв итерации

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

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

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

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

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

  • Задания по тестированию не учитывают время для написания тестовых сценариев.
  • Задания для команды разработчиков не включают в себя написание автоматических юнит-тестов.

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

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

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

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


Назначение баллов пользовательским историям

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

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

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

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

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

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

Покер Планирования – это способ командного согласования оценки сложности или объема работы при разработке программного обеспечения. В этом способе делается попытка минимизировать влияние, оказываемое на оценку преждевременными комментариями участников команды. Для каждого оцениваемого задания каждый член команды выбирает свою карту оценки (карты имеют значения 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100), таким образом, что его карту не видит никто из других игроков. После того как все игроки сделали свой выбор, карты раскрываются (и происходит обсуждение).


Измерение производительности

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

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

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

Через несколько итераций работы и такого подсчета баллов, вы сможете строить графики производительности, подобные тому, который показан на рисунке 3. Заметьте, что команда от итерации к итерации зарабатывает разное количество баллов.

Рисунок 3. График производительности на протяжении нескольких итераций.
Image of bar chart showing velocity over multiple iterations

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

Таблица 1. Количество баллов за итерацию
ИтерацияБаллы
128
232
336
434
533
637
731
835

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

  • Среднее количество баллов, зарабатываемое за итерацию - 33.
  • Текущая производительность команды – 35 баллов за итерацию.
  • Средняя производительность за 3 самые медленные итерации – 30 баллов.

Поэтому, предполагая, что до окончания работы над релизом остается 6 итераций, можно сделать следующие предположения:

  • При работе со средней производительностью команда сможет завершить историй еще на 198 баллов (6 х 33).
  • При работе с текущей производительностью команда сможет завершить историй еще на 210 баллов (6 х 35).
  • При работе с низкой производительностью команда сможет завершить историй еще на 180 баллов (6 х 30).

На рисунке 4 показан резерв релиза, разделенный на 3 секции. В средней секции показано, какое количество работы может быть выполнено на основе сделанных выше предположений.

Рисунок 4. Экстраполяция объема завершенной работы
Extrapolating where the work ends

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


Заключение

Основная цель гибкого планирования – сделать как можно больший объем «известной» работы видимым всем участникам процесса. Мы говорим «известной», потому что по мере получения новых знаний о выполняемой работе вы можете добавлять в резерв новые истории. Это позволяет владельцу продукта поддерживать приоритеты историй в актуальном состоянии и гарантировать, что работа постоянно будет идти над наиболее важными вещами.

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

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

Ресурсы

Научиться

Получить продукты и технологии

  • Разработайте ваш следующий Linux-проект с помощью ознакомительного ПО от IBM, которое можно загрузить непосредственно с сайта developerWorks.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux
ArticleID=417517
ArticleTitle=Гибкое (Agile) планирование в реальной жизни
publish-date=07302009