Юрген Аппело - Agile-менеджмент. Лидерство и управление командами

Здесь есть возможность читать онлайн «Юрген Аппело - Agile-менеджмент. Лидерство и управление командами» — ознакомительный отрывок электронной книги совершенно бесплатно, а после прочтения отрывка купить полную версию. В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Город: Москва, Год выпуска: 2018, ISBN: 2018, Издательство: Литагент Альпина, Жанр: Деловая литература, management, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Agile-менеджмент. Лидерство и управление командами: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Agile-менеджмент. Лидерство и управление командами»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

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

Agile-менеджмент. Лидерство и управление командами — читать онлайн ознакомительный отрывок

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

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

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

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

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

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

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

Евангелие от Agile

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

И даже в избытке.

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

В начале 1990-х была предложена новая методология под названием быстрая разработка приложений (Rapid Application Development, RAD). В рамках этой методологии наиболее успешным командам разработчиков удавалось сочетать некоторые формализованные методы, позаимствованные у «тяжеловесного» инженерного подхода (контроль за внесением изменений в техдокументацию, инспекции и применение контрольных показателей), с такими продиктованными практикой методами, как создание прототипов, выпуск инкрементных версий ПО и тесное сотрудничество с заказчиком [McConnell 1996]. В результате такого скрещивания формализованных и неформализованных методик возникли первые «легкие» методологии, включая эволюционное управление разработкой( Evo)(1988), Scrum(1995), методы разработки динамических систем( DSDM)(1995), методы Crystal(1997), Экстремальное программирование (XP)(1999), разработка, управляемая функциональностью (FDD)(1999), прагматическое программирование(1999) и адаптивная разработка ПО(2000).

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «Agile-менеджмент. Лидерство и управление командами»

Представляем Вашему вниманию похожие книги на «Agile-менеджмент. Лидерство и управление командами» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Harvard Business Review (HBR) - Управление командой
Harvard Business Review (HBR)
Отзывы о книге «Agile-менеджмент. Лидерство и управление командами»

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

x