Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Претензии к Agile

Хочу спросить мнения тех, кто его обоснованно имеет :)
У меня сложилось мнение по Agile Scrum методикам, что они помогают сделать из человека, несведущего в бизнес-задачах и технологических рисках, какое-то подобие руководителя проекта. Ну, вот как если бы вы прочли методичку-выжимку из PMBoK, и ломанулись внедрять международный крупный проект с командой 50+ человек.
Постулаты непогрешимости этой методологии гласят приблизительно следующее: «легким взмахом карты Planning Poker — вы сразу определите какие тут задачи mostly valuable, и какие ресурсы most competent for it»

Я для себя из Agile взял в основном итеративность, гибкость изменения приоритетов, и использование беклогов проекта/спринта.

Вот скажите, пожалуйста, кто что имеет сказать )

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Тем не менее уже имеем срач в комментах.
Нет тут явной конкретики по полочкам как в PMBoK.

Дается утопическая (для СНГ) абстракция с базовым набором принципов. И каждый уже адаптирует/извращается как хочет. На выходе можно и не понять что в результате у вас вышло — Scrum или Waterfall с доп. плюшками.

“легким взмахом карты Planning Poker — вы сразу определите какие тут задачи mostly valuable, и какие ресурсы most competent for it”

Defining of the most valuable tasks is responsibility of Product Owner (PO). As business/stakeholders representative PO should know it better than anyone. Neither Development Team nor Scrum Master can make this decision.

Only Development Team knows who is the most competent for a task that’s why the team is responsible for it. Neither PO nor Scrum Master can make this decision.

Scrum Master is responsible for efficiency of communication between PO and Development Team. That’s it.

Тогда уж так:
www.youtube.com/watch?v=Q6jMgmPIxmk

Для начала хочу сказать, что никакие процессы, никакой менеджмент не заменят развитых личных навыков, мотивации и профессионализма.
Долг программиста как профессионала — приносить своему нанимателю пользу ( value ), соотвественно как он разрабатывает проект — его дело. Хорошие программисты знают о том, что процесс разработки зависит от бизнеса заказчика. Допустим, его/ее проект работает в высококонкуретной среде ему важно быстро пробовать разные фичи в продакшене, хороший программист возьмет и внедрит continuous delivery чтобы дать нанимателю такую возможность, чем принесет ему тот самый value. Тупой ПМ скажет — «Как же так, у нас же СКРАМ, только через 2 недели и никак по другому» за что будет бит начальством.

Если ты профессионал, то твой долг приносить пользу, а как это сделать? Наладить диалог с заказчиком/стейкхолдерами и членами команды, сконцентрироваться непосредственно на продукте, служить общему делу, а не собственным интересам, подстраиваться под нужды проекта и заказчика. Хотя, минуточку, где-то я это уже видел — agilemanifesto.org

У меня сложилось мнение, что многие, имеющие претензии к аджайлу/скраму/ещё_чему_то, учили эти понятия по цитатам на башорге.

Agile — это идеология, там нет ни слова про «спринты», «беклоги» или итеративность.
Скрам — это Фреймворк, который ещё нужно адаптировать под вашу команду (и да, возможно на вашу специфику он не налезет).

Хорошо, тогда сформулируйте, пожалуйста, в двух фразах, Ваше понятие об «Идеологии Agile», если Вам не жалко минутки? Мое лично понятие — меньше бюрократии — больше valueable profit от конкретных действий, пусть и маленьких. А для этого я использую частую итеративность и беклоги проекта/спринтов :)

www.agilemanifesto.org/iso/en тут все сказано.
Так какие у вас претензии к аджайлу?

Попробую еще раз объяснить суть своего вопроса. К самому аджайлу у меня нет претензий, у меня вопросы к публике — кто как его понимает, и кто какого мнения о нем. Сам манифест я поддерживаю, но как и любая декларативная часть — он может быть существенно изменен по факту внедрения в какой-то конкретный проект каким-то определенным менеджером проекта.
Вот я и хотел собрать мнения публики — кто что чувствует, и какая самая полезная часть от методик им была освоена или испробована.

Знаете, читаешь вот книгу именитого автора, толстенная такая, может быть даже в двух томах, или «издание третье, переработанное и дополненное», а прочел, и понял, что во всей книге — одна единственная мысль. Да, полезная. Да, умная, новая и все такое, но одна (максимум две), а вся книга — это преамбула и эпилог к этой мысли. А, и еще, на американский манер, объяснение этой самой мысли в фабуле повторяется несколько раз, при помощи различных подходов и с различных точек зрения. Ну уже чтобы всем понятно было )

