Я недавно заметила, что только ленивый ещё не сравнивал классический проектный метод и agile. В интернете существует миллион таких статей, где главная цель — «продать» тот или иной подход. Agile уже давно просочился за пределы IT и того, что называется «разработка ПО». Вы удивитесь, как разные сферы отличаются по своей специфике управления проектами — вот почему, я хочу поговорить об этом.
Рубрика «аджайл»
12 принципов управления проектами: что не работает в Agile
2025-02-12 в 17:15, admin, рубрики: agile, agile manifesto, icagile, kanban, product management, project management, scrum, аджайл, Управление продуктом, управление проектамиВебинар «Десять главных трудностей Agile и способы их преодоления за час» 17 февраля в 20:00 по Москве
2020-02-14 в 9:23, admin, рубрики: agile, devops, аджайл, Блог компании Southbridge, вебинар, мероприятие, обучение, СлёрмTL;DR
27-29 февраля мы проводим Слёрм Аджайл. Как мы любим, в нем будет 20% теории и 80% практики (тренинга).
Слёрм Аджайл ведут эксперт-консультант Марина Алекс и практик аджайла, директор по разработке в международной продуктовой компании PropellerAds, Анатолий Иванов.
17 февраля в 20:00 по Москве мы проводим вебинар, где Марина Алекс разбирает 10 болей, которые слышит от компаний, где внедрение аджайла проваливается или идет с большим скрипом.
Регистрация на вебинар здесь
Обо всем подробнее.
Аты-баты шли «скрам-баты», или 85 заблуждений и препятствий гибкой разработки
2013-03-07 в 7:30, admin, рубрики: agile, scrum, аджайл, Блог компании «SCRUMguides», гибкая разработка, ошибки управления, скрам, управление проектами, метки: agile, scrum, аджайл, гибкая разработка, ошибки управления, скрам
Термин «скрам-бат» (scrumbut) впервые начал использовать Кен Шуэйбер что бы описать неверную трактовку или умышленную модификацию правил скрам, что бы уйти от болезненной правды о процессе, которую он помогает открыть.
Типичная формулировка скрам-бата выглядит так:
У нас скрам, но <Причина>, <ОбходнойПуть>
Где Причина — это описание дискомфорта, неприятного открытия с которым команда в силу тех, или иных причин не может справиться. А Обходной путь — это способ закрыть глаза на проблему, или устранить «симптомы», не разобравшись с причинами «организационного заболевания».
Типичные примеры скрам-батов, соответственно, выглядят так:
- У нас скрам, но мы не всегда успеваем закончить всю взятую работу, поэтому меняем длину итерации.
- У нас скрам, но все проблемы, которые мы могли устранить мы уже устранили, поэтому мы не проводим ретроспективы .
Мы стараемся термином «скрамбат» не злоупотреблять, поскольку некоторые типы отклонений свойственны началу внедрения аджайл и являются частью эволюции процесса. Например, если у вас скрам, но вы не делаете TDD, у вас нет парного программирования и слабо выраженное коллективное владение кодом — возможно, вы просто в начале пути. Причины могут быть разными — от неумения «продать» ценность инженерных практик менеджменту до неумения их «готовить». И то и другое можно научиться делать, но это занимает определенное время, верно?
Однако, каждый раз, когда я слышу «у нас скрам, но» в зрелых командах, я пытаюсь услышать нечто большее большее о причинах, которые такую модификацию обуславливают. И знаете, что? Веских причин на самом деле очень мало. Скорее, это непонимание ценностей гибкой разработки, недостаток смелости и силы что бы им следовать, которые вместе образуют процессное «скрамно».
Работая с командами, мы собрали список из 85 заблуждений и препятствий успешного внедрения гибкой разработки. Многие выходят за рамки правил карсасса скрам. В зависимости от контекста проекта, некоторые пункты могут иметь большее или меньшее влияние, и иметь оправдания обстоятельствами. Однако мы верим, что каждый элемент этого списка провоцирует искаженение ценностей и принципов Agile.
Читать полностью »
«Идеальный» скрам: вредные советы
2013-02-08 в 7:02, admin, рубрики: agile, аджайл, Блог компании Luxoft, разработка, скрам, метки: аджайл, скрамМногие компании уверяют, что работают по гибким методологии. Но там ли это? Возьмем, к примеру, скрам. Скрам давно испытанный и отточенный на практике рабочий процесс, но всегда ли он помогает в разработке? Может ли хорошо отлаженный процесс служить не поплавком, но грузилом? Я не являюсь скрам-тренером или кем-то подобным, просто хочу дать несколько анти-советов, которые, надеюсь, помогут взглянуть на скрам со стороны.