[kpv 7]

11 hours ago, Mplata_DEV said:

Agile это философия максимально быстрого внесения изменений в проект

ну хотя бы один пример сложного embedded изменения приведите. 

можно даже не в каких то условных деталях, а сколько времени уходит на переделку железа в результате "маленького нового желания" заказчика?

11 hours ago, Mplata_DEV said:

максимально четко ставит разработчикам актуальные именно на данный момент задачи.

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

 

On 5/19/2024 at 3:40 PM, dxp said:

о когда ведётся разработка материнской платы сервера (со 128-ядерным процессором и 16 планками DDR4), где работа схемотехника и конструктора ПП  занимает по полгода

я картинку для такого случая даже нашёл 🙂 как быстро сделать такую материнку (в левом нижнем углу)

https://www.scruminc.com/scrum-in-hardware-guide/

 

[kpv 7]

и уже достататочно классический пример аджайла на практике https://innovel.net/how-to-avoid-fatal-product-flaws-with-agile-and-scrum/

методология scrum хороша для R&D, НИР, НИОКР

да собственно во всех статьях это видно невооружённым взглядом

https://scrumtrek.ru/blog/agile-scrum/1753/extreme-manufacturing-principles/

[kpv 7]

Это и называется "х%як, х%як и в продакшен".

Чтобы довести это все до производства - это ещё один этап разработки.

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

Изменено 24 мая пользователем makc

[dxp 52]

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

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

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

Скрам-мастера. Это зачем они вообще нужны? Это люди, которые не обязаны быть специалистами в целевой тематике разработки, их задача -- организовывать процесс: проводить дейлики, планирования, ретры. Т.е. это по сути секретарь-стенографист на заседаниях. 

Дейлики. Зачем они нужны? Зачем обязательно собираться каждый день? Собираться надо по делу -- on demand. Надо если, то хоть три раза за день можно собраться, а не надо, так и неделями можно этим не страдать. Какие-то локальные вопросы люди, работающие совместно над задачей, решают оперативно сами на своём уровне, не отвлекая остальных. Более глобальные вопросы курирует руководитель работы, и если  надо, собирает людей -- не всех, а только тех, кто нужен с его точки зрения -- на совещание/планёрку. Когда люди собираются по делу -- для решения возникшего вопроса, это собрание полезное и живое. А когда они собираются, потому что так положено по распорядку -- ну, скрам требует проводить ежедневное собрание (дейлик) -- то это превращается в профанацию, потерю времени и снижение мотивации.

Продукт овнер. Он кто? Руководитель работы? Нет! Это типа заказчик или внутренний представитель заказчика. Он озвучивает (ставит) задачи -- в бэклог, а команда выбирает из бэклога те, что считает нужными делать в первую очередь. Команда решает! Да, команда, конечно, лучше знает, что надо делать в первую очередь. Вот прикольно было бы посмотреть, если на корабле команда бы решала, куда плыть, а не капитан.

При этом продукт овнер -- не командир над командой (как заказчик не командир над разработчиками), поэтому прямого непосредственного влияния он не имеет. Он не может поручить конкретному человеку делать то или иное, он не может снять исполнителя с задачи и поручить её другому. Это понижает и без того ущербную управляемость.

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

И дело не в SCRUM vs Waterfall, а в грамотно выстроенной иерархии управления! Такая иерархия зарулит любой скрам по эффективности на раз. Главная проблема с ней состоит в том, что выстроить её сложно: это требует от управленца ума, опыта (жизненного и управленческого), множества хороших человеческих качеств (таких как настоящая (а не показная) уважительность к людям, мудрость, доброта, строгость-требовательность, дальновидность и справедливость) и умение разбираться в людях. Это редкие умения и это дано далеко не каждому. Такой человек -- это куда более ценный кадр, чем даже очень квалифицированный специалист в предметной области. 

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

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

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

В заключение можно отметить, что история знает немало примеров эффективного управления сложными проектами задолго до появления скрамов. Авиация, судостроение, космос, атомная отрасль. И на Западе, и в СССР. И качество процесса определялось исключительно компетентностью кадров. Так было, так есть и сейчас. И так будет и дальше, ибо природа человека не меняется.

 

 

[mplata 8]

6 hours ago, dxp said:

Конечно -- некомпетентность руководства в вопросах управления ко всему этому и приводит. В первую очередь -- к внедрению скрама.

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

6 hours ago, dxp said:

ну, скрам требует проводить ежедневное собрание (дейлик) -- то это превращается в профанацию, потерю времени и снижение мотивации.

у нас собираются по расписанию, это может быть каждый день, а может быть через день, в зависимости от проекта. И представьте себе, люди сами ждут этой встречи! Возможно скрам-мастер это ключевое, возможно результат работы кажджого виден даже если он (результат) небольшой, возможно что-то еще, но тем не менее. 

6 hours ago, dxp said:

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

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

 

6 hours ago, dxp said:

И из них ещё изрядный процент тщеславных мудаков

абсолютно согласен!!

 

6 hours ago, dxp said:

В заключение можно отметить, что история знает немало примеров эффективного управления сложными проектами задолго до появления скрамов. Авиация, судостроение, космос, атомная отрасль. И на Западе, и в СССР.

Да, покойный мой родственник запускал Буран и он полетел. Горжусь им. 

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

