[makc 202]

8 минут назад, mplata сказал:

Дальше можно даже не читать. 

Если не относиться критически, то будет ровно то, о чем писал автор статьи. Так что читать однозначно стоит.

[mplata 8]

4 minutes ago, makc said:

Если не относиться критически, то будет ровно то, о чем писал автор статьи. Так что читать однозначно стоит.

Статья прочитана, с комментариями. 

Но ее практическая ценность стремится к нулю в виду того что на стороне автора статьи есть однозначная проблема декомпозиции задач и не было положительной реализации скрама. А принцип: если у меня не получилось то и у других тоже - не повод к написанию обобщающей статьи. 

[makc 202]

3 минуты назад, mplata сказал:

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

Автор говорит о подобных проблемах не в одном, а в ряде проектов и о том, к чему это приводило. Поэтому если вы не считаете это системной проблемой, то что это по вашему? И почему тогда вы так уверены, что не повторите таких ошибок, но на свой лад?

[dxp 51]

9 часов назад, mplata сказал:

Там адекватные комменты

Некоторые да. Но те, про которые вы:

9 часов назад, mplata сказал:

Самый первый в точку: автор статьи считает: "если не умеешь пользоваться скрамом то и другие не умеют. "

Про это там тоже было: универсальная перманентная отмазка: не умеете пользоваться. Ну-ну.

 

9 часов назад, mplata сказал:

Вы читаете автора, у которого явные проблемы с декомпозицией. 

Нет у автора никаких таких проблем. Декомпозиция в RnD работает непредсказуемо, т.к. задачи такие. А при разработке железа, где всё инертно в силу инертности самого предмета разработки, вся эта т.н. гибкость не работает и не нужна. И вообще весь скрам не нужен от слова совсем.

 

9 часов назад, mplata сказал:

Автор статьи просто не умеет пользоваться инструментом. Это из цикла товарищ прапорщик в этой кружке нет дна, и верх запаян. 

Во, опять та же самая отмазка. 🙂

[mplata 8]

12 hours ago, makc said:

И почему тогда вы так уверены, что не повторите таких ошибок, но на свой лад?

Потому что у нас этот инструмент уже работает.

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

 

2 hours ago, dxp said:

 

Про это там тоже было: универсальная перманентная отмазка: не умеете пользоваться. Ну-ну.

Ну я не могу обсуждать Ваш случай. Так как я понятия не имею почему у Вас скрам не заработал. 

Но за что я могу ручаться так это за то, что у нас он работает. 

Приходите 16го на конференцию АРПЭ, там все расскажем. 

[makc 202]

33 минуты назад, mplata сказал:

Потому что у нас этот инструмент уже работает.

 

33 минуты назад, mplata сказал:

Но за что я могу ручаться так это за то, что у нас он работает. 

Так и в вышеупомянутых статьях все скрам-мастера говорят ровно то же самое, но вот снизу это для работников выглядит (может выглядеть) совсем совсем иначе. Поэтому объективности ради хотелось бы узнать не только ваше мнение, но и мнения других участников процесса, о которых по-моему вы ничего не писали выше и которые вряд-ли приедут с критическими выступлениями на конференцию АРПЭ. Поэтому, как показатель объективности, могу предложить вам покритиковать ваше "работающее решение", ведь не может же быть всё идеально? Или может? 😉

[A.V.Avtomat 18]

https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://www.youtube.com/watch%3Fv%3DuOUkly9v3_k&ved=2ahUKEwiSvszR9t6GAxWUHXcKHXCGC0gQwqsBegQIDRAG&usg=AOvVaw2uA8z5zAvX2TlHY0GWHIcA

Изменено 16 июня пользователем A.V.Avtomat

[mplata 8]

On 6/15/2024 at 9:28 PM, makc said:

 

Так и в вышеупомянутых статьях все скрам-мастера говорят ровно то же самое, но вот снизу это для работников выглядит (может выглядеть) совсем совсем иначе. Поэтому объективности ради хотелось бы узнать не только ваше мнение, но и мнения других участников процесса, о которых по-моему вы ничего не писали выше и которые вряд-ли приедут с критическими выступлениями на конференцию АРПЭ. Поэтому, как показатель объективности, могу предложить вам покритиковать ваше "работающее решение", ведь не может же быть всё идеально? Или может? 😉

Исполнители разные. Кто то принимает , а кто то нет. 

Негатив от скрама:

1. Разговор переполнен англицизмами: дэйлик, бэклог, заданить и т.п. многих от этого корежит очень. 

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

3. Разработчики, как правило, интроверты и общение в группе публичное даётся некоторым сложно, особенно поначалу. 

4. В целом повышается интенсивность работы и если раньше разработчик чувствовал себя если не Богом то очень важным и диктующим правила, то теперь с него спрашивают и влезают в его кухню очень активно, это вызывает отторжение. Богоподобных разработчиков мы либо заземляем а если не получается - удаляем из команды. 

5. В целом внедрение скрама у нас происходило в несколько этапов:

А. Старт и интерес у всех участников

Б. Напряги и ломка в связи с тем что появились новые ритуалы и нужно перестраиваться. Тут появилось некоторое сопротивление 

В. Принятие, но не глубокое. То есть люди смирились с ритуалами. Недостаточно времени прошло до результатов. Но выбора нет , приходится работать в скраме.

Г. Принятие полное после получения результатов, становится понятным что работа в скраме даёт плоды. Есть результаты. Члены группы понимают что ничего не проспали, выполнено все в сроки, нет суеты перед сдачей, нагрузка распределена по проекту ровно. Команда мама хочет работать так далее. Ритуалы привычны и встречаются позитивно. Все синхронно и плавно. 

Кстати, по результатам конференции АРПЭ выяснилось что Аджайл используется очень широко именно в разработке железа! Мы не ожидали что это так распространено. Мы встретили понимание.

[Maksim_2444 7]

4 часа назад, mplata сказал:

Исполнители разные. Кто то принимает , а кто то нет. 

Негатив от скрама:

 

Самый главный негатив - не получиться "валять дурака" команде разрабов делая вид усердной работы. поэтому и полное отрицание этой концепции

 

4 часа назад, mplata сказал:

Кстати, по результатам конференции АРПЭ выяснилось что Аджайл используется очень широко именно в разработке железа! Мы не ожидали что это так распространено. Мы встретили понимание.

Аналогичные подходы к разработке существовали всегда - даже в СССР. 

Только такой подход позволял добиться хоть каких-то адекватных результатов в вменяемые сроки.

[mplata 8]

2 hours ago, Maksim_2444 said:

Самый главный негатив - не получиться "валять дурака" команде разрабов делая вид усердной работы. поэтому и полное отрицание этой концепции

Да, и это было подтверждено на конференции очень приличным количеством компаний которые занимаются разработкой. Для нас это было приятной неожиданностью.

Методика рабочая во многих даже российских компаниях. 

2 hours ago, Maksim_2444 said:

Аналогичные подходы к разработке существовали всегда - даже в СССР. 

Только такой подход позволял добиться хоть каких-то адекватных результатов в вменяемые сроки.

Да, только назвались эти методики не англицизмами, а так суть та же. Согласен. 

[kpv 7]

5 hours ago, Maksim_2444 said:

Самый главный негатив - не получиться "валять дурака" команде разрабов делая вид усердной работы. поэтому и полное отрицание этой концепции

вы никак не поймёте, что "контроль за исполнителями" - это совсем не называется скрамом.

Если вам бездельников надо ловить - это называется KPI, который  позволяет контролировать и оценивать работу.

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

А то что вы сейчас "переизобретаете" называется микроменеджмент

[kpv 7]

11 часов назад, mplata сказал:

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

это тупик какой-то логики, поэтому и ходим по кругу.

1. вы нанимаете  людей, у которых нет элементов самоорганизации или какого-то понимания управления и ведения проектом и при этом бросаете его в свободное плавание, в надежде, что он выплывет.

2. к вам не пойдут люди (из-за низкой зарплаты, из-за бардака в понимании всех этих процессов и ещё куча разных причин), потому что они за версту чуят, чем это кончается

3. а кончается это тем, что такой разработчик действительно может всё бросить и уйти на более высокооплачиваемую работу, а у вас повиснет проект или нае@#ётся всё капитально без него. ну а как может быть иначе, если вы ничем не хотите управлять?

