Comments 20
Так что же всё таки не так? Аналогичную статью можно про что угодно написать, имхо
для Scrum нет хороших альтернатив, конкуренция отсутствует.
А как же Kanban?
2. Kanban это мелкий тактический инструмент, и далеко не главная часть системы Lean.
Kanban не конкурент Scrum просто потому что это тактический инструмент огранизации
процесса передачи работы и все. Это не методология.
Если 看板 для вас работает, это отлично.
На всякий случай, хочу порекомендовать вам пару книг:
Джеффри К. Лайкер, Дао Toyota и
Мэри и Том Попендик, Бережливое производство программного обеспечения (увлекательное чтение).
Тем не менее, Kanban это всего лишь способ _сокращения_ waste перепроизводства
за счет ограничения объема незавершенной работы. Суть, если у вас на команду
уже, скажем, 6 задач в работе, вы не можете взять седьмую пока не закончите
одну из уже начатых. Очень разумно. Тем не менее, есть тонкости.
Вообще говоря, с точки зрения Toyota, Kanban это _один из самых плохих_
способов организации работы, и то к чему нужно стремиться — организации
потока производства единичных изделий. То есть вообще не браться за
вторую задачу пока не сделана первая. Это идеал, он не всегда достижим.
Также, нет ничего плохого в тактических инструментах, наоборот, они важны и нужны.
Kanban это техника организации _процессов_, это важно, но это тактика.
Scrum «больше» Kanban, поскольку позволяет работать с проектами,
а с точки зрения организации проекты сложнее процессов.
И да, Kanban был придуман до Agile, вот уж не знаю когда он был адаптирован к разработке. Scrum тоже был придуман до Agile. А что было придумано после 2001?
Интереснее всего то, что в итоге инженеры встали в оппозицию и даже начали бороться с Agile. Например, несмотря на то, что Robert C. Martin был одним из основных организаторов мероприятия, теперь он не только выступает против, но и составил свой Software Craftsmanship Manifesto.
Во первых хотелось бы получить пруфы на то, где дядюшка Боб откровенно выступает против Agile? Я пока что видел только его выступления где он вещает о том, что Agile неправильно поняли и неверно используют. Что кстати безусловно так и есть.
Во вторых он говорит о том, что пришли менеджеры и сделали на Agile бизнес, похоронив все то что за ним стоит и оставив все эти тренинги, покеры и прочую хрень.
В третьих Software Craftsmanship Manifesto — этот манифест совершенно о другом. Это манифест программистов ремесленников если быть буквальным. Этот манифест не о процессах разработки ПО а о разработке как о ремесле. И о разработчиках профессионалах. И Agile он не отменяет, а наоборот дополняет общие принципы личной ответственностью.
А еще он говорил и не раз о том, что по тем принципам по которым построен Agile IT профессионалы работали задолго до появления waterfall, а сама модель водопада стала ответом на то что рынок наводнили полчища низкоквалифицированных кодеров которые по сути или не являются профессионалами или являются слишком зелеными и молодыми и не имеют должного опыта чтобы работать по Agile и следовать Software Craftsmanship Manifesto.
Если не верите, один из пруфов, его выступление: «The Future of Programming».
1. Позиция Robert C. Martin относительно Agile высказан им прямо в статье:
techbeacon.com/uncle-bob-martin-agile-manifesto-15-years-later
That said, today’s agile is not the same agile that was discussed at the meeting.
и далее по тексту.
2. Software Craftsmanship Manifesto — конечно о другом, об индивидуальном профессионализме
и профессиональной этике. Это все безусловно важно, но работает уровнем ниже.
Agile это идея для коллектива, Craftsmanship — для отдельно взятого профессионала.
That said, today’s agile is not the same agile that was discussed at the meeting.
Вот это и есть суть того как мне кажется: «Что не так с гибкими методологиями».
То не так, что их исказили до неузнаваемости, отбросили из них все важное и добавили кучу всего второстепенного и теперь толкают в каждом втором переходе. И imho в том числе и Роберт Мартин об этом говорит.
Главным достижением Agile-инициативы стал посыл — работать можно по-другому. Можно искать другие пути достижения целей, пробовать нестандартные варианты решения проблем, творчески подходить к организации работы, смотреть на вещи шире своей специализации, пробовать, ошибаться.
Вы меня, конечно, извините, но это утверждение несколько… как бы то выразиться… Самоочевидно. Класс, блеск, "работать можно по-другому!" и последующее молчание навевает на мысль "но как именно — мы не знаем...". Agile как общественное явление "подсветил" подзабытые практики управления, а местами добавил новые. Sapienti sat. Адекватные управленцы возьмут и внедрят то, что работает для их организации и проекта, а что избыточно или неэффективно — не будут внедрять. Неадекватные управленцы, видимо, воспринимают Agile как религию и занимаются тем, что ходят по конференциям, тыкают друг в друга пальцами и качая головой подмечают: "ой, а вот тут у вас не agile" или "ооо, вы классные, у вас полный agile". То есть выполнение определенных ритуалов (покер, митинги, доски) в медийной плоскости стало показанием к увеличению авторитета той или иной команды, которая использует оный для… чего? Для красочных презентаций начальству? Начальство смотрит в бухгалтерию и без того всё прекрасно понимает. Для инженеров? Хорошие инженеры в гробу видали методологии управления и справедливо смотрят на них с непониманием. Вот и получается, что agile — это религиозное верование для менеджеров среднего звена, которым, видимо, нечем себя занять, а ответственно, быстро и качественно управлять процессом они не способны. Вот и ходят, смотрят друг на друга и меряются — у кого agile-нее.
Все это можно было и до Agile, но нужно было иметь большую смелость и авторитет, для того чтобы предложить что-то новое.
Смелость? Авторитет? Други мои, у вас есть компания, вы на короткой ноге с её руководителем. Какая, позвольте поинтересоваться, смелость вам нужна, чтобы прийти к CEO и сказать "коллега, у нас вот тут такие-то и такие-то проблемы, давай попробуем поступить так-то и вот так, у меня есть парочка идей"? При чем тут Agile, божечки?
Какой авторитет? Если ваша практика будет работать для вашей компании и обеспечивает вашим клиентам стабильные поставки и качественный продукт по минимальным костам — те, кому надо — просто придут и спросят как вы так сделали, а вы им расскажете. Или не расскажете. Или для них это работать не будет. О каком авторитете речь?
Agile позволил нам открыто говорить о проблемах и обсуждать небанальные варианты их решения.
Для того, чтобы открыто говорить о проблемах никакой agile не нужен. Нужно осознание что shit happens и чем быстрее о проблеме узнать — тем больше шансов её решить. И это не такое уж сакральное знание, чтобы создавать для этого целую новую идеологию. Это необходимый и базовый навык, без которого в бизнесе и управлении делать нечего.
«но как именно — мы не знаем...»— готового рецепта нет, факт.
Адекватные управленцы— все приходит с опытом, чтобы что то уметь, сначала нужно этому научиться.
Хорошие инженеры в гробу видали методологии управления— не совсем взрослая позиция, если человеку все равно как он работает, он получит то что получит.
вы на короткой ноге с её руководителем— а если не на короткой ноге, а наоборот, вы первый месяц в компании. У вас свежий взгляд, проблемы к которым все привыкли для вас очевидно, но, видите ли, ноги оказываются недостаточно короткими чтобы быть услышанным. Такое бывает.
те, кому надо — просто придут и спросят— такое тоже случается, но не всегда.
Для того, чтобы открыто говорить о проблемах никакой agile не нужен.— вы правы, нужна культура допускающая такую возможность. Как она называется не суть важно.
все приходит с опытом, чтобы что то уметь, сначала нужно этому научиться.
Кхм… Так, простите, зачем тогда так называемые "управленцы" посещают всякие курсы, тренинги, покупают книжки, получают MBA? Тут или крестик или трусы. Или признать, что только на практике можно познать все тонкости управления, а все эти обучалки — чистой воды надувательство. Или признать, что преподаваемый на них материал управленцы не могут применить "в полевых условиях" и надо бы наших управленцев сдавать на утилизацию.
не совсем взрослая позиция
Взрослая. Разработчик решает задачи, которые ему ставят. Как именно это делается и через какие тернистые пути проходят эти задачи в идеале разработчика касаться не должно. На практике я допускаю, что возможна двусторонняя консультация по приоритетам и порядку выполнения задач, но в целом собирать целый отдел разработчиков и заставлять показывать друг другу свои достижения и активно общаться — извините, это противоестественно и порождает корпоративную контркультуру ("меньше дела — больше слова"). Сугубо ИМХО.
нужна культура допускающая такую возможность
Дело не в культуре, а… Я даже не знаю как объяснить. В общем нежелание какого-то отдельного начальника признавать существование проблем, равно как и отрубать голову гонцу, принесшему дурную весть — это из области общей психологии. Комплексы, страхи, незакрытые гештальты… И как по мне — то (если брать сферический случай в вакууме) психологическая проработка даст гораздо больший результат, нежели тактика "просто миримся со странностями начальника — он в праве быть таким, какой он есть".
а если не на короткой ноге, а наоборот, вы первый месяц в компании
Напрямую относится к написанному выше. Если вы нанимаете менеджера, чтобы он разрулил конкретные проблемы с проектом, но выдаете ему при этом полномочия рядового программиста, то на какой же, пардон, результат вы рассчитываете? Это как отдать машину в автосервис, но настрого запретить открывать капот без присутствия и комментариев хозяина авто. И это опять же психологические проблемы нанявшего менеджера начальства.
Если же в такой ситуации оказывается разработчик, который видит проблемы, но не может донести до начальства, то… Печалька. Оптимально — попытаться реквизировать некоторые рычаги управления, а если не получится — то проще уволиться.
К сожалению, у меня нет успешного опыта работы по аджайл-методике… Все разы складывалось впечатление, что аджайл — для оправдания непонимания руководителями того, что должна делать команда, (а такое понимание — прямая обязанность руководителей) при том, что команда должна «шуршать». И вот это вот и есть та суть, которую я пока что мог видеть: «мы не понимаем, что делать, но мы хотим чтоб вы не расслаблялись».
Вместо того, чтобы хотя бы пробовать учиться решать реальные задачи управления (оценка необходимых сроков и ресурсов, мониторинг, оптимизация) собираются ежедневные ритуальные микро-совещания.
Раз в манифесте про архитектуру ничего не сказано, и нам её не надо. Про качество манифест тоже напрямую ничего не гоаорит. И мы этот вопрос не поднимаем. Главное чтобы командный дух был.
Замечано: чем меньше менаджер проекта разбирается в технических аспектах, тем большее значение он уделяет ритуалам.
О’Жаль: Что не так с гибкими методологиями