Здравствуйте, bkat, Вы писали:
K>>Bottom line — communication is a key, обо всём можно договориться. Но не о том сейчас речь. Я имею в виду ситуации, когда меня просят реализовать "кнопку, по нажатию на которую покажется сообщение ...", не объясняя того, зачем эта кнопка нужна и какие тут возможны use-case'ы. Иначе говоря, когда мне объясняют, как надо сделать, вместо того, что надо сделать — с первым при наличии второго я и сам справлюсь...
B>Хм... B>Ну дак спеки на что?
Спеки — это просто один из способов коммуникации. Это не вещь в себе, не самоцель и не единственный способ коммуникации. Такой подход имеет свои плюсы, имеет свои минусы и уж точно не является единственным и не является панацеей.
Здравствуйте, AndrewVK, Вы писали:
AVK>В дополнение к сказанному — промышленная разработка это еще и доведение кода до состояния, когда его можно отдать заказчику/упаковать в коробку. Т.е. в нем нет "тут не работает, тут недоделано, тут надо подрихтовать, а тут рыбу заворачивали". К сожалению, очень многие начинающие разработчики не понимаю, как долог путь от рабочего концепта до промышленного решения.
Что-то я не пойму. А как тогда быть с той частью IT-индустрии (т.е. — промышленности), которая занимается разработкой заказного ПО с единичными инсталляциями и непрерывным циклом доработки? Это, типа, "не промышленная" разработка?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, маген, Вы писали:
AVK>В дополнение к сказанному — промышленная разработка это еще и доведение кода до состояния, когда его можно отдать заказчику/упаковать в коробку.
Выходит гугл не занимается промышленной разработкой?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Что-то я не пойму. А как тогда быть с той частью IT-индустрии (т.е. — промышленности), которая занимается разработкой заказного ПО с единичными инсталляциями и непрерывным циклом доработки? Это, типа, "не промышленная" разработка?
Почему ты так решил? Код доводится до состояния, когда он применяется для автоматизации реальной деятельности, так что он вполне промышленный.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Что-то я не пойму. А как тогда быть с той частью IT-индустрии (т.е. — промышленности), которая занимается разработкой заказного ПО с единичными инсталляциями и непрерывным циклом доработки? Это, типа, "не промышленная" разработка?
AVK>Почему ты так решил? Код доводится до состояния, когда он применяется для автоматизации реальной деятельности, так что он вполне промышленный.
Я просто не пойму, где ключевые различия промышленного и непромышленного подхода, грубо говоря. Неработающую программу даже студент в качестве курсовика не может подсунуть (как правило).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Я просто не пойму, где ключевые различия промышленного и непромышленного подхода, грубо говоря. AVK>Если ты ищешь четкую и однозначную границу, то ее нет.
Упс. А как же тогда выставлять требования к вакансии? Если даже чёткой границы области определения нет?
ГВ>> Неработающую программу даже студент в качестве курсовика не может подсунуть (как правило). AVK>Работающая программа — это необходимое, но никак не достаточное требование.
Отлично, а что тогда достаточные требования?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>> Неработающую программу даже студент в качестве курсовика не может подсунуть (как правило). AVK>>Работающая программа — это необходимое, но никак не достаточное требование.
ГВ>Отлично, а что тогда достаточные требования?
имхо, наличие не только готовой, даже не полностью, но готовой на некотором этапе системы, которую будут и\или будут и уже используют в "боевом" режиме т.е. с реальными данными, для реальной автоматизации, а не некоторый теоретический продукт. Причем проблемы, которые возникают в уже внедренной и используемой системы решаются совсем по-другому, вспомнить хотя бы решение проблем безопасности, падения, недоработок и т.д. в Windows, Office, 1C и подобных. Именно опыт разработки и поддержки уже внедренных систем наверное и подразумевается в такой вакансии.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Упс. А как же тогда выставлять требования к вакансии? Если даже чёткой границы области определения нет? AVK>Вот так и выставлять. А что тебя удивляет?
Не понятно, как определять соответствие. Разве что по самоназванию.
AVK>У требования вроде "знание С++" тоже четкой границы нет.
Очень даже есть. И легко проверяется.
ГВ>>Отлично, а что тогда достаточные требования? AVK>Количество глюков на приемлемом уровне, отсутствие грубых недоделок, хорошее качество кода и много чего еще.
Тогда это просто опыт разработки программ, которые были переданы в эксплуатацию реальным пользователям. Вроде, ничем не отличается от любой другой коллективной разработки на заказ.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, RonWilson, Вы писали:
ГВ>>Отлично, а что тогда достаточные требования?
RW>имхо, наличие не только готовой, даже не полностью, но готовой на некотором этапе системы, которую будут и\или будут и уже используют в "боевом" режиме т.е. с реальными данными, для реальной автоматизации, а не некоторый теоретический продукт. Причем проблемы, которые возникают в уже внедренной и используемой системы решаются совсем по-другому, вспомнить хотя бы решение проблем безопасности, падения, недоработок и т.д. в Windows, Office, 1C и подобных. Именно опыт разработки и поддержки уже внедренных систем наверное и подразумевается в такой вакансии.
Хм. Но это именно опыт "внедрения и поддержки". При чём тут отдельная категория "промышленности"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хм. Но это именно опыт "внедрения и поддержки". При чём тут отдельная категория "промышленности"?
внедрять и поддерживать можно разные по масштабам и ориентированные на разные рынки системы, можно иметь такой опыт для какого-нибудь плеера, ошибка в котором в принципе обидное дело, но исправляется путем выкладывания нового exe-шника, или ошибки в системе бухгалтерского учета, в результате которых люди попросту не смогут работать, а то еще хуже. это конечно мое имхо, но как-то так.
Вот кстати определение из курса управления качеством, в ней нет выделения такого, что вот эта система — промышленная а это нет, это просто определение технологического процесса:
Промышленная разработка программного обеспечения как часть промышленной разработки сложных систем — высокотехнологичный процесс, в который вовлечено множество различающихся по численности, сфере деятельности и квалификации коллективов разработчиков. Одна из основных задач при совместной работе большого количества разработчиков или их коллективов: обеспечение единой схемы работы, позволяющей планировать выполнение работ, обеспечивать целостность и непротиворечивость различных узлов системы, а также давать гарантии соответствия системы ожиданиям заказчика.
Здравствуйте, Геннадий Васильев, Вы писали:
AVK>>Вот так и выставлять. А что тебя удивляет?
ГВ>Не понятно, как определять соответствие. Разве что по самоназванию.
Определяется по тому, какое качество кода на выходе получается. На практике отсутствие упомянутого навыка очень хорошо видно. Даже в форуме.
AVK>>У требования вроде "знание С++" тоже четкой границы нет.
ГВ>Очень даже есть.
Нету. Потому что у каждого своя степень знания материала, с которой начинается это "знает". Кому то знания синтаксиса достаточно, а кому то и детального изучения александресковщины мало.
ГВ>>>Отлично, а что тогда достаточные требования? AVK>>Количество глюков на приемлемом уровне, отсутствие грубых недоделок, хорошее качество кода и много чего еще.
ГВ>Тогда это просто опыт разработки программ, которые были переданы в эксплуатацию реальным пользователям.
Примерно так.
ГВ> Вроде, ничем не отличается от любой другой коллективной разработки на заказ.
Зато отличается от многих опенсорсов, проектов типа RSDN@Home, академических исследований и упомянутого тобой курсача.
... << RSDN@Home 1.2.0 alpha 4 rev. 1324 on Windows 7 6.1.7600.0>>
М>Лично у меня вариантов нет, я вообще не знаю, что _точно_ под этим термином М>подразумевается.
Насколько я понимаю, под данным термином не подразумевается вообще ничего. Как ты правильно заметил, этот термин начинает появляться все чаще и чаще; однажды, может быть, кто-то что-то в него и вложил (но об этом все уже благополучно забыли), а остальным сама фраза понравилась "промышленная разработка". Реально же круто звучит? Уж однозначно круче чем "опыт разработки N лет"!
Итого: очередное модное требование, как когда-то "знание паттернов проектирования", которое было в каждом втором требовании к соискателю.
Здравствуйте, AndrewVK, Вы писали:
ГВ>>Тогда это просто опыт разработки программ, которые были переданы в эксплуатацию реальным пользователям. AVK>Примерно так.
появилось нечто похожее на определение. По крайней мере, можно обсудить более предметно.
P.S.: В прочем, с наступающим!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Кэр, Вы писали:
Кэр>Здравствуйте, bkat, Вы писали:
K>>>Bottom line — communication is a key, обо всём можно договориться. Но не о том сейчас речь. Я имею в виду ситуации, когда меня просят реализовать "кнопку, по нажатию на которую покажется сообщение ...", не объясняя того, зачем эта кнопка нужна и какие тут возможны use-case'ы. Иначе говоря, когда мне объясняют, как надо сделать, вместо того, что надо сделать — с первым при наличии второго я и сам справлюсь...
B>>Хм... B>>Ну дак спеки на что?
Кэр>Спеки — это просто один из способов коммуникации. Это не вещь в себе, не самоцель и не единственный способ коммуникации. Такой подход имеет свои плюсы, имеет свои минусы и уж точно не является единственным и не является панацеей.
Со всем согласен, но в любом случае спеки — это стандартный подход
для описания того, что должна делать система.
Если есть проблемы внятно на бумаге сформулировать то, что хочется получить от системы,
то врядли другие способы коммуникации позволят это сделать намного лучше.
Здравствуйте, bkat, Вы писали:
K>>>>Bottom line — communication is a key, обо всём можно договориться. Но не о том сейчас речь. Я имею в виду ситуации, когда меня просят реализовать "кнопку, по нажатию на которую покажется сообщение ...", не объясняя того, зачем эта кнопка нужна и какие тут возможны use-case'ы. Иначе говоря, когда мне объясняют, как надо сделать, вместо того, что надо сделать — с первым при наличии второго я и сам справлюсь...
B>>>Хм... B>>>Ну дак спеки на что?
Кэр>>Спеки — это просто один из способов коммуникации. Это не вещь в себе, не самоцель и не единственный способ коммуникации. Такой подход имеет свои плюсы, имеет свои минусы и уж точно не является единственным и не является панацеей.
B>Со всем согласен, но в любом случае спеки — это стандартный подход B>для описания того, что должна делать система. B>Если есть проблемы внятно на бумаге сформулировать то, что хочется получить от системы, B>то врядли другие способы коммуникации позволят это сделать намного лучше.
Конкретно в контексте этой дискуссии. Вы предлагаете документировать поведение кнопки. Возможно это имеет смысл (если документ описывает общее поведение системы, и из этого однозначно понятно, что кнопка должна делать), но также вполне возможно это не имеет смысла. И дело тут не в том, что есть какие-то проблемы внятно сформулировать поведение кнопки на бумаге. Проблема в том, что дорого писать такую подробную документацию и потом поддерживать эту документацию в актуальном состоянии. Возможно гораздо проще обговорить это с ключевыми людьми, если есть вопросы, и написать реализацию.
Здравствуйте, Кэр, Вы писали:
Кэр>Здравствуйте, bkat, Вы писали:
K>>>>>Bottom line — communication is a key, обо всём можно договориться. Но не о том сейчас речь. Я имею в виду ситуации, когда меня просят реализовать "кнопку, по нажатию на которую покажется сообщение ...", не объясняя того, зачем эта кнопка нужна и какие тут возможны use-case'ы. Иначе говоря, когда мне объясняют, как надо сделать, вместо того, что надо сделать — с первым при наличии второго я и сам справлюсь...
B>>>>Хм... B>>>>Ну дак спеки на что?
Кэр>>>Спеки — это просто один из способов коммуникации. Это не вещь в себе, не самоцель и не единственный способ коммуникации. Такой подход имеет свои плюсы, имеет свои минусы и уж точно не является единственным и не является панацеей.
B>>Со всем согласен, но в любом случае спеки — это стандартный подход B>>для описания того, что должна делать система. B>>Если есть проблемы внятно на бумаге сформулировать то, что хочется получить от системы, B>>то врядли другие способы коммуникации позволят это сделать намного лучше.
Кэр>Конкретно в контексте этой дискуссии. Вы предлагаете документировать поведение кнопки. Возможно это имеет смысл (если документ описывает общее поведение системы, и из этого однозначно понятно, что кнопка должна делать), но также вполне возможно это не имеет смысла. И дело тут не в том, что есть какие-то проблемы внятно сформулировать поведение кнопки на бумаге. Проблема в том, что дорого писать такую подробную документацию и потом поддерживать эту документацию в актуальном состоянии. Возможно гораздо проще обговорить это с ключевыми людьми, если есть вопросы, и написать реализацию.
Дискуссия будет конкретна на конкретном проекте
А вообще, да я предлагаю документировать поведение кнопки.
Вернее сформулировать функцию системы, которая подразумевается.
Будет ли это кнопка или пункт меню или еще что-либо — это уже, кстати, больше решение.
И не такая уж и нерешаемая задача, которая требует не так уж и много людей и ресурсов.
Обговаривать с ключевыми людьми все равно придется.
Вопрос только в том, останется ли после обсуждений только дым в курилке
или будет что-то конкретное в документе.
Здравствуйте, bkat, Вы писали:
B>А вообще, да я предлагаю документировать поведение кнопки. B>Вернее сформулировать функцию системы, которая подразумевается. B>Будет ли это кнопка или пункт меню или еще что-либо — это уже, кстати, больше решение. B>И не такая уж и нерешаемая задача, которая требует не так уж и много людей и ресурсов. B>Обговаривать с ключевыми людьми все равно придется. B>Вопрос только в том, останется ли после обсуждений только дым в курилке B>или будет что-то конкретное в документе.
Будет что-то конкретное в коде — часто этого достаточно. Если принципиально то, что была выбрана именно кнопка, а не пункт меню и это знание хочется сохранить и использовать в дальнейшем — имеет смысл задокументировать это. Если нет — то найдутся и более достойные применения этому времени.
