Большинство таблиц не несут самих данных, а нужны лишь для связи множества объектов друг с другом
разве может быть как-то иначе?) реляционная модель это навороченная логика на самом деле. в ней выражаются логические связи между данными, а так же реализуются операции над ними.
а оверхед это и есть следствие очень глубокой нормализации. а очень глубокая нормализация получается из требований к универсальности модели данных («нечеткости схем»), в купе с необходимостью обеспечивать, при всем при этом, их логическую непротиворечивость.
я так понял, команда несет внутреннюю ответственность за качество. а кто определяет сроки и бюджет проекта, и кто потом отвечает за них?
решение об не-использовании тестировщиков все-таки было принято ПМ (который отвечает за людей и зарплату), а не командой?
мм… кажется начинаю вас понимать. с десятого раза, но спасибо за терпение и настойчивость.
За качество и выпуск самого продукта отвечает команда!
в смысле — юридически (кто является исполнителем, с которым заказчик заключает договор, и что, в общих чертах, представляет собой предмет такого договора)?
тяжело, говорите? мифический ПМ тупо переложил ответственность за качество продукта с себя на разработчиков — ура, тестировщики нам больше не нужны (развивайте мысль дальше — аналитики, проектировщики, маркетологи, ...). при таком раскладе уже ни какие метрики не принципиальны — можно делать стори поинты, функциональные единицы, фичи, деньги или в чем там еще из меряется value, не доводить дефекты до конечных пользователей — легко. :P
так в чем подвох? думаю, и сами знаете: мифический ПМ, который ни за что не отвечает — не нужен. волшебный пендель от начальства / заказчика за продуктовый деффект, быстро вернет ПМа из мифа в реальность, где контролировать качество ему так-и приходится. а тестирование это один из инструментов, дающий ПМу метрики, необходимые для быстрой обратной связи. очень удобная штука — с ним КК дается гораздо легче. мм… все имхо, разумеется.
зы: может через пару лет напишите опровержение, типа «жизнь без тестировщиков: как нажить геморрой на свою голову». :)
хоть программист и делает кучу дефектов и тут и там, его работа по-прежнему может считаться качественной.
в этом нет ничего удивительного, просто работа это процесс, а продукт это результат — и в каждом случае будут разные оценочные критерии, и соответственно свои «хорошо» или «плохо».
качество работы разработчика вы можете оценивать по степени вовлеченности, напряженности, безопасности, устойчивости, времени (не путать со сроками), наконец — т.е. по тому, _как_ он работает. оценивать качество результата — по соответствию техническим спецификациям, нормам и т.д.
но все это фигня, если вам нужно не оценивать, а контролировать и управлять — потому, что тут требуются количественные характеристики, которые можно измерять и сравнивать.
программист виноват в том, что не задал вопрос, а реализовал как ему показалось правильным. Если бы все на своих рабочих местах делали так как им лично кажется, то был бы полный беспредел везде
по-вашему, получается, что программист виноват в том, что он программирует. нет, в самом деле, если бы все на своих рабочих местах задавали вопросы, то ни кто бы не программировал, а все бы задавали вопросы.
возможно я вас не правильно понял, или вы говорите не теми картинками, но как-то не получается представить скрам в виде переходного процесса, т.е. — реакции ОУ на воздействие. да и адепты его называют, не процессом, а методологией.
попробуйте начать с базовых определений банальной неустаревающей ТАУ: что есть объект управления, каковы его характеристики и особенности, и каковы цели процесса управления? какую роль играет скрам — расскажите, каково назначение, принципы управления, критерии, требования, ограничения и т.п.
Другое дело, насколько его метрики и методики оценки совпадают с таковыми у заказчика и пользователей
это очень даже важное дело — появление доморощенных критериев и локальные оптимизации, которые не согласованны с метриками проекта, нужно всячески пресекать.
дополнительный самоконтроль потребует дополнительное время и ресурсы, а значит такая самодеятельность чревата увеличением стоимости разработки и срывами сроков. я не в смысле «хорошо» это или «плохо», но такие решения должны согласовываться на уровне проекта, а не приниматься локально.
retran, опишите, скрам с точки зрения банальной неустаревающей ТАУ или теории управления у менеджеров, или поделитесь ссылкой, если все уже где-то описано.
(без всякого сарказма, реально интересно увидеть взгляд на вопрос с такой стороны).
мне почему-то кажется, что пример с самсунгом немного не об этом, ведь заказчик такой штуки скорее всего был внутри компании и тесты S3 это стезя разработки, а не внешних отношений, как предлагается в статье.
может-ли внешний заказчик доверять автотестам? каким образом он можно убедиться, что приемочные автотесты:
1. полны (покрывают достаточный объем функциональности)?
2. состоятельны (действительно что-то проверяют, а не рисуют зеленые полоски «от балды»)?
3. адекватны (приложение в продакшене будет вести себя так же как в среде тестирования)?
4. экономически выгодны (стоимость их внедрения, разработки и поддержки будет ниже, чем у альтернатив)?
что мы не сделали, какие суды, вы вообще о чем? :) предмет, стоимость, порядок сдачи и приемки — все это описывается в договоре, предоставляя для подобных неформальных вопросов, вполне формальные ответы.
при рефакторинге уровня программы не меняются приемочные тесты. но все, что касается её внутренностей (unit, интеграционные) ломается — аж пыль столбом. :)
кстати, imgo есть в виде убунтячих пакетов на https://launchpad.net/~e15/+archive/ppa. собирали для очередного проекта тов. iadramelk. можно попытаться реанимировать, если вдруг кому-то это нужно.
решение об не-использовании тестировщиков все-таки было принято ПМ (который отвечает за людей и зарплату), а не командой?
так в чем подвох? думаю, и сами знаете: мифический ПМ, который ни за что не отвечает — не нужен. волшебный пендель от начальства / заказчика за продуктовый деффект, быстро вернет ПМа из мифа в реальность, где контролировать качество ему так-и приходится. а тестирование это один из инструментов, дающий ПМу метрики, необходимые для быстрой обратной связи. очень удобная штука — с ним КК дается гораздо легче. мм… все имхо, разумеется.
зы: может через пару лет напишите опровержение, типа «жизнь без тестировщиков: как нажить геморрой на свою голову». :)
в этом нет ничего удивительного, просто работа это процесс, а продукт это результат — и в каждом случае будут разные оценочные критерии, и соответственно свои «хорошо» или «плохо».
качество работы разработчика вы можете оценивать по степени вовлеченности, напряженности, безопасности, устойчивости, времени (не путать со сроками), наконец — т.е. по тому, _как_ он работает. оценивать качество результата — по соответствию техническим спецификациям, нормам и т.д.
но все это фигня, если вам нужно не оценивать, а контролировать и управлять — потому, что тут требуются количественные характеристики, которые можно измерять и сравнивать.
попробуйте начать с базовых определений банальной неустаревающей ТАУ: что есть объект управления, каковы его характеристики и особенности, и каковы цели процесса управления? какую роль играет скрам — расскажите, каково назначение, принципы управления, критерии, требования, ограничения и т.п.
это очень даже важное дело — появление доморощенных критериев и локальные оптимизации, которые не согласованны с метриками проекта, нужно всячески пресекать.
дополнительный самоконтроль потребует дополнительное время и ресурсы, а значит такая самодеятельность чревата увеличением стоимости разработки и срывами сроков. я не в смысле «хорошо» это или «плохо», но такие решения должны согласовываться на уровне проекта, а не приниматься локально.
(без всякого сарказма, реально интересно увидеть взгляд на вопрос с такой стороны).
может-ли внешний заказчик доверять автотестам? каким образом он можно убедиться, что приемочные автотесты:
1. полны (покрывают достаточный объем функциональности)?
2. состоятельны (действительно что-то проверяют, а не рисуют зеленые полоски «от балды»)?
3. адекватны (приложение в продакшене будет вести себя так же как в среде тестирования)?
4. экономически выгодны (стоимость их внедрения, разработки и поддержки будет ниже, чем у альтернатив)?
e.получается, что при расчетах для css3 так же можно брать готовые формулы, но из другого учебника.
зы: еще б оно деления угломера понимало… _o\--