6 лучших книг по разработке управление и гибкая разработка


Оглавление (нажмите, чтобы открыть):

12 методологий разработки ПО

  • Waterfall — традиционный подход.
  • RUP (Rational Unified Process) — рациональный.
  • Agile — общая методология гибкой разработки.
  • Crystal Clear — подход с уравниванием разработчиков в коллективе.
  • Spiral — спиральный метод.
  • DSDM (Dynamic Systems Development Model) — динамическая модель.
  • FDD (Feature Driven Development) — методология, рассматривающая будущие изменения.
  • JAD (Joint Application Development) — ориентированный на пользователя подход.
  • RAD (Rapid Application Development) — модель быстрой разработки.
  • Scrum — концепция работы в условиях сорванных сроков и идеологического кризиса.
  • XP (Extreme Programming) — экстремальная разработка в динамической среде.
  • LD (Lean Development) — метод, предполагающий бережное отношение ко всем участникам процесса.

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

Waterfall

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

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

RUP — итеративный подход, который решает проблемы, которые есть у Waterfall. Чем хорош RUP:

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

Agile

Agile — метод гибкой разработки программного обеспечения, предполагающий большое количество итераций. Документ Agile Manifesto описывает 4 идей и 12 принципов гибкого подхода, коротко его можно описать всего двумя пунктами:

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

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

Crystal Clear

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

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

Spiral

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

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

Модель развития динамических систем была разработана в Великобритании в середине 1990-х годов и является эволюционным развитием быстрой разработки приложений (RAD). Основная идея стандартная: при планировании в самом начале невозможно понимать всех тонкостей разработки, поэтому весь процесс — исследовательская работа.

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

FDD — процесс для обеспечения масштабируемости и повторяемости, при этом поощряющий творчество и инновации. Вот основные принципы:

  • Разработка каждого крупного проекта должна иметь системность.
  • Процессы должны быть простыми и проработанными.
  • Ценность и логичность процесса должна быть ясна каждому члену команды.
  • Предпочтение отдаётся коротким итеративным циклам разработки. Это уменьшает количество ошибок и позволяет быстрее наращивать функциональность.

FDD регламентирует время, которое должно затрачиваться на каждый из процессов. Организационной деятельности в цикле должна занимать не более 23−25%, в то время как на непосредственную разработку, сборку и тестирование функций необходимо тратить 75−77% времени.

JAD — это методология, нацеленная на максимальную занятость в разработке конечного пользователя. Происходит это посредством встреч и проведения совместных семинаров. JAD была придумана в 1970-х годах сотрудниками IBM и нацелена на бизнес в целом. Однако со временем данная концепция стала успешно применяться и для разработки программного обеспечения.

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

RAD — методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий — использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, Pascal или Fortran). Вот ещё несколько пунктов концепции:

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

RAD предполагает использование целого комплекса инструментов помимо языка быстрой разработки: системы сбора требований, среды разработки, фреймворки, программы для группового общения, ПО для тестирования.

Scrum

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

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

Экстремальное программирование — возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:

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

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

  • Поощрении сотрудников за успешную работу.
  • Изменении текущих задач только по мере необходимости или по запросу заказчика.
  • Строгом выполнении плана: всё, что сверх — считается потерями времени и ресурсов.
  • Внедрении общей концепции «Мыслить широко, делать мало, ошибаться быстро, учиться стремительно».

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

Методология разработки софта — организация труда, включающая идеологические принципы, план, контроль над процессами, подход к сотрудникам. Выделим 12 видов:

  • Waterfall — традиционный подход.
  • RUP (Rational Unified Process) — рациональный.
  • Agile — общая методология гибкой разработки.
  • Crystal Clear — подход с уравниванием разработчиков в коллективе.
  • Spiral — спиральный метод.
  • DSDM (Dynamic Systems Development Model) — динамическая модель.
  • FDD (Feature Driven Development) — методология, рассматривающая будущие изменения.
  • JAD (Joint Application Development) — ориентированный на пользователя подход.
  • RAD (Rapid Application Development) — модель быстрой разработки.
  • Scrum — концепция работы в условиях сорванных сроков и идеологического кризиса.
  • XP (Extreme Programming) — экстремальная разработка в динамической среде.
  • LD (Lean Development) — метод, предполагающий бережное отношение ко всем участникам процесса.

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

Waterfall

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

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

RUP — итеративный подход, который решает проблемы, которые есть у Waterfall. Чем хорош RUP:

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

Agile

Agile — метод гибкой разработки программного обеспечения, предполагающий большое количество итераций. Документ Agile Manifesto описывает 4 идей и 12 принципов гибкого подхода, коротко его можно описать всего двумя пунктами:

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

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

Crystal Clear

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

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

Spiral

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

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

Модель развития динамических систем была разработана в Великобритании в середине 1990-х годов и является эволюционным развитием быстрой разработки приложений (RAD). Основная идея стандартная: при планировании в самом начале невозможно понимать всех тонкостей разработки, поэтому весь процесс — исследовательская работа.

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

FDD — процесс для обеспечения масштабируемости и повторяемости, при этом поощряющий творчество и инновации. Вот основные принципы:

  • Разработка каждого крупного проекта должна иметь системность.
  • Процессы должны быть простыми и проработанными.
  • Ценность и логичность процесса должна быть ясна каждому члену команды.
  • Предпочтение отдаётся коротким итеративным циклам разработки. Это уменьшает количество ошибок и позволяет быстрее наращивать функциональность.

FDD регламентирует время, которое должно затрачиваться на каждый из процессов. Организационной деятельности в цикле должна занимать не более 23−25%, в то время как на непосредственную разработку, сборку и тестирование функций необходимо тратить 75−77% времени.

JAD — это методология, нацеленная на максимальную занятость в разработке конечного пользователя. Происходит это посредством встреч и проведения совместных семинаров. JAD была придумана в 1970-х годах сотрудниками IBM и нацелена на бизнес в целом. Однако со временем данная концепция стала успешно применяться и для разработки программного обеспечения.

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

RAD — методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий — использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, Pascal или Fortran). Вот ещё несколько пунктов концепции:

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

RAD предполагает использование целого комплекса инструментов помимо языка быстрой разработки: системы сбора требований, среды разработки, фреймворки, программы для группового общения, ПО для тестирования.

Scrum

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

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

Экстремальное программирование — возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:

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

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

  • Поощрении сотрудников за успешную работу.
  • Изменении текущих задач только по мере необходимости или по запросу заказчика.
  • Строгом выполнении плана: всё, что сверх — считается потерями времени и ресурсов.
  • Внедрении общей концепции «Мыслить широко, делать мало, ошибаться быстро, учиться стремительно».

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

Топ-7 методов управления проектами: Agile, Scrum, Kanban, PRINCE2 и другие

08 Июл 2020

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

— Роджер Лаунис, историк НАСА

У человечества за всю историю накопился внушительный список успешно реализованных сложных проектов. От строительства Пирамид в Гизе до отправки человека на Луну, самые смелые человеческие начинания требовали слаженной работы тысяч людей. А это подразумевает сложную систему управления проектами.

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

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

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

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

В этой статье мы рассмотрим:

  • Классический проектный менеджмент
  • Agile
  • Scrum
  • Lean
  • Kanban
  • SixSigma
  • PRINCE2

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

Почему «управление проектами»?

Имена Нила Армстронга и Базза Олдрина навсегда войдут в историю как символы одного из величайших достижений человечества – высадке человека на Луну. Однако основной вклад в это событие внесли 400 000 сотрудников НАСА и 20 000 компаний и университетов, работавших вместе над миссией «Аполлон».

В 1961 году Джон Кеннеди поставил задачу высадить человека на спутнике Земли и вернуть его обратно – при том, что на тот момент НАСА отправляли человека в космос лишь на 15 минут. Такая амбициозная цель потребовала невероятного количества ресурсов, кооперации, инноваций и планирования.

Как говорится в книге НАСА «Managing the Moon Program», основная проблема состояла не в том, «что делать?», а в том, «как сделать столько за такой короткий срок?». По словам доктора Макса Фагета (Dr. Max Faget), главы инжиниринга в Космическом центра имени Линдона Джонсона (The Lyndon B. Johnson Space Center, JSC), тогда в НАСА не представляли, как уложить все необходимые действия в 10 лет. А потому первым шагом стало «разбить проект на управляемые этапы».

Затем важно было ускорить выполнение каждой отдельной фазы и удостовериться, что команды и компании, работающие на каждой фазе, эффективно взаимодействуют друг с другом и вовремя поставляют результаты. Эта задача была возложена на доктора Джорджа Мюллера (George E. Muller), управлявшего каждой частью проекта «Аполлон», от Белого Дома до поставщика самой мелкой детали. Чтобы контролировать проект было легче, он решил разбить проект на 5 областей: «Контроль Программы», «Системная Инженерия», «Тестирование», «Надёжность и Качество» и «Лётная эксплуатация». Схема управления программой Аполлон представлена на Рисунке 1.

Эта система из 5 этапов – названных «Этапами GEM» в честь инициалов доктора Мюллера – была разработаны «ради фокусировки на тестировании продукта, и на его разработке с учётом того, что его будут тестировать», как отмечает сам Мюллер. «Контроль Программы» определял, что нужно сделать, управлял бюджетом и требованиями, а также управлял взаимосвязями элементов программы. Область «Системная инженерия» отвечала за разработку новых устройств и узлов, «Тестирование» за то, что эти новые элементы работают, «Надёжность и Качество» проверяли разработанные элементы на соответствие требованиям и стандартам, а «Лётная эксплуатация» отвечала за то, что эти узлы будут работать во время полёта.

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

Краткая история проектного управления

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

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

Однако, если Вы – шеф-повар, и готовите не одно блюдо, а несколько, например, салат (приготовление которого состоит из 3 этапов) и десерт (который нужно только подать), то Вам потребуется инструмент, позволяющий отслеживать временные затраты на каждый из элементов и время, когда они должны быть готовы. И тут на помощь приходит один из первых современных инструментов проектного управления: Диаграмма Гантта, представленная на Рисунке 2.

Изобретённая независимо Королем Адамеки (Korol Adamecki) и Генри Л. Ганттом (Genry L. Gantt) в начале XX в., диаграмма Гантта показывает расписание проекта основываясь на датах окончания и завершения задач. В неё вносятся задачи, их длительности и взаимосвязи, а затем высчитывается критический путь – самая длинная цепочка взаимосвязанных задач, определяющих длительность проекта. Взаимосвязи между началом и окончанием разных задач очень важны – вы же не можете подать гостям суп, пока вы его не сварили, не так ли?

Так вот, типовой проект очень похож на проект приготовления и подачи ужина, только в нём гораздо больше задач, взаимосвязей, дедлайнов и видов ресурсов. Проектам с жёсткими дедлайнами диаграмма Гантта помогает решить, когда лучше начинать те или иные задачи, чтобы сократить время реализации. А для проектов с сильными ресурсными ограничениями, диаграмма Гантта предоставляет возможность построить схему в форме событийной цепочки процессов (event-driven process chain) для планирования ресурсов.

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

Для таких проектов лучше подходят гибкие методы управления проектами Agile и связанные с ним подходы, такие как Lean, Kanban и другие. Есть и методы, позволяющие управлять как рабочим потоком, так и временем, и ресурсами – 6 Сигм и Scrum.

Популярные системы управления проектами

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

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

Базовые термины проектного управления

Agile: Гибкий итеративно-инкрементальный подход к управлению проектами и продуктами, ориентированный на динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует множество методов, базирующихся на идеях Agile, самые популярные из которых – Scrum и Kanban.

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

Событийная цепочка процессов (EPC-диаграмма): диаграмма, отображающая последовательность реализации работ проектов основываясь на доступности и загруженности ресурсов

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

Веха (контрольная точка, milestone): Ключевое событие, обозначающее, например, конец этапа. На диаграмме Гантта обозначается задачей с нулевой длительностью.

Мастер Йода рекомендует:  Linux Foundation запустила платформу Acumos AI Project

Менеджер проекта (руководитель проекта, project manager, PM): Руководитель команды проекта, ответственный за управление проектом (планирование, реализацию и закрытие проекта).

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

Содержание проекта (Scope): Описание работ, которые необходимо выполнить, чтобы получить продукт.

Спринт (Sprint): Итерация (рабочий цикл) в Scrum, длящаяся от недели до месяца, в ходе которой создаётся рабочая версия продукта или его элемент, представляющий ценность для заказчика.

«Классическое» или «традиционное» проектное управление: Наиболее широко распространённый метод управления проектами, основанный на так называемом «водопадном» (Waterfall) или каскадном цикле, при котором задача передаётся последовательно по этапам, напоминающим поток.

Далее мы рассмотрим различные подходы к управлению проектами более подробно. Мы начнём с Классического проектного управления и Agile, а затем рассмотрим Scrum, Kanban, 6 сигм и другие.

Классическое проектное управление

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

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

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

5 этапов традиционного менеджмента:

Этап 1. Инициация. Руководитель проекта и команда определяют требования к проекту. На данном этапе часто проводятся совещания и «мозговые штурмы», на которых определяется что же должен представлять из себя продукт проекта.

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

Этап 3. Разработка. Данная стадия реализуется не для всех проектов — как правило она является частью фазы планирования. В фазе разработки, характерной для технологических проектов, определяется конфигурация будущего проекта и/или продукта и технические способы его достижения. Например в ИТ-проектах на данном этапе выбирается язык программирования. (В отечественной практике данная фаза обычно не выделяется, а термин «разработка» не используется — прим. пер.)

Этап 4. Реализация и тестирование. На этой фазе происходит собственно основная работа по проекту – написание кода, возведение здания и тому подобное. Следуя разработанным планам начинает создаваться содержание проекта, определённое ранее, проводится контроль по выбранным метрикам. Во второй части данной фазы происходит тестирование продукта, он проверяется на соответствие требованиям Заказчика и заинтересованных сторон. В части тестирования выявляются и исправляются недостатки продукта.

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

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

Благодаря тому, что классический проектный менеджмент строго привязан ко времени исполнения задач, как правило, заранее определённому на этапе планирования, для реализации проектов в рамках данного подхода отлично подходят инструменты календарно-сетевого планирования. Самым распространённым инструментом календарно-сетевого планирования является уже упомянутая ранее диаграмма Гантта. Существует множество инструментов для её построения – от простых таблиц вроде Excel и Smartsheet до профессиональных программных пакетов вроде Microsoft Project и Primavera.

Сильные стороны классического проектного менеджмента

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

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

Слабые стороны классического проектного менеджмента

Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Руководство компании Toyota, знаменитую созданием таких систем как Lean и Kanban, часто критикуют за то, что они применяют классический подход в разработке софта для своей компании, причём именно за недостаток гибкости.

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

Agile

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

И тут в игру вступает Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на Рисунке 5.

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

Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова (об истории появления Agile можно прочесть здесь – прим.пер.). Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto), закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям.

Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки (frameworks): Scrum, Kanban, Crystal, и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам.

Сильные стороны Agile

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

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

Вотчина Agile – разработка новых, инновационных продуктов. В проектах по разработке таких продуктов высока доля неопределённости, а информация о продукте раскрывается по ходу проекта. В таких условиях реализовывать проект по «водопаду» становится невозможно– нет информации для планирования.

Слабые стороны Agile

В отличие от PRINCE2 и PMBOK Agile – не является ни методологией, ни стандартом. Agile — это набор принципов и ценностей. Слабая сторона состоит в том, что каждой команде придётся самостоятельно составлять свою систему управления, руководствуясь принципами Agile. Это непростой и длительный процесс, который потребует изменений всей организации, начиная процедурами и заканчивая базовыми ценностями. Это тернистый путь и не всем организациям он под силу.

Этот путь потребует от лидера изменений не только знаний и упорства, но и серьёзных административных ресурсов, а также затрат. К счастью, существуют готовые наборы практик, которые облегчают Agile-трансформацию организации. К таким наборам относятся фреймворк Scrum, метод Kanban и многие другие – Crystal, LeSS, SAFe, Nexus.

Scrum

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

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «беклог». Затем эти части приоретизируются Владельцем продукта – представителем Заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в Спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце Спринта Заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему Спринту. Длительность у Спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям Заказчика, которые имеют свойство изменяться со временем, перед началом каждого Спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, Scrum Мастер (Scrum Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

Как уже говорилось, Владелец продукта является представителем Заказчика в проекте, или олицетворяет всех клиентов будущего проекта, в случае если Заказчика нет. Для этого он должен досконально знать их потребности и образ мышления, а также разбираться в продукте и технологии его изготовления. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача — следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены.

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

  • Встреча по упорядочиванию беклога (BacklogRefinementMeeting, «BacklogGrooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него него зависит, какую ценность получит Заказчик по итогам спринта.
  • Планирование Спринта: После того, как Владелец продукта определил приоритеты, команда совместно решает, что же конкретно они будут делать во время грядущей итерации, как достигнуть поставленной на предыдущей встрече цели. Команды могут применять различные инструменты планирования и оценки на данном этапе, лишь бы они не противоречили принципам и логике Scrum. Планирование Спринта проводится в самом начале итерации, после Встречи по упорядочиванию продукта.
  • Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.
  • Подведение итогов Спринта: Цель этапа – обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.
  • Ретроспектива Спринта: Проводится сразу после Подведения итогов спринта и до планирования следующего спринта. На нём команда выясняет, насколько чётко и слаженно проходил процесс реализации этапа. Обследованию подвергаются возникшие проблемы в работе, методологии и взаимодействии. Именно этот этап позволяет команде провести рефлексию и следующий Спринт провести эффективнее.

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

Сильные стороны Scrum

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

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

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

Слабые стороны Scrum

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

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

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

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

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

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

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

Сильные стороны Lean

Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны Lean

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

А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций ̶ главное помнить об этом.

Kanban

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент.

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

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

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

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

  1. Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
  2. Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
  3. Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
  4. Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Сильные стороны Kanban

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.

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

Слабые стороны Kanban

Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких дедлайнов. Для жёстких дедлайнов лучше подходит классический подход или Scrum.

6 сигм (Six Sigma)

Компания Motorola, наряду с Toyota, также внесла вклад в развитие мирового проектного управления. Инженер этой компании Bill Smith создал концепцию 6 сигм в 1986 году. Это более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, также снижения количества брака и проблем.

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

Для этого было предложен процесс из 5 шагов, известных как DMEDI:

  • Определение (Define): Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.
  • Измерение (Measure): 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.
  • Исследование (Explore): На стадии исследования менеджер проекта решает, каким же образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. На данном этапе очень важно нестандартное мышление руководителя проектов при решении возникших проблем.
  • Разработка (Develop): На данном этапе реализуются планы и решения, принятые на предыдущих этапах. Важно понимать, что на данном этапе необходим детальный план, в котором описаны все действия, необходимые для достижения поставленных целей. Также на данном этапе измеряется прогресс проекта.
  • Контроль (Control): Ключевой этап в методологии 6 сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

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

Сильные стороны 6 сигм

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

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

Слабые стороны 6 сигм

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

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

PRINCE2

НАСА – не единственная государственная организация, которая внесла вклад в развитие проектного управления. Британское Правительство давно оценило эффективность проектного управления, и в 1989 году была создана британская методология PRINCE2. Название произошло от акронима «PRojects IN Controlled Environments version 2», что переводится как «Проекты в контролируемой среде версия 2». В отличие от гибких методов, PRINCE2 не использует итеративный подход к проекту. Если сравнивать PRINCE2 другими продуктами, то его можно сравнить с гибридом классического подхода к проектному управлению и концентрации на качестве из 6 сигм.

Методология PRINCE2 в отличие от, например, свода знаний PMBOK не содержит:

  • Специализированных аспектов управления проектом, например, отраслевых;
  • Конкретных практик и инструментов управления проектами, таких как диаграмма Гантта, WBS и т.п.

PRINCE2 концентрируется на управленческих сторонах проекта, выраженных в 7 принципах, 7 процессах и 7 темах проекта.

  • 7 принципов определяют общие правила управления проектами по PRINCE2, определяют базу методологии;
  • 7 процессов определяют шаги продвижения по проектному циклу;
  • 7 тем – аспекты, по которым проводится контроль для достижения успеха проекта.

Кроме того, PRINCE2 рекомендует адаптировать методологию под каждую конкретную организацию.

В начале проекта PRINCE2 предлагает нам определить 3 основных аспекта проекта:

  • Бизнес-аспект (Принесёт ли этот проект выгоду?)
  • Потребительский аспект (Какой нужен продукт, что мы будем делать?)
  • Ресурсный аспект (Достаточно ли у нас всего, чтобы достичь цели?)

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

Согласно PRINCE2 у каждого члена команды есть своя чёткая роль в каждом из 7 процессов:

  • Начало проекта (Startingupaproject):В ходе данного процесса назначается менеджер проекта и определяются общие требования к характеристикам продукта. Менеджер проекта, чья основная задача – внимание к деталям, отчитывается перед Управляющим комитетом проекта, который отвечает за общее руководство проектом. Именно Управляющий комитет следит за тем, чтобы проект не сбился с курса, и он же полностью отвечает за успех проекта.
  • Инициация проекта (Initiationaproject):В ходе данного процесса менеджер проекта составляет «Документацию по инициации проекта», в которой содержится план проекта по стадиям. Стадии могут длиться разное количество времени, но, как и в классическом подходе, они следуют строго друг за другом.
  • Руководство проектом (Directingaproject): Данный процесс предоставляет возможность Управляющему комитету нести общую ответственность за успех проекта, не погружаясь в детали, которые находятся в границах полномочий менеджера проекта.
  • Контроль стадии (Controllingastage):При реализации проекта, даже в идеальных условиях, будут вноситься определённые изменения. Процесс «Контроль стадии» реализует один из принципов PRINCE2 – принцип управления по исключениям. В обязанности менеджера проекта входит отслеживать в ходе выполнения стадии отклонения от плановых параметров проекта по срокам, содержанию, бюджету и др. Если эти отклонения превышают данные руководителю проекта Управляющим комитетом полномочия (в терминологии PRINCE2 – допуски), менеджер проекта обязан проинформировать Управляющий комитет и предложить пути выхода из ситуации.
  • Управление созданием продукта (ManagingProductDelivery):Процесс управления созданием продукта представляет собой взаимодействие менеджера проекта и менеджера команды по созданию одного из продуктов проекта. В обязанности менеджера проекта в данном процессе входит делегирование полномочий по созданию продукта менеджеру команды и приемка созданного продукта.
  • Управление границами стадии (Managingastageboundary): В ходе данного процесса менеджер проекта предоставляет Управляющему комитету всю необходимую информацию для оценки результатов пройденной стадии и принятия решения о переходе на следующую стадию.
  • Завершение проекта (Closingaproject):Одно из отличий PRINCE2 в том, что процесс завершения проекта не выделяется в отдельный этап или стадию, как в классическом подходе, а выполняется в рамках финальной стадии создания продукта. Цель процесса – подтвердить, что продукт проекта принят, или проект больше не может принести ничего полезного.
Мастер Йода рекомендует:  Завершающие советы по разработке дополнений для WordPress

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

Сильные стороны PRINCE2

  • Адаптируемость к особенностям организации;
  • Наличие чёткого описания ролей и распределения ответственности;
  • Акцент на продуктах проекта;
  • Определённые уровни управления;
  • Фокус на экономической целесообразности;
  • Последовательность проектной работы;
  • Акцент на фиксации опыта и постоянном совершенствовании.

Слабые стороны PRINCE2

  • Отсутствие отраслевых практик;
  • Отсутствие конкретных инструментов для работы в проекте.

Лучшая система управления проектами … для Вас!

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

Как получить международный сертификат по Agile

Для тех, кто хочет получить систематизированное понимание Agile, разобраться с преимуществами и недостатками гибкого подхода к проектам и продуктам, найти области наилучшего применения Agile и получить международный сертификат ICAgile Certified Professional — наш тренинг «ICAgile Certified Professional»

Подборка книг для начинающего веб-разработчика

Мы сделали для вас подборку лучших книг для начала изучения веб-разработки. В неё вошли книги по JavaScript, Node.js, React.js, HTML, CSS, дизайну и паттернам проектирования.

JavaScript: cильные стороны

Автор книги — Дуглас Крокфорд, создатель формата JSON и инструментов JSLint и JSMin, а также активный участник в развитии JavaScript. Его книга «JavaScript: сильные стороны» стала классикой и must-have для прочтения всеми программистами, желающими изучить JavaScript. Она поясняет принципы объектно-ориентированного подхода, принятого в языке, и выделяет как крутые возможности JS (синтаксис, функции, объекты, динамическую типизацию, наследование, массивы, регулярные выражения и многое другое), так и не самые удобные фичи, например программную модель на глобальных переменных. Благодаря разбору языка с различных сторон вы сможете писать более качественный и элегантный код.

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

JavaScript. Подробное руководство

Книга за авторством Дэвида Фленагана поможет как новичкам, так и опытным специалистам наиболее полно освоить JavaScript. Она вполне подойдёт в качестве справочника, однако множество практических примеров даст возможность лучше разобраться в особенностях языка. В шестом издании рассматривается стандарт ECMAScript версии 5, а также HTML5.

Сначала в книге даются основы языка JavaScript. Затем читатель знакомится с разработкой сценариев при помощи JavaScript и DOM. Затем рассматриваются всевозможные классы, функции, методы, объекты, конструкторы и многое другое, что входит в язык JavaScript 1.8, движок V8 3.0, а также стандарт ECMAScript 5. После изучения базы языка книга переходит к другим технологиям, использующимся в реальных проектах, например технологии WebSockets и WebWorkers, объектам localStorage и sessionStorage, а также API браузеров.

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

You Don’t Know JS

Серия книг «You Don’t Know JS», написанная Кайлом Симпсоном, получила признание среди JavaScript-разработчиков. Она состоит из 6 небольших книг, объясняющих отдельные аспекты языка:

В первой книге даются основы программирования и базовый синтаксис JavaScript, а в последующих автор копает всё глубже, раскрывая читателю все возможности языка. Поэтому книга подойдёт как начинающим веб-программистам, так и более опытным JS-разработчикам. Если вам будет сложно читать на языке оригинала, то на GitHub есть неполный перевод серии на русский язык.

Eloquent JavaScript

Книга Марина Хавербеке (Marijn Haverbeke) «Eloquent JavaScript» стремится подать информацию о JavaScript так, чтобы заставить компьютеры делать то, что вам от них нужно. С самого начала автор всячески дополняет текст множеством различных примеров кода для лучшего понимания, а затем предлагает написать несколько достаточно крупных программ, к примеру, упрощённый язык программирования или программу для рисования. Благодаря такой практической части читатель сможет без проблем освоить синтаксис языка и правила эффективного и красивого кода, научиться писать базовые веб-приложения и использовать Node.js для создания серверов и утилит.

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

JavaScript. Шаблоны

Во многих проектах возникают проблемы, которые можно решить без изобретения велосипеда. Для этого разработчики прибегают к шаблонам проектирования — специальным алгоритмам, которые были придуманы и улучшены другими девелоперами. В книге «JavaScript. Шаблоны» ведущий специалист Yahoo! Стоян Стефанов разбирает шаблоны проектирования, подходящие для разработки на JavaScript, например синглтон (singleton), «фабрика» (factory) или «декоратор» (decorator). Также в книге разбираются альтернативы шаблонов, изначально предусматривавших статическую типизацию из других языков. Это будет особенно полезно программистам, знакомых с Си-подобными языками.

Node.js в действии

Node или Node.js — программная платформа, основанная на движке V8 (транслирующем JavaScript в машинный код), превращающая JavaScript из узкоспециализированного языка в язык общего назначения. В основном Node.js используется в качестве веб-сервера. Однако на основе библиотеки функционирует множество фреймворков, включая Electron (фреймворк для разработки десктопных программ) и React.js (фреймворк для кроссплатформенной разработки).

Книга «Node.js в действии» расскажет об основах Node.js, методиках, особенностях и технологиях разработки веб-приложений, фреймворках Electron, Connect и Express, использовании webpack и Gulp. Во втором издании книги авторы Алекс Янг, Брэдли Мек и Майк Кантелон актуализировали материал книги и добавили новую часть про Electron и построение приложений командной строки.

React в действии

Книга «React в действии» от Марка Тиленса Томаса поможет разобраться с особенностями разработки на React.js. Сначала в книге рассматривается DOM и компоненты. После этого автор рассказывает о данных, потоках данных, изменяемом и неизменяемом состоянии, рендеринге, методах жизненного цикла, маршрутизации, тестировании и интеграции сторонних библиотек. В третьей части книги уделяется внимание архитектуре приложения Redux, взаимодействию React и Redux, серверному рендерингу и основам React Native. В итоге вы получите достаточный объём знаний для создания собственных веб-приложений на чистом React.js.

Новая большая книга CSS

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

HTML5 и CSS3. Разработка сайтов для любых браузеров и устройств

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

Книга Бена Фрэйна рассказывает о том, как создать адаптивный дизайн своего сайта с помощью CSS3 и HTML5. Вы познакомитесь с медиазапросами в контексте адаптивного дизайна, динамически изменяемой разметкой, способами создания эффектов, переходов и анимаций, форматом SVG для изображений и многими другими аспектами адаптивного дизайна.

Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement

Аарон Густафсон в своей книге стремился донести до разработчиков философию и механизмы принципа прогрессивного улучшения (progressive enhancement). Благодаря этому подходу пользователи, заходящие на сайт, будут видеть реактивно загружающийся контент, а не пустую страницу. Помимо объяснения теории, Аарон дополнил свою книгу множеством примеров на JavaScript, HTML и CSS.

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

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

Пожалуй, лучшая книга об Agile

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

Сколько проживет Agile среди разработчиков, которые пишут код также, как без Agile? Пройдет от силы 2-3 (ну 4, если понравится клеить стикеры на доску) итерации и все сделают вывод, что скрам не работает. Это классика жанра. Поэтому перед внедрением гибких методологий обязательно донесите основные принципы до разработчиков и проконтролируйте, чтобы они выполнялись. Иначе все остановится на уровне Scrum-артефактов.

А, да. Еще в книге есть любопытная глава «Как продать Scrum заказчику?»

Среди неоспоримых преимуществ скрама для Клиентов можно выделить следующие:

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

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

20 самых рекомендуемых книг для программистов на русском языке

Авторы проекта Dev-Books проанализировали миллионы вопросов и ответов в крупнейшем сообществе программистов Stack Overflow. Всё для того, чтобы найти книги, на которые чаще всего ссылаются разработчики.

В общий список вошло 5 720 книг. Ниже вы найдёте 20 самых упоминаемых из них, которые когда-либо выходили на русском.

По просьбе Лайфхакера своими мнениями насчёт некоторых изданий поделились отечественные эксперты.

1. «Эффективная работа с унаследованным кодом», Майкл К. Физерс

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

2. «Приёмы объектно-ориентированного проектирования. Паттерны проектирования», Эрих Гамма и другие

Классика для программиста. Первая книга, посвящённая именно шаблонам.

Леонид Выговский, системный архитектор IT-компании LiveTex

— Издание уже 20 лет переиздаётся в изначальном виде. В этом, конечно, главный недостаток книги: некоторые шаблоны уже неактуальны. Думаю, её полезно читать уже после других, более современных, книг по паттернам проектирования. Тем более что она написана сухим академическим языком. Для понимания паттернов эта книга не must read, но её прочтение добавляет крутости в глазах коллег-программистов. 🙂 Начинать я советую с «Паттернов проектирования» (Head First Design Patterns).

3. «Чистый код. Создание, анализ и рефакторинг», Роберт К. Мартин

Интересная, но во многом спорная книга о том, как писать понятный и поддерживаемый код.

Леонид Выговский, системный архитектор IT-компании LiveTex

— Почему спорная? Книг про написание кода уже огромное количество, и часть приёмов являются общепризнанными. Но каждый автор добавляет что-то своё. Лично для меня мнение Боба Мартина кажется иногда странным и противоречащим другим источникам. Не must read, но прочитать всё же стоит. Качество кода после прочтения становится лучше.

4. «Предметно-ориентированное проектирование», Эрик Эванс

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

Леонид Выговский, системный архитектор IT-компании LiveTex

— Из этой книги выросли концепции СQRS, BDD, onion-architecture и много других интересных идей. Единственный недостаток: книга насквозь теоретическая. Практическую пользу она приобрела только с выходом книги Вона Вернона «Реализация методов предметно-ориентированного проектирования» (Implementing Domain Driven Design). Поэтому читать их надо последовательно, сразу друг за другом.

5. «JavaScript: сильные стороны», Дуглас Крокфорд

Обязательная книга для веб-разработчиков. В ней Дуглас Крокфорд рассказывает о преимуществах языка JavaScript и учит грамотно их применять для создания эффективного кода.

6. «Шаблоны корпоративных приложений», Мартин Фаулер и другие

Книга описывает базовые принципы проектирования ПО для корпоративных платформ.

7. «Совершенный код. Мастер-класс», Стив Макконнелл

Классическая книга о том, как писать код лучше.

Михаил Осотов, директор по производству «Центра высоких технологий»

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

8. «Рефакторинг. Улучшение существующего кода», Мартин Фаулер и другие

Из серии книг по написанию понятного и качественного кода, «Рефакторинг» — лучшая.

Леонид Выговский, системный архитектор IT-компании LiveTex

Выговский: «Она не только показывает хороший код, но и на примере плохого объясняет, чем именно он плох. Эта книга — must read для всех. Причём чем раньше вы её прочтёте, тем лучше. Качество кода после прочтения сильно вырастет».

Если книгу Фаулера вы уже прочли, обратите внимание на «Рефакторинг с использованием шаблонов» (Refactoring to Patterns) Джошуа Кериевски, которую рекомендует Михаил Осотов.

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

Михаил Осотов, директор по производству «Центра высоких технологий»

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

9. «Паттерны проектирования», Эрик Фримен, Элизабет Фримен и другие

Серия Head First, на мой взгляд, идеально подходит для новичков в области разработки ПО.

Михаил Осотов, директор по производству «Центра высоких технологий»

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

10. «Язык программирования C», Брайан У. Керниган, Деннис М. Ритчи

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

11. «Эффективное использование С++. 55 верных способов улучшить структуру и код ваших программ», Скотт Майерс

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

12. «Экстремальное программирование: разработка через тестирование», Кент Бек

Автор на примерах описывает методику разработки ПО, которая предполагает тестирование программ ещё до написания их кода.

13. «Алгоритмы. Построение и анализ», Томас Х. Кормен и другие

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

14. «Регулярные выражения», Джеффри Фридл

Издание об эффективной работе с текстом в Perl, PHP, Java, Python, Ruby и других языках программирования.

15. «CLR via C#. Программирование на платформе Microsoft.NET Framework 4.5 на языке C#», Джеффри Рихтер

Классический учебник по разработке приложений для платформы Microsoft, в том числе с помощью Silverlight, Windows Presentation Foundation, ASP.NET и прочих технологий компании.

16. «Современное проектирование на C++», Андрей Александреску

Книга для опытных программистов на C++. Автор предлагает новый подход к разработке, сочетающий метапрограммирование шаблонов, обобщённое программирование и объектно-ориентированное программирование на этом языке.

17. «Microsoft ASP.NET 2.0. Базовый курс», Дино Эспозито

Детальное руководство для опытных специалистов по ASP.NET 2.0. Книга учит создавать мощные, надёжные и масштабируемые сайты на этой платформе.

18. «Шаблоны тестирования xUnit. Рефакторинг кода тестов», Джерард Месарош

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

19. «Компиляторы. Принципы, технологии и инструментарий», Альфред В. Ахо и другие

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

20. «Инфраструктура программных проектов. Соглашения, идиомы и шаблоны для многократно используемых библиотек .NET», Кржиштоф Цвалина, Брэд Абрамс

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

Полный рейтинг англоязычных книг доступен на сайте Dev-Books. Там же можно просмотреть списки самых популярных книг на определённые темы, будь то Java, Database Design или CSS.

ТОП-5 книг, которые должен прочитать каждый project manager

Чтение и осмысление прочитанного является одним из важных путей развития в любой сфере. У каждого успешного менеджера есть любимая книга (и не одна), которая когда-то вдохновила его на то, чтобы добиться признания и вершин мастерства в своем деле. И мы решили спросить нашего эксперта по управлению проектами, командообразованию и коммуникациям Дмитрия Башакина, какие книги, по его мнению, должен обязательно прочитать каждый project manager? Конечно, предложенный список – это самый минимум необходимой литературы (и совершенно недостаточный, чтобы стать управленцем-профессионалом). Надеемся, что полученные знания сыграют значимую роль в вашем карьерном росте.

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

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

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

Единственная книга в этом обзоре, которая до сих пор не переведена на русский, но обойти ее я просто не могу. Да, это классический project managementпо PMBoK-у. Да, это не самое легкое и увлекательное чтение. Но польза будет однозначно, многие разрозненные вещи сложатся, наконец, в стройную систему. И неважно, что вы не собираетесь PMP-сертифицироваться – достаточно желания управлять проектами по-взрослому.

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

Полученные в книгах навыки по управлению проектами стоит закрепить на тренингах.

Разработка требований — 9 книг

Все, что связано с разработкой требований и анализом (бизнес/системным) и около полезные вещи.

ISBN: 978-5-85582-326-4
Год издания: 2012
Издательство: Лори
Язык: Русский

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

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

ISBN: 5-7502-0240-2
Год издания: 2004
Издательство: Русская Редакция
Язык: Русский

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

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

Книга состоит из 23 глав, 4 приложений, словаря терминов и библиографического списка.

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

ISBN: 978-5-9775-3348-5, 978-5-7502-0433-5
Год издания: 2014
Издательство: Русская Редакция, БХВ-Петербург
Язык: Русский

Эта книга — подробное руководство по разработке качественных требований к программному обеспечению. Здесь описаны десятки проверенных на практике приемов выявления, формулирования, разработки, проверки, утверждения и тестирования требований, которые помогут разработчикам, менеджерам и маркетологам создать эффективное ПО. Настоящее издание дополнено новыми приемами, посвященными разработке требований в проектах гибкой разработки (agile).

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

Эта книга — подробное руководство по разработке качественных требований к программному обеспечению. Здесь описаны десятки проверенных на практике приемов выявления,…

ISBN: 978-5-459-01084-8
Год издания: 2012
Издательство: Питер
Язык: Русский

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

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

ISBN: 978-5-517-60923-6
Год издания: 2013
Издательство: Книга по Требованию
Язык: Русский

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

Эта книга о том, как собирать, документировать и проверять требования. Она рассчитана на самый широкий круг читателей: начинающих аналитиков, проектировщиков, архитекторов,…

ISBN: 5-8459-0275-4, 0-2020-1593-2
Год издания: 2002
Издательство: Захаров
Язык: Русский
ISBN: 978-5-8459-1795-9
Год издания: 2012
Издательство: Вильямс
Серия: Signature Series
Язык: Русский

‘ В этой книге, выхода которой с нетерпением ожидало сообщество сторонников гибких методологий разработки программного обеспечения, описывается процесс подготовки требований к разрабатываемой системе, который позволяет экономить время, избавляет от необходимости в переделках и ведет к созданию более совершенных программ. Лучший способ создать программное обеспечение, максимально полно удовлетворяющее потребностям пользователей, — начать с пользовательских историй. Это простые, понятные и краткие описания функциональности, которая представляет деловую ценность для реальных пользователей. В книге приводятся подробные рекомендации относительно того, как следует писать пользовательские истории и включать их в жизненные циклы разработки проекта. Вы узнаете, что такое хорошие пользовательские истории и что делает истории плохими. Вы познакомитесь с практическими методами сбора историй, позволяющими добиться хороших результатов даже тогда, когда возможность непосредственного общения с пользователями отсутствует. Автор демонстрирует, как систематизировать подготовленные пользовательские истории, установить для них приоритеты и эффективно применять для решения задач планирования, разработки и тестирования программного обеспечения. — Моделирование пользовательских ролей. — Сбор историй: опрос пользователей, анкетный метод, наблюдение, собрания. — Работа с менеджерами, инструкторами, продавцами и другими представителями пользователей. — Написание пользовательских историй для приемочного тестирования. — Использование историй для ранжирования задач, составления графиков работ и оценки трудозатрат. — В конце каждой главы приводится список контрольных вопросов и упражнений для самопроверки. Книга будет полезна разработчикам, тестировщикам, аналитикам и менеджерам проектов, использующим любую гибкую методологию программного обеспечения: XP, Scrum. и даже собственный гибкий подход.

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

Книги про управление IT проектами

Предлагаем вашему вниманию небольшой обзор книг об управлении проектами.

ОГЛАВЛЕНИЕ

SCRUM Революционный метод управления проектами. Дж. Сазерленд

Издательство: Манн, Иванов и Фербер, 2020. 320 страниц

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

1. Делим задачу на этапы (спринты). У каждого этапа должен быть видимый результат. Грубо говоря, если нужно написать 100 писем, после первого этапа должно быть готово/отправлено определенное количество писем, а не написано 100 черновиков, требующих доработки.

Мастер Йода рекомендует:  Задачи на логику помогите таракану, посчитайте множители и побудьте диспетчером

2. После этапа анализируем производительность, что можно улучшить ит.д., чтобы следующий этап был лучше.

3. Во время этапа каждый день задаем каждому члену группы 3 вопроса:
Что ты сделал вчера?
Что будешь делать сегодня?
Какие есть препятствия?

4. Бэклог проекта — список требований и идей, из которого формируем задание для следующего спринта.

5. Владелец продукта — ведет бэклог, знает всё о разработке и ситуации на рынке, отвечает за полезность продукта.

Ещё интересно написано об индексе счастья. Счастливый человек достигает больше и лучше, счастье надо измерять и от спринта к спринту думать, что сделает тебя/команду ещё счастливее.

Искусство управления IT-проектами. Скотт Беркун

Издательство: Питер, 2014. 700 страниц

Один из руководителей отдела разработки Internet Explorer. Всю книгу меня настойчиво преследовала мысль: «Вот поэтому Эксплорер такой и получается». Особенно после книги о скрам-технологиях.

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

1. Правило трех частей: проектирование, разработка, тестирование.

2. Базовые показатели доверия к расчетам (40-70-90%).

3. В календарном плане нужно учитывать болезнь и отпуска сотрудников.

4. Регулярный анализ выполнения календарных планов

5. Контрольные точки в плане

Критерии для технических требований.

Гибкое управление IT-проектами. Руководство для настоящих самураев. Дж. Расмуссон

Издательство: Питер, 2012. 340 страниц

Подход к разработке, который шире, чем Scrum (то есть Scrum — это один из его вариантов).
Тоже бьём задачу на части.

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

2. Проектирование, написание кода, анализ — непрерывный процесс (а не последовательный, как в классической модели).

3. В процессе разработки цели/задачи/объёмы могут поменяться в соответствии с актуальным курсом клиента.

4. Польза концепции проекта и прототипов.

5. Ответственность разработчика за деньги, сроки, результат.

6. Командная работа.

Remote: офис не обязателен. Дэвид Хенссон, Джеймсон Фрайд

Издательство: Манн, Иванов и Фербер, 2014. 160 страниц

От создателей Rework: бизнес без предрассудков 🙂 🙂

Книга-рассуждение о работе на удалёнке.

Скорее книга-мотивация или книга-настроение, чем книга-инструкция, но полезные моменты есть.

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

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

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

У нас в анкете для той же цели служит вопрос: Почему мы должны взять именно Вас? Тоже цель — просто проверить грамотность и адекватность 🙂

Наша студия специализируется на внедрении Битрикс24 и автоматизации Бизнес-процессов в Битрикс24. Обращайтесь!
Битрикс24 — удобный инструмент для увеличения эффективности работы компании.

При регистрации используйте промокод ниже для получения дополнительных бонусов (можно использовать только 1 промо-код):

  • Используйте промокод positive2bst и получите бесплатно дополнительно 12 пользователей на 6 месяцев!
  • Используйте промокод positive2bs2 и получите бесплатно дополнительные 5 гб на 1 год!

Заполняйте форму, размещенную ниже, и получите бесплатно учебник по основам работы с Битрикс24.

Agile — популярные книги

ISBN: 978-5-00100-424-0
Год издания: 2020
Издательство: Манн, Иванов и Фербер
Язык: Русский

Книга основателя методики Scrum, которая поможет вам реализовывать проекты в несколько раз быстрее и эффективнее.
Возможно, историки будущего будут разделять прогресс человечества четкой линией: «до Scrum» и «после» — настолько эта методика революционна. Её используют в большинстве технологичных компаний мира, но теперь она доступна всем, кто имеет дело со сложными проектами в любой отрасли.
Джефф изобрел свою методику, пытаясь справиться с недостатками классического управления проектами: людям редко удается работать слаженно, эффективно и быстро, большинство планов не выполняются (ни по времени, ни по ресурсам), подразделения и команды часто выполняют противоречащие друг другу задачи или дублируют их.
За 20 лет существования Scrum помогла не только большинству разработчиков программного обеспечения, но и ФБР, автопроизводителям, фармацевтам и простым людям, планирующим свои дела.
Эта книга полностью перевернет ваш подход к управлению проектами и поможет достичь результатов, которые раньше казались невозможными. Неважно, хотите ли вы изменить систему образования, изобретать новые технологии, бороться с голодом, просто открыть стартап или управлять своей командой в разы эффективнее — Scrum поможет вам успевать больше, затрачивая меньше времени и ресурсов.

Книга основателя методики Scrum, которая поможет вам реализовывать проекты в несколько раз быстрее и эффективнее.
Возможно, историки будущего будут разделять прогресс…

Год издания: 2007
Язык: Русский
Язык: Русский
ISBN: 5-8459-0558-3, 0-13-597444-5
Год издания: 2004
Издательство: Вильямс
Язык: Русский

Роберт Мартин в соавторстве с Джеймсом Ньюкирком и Робертом Коссом предлагает вниманию читателей книгу о различных методиках быстрого (и даже экстремального) программирования. Изложение начинается с обзора основных понятий экстремального

Роберт Мартин в соавторстве с Джеймсом Ньюкирком и Робертом Коссом предлагает вниманию читателей книгу о различных методиках быстрого (и даже экстремального) программирования.…

ISBN: 978-0-557-13832-6
Год издания: 2010
Издательство: C4Media Inc
Год издания: 2012
Язык: Русский
ISBN: 978-5-00100-614-5
Год издания: 2020
Издательство: Манн, Иванов и Фербер
Язык: Русский

Подробное руководство по четырем основным agile-методологиям, по которому легко и интересно учиться.

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

Что изменится после прочтения этой книги?

Вы поймете идеи, которыми руководствуются эффективные Agile-команды, а также ценности и принципы, которые их объединяют;
Вы познакомитесь с самыми популярными школами — Scrum, экстремальным и бережливым программированием и техникой Kanban — и поймете, как все они могут относиться к Agile-методологиям, несмотря на то, что очень отличаются друг от друга;
Вы узнаете о конкретных Agile-методах, которые сможете сразу внедрить в свои проекты, и познакомитесь с базовыми ценностями и принципами, которые понадобятся для того, чтобы это внедрение было эффективным.
Вы сможете лучше понимать свою команду и компанию, чтобы выбрать тот Agile-подход, который соответствует вашему мировоззрению (или максимально близок к нему);
Вы узнаете, для чего работать с agile-коучем и как он может помочь вам и вашей команде изменить свой подход и начать внедрять гибкие методологии.
Для кого эта книга

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

Подробное руководство по четырем основным agile-методологиям, по которому легко и интересно учиться.

Эта книга рассказывает о самых популярных Agile-методологиях — Scrum, XP…

ISBN: 9780578012810
Год издания: 2006
Издательство: 37signals
Язык: Английский

Getting Real details the business, design, programming, and marketing principles of 37signals. The book is packed with keep-it-simple insights, contrarian points of view, and unconventional approaches to software design. This is not a technical book or a design tutorial, it’s a book of ideas. Anyone working on a web app — including entrepreneurs, designers, programmers, executives, or marketers — will find value and inspiration in this book. 37signals used the Getting Real process to launch five successful web-based applications (Basecamp, Campfire, Backpack, Writeboard, Ta-da List), and Ruby on Rails, an open-source web application framework, in just two years with no outside funding, no debt, and only 7 people (distributed across 7 time zones). Over 500,000 people around the world use these applications to get things done. Now you can find out how they did it and how you can do it too. It’s not as hard as you think if you Get Real.

Getting Real details the business, design, programming, and marketing principles of 37signals. The book is packed with keep-it-simple insights, contrarian points of view, and…

ISBN: 978-5-00100-896-5
Год издания: 2020
Издательство: Манн, Иванов и Фербер
Серия: МИФ. Бизнес
Язык: Русский

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

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

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

Эта книга о построении высокопроизводительных…

ISBN: 978-5-85582-299-1, 0-9745140-8-X
Год издания: 2009
Издательство: Лори
Язык: Русский
ISBN: 978-5-459-01205-7
Год издания: 2012
Издательство: Питер
Язык: Русский

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

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

ISBN: 978-5-8459-1739-3, 978-0-321-60191-9
Год издания: 2011
Издательство: Вильямс
Серия: Signature Series
Язык: Русский

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

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

ISBN: 978-1617291050
Год издания: 2014
Издательство: Manning Publications
ISBN: 978-5-00117-349-6
Год издания: 2020
Издательство: Манн, Иванов и Фербер
Язык: Русский

Практичное, короткое, иллюстрированное и конкретное руководство по достижению результатов с помощью Scrum.

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

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

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

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

Основываясь на 15-летнем опыте, Зузана Шохова рассказывает, какие роли и обязанности есть у скрам-мастера, как ему решать повседневные задачи, какие компетенции нужны, чтобы стать выдающимся скрам-мастером, какими инструментами ему нужно пользоваться.

Практичное, короткое, иллюстрированное и конкретное руководство по достижению результатов с помощью Scrum.

Роль скрам-мастера является одной из самых недооцененных ролей в…

ISBN: 978-0132350884, 0-13-235088-2
Год издания: 2008
Издательство: Prentice Hall
Язык: Английский

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.

Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship . Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.

What kind of work will you be doing? You’ll be reading code—lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.

Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.

Readers will come away from this book understanding

How to tell the difference between good and bad code
How to write good code and how to transform bad code into good code
How to create good names, good functions, good objects, and good classes
How to format code for maximum readability
How to implement complete error handling without obscuring code logic
How to unit test and practice test-driven development

This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.

Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because…

Programming stuff

Страницы

понедельник, 16 июня 2014 г.

Хорошая, модная и плохая гибкая разработка

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

Бертран Мейер «Agile!: The Good, the Hype and the Ugly»

Сейчас гибкие методы (agile methods) являются чуть ли не стандартом в современной разработке ПО. Все проводят статус митинги, ретроспективы, пишут user stories и тест-кейсы, делают частые релизы и привлекают бизнес-пользователей; ненавидят «водопадные» методы и доказывают вред переработок. Часть принципов и практик гибкой разработки стали частью нашей жизни, и уже появилось целое поколение разработчиков, которые даже не слышали про альтернативные методологии.

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

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

ЦИТАТА
Когда мы выяснили недостатки догматичного следования идеям гибки методологий, мы должны постараться не попасть в аналогичную ловушку сами и постараться быть умеренными в своих суждениях. Эта книга пытается объяснить когда и как предписания гибких методологий должны быть заменены или объединены с другими техниками. Примером может служить компромисс между «гибкими» правилами о создании работающей системе на каждом шаге и пользе от создания программной инфраструктуры, которая не дает немедленных видимых результатов для пользователя.

Лично для меня каждая из приведенных выше составляющих очень важна. Если посмотреть внимательно на развитие нашей отрасли, то легко можно заметить, что она эволюционирует и строится на базе знаний и опыта, полученных ранее. И гибкие методы, тоже не являются в этом плане исключением. Так, например, итеративная разработка появилась в 70-х, труды по управлению требованиями и идея непрерывной интеграции – в 80-х, критика классического «водопада», опасности переработок, важности коммуникаций и того раньше. Таким образом, можно сказать, что гибкие методы – это очередной виток эволюции в разработке ПО, который делает акцент на определенном наборе практик, не столь популярных ранее, и уменьшает важность других практик, без которых разработка ПО считалась невозможной.

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

О важности понимания решаемой проблемы

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

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

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

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

Простота и борьба с изменениями

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

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

Данное стремление является основополагающим в гибких методологиях и даже зафиксировано в одном из принципов в agile-манифесте:

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

При этом конкретные методологии разработки, например, XP (eXtreme Programming) предлагают конкретные решения, как обеспечить выполнение данного принципа: «начинайте с самого простого рабочего решения и усложняйте его лишь тогда, когда этого будут требовать тесты» (start with the simple thing that could possible work and add complexity only when it’s required by tests) (еще одно описание простоты см. в «Simplicity is the Key»).

ПРИМЕЧАНИЕ
Бертран Мейер в своей книге дает достаточно формальное определение того, что такое принцип (разработки, проектирования), и чем от отличается от практики. Так вот, принцип – абстрактен, а практика – конкретна. Так, например, «будьте готовы к изменениям требованиям» – это принцип, а «используйте самое простое решение для достижения расширяемости системы» – это практика.

Несмотря на то, что совет по поводу простоты очень правильный, но он не такой простой, как кажется! (pun intended). У Рича Хики есть замечательное выступление, под названием «Simple Made Easy», о котором я писал как-то в Г+, в котором отлично показано, что «простота» (simplicity) – это не одно и тоже, что и «легкость» (easiness). Простое решение обычно отличается элегантностью и отсутствием лишнего, а легкое решение зачастую бывает примитивным и тяжелым для сопровождения, но самым легким в достижении.

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

ЦИТАТА
Каждый, кто когда-либо приходил к первому решению некоторой задачи замечал, что оно является слишком сложным, а попытка упростить его обычно означает увеличение трудозатрат, причем иногда – существенное.
Как и в других случаях, критика гибких методов некоторых общих практик является корректной: программисты заниматься ненужным и необоснованным обобщением. Но это не оправдывает отказ от проверенных практик, которые заключаются если не в попытке покрыть «самый общий случай», то как минимум случай более общий, чем текущий.
Негативный эффект от таких заявлений усиливается тем, что фундаментальная проблема изменений программного обеспечения является архитектурной. Простота изменений не возникает из воздуха: для этого архитектура решения должна быть спроектирована соответственно. Хорошие учебники учат этому, но такие Big Upfront задумки рьяно отвергаются сторонниками гибких методов.
Защита гибкими авторами изменений является правильной целью, но правильна здесь лишь цель, а не средства ее достижения.
Было бы хорошо верить в заклинание, что можно начать «с самого простого решение, которое только лишь может работать», и затем постепенно изменяя архитектуру прийти к великолепной системе. Но, к сожалению, это не так.

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

Тут очень интересно проследить сходства и различия в подходах представителя «классической» школы – Бертрана Мейера («папы» проектирования по контракту) и яркого представителя гибкой разработки – Кента Бека («папы» TDD и XP). Несмотря на видимые различия в подходах, Бек и Мейер предлагают лишь разные пути для достижения одной и той же цели.

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

Аналогичная картина есть и в вопросах «гибкости» решения. «Гибкие» авторы явно высказываются против «гибких» решений (и снова pun intended), поскольку чрезмерное обобщение может привести к усложнению решения, да и вообще не факт, что это обобщение возможно. Эта же проблема очевидна представителям и старой школы, поэтому тот же Мейер предложил более формальный подход ее решения: обобщать можно и нужно, но лишь тогда, когда польза от этого будет очевидна, например, в конце итерации!

ПРИМЕЧАНИЕ
Подробнее о пользе принятия решения на более поздних этапах см. заметку «Идеальная архитектура», а более полное описание подхода Мейера к повторному использованию кода см. в заметке «О повторном использовании кода».

О книге Бертрана Мейера «Agile! The Good, the Hype and the Ugly»

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

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

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

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

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

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

Цитаты и их обсуждения

Я уже довольно давно по мере чтения книги делюсь своими мыслями и цитатами в Г+ (и даже сделал для этого фид). В этом случае, по количеству цитат и мыслей можно судить, насколько сильное впечатление оказала та или иная книга. Несмотря на скромный размер (160 страниц) мыслей оказалось довольно много:

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