Постигая agile – "Постигая Agile" скачать fb2, rtf, epub, pdf, txt книгу Грин Дженнифер

Содержание

Постигая Agile читать онлайн бесплатно на Lifeinbooks.ru

Постигая Agile

Дженнифер Грин

Эндрю Стеллман

Эта книга рассказывает о самых популярных agile-подходах – Scrum, XP (экстремальное программирование), Lean (бережливое программирование) и Канбан. Она познакомит вас с методами, работающими в повседневной жизни, а также с базовыми ценностями и принципами, которые помогут вашей команде полностью изменить свой подход к работе над проектами. Вы начнете лучше разбираться в конкретных agile-подходах и сможете сразу внедрить их на практике. А главное, вы поймете, как превратить группу сотрудников, добавляющих в свою работу Agile, в настоящую команду, которая действительно улучшает способ создания продукта и добивается выдающихся результатов.

На русском языке публикуется впервые.

Эндрю Стеллман, Дженнифер Грин

Постигая Agile. Ценности, принципы, методологии

Издано с разрешения O’Reilly Media, Inc.

Благодарим за помощь в подготовке издания компанию ScrumTrek в лице Алексея Пименова, Сергея и Александры Липчанских

Все права защищены.

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

Authorized Russian translation of the English edition of Learning Agile, ISBN 9781449331924. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls rights to publish and sell the same.

© Andrew Stellman and Jennifer Greene, 2015

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2017

* * *

Нише и Лизе, которые были очень терпеливы

Предисловие партнера

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

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

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

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

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

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

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

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

    Кирилл Семенихин,

    директор Университета Иннополис

Предисловие

Похоже, людям постоянно нужно о чем-то спорить. С кем была успешнее группа Van Halen – с Дэвидом Ли Ротом или с Сэмми Хагаром? Что лучше – пепси-кола или кока-кола? Кто, Леннон или Маккартни? Кошки или собаки? В начале развития agile-подхода спорили на тему «принципы или практики». Первые сторонники Agile выделили набор принципов, отраженный в Agile-манифесте, а практики разбрелись по многочисленным гибким подходам. Однако ожесточенные споры, должна ли команда сначала понять принципы гибкой разработки ПО или же приступить к выполнению практической части до их полного усвоения, продолжались.

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

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

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

Я впервые встретился с Эндрю и Дженнифер шесть лет назад, когда они брали у меня интервью для своей книги «Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга»[1 — Стеллман Э., Грин Дж. Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга. М.: Символ-Плюс, 2010.]. Хотя в названии ничего не говорится о гибкости, во многом отношении эта книга именно о ней. Команда, которая приняла принципы гибкой разработки, овладела необходимыми методиками и отказалась от тех практик, которые посчитала ненужными, – действительно идеальная команда. В книге «Постигая Agile» Эндрю и Дженнифер сосредоточивают свое внимание на гибких методах разработки ПО и трех наиболее распространенных сейчас вариантах этого подхода – Scrum, Extreme Programming и Канбан. Вы увидите, как их общие принципы легли в основу различных практик в рамках каждого подхода. Например, здесь вы найдете ответ на вопрос, почему в Scrum требуется ретроспективный анализ после рывка, а в экстремальном программировании – нет.

Присоединяясь к Эндрю и Дженнифер посредством изучения Scrum, Extreme Programming и Канбан, вы прочтете множество рассказов. И это логично: в конце концов, во многих agile-командах принято слушать истории пользователей системы, чтобы знать, что именно они желают от нее получить. Вы увидите команды, которые пытаются создать правильную функциональность, тратя слишком много времени на выполнение прошлогодних требований, ошибочно принимая за гибкий подход лишь иную форму командно-административного управления, и, будучи подвергнутыми переменам, не могут принять их и многое другое. Но более важно то, что вы узнаете, как эти команды преодолели проблемы. Сможете это и

Страница 2 из 14

