Из статьи крайне неясен профит этого. Кроме того надо создавать webapp с wildcard байндингом для Host-named sitecollection (HNSC), иначе придется байндинги править на каждом сервере, а это очень геморройно.
Из недавнего:
Capers Jones. Scoring and Evaluating Software Methods, Prectices and Results. 2010. у него еще много исследований интересных, увы не помню где качал
Если 30 лет не выявлено, то видимо связи то и нет. Если бы было одно исследование, то был бы один разговор. А исследований несколько, причем очень даже адекватных, и все равно не выявлено.
Собственно, главный вопрос: как из этого соотношения был получен вывод о силе связи между стажем и продуктивностью?
Ни в одном исследовании не было выявлено связи опыта (стажа) и продуктивности.
Понятно что есть минимальный уровень опыта, с которым это выполняется, и для конкретной задачи требуется минимальный уровень понимания технической и предметной области.
А вы прочитайте фразу ровно до того куска, который вы процитировали. Это ведь вопрос эффективности. В малых командах продуктивность (писать код правильно) не так важна, как эффективность (писать нужный код).
Разный конечно, но к продуктивности это не относится. Это вопрос эффективности, ведь программист может струячить качественный, но совершенно не нужный код.
Важно не только отсутствие корреляции между опытом и продуктивностью, но и огромная разница для людей с одинаковым уровнем опыта. Среди профессиональных водителей примерно одного стажа вряд ли встретишь отличия в разы.
4.Совет руководителям проекта. В классическом треугольнике качество-сроки-бюджет, бюджет как правило зафиксирован, категория качества является для топ-менеджмента довольно абстрактной (сокращать функционал не дают, так что качество это именно качество), так что вместо треугольника готовьтесь воевать только на одном фронте — фронте сроков. Просто учитывайте это при планировании.
А где совет то? Правило треугольника как раз говорит что все три вершины зафиксировать нельзя. Можно зафиксировать одну из них, например бюджет. При зафиксированном бюджете команда установит объем функционала и будет варьировать сроки реализации путем изменения количества привлеченных разработчиков.
Если тебе дают хотя бы две зафиксированные вершины, то варьировать уже нечего.
Кстати в оригинале в треугольнике нету «качества», есть объем, срок и бюджет. Качество присутствует во всех трех неявно. Причем зависимость явно нелинейная, поэтому нельзя просто обменять качество на срок.
Я писал в блоге на эту тему: gandjustas.blogspot.ru/2013/12/host-named-sitecollections.html
2) Клиентские компьютеры были в домене?
3) Это внешний сайт?
4) Почему сразу не сделали формы?
Capers Jones. Scoring and Evaluating Software Methods, Prectices and Results. 2010. у него еще много исследований интересных, увы не помню где качал
И вот это: sequoia.cs.byu.edu/lab/files/pubs/Delorey2007a.pdf
Ни в одном исследовании не было выявлено связи опыта (стажа) и продуктивности.
Понятно что есть минимальный уровень опыта, с которым это выполняется, и для конкретной задачи требуется минимальный уровень понимания технической и предметной области.
Именно так.
А где совет то? Правило треугольника как раз говорит что все три вершины зафиксировать нельзя. Можно зафиксировать одну из них, например бюджет. При зафиксированном бюджете команда установит объем функционала и будет варьировать сроки реализации путем изменения количества привлеченных разработчиков.
Если тебе дают хотя бы две зафиксированные вершины, то варьировать уже нечего.
Кстати в оригинале в треугольнике нету «качества», есть объем, срок и бюджет. Качество присутствует во всех трех неявно. Причем зависимость явно нелинейная, поэтому нельзя просто обменять качество на срок.