Здравствуйте, Shmj, Вы писали:
bnk>>Речь скорее всего про разные вещи. bnk>>Задача "сортировка файла" проектом не является, это же просто задача.
S>Проект состоит из таких вот задач. И на поиск решения для некоторых из них — троится немало времени. S>Да, можно согласится что время тратиться на написание документации, тесты, создание авто-тестов. Но никак не на сбор и анализ требований — это вообще 1% от проекта.
IMHO если не тратить на обсуждение кучу времени, придется постоянно переписывать код.
В конце концов заказчик просто устанет от этого и выберет другого исполнителя, или у него деньги закончатся.
Цена ошибки увеличивается экспоненциально по мере реализации кода.
На этапе когда только обсуждаешь — 1 рубль, когда код написан — 10 рублей, когда выложен в продакшен — 100 рублей.
Самая большая ошибка — решать не ту задачу.
А многие задачи можно же решить вообще без написания кода, чисто административными методами
Re[15]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
DP>>Вот смотрите: даже сейчас нам понадобилось несколько сообщений туда-сюда, чтобы уточнить требования. И они все еще ясно не прописаны. S>Вы понимаете разницу между сбором требований и нахождением путей решения? Что, по вашему мнению, занимает больше времени?
Чем подробнее соберете требования, тем меньше будете искать решение или кодировать. Думаю можно утверждать, что время кодирования обратно пропорцианально
времени сбора требований. Чем меньше одно, тем больше другое.
Кодом людям нужно помогать!
Re[17]: Сбор, систематизация и анализ требований vs кодирован
S>Никто не спорит что это важно и может сэкономить время, если грамотно составлены требования и заказчик сам точно знает что нужно. Часто сам точно не знает и уже в процессе рождаются лучшие решения. Однако же не отменяет того факта, что сбор выполнить быстро и легко, а вот воплотить слова в жизнь — сложно и долго.
А может попробовать наоборот -- сбор выполнить сложно и долго, а зато потом воплотить слова в жизнь -- быстро и легко. Почему нет?
Кодом людям нужно помогать!
Re[18]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Sharov, Вы писали:
S>Чем подробнее соберете требования, тем меньше будете искать решение или кодировать. Думаю можно утверждать, что время кодирования обратно пропорцианально S>времени сбора требований. Чем меньше одно, тем больше другое.
Нет — требования и так понятны — обычно проблема как реализовать. Вот привел конкретную задачу — уже 2 недели никто не может толкового решения найти.
Re[16]: Сбор, систематизация и анализ требований vs кодирован
S>Чем подробнее соберете требования, тем меньше будете искать решение или кодировать. Думаю можно утверждать, что время кодирования обратно пропорцианально S>времени сбора требований. Чем меньше одно, тем больше другое.
Бывает и такое, что в ходе обсуждения задачи с ПМами выясняется, что эту юзер-стори вообще делать не нужно, или нужно, но у нее настолько низкий приоритет, что она забудется где-то там внизу бэклога. А бывает, наоборот, делаешь большую задачу в соответствии со всеми мельчайшими деталями спеки, а потом этим никто не пользуется. Лично сталкивался с обоими ситуациями.
Патриот здравого смысла
Re[17]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Чем подробнее соберете требования, тем меньше будете искать решение или кодировать. Думаю можно утверждать, что время кодирования обратно пропорцианально S>>времени сбора требований. Чем меньше одно, тем больше другое.
S>Нет — требования и так понятны — обычно проблема как реализовать. Вот привел конкретную задачу — уже 2 недели никто не может толкового решения найти.
А кто-то искал две недели? Ты денег предложи — сразу найдут.
Re[3]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали: S>А как же время на тестирование — если цена ошибки высока? Почему именно сбор требований?
А если цена ошибки высока — то тогда требования еще важнее. Тестировние в обычном понимании, когда программист или его коллега пишет юнит тесты на основе кода и дизайна, не является самым важным, но может присутствовать как часть разработки. Тест кейсы должны быть написаны не из кода а исходя из требований на систему, и тестирование должно доказать что все требования были выполнены верно и даже бывает доказать что весь код при этом выполнялся, т.е. что там нет ничего ненужного, типа заделов на будущее или левой копипасты из интернета. Да и сам код кстати тоже должен быть разработан исходя из подробных требований а не как какой-то программист типа подумал что будет хорошо.
Re[18]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, qqqqq, Вы писали:
Q>А если цена ошибки высока — то тогда требования еще важнее. Тестировние в обычном понимании, когда программист или его коллега пишет юнит тесты на основе кода и дизайна, не является самым важным, но может присутствовать как часть разработки. Тест кейсы должны быть написаны не из кода а исходя из требований на систему, и тестирование должно доказать что все требования были выполнены верно и даже бывает доказать что весь код при этом выполнялся, т.е. что там нет ничего ненужного, типа заделов на будущее или левой копипасты из интернета. Да и сам код кстати тоже должен быть разработан исходя из подробных требований а не как какой-то программист типа подумал что будет хорошо.
Во-первых, цена ошибки высока только в космических сервисах разве что, да и там можно предусмотреть откат.
Во-вторых, то что цена высока — это значит, что долго делать. Да, важно описать сервис. Но это не долго и не сложно — я готов бесплатно для простых сервисов. А вот найти как реализовать — это долго и сложно, бесплатно уже 2 недели никто не хочет для простого задания.
И еще. В большинстве случаев хорошие идеи приходят в момент воплощения — девелопер предлагает — а вот может давайте так сделаем — и все соглашаются что это лучше, т.к. на этапе составления требований об этом и подумать не могли.
Re[5]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>Во-первых, цена ошибки высока только в космических сервисах разве что, да и там можно предусмотреть откат.
Не только в космосе. Например: в финтехе ошибка может привести к большим убыткам, а системах управления электростанциями, промышленным оборудованием или в бортовом ПО самолёта — ещё и человеческим жертвам.
S>Во-вторых, то что цена высока — это значит, что долго делать. Да, важно описать сервис. Но это не долго и не сложно — я готов бесплатно для простых сервисов.
Дай определение простого сервиса.
S>А вот найти как реализовать — это долго и сложно, бесплатно уже 2 недели никто не хочет для простого задания.
Разработка программного продукта — процесс сложный на всех этапах жизненного цикла.
S>И еще. В большинстве случаев хорошие идеи приходят в момент воплощения — девелопер предлагает — а вот может давайте так сделаем — и все соглашаются что это лучше, т.к. на этапе составления требований об этом и подумать не могли.
Уточнение требований в процессе разработки — обычное дело. И, если сбором и анализом требований занимаются отдельные люди, то хорошо бы, обсуждать требования с программистами и тестировщиками не только, когда требования уже готовы, но и в процессе разработки требований.
Re[18]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:
S>>Нет — требования и так понятны — обычно проблема как реализовать. Вот привел конкретную задачу — уже 2 недели никто не может толкового решения найти. G>А кто-то искал две недели? Ты денег предложи — сразу найдут.
Сколько нужно?
Re[19]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>А кто-то искал две недели? Ты денег предложи — сразу найдут.
S>А требования бесплатно и без денег напишут.
Дай мне контакт людей, которые бесплатно напишут
Re[19]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Нет — требования и так понятны — обычно проблема как реализовать. Вот привел конкретную задачу — уже 2 недели никто не может толкового решения найти. G>>А кто-то искал две недели? Ты денег предложи — сразу найдут.
S>Сколько нужно?
Я бы за десятку взялся.
Re[17]: Сбор, систематизация и анализ требований vs кодирован
S>Нет — требования и так понятны — обычно проблема как реализовать. Вот привел конкретную задачу — уже 2 недели никто не может толкового решения найти.
Так вы ж сами привели решение. Плюс еще кто-то даже ссылку на решение в своем гитхабе выложил. Что еще надо?
Задача лично для меня интересная. Но мотивации нет ее делать. И тут дело даже не в деньгах. Если уж совсем нечем будет в плане программинга заняться, то можно будет. Я даже порывался пару раз начать...
Патриот здравого смысла
Re[18]: Сбор, систематизация и анализ требований vs кодирован
S>>А вот найти как реализовать — это долго и сложно, бесплатно уже 2 недели никто не хочет для простого задания. AN>Разработка программного продукта — процесс сложный на всех этапах жизненного цикла.
Здесь обсуждается вопрос — какое затраты на сбор и анализ требований в сравнении с другими этапами.
Re[20]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здесь обсуждается вопрос — какое затраты на сбор и анализ требований в сравнении с другими этапами.
Для сферической задачи в вакууме, затраты тоже сферические. Затраты на этап аналитики, по сравнению с другими этапами разные для разных проектов и могут сильно отличатся в зависимости от многих факторов:
Насколько типовой проект.
Насколько хорошо заказчик понимает, что должно получится и насколько детальное описание бизнес-требований у него есть.
Сколько заинтересованных лиц есть со стороны заказчика, если нужно учесть пожелания нескольких отделов, время на сбор и анализ требований может сильно увеличиваться.
Нужна ли интеграция со сторонними системами, если нужна — потребуется обсудить, как это делать и заранее подумать, как такую интеграцию тестировать.
Как нужно действовать в случае сбоя на компе, на котором ПО работает. Если можно день подождать, пока комп починять, можно вообще не задумываться над вопросом, а для системы, которая должна работать 24/7 требуется заранее подумать над отказоустойчивостью.
Есть ли к тому софту, ТЗ для которого пишется, какие-то требования со стороны регулирующих органов.
