Здравствуйте, Nikolay_Ch, Вы писали:

_>>См. Экстремальное программирование.
N_C>И что мы там видим? Доску и карточки? Это да. НО! Только при планировании работ эти карточки берутся и раскладываются
N_C>на доске. Таким образом получается тот-же план, только вид сбоку. И XP говорит, вообще-то, если поступает новые задачи,
N_C>то происходит пересмотр положения карточек на доске — а это вообще-то и есть пересмотр планов.
Че пристал?..
Работай как привык!
Я же не против

_>Че пристал?..
Мда... Молодой человек, потрудитесь вести себя спокойнее!

_>Работай как привык!
_>Я же не против
Я, вообще-то здесь делюсь мнением. И если что-то не устраивает в моих репликах так и говори.
Я работаю как привык и хотя-бы пытаюсь аргументировать свою точку зрения, а вот от тебя что-то
аргументов кроме "XP и все!" не услышал.

Здравствуйте, Streamer1, Вы писали:

S>некоторые подчиненные не любят когда их просят составить приблизительный план по выполнению задачи, обосновывая это невозможностью планирования в связи со "спецификой" области разрботки ПО и т.п.
S>в ход идут различные отмазки вроде "ну есть кое-какие идеи — чем не план? зачем его писать если он всеравно поменяется?" короче все как у Ашманова

S>Интересно можно ли переубедить? Хотелось бы стимулировать ответственностью... Или это бесполезное занятие?



если програмист нормальный он на 99% может сказать сколько времени займет тот или иной процес.
советую поменять их!

Здравствуйте, Nikolay_Ch, Вы писали:

Я уже поделился.
Мои ответы не были поняты, по крайней мере, тобой.
Зачем ругаться?..

Здравствуйте, alex_ez, Вы писали:

S>>а как же тогда быть? написанный менеджером плохо, написаный программером тоже плохо, выходит совсем без плана? а какже время планировать?

_>см. Экстремальное Программирование

А ты сам-то его видел?

Здравствуйте, SEDEGOFF, Вы писали:

_>>И все.
SED>Я так понял вы привели экстремальное программирование как пример методики в которой не используется планирование вообще и она работает на ура. Но я увидел что планирование тоже есть. Может я не правильно вас понял. Разъясните по подробнее — что вы хотели сказать, рекомендуя смотреть экстремальное программирование.

Я надеюсь, что общение не войдет в переперательство.

Планирование в экстремальном програмировании есть. Но это не "План" как таковой. Это то, что нужно сделать.
Каждый член комманды разработчиков !играет! свою роль и может одновременно является программистом.
Есть такие члены комманды как контролер, архитектор — которые задают и иногда направляют программистов, не мешая выполнять задачу.

Вообще, что я хотел выразить в первом посте:
План — это такая бумажка, которая висит над программистом не давая двигаться вперед, и, фактически, заставляет двигаться назад.
Программирование — это творчество. Представьте себя художником, перед которым поставили задачу нарисовать портрет и дали план: нужно в такие то сроки нарисовать руки, в такие то — ноги, потом туловище, ну и голову в конце. Помоему, это чистой воды бред.
Перенося на более новое направление творчесской деятельности — написание программ — у нас не меняется ни концепция возникновения идей, ни концепция реализации, меняется только инструмент и результат.

Здравствуйте, alex_ez, Вы писали:

_>Здравствуйте, SEDEGOFF, Вы писали:

_>Я надеюсь, что общение не войдет в переперательство.
Я тоже.

_>Планирование в экстремальном програмировании есть. Но это не "План" как таковой. Это то, что нужно сделать.
_>Каждый член комманды разработчиков !играет! свою роль и может одновременно является программистом.
_>Есть такие члены комманды как контролер, архитектор — которые задают и иногда направляют программистов, не мешая выполнять задачу.

_>Вообще, что я хотел выразить в первом посте:
_>План — это такая бумажка, которая висит над программистом не давая двигаться вперед, и, фактически, заставляет двигаться назад.
_>Программирование — это творчество. Представьте себя художником, перед которым поставили задачу нарисовать портрет и дали план: нужно в такие то сроки нарисовать руки, в такие то — ноги, потом туловище, ну и голову в конце. Помоему, это чистой воды бред.
_>Перенося на более новое направление творчесской деятельности — написание программ — у нас не меняется ни концепция возникновения идей, ни концепция реализации, меняется только инструмент и результат.
Для начала, давайте посмотрим с другой стороны — со стороны того, кто платит деньги. Он их платит не для того что бы программисту было что кушать пока он будет творить. Он их инвестирует и планирует(!) когда они начнут отрабатываться. Просто так не один нормальный заказчит не скажет — вот вам миллион как сделает позвоните. Он с начала спросит когда это будет сделано, и только после ответа будет принимать решение — давать или не давать денег. А если вы назовете срок без плана — то этот срок будет 99.999% неправильным и не выполнимым. Скажите — вы бы заказали картину у художника, который бы вам на вопрос ответил "Это же творчество! Когда будет готова неизвестно!"? Я думаю нет, во всяком случае я бы не заказал. Кроме того — нет ничего хуже не контролируемого творчества — это то же самое что глухой телефон. Вы даете задание "Измени на кнопке надпись с "Прогрузка" на "Загрузка". Не обозночаете не сроков не контрольных точек. Самое интресное что эта задача не будет сделана и через неделю, это в лучшем случае, а в хучшем вы получите новый юзекейс.
Теперь собственно про планы. Я не стремлюсь сделать план на 100% соответствующий возможностям программиста. Если я пишу задачу "Сделать вывод сообщения для пользователя после акцепта документа — Документ акцептова успешно." для программиста Иванова и я знаю что на реализацию этой задачи он потратит один час, то в плане у него в пункте длительность будет написано 1.3 часа. Идея понятна? Я, лично, не стремлюсь сделать план со 100% загрузкой программиста. Я всегда закладываю буффер примерно в 30%(Сейчас все идет к 20%). На тех задачах, которые решаются первый раз, буфер может достигать 100% самой задачи и называется этот пункт "Риски" (Правда его еще оправдать нужно).
Ну и на последок, повторюсь наверное, творчество для клиента это и есть минус и по этому его нужно планировать. Кроме того, на проектах более 500 человекочасов план просто необходим, так как уже 50 часе вы просто не будете знать что делать, вы будете разрываться.

Не хочу вас обидеть и сразу прошу прощения если случиться именно так, но по вашему посту можно сказать что вы не участвовали в больших проектах. А человек так устроен что он не верит не кому, пока сам не попробует. И только с опытом человек начинает понимать весь смысл выражения "Умный учится не только на своих ошибках — а даже больше на чужих".

Здравствуйте, alex_ez, Вы писали:

_>План — это такая бумажка, которая висит над программистом не давая двигаться вперед, и, фактически, заставляет двигаться назад.
Вот еще про это не упомянул. Правильно составленный план как раз показывает куда двигаться дальше. А грамотно составленый план — вызывает у программиста желание двигаться быстрее и качаственнее.

Здравствуйте, SEDEGOFF, Вы писали:

SED>Теперь собственно про планы. Я не стремлюсь сделать план на 100% соответствующий возможностям программиста. Если я пишу задачу "Сделать вывод сообщения для пользователя после акцепта документа — Документ акцептова успешно." для программиста Иванова и я знаю что на реализацию этой задачи он потратит один час, то в плане у него в пункте длительность будет написано 1.3 часа. Идея понятна? Я, лично, не стремлюсь сделать план со 100% загрузкой программиста. Я всегда закладываю буффер примерно в 30%(Сейчас все идет к 20%). На тех задачах, которые решаются первый раз, буфер может достигать 100% самой задачи и называется этот пункт "Риски" (Правда его еще оправдать нужно).

Интересно, как определить потребное время для задачи "Исправить баг номер 184, заключающийся в вылете access violation в случайный момент времени с периодом полураспада около 10000 часов"?

Здравствуйте, Vinni-puh, Вы писали:

VP>Интересно, как определить потребное время для задачи "Исправить баг номер 184, заключающийся в вылете access violation в случайный момент времени с периодом полураспада около 10000 часов"?

