Re[6]: Психология управления программными проектами
От: Anatolix Россия https://www.linkedin.com/in/anatolix/
Дата: 06.12.04 10:07
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Ты аккуратно вырезал из начала моей цитаты важную фразу: "Если речь идет о проектах без рефакторинга и о технически грамотных программистах (которые знакомы с языком и платформой) — не может." Как ты считаешь, какие проекты я имею в виду, когда говорю, что они без рефакторинга (добавлю: и без reverse engineering)? Не похоже на возню с легаси системами, не находишь?


G>Чтобы снять вопросы, скажу еще раз, прямо, что я говорю только о написании нового кода.


Ну ты же понимаешь что между новым кодом и legacy разница только во времени его написания. Через год уже твой код станет немножко legacy.
Ну ты же знаешь про систему CoCoMo и надеюсь не будешь отрицать что количество строк от времени зависит не линейно, поэтому можно посчитать количество строк в час, а можно в год и эти 2 значения не будут иметь друг к другу ничего общего.

Т.е. из-за неинейности скорости разработки, параметр средняя скорость написания смысла имеет не много поэтому я твои тезисы ставлю под сомнение.

Отдельные сомнения теперь вызывает и оценка оценка 20-60loc/hr очень похожа на оценку в час. Я легко поверю в такой темп в краткосрочной перспективе, но на протяжении года я сильно сомневаюсь, что можно такой темп держать(а ты только что сказал что считается она на протяжении года).
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Re[7]: Психология управления программными проектами
От: Gaperton http://gaperton.livejournal.com
Дата: 06.12.04 14:45
Оценка: 1 (1)
Здравствуйте, Anatolix, Вы писали:

A>Ну ты же понимаешь что между новым кодом и legacy разница только во времени его написания. Через год уже твой код станет немножко legacy.

Код станет legacy когда будет переведен в production, и сменится минимум состава команды, работающий над ним, так, что знания о коде будут частично утеряны. Когда придется планировать время на reverse engineering, тогда код и станет legacy. Если такое случилось в процессе разработки одного нового продукта до сдачи его в эксплуатацию , и вы на это закладываетесь как на штатную ситуацию , тогда конечно да. We're writing legacy code. Now.

A>Ну ты же знаешь про систему CoCoMo и надеюсь не будешь отрицать что количество строк от времени зависит не линейно, поэтому можно посчитать количество строк в час, а можно в год и эти 2 значения не будут иметь друг к другу ничего общего.

Они имеют много общего . LOC в час = LOC в год / кол-во рабочих дней в году / кол-во часов в дне.

Ты, видимо, до сих пор не догнал, что "строки в час" считаются на статистике по закрытой задаче, которая делается, например, неделю (а не замеряется скорость печати программера за отдельный час). И эти строки в час не будут "средними", средние — это посчитанные но большом количестве задач.

Таки это был раз. Во вторых, при хорошей декомпозиции время разработки одного изолированного модуля не зависит от наличия остальных модулей — они разрабатываются независимо и тестируются unit тестами. Не понимаю, откуда здесь возьмется нелинейность по количеству модулей, которая уменьшит мне продуктивность на одном из них в 10 раз. Причем хаотически и непредсказуемо, о чем шла речь с статье.

А время фазы интеграции, где все это должно взлететь, мы запланируем отдельно, основываясь на предполагаемой плотности дефектов (defect/KLOC) и размере кода в строках (LOC), и измеренном времени на дефект (или возьмем прогноз частично из головы, обработав его PERT-ом — тоже неплохо получится). Продуктивность при планировании этой фазы не очень интересна. И все, нелинейность вас не волнует, проверено при размере команды до 20 чел и сроке проекта до полутора лет. Если добавить, что план постоянно корректируется по ходу получения фактической информации по продуктивности и рискам, так все вообще станет хорошо.

A>Т.е. из-за неинейности скорости разработки, параметр средняя скорость написания смысла имеет не много поэтому я твои тезисы ставлю под сомнение.

Не понимаю, к чему сомневаться и теоретизировать о том, что можно легко измерить.

A>Отдельные сомнения теперь вызывает и оценка оценка 20-60loc/hr очень похожа на оценку в час. Я легко поверю в такой темп в краткосрочной перспективе, но на протяжении года я сильно сомневаюсь, что можно такой темп держать(а ты только что сказал что считается она на протяжении года).

А ты не верь, а проверь. 20 LOC/hr — это нормальный измеренный среднийтемп для практически всех команд у нас в компании за последних два года, который стабилен поквартально. Посчитан на групповых проектах сроком от полугода — понятно, что это не двухчасовая изолированная задачка, которая колбасится на 60 LOC/hr (у меня — 45 LOC/hr).

Сейчас попробую достать наши метрики по закрытым проектам, если получится, пришлю сюда.
Re[6]: Психология управления программными проектами
От: kikap Россия http://www.kika.ru
Дата: 07.12.04 03:18
Оценка:
Здравствуйте, AndreyFedotov, Вы писали:
AF> Вот об этом я и говорю Главное — результат. Сравним с инженерными областями — архитектурой, например, или индустрией.

Вы читали Дика Гэбриела? Если да, то это редкий случай... Просто цитата фактически прямая.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Re[8]: Психология управления программными проектами
От: Anatolix Россия https://www.linkedin.com/in/anatolix/
Дата: 07.12.04 06:30
Оценка:
Здравствуйте, Gaperton, Вы писали:

