Софт за 30 дней. Как Scrum делает невозможное возможным - [9]
Проблема 2 каскадного процесса: срыв графиков релизов. Наш график разработки не может сдвинуться более чем на 30 дней, так как это максимальная длительность одной итерации. Мы выпускаем накопленные инкременты, когда достигаем даты релиза. Мы не выделяем итераций для построения малозначительного функционала, что позволяет выпускать законченную систему гораздо раньше, чем обычно. При использовании традиционного метода разработки программного обеспечения только менее 50 % функционала используется часто. Мы не разрабатываем этот функционал.
Проблема 3 каскадного процесса: создание стабильной версии перед релизом занимает все больше и больше времени. Каждая итерация производит законченный, готовый к работе прирост функционала. Каждый последующий инкремент интегрируется с инкрементами всех предыдущих итераций, он также полностью завершен и готов к использованию. Перед релизом не требуется дополнительной работы по стабилизации, так как эта работа уже была выполнена.
Проблема 4 каскадного процесса: планирование занимает слишком много времени и выполняется неправильно. Начальное планирование сводится к постановке цели и определению наиболее ценных функциональных возможностей, производительности и особенностей, необходимых для ее достижения. Затем определяются ориентировочная стоимость и срок разработки. Планирование до первой итерации, как правило, занимает 20 % времени от того, что обычно мы привыкли тратить на планирование для каскадного, или предиктивного, метода. Мы планируем детальные требования для каждой итерации только непосредственно перед ее началом. Это планирование перед итерацией называется «точно в срок», и в него могут включаться требования, возникающие во время проверки предыдущей итерации, и адаптироваться лучшие требования для следующей.
Проблема 5 каскадного процесса: изменения трудно вносить в процессе разработки. В итеративно-инкрементальном процессе нет состояния середины процесса разработки. Новые требования могут возникать и быть добавлены перед каждой итерацией с минимальными затратами.
Проблема 6 каскадного процесса: ухудшение качества. Инкремент каждой итерации закончен и готов к использованию. Качество уже встроено. Каждый последующий инкремент также добавляет определенное качество. Нет этапа спешной стабилизации в конце проекта, когда нередко жертвуют качеством ради соблюдения сроков выпуска. Эта работа уже выполнена.
Проблема 7 каскадного процесса: авралы наносят моральный вред. Процесс стабилизации программного обеспечения перед выпуском исключен, как и работа в выходные и сверхурочная работа.
Как видите, итеративно-инкрементальный метод разработки, основанный на эмпирическом процессе, контролирует проблемы, которые обычно преследуют разработчиков программного обеспечения. При этом, чтобы определить нужды конкретных организаций, мы должны знать, как этими проектами управлять. Об этом мы поговорим в следующих главах и более детально в главе 6.
Работой можно управлять, используя всего три переменные. Первая (А) – это требования, функциональные возможности, которые предоставит планируемое программное обеспечение. Вторая переменная (В) – время, которое теперь мы измеряем в блоках по 30 дней. Третья переменная (С) – законченная работа, которая измеряется в пригодных к применению функциональных возможностях или в количестве требований и функциональных возможностей, выполненных в каждый из 30-дневных периодов и совокупно.
Таким образом, можно создать график для управления проектом.
1. Бэклог требований по оси Y, или вертикальной оси. Работа по выполнению каждого требования разбита по размеру. Давайте предположим, что у нас есть пять требований. Каждое требует выполнения 2, 3, 5, 3 и 8 блоков работы. Они создают объем работы по оси Y из 21 блока. Блоки расположены в порядке, в котором вы хотите превращать их в пригодные к использованию функциональные возможности. Давайте, скажем, порядок сверху вниз будет 2, 3, 5, 3 и 8.
2. Время отложим по горизонтальной оси Х. Блоки по 30 дней, что составляет протяженность одной итерации.
3. Мы предполагаем, основываясь на предыдущем опыте, что команда разработки выполняет по пять блоков работы за каждую итерацию. Реальную производительность команды разработки выясним, когда начнем работу, а пока это всего лишь прогноз вчерашней погоды. Итак, мы предполагаем, что 20 блоков работы будут закончены за первые четыре итерации и последний фрагмент будет выполнен в течение пятой итерации.
4. Объем выполненной работы и готовые к использованию функциональные возможности вычисляются в конце каждой итерации. Мы планируем, что первые два требования, которые состоят из двух и трех блоков работы, будут закончены в течение первой итерации. Мы предполагаем закончить следующий фрагмент функциональных возможностей, состоящий из пяти блоков работы, во второй итерации. К этому времени мы обычно уже корректируем планы относительно того, что же делать дальше. Мы уже видели первые два инкремента и часто на этом этапе находим непредвиденные или измененные требования для следующей итерации. Если такого не случилось, мы продолжаем, как планировалось. Тем не менее план и будущие требования без проблем могут изменяться в конце каждой итерации. Размер инкрементов измеряется в тех же единицах, что и требования по оси
Книга основателя методики Scrum, которая поможет вам реализовывать проекты в несколько раз быстрее и эффективнее. Возможно, историки будущего будут разделять прогресс человечества четкой линией: «до Scrum» и «после» — настолько эта методика революционна. Её используют в большинстве технологичных компаний мира, но теперь она доступна всем, кто имеет дело со сложными проектами в любой отрасли. Джефф изобрел свою методику, пытаясь справиться с недостатками классического управления проектами: людям редко удается работать слаженно, эффективно и быстро, большинство планов не выполняются (ни по времени, ни по ресурсам), подразделения и команды часто выполняют противоречащие друг другу задачи или дублируют их. За 20 лет существования Scrum помогла не только большинству разработчиков программного обеспечения, но и ФБР, автопроизводителям, фармацевтам и простым людям, планирующим свои дела. Эта книга полностью перевернет ваш подход к управлению проектами и поможет достичь результатов, которые раньше казались невозможными.
Эта книга несет в себе дух скрама, раскрывая его ценности и основные принципы. Кен Швабер, один из создателей скрама, соавтор «Руководства по скраму» и основатель Scrum.org, собрал лучшие кейсы из своей практики, демонстрирующие примеры успехов и неудач применения скрама в реальных проектах. Они помогут вам понять, как использовать скрам для решения комплексных проблем и достижения результатов. Автор рассказывает, как эффективно управлять сложными, громоздкими проектами и изменяющимися требованиями к продукту; упрощать организационную структуру с помощью самоуправляемых команд разработки; получать более четкие описания требований и внятную обратную связь от клиентов и заказчиков. Вы узнаете, как эффективнее планировать работу над проектом, научитесь избегать ошибочных действий, используя регулярную инспекцию, а также увеличивать отдачу от инвестиций.
Эта книга – продолжение первой части, вышедшей в 2015 г. Во второй части анализируются 100 дел ФАС России против малого и среднего бизнеса за 2016—2018 гг. Несмотря на принятие 3.07.2016 закона об «иммунитетах» для малого бизнеса от антимонопольного контроля, подходы ФАС изменились незначительно. По основным объектом преследования остаются н самые крупные игроки на рынке. В книге предлагается реформа антимонопольного регулирования, предусматривающая полное прекращение преследования МСП.
Нейробиолог Шрини Пиллэй, опираясь на последние исследования мозга, примеры из спорта и бизнеса и истории из своей психологической практики, бросает вызов традиционному подходу к продуктивности. Вместо внимания и сосредоточенности он предлагает специально «расфокусироваться», чтобы стимулировать креативность, развить память, увеличить продуктивность и двигаться к целям. На русском языке публикуется впервые.
Сразу после выхода в свет эта книга заняла первые места на Amazon среди книг по маркетингу и клиентскому сервису. Формирование источника регулярной выручки для компании – важная задача каждого предпринимателя. Благодаря разнообразию разновидностей бизнес-моделей на основе подписки для каждой отрасли можно найти подходящий вариант. Подписчики в любом случае намного ценнее для компании, чем обычные покупатели. Эта книга для всех, кто хочет построить бизнес-модель, приносящую регулярную прибыль. На русском языке публикуется впервые.
В бизнесе да и в жизни уже не так важно, что именно вы делаете. Гораздо важнее то, как вы это делаете. Дов Сайдман, основатель и CEO компании LRN, на страницах своей книги убедительно доказывает: моральные «факторы», прежде считавшиеся «факультативными», определяют сегодня ваш успех. Только ориентируясь на нравственные ценности, выстраивая отношения на основании доверия и заботясь о собственной репутации, вы сможете обойти конкурентов и преуспеть в бизнесе и в жизни. Эта книга будет полезна владельцам компаний, руководителям и менеджерам, которые заботятся не только о прибыли, но и о том, какое наследство они оставят своим детям.
Инновации являются важнейшим фактором роста. Сегодня, более чем когда-либо, компании должны внедрять инновации, чтобы выжить. Но успешные инновации – это очень непростая задача. Авторы – партнеры всемирно известной консалтинговой компании Simon-Kucher & Partners Strategy & Marketing Consultants знают о чем говорят. Георг Таке – ее генеральный директор, а Мадхаван Рамануджам – партнер в Сан-Франциско. Simon-Kucher & Partners – глобальная консалтинговая компания, насчитывающая 900 профессионалов в 33 офисах по всему миру.
«Шпаргалки для менеджеров» – это ваши «карманные консультанты» в решении самых разных проблем деловой, да и повседневной жизни. Ничего лишнего – только самое главное!Аттестация персонала – важнейший этап в работе менеджера, который стремится к взаимопониманию и эффективному сотрудничеству с подчиненными. Здесь вы найдете практические советы о том, как проводить собеседование, выносить объективную оценку и способствовать профессиональному росту сотрудников.