читаем и качаем книги по гибкой методологии —

Несколько книг по Agile и Scrum, которые будут вам полезны.

Внедрение Scrum для компаний, которым нужны быстрые процессы.

Книги, переведенные на русский:

Асхат Уразбаев, Никита Филиппов
Ag;)eChecklist Очень краткое описание практик гибкой разработки
https://www.pmoffice.by/wp-content/uploads/2016/07/agilechecklist20.pdf

Хенрик Книберг
Scrum XP записки с передовой. Как мы делаем Scrum
https://www.pmoffice.by/wp-content/uploads/2016/07/Scrum-XP-zapiski-s-peredovoy.pdf

Разрабатывается и поддерживается Кеном Швабером и Джеффом Сазерлендом
Исчерпывающее руководство по Скраму: Правила Игры
https://www.pmoffice.by/wp-content/uploads/2016/07/Scrum-Guide-RUS.pdf

Джефф Сазерленд “Scrum. Революционный метод управления проектами”http://www.ozon.ru/context/detail/id/34376940/

Алексей Кривитский “Быстрый старт в agile ретроспективы”
https://leanpub.com/agile-retrospective-kickstarter-ru

Джил Конрат: Гибкие продажи. Как продавать в эпоху перемен
http://www.labirint.ru/books/482675/

Эрик Рис “Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели”
http://www.ozon.ru/context/detail/id/18322266/

Синди Альварес “Продукт, который купят. Метод Lean Customer Development” –http://www.ozon.ru/context/detail/id/34432645/

Майкл Томас Вейдер “Инструменты бережливого производства. Мини-руководство по внедрению методик бережливого производства”
http://www.ozon.ru/context/detail/id/32218895/

Майкл Томас Вейдер “Инструменты бережливого производства II. Карманное руководство по практике применения Lean”
http://www.ozon.ru/context/detail/id/34350832/

Книги на английском:

Roland Smart “The Agile marketer”
http://www.ozon.ru/context/detail/id/136235544/

Scott Brinker “Hacking Marketing: Agile Practices to Make Marketing Smarter, Faster, and More Innovative”
https://www.amazon.com/Hacking-Marketing-Practices-Smarter-Innovative/dp/1119183170/

Anthony Freeling “Agile Marketing”
https://www.amazon.com/Agile-Marketing-Anthony-Freeling/dp/1456491091/

David Meerman Scott “The New Rules of Sales and Service: How to Use Agile Selling, Real-Time Customer Engagement, Big Data, Content, and Storytelling to Grow Your Business”
https://www.amazon.com/New-Rules-Sales-Service-Storytelling/dp/1118827856/

Отзывы о книге Scrum. Революционный метод управления проектами

Рецензию собирался писать, но все никак не было повода, а тут игра. Что называется, в точку.

Узнал я об этой книге после семинара, посвященного техникам Agile; в нем акцент ставился на Scrum. Что ж, должен сказать, «цепануло так цепануло». Для меня открылся новый мир организации бизнеса, проектов, команд. Порекомендовали начать с этой книги и, должен сказать, рекомендация оказалась полезная.

До сих пор в моей голове был только один способ организации дела (точнее, альтернатива-то была, но вот вживую или даже в примере я ее никогда не видел). Для меня управление всегда означало распределение власти, контроль и жесткую иерархию. Даже новомодные постиндустриальные принципы Toyota содержали принципы «власти — подчинения». И тут открылось… Оно!
Мало того, что альтернатива существует и работает, так еще и показала в действии всю свою эффективность — децентрализация оказалась в тренде.
Конечно, я быстренько прикупил книгу, которая еще раз сыграла на струнах моих внутренних устремлений — черно-белый шрифт на красной обложке, так еще и «Революционный» метод! Революционный. Да, то, что нужно!

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

Избавьтесь от званий и титулов … Дайте людям свободу делать то, что они считают правильным, и возможность нести за это ответственность. Результаты вас поразят.

Диаграммы Ганта производят глубокое впечатление. Существует лишь единственная проблема: они все неправильны — без исключения

Люди счастливы не потому, что успешны. Они преуспевают, потому что счастливы

Не ищите дурных людей, ищите вредные системы — системы, которые стимулируют ненадлежащее поведение и вознаграждают за плохую работу

Следовать плану глупо!

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

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

Надеюсь, что и российский бизнес, и некоммерческие учреждения к этому скоро придут.

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

Из «минусов» книги:
Вся технология изложена на пяти страницах книги. Остальное — обоснование, философия, история утверждения и кейсы. Много воды. Зато вся вода — от основателя метода.

ТОП-100 Аджайл книг всех времен (на конец 2013 года) / ScrumTrek corporate blog / Habr

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

Методику составления рейтинга мы позаимствовали у Jurgen Appelo. Алгоритм подсчёта базируется на пяти различных критериях: количество отзывов Amazon, число отзывов GoodReads, средняя оценка Amazon, средняя оценка GoodReads, а количество дней, прошедших с первой публикации. Это означает, что этот список показывает вам смесь из самых популярных, лучших по оценкам, и (относительно) новейший книги в этой категории.

Данный список книг мы попросили прокомментировать двух экспертов:

Борис Вольфсон. Технический директор компании HeadHunter.

Андрей Ребров. Agile Engineering Coach компании ScrumTrek.

1. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (2013)
Gene Kim, Kevin Behr, George Spafford