[mplata 8]

11 hours ago, kpv said:

я картинку для такого случая даже нашёл 🙂 как быстро сделать такую материнку (в левом нижнем углу)

Нож в руках убийцы это орудие убийства, нож в руках шеф-повара инструмент создания шедевра. Скрам это инструмент. 

и наличие красок не делает владельца художником. 

 

[mantech 40]

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

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

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

[dxp 52]

В 24.05.2024 в 15:25, mplata сказал:

Согласитесь, что скрам и некомпетентность руководства это независимые сущности.

На данный момент не могу согласиться, ибо первое является следствием второго. Где руководство умеет эффективно рулить, там никаких скрамов нет и не надо.

В 24.05.2024 в 15:25, mplata сказал:

Скрам будет работать если руководитель адекватен или не работает если нет.

А зачем эта сущность (скрам) вообще нужна, если руководитель адекватен? Нам-то поют,что скрам сам по себе прекрасен и неимоверно могуч, т.ч. делает хорошо независимо от руководителей.

В 24.05.2024 в 15:25, mplata сказал:

Нормальных скрам-мастеров почти нет.

В 24.05.2024 в 15:25, mplata сказал:

Возможно скрам-мастер это ключевое

Расскажите, пожалуйста, поподробнее про скрам-мастеров? Что это за роль (по-вашему)?

Что значит "нормальных нет"? А какие они -- нормальные?

Как скрам-мастер, который, напомню, вообще даже не специалист в предметной области, который не командир (не руководитель) в команде, который по сути никакой власти не имеет и несёт функции организации построений митингов и логирования их результатов, может как-то влиять на эффективность процесса разработки?

Из ваших слов получается, что всё упирается в скрам-мастеров, де, от них всё зависит. Я согласен с тем, что зависит от людей, но только если эти люди -- руководители процессов и исполнители. В первую очередь зависит от руководителей, во вторую от исполнителей. Где тут скрам-мастер, мне не понятно. Раскройте, пожалуйста, ваше понимание этой темы?

[Карлсон 3]

Скрамы, фигамы, это всё просто замечательно, но давайте вернемся к конкретике.

Вот есть у вас, например, задача: разработать портативный блок индикации на основе 128х128 rgb oled с поворотно-нажимным энкодером и питанием от двух АА, с блютусом, который получает данные от какого-то датчика и просто периодически отображает эту цифру на экране. Никаких требований по ЭМС, защитам, стойкостям и прочему нет. Дизайн тоже не нужен. Температура эксплуатации консьюмерская, время работы сколько получится. У вас в наличии в компании такие специалисты, как: конструктор механики, схемотехник, тополог, программист, снабженец, монтажник.

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

[kpv 7]

On 5/24/2024 at 12:49 PM, mplata said:

и наличие красок не делает владельца художником. 

и тут приходит заказчик и говорит: нужен ещё младенец 🙂

стырил комментарий с хабра

[mplata 8]

10 hours ago, Карлсон said:

Скрамы, фигамы, это всё просто замечательно, но давайте вернемся к конкретике.

Вот есть у вас, например, задача: разработать портативный блок индикации на основе 128х128 rgb oled с поворотно-нажимным энкодером и питанием от двух АА, с блютусом, который получает данные от какого-то датчика и просто периодически отображает эту цифру на экране. Никаких требований по ЭМС, защитам, стойкостям и прочему нет. Дизайн тоже не нужен. Температура эксплуатации консьюмерская, время работы сколько получится. У вас в наличии в компании такие специалисты, как: конструктор механики, схемотехник, тополог, программист, снабженец, монтажник.

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

Вас принять в скрам команду? ))

[Карлсон 3]

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

Вас принять в скрам команду? ))

Мне действительно интересно, как, на примере такой простой задачи, можно организовать процесс разработки, пользуясь эджаил методиками. Вот, например, как вы разобьете задачу создания ЭПС? Просто будет висеть одна задача на две недели, типа "разработать ЭПС устройства"? Меня именно организационный вопрос интересует. Вы же пишете, что внедрили у себя скрам при разработке железа. Хотелось бы услышать подробнее, как это происходит в правильном месте.

[mplata 8]

2 hours ago, kpv said:

и тут приходит заказчик и говорит: нужен ещё младенец 🙂

 

 

Ну если заказчик платит, то почему нет. ))) а если серьезно, то если транслировать Ваш вариант в железо, то это все почти с нуля. К реальной жизни это имеет слабое отношение. 

А вот в процессе НИР и НИОКР может возникнуть ситуация, где нужно менять что-то и вот тут то как раз гибкость очень нужна. Об этом я и говорю. 

[тау 29]

я против скрамов в разработке. Поучаствовал еще лет 10 назад. Пустая трата времени , имхо. 

[gin 0]

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

А если посмотреть назад в историю, то Туполеву не нужны были аджайлы при работе над ТУ-4. Курчатов не пользовался скрамом при разработке своей РДС-1 (а эти изделия были уж точно посложнее очередного сайтика в Интернете). Причем свои задачи они успешно выполнили в достаточно сжатые сроки. Просто они сами инженерами были, потому и другими инженерами руководить могли. На одном языке с ними говорили. Так что и нам надо брать с них пример.

 

P.S. Это конечно же всё моё сугубо личное мнение, на истину в последней инстанции не претендующее.