Гибкая методология разработки: вы все еще стоите на распутье или уже сделали свой выбор?

Оригинал:
Agile project methodology:
Are you on the fence or off it?

[Пометки переводчика]

Автор - Элизабет Томас

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

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

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

Agile в блоге321:

Но если методология PRINCE2 настолько хороша, почему так много государственных проектов в итоге проваливается?

Бывший министр обороны США Роберт Гейтс мог бы показать «успехи» традиционной методологии. В конце одного печально известного провального государственного проекта он отметил: «Я бы сказал так: за полмиллиарда долларов мы получили непроизносимую аббревиатуру [DIMHRS]».

Многие проекты терпят неудачу, потому что они выполняются традиционным способом людьми или компаниями, которые отказываются следовать инновациям. (Небольшое отступление: диаграммы Ганта и другие базовые принципы управления проектами были разработаны в 19-м веке.)

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

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

Кроме того, в стандартных каскадных проектах нереально выяснить постфактум, что пошло не так – так как не проводится «разбор полетов» – а поэтому весьма вероятно повторение подобных ошибок в будущих проектах.

Прогрессивные мыслители искали лучший способ организации. В 2001 году Они представили первый манифест «agile Manifesto». Вот что они написали:

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

· Работающее программное обеспечение важнее, чем полная документация;

· Сотрудничество с заказчиком важнее, чем контрактные обязательства;

· Реакция на изменения важнее, чем следование плану».

То есть: хотя принципы справа имеют ценность, мы больше ценим принципы слева.

Агентство «Форрестер Рисеч» недавно сделало вывод, что гибкая методология разработки сегодня уже не какая-то чудаковатая новая теория, а вполне практическое направление, способствующее успеху компаний, использующих его. Они пишут: «Пришло время профессионалам в области разработки программного обеспечения отринуть сомнения по поводу гибкой методологии разработки. По словам тех, кто успешно внедрил agile-методы, получаемые преимущества стоят затраченных усилий, и с недавним резким ростом числа применений этой методологии повысилась и вероятность работы в agile-команде или с ней - для всех».

А вы уже проводите необходимые изменения в управлении проектами разработки ПО или все еще стоите на распутье? Помните, что написал в своей книге «Адаптивная корпорация» (1985 г.) гуру управления изменениями Элвин Тоффлер: «Всегда легче говорить о переменах, чем делать их».

Первый принцип agile: предоставляйте результаты постоянно и быстро, чтобы удовлетворить ожидания клиента

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

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

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

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

Основная идея

У данного подхода есть много популярных вариантов: eXtreme Programming, «скрам» (scrum) и усовершенствованная методика «канбан», которую некоторые считают слишком уж простой. Поэтому разные люди по-разному понимают слово «agile», но основная идея всегда заключается в следующем.

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

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

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

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

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

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

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

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

Кто пользуется гибким подходом?

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

Стив Бортвик, директор по технологиям (CTO) компании «Артезиан Солюшенс», так объясняет причины перехода компании к agile-методам:

Мы небольшая компания по разработке ПО, у нас 25 человек, из которых 10 в отделе разработки и тестирования, финансируем мы себя сами. Думаю, это повлияло на наш подход к разработке программ. Эта компания была основана в 2007г. и она - мой третий стартап. Прошлый мы продали крупной американской компании в 2006г., так что новичками в разработке программ нас не назовешь.

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

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

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

А что предпочитаете вы - статус-кво или более успешные проекты?

Второй принцип agile: приветствуйте изменение требований

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

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

  • не хотят, чтобы их считали слабаками, у которых нет «постоянства в принципах»
  • полагают, что нужно держать все вокруг в ежовых рукавицах.

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

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

Но в реальности все может измениться за один день.

Ни один план не переживет контакта с противником

- Гельмут фон Мольтке (1848-1916), начальник генерального штаба прусской армии

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

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

Если вы запланировали все заранее, «заморозили» требования к проекту, а затем произошло что-то из перечисленного ниже?

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

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

Планирование в гибком мире

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

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

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

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

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

Что такое «бэклог»?

Это основной список всех тех вещей, которые потребуются вам на проекте.

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

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

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

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

Что такое «график обратного отсчета»?

График обратного отсчета поможет вам понять, чего уже добилась ваша команда.

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

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

Пример графика обратного отсчета. Автор: Пабло Штрауб

Примечание

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

Ключ к победе - изменения для клиента.

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

Третий принцип agile: предоставляйте программы по частям и быстро

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

Видели когда-нибудь статьи типа «Руководство по выполнению задач для ленивых»? Пункты в таких статьях применимы и к гибкому проекту.

