ИМХО. Что действительно хорошо в ХП так это юнит тесты и парное программирование. ну и еще запрещение овертаймов. Хотя это врядли строго ХПшная практика. Юнит тесты и парное программирование по сути дают возможность серьезно выграть на отладке. Не более но и не менее. возводить какуюбытгонибыло методологию в абсолют глупо.

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

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

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

привет!
Реально, этому учат — курсов масса, вот к примеру те, на которые сам ходил или своих подчиненных посылал:
http://www.sep.russee.com/

Если точно отмечать, то тут стоит посмотреть на
"Человеческий фактор в разработке ПО" и "Управлеение командами разработчиков" (последний уже прошел и в Питере и Москоу и поа планируется только в СПб — стоит спросить их — когда)

А вообще, кто-нибудь на тренинги ходит или только большие компании да крези по типу меня их туда таскают?

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

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

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

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

Здравствуйте, Аноним, Вы писали:

А>Реально, этому учат — курсов масса, вот к примеру те, на которые сам ходил или своих подчиненных посылал:
А>http://www.sep.russee.com/
А>"Человеческий фактор в разработке ПО" и "Управлеение командами разработчиков" (последний уже прошел и в Питере и

Посмотрел описание курса "Человеческий фактор в разработке ПО" (вот ссылка: http://www.russee.com/index.phtml?aid=30020515). Кроме смеси и так известных психологических методик, тестов и т.п. ничего не нашел.

Хотелось бы прояснить такие вопросы:

1) Курс содержит только краткое изложение различных психологических методик или конкретные управленческие приемы?

2) Если в курсе излагаются управленческие приемы, то чем они отличаются от приемов, изложенных в популярных книжках по управлению? Например, в книжках Дейла Карнеги, В. Тарасова и т.д.?

3) Есть ли конкретные примеры применения этих приемов в области разработки софта. Если такие примеры есть, то сколько? Несколько единиц? Или несколько десятков?

4) Есть ли среди примеров нетривиальные? Сколько?

5) Какие управленческие задачи способны решать изложенные приемы?

6) Сколько из этих задач являются актуальными для ПМов?

7) К каким качественным уровням относятся эти задачи? Т.е. грубо говоря, рассказывается ли о том, как внедрить в команде отдельные процедуры (планирование, отчетность)? Или рассказывается о том, как поставить и наладить технологический процесс по разработке качественного ПО, который бы продержался без существенных изменений 5 — 7 лет?

8) Есть ли у авторов курса открытые публикации, в которых изложены некоторые (не все!) приемы, и по которым можно судить о качестве курса?

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

_>Че пристал?..
_>Работай как привык!
_>Я же не против


Да, хамство прям прёт

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


_>Для хорошей отдачи от XP — нужно пользоваться ВСЕМИ практиками XP сразу. Использование некоторых из практик XP — не дадут нужного результата, а часто сделают его хуже. (c) Brooks, кажется.


Назови хоть один проект, который так делал и закончился успешно ($ принёс и работает)?

D В жизни главное умеренность, а экстремальность тока всё портит

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

SED> Ставьте очень мелко дроблёные задачи. Это наиболее важная часть в вашей работе по составлению плана. Ваши задачи должны измеряться в часах, а не в днях.

Это позиция крайне неопытного менеджера.

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

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

SED>> Ставьте очень мелко дроблёные задачи. Это наиболее важная часть в вашей работе по составлению плана. Ваши задачи должны измеряться в часах, а не в днях.

E>Это позиция крайне неопытного менеджера.
Почему? Оглядываясь назад и сравнивая результаты, я понимаю что человек говорит дело. Во всяком случае у меня так и было — сначала дни — потом часы.

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


SED>>> Ставьте очень мелко дроблёные задачи. Это наиболее важная часть в вашей работе по составлению плана. Ваши задачи должны измеряться в часах, а не в днях.
E>>Это позиция крайне неопытного менеджера.
SED>Почему? Оглядываясь назад и сравнивая результаты, я понимаю что человек говорит дело. Во всяком случае у меня так и было — сначала дни — потом часы.

Совершенно очевидно, что план может и должен меняться. Если дробить задачи слишком мелко, поддержка плана в здоровом состоянии может превратиться в самоцель, т.е у Вас на это будет уходить слишком много времени, или план быстро перестанет отражать реальную ситуацию. Это время, по моему опыту, лучше посвящать комуникациям с командой.

E>Совершенно очевидно, что план может и должен меняться. Если дробить задачи слишком мелко, поддержка плана в здоровом состоянии может превратиться в самоцель, т.е у Вас на это будет уходить слишком много времени, или план быстро перестанет отражать реальную ситуацию. Это время, по моему опыту, лучше посвящать комуникациям с командой.
А кто-же будет дробить план на мелкие задачи? Конкретный исполнитель? Но кто поручится, что он сделает это?

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