Андрей Ребров: Тема DevOps активно обсуждает в русскоязычном сообществе последныие пару лет: есть группы, конференции, создаются целые отделы devops и так далее. И на этом пути очень важно не наделать ошибок, чтобы DevOps не приняли за новую религию. Один из способов это избежать — правильно понимать, что это такое, и помочь в этом может книги The Phoenix Project. Данная книга интересна еще и потому, что является почти художественной – у нее есть герои. завязка, интриги и конечно счастливый финал. Эта книга о том, как перейти из состояния хаоса в производстве к понятной системе поставок, выстроить инженерную культуру и начать доверять друг другу. В этой книге очень понятным языком описаны массы ситуаций, с которыми мы, разработчики и сисадмины, постоянно сталкиваемся, например, шаловливые руки программистов или простои из-за менеджерского бюрократизма. Ищите способы, как это побороть? Тогда эта книга для вас!

2. Essential Scrum: A Practical Guide to the Most Popular Agile Process (2012)
Kenneth S. Rubin

3. Running Lean: Iterate from Plan A to a Plan That Works (2012)
Ash Maurya

4. Impact Mapping: Making a Big Impact with Software Products and Projects (2012)
Gojko Adzic

5. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (2011)
Eric Ries

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

6. Lean Analytics: Use Data to Build a Better Startup Faster (2013)
Alistair Croll, Benjamin Yoskovitz

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

7. Succeeding with Agile: Software Development Using Scrum (2009)
Mike Cohn

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

Андрей Ребров: Все авторы книжек по аджайл стремятся уйти от догматизма (в agile это считается ересью) и в итоге теряют практичность. Ну правда, если постоянно делать оговорки в стиле “и так бывает и вот так тоже можно” – возникает вопрос – а как надо-то? Майк Кон для себя этот вопрос однозначно решил в пользу практичности. Лично мне это нравится, так что очень рекомендую почитать все книги Майка. Самая последняя его книга содержит годы его размышлений, она глубокая, как космос и неисчерпаемая как атом.

8. Commitment (2013)
Olav Maassen, Chris Matts, Chris Geary

9. The Scrum Field Guide: Practical Advice for Your First Year (2012)
Mitch Lacey

10. Agile Software Development, Principles, Patterns, and Practices (2002)
Robert C. Martin

11. Specification by Example: How Successful Teams Deliver the Right Software (2011)
Gojko Adzic

12. Agile Estimating and Planning (2005)
Mike Cohn

Андрей Ребров: Ну вы уже поняли, я фанат Майка Кона (до тех пор, пока Jeff Patton не напишет свою книгу!). Хотите знать, как закончить проект в срок и при этом работать по Agile? Книга об оценке и планировании от того же Майка нашего Кона.

13. The Agile Samurai: How Agile Masters Deliver Great Software (2010)
Jonathan Rasmusson

14. Clean Code: A Handbook of Agile Software Craftsmanship

(2008)
Robert C. Martin

15. Refactoring: Improving the Design of Existing Code (1999)
Martin Fowler, et al.

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

16. The Art of Unit Testing: With Examples in .Net (2009)
Roy Osherove

17. Working Effectively with Legacy Code (2004)
Michael Feathers

18. The Lean Entrepreneur: How Visionaries Create Products, Innovate with New Ventures, and Disrupt Markets (2013)
Brant Cooper, Patrick Vlaskovits

19. The Pragmatic Programmer: From Journeyman to Master

(1999)
Andrew Hunt, David Thomas

20. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (2010)
Jez Humble, David Farley

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

21. User Stories Applied: For Agile Software Development (2004)
Mike Cohn

Андрей Ребров: Еще одна книжка от Майка, на этот раз об управлении требованиями и работе с заказчиками с использованием User Stories. Как всегда, очень практично и интересно. Замечательное чтиво! Если вы аналитик, поставьте ее рядом с Effective Use Cases by Alistair Cockburn

22. Scrum and XP from the Trenches (2007)
Henrik Kniberg

Андрей Ребров: Ставшая уже культовой книга знаменитого Хенрика Книберга о его опыте внедрения Agile. Написано очень ясно, интересно и вдохновляюще. Книга небольшая и переведена на русский язык украинскими камрадами.

Борис Вольфсон: Книга, которая для многих стала первым знакомством с Agile. Но хочу отметить, что на данный момент достаточно много информации в ней устарело.

23. The Clean Coder: A Code of Conduct for Professional Programmers (2011)
Robert C. Martin

24. The Elements of Scrum (2011)
Chris Sims, Hillary Louise Johnson

25. Lean UX: Applying Lean Principles to Improve User Experience (2013)
Jeff Gothelf

26. Implementing Domain-Driven Design (2013)
Vaughn Vernon

27. Growing Object-Oriented Software, Guided by Tests (2009)
Steve Freeman, Nat Pryce

28. Domain-Driven Design: Tackling Complexity in the Heart of Software (2003)

Eric Evans

29. Lean from the Trenches: Managing Large-Scale Projects with Kanban (2011)
Henrik Kniberg

30. Kanban: Successful Evolutionary Change for Your Technology Business (2010)
David J. Anderson

31. The Principles of Product Development Flow: Second Generation Lean Product Development (2009)
Donald G. Reinertsen

32. Management 3.0: Leading Agile Developers, Developing Agile Leaders (2011)
Jurgen Appeal

33. Lean Software Development: An Agile Toolkit (2003)
Mary Poppendieck, Tom Poppendieck