Например:

  • Составьте список того, что нужно сделать. Храните записную книжку, где будете вычеркивать каждое сделанное задание. Радуйтесь тому, что вам удалось выполнить.
  • Прекратите откладывать задачи. Вставайте каждый день и делайте что-то, не важно, насколько мало задание. Если вы справились с ним, то и большие задачи не покажутся вам непреодолимыми.
  • Расставьте приоритеты. Что нужно сделать в первую очередь? Можно ли что-то сделать позже? Надо ли вообще это делать? Все сразу сделать не получится, так что решите, что имеет первоочередную важность, а что может подождать.
  • Установите ограничения по времени на каждую задачу. Это хороший принцип, который позаимствован у когнитивно-бихевиорального направления в психологии. Вы можете испытать чувство бессилия, если подумаете «передо мной столь огромная задача, что я даже не могу приступить к работе». Вместо этого скажите себе, что потратите на работу над задачей только 30 минут и ни минутой больше. Если вы займетесь сложной задачей в течение некоторого времени, это будет не так уж страшно. (И зачастую вы заметите, что работаете больше того времени. Что отвели сами себе, потому что вам понравится работа над этой задачей.)
  • Устраните отвлекающие факторы. Минимум совещаний и задач, которые не относятся к проекту. Менеджмент должен постоянно устранять любые препятствия на пути к выполнению задач, относящихся к проекту.

Все это напоминает обычный здравый смысл? То же верно и в отношении agileа.

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

Пишите программный код короткими «забегами»

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

Как это работает

Когда вы разделили общие требования на более мелкие наборы требований или «пользовательские истории», которые находятся в бэклоге, пришло время решить, какие из «историй» вы выполните забегом.

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

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

Айджайл-коуч Марк Родс замечает следующее: «Работа забегами означает, что вы можете изменять размер команды, чтобы подстроиться под рабочую нагрузку. Крупные компании координируют «забеги» команд и могут менять размер команды. Через определенный интервал времени все [менеджеры проектов] в компании регулярно собираются, чтобы обсудить различные проекты и то, как лучше распределить ресурсы».

Как начать забег

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

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

На ежедневных собраниях – скрамах – обсуждается прогресс, достигнутый за день.

Забеги всегда имеют одинаковую продолжительность. Нельзя делать забег длиной две недели, а потом забег длиной 10 недель.

Келли Уотерс занимался переходом компании «Ай-пи-си Медиа» к гибким методам разработки. Вот его мнение: «Если вы представите спектр подходов к разработке с хаосом на одном конце и строго формализованной разработкой на другом, «agile» окажется где-то посередине. Это формализованный подход, но концепция не ограничивает вас слишком строго».

Четвертый принцип agile: заказчик и разработчик работают вместе каждый день

Положите конец подходу «мы» (работники) и «они» (клиенты). Гибкий подход требует тесного сотрудничества с заказчиком, так что мы и они объединяются в «нас».

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

Постоянный диалог

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

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

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

«Люди часто думают о том, как улучшить «свой» продукт, так что вовлеченность заказчика имеет огромное значение».

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

Хорошая практика рабочего общения

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

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

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

Сотрудничество в управлении

agile-коуч Рэйчел Дэвис объясняет, что значит сотрудничество: «Команды agile-разработки во время написания программ опираются на процесс сотрудничества, в котором основную роль играют рабочие версии программ, а документы имеют второстепенное значение». Это не значит, что документы не нужны, но – вам не следует тратить много времени на создание документов, которые потом нужно «выполнить». Документы и программы разрабатываются параллельно и регулярно обновляются.

А где место менеджера по продукции?

Слово Стиву Бортнику, CTO компании «АртезианСолюшенс»: «В идеале ваш менеджер по продукции должен участвовать в ежедневных собраниях. Отрицательная сторона, конечно, заключается в том, что разработка кода – не тот вид деятельности, которому идет на пользу постоянное прерывание работы. Следует найти баланс между рабочим общением и производительностью. В идеале дискуссии и общение следует делать как можно более насыщенными, а программистов нужно защищать от того, чтобы их не «выбили с поля».

Прозрачность и сотрудничество

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

Хранилища следует оставить только в сельском хозяйстве

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

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

Пятый принцип agile: Прекратить микроменеджмент!

Хорошо подберите участников команды, но потом доверяйте их суждениям.

«Мотивация – искусство заставить людей делать то, что нужно тебе, потому что они хотят это сделать сами.»
Дуайт Эйзенхауэр

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

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

«Я набираю в команду людей, которые хорошо умеют объясняться и у которых много идей», - объясняет один из управляющих.

Стив Бортвик, CTO «Артезиан Солюшенс», так описал этот принцип: «Это не какая-то особая черта разработки программ или «agileа», просто людям нужно давать возможность рисковать самим и делать ошибки»

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

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

Разработчики сами выбирают себе задачи

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

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

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

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

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

Отказ от контроля

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

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

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

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

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

Руководство должно серьезно воспринимать agile

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

Если высшее руководство не относится серьезно к новым, созданным по методу «agile» командам, весь эксперимент может провалиться – у первой команды, которая начала осваивать гибкие методы, пропадет весь энтузиазм.

<br /> <div style="background-color: none transparent;"><a href="http://news.rsspump.com/" title="rsspump">news</a></div> <p></p>

Внимание Двойник!
Уважаемые клиенты и партнеры!
Просим Вас обратить внимание, что с конца 2011 года в городе Омске действует организация ООО "Лаб321" (ИНН:5503231758). Настоящим сообщаем, что деятельность указанной организации не имеет к нам никакого отношения. Использование данного наименования является нарушением действующего законодательства в части фирменного наименования юридического лица, о чем руководителю указанного предприятия направлено официальное письмо.
Прошедшие мероприятия