Вхід і реєстрація
Різне · 22 березня 2015, 22:48 1140
Denys Ryzhykh, Agile Coach, Authorized Instructor ICAgile, Scrum Master в Luxoft

Претензии к Agile

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

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

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

Теми: Agile, PMBOK, Scrum
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
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
Stas Bondarets Product manager 24.03.2015 00:09

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

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

Відповісти
Підтримати
Ilya Palkin Software Developer 23.03.2015 18:31
“легким взмахом карты 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.

Відповісти
Підтримати
Denys Ryzhykh Agile Coach, Authorized Instructor ICAgile, Scrum Master в Luxoft 23.03.2015 14:58

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

Відповісти
Підтримати
anonymous
anonymous 23.03.2015 11:20

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

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

Відповісти
Підтримати
Pavel Kruchina CTO 23.03.2015 08:00

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

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

Відповісти
Підтримати
Denys Ryzhykh Agile Coach, Authorized Instructor ICAgile, Scrum Master в Luxoft 23.03.2015 09:18

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

Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 23.03.2015 09:41

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

Відповісти
Підтримати
Denys Ryzhykh
Denys Ryzhykh Agile Coach, Authorized Instructor ICAgile, Scrum Master в Luxoft 23.03.2015 10:10

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

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

Відповісти
Підтримати
Pavel Kruchina
Pavel Kruchina CTO 23.03.2015 10:21

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

Відповісти
Підтримати
Denys Ryzhykh
Denys Ryzhykh Agile Coach, Authorized Instructor ICAgile, Scrum Master в Luxoft 23.03.2015 11:24

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

Відповісти
Підтримати
Pavel Kruchina
Sergio Gonzales 23.03.2015 04:07

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

Відповісти
Підтримати
anonymous 23.03.2015 11:03
подобные новомодные методики
Scrum появился в 95 году, 20 лет назад...
Відповісти
Підтримати
Sergio Gonzales
Олексій Пєніє 23.03.2015 03:06

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

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

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

Відповісти
Підтримати
Нестор Иванович 23.03.2015 03:25

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

Відповісти
Підтримати
Олексій Пєніє
Grez 23.03.2015 04:23

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

Відповісти
Підтримати
Нестор Иванович
Denys Ryzhykh Agile Coach, Authorized Instructor ICAgile, Scrum Master в Luxoft 23.03.2015 09:16

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

Відповісти
Підтримати
Grez
Grez 23.03.2015 14:38
Если коллеги рядом, и надо еще вести доску задач в Jira и формализовать результаты митигов — то тогда уже memory overrun ?
С моей точки зрения, все эти доски с митингами, преследуют одну цель — еще повысить мотивацию девов, и достигают они это тем, что со старта показывают самим программистам прогресс. Одно дело пилить в вакуме фичу пару месяцев, пусть даже и с планом. Другое дело каждую неделю иметь промежуточный результат и «good work».
Відповісти
Підтримати
Denys Ryzhykh
Denys Ryzhykh Agile Coach, Authorized Instructor ICAgile, Scrum Master в Luxoft 23.03.2015 09:12

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

Відповісти
Підтримати
Олексій Пєніє
Sergey Los Technical Director Odrex в Odrex 23.03.2015 12:55

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

Відповісти
Підтримати
Denys Ryzhykh
Олексій Пєніє 24.03.2015 01:26

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

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

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

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

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

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

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

Відповісти
Підтримати
Denys Ryzhykh

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.