34. Making Things Happen: Mastering Project Management (2008)
Scott Berkun

35. How to Change the World: Change Management 3.0 (2012)
Jurgen Appelo

36. The Art of Agile Development (2007)
James Shore, Shane Warden

37. Scrum: a Breathtakingly Brief and Agile Introduction

(2012)
Chris Sims, Hillary Louise Johnson

38. Innovation Games: Creating Breakthrough Products Through Collaborative Play (2006)
Luke Hohmann

39. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (2010)
Dean Leffingwell

40. Implementing Lean Software Development: From Concept to Cash (2006)
Mary Poppendieck, Tom Poppendieck

Андрей Ребров: Самая последняя книжка по Лин от авторов методологии Lean Software Development. Изложение в принципе неплохое, однако не свободное от некоторых недостатков. Мне кажется, оно слишком сильно напирает на разработку ПО и слишком мало говорит о применении Лин как такового. Однако она вроде как первоисточник – как минимум, полистать нужно!

41. The Professional ScrumMaster’s Handbook (2013)
Stacia Viscardi

42. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition

(2010)
Lyssa Adkins

43. Managing the Design Factory (1997)
Donald G. Reinertsen

44. Agile Principles, Patterns, and Practices in C# (2006)
Robert C. Martin, Micah Martin

45. Getting Results the Agile Way: A Personal Results System for Work and Life (2010)
J.D. Meier

46. UX for Lean Startups: Faster, Smarter User Experience Research and Design (2013)
Laura Klein

47. Personal Kanban: Mapping Work | Navigating Life (2011)
Jim Benson, Tonianne DeMaria Barry

48. Agile Coaching (2009)
Rachel Davies, Liz Sedley

49. Test Driven Development for Embedded C (2011)
James W. Greening

50. 30 Days to Better Agile: Effective strategies for getting results Fast using Scrum (2012)
Angela Druckman

51. xUnit Test Patterns: Refactoring Test Code (2007)
Gerard Meszaros

52. The Concise Executive Guide to Agile (2010)
Israel Gat

53. Behind Closed Doors: Secrets of Great Management (2005)
Johanna Rothman, Esther Derby

54. Writing Effective Use Cases (2000)
Alistair Cockburn

55. Leading Lean Software Development: Results Are not the Point (2009)
Mary Poppendieck, Tom Poppendieck

56. Practices of an Agile Developer: Working in the Real World (2005)
Venkat Subramaniam, Andy Hunt

57. Agile Management (2012)
Ángel Medinilla

58. Crystal Clear: A Human-Powered Methodology for Small Teams (2004)
Alistair Cockburn

59. Agile Game Development with Scrum (2010)
Clinton Keith

60. The Culture Game: Tools for the Agile Manager (202)
Dan Mezick

61. Extreme Programming Explained: Embrace Change (multiple editions) (1999)
Kent Beck, Cynthia Andres

62. The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century (2010)
Stephen Denning

63. Agile and Iterative Development: A Manager’s Guide (2003)
Craig Larman

64. The People’s Scrum: Agile Ideas for Revolutionary Transformation (2013)
Tobia
2013s Mayer

65. Agile Project Management: Creating Innovative Products (2nd Edition) (2009)
Jim Highsmith

66. Refactoring to Patterns (2004)
Joshua Kerievsky

67. Discover to Deliver: Agile Product Planning and Analysis (2012)
Ellen Gottesdiener, Mary Gorman

68. Agile in a Flash: Speed-Learning Agile Software Development (2011)
Jeff Langr, Tim Ottinger

69. Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects (2009)
Johanna Rothman

70. Agile Testing: A Practical Guide for Testers and Agile Teams (2009)
Lisa Crispin, Janet Gregory

Андрей Ребров: Подробно не буду писать, это просто классика и абсолютный маст для тестировщика.

71. Scrum Mastery: From Good To Great Servant-Leadership (2013)
Geoff Watts

72. Manage It!: Your Guide to Modern, Pragmatic Project Management (2007)
Johanna Rothman

73. Agile Retrospectives: Making Good Teams Great (2006)
Esther Derby, Diana Larsen

Андрей Ребров: Книга о том, как проводить ретроспективы. Весьма рекомендую двум категориям граждан: тем, кто не умеет их проводить и тем, кто за годы проведения ретро исчерпал свои проблемы и уже не знает как вернуть им полезность (и драйв!). Написана она фасилитаторами (фасилитация – это такая наука о проведении митингов), так что может показаться немного излишней в плане набора ритуальных действий, но там реально много интересных идей о проведении ретроспектив!

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

74. The Human Side of Agile — How to Help Your Team Deliver (2012)
Gil Broza

75. Liftoff: Launching Agile Teams & Projects (2011)
Diana Larsen, Ainsley Nies

76. Software in 30 Days: How Agile Managers Beat the Odds… (2012)
Ken Schwaber, Jeff Sutherland

77. Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (2008)
Craig Larman, Bas Vodde

Андрей Ребров: читал множество книжек про масштабирование разработки, ничего идеального на эту тему не нашел. Однако пока ничего лучше книги Лармана не видел. Если у вас работает больше одной команды и вам надо синхронизировать их работу – почитайте обязательно. Заодно увидите, как реально применяется Лин на конкретных примерах.

78. Agile Project Management with Scrum (2004)
Ken Schwaber

79. Organizational Patterns of Agile Software Development (2004)
James O. Coplien, Neil B. Harrison

80. Agile Project Management For Dummies (2012)
Mark C. Layton

81. The Productive Programmer (2008)
Neal Ford

82. Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing (2009)
Gojko Adzic

83. Requirements by Collaboration (2002)
Ellen Gottesdiener

84. Test Driven Development: By Example (2002)
Kent Beck

85. Agile Software Development with Scrum (2001)
Ken Schwaber, Mike Beedle

86. Agile Software Development with Distributed Teams (2010)
Jutta Eckstein

87. Continuous Integration: Improving Software Quality and Reducing Risk (2007)
Paul M. Duvall, Steve Matyas, Andrew Glover

88. Enterprise-Scale Agile Software Development (2009)
James Schiel

89. Lessons in Agile Management: On the Road to Kanban (2012)
David J. Anderson

90. Applied Software Project Management (2005)
Andrew Stellman, Jennifer Greene

91. Exploring Scrum: the Fundamentals: People, Product, and Practices (2011)
Dan Rawsthorne, Doug Shimp

92. Collaboration Explained: Facilitation Skills for Software Project Leaders (2006)
Jean Tabaka

93. Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams (2010)
Greg Cohen

94. Changing Software Development: Learning to Become Agile (2008)
Allan Kelly

95. Get Agile!: Scrum for UX, Design & Development (2013)
Pieter Jongerius

96. Scrum Product Ownership: Balancing Value From the Inside Out (multiple editions) (2009)
Robert Galen

97. Agile Product Management with Scrum: Creating Products that Customers Love (2010)
Roman Pichler

98. Ship it! A Practical Guide to Successful Software Projects (2005)
Jared Richardson, William A. Gwaltney

99. Scaling Software Agility: Best Practices for Large Enterprises (2007)
Dean Leffingwell

100. Stand Back and Deliver: Accelerating Business Agility (2009)
Pollyanna Pixton, Niel Nickolaisen, Todd Little, Kent McDonald

Шесть «сакральных» книг для Скрам-мастера

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

Agile Project Management With Scrum

Классика жанра от создателя Скрама Кена Швабера, одна из первых книг по Скраму и однозначно культовая книга для любого Скрам-мастера. Книга, которую растащили на цитаты. Легко читается, минимум теории. Большая часть книги — кейсы и ситуации, в которые попадал Кен в качестве Скрам-мастера. Книга представляет собой идеальное пособие для новичков в профессии, они демонстрирует образ мышления самого создателя Скрама. Что может быть более ценного?

The Professional ScrumMaster’s Handbook

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

The Scrum Field Guide

Готовы основательно и глубоко взяться за Скрам? Пора переходить к этой книге. В отличии от предыдущей, она глубоко описывать принципы, тактики и приемы, которые может использовать Скрам-мастер. Большой плюс книги — фокус на инженерной культуре, в ней обширно обсуждается парное программирование, автоматические тесты и т.д. Из минусов я бы отметил чрезмерный фокус на velocity (недаром Джефф Сазерлэнд ведь писал предисловие) и продуктивность команд. Но для фанатов расчетов capacity и всевозможных velocity это просто клондайк! Автор дает практические советы по работе с возникающими багами в Спринте, распределенными командами, декомпозиции “историй”, описывает конкретные шаги для создания DoD. Всего не перечислить. Минус книги — ее объем, помню, что я устал ее читать и бегло прошелся по завершающим страницам. Очень рекомендую!

The Great ScrumMaster

Самая “свежая” из книг в данном обзоре и, пожалуй, самая простая для чтения. Представляет собой компиляцию уже известных моделей, подходов, которые можно найти в других местах, но в этом и заключается ее прелесть. Небольшая по объему, легко читается. Создана для проглатывания за пару дней. Фокусируется на soft skills для Скрам-мастера: 5 дисфункций команды, командный и системный коучинг, позитивная психология, фасилитация и т.д.

Coaching Agile Teams

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

Scrum Mastery

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

В завершении.

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

Scrum ON!

Книга Scrum читать онлайн бесплатно, автор Джефф Сазерленд на Fictionbook

Jeff Sutherland

SCRUM

The Art of Doing Twice the Work in Half the Time

Издано с разрешения Scrum, Inc. c/o The Ross Yoon Agency

Правовую поддержку издательства обеспечивает юридическая фирма «Вегас-Лекс»

© Jeff Sutherland and Scrum, Inc., 2014

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

* * *

Эту книгу хорошо дополняют:

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

Вадим Богданов

Бизнес-процессы

Владимир Репин

Deadline

Том Демарко

Предисловие партнера к российскому изданию

Книга, которую вы держите в руках, написана одним из авторов Scrum. Он рассказывает о предпосылках создания методологии и основных ее аспектах.

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

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

Основная характеристика Scrum – гибкость. Данный подход позволяет оперативно реагировать на изменения в требованиях заказчика и быстро адаптировать продукт к ним.

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

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

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

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

Ульяна Самолова,

президент Samolov Group

Введение

Почему Scrum?

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

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

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

