Как стать автором
Обновить

Комментарии 28

Agile — это бюрократия :)
Agile — это как раз уменьшение уровня бюрократии в смысле «бумажек» и в смысле согласования принятия решений относительно «классических» методов ведения проектов (типа ГОСТ 34.601-90). Только современные программисты сталкиваются с вариантами Agile чаще приходя «с улицы», а не с «классических» проектов, потому систематизация проектирования и разработки выглядит для них увеличением количества бюрократии, а не уменьшением. Думаю, для понимания Agile (как и в других дисциплинах и науках) требуется ознакомление с историческими способами ведения проектов, с их проблемами на фоне новых экономических и технических требований, а потом уже с решениями этих проблем с помощью новомодных базвордов и принципов.
Такой бюрократический ответ)) По аджайлу писали?
Это не отменяет того, что Agile — это бюрократия. Вообще, методологии ведения проектов уменьшают продуктивность разработчиков ради таких бизнес-ценностей как планирование, управляемость, предсказуемость и т. п.
Бюрократия — страшное для вас слово, похоже. И нет, продуктивность разработчиков при правильно построенной бюрократии повышается, а не понижается, ведь ради неё, в конечном итоге, любая бюрократия и нужна.
Нет, не страшное, просто имеющее место быть явление, неизбежное зло в более-менее масштабных проектах.
Если под бюрократией понимать определенные правила, то да, но Agile не про это.

Планирование, в классическом виде, как диаграмма Ганта в Agile нет, более того в Lean вообще есть только здесь и сейчас.
Управляемость — кем? Тут только команда разработчиков принимает решение без менеджеров.
Предсказуемость — смотря с чем сравнивать, а если смотреть на принцип «изменения приветствуются» — то, как можно что-то предсказать, если в Kanban нет понимания, что будет дальше — это известно только в миг, когда мы берем новую задачу, а в Scrum — есть набор задач на спринт, но это опять же только обязательства команды выдать какую-то ценность за фиксированный промежуток времени, чтобы им не мешали.

Agile — это про людей, все описанное, это просто выраженное словами нормальное продуктивное взаимодействие людей. И тут, как в программировании, либо пишешь свой велосипед или делаешь костыли, а можешь взять лучшие практики и готовое решение.

Про продуктивность, тут такой момент — если все работает и все устраивает — не трогай, а если проблемы, то для них есть решения.
Проблемы с которыми я сталкивался:
— зависимость команд Мобильного приложения и Бекенда
— команда не выпускает ничего, но работа кипит и все заняты делом
— заказчик не доволен и не понимает, что происходит

и т.д. Их можно решить самостоятельно с помощью «скотча», но есть люди, кто уже проходил подобный путь, у них уже есть красивые решения ими-то и нужно воспользоваться.

Agile — это люди.

Бюрократия это процедура.


Обязательный скрам, обязательные ретроспективы, на которых надо написать что понравилось, а что нет. После того, как напишешь, то, что понравилось, наклеят на доску и забудут, а для того, что не понравилось, будут искать решения. Ты так никогда и не поймёшь зачем ты выделял хорошие моменты. И ты не можешь не написать ничего, даже если тебя всё устраивает, потому что тогда ты не involved не proactive и тебе надо больше team spirit.


На планнинг покере надо давать оценки задачам о наличии которых ты вчера даже не подозревал, а сегодня знаешь только название и краткое описание из джиры, но устраниться от этого ты не можешь. Ибо если сказать, что в общем-то занимаешься другим и данную задачу оценивать не в состоянии, то не исключено, что тебе её и дадут, для улучшения bus factor и collective code ownership, а потом, когда ты будешь ковыряться с задачей раза в два дольше, чем человек, который в теме — сделают выговор за уменьшение velocity.


И, не дай бог программирования, после описанных выше событий ты скажешь, что agile это не весело и не exiting. Это значит, что ты inflexible, что у тебя low communication skills и возможно даже что ты не совсем client faced а греха выше нет и быть не может.


Это — тоже Agile

Любой сложный метод в массах часто превращается в карго-культ.

Что я тут могу спросить.
Можно ли пропустить скрам?
Можно ли не устраивать ретроспективу?
Можно ли на ретроспективе не говорить про хорошие моменты?
Можно ли устраниться из оценки непонятных тебе задач?
Можно ли не брать непонятные задачи?

Договоритесь об этом со своей командой сами, приведите им свои аргументы об избыточности каких-то процессов, выслушайте их аргументы о том, чем полезны эти избыточности, придите к компромиссам. Аджайл, как обещает автор данного поста, это бюрократия не ради бюрократии, это бюрократия ради людей, и если процесс угнетает людей (вас), то что-то явно идёт не очень хорошо.
Разве в Agile кто-то раздает задачи членам команды? Мне всегда казалось, что задачи берутся с «доски» самостоятельно. В Agile же и роли тим-лида вроде как нет. Я ошибаюсь?
Часто в командах, в которых участники сильно различаются компетенциями или амбициями, любые холакратические (holacracy) схемы имеют тенденцию вырождаться в иерархические схемы («синдром вахтёра», «дедовщина», «тим-лидерство» :) и т.п.)

Ну, если два человека хотят одну и ту же задачу, надо же как-то решать, чья она.

Два этих человека и должны решить этот вопрос без привлечения лишних иерархических схем согласования. Аджайл экономит именно на этом арбитраже, «размазывая» ответственность по команде. Аджайл в этом смысле — это что-то типа философской парадигмы, религии, которой искренне должны следовать все члены команды. Компоновать такие команды — сложное занятие (автор данной статьи, видимо, промышляет как раз чем-то подобным), работать в таких командах — удовольствие :).
Тогда это уже не Agile. :)
Некоторые задачи стоит, чтобы распределял тим-лид, некоторые просто брать из буфера.
У нас сейчас буфер разбирается по дням по очереди.
Без тим-лида в команде — это бред. :)
В манифесте нет ничего про раздачу задач, поэтому в Agile можно и так, и так. В Скраме да, предполагается, что люди самостоятельно берут задачи. При этом возможны всякие конфликты, которые должен разруливать скрам-мастер.

Если команда различается по компетенциям, то в начале спринта для улучшения планирования можно задачки разбрасывать на людей, которые все равно будут их делать (чтобы посмотреть, что они не перегружены). Задачи, которые может делать больше одного человека не назначаем.

Bus factor — отдельная история.
Это один из видов взаимодействия людей, один из способов решения проблем управляемости команды и предсказуемости результатов её работы. Прежде всего для заказчика.
Когда нет Agile и так называемой «бюрократии» приходят самые насущные проблемы… решения содержат скрытые на этапе приема проблемы, процесс разработки происходит хаотический и нет инструмента контроля, а там где нет контроля, то и не существует системы развития и карьеры. Одним словом «хоп-хоп-и-в-прадакшен». Если Вы все еще не работаете по какой-то методологии, то скорее всего имеете кучу этих и других проблем, что приводит в конечном итоге к плачевным результатам. P.S. Писал не по Agail, а по Kanban (не более 5 мин. на комментарий)
Следует различать методологии программирования и методологии создания продукта. Создание продукта — бизнес-задача и разработчикам она особо не интересна, поэтому рассматривается как мешающая разработке. А Agile — прежде всего методологии создания продуктов, методологии управления требованиями, контроля за их реализацией и т. п. Agile нужен бизнесу прежде всего, а не разработчикам. Нам то что, можем копать, а можем не копать, дайте технические требования, расставьте приоритеты и мы их будем реализовывать. Будем использовать при этом всякие технические методологии типа *DD или нет, по сути наше дело. Изменятся требования и/или приоритеты — переключимся, может матюгнется кто, что код, который выстрадал за долгое время больше не нужен, но не более. Беда в том, что бизнес это не устраивает, ему нужен контроль (или иллюзия контроля) за процессом разработки, ему нужны оценки, планы, текущее состояние, прогресс и т. д.
в Agile нет контроля, там он заменяется доверием и прозрачностью
Да ладно? Прозрачность означает как раз, что контролировать процесс может каждый заинтересованный в проекте. Ежедневные митинги — это что как не форма контроля? Борды (хоть реальные, хоть виртуальные) на которых разработчики обязаны если не заносить задачи (это может менеджмент делать), то оперативно отражать изменения статуса.

Agile — методологии создания продукта, методологии управления проектом, а не методологии разработки, не методологии проектирования, программирования и кодирования. Agile — это методологии контроля процесса разработки и управления им.
Пост скорее не о «Agile или Lean: Ага ага, какая разница-то?»
А об этом: «Вот это Agile. Вот это Lean.»
В таком же духе можно написать статьи «Вот это Водопад. Вот это Agile. Вот это Scrum. и т.п»
Ой как же вы надоели :)
Редкая IT компания имеет инженерный подход к производству ПО. И вообще в текущих реалиях я бы даж на эту тему посморил, а надо ли это в принципе? Для большой компании возможно, хотя бы с сотнями разработчиков. Но это не будет ни Aglie ни Lean. В текущих реализях разработка ПО больше напоминает работу бригады мастеров, и инженерии тут на копейки, важно правильно подобрать людей в команду, а уж они потом договорятся и настроят процесс так как им надо.
В больших же компаниях именно инженерные процессы будут далеки от Agile потому, что при внесении изменений в core framework потребуется осознать кучу зависимостей и аджайл тикеты на доске в этом никак не помогут.

> важно правильно подобрать людей в команду, а уж они потом договорятся и настроят процесс так как им надо
Аджайл в том числе как раз и об этом. Меньше управления, больше самоорганизации. Как бы такой ненавязчивый инструмент для помощи в самоорганизации. И работает это именно для маленьких команд или выделенных из больших команд маленьких рабочих групп (где члены команды «на одной волне»).
Меньше управления, больше самоорганизации. Какой-то популизм в IT. Аджаил никогда из группы людей не сделает команду. Сначала команда, а потом хоть что. При сильной команде аджаил в том виде, в котором его продают вообще бесполезен.
Agile — принципы, они перечислены в статье, реализаций множество, они разные в деталях. В самой популярной реализации принципов — Скраме — за формирование из группы людей команды отвечает отдельный человек — Scrum Master. Он вообще не технический специалист.

Сильная команда из ниоткуда — это несистемный подход. Как не потерять (при естественной смене людей время от времени) силу команды? Как сделать вторую сильную команду? Один из системных ответов на эти вопросы — Scrum. Это исключительно организационный фреймворк для формирования «сильных» команд.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории