Добрый день !
Хочется спросить совета у форумчан по одному вопросу, хотя не совсем уверен, что выбранная тема четко соотносится с ним.

Я — заказчик. Проект небольшой – ATmega168 + PCF7991, пара реле, пара ключей и десяток входных сигналов (логика). На выходе должен появится работающий образец в предфинальном варианте для запуска в серию + вся исходная информация.
Исполнителей двое, электронщик и программист. С каждым из них - своя история взаимодействия.

При отправке ПП на изготовление выяснилось, что все проводники на плате были сделаны не трассой а графикой (линии), которые естественно нормальному редактированию не поддавались. При увеличении была заметна небрежность — нахлесты, несведение в точку и т.п. Ну и апофеозом всего — невозможность автоматической проверки корректности дизайна платы в контексте правил разводки (DRC ). На мой вопрос «почему так» было сказано, что Altium в котором он работал с очень ограниченной лицензией и по другому никак ... Потратив несколько часов на обзор и вникание в имеющейся доступный софт, был сделан выбор в пользу DipTrace. Цена вопроса - 10 тыс.р (1000 выводов, 4 слоя). Плата была переделана в приемлемый срок и с надлежащим качеством. Пре передаче в Резонит выяснилось, что теперь формат DipTrace в качестве входного не принимается.
На мое указание транслировать проект в гербер и сверловку, электронщик заявляет, что это работа технолога и ничего в этом случае гарантировать не может.
Пришлось делать самому, заняло примерно пять минут с проверкой полученных герберов сторонним вьювером. Из Резонита все пришло как задумывалось и без вопросов.

Программист ... Тут сложнее — ломаный IAR. Попытка разговора в стиле «ай-яй-яй, а давай делать в Atmel Studio» (4.18 например) не привела ни к чему. Хотя изначально было сказано, что проект будет развиваться и необходим грамотный и качественный подход к проектированию и железа и софта. Ну Си он и в Африке Си, махнул на это рукой, запланировав по окончанию этой фазы переехать в студию за короткое время.
Наконец пришло время тестирования полученного образца. Детали описывать не стану. Выяснилось, что устройство при провалах питания ведет себя непредсказуемо, но чаще всего намертво «зависает». Посовещавшись пару дней и проводя какие-то эксперименты ими было заявлено, что это «плохие» микроконтроллеры ... - Не вопрос, - сказал я и приобрел с десяток ATmega168 из разных мест и партий. Снова испытания и проверки, но — безуспешно. На мой вопрос «а включен ли внутренный BOD?» было бодро ответили - «пробовали по всякому, ничего не помогает» и предложили - «а давайте на вход по питания поставим отсечку», чтобы ниже 8 вольт устройство просто отключалось.
Время поджимало — снова махнул рукой (зря) ... Прошло несколько дней на протяжении который электронщик как в старые добрые времена СЮТов взяв в руки паяльник плодил вариант за вариантом схему, приговаривая «вот уже почти ...»

Делать мне было нечего и я взялся чтение классики и истоков. Изучив варианты построения схемотехники UVLO (under voltage lock out) и внимательно почитав datasheet на микроконтроллер решил взять инициативу в свои руки ...
На моем рабочем столе помимо компьютера разместились : опытный образец, программатор, паяльная станция и лабораторный источник питания. Получив по запросу от программиста исходный код и прошивку (IAR я не устанавливал) взялся за тщательную проверку всего и вся. Собственно все заняло минут десять. За это время я убедился, что fuse bits прошиты мягко говоря странным образом. На вопрос «Это правильно?» был четкий ответ - «Да ! У нас так все устройства работают».
Пришлось распечатать нужные страницы даташита и попросить пояснить наглядно. Случился таймаут по окончании которого мне было выдано две разные версии с новыми комбинациями и «пояснениями» в стиле «а можно и вот так» ...
Я пригласил грамотного специалиста который мне шепотом сообщил, что ошибка на самом деле на генетическом уровне. Им же аргументировано объяснил, что все не так, как они себе представляли и нужно просто вдумчиво читать документацию, т.к. там все-все написано. Закончив объяснения он запрограммировал fuse bits как нужно. Устройство перестало себя вести неадекватно на что программист заявил, что он — программист а не железячник и эти конфигурационные биты не его проблемы. Электронщик в ответ показал пальцем на программиста ... Еще не занавес.
Напоследок я потратил пару часов на анализ исходного кода (лучше бы я это не делал).
Вновь не стану описывать увиденное. Сообщу только одну деталь (программная реализация SPI – это мелочи) — сбросов watchdog-а я насчитал целых 70 ! ...
На высказанное мое недоумение был ответ «Ну работает же!» ©
Занавес ...

