dxp
-
Постов
4 548 -
Зарегистрирован
-
Посещение
-
Победитель дней
14
Сообщения, опубликованные dxp
-
-
1 час назад, mplata сказал:
Поверьте, ИТ компании умеют считать деньги.
Мне довелось поработать в такой. Весьма успешной (в плане денег). Видел изнутри. Куча пустых, ненужных и вредных вещей, начиная от опенспейсов и заканчивая скрамами. Да, я помню, вы объясняли, что просто там неправильный скрам и неправильные скрам-мастера (правда, не рассказали, какие скрам-мастера правильные, хотя я попросил об этом). Ну дак вот, в этой конкретной конторе неправильный скрам, это выражается, в частности, в потере массы времени на пустые митинги, на отсутствие внятной линии в разработке (зато имитация на уровне), словом, это никак нельзя признать эффективным. И вы думаете, что контора обанкротилась? Отнюдь -- на волне импортозамещения (там тематика инфобез), когда зарубежных игроков все выкинули (и это правильно), тут образовалась монополия, и бабло полилось вообще водопадом. Деньги там считать умеют -- прибыль в основном. Потери от неэффективной организации работы там никто не считает. Просто потому, что не считает это неэффективным. Даннинг-Крюгер в чистом виде.
1 час назад, mplata сказал:И если что то их съедает это удаляют молниеносно.
Это фантазии. Там бабла столько, что потери не сказываются не то, что фатально, но даже болезненно. IT сфера перекормлена баблом чрезмерно (и, имхо, совершенно незаслуженно). Поэтому неэффективность управления там купируется деньгами, возможностью высасывать людские ресурсы. Бабло -- главный ресурс IT! Сделай там уровень таким же как в других инженерных областях, проблема с кадрами встанет очень остро. Вот тогда там начнут задумываться об неэффективности и повыкидывают скрамы нафиг.
-
3 часа назад, Maksim_2444 сказал:
Такой выбор комплектации возможен только при системах, подобных СКРАМу.
На чём основано это утверждение? С таким же успехом можно утверждать ровно обратное. Вам пример предложили, попросили рассказать, как скрам зарулит тему. Но в ответ какие-то отговорки и офтопик.
-
3 часа назад, Ascetic сказал:
Так китайцы так и сделали - при отключении всех предупреждений, как я показал в посте, все важные, с точки зрения трассировщика, предупреждения будут выводиться вне зависимости от параметра "Show All Warning".
Некоторые важные с точки зрения трассировщика могут оказаться не важными на самом деле, и их достаточно будет принять к сведению -- и скрыть. Если инструмент этого не позволяет, придётся это делать руками.
-
Прекрасный пример. На деле будет так: если на этапе проектирования кузова не предусмотрели установки дизельного двигателя (который более тяжёлый, имеет другие точки крепления, требует совсем другой трансмиссии и т.п.), то ничего с этой затеей не получится. Такие вещи должны сразу закладываться на этапе проектирования ТЗ. И ничего там в ТЗ, когда процесс пошёл, уже радикально не поменяешь -- только цвет да всякие свистелки-перделки. Вот их можно скрамить. А кузов, двигатель, трансмиссию -- это всё на старте надо предусмотреть. И никак это ТЗ на мелкие задачи не разбивается.
-
6 часов назад, StewartLittle сказал:
То есть, другими словами: принять предупреждения к сведению - это не то же самое, что игнорировать предупреждения.
А принятые к сведению засапрессить, чтобы не загромождали вывод и не маскировали другие сообщения (предупреждения). Когда в выхлопе болтается три сотни предупреждений, которые просмотрены и приняты к сведению, увидеть новое, возможно, важное, может оказаться затруднительно. Хорошо, если инструмент позволяет это делать. Иначе приходится самостоятельно наворачивать постпроцессинг лога.
-
1
-
-
В 24.05.2024 в 15:25, mplata сказал:
Согласитесь, что скрам и некомпетентность руководства это независимые сущности.
На данный момент не могу согласиться, ибо первое является следствием второго. Где руководство умеет эффективно рулить, там никаких скрамов нет и не надо.
В 24.05.2024 в 15:25, mplata сказал:Скрам будет работать если руководитель адекватен или не работает если нет.
А зачем эта сущность (скрам) вообще нужна, если руководитель адекватен? Нам-то поют,что скрам сам по себе прекрасен и неимоверно могуч, т.ч. делает хорошо независимо от руководителей.
В 24.05.2024 в 15:25, mplata сказал:Нормальных скрам-мастеров почти нет.
В 24.05.2024 в 15:25, mplata сказал:Возможно скрам-мастер это ключевое
Расскажите, пожалуйста, поподробнее про скрам-мастеров? Что это за роль (по-вашему)?
Что значит "нормальных нет"? А какие они -- нормальные?
Как скрам-мастер, который, напомню, вообще даже не специалист в предметной области, который не командир (не руководитель) в команде, который по сути никакой власти не имеет и несёт функции организации
построениймитингов и логирования их результатов, может как-то влиять на эффективность процесса разработки?Из ваших слов получается, что всё упирается в скрам-мастеров, де, от них всё зависит. Я согласен с тем, что зависит от людей, но только если эти люди -- руководители процессов и исполнители. В первую очередь зависит от руководителей, во вторую от исполнителей. Где тут скрам-мастер, мне не понятно. Раскройте, пожалуйста, ваше понимание этой темы?
-
1
-
-
47 минут назад, Turgenev сказал:
- можно ли использовать конденсаторы рассчитанные на 100 Вольт при 104 Вольтах, чем это чревато и описывается ли это где-то производителем?
А они там прямо на эти 104 В стоят? Или может там их пара последовательно с выравниванием потенциалов?
-
2 часа назад, НЕХ сказал:
Просто при подаче питания не нажимаю кнопку включения сразу. Что-то грузится в дежурном режиме...
В смысле, при включении вилки в розетку? Так я из розетки вообще не выдёргиваю штепсель. Включаю и выключаю только кнопкой на передней панели.
-
Проапгрейдил до последней версии. Буду наблюдать.
4 минуты назад, khach сказал:т.е GUI андроидовский запустился полностью? Проверить по логам андроида. Тогда или ZYNQ не прогрузился или завис или тактовый генератор АЦП не стартует. Смотреть логи ZYNQ на его RS232 порте. Это к сожалению с разборкой связано осцилла, т.к иначе не добраться. Да и плохо документировано в сети- можно найти только пару кусочков логов удачной загрузки.
Не, вскрывать новый апломбированный дивайс не готов.
-
Вопрос такой: есть DHO4804, исправно работает кроме одного момента: при включении питания иногда нет "лучей" сигналов. И никакими действиями их добыть не получается. Только ребутом. Такое бывает не каждый раз, примерно в половите случаев. Не фатально, но изрядно анноит. Кто-нибудь сталкивался с подобным? Есть идеи, куда ковырять? Гуглением ничего не нашёл.
-
10 часов назад, mplata сказал:
собственно это было основным (разговор ради разговора это главная ошибка неопытных или самолюбивых управленцев, которые управленцы ради управления). Все остальное уже косвенно говорит о том, что Вы сталкивались с непрофессиональным менеджментом.
Конечно -- некомпетентность руководства в вопросах управления ко всему этому и приводит. В первую очередь -- к внедрению скрама. Потому как если бы руководство было управленчески состоятельно, оно бы выстроило эффективную иерархию управления, найдя, отобрав, поставив на ключевые позиции правильных людей, которые отрабатывают задачи на своём уровне иерархии так, как надо. Поскольку оно этого не смогло, а понимание, что как-то управлять надо, то тут привлекательно выглядит готовая методология. И скрам тут представлен лучше и ярче всех остальных -- реклама, продвижение: на этом немало народу кормится.
Скрам-мастера. Это зачем они вообще нужны? Это люди, которые не обязаны быть специалистами в целевой тематике разработки, их задача -- организовывать процесс: проводить дейлики, планирования, ретры. Т.е. это по сути секретарь-стенографист на заседаниях.
Дейлики. Зачем они нужны? Зачем обязательно собираться каждый день? Собираться надо по делу -- on demand. Надо если, то хоть три раза за день можно собраться, а не надо, так и неделями можно этим не страдать. Какие-то локальные вопросы люди, работающие совместно над задачей, решают оперативно сами на своём уровне, не отвлекая остальных. Более глобальные вопросы курирует руководитель работы, и если надо, собирает людей -- не всех, а только тех, кто нужен с его точки зрения -- на совещание/планёрку. Когда люди собираются по делу -- для решения возникшего вопроса, это собрание полезное и живое. А когда они собираются, потому что так положено по распорядку -- ну, скрам требует проводить ежедневное собрание (дейлик) -- то это превращается в профанацию, потерю времени и снижение мотивации.
Продукт овнер. Он кто? Руководитель работы? Нет! Это типа заказчик или внутренний представитель заказчика. Он озвучивает (ставит) задачи -- в бэклог, а команда выбирает из бэклога те, что считает нужными делать в первую очередь. Команда решает! Да, команда, конечно, лучше знает, что надо делать в первую очередь. Вот прикольно было бы посмотреть, если на корабле команда бы решала, куда плыть, а не капитан.
При этом продукт овнер -- не командир над командой (как заказчик не командир над разработчиками), поэтому прямого непосредственного влияния он не имеет. Он не может поручить конкретному человеку делать то или иное, он не может снять исполнителя с задачи и поручить её другому. Это понижает и без того ущербную управляемость.
Все эти проблемы решены при правильно выстроенной иерархии управления.
Скрам-мастераСекретари там не нужны. Митинги проводятся по необходимости и целевым образом. Вместо продукт овнера там руководитель (группы, работы и т.п.), который персонально отвечает перед вышестоящими уровнями иерархии за результат и облечён властью (т.е. реализуемой на практике способностью управлять) на своём уровне. Он организовывает рабочий процесс, следит за ходом его выполнения, оперативно реагирует на вводные. Всё это даёт реальную эффективность, а не мнимую, как в случае скрама. Потому что у ошибок и успехов есть имя, фамилия и отчество, сиречь, настоящая персональная ответственность, а не мнимая коллективная.И дело не в SCRUM vs Waterfall, а в грамотно выстроенной иерархии управления! Такая иерархия зарулит любой скрам по эффективности на раз. Главная проблема с ней состоит в том, что выстроить её сложно: это требует от управленца ума, опыта (жизненного и управленческого), множества хороших человеческих качеств (таких как настоящая (а не показная) уважительность к людям, мудрость, доброта, строгость-требовательность, дальновидность и справедливость) и умение разбираться в людях. Это редкие умения и это дано далеко не каждому. Такой человек -- это куда более ценный кадр, чем даже очень квалифицированный специалист в предметной области.
К сожалению, большинство менеджеров не таковы. И из них ещё изрядный процент тщеславных мудаков, для которых на первом месте стоят личная слава и доходы, а не интересы дела. Такие "управленцы" (а их много -- они активно лезут наверх, к власти, которая для них кормушка и "тёплое место") в принципе не способны эффективно работать в иерархии управления, т.к. они будут решать в первую очередь свои личные карьерные задачи, а не отдаваться интересам дела.
Выстраивать иерархию управления должен самый главный босс в организации -- это его прямая и нативная обязанность. От неё зависит вообще всё. Если он этого не может, то и этой системы управления тоже нет. Но управлять-то как-то надо. Вот и хватаются за готовые методологии. Но вместо реального управления там иллюзия оного.
В мире софта это как-то едет, т.к. там процессы такие, что многие ошибки сглаживаются (и качество результата оценить сложно (например, если штукатур плохо сделал работу, это сразу видно по кривой стене, но по софту этого сразу не увидишь -- это надо поработать с ним, а т.к. его постоянно правят, то не понятно, какое его состояние надо оценивать), и исправлять ошибки дёшево -- почти бесплатно в том смысле, что не требуется ни затрат материалов, ни значительных временнЫх затрат, нет проблем с логистикой (отзывать бракованную продукцию и заменять её на исправленную) и т.п.
В заключение можно отметить, что история знает немало примеров эффективного управления сложными проектами задолго до появления скрамов. Авиация, судостроение, космос, атомная отрасль. И на Западе, и в СССР. И качество процесса определялось исключительно компетентностью кадров. Так было, так есть и сейчас. И так будет и дальше, ибо природа человека не меняется.
-
2
-
1
-
-
Только ценник на них ого-го. И в прежние-то времена оно под полтинник тянуло, а сейчас 100+ тыр. Готовы ради двух десятков контактов за это платить? Имхо, два десятка проще и дешевле купить обжатыми. А этот инструмент приобретать только если операции обжима требуются постоянно (периодически).
-
8 часов назад, djhall сказал:
Как расчитать set_input_delay?
Тут ничего рассчитывать не нужно, нужно просто задать задержку, вносимую внешними цепями в пути данных. set_input_delay как бы говорит анализатору (STA), что, мол, там снаружи сигнал ещё задерживается на столько-то, поэтому у тебя вот бюджет таймингов уменьшается на эту величину. Например, если снаружи нет ничего, кроме проводников на плате, и их длина такая, что задержкой в них можно пренебречь, то следует указать значение ноль. Если есть какие-то ощутимые задержки, то их и указать. Особенно это касается случаев, когда данные, например, проходят через какой-то буфер, который вносит пару нс, причём, там ещё и разброс значений присутствует -- тогда для max и min будут разные значения.
-
Если речь про инструментарий, то Jira+Confluence+Gitlab.
-
1 час назад, mplata сказал:
Скрам вполне себе система.
Нет, скрам -- это методология ведения работы. А система следующий, более низкий уровень иерархии, система управления строится на основе методологии. Что не делает методологию системой.
1 час назад, mplata сказал:Вики также со мной согласна, и прекрасно работает далеко не только в программировании.
Конечно. Логистика, закупки, отлаженные производственные процессы -- да. Где всё более-менее предсказуемо и поддаётся адекватному прогнозированию. Но не в разработке нового.
1 час назад, mplata сказал:1. Не даёт лодырничать
Серьёзно? 🙂 Ещё как даёт -- просто методы лодыри применяют другие. Например ИБД (имитация бурной деятельности). А в совокупности к хорошо подвешенным языком бездельник вообще может казаться самым деятельным -- скрам предоставляет как раз возможность демонстрировать (дейлики и прочие регулярные митинги).
Не даёт лодырничать никакой не скрам. Вообще, никакая методология или система управления не решает сама по себе эту задачу. Её решает конкретный человек -- руководитель. Если он на своём месте, он прекрасно видит, кто что стоит, кто чем занимается, где есть толк, а где пустота (имитация). Потому что принцип "Кадры решают всё!" применим не только к исполнителям, но и (в первую очередь!) к руководителям.
Управление -- живой процесс. И всё зависит от квалификации, умений, опыта и адекватности человека, который осуществляет это управление. Никаких других вариантов нет. Полагать, что скрам что-то там кому-то не даёт или наоборот обеспечивает результат -- есть вредная иллюзия.
Далее по пунктам.
1 час назад, mplata сказал:2. Повышает вовлечённость всей группы в проект
Ещё одна иллюзия. То, что скрам-методология предполагает ежедневные митинги наряду с планированием спринтов и ретрами, никакой вовлечённости не повышает и не обеспечивает: сидят люди на митинге, слушают бубнение очередного выступающего, ждут своей очереди отчитаться и того, когда это бесполезное и бессмысленное мероприятие закончится. Только и всего. Много раз лично участвовал в этих митингах и наблюдал оную картину.
Вовлечённость в проект может поднять тот же самый человек, который руководит процессом, применяя три рычага (это известная тема из психологии):
- поднять интерес подчинённого сотрудника-коллеги, правильно выбирая для него задачи -- далеко не все задачи интересны всем, поэтому тут надо внимательно и чутко подходить. Будет интерес -- будет результат. Интерес -- это самый главный мотиватор;
- помочь с пониманием трудных моментов (сам или привлекая других, более квалифицированных в вопросе людей). Когда человек имеет хорошее понимание того, что он делает, это тоже прилично мотивирует (повышает вовлечённость), позволяет работать эффективнее, что поощряет исполнителя, который видит позитивный результат своей работы;
- довести важность дела до сотрудника-коллеги: нужность результата, ответственность перед заказчиком, уважение товарищей и т.п.
Всё это -- живая работа с людьми. Только она и даёт результат. А пустая говорильня на дейликах -- просто трата времени и сил.
2 часа назад, mplata сказал:3. Позволяет быстро адаптироваться к новым реалиам или дополнениям.
За счёт чего? Что такого уникального даёт скрам для этого? Что собрались и поговорили? Ну, собрались и поговорили. Наговорились, устали, ничего не решили -- это сколько угодно. Даже более того -- это обычный результат, когда толпа пытается что-то решить. "Лебедь, рак и щука". И эта говорильня продолжается из раза в раз без всякого результата.
Решение менять курс (адаптироваться) должен принимать тот, кто отвечает за результат. Его ответственность, его и решение. Как правило, это тот же самый руководитель работы. Он может собрать людей, спросить их экспертное мнение, выслушать каждого, и на основании этого, а также своего опыта и знания своих людей (к чьему мнению в какой ситуации нужно прислушиваться больше, а чьё умножать на 0.1) принять решение, за результат которого ему потом отвечать. Никакие общие собрания и пустопорожная болтовня на них не нужны.
2 часа назад, mplata сказал:4. Соблюдение сроков и ощущение ответственности каждого
Соблюдение сроков обеспечивается грамотным разбиением работы на этапы и контролем выполнения работы по этим этапам. А коллективная ответственность -- это миф! За исключением крайних случаев: типа, все мегасознательные и ответственные как главный герой из советского фильма "Коммунист", или когда в случае неуспеха всех расстреляют (лишат премии, уволят и т.п.). Во всех других случаях коллективная ответственность проявляет себя как коллективная безответственность. Всегда в группе (статистически) находятся раздолбаи, тормоза, рукожопы, эгоисты-индивидуалисты и т.п. И без присмотра и персональной ответственности всё это приводит к тому, что результат провальный, с спросить не с кого.
Итого, опять всё сводится к компетенции и квалификации управляющего процессом конкретного человека.
2 часа назад, mplata сказал:5. Вся группа видит результат, даже если конкретный исполнитель выполнял только небольшую часть проекта.
Работает только в случае простых задач. Проходили не раз. Когда задачи сложные, требующие серьёзного вникания, всё это не работает от слова совсем.
Пример из реальности: пилим командой ПЛИСовый проект, я занимаюсь PCIe DMA (на TLP), а коллега -- поиск паттернов в потоке сетевого трафика. У нас задачи не пересекаются вообще никак! И каждая из них требует глубокого погружения. В итоге, все скучают, когда я что-то бубню запросы чтения памяти хоста, проблемы негарантированного порядка прихода CplD от разных запросов, про кредиты non-posted запросов и подобное, а когда коллега говорит про свою работу, я из его рассказов понимаю только, что у него там какие-то блум-фильтры, перфектные таблицы кукбука и ещё какая-то хрень, названия которой я не запомнил. Чтобы мне понимать, о чём он говорит, мне нужно серьёзно погружаться в тематику его работы, но я не могу этого делать -- у меня своей выше крыши. И у него ровно та же ситуация. И у всех в группе. Получается, что все сидят и тупо ждут, чтобы отчитаться, и когда это пустое мероприятие закончится. Скрам-мастер не понимает вообще ничего из того, что там говорят, т.к. он не специалист ни в ПЛИС, ни в тематике проекта. Ну, по скраму он и не должен. Его задача -- быть секретарём заседания.
И вот в итоге проектом занимается 8 человек, но задачи у всех перпендикулярные, какие-то общие места есть только на стыковках, а это очень небольшая часть проекта. В итоге, на общие темы мы можем поговорить только про какое-нить CDC FIFO, проблемы с STA, нюансами использования общего инструментария (симулятор, синтезатор и т.п.) и другими общими вопросами, которые к непосредственно проекту имеют опосредованное отношение.
Итого, эффективно задачи решаются при правильно организованной иерархии управления, когда все люди -- и специалисты, и руководители (от крупных до тимлидов) на своих местах. Иерархия -- это естественный способ решения сложности в человеческой коллективной деятельности.. Да, тут важно не скатиться в раздувание иерархии на пустом месте, не допустить возникновения и роста бюрократии и формализации. Поддерживать процесс живым -- это достигается только правильным подбором кадров и никак иначе.
Скрам же тут не помогает совсем никак. А мешает изрядно. Он размывает ответственность, распыляет цели, место чётко выверенного курса получается "рыскание". На локальном уровне хорошо работает самоорганизация, когда подбираются (или подбирают) люди ответственные, мотивированные, знающие и умеющие -- она сами между собой наладят и взаимодействие, и рабочий процесс. Но это происходит самодвижущимся образом у них без всяких скрамов. Скрам и тут только мешает, пытаясь формализовать этот естественно сложившийся процесс.
2 часа назад, mplata сказал:Вы ведь понимаете, что в процессе разработки можно столкнуться с чем-то неоптимальным и без переделок будет плохо совсем. Разработка как таковая это далеко не всегда разжеванное ТЗ, бывает есть только идея и общие представления. То есть работа над тем что никто не делал никогда, и включается этап НИРа. Если же ТЗ абсолютно однозначно и детально, то в этом случае скрам будет играть организационную роль.
Когда задача совсем новая и непонятная, то, конечно, никакого внятного ТЗ быть не может. Поэтому ведётся предварительная работа -- например, как вы правильно назвали, выполняется НИР. А потом при выполнении ОКР ещё эскизный проект (ЭП), на входе которого присутствует проект ТЗ, и цель ЭП -- создать технический облик объекта разработки и разработать уже нормальное ТЗ, с которым можно смело идти в технический проект (ТП), коий уже и есть собственно разработка.
Где тут рулящая роль скрама? Да без него это сто лет делалось и делается. Он сюда вообще не вписывается. Что же касается корректировки ТЗ по ходу дела, то и это возможно, но не так огульно как это делается со скрамом. Если заказчик предлагает (просит) что-то поменять, это рассматривается, и если принимается, то выпускается специальные документ: дополнение к ТЗ. Все эти доп. хотелки отражаются там. И всегда видно, что было исходно, а что изменилось по ходу дела. Отдельный документ позволяет хорошо видеть, сколько чего, когда и как изменилось. И это позволяет эффективно пресекать излишнюю тягу заказчика к фантазиям .
При разработке софта эти изменения реализуются ещё как-то более-менее безболезненно. При разработке железа -- это как правило боль, и часто оказывается неприемлемым. Иначе разработка затягивается на годы. Это проблема, когда софтовая контора берётся делать железо: тематика и средства радикально другие, а подходы те же самые. Я работал в софтовой IT комании, которая взялась разрабатывать железо (для себя, для своего продукта), в итоге 6 лет хардварному отделу, объём работы проделан колоссальный, сами разработки технически очень достойные (специалисты высокого уровня там трудятся -- контора может себе таких позволить), но в серии и у клиентов по истечении этого срока нет ни одного из полудюжины разрабатываемых изделий.
Это происходит именно по причине постоянных корректировок хотелок, отрицания ТЗ как такового, отсутствия этапности в работе, зато есть скрам во всей его красе с коллективной
ответственностьюбезответственностью и прочим. Да и странно предъявлять ответственность исполнителям, если от них тут мало что зависит -- каждый из них на своём месте свою работу сделал хорошо.Подводя итог
Скрам, возможно, неплохо себя проявляет при разработке, например, веб-приложений, когда результат работы можно сразу предъявить, и заказчик видит его, может попросить что-то поменять или откорректировать -- вот тут спринты, как контрольные точки, помогают. Но когда ведётся разработка материнской платы сервера (со 128-ядерным процессором и 16 планками DDR4), где работа схемотехника и конструктора ПП занимает по полгода, какие нафиг спринты?! То же самое и с ПЛИС: тот же PCIe DMA я пилил несколько месяцев, и эта работа почти никак не пересекалась с другими -- она несмотря на известную сложность, является локальной, законченной в себе -- ни вводные никакие снаружи тут не нужны, ни результат показать в конце спринта невозможно (вряд ли кому будет интересно смотреть на очередной добавившийся тест того или иного модуля).
По итогу пристального наблюдения за этой темой и невольного участия в ней, для себя я сделал следующий вывод: скрам -- это вредная иллюзия управляемости процесса, которая проникла глубоко в сфере IT. Секрет успеха этого внедрения состоит из двух частей:
- Потребность руководства IT компаний в инструментах управления, которые оное руководство само создать не смогло, но тут ему предложили готовое "решение".
- Агрессивная реклама этой методологии со стороны консалтинговых агентств и лавок вроде AgileLab, желающих рубить немалые деньги на некомпетентности, доверчивости и легковерности руководителей IT контор. Ну, почему руководители контор ведутся на это -- это Даннинг-Крюгер в полный рост: уровень управленческой компетентности не позволяет ни организовать процесс эффективно, ни понять, что предлагаемое тоже не решение.
Процесс разработки и продвижения софта сам по себе прощает многие косяки -- цена ошибки невелика, стоимость производства ноль, сроки производства -- тоже почти нулевые (сколько на пересборку требуется), возможность отлаживаться на клиентах и т.п. Всего этого нет в теме разработки железа, там всё эти ошибки стоят дорого. Поэтому там этот подход не работает совсем.
Если в какой-то конторе ввели Scrum, это по факту и по сути является ничем иным как росписью руководства этой конторы в собственной управленческой несостоятельности. Не больше, не меньше.
-
5
-
1
-
"Огласите весь список, пожалуйста" ©
Что вы понимаете под "системами управления проектами в электронике"? Какие знаете? Если что, то SCRUM -- это не система управления проектами вообще и уж точно не в электронике.
Система управления проектами -- это, например, Redmine. Альтернативная связка Jira+Confluence. Хотя я бы не назвал это именно "системой" управления, это просто багтрекер + вики.
-
Ну, надо всё же чтобы прогон подольше был, а то тут уже начинает влияет время загрузки тулов. Вивада сама по себе тормозная, она запускается долго. За это время Gowin уже успеет всё собрать и закончить. 🙂
Надо подобрать так, чтобы время сборки занимало хотя бы минут 5.
-
6 часов назад, pavlovconst сказал:
Если интересно, присылайте результаты прогона на вашем железе 🙂
Прогон для Vivado 2023.1.2:
Конфигурация PC: AMD Ryzen 9 7900X, DDR5 2x32GB (на частоте 5200 МГц), MB на чипсете B650, NMVe (1000 ГБ SSD M.2 Samsung 970 EVO Plus).
Время что-то очень коротким вышло -- либо проект простой (для современного железа), либо, может, сделал что-то не так. Но просто открыл проект вивадой, она предложила конвертнуть в нынешний формат, я согласился. Дальше пнул сборку и всё.
-
40 минут назад, mplata сказал:
В Вашем примере вполне возможен такой результат: сделали ТЗ, начали работу, через месяц проверяем что сделано и оказывается что сделано не совсем то или вообще ничего.
Это что за ТЗ такое, когда через месяц оказалось, что оно не про то? ТЗ -- серьёзный документ, от него зависит результат чуть не на все 100%. ТЗ -- это отправная точка в разработке. Из него формируются этапы работы. Если через месяц выясняется, что ТЗ не про то, что надо, разработчика ТЗ (или того, кто ему задачу ставил) гнать за профнепригодность.
40 минут назад, mplata сказал:А так как часто заказчик по ходу разработки меняет или дополняет что то то через этот самый месяц получается катастрофа.
Меняет и дополняет по ходу дела?!!! Серьёзно?! Вот это и корень проблем при использовании IT'шных подходов в разработке железа! Это в софте можно быстро перех..якать, с железом это не прокатывает. Да и с софтом эта практика порочна и является источником массы проблем, просто там последствия ощущаются не так больно. Вместо того, чтобы сразу подумать и спланировать процесс, там доминирует метод "х.як, х..як и в продакшн". Единственный сценарий, где такое оправдано -- это когда задача (что нужно конкретно сделать) недостаточно ясна на старте, и пока не начнёшь, невозможно понять, как конкретно это надо сделать. Поэтому применяется этот метод "тыка" -- сделали что-то, увидели, то или не то. Тут, конечно, нужно всем участвовать -- и заказчику, и разработчику, и периодичность этих контрольных точек должна быть достаточно короткой (1-4 недели) -- те самые спринты. Это как-то работает при разработке софта, но с железом это полный провал. Там нужно всё заранее тщательно проектировать и планировать, потому что перефигачить по ходу дела не получится, т.к. стоимость производства в отличие от софта далеко не ноль.
40 минут назад, mplata сказал:Этого не происходит в скраме, более того все участники знают что происходит на других направлениях
Что знают? Что мешает это знать без скрама? А нужно ли всем участникам это знать? Не будет ли это "знание" отвлекать их от своей конкретной и сложной работы?
40 минут назад, mplata сказал:когда поступают комплектующие
Это нужно знать всем участникам команды? Зачем? Об этом нужно знать тем, кто к этому причастен. Это узнаётся адресно без всяких скрамов. При правильной организации работы есть её руководитель, который всё аспекты курирует (или назначает ответственных, если задач много).
40 минут назад, mplata сказал:когда можно приступать к выпуску КД
И для этого скрам нужен? А как же без него-то обходились десятки лет и продолжают обходиться? Когда приступать к выпуску КД -- очевидно на этапе РКД.
40 минут назад, mplata сказал:когда нужно отдать корпус в покраску.
Ну да, тут никак не обойтись без планирования спринта, дейликов, ретры. Ведь все разработчики должны быть в курсе, когда же надо отдать корпус в покраску. И уж стопроцентно это должны знать скрам-мастер и продукт овнер.
40 минут назад, mplata сказал:все прозрачно и без нервов
Ну, если потеря кучи времени и отвлечение на посторонние процессы, зачастую искусственные и бесполезные, как натягивание работы на сторипоинты, никого не расстраивает, то пожалуй поверю. 🙂
40 минут назад, mplata сказал:А главное в начале стринта нет необходимости каждому перегружать себя, вешаешь на себя посильную ношу.
Ну, о чём и речь -- годится только для простых и понятных задач, которые ясно, как делать, можно достоверно спрогнозировать трудозатраты и т.п. Словом -- не про разработку. Логистика, снабжение, какие-то уже более-менее отлаженные производственные процессы, когда есть опыт, на который можно опереться. В разработке нового такого опыта как правило нет, поэтому всё это скрам-планирование идёт лесом.
40 минут назад, mplata сказал:У нас это прижилось и работает просто великолепно.
Ну, удачи вам
-
2
-
1
-
-
17 часов назад, mplata сказал:
Работать нужно в СКРАМ системе управления проектами, спринтами по 2 недели
Прошу прощения за офтопик, но вот это вот зачем при разработке железа? Это же как-то годится только для очень простых процессов и при разработке вебсайтов, когда нужна постоянная обратная связь с заказчиком/потребителем -- "курс" работы на спринтах и корректируется. При разработке железа нужен свосем другой flow: ТЗ, ведомость исполнения (план-график, роадмап и т.п.), этапность. SCRUM тут вообще не ложится никак и является только помехой.
P.S. Если тема интересна и есть желающие обсудить/высказаться, то может имеет смысл создать отдельную тему.
-
А через JTAG подрубиться не пробовали? Там, вроде, есть режим, когда можно дебаг-сессию поднять, подключившись к уже загруженной в программе. Сам не пробовал такое.
-
-
Цель -- иметь сравнительную проверку РС железа, поэтому проект нужен один с конкретными настройками. Ровно так было с прошлым тестом. Вполне адекватно показывал производительность железа.
BRAM, DSP, PCIe, etc -- это ещё одна "координата": эти аппаратные блоки имеют жёсткое расположение внутри FPGA, что даёт новые вводные для инструментария. В реальных проектах всё это как правило есть, поэтому для адекватности теста такие элементы тоже нужны. И никакая кроссплатформенность тут не нужна.
Если хочется иметь тест, который можно собрать на любом тулчейне (Vivado, Quartus, PDS, Gowin и т.д.), то это должен быть совсем другой проект, и показывать он будет тоже нечто другое -- скорее производительность тулчейна, а не эффективность РС железа. Такой тест не должен иметь ничего, кроме логики и регистров. Ну, и на PnR всё равно будут проблемы с констрейнами по распределению пинов. Т.ч. по-любому придётся делать портирование. Моё мнение, такой тест достаточно бесполезен в отличие от предлагаемого варианта по тестированию производительности РС железа.
IP ядра -- это блоки, которые могут собираться параллельно, это даёт преимущество многоядерным процам, это хороший тест на эффективность работы с памятью и кэшами в одновременном многоядерном нагруженном доступе. IP ядер в проекте может быть немало (десятки), и их сборка (создание и синтез) занимают время обычно побольше, чем синтез самого проекта. И это хороший способ разгрузить синтез, т.к. IP ядра обычно собираются в OOC режиме.
-
Помнится, было дело тут на форуме: кто-то скидал простой, но затратный на сборке проект под Quartus (как бы не для Cyclone II), и все желающие могли собрать его на своём железе и выложить результаты -- была какая-то более-менее объективная оценка эффективности сборочной машины. Может тоже так же сделать: скидать проект под Vivado, например, на Artix7-200, и выложить, чтобы все желающие могли попробовать и доложить какие-то более-менее объективные результаты? Показать: конфигурация РС, время сборки в формате:
- IP ядра.
- Синтез.
- P&R.
- Общее время.
Вот только состав проекта надо подобрать, чтобы там не было перекосов, чтобы все компоненты равномерно задейстовались: комбинационная логика, флопы, блочная память, IP ядра (как минимум PLL, а ещё, может PCIe), DSP блоки (но без фанатизма). Может есть что-то готовое на примете?
Думается, такое было бы и интересно многим, и полезно.
-
2
Системы управления разработками в электронике
в Управление проектами
Опубликовано · Пожаловаться
А я не про это написал. Я возражал на ваш тезис, что, де, в IT компания умеют считать деньги, и был скрам неэффективен, его бы выкинули сразу. А это далеко не так.