Видимо это время как раз входит в те самые 30% — написал кусок кода за час — есть 20 минут на исправление багов, можешь их сэкономить, тогда будешь исправлять потом, когда баг обнаружится. (-:

Здравствуйте, Vinni-puh, Вы писали:

VP>Интересно, как определить потребное время для задачи "Исправить баг номер 184, заключающийся в вылете access violation в случайный момент времени с периодом полураспада около 10000 часов"?
Поделюсь опытом и надеюсь он будет полезен. Сейчас у меня таких ошибок не появляется вообще! Как этого добиться? Проанализируйте решения этих ошибок. У меня получилось следующее:
1. Низкое качество кода. Решается вообще без проблем — иногда очень быстро
2. Низкое качество сторонних компонент и библиотек. Решается использованием золотого правила — НЕ ИСПОЛЬЗУЙТЕ НЕ ПРОВЕРЕННЫЕ РЕШЕНИЕ. Я даже сейчас работаю с решениями 3 летней давности. Если возникает необходимость в новом функционале, то как минимум у двух программистов появляется в планах "Тестирование библиотеки ХХХ"(Тестеры сдесь не причем)
3. Баги, с которыми нужно смериться или обойти. Общий процент от всего — менее 0.01. Тут все зависит от ситуации, но зачастую его компенсирует буфер, размер которого прямопропорционален новизне используемой технологии с коэффициентом k. В любом случае эта решаемая проблема и она не стоит выведенного яйца. Приведу свой пример. В BizTalk2004 есть одна фича, о не знании которой рядовой программис завалит все не мыслемые сроки. Я обнаружил эту фичу на втором расширении рисков (были 8 часов, потом стал 12. И последняя 16). Эту фичу я опубликовал. Из-за этой фичи больше небыло не одной задержки.
Удачи вам в решении этих багов

Здравствуйте, SEDEGOFF, Вы писали:

Молодой человек, зачем вы вводите людей в заблуждение?..

VP>>Интересно, как определить потребное время для задачи "Исправить баг номер 184, заключающийся в вылете access violation в случайный момент времени с периодом полураспада около 10000 часов"?
SED>Поделюсь опытом и надеюсь он будет полезен. Сейчас у меня таких ошибок не появляется вообще! Как этого добиться? Проанализируйте решения этих ошибок. У меня получилось следующее:

SED>1. Низкое качество кода. Решается вообще без проблем — иногда очень быстро
Низкое качество кода это неверное понятие. Код не может быть Низкокачественным, высококачественным, инакокачественным, код может быть красивым, может быть оптимальным, может быть траспортируемым, может быть на языке Мю, а низкокачественными могут быть помидоры, залежавшиеся с прошлого года в коморке. Выбирали бы вы выражения, когда разговариваете с людьми.

SED>2. Низкое качество сторонних компонент и библиотек. Решается использованием золотого правила — НЕ ИСПОЛЬЗУЙТЕ НЕ ПРОВЕРЕННЫЕ РЕШЕНИЕ. Я даже сейчас работаю с решениями 3 летней давности. Если возникает необходимость в новом функционале, то как минимум у двух программистов появляется в планах "Тестирование библиотеки ХХХ"(Тестеры сдесь не причем)
А при чем тогда тестеры?.. У вас их вообще нет?.. Или тестеры — это вы?

SED>3. Баги, с которыми нужно смериться или обойти. Общий процент от всего — менее 0.01. Тут все зависит от ситуации, но зачастую его компенсирует буфер, размер которого прямопропорционален новизне используемой технологии с коэффициентом k. В любом случае эта решаемая проблема и она не стоит выведенного яйца. Приведу свой пример.
Может не надо примеров? Хватит того, что проблема яйца не стоит... МТС блин...

SED> В BizTalk2004 есть одна фича, о не знании которой рядовой программис завалит все не мыслемые сроки. Я обнаружил эту фичу на втором расширении рисков (были 8 часов, потом стал 12. И последняя 16). Эту фичу я опубликовал. Из-за этой фичи больше небыло не одной задержки.
Че сказал то?... К тому же еще и неграмотно.

SED>Удачи вам в решении этих багов
И на вопрос не ответил, и нафлудил неслабо.
Молодец.

p.s. Зачем RSDN то читаешь?.. да еще через Веб. Или ты книгу пишешь?.. бабки захотелось сделать на людях?..

Здравствуйте, alex_ez, Вы писали:


_>Молодой человек, зачем вы вводите людей в заблуждение?..
Я считаю ваш пост личным Оскорблением (читайте правила) и прошу администраторо на это обратить внимание.

_>Низкое качество кода это неверное понятие. Код не может быть Низкокачественным, высококачественным, инакокачественным, код может быть красивым, может быть оптимальным, может быть траспортируемым, может быть на языке Мю, а низкокачественными могут быть помидоры, залежавшиеся с прошлого года в коморке. Выбирали бы вы выражения, когда разговариваете с людьми.
Объяснять долго не буду, но поверьте мне — земля круглая!

SED>>2. Низкое качество сторонних компонент и библиотек. Решается использованием золотого правила — НЕ ИСПОЛЬЗУЙТЕ НЕ ПРОВЕРЕННЫЕ РЕШЕНИЕ. Я даже сейчас работаю с решениями 3 летней давности. Если возникает необходимость в новом функционале, то как минимум у двух программистов появляется в планах "Тестирование библиотеки ХХХ"(Тестеры сдесь не причем)
_>А при чем тогда тестеры?.. У вас их вообще нет?.. Или тестеры — это вы?
А при том что тестеры тестируют конечный продукт! Лично у меня нет тестеров компонетов. Как, например, вы будете тестировать библиотеку загрузки весов DiGi от трех разных фирм.

SED>>3. Баги, с которыми нужно смериться или обойти. Общий процент от всего — менее 0.01. Тут все зависит от ситуации, но зачастую его компенсирует буфер, размер которого прямопропорционален новизне используемой технологии с коэффициентом k. В любом случае эта решаемая проблема и она не стоит выведенного яйца. Приведу свой пример.
_>Может не надо примеров? Хватит того, что проблема яйца не стоит... МТС блин...
ну — ну

SED>> В BizTalk2004 есть одна фича, о не знании которой рядовой программис завалит все не мыслемые сроки. Я обнаружил эту фичу на втором расширении рисков (были 8 часов, потом стал 12. И последняя 16). Эту фичу я опубликовал. Из-за этой фичи больше небыло не одной задержки.
_>Че сказал то?... К тому же еще и неграмотно.
Без комментариев
SED>>Удачи вам в решении этих багов
_>И на вопрос не ответил, и нафлудил неслабо.
_>Молодец.

_>p.s. Зачем RSDN то читаешь?.. да еще через Веб. Или ты книгу пишешь?.. бабки захотелось сделать на людях?..

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

Здравствуйте, SEDEGOFF, Вы писали:

SED>Здравствуйте, Vinni-puh, Вы писали:

SED>Проанализируйте решения этих ошибок. У меня получилось следующее:
SED>1. Низкое качество кода.
SED>2. Низкое качество сторонних компонент и библиотек.
Сколько смог вспомнить, подобные трудноуловимые баги у меня возникали именно по этой причине.

SED>Решается использованием золотого правила — НЕ ИСПОЛЬЗУЙТЕ НЕ ПРОВЕРЕННЫЕ РЕШЕНИЕ. Я даже сейчас работаю с решениями 3 летней давности. Если возникает необходимость в новом функционале, то как минимум у двух программистов появляется в планах "Тестирование библиотеки ХХХ"(Тестеры сдесь не причем)
Самое печальное, что эти баги проявляются только при эксплуатации (по условию задачи период полураспада 10000 часов), после того, как сторонняя библиотека уже крепко вросла в проект. А выделить такие ресурсы, как двух программистов, занимающихся тестированием библиотеки, мы к сожалению не можем. Накладно.

SED>3. Баги, с которыми нужно смириться или обойти. Общий процент от всего — менее 0.01.
Ну, по-моему 0.01 — это тоже немало. Хотя иногда так всё и кончается.

Здравствуйте, Vinni-puh, Вы писали:

VP>Самое печальное, что эти баги проявляются только при эксплуатации (по условию задачи период полураспада 10000 часов), после того, как сторонняя библиотека уже крепко вросла в проект.
Согласен, это грустно. Но вы же сейчас можете оценить сколько еще бед она вам принесет? И, например, что буде выгодней сейчас потратить 100 часов на ее "искоренение" или в течении 2 следующих лет потратить 200 часов. Повторюсь — это пример. Потому как в реальной жизни, например, выгодней будет потратить 200 часов из за того что заказчик не даст 100 часов сейчас и выставит неустойку которая не оправдает этих затрат. С другой стороны есть такое правило — сначало исправляем ошибки, потом идем дальше.
VP>А выделить такие ресурсы, как двух программистов, занимающихся тестированием библиотеки, мы к сожалению не можем. Накладно.
Можно тоже оценить затраты на будующее. Что выгодней сейчас потратить время на проверку или потом "бороться". А вообще лучше день потерять, а потом за пять минут долететь


SED>>3. Баги, с которыми нужно смириться или обойти. Общий процент от всего — менее 0.01.
VP>Ну, по-моему 0.01 — это тоже немало. Хотя иногда так всё и кончается.
Если не вести историю по таким фичам, то это просто огромное значение. Ну а если у вас все ходы записаны, то все решается быстро. За исключение нахождения новых, не задокументированных фич

Здравствуйте, alex_ez, Вы писали:

_>Скажу я вот что, и буду прав.

Это не тебе решать Критерий истины — практика (с)

_>Планирование — должно быть.
_>План — нет.

валяюсь на полу...

_>А я не хочу организововаться, и хоть дерьмом ты меня корми, план на меня никак не повлияет. А теория — она и есть теория.

Вот именно. Безответственные люди как раз и не хотят организовываться, чтобы не нести ответственность.

_>Программирование — это творчество. Представьте себя художником, перед которым поставили задачу нарисовать портрет и дали план: нужно в такие то сроки нарисовать руки, в такие то — ноги, потом туловище, ну и голову в конце. Помоему, это чистой воды бред.

И где бред? Мой знакомый художник рисует картины и портреты на заказ, и легко называет сроки исполнения. И творчества в рисовании портрета нет никакого.

Никто в здравом уме не поставит успех проекта в зависимость от твоего "творчества". Думаешь, если тебя муза посетит, то проект удастся, а если нет, то не удастся? Программистам ставят задачи, с которыми они точно справятся. Если с чем-то есть риск не справиться, то задача формулируется по-другому, "исследовать возможность сделать это".

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

Здравствуйте, Кодёнок, Вы писали:

_>>Скажу я вот что, и буду прав.
Кё>Это не тебе решать Критерий истины — практика (с)
Это не тебе решать Критерий истины — практика. (с)
))))))