С момента своего возникновения концепция Scrum легла в основу проектирования новых программных продуктов для технологических отраслей. Однако, снискав признание и успех в Кремниевой долине среди руководителей проектов по созданию программного обеспечения и нового оборудования, в общей деловой практике Scrum остается еще малоизвестной методологией. Именно ради этого делового сообщества – людей, не связанных напрямую с миром высоких технологий, – я задумал написать книгу, в которой собираюсь раскрыть и разъяснить преимущества Scrum как системы управления в бизнесе. Я расскажу о первоистоках методологии Scrum: производственной системе компании Toyota и концепции, созданной для задач боевой авиации, – цикле OODA^{. Рассмотрю вопрос, почему организация проектов силами небольших команд является более эффективным способом работы. Остановлюсь на следующих моментах: как правильно расставлять приоритеты в работе над проектом; как организовывать спринты, то есть короткие этапы разработки проекта (от одной недели до одного месяца), – причем делать это таким образом, чтобы каждый член команды отвечал за свою часть работы, а результат последующего этапа вбирал в себя функции проекта, реализованные на предыдущих этапах; как проводить ежедневные короткие обсуждения задач проекта, чтобы быть не только в курсе сделанного, но и тех трудностей, с которыми неизбежно приходится сталкиваться. Кроме того, я объясню, как методология Scrum объединяет концепцию непрерывного совершенствования и концепцию реализации продукта с минимальным функционалом, что позволяет не ждать завершения всех работ, а оперативно удовлетворять требования заказчика на каждом этапе проекта. Вы узнаете, что мы применяли Scrum при проектировании абсолютно всего: от создания дешевых автомобилей с расходом топлива четыре литра на сто пятьдесят километров до разработки современных, на уровне XXI века, баз данных ФБР.}

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

Джефф Сазерленд

Глава первая
Привычное мироустройство дает трещину

Джефф Джонсон был заранее уверен, что денек выдастся нелегким. Тогда, 3 марта 2010 года, Федеральное бюро расследований решило приостановить свой крупномасштабный и многообещающий план модернизации управления информацией. Воплотив его, ФБР смогло бы предотвращать события, подобные 11 сентября. Однако разработка проекта потерпела фиаско – одно из самых грандиозных, которое знавала история развития программного обеспечения. В Бюро пытались обновить свою компьютерную систему уже более десяти лет, и похоже, их постигла катастрофа. Опять провал.

Но на сей раз – с детищем Джеффа Джонсона – все пойдет иначе.

Семь месяцев назад он появился в ФБР и заинтересовал своим предложением директора по информационному обеспечению Чеда Фулгэма – когда-то они вместе работали в банке Lehman Brothers. Джеффа назначили помощником начальника управления информационных разработок и дали офис на верхнем этаже здания имени Эдгара Гувера, то есть в штаб-квартире ФБР, расположенной в центре Вашингтона, округ Колумбия. Из его просторного кабинета открывался вид на монумент Вашингтона. Вряд ли Джефф предполагал, что ближайшие два года ему предстоит провести в бетонном подвале, в каморке без окон, где он будет пытаться исправить проект, который, по общему мнению, считался безнадежным.

Джефф Джонсон и его босс сочли правильным заявить о поражении и закрыть программу, работа над которой длилась без малого десять лет и обошлась ФБР в сотни миллионов долларов. Настал момент признать, что больший смысл имело бы забрать ее себе и трудиться над ней самостоятельно внутри отдела. «Решение далось нам нелегко, – сказал Джефф. – Но проект требовалось сделать, и сделать хорошо».

 

Столь долгожданная электронная система была призвана помочь ФБР вступить в новую эпоху – эпоху Facebook, Twitter, Amazon и Google. Шел 2010 год, а большинство документации хранилось в бумажном виде. Программная система, когда-то созданная для нужд Бюро, называлась «Автоматизированная поддержка следственных дел» (Automated Case Support, ACS) и работала на гигантских ЭВМ – последнем слове техники далеких восьмидесятых. Многие спецагенты предпочитали ею не пользоваться. Слишком она была громоздкой и медленной для эпохи терактов и стремительно перемещающихся преступников.

Когда агенту ФБР требовалось что-то сделать – а фактически все что угодно: заплатить осведомителю, выследить террориста, составить досье на банковского грабителя, – его работа мало чем отличалась от аналогичной тридцатилетней давности. Вот как описывает эту процедуру Джонсон: «Вы составляли в текстовом редакторе подробную записку и распечатывали ее в трех экземплярах. Одну копию посылали на утверждение, и она проходила всю санкционную цепочку до самого верха. Вторую отправляли в местный архив на случай, если первая потеряется. Ну а с третьей вы садились, брали красную ручку – да-да, я не шучу, красную ручку – и обводили ключевые слова для занесения в базу данных. Вы индексировали собственный отчет».

Итак, если ваш запрос одобряли, то первый экземпляр пронумеровывали и спускали вниз. Просто номер, проставленный на листе бумаги, – именно так в ФБР осуществлялось управление документами по расследуемым делам. Система была вопиюще архаичной и фантастически уязвимой. В том числе и из-за нее на Бюро возложили вину, что его подразделения не сумели связать все сведения воедино и обнаружить многочисленных активистов «Аль-Каиды», въехавших в страну за месяцы и даже считаные недели до 11 сентября. Один отдел следил за некой подозрительной личностью. Другой отдел занимался сомнительными иностранцами, почему-то одновременно в большом количестве проходящими летную подготовку. В третьем отделе занесли в список особого контроля кого-то неблагонадежного. Но между отделами не существовало никакого обмена информацией. Во всем ФБР никто так и не сложил вместе имеющиеся данные.

