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

Вот ключевые темы, затронутые на конференции Agile:

1. Доверяйте команде.

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

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

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

2. Даже самодисциплинирующаяся команда нуждается в обучении.

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

Помочь здесь способны модели, при помощи которых менеджеры могут урегулировать конфликты внутри группы, например, модель урегулирования Abide model (attractors, barriers, identities, diversity, environment – факторы притяжения, барьеры, самосознание, разнородность, окружение). Изменяя эти параметры, можно повлиять на результаты. Используя модель потока, менеджеры могут регулировать уровень сложности задач, основываясь на индивидуальных способностях членов команды, чтобы найти в коллективе баланс между беспокойством и скукой.

3. Приспосабливайтесь или уходите! Новая роль менеджера

Что же значит руководить в стиле agile? Необходимо сосредоточится на сотрудничестве, доверии, обеспечивать прозрачность информации и создавать продуктивные и стабильные команды.

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

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

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

Чтобы добиться взаимного доверия между членами команды, руководитель сам должен им доверять! Возможно, этот совет очевиден, но всегда ли наши слова не расходятся с делом?

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

4. Мотивировать, а не демотивировать: аттестация, бонусы и премии.

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

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

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

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

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

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

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

Тогда что же мы измеряем и на чем должна быть основана наша система аттестации?

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

5. Создавайте договоры поставки, основанные на стоимости.

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

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

«Записывайте все неисполненные запросы по проекту, выявляя функции, которые надо разработать. Отдавайте приоритет функциям, имеющим ценность для бизнеса (например, по ожидаемому ROI)».

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

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

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

Такой подход удобен для клиента, так как допускает изменения. И клиент не попадает в ловушку высокозатратных изменений.

Сьюзерленд также напоминает, что договор Agile содержит статью «Деньги безвозмездно». Большое количество разработанных функций никогда не используются. Когда команда разработчиков выпускает программу поэтапно, реализуя высокоприоритетные и самые ценные для бизнеса функции в первую очередь,клиент может быть удовлетворен частично реализованным проектом. В этом случае у него будет возможность прекратить договор в любое время, выплатив 20% его оставшейся стоимости. Что позволит клиенту вернуть 80% оставшихся средств, не разрывая отношения с поставщиком.

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

6. Старайтесь не строить дощатых дорог.

Примерно сто шестьдесят лет назад в США повсеместно строились дощатые дороги. Технология такого строительства требовала значительных капиталовложений, но давала немедленный положительный результат. Однако такие дороги быстро разрушались; на их ремонт ежегодно уходило 20-30% от первичных затрат. В итоге от этого способа отказались. Является ли Agile долговечным решением или же «дощатой дорогой»?

Это не первая панацея, предлагаемая сообществу программистов. Языки высокого уровня, как говорилось еще пятьдесят лет назад на знаменитой лекции Тьюринга, сулили решение проблемы - «кризиса программного обеспечения» - но языки COBOL, Fortran и PL/1 усложнили работу программистов. Ветераны помнят волну структурированного программирования, 4GL (языки четвертого поколения), быстрое проектирование приложений, «программирование без программиста» и другие варианты решения всех наших проблем. Со временем эти «универсальные» решения заняли значительно более скромное место.

Водопадная модель разработки программ была «дощатой дорогой», призванной решить проблемы методами управления, заимствованными из других отраслей. Но их пригодность в случае разработки ПО была значительно переоценена, и последствия этой стратегической ошибки сказываются по сей день. В статье издания ACM Software Engineering Notes от апреля 1982 года написано: «Спорить с тем, что любая схема жизненного цикла, даже с вариациями, может быть применена к разработке всей системы, значит… оторваться от реальности».

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

7. Кому вы доверяете?

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

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

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

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

Мало того, что мы пристрастны, пристрастия наши еще и чрезвычайно сильны.

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

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

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

Мыслите нестандартно

Раз за разом компании внедряют систему Agile, не понимая ее философской особенности: система Agile – не свод инструкций, а мировоззрение. Если же вы воспринимаете технику Agile как набор предписаний, результат будет гораздо хуже, чем при водопадной модели разработки ПО. Вы дискредитируете идею Agile, потерпите неудачу в проекте, разрушите существующий (пусть и водопадный) механизм разработки ПО и сломите командный дух. Не вините методологию. Когда я слышу от менеджера: «Методология Agile предписывает нам на этом этапе проекта сделать следующее. Так идите и делайте», − я едва удерживаюсь, чтобы не треснуть этого «руководителя» по его пустой голове. Мыслите нестандартно! Вы же разрабатываете программное обеспечение!

Eugene Nizker. 7 Agile leadership lessons for the suits. CIO.com. 09/04/2008