_>>Планирование — должно быть.
_>>План — нет.
Кё> валяюсь на полу...
Ты пол моешь?.. Вставай и читай оригинал до просветления

_>>А я не хочу организововаться, и хоть дерьмом ты меня корми, план на меня никак не повлияет. А теория — она и есть теория.
Кё>Вот именно. Безответственные люди как раз и не хотят организовываться, чтобы не нести ответственность.
А теория — она и есть теория.

_>>Программирование — это творчество. Представьте себя художником, перед которым поставили задачу нарисовать портрет и дали план: нужно в такие то сроки нарисовать руки, в такие то — ноги, потом туловище, ну и голову в конце. Помоему, это чистой воды бред.
Кё>И где бред? Мой знакомый художник рисует картины и портреты на заказ, и легко называет сроки исполнения. И творчества в рисовании портрета нет никакого.
Это не художник. Это фотограф какойто.

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

p.s. давайте по делу, если есть факты — то их и говорим, если нету — не надо писать поемы про художников, которые четко знают, когда закончат, с которыми нельзя будет поспорить за неимением локально аналогов.

Здравствуйте, alex_ez, Вы писали:

_>p.s. давайте по делу, если есть факты — то их и говорим, если нету — не надо писать поемы про художников, которые четко знают, когда закончат, с которыми нельзя будет поспорить за неимением локально аналогов.

А это я тебе не факт привел?

Здравствуйте, Кодёнок, Вы писали:

_>>p.s. давайте по делу, если есть факты — то их и говорим, если нету — не надо писать поемы про художников, которые четко знают, когда закончат, с которыми нельзя будет поспорить за неимением локально аналогов.
Кё>А это я тебе не факт привел?
приводи _достоверные_ факты, пожалуйста. а не про "гагарина".

Здравствуйте, alex_ez, Вы писали:

_>>>p.s. давайте по делу, если есть факты — то их и говорим, если нету — не надо писать поемы про художников, которые четко знают, когда закончат, с которыми нельзя будет поспорить за неимением локально аналогов.
Кё>>А это я тебе не факт привел?
_>приводи _достоверные_ факты, пожалуйста. а не про "гагарина".

Достоверный это какой? Этот чем не достоверен?