Опять. В самом аджайле нет методик.
А обсуждать видоизмененный «публикой» скрам — это как критиковать Битлз по напевкам Рабиновича.

Но ведь у каждого святого писания тоже есть различные течения ;)

Профанация и развод для лохов — вот приблизительно так я характеризую подобные новомодные методики.
Как бы нам не хотелось, но каждый проект по-своему индивидуален: командой, временными рамками, набором решаемых задач, деталями взаимодействия. И невозможно вот так взять всё и бац, стандартизировать. В реальной жизни эффективнее создавать индивидуальные наборы методик/инструментария под конкретный проект.

подобные новомодные методики
Scrum появился в 95 году, 20 лет назад...

Канбан рулит. Всё остальное, что не использует канбаны в том или ином виде — жалкая имитация контроля над процессом.

В скраме слишком многое зависит от человеческого фактора. Правильнее сказать, в саму технологию встроены возможности злоупотребления с каждой из сторон, и редко кто устоит перед соблазном их эксплойтить. Канбан наоборот — исключает человеческий фактор из тех процессов, где он вреден. И хотя введение канбанов не мешает иметь скрам в полный рост, равно как и многие другие вариации — как правило канбан самодостаточен и весь процесс переходит именно туда, превращая другие надстройки в бесполезный ритуал.

Ну и ещё такая мелочь — скрам приводит к выгоранию людей, притом настолько же глубокому как посттравматический синдром. Люди становятся на редкость безответственными, нетерпеливыми, злыми и циничными. Я бы даже сказал он для этого предназначен.

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

А мне кажется скрам несколько вторичен в плане выгорания.
Я например заметил следующее — онсайт с коммандой талантливых и мотивированных девов, у которых заразная мысль бороздит океяны, за месяц я чувствовал себя как выжатый лимон. Это при напрочь поломаном скраме.
В удаленке же, где митинги, таски, эстимейты, джира, планирование, вот это все, но нет рядом коллег, и можна среди бела дня пойти на пляж (тайм зона всеравно другая, nobody really cares) то эффект прямо таки противоположный.

Т.е. я правильно понял? Если коллеги рядом, и надо еще вести доску задач в Jira и формализовать результаты митигов — то тогда уже memory overrun ?
Ну а так, да, если коллеги рядом в одной комнате, то можно за день горы своротить. Сталин так и делал. Закрывал группу инженеров в тюрьму, и работали они по расписанию и под наздором НКВДистов. Такой метод управления проектами назывался «Шарага» ))
Заодно полнейшая конфиденциальность и гарантия отсутствия утечки информации. Penetration tests проводились в рядах надзирателей-конвоиров, силами контрразведки ))

Если коллеги рядом, и надо еще вести доску задач в Jira и формализовать результаты митигов — то тогда уже memory overrun ?
С моей точки зрения, все эти доски с митингами, преследуют одну цель — еще повысить мотивацию девов, и достигают они это тем, что со старта показывают самим программистам прогресс. Одно дело пилить в вакуме фичу пару месяцев, пусть даже и с планом. Другое дело каждую неделю иметь промежуточный результат и «good work».

Что именно от канбана Вам нравится? Доска? Нет, я не против, я просто уточнить хочу. Какой тип проекта Вы по канбану делали/участвовали?