вы.

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

    Майк Кон,

    автор книги «Scrum. Гибкая разработка ПО»[2 — Кон М. Scrum. Гибкая разработка ПО. М.: Вильямс, 2016.]

Глава 1. Обучая Agile

Самая важная установка, которая может быть сформирована, – это желание учиться.

    Джон Дьюи[3 — Джон Дьюи (1859–1952) – американский философ и педагог, представитель философского направления «прагматизм». Автор более 30 книг и 900 научных статей по философии, социологии, педагогике и другим дисциплинам. Прим. ред.]. Опыт и образование

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

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

• Agile-проекты обеспечивают высокое качество прогр

lifeinbooks.net

Постигая Agile (fb2) | Флибуста

Серенький волчок про Лысак: Характерник
Соглашусь с предыдущими комментариями. Печальное убожество на фоне суперкрутости и суперпатриотичности ГГ. При этом суперпатриотичность у ГГ специфичная, к российским властям вроде отношение отрицательное, а к неким атаманам-казакам — наше всё. А эти казаки в рос-турецкую войну бывало и на стороне турок воевали…
Куда-то автора несёт не туда. Или пригрозили не напечатать при заниженной патриотичности?
Не рекомендую.
Miamamasha про Оченков: Путь на Балканы
Весьма недурственно. Герой, конечно, и швец, и жнец, и молодец, каких поискать, но прогрессорством не злоупотребляет и матушку-историю вспять поворачивать не пытается. Финал немного странный, на мой взгляд. Непонятно зачем герой ввязывается в странную криминальную авантюру, совершенно нехарактерную для всего остального сюжета. Но в целом, книга достойная.
tt1000 про Мартин: Гра престолів
2Alia2007 >
А кто-то даже и издал в бумаге. А потом оцифровал.
И имя переводчицы знакомое.
Ну, блин, если кто не верит, что украинский — это другой язык, пусть попробует на нем хоть что-то прочитать и понять без словаря.
Это вообще нормально, что страна выпускает книги на государственном языке. Ненормально, что так мало, и так поздно.

А насчет числа читающих — ну вижу, цифра растет. Но есть проблема, даже несколько.
Во-первых, отсутствие привычки. Так мало издавали своего, столько везли из РФ, что у обычного человека просто навык утрачивается.
2. Эти переводческие школы — чёрт-те что. Бывает, навставляют слов устаревших, редкоупотребляемых, диалектизмов — для особой «красявости». Не для людей, не для определенной массовой ЦА, которая бы окупила тираж. Ну, филологи, может, и оценят, а обычный человек — плюнет и возьмет русский перевод.
3. Современные переводы вообще. Нынешние переводчики усиленно страдают херней. Они переусложняют и перегружают фразы, чтоб «кто на ком стоял» было непонятно, текст мертвый, суконный.

4. И бывают конкретные за**бы конкретного переводчика.


ausgabez про Богдашов: Уравнять шансы
> Достаточно убрать перешеек между Южной и Северной Америками и Гольфстрим как явление исчезнет.

Вы прослушали краткий пересказ влажных поцреотических мечтаний.


subaku про Халимендис: Попасть замуж
10% — полет нормальный, стандарт ЛФР-СИ. Похоже «до степени смешения» на «Подарок» Александры Плен http://flibusta.site/b/388461 (ну, не слово в слово, и есть разница в мелких деталях)
anupyld про Богдашов: Уравнять шансы
Никаких ИНОПЛАНЕТЯН для того, чтобы «нагнуть Омерику» не нужно. Достаточно убрать перешеек между Южной и Северной Америками и Гольфстрим как явление исчезнет. А климат в Европах и Америках станет как в Сибири. Вот тогда-то мы и увидим как борьба за торжество демократии во всем мире сменится борьбой за существование…
Ber про Богдашов: Уравнять шансы
очень жалко, что бОльшую часть книги афтар потратил на описание глупейшей Омерики.
А ещё жальче, что этот афтар признаёт, что этих пиндосов мы наклоним только если ИНОПЛАНЕТЯНЕ подарят нам разных технологий много и нахаляву.
Просто бред антиамериканца. Удивительно, что про Израиль ничего шпиономаньячного нету.
Все впечатления

flibusta.site

Книга Постигая Agile читать онлайн бесплатно, автор Эндрю Стеллман на Fictionbook

Издано с разрешения O’Reilly Media, Inc.

Благодарим за помощь в подготовке издания компанию ScrumTrek в лице Алексея Пименова, Сергея и Александры Липчанских

Все права защищены.

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

Authorized Russian translation of the English edition of Learning Agile, ISBN 9781449331924. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls rights to publish and sell the same.

© Andrew Stellman and Jennifer Greene, 2015

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2017

* * *

Нише и Лизе, которые были очень терпеливы


Предисловие партнера

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

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

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

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

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

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

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

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

Кирилл Семенихин,
директор Университета Иннополис

Предисловие

Похоже, людям постоянно нужно о чем-то спорить. С кем была успешнее группа Van Halen – с Дэвидом Ли Ротом или с Сэмми Хагаром? Что лучше – пепси-кола или кока-кола? Кто, Леннон или Маккартни? Кошки или собаки? В начале развития agile-подхода спорили на тему «принципы или практики». Первые сторонники Agile выделили набор принципов, отраженный в Agile-манифесте, а практики разбрелись по многочисленным гибким подходам. Однако ожесточенные споры, должна ли команда сначала понять принципы гибкой разработки ПО или же приступить к выполнению практической части до их полного усвоения, продолжались.

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

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

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

Я впервые встретился с Эндрю и Дженнифер шесть лет назад, когда они брали у меня интервью для своей книги «Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга». Хотя в названии ничего не говорится о гибкости, во многом отношении эта книга именно о ней. Команда, которая приняла принципы гибкой разработки, овладела необходимыми методиками и отказалась от тех практик, которые посчитала ненужными, – действительно идеальная команда. В книге «Постигая Agile» Эндрю и Дженнифер сосредоточивают свое внимание на гибких методах разработки ПО и трех наиболее распространенных сейчас вариантах этого подхода – Scrum, Extreme Programming и Канбан. Вы увидите, как их общие принципы легли в основу различных практик в рамках каждого подхода. Например, здесь вы найдете ответ на вопрос, почему в Scrum требуется ретроспективный анализ после рывка, а в экстремальном программировании – нет.

Присоединяясь к Эндрю и Дженнифер посредством изучения Scrum, Extreme Programming и Канбан, вы прочтете множество рассказов. И это логично: в конце концов, во многих agile-командах принято слушать истории пользователей системы, чтобы знать, что именно они желают от нее получить. Вы увидите команды, которые пытаются создать правильную функциональность, тратя слишком много времени на выполнение прошлогодних требований, ошибочно принимая за гибкий подход лишь иную форму командно-административного управления, и, будучи подвергнутыми переменам, не могут принять их и многое другое. Но более важно то, что вы узнаете, как эти команды преодолели проблемы. Сможете это и вы.

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

Майк Кон,
автор книги «Scrum. Гибкая разработка ПО»

Глава 1. Обучая Agile

Самая важная установка, которая может быть сформирована, – это желание учиться.

Джон Дьюи. Опыт и образование

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

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

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

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

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

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

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

вы можете при помощи Agile добиться подобных результатов?

Из этой книги вы узнаете о двух самых популярных agile-методологиях – Scrum и XP (экстремальном программировании). Вы прочтете также о Lean (бережливом программировании) и Канбан (Kanban), о том, как они помогают понять принципы создания программ и развить свои навыки. Вы увидите, что четыре школы Agile сосредоточивают внимание на разных отраслях разработки, но у них есть нечто общее: они направлены на изменение образа мыслей команды.

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

Что такое Agile?

Agile – это набор методов и методологий, которые помогают вашей команде эффективнее мыслить, работать и принимать решения.

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

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

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

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

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

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

Что же происходит? Может быть, разработчик ведет себя нерационально? Или менеджер проекта слишком требователен? Почему такая простая и общепринятая процедура порождает конфликт?

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

Рис. 1.1. Менеджер проекта, желающий, чтобы команда проводила ежедневные митинги, удивлен, что это нравится не всем

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

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

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

Но как быть, если у разработчика и менеджера проекта совсем иное мировоззрение? А каждый член команды будет относиться к ежедневному митингу совершенно по-другому?


Рис. 1.2. Кажется, у обоих есть веские основания для собственного мнения о ежедневных митингах. Как это скажется на проекте?

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

А что если разработчик почувствовал, что цель совещания – не только доложить обстановку, но и понять, как продвигается проект, ежедневно вместе искать возможности для оптимизации процесса? Тогда ежедневный митинг становится важным для него. Хороший разработчик, как правило, имеет собственное мнение не только о своем коде, но и об общем направлении проекта. Ежедневный митинг – это способ убедиться, что проект реализуется разумно и эффективно. Разработчик понимает, что в долгосрочной перспективе эта процедура принесет пользу его работе, поскольку все, что от него не зависит, тоже выполняется хорошо. Кроме того, он знает: если на совещании придется упомянуть о проблемах планирования, то все прислушаются к его мнению и работа над проектом пойдет еще лучше.


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

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

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

Кому следует прочитать эту книгу

Можно ли сказать, что одна из приведенных ниже ситуаций возникала у вас и вашей команды?

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

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

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

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

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

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

1. Стеллман Э., Грин Дж. Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга. М.: Символ-Плюс, 2010.2. Кон М. Scrum. Гибкая разработка ПО. М.: Вильямс, 2016.3. Джон Дьюи (1859–1952) – американский философ и педагог, представитель философского направления «прагматизм». Автор более 30 книг и 900 научных статей по философии, социологии, педагогике и другим дисциплинам. Прим. ред.

fictionbook.ru

Читать онлайн «Постигая Agile» автора Грин Дженнифер — RuLit

Эндрю Стеллман, Дженнифер Грин

Постигая Agile. Ценности, принципы, методологии

Издано с разрешения O’Reilly Media, Inc.

Благодарим за помощь в подготовке издания компанию ScrumTrek в лице Алексея Пименова, Сергея и Александры Липчанских

Все права защищены.

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

Authorized Russian translation of the English edition of Learning Agile, ISBN 9781449331924. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls rights to publish and sell the same.

© Andrew Stellman and Jennifer Greene, 2015

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2017

* * *

Нише и Лизе, которые были очень терпеливы

Предисловие партнера

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

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

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

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

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

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

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

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

Кирилл Семенихин,

директор Университета Иннополис

Похоже, людям постоянно нужно о чем-то спорить. С кем была успешнее группа Van Halen – с Дэвидом Ли Ротом или с Сэмми Хагаром? Что лучше – пепси-кола или кока-кола? Кто, Леннон или Маккартни? Кошки или собаки? В начале развития agile-подхода спорили на тему «принципы или практики». Первые сторонники Agile выделили набор принципов, отраженный в Agile-манифесте, а практики разбрелись по многочисленным гибким подходам. Однако ожесточенные споры, должна ли команда сначала понять принципы гибкой разработки ПО или же приступить к выполнению практической части до их полного усвоения, продолжались.

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

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

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

www.rulit.me

Эндрю Стеллман, Постигая Agile – читать онлайн – Альдебаран

Издано с разрешения O’Reilly Media, Inc.

Благодарим за помощь в подготовке издания компанию ScrumTrek в лице Алексея Пименова, Сергея и Александры Липчанских

Все права защищены.

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

Authorized Russian translation of the English edition of Learning Agile, ISBN 9781449331924. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls rights to publish and sell the same.

© Andrew Stellman and Jennifer Greene, 2015

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2017

* * *

Нише и Лизе, которые были очень терпеливы


Предисловие партнера

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

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

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

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

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

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

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

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

Кирилл Семенихин,
директор Университета Иннополис

Предисловие

Похоже, людям постоянно нужно о чем-то спорить. С кем была успешнее группа Van Halen – с Дэвидом Ли Ротом или с Сэмми Хагаром? Что лучше – пепси-кола или кока-кола? Кто, Леннон или Маккартни? Кошки или собаки? В начале развития agile-подхода спорили на тему «принципы или практики». Первые сторонники Agile выделили набор принципов, отраженный в Agile-манифесте, а практики разбрелись по многочисленным гибким подходам. Однако ожесточенные споры, должна ли команда сначала понять принципы гибкой разработки ПО или же приступить к выполнению практической части до их полного усвоения, продолжались.

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

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

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

Я впервые встретился с Эндрю и Дженнифер шесть лет назад, когда они брали у меня интервью для своей книги «Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга». Хотя в названии ничего не говорится о гибкости, во многом отношении эта книга именно о ней. Команда, которая приняла принципы гибкой разработки, овладела необходимыми методиками и отказалась от тех практик, которые посчитала ненужными, – действительно идеальная команда. В книге «Постигая Agile» Эндрю и Дженнифер сосредоточивают свое внимание на гибких методах разработки ПО и трех наиболее распространенных сейчас вариантах этого подхода – Scrum, Extreme Programming и Канбан. Вы увидите, как их общие принципы легли в основу различных практик в рамках каждого подхода. Например, здесь вы найдете ответ на вопрос, почему в Scrum требуется ретроспективный анализ после рывка, а в экстремальном программировании – нет.

Присоединяясь к Эндрю и Дженнифер посредством изучения Scrum, Extreme Programming и Канбан, вы прочтете множество рассказов. И это логично: в конце концов, во многих agile-командах принято слушать истории пользователей системы, чтобы знать, что именно они желают от нее получить. Вы увидите команды, которые пытаются создать правильную функциональность, тратя слишком много времени на выполнение прошлогодних требований, ошибочно принимая за гибкий подход лишь иную форму командно-административного управления, и, будучи подвергнутыми переменам, не могут принять их и многое другое. Но более важно то, что вы узнаете, как эти команды преодолели проблемы. Сможете это и вы.

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

Майк Кон,
автор книги «Scrum. Гибкая разработка ПО»

Глава 1. Обучая Agile

Самая важная установка, которая может быть сформирована, – это желание учиться.

Джон Дьюи. Опыт и образование

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

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

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

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

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

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

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

Из этой книги вы узнаете о двух самых популярных agile-методологиях – Scrum и XP (экстремальном программировании). Вы прочтете также о Lean (бережливом программировании) и Канбан (Kanban), о том, как они помогают понять принципы создания программ и развить свои навыки. Вы увидите, что четыре школы Agile сосредоточивают внимание на разных отраслях разработки, но у них есть нечто общее: они направлены на изменение образа мыслей команды.

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

Что такое Agile?

Agile – это набор методов и методологий, которые помогают вашей команде эффективнее мыслить, работать и принимать решения.

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

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

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

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

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

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

Что же происходит? Может быть, разработчик ведет себя нерационально? Или менеджер проекта слишком требователен? Почему такая простая и общепринятая процедура порождает конфликт?

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

Рис. 1.1. Менеджер проекта, желающий, чтобы команда проводила ежедневные митинги, удивлен, что это нравится не всем

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

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

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

Но как быть, если у разработчика и менеджера проекта совсем иное мировоззрение? А каждый член команды будет относиться к ежедневному митингу совершенно по-другому?


Рис. 1.2. Кажется, у обоих есть веские основания для собственного мнения о ежедневных митингах. Как это скажется на проекте?

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

А что если разработчик почувствовал, что цель совещания – не только доложить обстановку, но и понять, как продвигается проект, ежедневно вместе искать возможности для оптимизации процесса? Тогда ежедневный митинг становится важным для него. Хороший разработчик, как правило, имеет собственное мнение не только о своем коде, но и об общем направлении проекта. Ежедневный митинг – это способ убедиться, что проект реализуется разумно и эффективно. Разработчик понимает, что в долгосрочной перспективе эта процедура принесет пользу его работе, поскольку все, что от него не зависит, тоже выполняется хорошо. Кроме того, он знает: если на совещании придется упомянуть о проблемах планирования, то все прислушаются к его мнению и работа над проектом пойдет еще лучше.


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

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

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

Кому следует прочитать эту книгу

Можно ли сказать, что одна из приведенных ниже ситуаций возникала у вас и вашей команды?

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

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

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

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

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

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

aldebaran.ru

Читать книгу Постигая Agile Дженнифер Грин : онлайн чтение

Текущая страница: 1 (всего у книги 34 страниц) [доступный отрывок для чтения: 8 страниц]

Эндрю Стеллман, Дженнифер Грин
Постигая Agile. Ценности, принципы, методологии

Издано с разрешения O’Reilly Media, Inc.

Благодарим за помощь в подготовке издания компанию ScrumTrek в лице Алексея Пименова, Сергея и Александры Липчанских

Все права защищены.

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

Authorized Russian translation of the English edition of Learning Agile, ISBN 9781449331924. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls rights to publish and sell the same.

© Andrew Stellman and Jennifer Greene, 2015

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2017

* * *

Нише и Лизе, которые были очень терпеливы

Предисловие партнера

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

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

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

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

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

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

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

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

Кирилл Семенихин,

директор Университета Иннополис

Предисловие

Похоже, людям постоянно нужно о чем-то спорить. С кем была успешнее группа Van Halen – с Дэвидом Ли Ротом или с Сэмми Хагаром? Что лучше – пепси-кола или кока-кола? Кто, Леннон или Маккартни? Кошки или собаки? В начале развития agile-подхода спорили на тему «принципы или практики». Первые сторонники Agile выделили набор принципов, отраженный в Agile-манифесте, а практики разбрелись по многочисленным гибким подходам. Однако ожесточенные споры, должна ли команда сначала понять принципы гибкой разработки ПО или же приступить к выполнению практической части до их полного усвоения, продолжались.

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

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

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

Я впервые встретился с Эндрю и Дженнифер шесть лет назад, когда они брали у меня интервью для своей книги «Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга»1
  Стеллман Э., Грин Дж. Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга. М.: Символ-Плюс, 2010.

[Закрыть]. Хотя в названии ничего не говорится о гибкости, во многом отношении эта книга именно о ней. Команда, которая приняла принципы гибкой разработки, овладела необходимыми методиками и отказалась от тех практик, которые посчитала ненужными, – действительно идеальная команда. В книге «Постигая Agile» Эндрю и Дженнифер сосредоточивают свое внимание на гибких методах разработки ПО и трех наиболее распространенных сейчас вариантах этого подхода – Scrum, Extreme Programming и Канбан. Вы увидите, как их общие принципы легли в основу различных практик в рамках каждого подхода. Например, здесь вы найдете ответ на вопрос, почему в Scrum требуется ретроспективный анализ после рывка, а в экстремальном программировании – нет.

Присоединяясь к Эндрю и Дженнифер посредством изучения Scrum, Extreme Programming и Канбан, вы прочтете множество рассказов. И это логично: в конце концов, во многих agile-командах принято слушать истории пользователей системы, чтобы знать, что именно они желают от нее получить. Вы увидите команды, которые пытаются создать правильную функциональность, тратя слишком много времени на выполнение прошлогодних требований, ошибочно принимая за гибкий подход лишь иную форму командно-административного управления, и, будучи подвергнутыми переменам, не могут принять их и многое другое. Но более важно то, что вы узнаете, как эти команды преодолели проблемы. Сможете это и вы.

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

Майк Кон,

автор книги «Scrum. Гибкая разработка ПО»2
  Кон М. Scrum. Гибкая разработка ПО. М.: Вильямс, 2016.