Комиссия 11 сентября ^{– в попытках установить внутренние факторы, позволившие произойти тому, что произошло, – детально изучила все обстоятельства террористических атак. По мнению членов комиссии, аналитики не могли получить доступа к информации, которую должны были исследовать. «Плачевное состояние информационных систем ФБР, – гласит отчет, – привело к тому, что получение такого рода доступа в большей степени зависело от личных отношений аналитика с сотрудниками оперативных команд и подразделений, располагавших информацией».}

До событий 11 сентября в ФБР никогда не выполняли экспертной оценки общей террористической угрозы Соединенным Штатам. На то было множество причин: от погони за карьерой до проблем с обменом информацией. Однако недостаток технологического развития указан комиссией как, пожалуй, основной фактор, из-за чего Бюро потерпело такое трагическое фиаско в дни, предшествовавшие 11 сентября. «Информационные системы катастрофически не соответствовали ситуации, – заключила комиссия в отчете, – в ФБР были лишены возможности охватить в полной мере ту информацию, которой оно обладало, поскольку не существовало эффективного механизма хранения и совместного использования накопленного объема знаний».

Когда сенаторы начали задавать ФБР некоторые неудобные вопросы, представители Бюро в основном отделывались фразой: «Не беспокойтесь, мы уже разрабатываем план модернизации». На этот проект под названием «Виртуальные следственные дела» (Virtual Case File, VCF) возлагали большие надежды. В желании извлечь максимальную выгоду из любого кризиса отвечавшие за разработку чиновники заявили о необходимости добавить всего лишь 70 миллионов долларов к имеющимся 100 миллионам, которые были предусмотрены в бюджете. Если вы почитаете публикации того времени, рассказывавшие о новом программном обеспечении для ФБР, то обнаружите, что никто не скупился на слова вроде революционный и преобразование.

Спустя три года проект закрыли. Программа была непригодна для работы. Ни на йоту. ФБР потратило 170 миллионов долларов из кармана налогоплательщиков на покупку компьютерной системы, которой никто никогда не будет пользоваться – ни единой строчкой кода, ни одним приложением, ни малейшим кликом мыши. Проект в целом оказался полностью провальным. И это нельзя считать простым недоразумением – неудачей IBM или Microsoft. Ведь на кону без преувеличения стоял вопрос о человеческих жизнях. На страницах Washington Post появилось признание Патрика Лехи, сенатора-демократа от штата Вермонт, председателя юридического комитета сената:

Мы располагали информацией, которая могла бы предотвратить 11 сентября. А они там сидели, и никто не принял никаких мер… Я до сих пор не вижу, что они устраняют проблему… Пока мы дойдем до технологии XXI века, уже наступит XXII столетие^.

Довольно показательно, что после провала программы «Виртуальные следственные дела» многие сотрудники ФБР перестали быть таковыми.

К следующему проекту, названному «Страж» (Sentinel), ФБР приступило сразу, в 2005 году. Программа обязательно начнет работать. В данном случае все будет иначе: в Бюро примут необходимые меры, проведут надлежащие бюджетные процедуры и организуют правильные средства контроля. Они как следует выучили урок. Цена вопроса? Сущий пустяк – 451 миллион долларов. И система «Страж» будет полностью работоспособной в 2009 году.

Что на этот раз могло пойти не так? Ответ появился в марте 2010 года и лежал на столе Джеффа Джонсона. Компания Lockheed Martin, подрядчик, которого наняли для разработки новой системы, опаздывала на год, осуществив лишь половину проекта и потратив 405 миллионов. Для завершения программы, по оценкам независимых экспертов, ей потребовалось бы еще от шести до восьми лет, а налогоплательщикам пришлось бы раскошелиться дополнительно на 350 миллионов долларов минимум.

Разбираться с проблемой пришлось Джонсону.

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

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

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

Каскадная модель

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

Генри Гант придумал свои знаменитые диаграммы в 1910 году. Впервые ими начал пользоваться генерал Уильям Крузер, начальник артиллерийско-технической службы вооруженных сил США в Первую мировую войну. Каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее «окопные» организационные идеи остаются популярными и по сей день.

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

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

В бытность свою кадетом Военной академии США, более известной как Вест-Пойнт, я спал в бывшей комнате Эйзенхауэра. По ночам уличные огни, отражаясь в висевшей над камином золотой табличке, иногда будили меня. Табличка гласила: «Здесь спал Дуайт Эйзенхауэр». Я вспомнил об этом президенте, поскольку он однажды заметил, что планировать сражение очень важно, но стоит прогреметь выстрелам – и твоя схема действий развеивается вместе с первым дымом. По крайней мере, Эйзенхауэру хватило здравого смысла не использовать диаграммы Ганта.

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

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

Чед доложил генеральному инспектору Министерства юстиции^{, что завершить систему «Страж» Бюро сможет только в том случае, если возьмет на себя управление проектом: они сократят количество разработчиков, выполнят наиболее трудную часть плана в пять раз быстрее и истратят менее одной десятой бюджетных денег. В докладах генерального инспектора Конгрессу, обычно сухих и официальных, явственно звучали скептические нотки.}

 

Представители финансового контроля, регулярно проводившие по распоряжению генерального инспектора проверку хода работ над проектом, в октябре 2010 года представили очередной отчет, в котором выразили серьезную озабоченность по поводу предложения ФБР; свои основные соображения они изложили в девяти пунктах, после чего следовало их заключение:

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

