Эти книги помогают внедрять Agile в «Сбербанке» и сократить время выхода нового продукта. Agile книга


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

В преддверии крупнейшей восточноевропейской конференции по гибким методологиям 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

habr.com

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

Agile-книга об Agile-методологиях

Авторы — большие приверженцы гибких методик разработки ПО и Манифеста Agile. Эндрю Стеллман — разработчик с богатым двадцатилетним стажем, а Дженифер Грин помимо программирования известна как менеджер и аналитик. Оба являются agile-коучами. Такой дуэт довольно неплохо помогает взглянуть на методологии: и глазами руководителя, и глазами разработчика.

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

Кому стоит читать?

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

Менеджерам, коучам, рядовым сотрудникам

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

Книга подойдёт и каждому, кто работает или управляет командой, использующей Agile-методологию. Эти люди смогут ответить для себя на многие вопросы касательно разных методик и практик. Возможно, понять наконец, что те же «дэйли-митингс» нужны не просто как бессмысленный ритуал, если им не смог это объяснить Scrum-мастер или менеджер проекта.

В «Постигая Agile…» очень хорошо разобраны четыре самых популярных методологии: Scrum, XP, Kanban и Lean. Главы о каждой вполне хватит, чтобы начать в ней разбираться и понимать отличия.

Разработчикам

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

Любому, кто хочет оптимизировать рабочий процесс

Даже если вы не работаете в IT-сфере, не руководите коллективом или, может быть, вы вообще фрилансер, в этой книге вы найдёте полезные советы. Главы о Kanban и Lean содержат много интересной информации и о личной эффективности. Как смотреть на свой труд по-новому, как сокращать затраты и издержки в деньгах и во времени там, где это возможно.

Кому не стоит читать?

Тем, кто уже хорошо знаком с Agile-методологиями и пытается внедрять их в сфере, далёкой от разработки ПО. Если вам не надо объяснять, чем Kanban отличается от Scrum, как работать с диаграммой сгорания и доской задач, то книга может показаться местами повторяющейся и скучноватой. Особенно, если вы ищите способы ввести, например, «Скрам», в сфере маркетинга. Ответов на такие вопросы книга не содержит.

Постигая Agile

Преимущества и недостатки

На основании в первую очередь содержания и структуры можно выделить преимущества и недостатки «Постигая Agile…».

Преимущества:

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

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

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

 

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

kogio.ru

10 книг, которые вам стоит прочесть – Елена Литвинова – Блог – Сноб

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

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

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

 

 

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

  1. Корпорация гениев. как управлять командой творческих людей

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

 

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

в блоге компании.  

     2.

Юлия Чемеринская, “Круглая методика”

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

 

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

 

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

 

      3.

Дэниел Гоулман, Эмоциональный интеллект

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

 

Кроме того, овладение навыками эмпатии - одна из важнейших компетенций будущего. Мир следующего десятилетия во многом будет опираться на команды, а одиночки не могут создавать команду и не могут долго быть в ней. При этом надо понимать, что сегодняшний мир не приучает молодежь к “командной игре”. Он скорее  ориентирует ее на заботу о себе. Сегодняшний 20+ сотрудники очень эгоцентричны, и преодоление этого фактора, умение снимать этот внутренний конфликт - залог успеха множества компаний и команд.

 

     4.

Чип Хиз, Дэн Хиз, Сердце перемен

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

 

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

 

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

 

     5.  

Патрик Ленсиони Пять пороков команды

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

 

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

 

Специально для этой статьи я дополнила свой лист традиционным списком книг на русском языке, в названии которых уже присутствует в той или иной степени слово/понятие Agile:

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

Логично дополняет книгу Эрика Риса и показывает как можно начать разговор с потенциальными клиентами даже не имея продукт и создать продукт с максимальной ценностью

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

Много важных моментов о том как на самом деле можно создать продукт с максимальной ценностью

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

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

 

