Получая много вопросов в прошлом, я решил расставить все точки над “и”.
LEAN
Lean пришел из бережливого производства (Lean Manufacturing), он имеет набор принципов, относящихся к качеству, скорости и клиентоориентированности (то же, что мы пытаемся сделать в agile разработке, правильно?)
Мэри и Том Поппендик адаптировали принципы “Бережливого Производства” для разработки программного обеспечения, и я верю, что эти идеи являются основами и причинами того, как agile работает:
1. Устранение потерь.
2. Повышение качества.
3. Создание знаний.
4. Отсроченные обязательства.
5. Быстрая поставка.
6. Уважение людей.
7. Полная оптимизация.
В двух словах, Lean говорит: безжалостно избавляйтесь от всего, что не добавляет дополнительной ценности, и делайте только то, в чем вы абсолютно уверены, что это нужно делать в настоящий момент. Устранять потери означает устранять бесполезные собрания, задачи и документацию. Но это также означает избавляться от временных потерь в любых известных задачах, которые нужно будет сделать в будущем (все постоянно меняется и часто в итоге становится ненужным. Если бы мы сделали что-то наперед, то мы должны были бы потратить время на переделку этого, потому что условия или наше понимание уже изменилось в последствии). Это также означает, что мы должны избавляться от не эффективных способов работы, таких как многозадачность, чтобы мы могли делать поставки быстро.
Lean также делает очень сильный акцент на то, что называется “системой”, т.е. что команда работает как единое целое. Мы всегда должны смотреть на нашу работу “с высоты”, чтобы быть уверенным, что мы улучшаемся в целом. Например, много менеджеров хотят “занять” работой каждого разработчика на 100%, но в большинстве случаев это, на самом деле, контрпродуктивно. Давайте не будем заставлять людей кодировать то, что не нужно (или полностью не определено), только ради того, чтобы они кодировали, потому что в будущем для нас это создает еще больше работы.
Подводя черту, Lean говорит: уважайте людей. Это означает давать людям ту работу, которую они лучше всего знают как надо делать. Дайте им то, что им необходимо, чтобы быть эффективными и затем доверьте им сделать это. Суть программной разработки в постоянном обучении; поэтому строить работу нужно так, чтобы убеждаться, что мы постоянно учимся. И поэтому нужно откладывать принятие решения до последнего момента (ведь мы будем на тот момент знать больше). В итоге разработка идет путем создания качественного продукта, потому что нет другого способа, обеспечивающего постоянную быструю поставку, если нужно возвращаться и убирать наш беспорядок.
“Организации, которые по-настоящему следуют Lean, имеют сильное конкурентное преимущество, потому что они очень быстро и в высшей степени дисциплинированно реагируют на рыночный спрос, а не пытаются предсказывать будущее”, – Мэри Поппендик.
Agile
Agile опирается на совокупность ценностей и принципов, изложенных в манифесте Agile. Манифест был ответной реакцией на тяжеловесные методологии, которые были популярны, пока изнемогающие программные проекты, в конце концов, не начинали делать то, что на самом деле нужно, — создавать программное обеспечение, которое помогает клиентам. Я верю, что ценности и принципы Agile работают потому, что наука следует за Lean, и вы увидите множество заимствований, повторяющихся в Agile.
Ценности Agile – это:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условия контракта.
Реагирование на изменение важнее следования первоначальному плану.
Принципы Agile – это:
1. Наивысший приоритет — удовлетворение пользователей.
2. Изменение требований приветствуется.
3. Работающий продукт следует выпускать как можно чаще.
4. Представители бизнеса и разработки должны работать вместе ежедневно.
5. Над проектом должны работать мотивированные профессионалы.
6. Непосредственное общение является наиболее практичным и эффективным.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
9. Постоянное внимание техническому совершенствованию и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы повышение эффективности и соответственно корректировать стиль своей работы.
Любой проект, который следует этим ценностям и принципам, по праву может считаться agile. Тем не менее, безусловно есть наиболее общие практики для agile команд, следуя которым достигается гибкость (agility).
Наиболее общие это: Scrum или Kanban (или гибрид из обоих) для “Управленческих практик”. Экстремальное программирование (XP) для Технических практик (с новыми практиками становится популярным, во многом из-за Lean Statup, такие как непрерывное развертывание и тестирование на проде).
Хорошие agile команды выбирают часть из управленческих и технических практик, те, что лучше для них. (Плохой пример, когда берут только пару практик, ложно веря, что это “их делает agile”)
Благодарности: Спасибо Юрию Прокудину, Екатерине Кивелевой за помощь в подготовке текста.
Комментарии (25)
G-M-A-X
06.09.2016 22:50Agile — это бюрократия :)
napa3um
06.09.2016 23:48+5Agile — это как раз уменьшение уровня бюрократии в смысле «бумажек» и в смысле согласования принятия решений относительно «классических» методов ведения проектов (типа ГОСТ 34.601-90). Только современные программисты сталкиваются с вариантами Agile чаще приходя «с улицы», а не с «классических» проектов, потому систематизация проектирования и разработки выглядит для них увеличением количества бюрократии, а не уменьшением. Думаю, для понимания Agile (как и в других дисциплинах и науках) требуется ознакомление с историческими способами ведения проектов, с их проблемами на фоне новых экономических и технических требований, а потом уже с решениями этих проблем с помощью новомодных базвордов и принципов.
VolCh
07.09.2016 07:57Это не отменяет того, что Agile — это бюрократия. Вообще, методологии ведения проектов уменьшают продуктивность разработчиков ради таких бизнес-ценностей как планирование, управляемость, предсказуемость и т. п.
napa3um
07.09.2016 08:30Бюрократия — страшное для вас слово, похоже. И нет, продуктивность разработчиков при правильно построенной бюрократии повышается, а не понижается, ведь ради неё, в конечном итоге, любая бюрократия и нужна.
VolCh
08.09.2016 21:16Нет, не страшное, просто имеющее место быть явление, неизбежное зло в более-менее масштабных проектах.
rms
07.09.2016 08:42+1Если под бюрократией понимать определенные правила, то да, но Agile не про это.
Планирование, в классическом виде, как диаграмма Ганта в Agile нет, более того в Lean вообще есть только здесь и сейчас.
Управляемость — кем? Тут только команда разработчиков принимает решение без менеджеров.
Предсказуемость — смотря с чем сравнивать, а если смотреть на принцип «изменения приветствуются» — то, как можно что-то предсказать, если в Kanban нет понимания, что будет дальше — это известно только в миг, когда мы берем новую задачу, а в Scrum — есть набор задач на спринт, но это опять же только обязательства команды выдать какую-то ценность за фиксированный промежуток времени, чтобы им не мешали.
Agile — это про людей, все описанное, это просто выраженное словами нормальное продуктивное взаимодействие людей. И тут, как в программировании, либо пишешь свой велосипед или делаешь костыли, а можешь взять лучшие практики и готовое решение.
Про продуктивность, тут такой момент — если все работает и все устраивает — не трогай, а если проблемы, то для них есть решения.
Проблемы с которыми я сталкивался:
— зависимость команд Мобильного приложения и Бекенда
— команда не выпускает ничего, но работа кипит и все заняты делом
— заказчик не доволен и не понимает, что происходит
и т.д. Их можно решить самостоятельно с помощью «скотча», но есть люди, кто уже проходил подобный путь, у них уже есть красивые решения ими-то и нужно воспользоваться.
Agile — это люди.poxu
07.09.2016 19:27+1Бюрократия это процедура.
Обязательный скрам, обязательные ретроспективы, на которых надо написать что понравилось, а что нет. После того, как напишешь, то, что понравилось, наклеят на доску и забудут, а для того, что не понравилось, будут искать решения. Ты так никогда и не поймёшь зачем ты выделял хорошие моменты. И ты не можешь не написать ничего, даже если тебя всё устраивает, потому что тогда ты не involved не proactive и тебе надо больше team spirit.
На планнинг покере надо давать оценки задачам о наличии которых ты вчера даже не подозревал, а сегодня знаешь только название и краткое описание из джиры, но устраниться от этого ты не можешь. Ибо если сказать, что в общем-то занимаешься другим и данную задачу оценивать не в состоянии, то не исключено, что тебе её и дадут, для улучшения bus factor и collective code ownership, а потом, когда ты будешь ковыряться с задачей раза в два дольше, чем человек, который в теме — сделают выговор за уменьшение velocity.
И, не дай бог программирования, после описанных выше событий ты скажешь, что agile это не весело и не exiting. Это значит, что ты inflexible, что у тебя low communication skills и возможно даже что ты не совсем client faced а греха выше нет и быть не может.
Это — тоже Agile
napa3um
07.09.2016 19:43+1Любой сложный метод в массах часто превращается в карго-культ.
poxu
07.09.2016 20:17Что я тут могу спросить.
Можно ли пропустить скрам?
Можно ли не устраивать ретроспективу?
Можно ли на ретроспективе не говорить про хорошие моменты?
Можно ли устраниться из оценки непонятных тебе задач?
Можно ли не брать непонятные задачи?napa3um
07.09.2016 20:41+1Договоритесь об этом со своей командой сами, приведите им свои аргументы об избыточности каких-то процессов, выслушайте их аргументы о том, чем полезны эти избыточности, придите к компромиссам. Аджайл, как обещает автор данного поста, это бюрократия не ради бюрократии, это бюрократия ради людей, и если процесс угнетает людей (вас), то что-то явно идёт не очень хорошо.
rehcraeser
08.09.2016 12:53Разве в Agile кто-то раздает задачи членам команды? Мне всегда казалось, что задачи берутся с «доски» самостоятельно. В Agile же и роли тим-лида вроде как нет. Я ошибаюсь?
napa3um
08.09.2016 13:19Часто в командах, в которых участники сильно различаются компетенциями или амбициями, любые холакратические (holacracy) схемы имеют тенденцию вырождаться в иерархические схемы («синдром вахтёра», «дедовщина», «тим-лидерство» :) и т.п.)
poxu
08.09.2016 13:28Ну, если два человека хотят одну и ту же задачу, надо же как-то решать, чья она.
napa3um
08.09.2016 13:39Два этих человека и должны решить этот вопрос без привлечения лишних иерархических схем согласования. Аджайл экономит именно на этом арбитраже, «размазывая» ответственность по команде. Аджайл в этом смысле — это что-то типа философской парадигмы, религии, которой искренне должны следовать все члены команды. Компоновать такие команды — сложное занятие (автор данной статьи, видимо, промышляет как раз чем-то подобным), работать в таких командах — удовольствие :).
G-M-A-X
08.09.2016 21:27Тогда это уже не Agile. :)
Некоторые задачи стоит, чтобы распределял тим-лид, некоторые просто брать из буфера.
У нас сейчас буфер разбирается по дням по очереди.
Без тим-лида в команде — это бред. :)
hippoage
13.09.2016 15:55В манифесте нет ничего про раздачу задач, поэтому в Agile можно и так, и так. В Скраме да, предполагается, что люди самостоятельно берут задачи. При этом возможны всякие конфликты, которые должен разруливать скрам-мастер.
Если команда различается по компетенциям, то в начале спринта для улучшения планирования можно задачки разбрасывать на людей, которые все равно будут их делать (чтобы посмотреть, что они не перегружены). Задачи, которые может делать больше одного человека не назначаем.
Bus factor — отдельная история.
VolCh
08.09.2016 21:19Это один из видов взаимодействия людей, один из способов решения проблем управляемости команды и предсказуемости результатов её работы. Прежде всего для заказчика.
vit1251
14.09.2016 20:53Когда нет Agile и так называемой «бюрократии» приходят самые насущные проблемы… решения содержат скрытые на этапе приема проблемы, процесс разработки происходит хаотический и нет инструмента контроля, а там где нет контроля, то и не существует системы развития и карьеры. Одним словом «хоп-хоп-и-в-прадакшен». Если Вы все еще не работаете по какой-то методологии, то скорее всего имеете кучу этих и других проблем, что приводит в конечном итоге к плачевным результатам. P.S. Писал не по Agail, а по Kanban (не более 5 мин. на комментарий)
DamirGor
07.09.2016 17:07Пост скорее не о «Agile или Lean: Ага ага, какая разница-то?»
А об этом: «Вот это Agile. Вот это Lean.»
В таком же духе можно написать статьи «Вот это Водопад. Вот это Agile. Вот это Scrum. и т.п»
vyatsek
08.09.2016 14:12Ой как же вы надоели :)
Редкая IT компания имеет инженерный подход к производству ПО. И вообще в текущих реалиях я бы даж на эту тему посморил, а надо ли это в принципе? Для большой компании возможно, хотя бы с сотнями разработчиков. Но это не будет ни Aglie ни Lean. В текущих реализях разработка ПО больше напоминает работу бригады мастеров, и инженерии тут на копейки, важно правильно подобрать людей в команду, а уж они потом договорятся и настроят процесс так как им надо.
В больших же компаниях именно инженерные процессы будут далеки от Agile потому, что при внесении изменений в core framework потребуется осознать кучу зависимостей и аджайл тикеты на доске в этом никак не помогут.
napa3um
08.09.2016 14:20> важно правильно подобрать людей в команду, а уж они потом договорятся и настроят процесс так как им надо
Аджайл в том числе как раз и об этом. Меньше управления, больше самоорганизации. Как бы такой ненавязчивый инструмент для помощи в самоорганизации. И работает это именно для маленьких команд или выделенных из больших команд маленьких рабочих групп (где члены команды «на одной волне»).vyatsek
12.09.2016 12:07Меньше управления, больше самоорганизации. Какой-то популизм в IT. Аджаил никогда из группы людей не сделает команду. Сначала команда, а потом хоть что. При сильной команде аджаил в том виде, в котором его продают вообще бесполезен.
hippoage
13.09.2016 16:10Agile — принципы, они перечислены в статье, реализаций множество, они разные в деталях. В самой популярной реализации принципов — Скраме — за формирование из группы людей команды отвечает отдельный человек — Scrum Master. Он вообще не технический специалист.
Сильная команда из ниоткуда — это несистемный подход. Как не потерять (при естественной смене людей время от времени) силу команды? Как сделать вторую сильную команду? Один из системных ответов на эти вопросы — Scrum. Это исключительно организационный фреймворк для формирования «сильных» команд.
stepanp
Эскобар.jpg