Agile — это идеология. Я ещё не знал таких слов, но наша команда уже так работала. Здесь главное понять — что бизнес рулит, и что просчитать программный процесс невозможно наперёд. А также эта методология очень успокаивающе действует на начальство. У меня лет 10 назад была ситуация, когда требовали полного планирования программного процесса с выводом трудочасов, планированием окончания проекта за полгода вперёд и т.д. В общем практически RUP. Тратилась уйма времени на это, причём впустую. Потому что: а) рассчитать большой проект невозможно (особенно если это инновация). б) программисты — непрактичные люди как правило, и большинство из них склонны неправильно считать скорость своей работы . т.е. как правило, им кажется, что они сделают всё в 2 раза быстрее, чем это получится на самом деле. в) пока ты тратишь время на разработку плана проекта, его согласование — проходит куча времени, за которое можно было уже двигаться. г). Никогда невозможно просчитать, что будет за поворотом.
Поэтому мы постепенно убедили руководство, что мы работаем ради бизнеса, работаем с той скоростью, как можем (но максимально самоотверженно), планы меняем по ходу дела, при этом не забываем приглашать руководство и всех желающих на митинги по планированию, если клиент что-то просит изменить, или нашёлся баг — всё бросаем и исправляем. В общем — получили Agile, который стал культурой нашей команды.
Ну а теперь я получил и научное подтверждение, распечатал манифест, и радуюсь вместе с руководством.
Что касается методологий — то, на нашу команду Scrum не налазит — слишком всё у нас быстро меняется, слишком много поддержки мы оказываем, да и команда небольшая и менее формализованная. Плюс, в моём представлении чистый Scrum — чисто американская методология в стиле баптистских священников, призванная зажечь толпу на подвиги ежедневными митингами и харизмой скрам мастера. Его в наших условиях нужно видоизменять.
А вот Kanban мне полюбился. Какую-то вариацию Kanban — Scrum буду внедрять.
Что именно внедрять:
1. ежедневные митинги с обсуждением всех проектов. Это очень сплачивает коллектив, плюс даёт ПМу самому не потерять контроль над проектом, а также возможность быстрого переключения сотрудников, которые всегда в курсе ситуации. Эти митинги с участием всех разработчиков (у нас не очень большая команда) — потому все сразу.
2. Доска (в стиле Канбан) — это крутое средство визуализации, также в первую очередь инструмент ПМа.
3. Планирование релизов — ( но с плавающей периодичностью). Т.е. не раз в определённый срок, а плюс минус, чтобы релиз был полностью готов, оттестирован, описан и т.д. План должен быть, но не жёсткий. Здесь в Scrum именно важная вещь — это то, что релизы должны быть как можно чаще. Просто эта частота может зависеть и от обстоятельств.
4. Почему Kanban — потому что команда ведёт сразу несколько проектов, между которыми и переключаемся в зависимости от ситуации. Kanban позволит нам правильно спланировать и визуализировать задачи, боле гибко реагировать на ситуацию, но при этом не потеряв учёт времени.

Почти все проекты которые я когда-либо делал и делаю, включая собственные — построены на канбане. Само слово «канбан» означает «карточка». Его суть — разделение процесса на малые зоны ответственности, идеально прилегающие друг к другу.

А доска не более чем красивый элемент. Если нет соревнования, её можно даже не вести.

Ключевая сущность канбанов — в том что они живут своей жизнью. Под каждый из них легко пишется жизненный цикл. Достаточно просто решаются типовые «сложности»: без труда рождаются и внедряются дополнительные канбаны, изменяются приоритеты, достаются из долгого ящика отложенные задачи.

К примеру, есть проект который реанимировали спустя полтора года остановки. Знаешь, сколько заняла реанимация? 2 минуты. То есть его реанимировали ещё до того, как я с заказчиком положил трубку, и мы не прекращая разговора обсудили детали как будто проект находился в разработке буквально только что. Пожелание исполнили тем же днём и тогда же благополучно законсервировали проект.

Недостатки у канбана тоже есть. Всего два, но значительные!
1) Работая по канбанам, люди начинают бояться новых крупных задач. Старт большой задачи может долгое время откладываться, если есть незавершённые канбаны знакомого процесса, пусть и с низким приоритетом. Как ни странно, именно менеджер и откладывает. Другими словами, решения о крупных изменениях не подчиняются этой системе, они должны вноситься извне.
Следствие: Нужна хоть какая-нибудь система риск-менеджмента до запуска, иначе объекты риска не найдут отражения в канбанах и проблемы создадут снежный ком.

2) Канбаны очень легко ложатся в долгий ящик, и несрочные задачи имеют тенденцию к накоплению. Некоторые задачи так и остаются канбанами — формально они должны быть реализованы, но реальный срок их реализации стремится к бесконечности. Нужен человек в чьей зоне отвественности будет анализ долгого ящика и иногда что-то должно делаться. Это должно стать принципом, люди должны получать удовольствие от повышения качества (а именно эти задачи занимают львиную долю «несрочных»).

Есть и ещё +1, но является ли он недостатком — с какой стороны посмотреть. Люди становятся трудоголиками.

Подписаться на комментарии