1. Цикл OODA (OODA loop), или петля OODA, или петля Бойда, включает в себя четыре составляющих: observe («наблюдать»), orient («ориентироваться»), decide («решать»), act («действовать»). См. подробно в . Здесь и далее примечания редактора.2. Комиссия 11 сентября (The 9/11 Commission), полное название – Национальная комиссия по террористическим атакам против Соединенных Штатов; сформирована 27 ноября 2002 г. – Здесь и далее прим. ред.1. Dan Eggen, Griff Witte. The FBI’s Upgrade That Wasn’t. $170 Million Bought an Unusable Computer System // Washington Post, 2006, August 18, p. A1.3. Чед Фулгэм отчитывался перед генеральным инспектором, поскольку ФБР, представляя собой подразделение не только разведывательного сообщества США, но и Министерства юстиции США, подчиняется одновременно директору Национальной разведки и генеральному прокурору. Служба генерального инспектора занимается ревизией и аудиторскими проверками с целью контроля за расходованием средств. Во время описываемых событий генеральным инспектором был Гленн Файн (2000–2011).2. Status of the Federal Bureau of Investigation’s Implementation of the Sentinel Project. US Department of Justice, Office of the Inspector General. Report 11–01, October 2010.

Читать онлайн «Scrum. Революционный метод управления проектами» автора Сазерленд Джефф — RuLit

К следующему проекту, названному «Страж» (Sentinel), ФБР приступило сразу, в 2005 году. Программа обязательно начнет работать. В данном случае все будет иначе: в Бюро примут необходимые меры, проведут надлежащие бюджетные процедуры и организуют правильные средства контроля. Они как следует выучили урок. Цена вопроса? Сущий пустяк — 451 миллион долларов. И система «Страж» будет полностью работоспособной в 2009 году.

Что на этот раз могло пойти не так? Ответ появился в марте 2010 года и лежал на столе Джеффа Джонсона. Компания Lockheed Martin, подрядчик, которого наняли для разработки новой системы, опаздывала на год, осуществив лишь половину проекта и потратив 405 миллионов. Для завершения программы, по оценкам независимых экспертов, ей потребовалось бы еще от шести до восьми лет, а налогоплательщикам пришлось бы раскошелиться дополнительно на 350 миллионов долларов минимум.

Разбираться с проблемой пришлось Джонсону.

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

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

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

КАСКАДНАЯ МОДЕЛЬ

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

Генри Гант придумал свои знаменитые диаграммы в 1910 году. Впервые ими начал пользоваться генерал Уильям Крузер, начальник артиллерийско-технической службы вооруженных сил США в Первую мировую войну. Каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее «окопные» организационные идеи остаются популярными и по сей день.

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

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

В бытность свою кадетом Военной академии США, более известной как Вест-Пойнт, я спал в бывшей комнате Эйзенхауэра. По ночам уличные огни, отражаясь в висевшей над камином золотой табличке, иногда будили меня. Табличка гласила: «Здесь спал Дуайт Эйзенхауэр». Я вспомнил об этом президенте, поскольку он однажды заметил, что планировать сражение очень важно, но стоит прогреметь выстрелам — и твоя схема действий развеивается вместе с первым дымом. По крайней мере, Эйзенхауэру хватило здравого смысла не использовать диаграммы Ганта.

Итак, Lockheed представила ФБР множество соблазнительных графиков, и Бюро подписало договор. На этот раз, по общему мнению, задание было детально продумано, поэтому ничто не могло пойти наперекосяк: «Взгляните, вот план работы над проектом — с цветной маркировкой, шкалой времени и гистограммами».

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

Чед доложил генеральному инспектору Министерства юстиции[3], что завершить систему «Страж» Бюро сможет только в том случае, если возьмет на себя управление проектом: они сократят количество разработчиков, выполнят наиболее трудную часть плана в пять раз быстрее и истратят менее одной десятой бюджетных денег. В докладах генерального инспектора Конгрессу, обычно сухих и официальных, явственно звучали скептические нотки.

Представители финансового контроля, регулярно проводившие по распоряжению генерального инспектора проверку хода работ над проектом, в октябре 2010 года представили очередной отчет, в котором выразили серьезную озабоченность по поводу предложения ФБР; свои основные соображения они изложили в девяти пунктах, после чего следовало их заключение:

В общем и целом у нас есть существенные опасения в отношении предложенного нового подхода; остается немало вопросов по поводу способности исполнителей обеспечить завершение проекта «Страж» без дополнительных расходов, без нарушения сроков и при сохранении в новой системе функциональности старой системы управления следственными делами…2

НОВОЕ МЫШЛЕНИЕ

Новый подход назывался Scrum. Создал его я двадцать лет назад. На сегодняшний день Scrum является единственной проверенной на деле методологией, способной вытянуть проекты, подобные «Стражу». Существует два подхода к работе: старый «каскадный» — при нем выбрасываются на ветер сотни миллионов долларов, и зачастую он так ни к чему и не приводит; новый — когда обязательства выполняются меньшими силами, в короткие сроки и с низкими затратами, а итоговый продукт отличается отменным качеством и обеспечивает высокую производительность. Я понимаю, мои слова звучат слишком хорошо, чтобы быть правдой, но результаты говорят сами за себя. Методология работает.

