[dxp 52]

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

[mplata 8]

4 hours ago, dxp said:

 А кузов, двигатель, трансмиссию -- это всё на старте надо предусмотреть. И никак это ТЗ на мелкие задачи не разбивается. 

Почему не разбивается? Очень даже разбивается. И скрамить можно легко. Даже внедрение дизеля на авто бензиновый. Только задач будет больше чем при добавлении свистелок и начать придется не с почти готового авто как в случае покраски, а с более раннего этапа. 

Пока действительно против те, кому придется реально работать. Хочется сесть и разрабатывать что-то долго чтобы никто не отвлекал и в таком инкубаторе провести как можно больше времени. А потом когда придет время сдавать проект не сдать его в срок или сделать все не так. Зато спокойно и никто не мешает. 

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

[one_eight_seven 6]

6 minutes ago, mplata said:

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

Протокол разногласий придумали задолго до дебильной терминологии, и задолго до того, как waterfall, не имеющий ничего общего с имеющимися практиками и стандартами разработки на второй страничке той самой книги.
И, конечно же - до того, как влажные фантазии начали с ним сравнивать

[mplata 8]

15 hours ago, Yuri7751 said:

Ну и? А тут работающая система! Все шуршат, генерятся отчёты со страшной силой, совещания, графики... И, что замечательно, есть мальчики для битья, которых можно возить мордой по столу без риска сорвать проект - те же скрам-мастера или как их там. Лепота! Если б я был директором, непременно какую-нибудь такую херню внедрил

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

9 minutes ago, one_eight_seven said:

Протокол разногласий придумали задолго до дебильной терминологии, и задолго до того, как waterfall, не имеющий ничего общего с имеющимися практиками и стандартами разработки на второй страничке той самой книги.
И, конечно же - до того, как влажные фантазии начали с ним сравнивать

Протокол разногласий не противоречит скраму. 

[one_eight_seven 6]

12 minutes ago, mplata said:

Протокол разногласий не противоречит скраму.

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

Изменено 28 мая пользователем one_eight_seven

[Карлсон 3]

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

 почему не удалось то или иное, где тебе помогают решить твой же вопрос.

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

Я вам привел пример реальной задачи в вакууме. Кто у вас будет решать вопрос схемотехника или программиста, если их больше нет в команде других? Скрам-мамстер?

 

Какой блок работ можно брать, например, если у вас изначально стоит задача разработать ЭПС устройства? Или вы будете схему на мельчайшие субблоки бить? Работа ради работы? 🙂

 

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

[kpv 7]

12 hours ago, mplata said:

Пока действительно против те, кому придется реально работать.

 

12 hours ago, mplata said:

пусть заказчик просит сделать ПИД регулятор температуры (четкое ТЗ, сроки). Сделали и даже прекрасно работает!

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

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

[mplata 8]

3 minutes ago, kpv said:

 

Если у разработчиков всё хорошо, и они всё сделали и это даже прекрасно работает. 

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

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

[gin 0]

В 27.05.2024 в 14:43, mplata сказал:

Без ТЗ, как мой коллега выше сказал, результат хз. Это основной документ. 

Ваше ТЗ - это документ? С номером и датой, с подписями исполнителя и заказчика? С подписью утверждающего?

Как ваше ТЗ при работе по скраму выглядит? Можете здесь пример вашего ТЗ привести, хотя бы шаблон?

[kpv 7]

1 hour ago, mplata said:

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

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

хотите модных слов: для железа это водопад или канбан https://vc.ru/dev/328819-scrum-kanban-waterfall-kak-vybrat-metodologiyu-upravleniya-proektami

практически всё по полочкам разложено здесь https://habr.com/ru/articles/319370/

для ПО скрам отлично подходит, множество удобных и готовых инструментов для двиганья мышкой

14 hours ago, mplata said:

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

 

Жизненный цикл разработки ПП

1. Подбор элементной базы (какие компоненты будут закладываться). Анализируем цены, доступность и сроки поставки. Подбор выполняется в динамическом режиме вместе с созданием схемы. Выбор элементной базы проводится на основе схемы электрической принципиальной с учетом изложенных в ТЗ условий и требований

2 hours ago, mplata said:

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

Вы пытаетесь из скрам-мастера вырастить руководителя разработки 🙂

[gin 0]

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

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

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

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

[kpv 7]

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

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

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

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

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

[Maksim_2444 11]

20 часов назад, dxp сказал:

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

Это мы видим на примере "Буханки", Камаза и других подобных проектов...

 

те, кто думает иначе - почему-то могут по другому.

 

например  Opel Astra H - линейка ДВС и КПП менялась на всем протяжении выпуска авто, комплектация авто так же постоянно дополнялась и расширялась (ESP отсутствовало в ранних версиях). Они даже кузовные элементы вроде внедряли новые.

подобные примеры можно увидеть у большинства контор, которые внедрили систему управления разработкой 

 

кстати, с Opel прекрасный пример.

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

 И второй вопрос: как по другому провести синхронизацию отделов разработки из 10-30 разных стран?

Изменено 29 мая пользователем Maksim_2444

[kpv 7]

33 minutes ago, Maksim_2444 said:

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

она как бы у всех есть, или хотя бы должна быть 🙂

33 minutes ago, Maksim_2444 said:

комплектация авто так же постоянно дополнялась и расширялась  (ESP отсутствовало в ранних версиях)

вместо блока ABS устанавливается блок ABS/ESP 🙂

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

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

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

 

[Maksim_2444 11]

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

она как бы у всех есть, или хотя бы должна быть 🙂

вместо блока ABS устанавливается блок ABS/ESP 🙂

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

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

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

 

Вы не внимательно читаете:  линейка ДВС и КПП менялась на всем протяжении выпуска авто

 

Хотя я не указал напрямую, что появлялись новые версии, не заложенные ранее. имелось ввиду это

6 минут назад, kpv сказал:

она как бы у всех есть, или хотя бы должна быть 🙂

вместо блока ABS устанавливается блок ABS/ESP 🙂

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

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

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

 

По поводу ABS/ESP вы ошибаетесь, т.к. не сталкивались:

 

Для доработки первых версий авто до ESP требуется: замена блока ABS, замена блока приборной панели, замена под рулевого блока,  доукомплектация авто блоком датчика  ESP и проводкой к нему. Позднее, после внедрения ESP в авто, проводка прокладывалась общая для блока ABS и блока ABS/ESP, при этом все остальное комплектовалось в зависимости от заказа: либо чистый блок ABS и другие блоки без поддержки ESP, либо все с поддержкой ESP.

 

Такой выбор комплектации возможен только при системах, подобных СКРАМу.

Изменено 29 мая пользователем Maksim_2444