[Закрыть]

Глава 1. Обучая Agile

Самая важная установка, которая может быть сформирована, – это желание учиться.

Джон Дьюи3
  Джон Дьюи (1859–1952) – американский философ и педагог, представитель философского направления «прагматизм». Автор более 30 книг и 900 научных статей по философии, социологии, педагогике и другим дисциплинам. Прим. ред.

[Закрыть]

. Опыт и образование

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

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

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

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

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

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

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

Из этой книги вы узнаете о двух самых популярных agile-методологиях – Scrum и XP (экстремальном программировании). Вы прочтете также о Lean (бережливом программировании) и Канбан (Kanban), о том, как они помогают понять принципы создания программ и развить свои навыки. Вы увидите, что четыре школы Agile сосредоточивают внимание на разных отраслях разработки, но у них есть нечто общее: они направлены на изменение образа мыслей команды.

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

Что такое Agile?

Agile – это набор методов и методологий, которые помогают вашей команде эффективнее мыслить, работать и принимать решения.

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

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

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

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

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

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

Что же происходит? Может быть, разработчик ведет себя нерационально? Или менеджер проекта слишком требователен? Почему такая простая и общепринятая процедура порождает конфликт?

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


Рис. 1.1. Менеджер проекта, желающий, чтобы команда проводила ежедневные митинги, удивлен, что это нравится не всем

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

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

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

Но как быть, если у разработчика и менеджера проекта совсем иное мировоззрение? А каждый член команды будет относиться к ежедневному митингу совершенно по-другому?


Рис. 1.2. Кажется, у обоих есть веские основания для собственного мнения о ежедневных митингах. Как это скажется на проекте?

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

А что если разработчик почувствовал, что цель совещания – не только доложить обстановку, но и понять, как продвигается проект, ежедневно вместе искать возможности для оптимизации процесса? Тогда ежедневный митинг становится важным для него. Хороший разработчик, как правило, имеет собственное мнение не только о своем коде, но и об общем направлении проекта. Ежедневный митинг – это способ убедиться, что проект реализуется разумно и эффективно. Разработчик понимает, что в долгосрочной перспективе эта процедура принесет пользу его работе, поскольку все, что от него не зависит, тоже выполняется хорошо. Кроме того, он знает: если на совещании придется упомянуть о проблемах планирования, то все прислушаются к его мнению и работа над проектом пойдет еще лучше.


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

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

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

Кому следует прочитать эту книгу

Можно ли сказать, что одна из приведенных ниже ситуаций возникала у вас и вашей команды?

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

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

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

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

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

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

iknigi.net

Эндрю Стеллман, Постигая Agile – читать онлайн полностью – ЛитРес

Издано с разрешения O’Reilly Media, Inc.

Благодарим за помощь в подготовке издания компанию ScrumTrek в лице Алексея Пименова, Сергея и Александры Липчанских

Все права защищены.

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

Authorized Russian translation of the English edition of Learning Agile, ISBN 9781449331924. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls rights to publish and sell the same.

© Andrew Stellman and Jennifer Greene, 2015

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2017

* * *

Нише и Лизе, которые были очень терпеливы


Предисловие партнера

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

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

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

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

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

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

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

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

Кирилл Семенихин,
директор Университета Иннополис

Предисловие

Похоже, людям постоянно нужно о чем-то спорить. С кем была успешнее группа Van Halen – с Дэвидом Ли Ротом или с Сэмми Хагаром? Что лучше – пепси-кола или кока-кола? Кто, Леннон или Маккартни? Кошки или собаки? В начале развития agile-подхода спорили на тему «принципы или практики». Первые сторонники Agile выделили набор принципов, отраженный в Agile-манифесте, а практики разбрелись по многочисленным гибким подходам. Однако ожесточенные споры, должна ли команда сначала понять принципы гибкой разработки ПО или же приступить к выполнению практической части до их полного усвоения, продолжались.

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

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

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