Двадцать лет назад я был близок к отчаянию. Мне требовалось выработать новое мышление. Изучив тонны исследовательских и экспериментальных материалов, просмотрев горы статистических данных, я осознал, что нам всем нужен новый подход к организации человеческой деятельности. Вряд ли поставленную мною задачу можно считать слишком сложной или особенно свежей, этот вопрос обсуждался, и не раз, в прошлом. Известны исследования еще времен Второй мировой войны, в которых рассматриваются наиболее эффективные способы организации труда. Однако по каким-то мотивам люди никогда не стремились сложить во­едино разрозненные фрагменты. Последующие два десятилетия я пытался идти исключительно по этому пути, и моя методика получила широкое распространение при разработках программного обеспечения — сферы, ради которой я ее создавал. И в таких гигантах, как Google, Amazon и Salesforce.com, и в маленьких никому не известных стартапах люди с помощью Scrum принципиально изменили свой подход к достижению цели.

Книги по Скрам и гибкой разработке

Scrum. Навчись робити вдвічі більше за менший час

Джефф Сазерленд
 

• Книжка входить до Топ-10 Amazon.com — Автор — розробник революційної методики Scrum, яка дозволяє гнучко будувати роботу і підвищує її якість — За 20 років методика допомогла в роботі не тільки фахівцям IT, співробітникам ФБР, бізнесменам, але й звичайним людям

У надшвидкому та гіперконкурентному світі ХХІ століття немає місця для марнування — часу, зусиль, ресурсів. Та навіть якщо ви зробите те, що планували, коли планували та вкладетеся в бюджет, може виявитися, що клієнт уже потребує чогось іншого. Адже умови змінюються з небаченою раніше швидкістю… Унікальна методика Scrum руйнує стереотипи старої методики управління проектами. Її основа — команда, що має надзвичайне почуття мети, самоорганізовується та самоуправляється, а навички її учасників підсилюють одна одну навіть без зусиль з їхнього боку. І, якщо, зробивши крок у нову еру під назвою Scrum, ви не зробили вдвічі більше за половину часу, вам потрібно лише ще раз уважно перечитати цю книгу!

bookclub.ua

Scrum. Революционный метод управления проектами

Джефф Сазерленд
 

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

ozon

Софт за 30 дней. Как Scrum делает невозможное возможным

Кен Швабер, Джефф Сазерленд
 

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

ozon

Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Роман Пихлер
 

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

ozon

Коучинг agile-команд. Руководство для scrum-мастеров, agile-коучей и руководителей проектов в переходный период

Лисса Адкинс
 

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

ozon

Пользовательские истории. Гибкая разработка программного обеспечения

Майк Кон
 

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

ozon

User Story Mapping. Пользовательские истории. Искусство гибкой разработки ПО.

Джефф Паттон
 

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

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

Канбан. Альтернативный путь в Agile

Дэвид Андерсон
 

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

ozon

Agile ретроспектива. Как превратить хорошую команду в великую

Эстер Дерби, Диана Ларсен
 

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

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

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

ozon

Пять пороков команды

Патрик М. Ленсиони
 

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

ozon

Драйв: Что на самом деле нас мотивирует

Дэниель Пинк
 

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

ozon

Peopleware: Человеческий фактор. Успешные проекты и команды

Том ДеМарко, Тимоти Листер
 

Немногие книги о компьютерах оказали такое заметное влияние на управление разработкой программного обеспечения, как ЧЕЛОВЕЧЕСКИЙ ФАКТОР. Уникальное озарение этой книги, долгие годы сохранявшей свое положение в списке бестселлеров: самые сложные проблемы разработки ПО носят не технологический, а социальный характер. Эти человеческие проблемы решать не просто, однако, решив их, вы увеличите шансы на успех до верхнего предела. В третьем издании появилось шесть новых глав и внесены многочисленные правки в основной текст, так что теперь книга лучше соответствует современным средам разработки и современным проблемам. В частности, обсуждаются патологии лидерства, которые раньше за патологии не считались, эволюционирующая культура собраний, а еще растущее понимание того, что некоторые наши инструменты служат скорее якорями, а не двигателями. Каждый, кому необходимо управлять проектом по разработке ПО или целой организацией такого рода, найдет на страницах этой книги множество ценных советов.

ozon

Цель. Процесс непрерывного совершенствования

Элияху Голдратт
 

«Цель» – книга научная и образовательная. Сейчас эти два понятия употребляют так часто, что их первоначальный смысл затерялся в тумане излишнего подобострастия и таинственности. Как и большинство серьезных ученых, я думаю, что наука вовсе не имеет дела ни с тайнами природы, ни с непреложными истинами. Это попросту метод, с помощью которого мы оперируем неким минимальным набором предположений, способных посредством прямых логических построений обосновать существование многих явлений природы.Физический закон сохранения энергии отнюдь не истина. Это всего лишь предположение, эффективно объясняющее огромное количество природных феноменов. Доказать универсальную применимость этого предположения невозможно, сколько бы конкретных примеров его справедливости вы ни приводили. Зато опровергнуть это предположение можно одним-единственным фактом, который оно оказалось бы не в состоянии объяснить. Но даже такое опровержение не лишает предположение справедливости. Оно свидетельствует о необходимости другого, более общего предположения.Именно так закон сохранения энергии был замещен более общим эйнштейновским постулатом сохранения энергии и массы. Эйнштейновский закон – не истина в такой же степени, как и его предшественник.

ozon

Открывая организации будущего

Фредерик Лалу
 

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

ozon

Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели

Эрик Рис
 

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

ozon

Непрерывное развертывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ

Джез Хамбл, Дэвид Фарли
 

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

ozon