"работники, которые не хотят работать" - про них столько анекдотов на эту тему, что можно ваш изобретённый "аджайл", весь пересказать.

давайте начнём с индусов, как один из самых ярких примеров, как их пытаются контролировать, а они изобретают всяческие способы обойти этот контроль?

Потому что kpi с программистами очень сложно изобрести и копья на эту тему ломают очень давно. В микроменеджменте на практике побеждают те, у которых в программировании навыков ноль, но зато хорошо язык подвешен.  И  термин "профессиональный" есть - мужское пизд@%#льство. а так как вы хотите держать разрабов в ежовых рукавицах (называя это почему то "помощью в разработке") то менять вам этих разрабов до мокровкиного заговенья. отъявленные пиз@#*олы у вас будут отваливаться до шести месяцев, потому что и вы и они поймут, что халявы не будет. Нормальные разрабы продержатся до года, потому что такой анальный секс в разработке им особо не приемлем, ничего нового они не узнаю, а только профессионально будут деградировать. А вот студенты и неопытные будут всё терпеть, потому что им во первых наработка стажа и опыта, а во вторых они ничего больше в мире не видели. И в срок до 2-3 лет наберутся опыта и слиняют в хорошие места, а ленивые останутся и будут изображать видимость работы, так как всё и вся уже изнутри знают и найдут лазейки. У меня даже смешной случай из жизни есть, когда на собеседовании спросили "на какой уровень зарплаты вы рассчитываете, если ничего не будете делать, а только пить кофе".

 

[kpv 7]

4 hours ago, mplata said:

Да, только назвались эти методики не англицизмами

если пользоваться аналогиями из СССР - функции контроля сейчас выполняет "мастер участка", раздаёт люлей слесарям и не даёт бухать линейному составу. И там точно такая же проблема управления, когда какой-нибудь "Михалыч" увольняется или выходит на пенсию. Люди старой закалки, обычно, очень ответсвенные и самоорганизованные, поэтому как там этим участком управляет Михалыч до поры до времени никого не интересует. Есть какие-то устоявшиеся метрики эффективности (план, процент брака, стабильность показателей и так далее) и начальство обычно это устраивает.

А без "Михалыча" надо что-то построить, и тут приходят "эффективные менеджеры", которые не хотят во всё это вникать.  Ломают достаточно эффективный коллектив, отчитываются по новым правилам KPI, что работа сделана, эффективность повышена. 

Но когда они увольняются, то опять выясняется, что надо искать нового "Михалыча", а найти ему замену очень сложно: или пьёт, либо гонору много, а ничего не умеет. В таких ситуациях, конечно, много других условий накладывается, но там kpi всё таки не такая сложная задача и контролировать результаты работы можно научиться и без "Михалыча".

 

Но это совсем не методика  управление проектом, а управление людьми. Это про кнут и пряник, это про мотивацию. Про поддержание эфективности. Это печеньки в офисе, кофеавтомат в холе, поддержка благоприятной атмосферы в коллективе. ДМС и путёвки в пионерлагеря.  Это где-то рядом (оно может даже вносить коррективы в управление проекта) работает параллельно, чтобы у начальства была метрика, по которой они могут оценить работу каждого отдельно и команды целиком. В идеальном случае это не надо, какогда все добросовестно относятся к своим обязанностям (но при этом управление проектом никуда не пропадает). И надо десять надзирателей за одним исполнителем, если дела совсем плохи. Наручниками к столу, не выпускать за пределы завода, пока не выполнишь план. Сечь розгами откровенных бездельников. Мы говорим и думаем о разных вещах, поэтому получилось как в анекдоте: со стороны руководства мысли совсем другие - чтобы корова меньше ела и давала больше молока, её нужно меньше кормить и больше доить.

[A.V.Avtomat 18]

8 часов назад, mplata сказал:

Да, только назвались эти методики не англицизмами, а так суть та же. Согласен. 

Главной послевоенной методикой в СССР  было наличие репрессивного аппарата, который не позволял "валять дурака" и "бить баклуши" за государственные деньги.

И не надо путать репрессии с повышением эффективности, хотя эти репрессии так же, а скорее быть даже и сильнее повышали эффективность, как ваши методики.

Надеюсь, что все знают "методику" стимулирования труда коллектива, создававшего советскую атомную бомбу