А если вы хотите разобраться в роли руководителя в Agile организации и как работать с Agile командами, то приглашаем на наш открытый тренинг осенью: 11-12 сентября, Москва, Тренинг Менеджмент 3.0. Формируем Agile мышление, тренер Ральф Русмален (Амстердам)

snob.ru

Эти книги помогают внедрять Agile в «Сбербанке» и сократить время выхода нового продукта

Директор розничного транзакционного бизнеса «Сбербанка» Светлана Кирсанова рассказала Rusbase, как метод Agile повлиял на подход на одного из дивизионов «Сбербанка» к бизнесу, и какие книги в этом помогли. В конце она поделилась книгами, которые ее впечатлили.

Нередко у меня спрашивают: а что дает Agile? Это изменение культуры и микросервисный подход к ведению бизнеса. А также возможность не планировать сразу огромных проектов, а двигаться более мелкими, но быстрыми итерациями, уточняя по ходу постановку задачи и корректируя ее реализацию в зависимости от желания клиентов. Например, в части эквайринга нам удалось снизить показатель time to market по некоторым проектам с полугода-года до трех-четырех недель, а иногда – до нескольких дней. Это означает, что клиент в разы быстрее получает новые услуги. Но нужно понимать, что это большой и долгий путь, а не мгновенный результат с того момента, как вы решили перейти в Agile.

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

«Scrum: The Art of Doing Twice the Work in Half the Time», Джефф Сазерленд, и «Коучинг Agile Команд», Лисса Адкинс

Я прочитала десятки книг по Agile и Scrum. Эти две, на мой вкус, дают комплексное представление о культуре. Во-первых, обобщают многое из того, что есть по этой теме. А во-вторых, дают четкий ответ на вопрос: «Зачем agile конкретно мне? Моей команде? Организации в целом?»

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

На нашу полку попадают книги, которые рекомендуют герои наших интервью и колумнисты. Получите месяц на Bookmate бесплатно: введите промокод RUSBASE.

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

«О чём я говорю, когда говорю о беге», Харуки Муракам и «OPEN», Андреа Агасси

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

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

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

Материалы по теме:

Что читает вице-президент «Рыбаков фонда»

Любимые книги Андрея Себранта, директора по маркетингу сервисов «Яндекса»

Эти книги о вирусах и эгоизме помогли решить проблемы с HR, маркетингом и клиентским сервисом

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

Что читает руководитель проектного офиса OneTwoTrip

Актуальные материалы — в Telegram-канале @Rusbase

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

rb.ru

Agile Results — обзор системы личной эффективности

Getting Results The Agile WayМеня всегда интересовали различные системы личной эффективности, особенно те из них, которые сфокусированы на достижение результатов.

При использовании To-do списков часто замечаешь, что продуктивность дня оценивается по количеству выполненных дел, а не по их качеству.

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

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

30 days Of Getting ResultsМетодика была разработана одним из старших менеджеров Microsoft, J.D. Meier. Описанию системы посвящена отдельная книга Getting results the Agile way, но мое знакомство с Agile Results началось не с нее: я увидел обзорную статью на betteri.ru, а после этого прочел другую книгу автора о том, как за 30 дней внедрить методику в свою жизнь – 30 days of getting results. В книге дан подробный алгоритм на каждый день для постепенного знакомства с методикой.

Данную книгу можно скачать бесплатно или же прочесть отдельные разделы на специальном сайте — http://www.30daysofgettingresults.com.

Обзор системы Agile Results

Основа методики — правило трех результатов:

  • Три результата дня. Каждый день в начале дня (или накануне вечером) надо сформулировать 3 главных результата дня, которые сегодня хочется добиться. Каждый день начинаем с «чистого листа»
  • Аналогично – три результата недели
  • Три результата года

Для каждого результата указываем:

  • Зачем (обеспечивая связь со сферами влияния)
  • Как (что нужно сделать, чтобы результат был достигнут)
  • Конечный результат (отвечаем на вопрос как понять, что результат достигнут)

Система работает следующим образом:

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

Области внимания J.D. Meier назвал «Сферами влияния», между которыми необходимо сохранять баланс. Все задачи и проекты он предлагает делить на три области:

  • Рабочая сфера,
  • Личная сфера,
  • Жизнь или жизненная сфера.

Проекты и задачи в рабочей и личной сферах делятся на «Текущую деятельность», «Активные проекты» и «Отложенное» (backlog), а в «Жизни» автор выделяет:

  • Разум
  • Тело
  • Эмоции
  • Карьера
  • Финансы
  • Отношения
  • Развлечения

 Главные принципы Agile Results

  • Начинайте каждый день, неделю, месяц, год «С чистого листа». Ежедневный контроль и если надо — пересмотр приоритетов
  • Принцип 80/20 — тратьте 80 процентов времени на действия, а не на планирование.
  • Будьте готовы изменить подход, если что-то не работает
  • «Откусывайте ровно столько, сколько сможете откусить»
  • Делите Действия и Справочную информацию, т.к. далеко не вся информация требует действий
  • Устанавливайте границы: Определите лимиты в сферах влияния, четко представляйте минимумы и максимумы, которые отводятся для каждой сферы

 

Ключевые ценности Agile Results

  • Подход важнее результата. На результат действий не всегда можно влиять, но всегда можно изменить свое отношение, поступки и ответную реакцию.
  • Энергия приоритетнее времени
    • Фокус на поддержание высокого уровня энергии
    • Правильное питание
    • Хороший сон
    • Физические нагрузки
  • Концентрация важнее количества. Не надо выполнять как можно больше задач, а надо выполнять те задачи, которые действительно необходимы (отвечают целям)
  • Достаточно хорошо лучше, чем идеально. Лучше сделать, чем постоянно исследовать, как можно было бы сделать работу еще более лучше
  • Мыслить категориями развития =  я всегда буду учиться и расти
  • Результат важнее действия: проводить больше времени на работе — не главное, главное — результат
  • Система приоритетнее временного решения

Конспект основных идей по методике Agile Results я свел в ментальную карту:

Обзор Agile Results

Обзор Agile Results

Если заинтересовала методика, то на отдельной странице на сайте я собрал все мои заметки о внедрении методики день за днем и связанные статьи.

 

selfmngmt.ru

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

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

Эндрю Стеллман, Дженнифер ГринПостигая 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 results

Я редко пишу о саморазвитии и личной эффективности.

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

Но, тем не менее, я достаточно часто продолжаю получать вопросы от читателей, которые я объединил в несколько групп:

  • Как мне удается планировать свой день и выполнять запланированное?
  • Какой системой планирования и какими инструментами я пользуюсь?
  • Можно ли легко адаптировать мою систему под себя?

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

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

Дело не в том, что эти системы – плохие.  Для себя я сделал вывод: только сам человек способен создать под себя идеальную систему управления временем.

Мой пример

Давайте рассмотрим мой пример.

Я прочитал «Тайм-драйв» Архангельского, начал выписывать списки дел, завел календарик-пинарик, и распечатал хронометраж. Через неделю, я просто возненавидел тайм-менеджмент!

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

GTD Девида Аллена поначалу показалась мне решением всех проблем. Но, только поначалу  😀 Мне тяжело было справиться с системой планирования, структурированием папок, ярлыками и тегами. В итоге, я даже не дочитал книгу.

Следующей в списке была Agile Results.

С этой системой я познакомился в книге Дж. Д. Майера «30 дней достижения результатов». Первые впечатления после 30 дней использования системы я описал здесь.

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

Почему?

Потому что, каждый из создателей систем управления временем создавал их под себя!

Гибрид на основе Agile Results

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

Поэтому, я принял решение попробовать создать систему планирования и управления временем, идеально подходящую, в первую очередь, мне!

За основу была взята модель Agile Results.

Почему?

Потому что, именно Agile Results позволяет гармонично охватывать все стороны жизни и концентрироваться на самых важных вещах!

Что входит в мою систему?

#1 –  Инструменты

  • Day One — Bloom Built, LLC – это мой ежедневник, в котором я подвожу итоги дня и недели.
  • Evernote – это мой виртуальный ассистент. В Evernote созданы блокноты по упрощенной модели Agile Results
  • Напоминания – это стандартная программа для Mac, в которую я заношу напоминания о событиях, привязанных к конкретной дате и времени
  • Eggscellent — Monocle Society. Инструмент, позволяющий разбивать работу на 25-минутные интервалы и 5-минутные перерывы на основании техники Pomodoro.

#2 – Элементы систем

  • Agile Results – система планирования
  • GTD – блокнот «Входящее» и «To-Do»
  • 18 минут Питера Брегмана – Принципы фокусировки и планирования
  • Техника Pomodoro – работа над задачами с регулярными интервалами и перерывами
  • Планирование дня блоками – позволяет четко структурировать, чем я занимаюсь в определенные отрезки дня

Как работает моя система?

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

#1 – Структура блокнотов планирования в Evernote на основании системы Agile Results

Именно таким образом выглядит моя система планирования. Она состоит из 9-ти блокнотов:

Моя система планирования. Пошаговое руководство как все успевать

#1 – Входящее (To-Do)

Моя система планирования. Пошаговое руководство как все успевать

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

#2 – Фундамент

Моя система планирования. Пошаговое руководство как все успевать

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

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

Я достаточно часто заглядываю в этот блокнот – он является моим маяком и ориентиром.

#3 – План дня

Моя система планирования. Пошаговое руководство как все успевать

План дня состоит из нескольких частей.

Первое, это 3 ключевых результата, которых я хочу добиться в течении дня. Над этими делами я работаю в первую очередь.

Второе, список остальных задач на день.

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

#4 – План недели

Моя система планирования. Пошаговое руководство как все успевать

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

  • Главный приоритет недели (задачи из этой группы выполняются каждый день)
  • Топ-10 задач на неделю (к которым относятся самые приоритетные задачи для меня)
  • Перечень остальных задач, к которым я перехожу в том случае, если выполнил все запланированное.
#5 – Пятничный обзор

Моя система планирования. Пошаговое руководство как все успевать

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

#6 – План месяца

Моя система планирования. Пошаговое руководство как все успевать

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

Почему?

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

#7 – План года

Моя система планирования. Пошаговое руководство как все успевать

План года полностью аналогичен  ежемесячному планированию.

#8 – Проекты

Моя система планирования. Пошаговое руководство как все успевать

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

#9 – Идеи

Моя система планирования. Пошаговое руководство как все успевать

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

Этот блокнот нужно регулярно пересматривать и чистить ( я это делаю каждую неделю), так как идеям свойственно терять актуальность  😀

#2 – Мои принципы планирования и управления временем

Теперь немного расскажу о том, как я работаю с этой системой.

#1 – Ежедневно

Моя система планирования. Пошаговое руководство как все успевать

Каждое утро я выделяю 5 минут (помните 18 минут Питера Брегмана?) на планирование 3 ключевых результатов дня, просмотра напоминалок со встречами и плана на неделю, а также составление перечня задач на день.

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

В конце дня я выделяю 5 минут, чтобы быстро подвести итоги дня, оценить, что получилось и не получилось. Итоги дня я переношу в электронный ежедневник Day One — Bloom Built, LLC.

#2 – Еженедельно

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

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

Полученные выводы я переношу в свой электронный ежедневник Day One — Bloom Built, LLC.

#3 – Ежемесячно

Ежемесячно я подвожу итоги своей работы:

  • Уровень доходов и расходов
  • Выполнение маркетинговых целей
  • Достижение поставленных задач на месяц
  • Анализ эффективности сайта и публикаций

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

#4 – Ежегодно

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

Надеюсь, что моя система пригодится и вам  😉

azinkevich.com


Смотрите также