А теперь собственно суть вопроса.

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

P.S. Спасибо за терпение, проявленное при прочтении текста выше

1). "Ну вы блин даёте!"

Без ТЗ и КП Вы не подпишете ни один договор на разработку ни с "госками", ни со сколько-нибудь серьёзными заказчиками.
А без хорошо проработанного ТЗ Вы рискуете уйти в хорошие минусы, так как мутные места в ТЗ всегда трактуются в пользу заказчика.

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

2). У Вас очень странное представление о Agile.

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

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

Я как представил разработку авианосца и всего его нутра за несколько коротких итераций.. Сразу повеселел.



На моей памяти (а это 40 лет работы в отрасли), все, что начиналось без ТЗ - заканчивалось провалом.

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

Однажды столкнулся с одним СТП - смотрите во вложении. Подобный документ можно прикрепить приложением к договору/ТЗ. Мне в этих требованиях самому не все нравится, вы их можете взять за основу для разработки своего документа.

Сообщение отредактировал Elsystems - Aug 23 2016, 04:45

Фееричная помесь стиля кодирования и запретов на очевидные ошибки. И так же очевидно не имеющая ничего общего с получением качественного кода. Вот например правильный документ на стиль исходников, к примеру : https://google.github.io/styleguide/cppguide.html Ну а по поводу отсутствия глупых ошибок спасет только уровень знаний и опыта. Если "програмизд" не осилил правильных книг, а только нахватался по верхам, от такого вредителя никакой документ не поможет.

Кмк качество кода извне может быть обеспечено только при промежуточном контроле. Т.е. должен использоваться общий репозиторий, и принимающему нужно просматривать изменения и обладать нужной квалификацией, что бы оперативно заворачивать на переписывание ересь. Повторюсь, никакими документами обеспечить качество кода без квалифицированного программиста на своей стороне невозможно. Единственное исключение изначально нанять этого качественного программиста на выполнение задачи, тогда за вас будет работать его внутренний самоконтроль.

ИМХО, но не верно ни то, ни другое.

Самое важное инструменты!

Ага, нажал на кнопку - получил результат

Непонятно еще что понимается под "качественным кодом". Может под этой фразой каждый свое понимает. Для меня - это когда на проекте меняется программист, и новый программист въезжает и разбирается в коде очень быстро. По идее должно быть что то типа ЕСКД для кодов, но т.к. такого вроде нет, фирмы для себя пытаются разрабатывать свои СТП.

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

А где бы найти какие требования к кодам ? В простом и коротком виде, что бы можно было быстро внедрить.

Вот, кстати, кое-что.
Единая система программной документации (ЕСПД)

Не, ЕСПД - это совсем не то. Это о том как по единым правилам блок-схему рисовать и всякие инструкции и формуляры писать. К тому же сто лет назад как вышла, так и не модернизируется в отличии от ЕСКД.

Вариантов тьма и холиваров тьма.
Лучше внедрить СТП под свои цели с учетом местных особенностей.
Можно в качестве лирической основы взять какую-нибудь философию/декларацию и нарастить на нее конкретные и детальные требования в виде СТП.
Лирика:
https://en.wikipedia.org/wiki/Zen_of_Python
https://ru.wikipedia.org/wiki/Python
https://en.wikipedia.org/wiki/Unix_philosophy
https://ru.wikipedia.org/wiki/Философия_UNIX


Быстрота внедрения зависит, в частности, от зрелости коллектива разработчиков и адекватности требований СТП.
Хорошо, если не будет воплей об ущемлении творческого полета тружеников мышки и клавиатуры, считающих "грязный хак" и недокументированные возможности высшим достижением, а стандарты убожеством.

Сообщение отредактировал BackEnd - Aug 27 2016, 14:02

Вот тут толковый перечень правил.
"10 правил, которые позволяют NASA писать миллионы строк кода с минимальными ошибками"
https://habrahabr.ru/company/hexlet/blog/303160/

MiklPolikov, спасибо за ссылку по правилам программирования. Многие и я в том числе потеряли годы на "изобретение" аналогичных правил.

Сообщение отредактировал VNS - Aug 29 2016, 07:08