E>>Совершенно очевидно, что план может и должен меняться. Если дробить задачи слишком мелко, поддержка плана в здоровом состоянии может превратиться в самоцель, т.е у Вас на это будет уходить слишком много времени, или план быстро перестанет отражать реальную ситуацию. Это время, по моему опыту, лучше посвящать комуникациям с командой.
N_C>А кто-же будет дробить план на мелкие задачи? Конкретный исполнитель? Но кто поручится, что он сделает это?

А зачем вообще дробить его на мелкие задачи?

E>А зачем вообще дробить его на мелкие задачи?
Для того, чтобы более точно рассчитать время на реализацию той или иной задачи. Чем мельче задача, тем это сделать проще, чем она крупнее, тем расчет времени менее точен.

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

E>>А зачем вообще дробить его на мелкие задачи?
N_C>Для того, чтобы более точно рассчитать время на реализацию той или иной задачи. Чем мельче задача, тем это сделать проще, чем она крупнее, тем расчет времени менее точен.

Кому проще? Кто у вас оценивает задачи?

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

E>>А зачем вообще дробить его на мелкие задачи?
N_C>Для того, чтобы более точно рассчитать время на реализацию той или иной задачи. Чем мельче задача, тем это сделать проще, чем она крупнее, тем расчет времени менее точен.

А время на интеграцию результатов этих мелких задач в одно целое как тогда рассчитывать?

E>Кому проще? Кто у вас оценивает задачи?
Скажем так... Оценка осуществляется совместно с непосредственным исполнителем. Самому исполнителю и проще.

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

SED>>> Ставьте очень мелко дроблёные задачи. Это наиболее важная часть в вашей работе по составлению плана. Ваши задачи должны измеряться в часах, а не в днях.
E>>Это позиция крайне неопытного менеджера.
SED>Почему? Оглядываясь назад и сравнивая результаты, я понимаю что человек говорит дело. Во всяком случае у меня так и было — сначала дни — потом часы.

А это вообще реально? Вот у меня часть проекта — написать сервер. Я сам хз какие там подзадачи, да мне и не нужно вникать в это. Я знаю что программист сам легко это сделает, он уже не один сервер написал; я просто описал задачу и он сделал, по времени уложился. Как тут дробить и зачем мне вообще лезть в его работу?

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

E>>Кому проще? Кто у вас оценивает задачи?
N_C>Скажем так... Оценка осуществляется совместно с непосредственным исполнителем. Самому исполнителю и проще.

Очень хорошо, что с исполнителем. Но выходит, что Вы считаете, что лучше исполнителя представляете, как именно и в какой последовательность реализовывать эту (более крупную) задачу? Не пытаетесь ли Вы тем самым делать часть чужой работы? (technical/team lead'a и самого исполнителя)? Уверены ли Вы, что сделаете эту работу заведомо лучше их?

Кё>А время на интеграцию результатов этих мелких задач в одно целое как тогда рассчитывать?
Я же не предлагаю дробить системы на подсистемы. Я предлагаю дробить высокоуровневые задачи на более мелкие.
Здесь далеко не всегда возникает задача интеграции. А если и возникает, то от нее никуда не денешься и в той
ситуации, когда задачу не раздробили. Все равно исполнитель для себя будет задачу дробить.

Кё>А это вообще реально? Вот у меня часть проекта — написать сервер. Я сам хз какие там подзадачи, да мне и не нужно вникать в это. Я знаю что программист сам легко это сделает, он уже не один сервер написал; я просто описал задачу и он сделал, по времени уложился. Как тут дробить и зачем мне вообще лезть в его работу?
И что? Исполнителю поставлена общая задача и выделено общее время. Что и как он делает внутри этого времени — Вы не видите и не оцениваете. Он заболел, ушел в отпуск, уволился и т.п. и работа встает, пока следующий исполнитель не оценит сделанной работы и сколько еще осталось. Раздробить работу на нескольких исполнителей тоже не представляется возможным. В общем и целом Вы или целиком перекладываете оценку времени работы на исполнителя (и оказываетесь в заложниках конкретного исполнителя) или ставите свои планы, рискуя нарваться на то, что исполнитель не сможет решить эту задачу за отведенное время.

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

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

Откуда вы взяли, что при этом неизвестны сроки готовности?
При экстремальном планировании оцениваются сроки реализации историй в идеальных неделях. Если поделить их на скорость команды, вы получите реальный срок.