0 added
0 removed
Original
2026-01-01
Modified
2026-02-21
1
<p>Разработчики хотят упростить жизнь себе и коллегам по цеху: создают новые методологии разработки, например, экстремальное программирование. Менеджеры не отстают, смотрят по сторонам, обобщают опыт и придумывают свои методы управления. Так, например, появился экстремальный менеджмент.</p>
1
<p>Разработчики хотят упростить жизнь себе и коллегам по цеху: создают новые методологии разработки, например, экстремальное программирование. Менеджеры не отстают, смотрят по сторонам, обобщают опыт и придумывают свои методы управления. Так, например, появился экстремальный менеджмент.</p>
2
<p>Термин "экстремальное управление проектами" придумал эксперт по менеджменту Дуг ДеКарло в 2004 году. На самом деле он просто собрал опыт разных компаний, проанализировал, выделил самое лучшее и получил авторский метод менеджмента. Весь процесс управления по ДеКарло основан на принципах экстремального программирования<em>(Extreme Programming)</em>.</p>
2
<p>Термин "экстремальное управление проектами" придумал эксперт по менеджменту Дуг ДеКарло в 2004 году. На самом деле он просто собрал опыт разных компаний, проанализировал, выделил самое лучшее и получил авторский метод менеджмента. Весь процесс управления по ДеКарло основан на принципах экстремального программирования<em>(Extreme Programming)</em>.</p>
3
<a>Источник</a><p><strong>Экстремальное программирование (<em>XP</em>)</strong> - гибкая методология разработки программного обеспечения. По сути, это все - лучшие практики<em>Agile</em>, но используемые по максимуму.<em>XP</em>сформулировал и впервые использовал американский разработчик Кент Бек в конце 90-х годов.</p>
3
<a>Источник</a><p><strong>Экстремальное программирование (<em>XP</em>)</strong> - гибкая методология разработки программного обеспечения. По сути, это все - лучшие практики<em>Agile</em>, но используемые по максимуму.<em>XP</em>сформулировал и впервые использовал американский разработчик Кент Бек в конце 90-х годов.</p>
4
Особенности экстремального программирования и менеджмента<p>Главная особенность XP - методология применима только в сфере разработки программного обеспечения. Ее не использовать там, где нет никакого digital-продукта.</p>
4
Особенности экстремального программирования и менеджмента<p>Главная особенность XP - методология применима только в сфере разработки программного обеспечения. Ее не использовать там, где нет никакого digital-продукта.</p>
5
В основе экстремального программирования - agile-манифест. И принципы<em>Agile</em>.<p> XP - это agile-методология, но она опирается на свои ценности.</p>
5
В основе экстремального программирования - agile-манифест. И принципы<em>Agile</em>.<p> XP - это agile-методология, но она опирается на свои ценности.</p>
6
<p><strong>Основные ценности XP</strong></p>
6
<p><strong>Основные ценности XP</strong></p>
7
<p>Простота</p>
7
<p>Простота</p>
8
<p>Упрощение кода и процесса работы.</p>
8
<p>Упрощение кода и процесса работы.</p>
9
<p>Коммуникация</p>
9
<p>Коммуникация</p>
10
<p>Не быть отшельником, а взаимодействовать с коллегами, чтобы быстрее искать решения проблем.</p>
10
<p>Не быть отшельником, а взаимодействовать с коллегами, чтобы быстрее искать решения проблем.</p>
11
<p>Обратная связь</p>
11
<p>Обратная связь</p>
12
<p>Постоянно общаться с заказчиком и следить за изменениями требований.</p>
12
<p>Постоянно общаться с заказчиком и следить за изменениями требований.</p>
13
<p>Смелость</p>
13
<p>Смелость</p>
14
<p>Не бояться рисковать и использовать новые непроверенные практики.</p>
14
<p>Не бояться рисковать и использовать новые непроверенные практики.</p>
15
<p>Уважение</p>
15
<p>Уважение</p>
16
<p>Уважать себя, коллег, правила и цели проекта.</p>
16
<p>Уважать себя, коллег, правила и цели проекта.</p>
17
<p>Как и у любой другой методологии, у XP есть свой набор практик, на которых строится вся работа.</p>
17
<p>Как и у любой другой методологии, у XP есть свой набор практик, на которых строится вся работа.</p>
18
<p>Два разработчика садятся за один компьютер и пишут код. Не каждый свою версию, а вместе работают над одной функцией продукта. Сначала решение предлагает один разработчик, второй наблюдает и по ходу комментирует и исправляет ошибки. Потом программисты меняются местами и процесс повторяется.</p>
18
<p>Два разработчика садятся за один компьютер и пишут код. Не каждый свою версию, а вместе работают над одной функцией продукта. Сначала решение предлагает один разработчик, второй наблюдает и по ходу комментирует и исправляет ошибки. Потом программисты меняются местами и процесс повторяется.</p>
19
<p>Из двух решений в процессе работы выбирают лучшее и чистят код до идеального состояния. Работает принцип - две головы лучше, чем одна. Но это вызывает много споров среди разработчиков, так как они привыкли работать и отвечать за результат в одиночку.</p>
19
<p>Из двух решений в процессе работы выбирают лучшее и чистят код до идеального состояния. Работает принцип - две головы лучше, чем одна. Но это вызывает много споров среди разработчиков, так как они привыкли работать и отвечать за результат в одиночку.</p>
20
<p>Подготовка к тестированию начинается еще до начала написания кода. Программист сначала пишет тесты и только потом - код.</p>
20
<p>Подготовка к тестированию начинается еще до начала написания кода. Программист сначала пишет тесты и только потом - код.</p>
21
<p>Любой разработчик может править код, который написал его коллега по команде.</p>
21
<p>Любой разработчик может править код, который написал его коллега по команде.</p>
22
<p><strong>Единое оформление кода</strong></p>
22
<p><strong>Единое оформление кода</strong></p>
23
<p>Чтобы код выглядел одинаково, даже если его писали пять разных программистов, команда использует единый стиль. Если все работают над одним проектом, то заранее оговаривают фреймворки, которые будут задействованы.</p>
23
<p>Чтобы код выглядел одинаково, даже если его писали пять разных программистов, команда использует единый стиль. Если все работают над одним проектом, то заранее оговаривают фреймворки, которые будут задействованы.</p>
24
<p><strong>Непрерывная интеграция</strong></p>
24
<p><strong>Непрерывная интеграция</strong></p>
25
<p>Новые части кода постоянно встраивают в уже имеющийся. Так разработчикам проще выявлять ошибки. Если после вставки нового кода, добавления новой функции система перестала работать правильно, программист понимает, где искать ошибку.</p>
25
<p>Новые части кода постоянно встраивают в уже имеющийся. Так разработчикам проще выявлять ошибки. Если после вставки нового кода, добавления новой функции система перестала работать правильно, программист понимает, где искать ошибку.</p>
26
<p><strong>Общее видение системы</strong></p>
26
<p><strong>Общее видение системы</strong></p>
27
<p>Чтобы программисты одинаково понимали результат, который должны получить, используется метафора. Систему сравнивают с чем-то, что понятно и знакомо всем в команде. Так формируется единое видение.</p>
27
<p>Чтобы программисты одинаково понимали результат, который должны получить, используется метафора. Систему сравнивают с чем-то, что понятно и знакомо всем в команде. Так формируется единое видение.</p>
28
<p><strong>Никаких переработок</strong></p>
28
<p><strong>Никаких переработок</strong></p>
29
<p>Для высокой продуктивности важно физическое и эмоциональное состояние команды. Поэтому переработки в XP не приветствуются. Норма работы - не более40 часов в неделю. Это дает возможность команде выложиться по максимуму, но не перегореть.</p>
29
<p>Для высокой продуктивности важно физическое и эмоциональное состояние команды. Поэтому переработки в XP не приветствуются. Норма работы - не более40 часов в неделю. Это дает возможность команде выложиться по максимуму, но не перегореть.</p>
30
<p>Все начинается с выяснения требований и планирования. Задачи записывают на карточки, выясняют у заказчика последовательность, в которой он хочет получать функционал продукта. Карточки располагают по приоритетности. По схожей системе работают команды в Scrum и Kanban.</p>
30
<p>Все начинается с выяснения требований и планирования. Задачи записывают на карточки, выясняют у заказчика последовательность, в которой он хочет получать функционал продукта. Карточки располагают по приоритетности. По схожей системе работают команды в Scrum и Kanban.</p>
31
Схема работы Scrum и Kanban. <a>Источник</a><p>Команда анализирует информацию, оценивает время на каждую задачу. Согласовывает все с заказчиком и начинает работу над проектом. Требования часто меняются, поэтому процесс делят на короткие этапы с частыми релизами, как и в Scrum.</p>
31
Схема работы Scrum и Kanban. <a>Источник</a><p>Команда анализирует информацию, оценивает время на каждую задачу. Согласовывает все с заказчиком и начинает работу над проектом. Требования часто меняются, поэтому процесс делят на короткие этапы с частыми релизами, как и в Scrum.</p>
32
<p>Прежде чем начать, команда создает тесты, которые будет использовать для проверки готового кода. Когда тесты готовы, разработчики пишут первую часть кода. Тестируют ее, а потом приступают ко второй. Постепенно появляется все больше маленьких частей кода, которые в процессе добавляют в единую систему. Части кода и функции будущего продукта наращивают постепенно, как снежный ком. После каждого релиза команда собирает обратную связь, чтобы двигаться дальше.</p>
32
<p>Прежде чем начать, команда создает тесты, которые будет использовать для проверки готового кода. Когда тесты готовы, разработчики пишут первую часть кода. Тестируют ее, а потом приступают ко второй. Постепенно появляется все больше маленьких частей кода, которые в процессе добавляют в единую систему. Части кода и функции будущего продукта наращивают постепенно, как снежный ком. После каждого релиза команда собирает обратную связь, чтобы двигаться дальше.</p>
33
<p><em>XP</em>и экстремальный менеджмент - части одной большой системы. Они взаимосвязаны, так как когда-то принципы методологии разработки повлияли на способ управления проектами. И теперь идеи<em>XP</em>можно применять не только к процессу написания кода, но и к работе менеджера. Как это сделать?</p>
33
<p><em>XP</em>и экстремальный менеджмент - части одной большой системы. Они взаимосвязаны, так как когда-то принципы методологии разработки повлияли на способ управления проектами. И теперь идеи<em>XP</em>можно применять не только к процессу написания кода, но и к работе менеджера. Как это сделать?</p>
34
<ul><li><strong>Использовать</strong>практики<em>XP</em>для сложных и запутанных проектов, когда требования быстро меняются и надо успевать держать все под контролем.</li>
34
<ul><li><strong>Использовать</strong>практики<em>XP</em>для сложных и запутанных проектов, когда требования быстро меняются и надо успевать держать все под контролем.</li>
35
<li><strong>Делать</strong>только то, что нужно сейчас, а не пытаться угадать, что потребуется в будущем.</li>
35
<li><strong>Делать</strong>только то, что нужно сейчас, а не пытаться угадать, что потребуется в будущем.</li>
36
<li><strong>Постоянно улучшать</strong>и упрощать не только код, но и процессы работы команды.</li>
36
<li><strong>Постоянно улучшать</strong>и упрощать не только код, но и процессы работы команды.</li>
37
<li><strong>Всегда</strong><strong>выбирать самую актуальную проблему</strong>и применять одну из практик для ее решения. Потом следующую проблему. И так - пока все не будет идеально.</li>
37
<li><strong>Всегда</strong><strong>выбирать самую актуальную проблему</strong>и применять одну из практик для ее решения. Потом следующую проблему. И так - пока все не будет идеально.</li>
38
</ul><p> XP - только одна из гибких методологий, принципы которых активно используют в управлении проектами. Она не так популярна, как, например, Scrum. Только небольшой процент команд использует весь комплекс практик XP в работе над проектом. Чаще выбирают одну или несколько, которые больше всего подходят и могут реально упростить процесс.</p>
38
</ul><p> XP - только одна из гибких методологий, принципы которых активно используют в управлении проектами. Она не так популярна, как, например, Scrum. Только небольшой процент команд использует весь комплекс практик XP в работе над проектом. Чаще выбирают одну или несколько, которые больше всего подходят и могут реально упростить процесс.</p>
39
<p>Если вы решили сочетать несколько разных методологий, то важно не пытаться вместить в один проект все и сразу и думать, что так быстрее заработает. Нужно понимать, что и для каких целей вы хотите использовать. И помнить: если это помогло вашему конкуренту, это не значит, что и у вас будет хороший результат. Все может получиться наоборот. Если есть сомнения, лучше учиться проектным менеджерским трюкам и жонглированиям методологиями у мастеров со стажем и большим практическим опытом.</p>
39
<p>Если вы решили сочетать несколько разных методологий, то важно не пытаться вместить в один проект все и сразу и думать, что так быстрее заработает. Нужно понимать, что и для каких целей вы хотите использовать. И помнить: если это помогло вашему конкуренту, это не значит, что и у вас будет хороший результат. Все может получиться наоборот. Если есть сомнения, лучше учиться проектным менеджерским трюкам и жонглированиям методологиями у мастеров со стажем и большим практическим опытом.</p>
40
40