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