> Код станет legacy когда будет переведен в production, и сменится минимум состава команды, работающий над ним, так, что знания о коде будут частично утеряны.


Он тогда совсем Legacy станет, немножко Legacy т.е. требующий дополнительное время он становится достаточно быстро. Т.е. я вот например месяц назад нашел багу в коде который писал 2 года назад. Поправил. Но времени это у меня заняло не 5 минут, а час. Даже об одном и том же коде знания оказываются утерянными, даже если есть документы по design их нужно читать.

A>>Ну ты же знаешь про систему CoCoMo и надеюсь не будешь отрицать что количество строк от времени зависит не линейно, поэтому можно посчитать количество строк в час, а можно в год и эти 2 значения не будут иметь друг к другу ничего общего.

G>Они имеют много общего . LOC в час = LOC в год / кол-во рабочих дней в году / кол-во часов в дне.

А почему не LOC в час = LOC в месяц / количество рабочих дней в месяце / количество часво в году? Другая характеристика будет.

G>Ты, видимо, до сих пор не догнал, что "строки в час" считаются на статистике по закрытой задаче, которая делается, например, неделю (а не замеряется скорость печати программера за отдельный час). И эти строки в час не будут "средними", средние — это посчитанные но большом количестве задач.


Среднее можно посчитать по любому параметру. Так вот среднее KLOC среди проектов в месяц и среднее KLOC среди проектов в 3 года совсем разное.

G>Таки это был раз. Во вторых, при хорошей декомпозиции время разработки одного изолированного модуля не зависит от наличия остальных модулей — они разрабатываются независимо и тестируются unit тестами. Не понимаю, откуда здесь возьмется нелинейность по количеству модулей, которая уменьшит мне продуктивность на одном из них в 10 раз. Причем хаотически и непредсказуемо, о чем шла речь с статье.


Да забей ты на статью. Просто если у тебя есть N модулей то между ними есть 2 крайних варианта
1) N-1 связей между ними (идеальный дизайн)
2) N*N связей (наихудший дизайн)

Это экстремальные значения, в реальной жизни получается где то наверное N*LnN — но все равно не линейно.

G>А время фазы интеграции, где все это должно взлететь, мы запланируем отдельно, основываясь на предполагаемой плотности дефектов (defect/KLOC) и размере кода в строках (LOC), и измеренном времени на дефект (или возьмем прогноз частично из головы, обработав его PERT-ом — тоже неплохо получится). Продуктивность при планировании этой фазы не очень интересна. И все, нелинейность вас не волнует, проверено при размере команды до 20 чел и сроке проекта до полутора лет. Если добавить, что план постоянно корректируется по ходу получения фактической информации по продуктивности и рискам, так все вообще станет хорошо.


Полтора года это очень короткий проект, есть такие решения типа сделать сдать и забыть. Здесь действительно legacy это не так страшно. Но все равно есть. Кроме того ты для чего сроки измеряешь для программы или для продукта? Я так понимаю что обсуждать имеет смысл продукт, во всяком случае CoCoMo коэффичиенты для них посчитаны. Я не вижу смысл считать продуктивность в KLoc для кода который еще нужно дорабатывать в двое большее времени чем потратили на написание.

A>>Т.е. из-за неинейности скорости разработки, параметр средняя скорость написания смысла имеет не много поэтому я твои тезисы ставлю под сомнение.

G>Не понимаю, к чему сомневаться и теоретизировать о том, что можно легко измерить.

A>>Отдельные сомнения теперь вызывает и оценка оценка 20-60loc/hr очень похожа на оценку в час. Я легко поверю в такой темп в краткосрочной перспективе, но на протяжении года я сильно сомневаюсь, что можно такой темп держать(а ты только что сказал что считается она на протяжении года).

G>А ты не верь, а проверь. 20 LOC/hr — это нормальный измеренный среднийтемп для практически всех команд у нас в компании за последних два года, который стабилен поквартально. Посчитан на групповых проектах сроком от полугода — понятно, что это не двухчасовая изолированная задачка, которая колбасится на 60 LOC/hr (у меня — 45 LOC/hr).

G>Сейчас попробую достать наши метрики по закрытым проектам, если получится, пришлю сюда.


Давай. С интересом посмотрю.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Re[9]: Психология управления программными проектами
От: Maxim S. Shatskih Россия  
Дата: 08.12.04 15:01
Оценка:
A>Ну и хорошо. Просто отсутствие стагнации в отрасли. Меня подобная ситуация полностью устраивает, потому что даже при том что значительная часть проектов заваливается это происходит из-за того что кто то откусил больше чем смог проглотить.

Золотые слова. Просто золотые и все.
Часто руководитель девелопмента нахватает проектов — а потом у него элементарно некому их делать. Развитие компании в персонале отстает от развития в заказчиках.

А проекты хватаются с надеждой на авось.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[7]: Психология управления программными проектами
От: Maxim S. Shatskih Россия  
Дата: 08.12.04 15:04
Оценка:
OE>сделать проще гораздо сложнее и дольше, чем сделать сложнее, сложно — оно само-собой
получается

Не согласен. Чтобы сделать проще — надо больше думать на этапе проектирования. На сроки это практически не влияет. И сказал бы, что тут играет большую роль профессиональный уровень архитектора, а не потраченное им время.

Сделать сложнее — оно тупее в плане требований к архитекторам, но всегда хуже по общим срокам проекта.
Занимайтесь LoveCraftом, а не WarCraftом!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.