Я впервые встретился с Эндрю и Дженнифер шесть лет назад, когда они брали у меня интервью для своей книги «Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга»[1]. Хотя в названии ничего не говорится о гибкости, во многом отношении эта книга именно о ней. Команда, которая приняла принципы гибкой разработки, овладела необходимыми методиками и отказалась от тех практик, которые посчитала ненужными, – действительно идеальная команда. В книге «Постигая Agile» Эндрю и Дженнифер сосредоточивают свое внимание на гибких методах разработки ПО и трех наиболее распространенных сейчас вариантах этого подхода – Scrum, Extreme Programming и Канбан. Вы увидите, как их общие принципы легли в основу различных практик в рамках каждого подхода. Например, здесь вы найдете ответ на вопрос, почему в Scrum требуется ретроспективный анализ после рывка, а в экстремальном программировании – нет.

Присоединяясь к Эндрю и Дженнифер посредством изучения Scrum, Extreme Programming и Канбан, вы прочтете множество рассказов. И это логично: в конце концов, во многих agile-командах принято слушать истории пользователей системы, чтобы знать, что именно они желают от нее получить. Вы увидите команды, которые пытаются создать правильную функциональность, тратя слишком много времени на выполнение прошлогодних требований, ошибочно принимая за гибкий подход лишь иную форму командно-административного управления, и, будучи подвергнутыми переменам, не могут принять их и многое другое. Но более важно то, что вы узнаете, как эти команды преодолели проблемы. Сможете это и вы.

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

Майк Кон,
автор книги «Scrum. Гибкая разработка ПО»[2]

Глава 1. Обучая Agile

Самая важная установка, которая может быть сформирована, – это желание учиться.

Джон Дьюи[3]. Опыт и образование

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

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

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

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

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

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

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

Из этой книги вы узнаете о двух самых популярных agile-методологиях – Scrum и XP (экстремальном программировании). Вы прочтете также о Lean (бережливом программировании) и Канбан (Kanban), о том, как они помогают понять принципы создания программ и развить свои навыки. Вы увидите, что четыре школы Agile сосредоточивают внимание на разных отраслях разработки, но у них есть нечто общее: они направлены на изменение образа мыслей команды.

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

Что такое Agile?

Agile – это набор методов и методологий, которые помогают вашей команде эффективнее мыслить, работать и принимать решения.

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

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

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

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

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

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

Что же происходит? Может быть, разработчик ведет себя нерационально? Или менеджер проекта слишком требователен? Почему такая простая и общепринятая процедура порождает конфликт?

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

Рис. 1.1. Менеджер проекта, желающий, чтобы команда проводила ежедневные митинги, удивлен, что это нравится не всем

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

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

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

Но как быть, если у разработчика и менеджера проекта совсем иное мировоззрение? А каждый член команды будет относиться к ежедневному митингу совершенно по-другому?


Рис. 1.2. Кажется, у обоих есть веские основания для собственного мнения о ежедневных митингах. Как это скажется на проекте?

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

А что если разработчик почувствовал, что цель совещания – не только доложить обстановку, но и понять, как продвигается проект, ежедневно вместе искать возможности для оптимизации процесса? Тогда ежедневный митинг становится важным для него. Хороший разработчик, как правило, имеет собственное мнение не только о своем коде, но и об общем направлении проекта. Ежедневный митинг – это способ убедиться, что проект реализуется разумно и эффективно. Разработчик понимает, что в долгосрочной перспективе эта процедура принесет пользу его работе, поскольку все, что от него не зависит, тоже выполняется хорошо. Кроме того, он знает: если на совещании придется упомянуть о проблемах планирования, то все прислушаются к его мнению и работа над проектом пойдет еще лучше.


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

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

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

Кому следует прочитать эту книгу

Можно ли сказать, что одна из приведенных ниже ситуаций возникала у вас и вашей команды?

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

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

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

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

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

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

www.litres.ru

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *