Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным
- Название:Софт за 30 дней. Как Scrum делает невозможное возможным
- Автор:
- Жанр:
- Издательство:Литагент МИФ без БК
- Год:2017
- Город:Москва
- ISBN:978-5-00100-768-5
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным краткое содержание
Эта книга поможет руководителям и менеджерам компаний, которые хотят покончить с дорогим и медленным циклом разработки ПО.
На русском языке публикуется впервые.
Софт за 30 дней. Как Scrum делает невозможное возможным - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
В целом мы обнаружили, что небольшие команды лучше всего выполняют работу на основе итеративно-инкрементального метода. Численность команды обычно не более девяти, но не менее трех человек. Вместе члены команды должны обладать всеми видами квалификации, необходимой для преобразования ваших требований в функциональные возможности и реализации вашей идеи. В зависимости от того, какое программное обеспечение создает команда, ее члены должны разбираться в программировании, тестировании, дизайне, анализе, документировании, архитектуре и т. п. Атрибуты команды – опыт совместной работы, продуктивность, качество, креативность и непрерывное совершенствование.
Наши идеи о качествах наиболее эффективных команд разработчиков в значительной степени опираются на работу Такеучи и Нонаки, которые изучали командную работу Гарвардском университете [3]. Они наблюдали за поведением автономных команд, мотивированных высшей целью, вовлеченных в перекрестное обучение и работавших в коротких итерациях. Активное сотрудничество этих команд способствовало генерированию цикла знаний и вело к созданию инноваций, более быстрому времени выхода на рынок и более высокому качеству.
Действия команд напоминали им игру в регби, поэтому они назвали этот стиль управления разработкой проекта Scrum – так в регби называется момент возобновления игры после того, как мяч вышел за пределы поля.
Основываясь на знаниях, полученных нами от Такеучи и Нонаки, мы определили практические методы, позволяющие дополнить структуру эмпирического процесса разработки программного обеспечения. Все эти практические методы ведут к созданию высокопроизводительных команд, которые проявляют творческий подход, демонстрируют качество, производительность и моральный дух.
Уважение к личности сотрудника. В некоторых компаниях к сотрудникам относятся как к детям, их мнение не учитывается, им просто указывают, что именно делать в каждый момент в течение дня. Для того чтобы люди были вдохновлены и вовлечены в свою работу, следует создать атмосферу содействия, когда с сотрудниками обращаются с уважением и восхищением. Scrum призван обеспечить такую обстановку. Мы были не первые, кто решил применять идеи и практические методы, используемые в Scrum. Большинство из них представляют собой передовые методы в индустрии. Тем не менее Джефф действительно сосредоточен на аспекте «люди» в среде разработки программного обеспечения Scrum.
Встроенная нестабильность. Процесс разработки начинается с установки высшим руководством общих целей или задания стратегического направления. Они не вручают команде четкий рабочий план, а дают ей свободу. Постановка сложных задач создает динамическую напряженность внутри команды.
Самоорганизующиеся проектные команды. Сама команда решает, как достичь цели, поставленные руководством. Идея в том, чтобы заставить команду не полагаться на внешнее управление, но организоваться и управляться самостоятельно. Самоорганизация очевидна, когда в команде выполнены три условия: автономность, превосходство и взаимное развитие. Автономность есть, когда управление ограничено только руководством, деньгами и поддержкой. Руководство редко вмешивается. В некотором смысле управление действует как венчурные фонды, которые открывают свои кошельки, но при этом держат рты закрытыми. Команды постоянно стараются работать лучше. Это нескончаемый поиск пределов производительности.
Взаимное развитие. Совместно размещенные кросс-функциональные команды воспитывают в своих участниках стремление к высокой производительности, качеству и креативность. Члены команды работают совместно, и границы между сферами деятельности начинают размываться. На самом деле некоторые компании требуют от каждого члена команды знаний по двум специализациям (например, программирование более чем на одном языке плюс навыки тестировщика) и в двух областях (например, дизайн и маркетинг). Интенсивное взаимодействие индивидуальностей начинает задавать пульс, или темп команды.
Пересекающиеся фазы разработки. Избегая линейной последовательности в работе, команда способна поглощать «вибрацию» или «шум», создаваемый препятствиями в процессе разработки. Когда образуется «узкое горлышко», команда не приходит к внезапной остановке, но решает проблему. Пересекающиеся фазы избавляют от традиционного понятия разделения труда. Такой подход не только обеспечивает скорость и гибкость, но и способствует разделению ответственности, поощряет сотрудничество, стимулирует вовлеченность и обязательность, а также чувствительность к рыночным условиям. Недостаток в данном случае – необходимость управления интенсивным процессом, который требует прозрачности, взаимодействия, напряжения и даже конфликта.
Многоуровневое и мультифункциональное обучение. Обучение в команде идет в разных направлениях. В 3М, например, инженерам рекомендуется использовать 15 % своего рабочего времени, чтобы заниматься своей мечтой. Если команда работает с компанией Honda, ее члены могут быть отправлены в Европу, чтобы «осмотреться и понять, что там происходит». Идея в том, что обучение часто происходит в необычных местах и необычным способом и, самое главное, инициируется сотрудниками и поощряется и направляется руководством.
Тонкий контроль. Несмотря на то что команда разработки предоставлена сама себе, она работает не бесконтрольно. Акцент делается на самоконтроле и достаточном количестве контрольных точек, которые устанавливаются для предотвращения нестабильности, неопределенности и хаоса. Контроль со стороны равного и «контроль с любовью» – основы тонкого контроля. Динамическое движение возникает только в окружении, заботливо созданном руководством. Командные лидеры тщательно отбираются, а в самой команде иногда происходит замена участников, чтобы создать правильную динамику и уверенность, что люди смогут ужиться и работать вместе. В команде должен быть набор общих ценностей, а стимулы должны быть основаны на командной работе. При этом следует допускать возможность ошибок.
Передача знаний. Чтобы компания была успешной на рынке, выстраданные знания, накопленные внутри нее, должны быть доступны во всей компании, которая нуждается в новых командах с опытными людьми. Успешные мероприятия в рамках одного проекта распространяются внутри компании как стандартная практика. В то же время разучиться так же важно, как и научиться. Рынок меняется быстро, старые трюки могут больше не работать. Управление предъявляет новые требования, которые явно не могут быть удовлетворены старыми методами ведения дел.
Читать дальшеИнтервал:
Закладка: