Что согласно статистическим исследованиям, приведет к снижению производительности в 1.5 - 2 раза. Смотри книгу "Peapleware"

Это книга Демарко?

У Голдратта в "Критической цепи" приведено теоретическое обоснование для этих наблюдений.

А можешь приблизительно указать место в книге где находится это обоснование?
Какая глава хотя бы, хочется внимательно перечитать

>> Эта система позволяет постоянно держать нагрузку на все звенья разработки.
Что согласно "теории ограничений" совсем не хорошо.

Ну почему же?
Согласно теории ограничений всегда есть более слабое звено, этого не избежать.
Ну это же не значит что надо работать в полсилы? Тогда получится что более сильные звенья еще меньше нагружены.
Просто надо выполняя работу, параллельно искать и укреплять самое слабое звено.

Что согласно статистическим исследованиям, приведет к снижению производительности в 1.5 - 2 раза. Смотри книгу "Peapleware". У Голдратта в "Критической цепи" приведено теоретическое обоснование для этих наблюдений.

Что согласно "теории ограничений" совсем не хорошо.

Да,  согласен. с точки зрения Голдратта, это не верно, но следует заметить, что в своих книгах Цель и Цель-2 он описывает непосредственно решение проблем, а если проблема не возникла и не появилось этих "бутылочных горлышек", то вполне применимо.
Замечу, что в этой идее (кстати работает на практике) "параллельная" (с тестированием) разработка идет по менее критичным задачам, т.е. задачи, реализация которых может быть отложена на какой-то срок. Программисты продолжают разработку критичных задач, когда ресурс тестировщика освободился.
За книгу огромное спасибо!

В упомянутом "Методе анализа иерархий" предлагается придумать какие-то критерии, назначить им коэффициенты, и т.д. В итоге получим числовую оценку "критичности".
То есть предлагается какой-то формальный подход.

В данном случае (мое мнение) тут указано скорее формализация уже оцененных задач, а не методика оценки.

А вы как делаете такие оценки?

Вот это и является самым сложным)))
Тут, наверное, сложно представить какой-то единоверный механизм. Оценка осуществляется непосредственно в зависимости от проекта и ожидаемых результатов проекта.
Т.е. Если проект по разработке нового обособленного модуля/системы, тогда наиболее приоритетными задачами явно будут те, выполнение которых позволит достичь целей этой системы/модуля, а наименее приоритетными будут удобство, аналитика, отчетность.
Если же разрабатываемый модуль(система) напрямую зависит от существующих систем, тогда лично я ставлю в приоритет интеграцию (т.е. получение данных из вне), а уже потом функциональность самой системы  .... и т.п.

Так же, в принципе, будет действовать и ребенок в вашем примере - если критичность похода в школу превышает критичность больного зуба (например четвертная контрольная работа и родители потом идут на родительское собрание) тогда школа... (хотя с детьми все гораздо сложнее).

Вы говорите о "критичности" "приоритетности" и "трудоемкости".
Из них "критичность" и "приоритетность" - это уже результат оценки задачи, это не "первичные" признаки задач.

Я "критичность" и "приоритетность" изначально стараюсь получить от заказчика (оговорюсь - самыми низкоуровневыми задачами стараюсь заказчика не грузить), потом совместо с заказчиком просматриваем его оценку, обсуждаем и не редко часть задач меняет свою первоначальную оценку. Естественно, что по части задач мы периодически проводим переоценку и актуализацию. Но у меня не было такого большого числа задач сразу (они всегда появлялись по-ходу разработки) и может быть я не сталкивался с аналогичной проблемой.

Попробую ответить в одном посте.
1.
"Peapleware" Том ДеМарко, Тимоти Листер - http://www.ozon.ru/context/detail/id/2338486/ Книги под ракой нет, но ЕМНИП это примерно 70-80 стр, слева.

2.

А можешь приблизительно указать место в книге где находится это обоснование?
Какая глава хотя бы, хочется внимательно перечитать

Размазано на несколько глав. Из-за особенностей нашего мышления, лучше перечитать полностью. Конкретное место можно найти по словосочетанию "студенческий синдром". ЕМНИП.

PS. если хотите разобраться с проблемами  мышления и почему нужно перечитать полностью, рекомендую:
http://lesswrong.ru/w/%D0%97%D0%B0%D0%BF%D0%B0%D1%81%D1%91%D0%BD%D0%BD%D1%8B%D0%B5_%D0%BC%D1%8B%D1%81%D0%BB%D0%B8
и
http://lesswrong.ru/w/%D0%9A%D0%B0%D0%BA_%D0%BA%D0%B0%D0%B7%D0%B0%D1%82%D1%8C%D1%81%D1%8F_%D0%B8_%D0%B1%D1%8B%D1%82%D1%8C_%D0%B3%D0%BB%D1%83%D0%B1%D0%BE%D0%BA%D0%BE%D0%BC%D1%8B%D1%81%D0%BB%D0%B5%D0%BD%D0%BD%D1%8B%D0%BC

3.

Ну почему же?
Согласно теории ограничений всегда есть более слабое звено, этого не избежать.
Ну это же не значит что надо работать в полсилы? Тогда получится что более сильные звенья еще меньше нагружены.

Нет. Здесь есть несколько моментов. И почти все они противоречат нашим "запасенным мыслям".
* ограничение системы должно быть нагруженным. Остальные рабочие центры обязаны работать "неэффективно". Попытки заставить неограничения системы работать максимально эффективно следует пресекать. Именно поэтому я резко против KPI.
* Если ограничение системы находится вне фирмы, то все отделы обязаны работать "неэффективно".

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

Э-э-э... Все сильно сложнее. Различают минимум три варианта: "уникальность"; "Наибольшая трудоемкость"; "наилучшая управляемость".

4.

а если проблема не возникла и не появилось этих "бутылочных горлышек", то вполне применимо.

Это невозможно. В принципе невозможно. В караване всегда есть самый медленный корабль.

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


-------------------------
Если есть желание, можно устроить обсуждение вживую или по скайпу. Так мне будет проще ответить на все вопросы.
Я тут прикинул во время прогулок (это около 10 часов размышлений). что чтобы ответить на изначальный вопрос обсуждения, мне нужно написать порядка 30 000 слов. Это явно не пост в форуме. Ах, да, а потом это должно пройти проверку и знатоков ТОС, психологии, теории вариаций и т.д.

Давайте я вам порекомендую одну из своих статей по нескольким методам управления задачами в зависимости от типа производственно потока V.A.T.I. Статья не сильно простая, что делать. Управление штука сложная.
Форд, Тойота и морские свинки

Но ведь у вас же не тысяча исполнителей, вы же не можете сразу все задачи кому-то назначить.

Около сотни - программистов, художников, продюсеров, менеджеров и QA-инженеров.

И вот здесь начинается самое интересное, именно этого и касается мой вопрос.
Значит нужно из всех задач (как вы пишете - из десятков тысяч) выбрать именно те, которые наиболее актуальны на данный момент.
Как вы делаете этот отбор? По каким признакам вы отбираете первоочередные задачи? Вот это меня интересует.

Работа над задачами ведётся в рамках версии. Каждая версия приложения - отдельный продукт. У продукта есть концепция. Продукт предназначен для определённых рынков и сегментов. Поэтому из ключевых фич (100 - 200 штук) делается выбор в соответствии с пониманием того, на какой рынок будет выпущен продукт, и для каких сегментов он будет предназначен.

Далее отобранные фичи прорабатываются продюсерами/бизнес-аналитиками, готовится детальный дизайн-документ, составляется список фич в виде:

Feature - Sub-Feature - Sub-Feature Element.

Делается грубая оценка проекта. Далее выполняется техническое планирование, прорабатывается технический дизайн, выбираются технологии для реализации фич, создаётся перечень технических задач (количество которых может доходить до нескольких тысяч). Выполняется детальная оценка проекта. Каждая техническая задача не должна занимать меньше 4-х и больше 24-х часов.

По результатам оценки уточняется таймлайн проекта, даты майлстоунов. Делается распределение фич и подфич по спринтам. Уточняется количество ресурсов, которые необходимо привлечь на проект для выпуска продукта в срок.

Как вы распределяете нагрузку?
Есть какой-то подход? Или просто хаотично?

Выполняется нагрузочное планирование (capacity planning). Создаётся детальный план, который учитывает объём работы, имеющиеся ресурсы и длительность проекта. Имеющиеся технические задачи распределяются между сотрудниками. План обновляется для каждого майлстоуна, т.к. входе работы над проектом ситуация может меняться. Учитывается overhang для всей команды. Если сильно не успеваем, то некоторые фичи могут быть отменены.

Работа над задачами ведётся в рамках версии. Каждая версия приложения - отдельный продукт. У продукта есть концепция. Продукт предназначен для определённых рынков и сегментов. Поэтому из ключевых фич (100 - 200 штук) делается выбор в соответствии с пониманием того, на какой рынок будет выпущен продукт, и для каких сегментов он будет предназначен.

Далее отобранные фичи прорабатываются продюсерами/бизнес-аналитиками, готовится детальный дизайн-документ, составляется список фич в виде:

Feature - Sub-Feature - Sub-Feature Element.

Делается грубая оценка проекта. Далее выполняется техническое планирование, прорабатывается технический дизайн, выбираются технологии для реализации фич, создаётся перечень технических задач (количество которых может доходить до нескольких тысяч). Выполняется детальная оценка проекта. Каждая техническая задача не должна занимать меньше 4-х и больше 24-х часов.

По результатам оценки уточняется таймлайн проекта, даты майлстоунов. Делается распределение фич и подфич по спринтам. Уточняется количество ресурсов, которые необходимо привлечь на проект для выпуска продукта в срок.

Выполняется нагрузочное планирование (capacity planning). Создаётся детальный план, который учитывает объём работы, имеющиеся ресурсы и длительность проекта. Имеющиеся технические задачи распределяются между сотрудниками. План обновляется для каждого майлстоуна, т.к. входе работы над проектом ситуация может меняться. Учитывается overhang для всей команды. Если сильно не успеваем, то некоторые фичи могут быть отменены.

Очень нравится подход. Это сильно лучше того, что часто встречается. Т.е. на мой взгляд это дает очень серьезные преимущества. Если еще и проверка полноты атомарных задач поставлена на уровне, то ... мои аплодисменты. Это круто.

PS. Я бы не стал делать нижнюю грань трудоемкости для атомарной задачи. Но это обсуждаемо. Может я и не прав.
Верхняя очень близка к тому что я стараюсь использовать. Я бы сказал полнедели и добавил бы еще два условия: атомарная задача это не более одного исполнителя и не более одной информационной системы. Опять же обсуждаемо.

PSS. Это скорее техническое замечание. Мелкое.
> Feature - Sub-Feature - Sub-Feature Element.
Это один из видов классификации. Я бы предпочел фасетную классификацию. Понимаю, что сильно сложнее, поэтому не готов рекомендовать для всех. Скорее всего, ваш способ лучше для вас и для многих других.
-----------------------
Может рекомендации Кирилла в FAQ вынести? Достаточно стройно. Что скажете комрады?

Коллеги, подолью масло в огонь и раскрою немного ответы Сергея по ТОС:
http://www.tocpeople.com/2014/10/10-oshibok-upravleniya-proektami/

Угу. И в 10 пункте есть ключевое утверждение, которое почти все, всегда пропускают. И совершенно неизбежно получают плохое управление большим количеством задач.

PSS. Это скорее техническое замечание. Мелкое.
> Feature - Sub-Feature - Sub-Feature Element.
Это один из видов классификации. Я бы предпочел фасетную классификацию. Понимаю, что сильно сложнее, поэтому не готов рекомендовать для всех. Скорее всего, ваш способ лучше для вас и для многих других.

Можно поподробнее про фасетную классификацию?
Как лучше классифицировать задачи?

Можно поподробнее про фасетную классификацию?
Как лучше классифицировать задачи?

На мой взгляд, нет наилучшей классификации вообще. Бывает наилучшая классификация для решения какой-то конкретной задачи. Какую задачу Вы хотите решить?

Приведу пример. Упомянутая мною классификация Feature -> Sub-Feature -> Sub-Feature Element упрощает оперирование фичами проекта и помогает составлять план версии и планы на майлстоун. Если различных sub-feature элементов может быть сотни или тысячи, то количество фич - несколько десятков или сотен. Благодаря иерархии сокращается количество элементов, которые нужно держать в поле зрения.

Аналогичным образом, при разработке приложения с большим количеством экранов уменьшить количество задач, которое нужно держать в "оперативной памяти", может помочь такая классификация: Mode -> Screen Flow -> Screen -> Screen Element.

Более детально написал в статье - http://megamozg.ru/post/11550/

Работа над задачами ведётся в рамках версии. Каждая версия приложения - отдельный продукт. У продукта есть концепция. Продукт предназначен для определённых рынков и сегментов. Поэтому из ключевых фич (100 - 200 штук) делается выбор в соответствии с пониманием того, на какой рынок будет выпущен продукт, и для каких сегментов он будет предназначен.

Далее отобранные фичи прорабатываются продюсерами/бизнес-аналитиками, готовится детальный дизайн-документ, составляется список фич в виде:

Feature - Sub-Feature - Sub-Feature Element.

Делается грубая оценка проекта. Далее выполняется техническое планирование, прорабатывается технический дизайн, выбираются технологии для реализации фич, создаётся перечень технических задач (количество которых может доходить до нескольких тысяч). Выполняется детальная оценка проекта. Каждая техническая задача не должна занимать меньше 4-х и больше 24-х часов.

По результатам оценки уточняется таймлайн проекта, даты майлстоунов. Делается распределение фич и подфич по спринтам. Уточняется количество ресурсов, которые необходимо привлечь на проект для выпуска продукта в срок.

Выполняется нагрузочное планирование (capacity planning). Создаётся детальный план, который учитывает объём работы, имеющиеся ресурсы и длительность проекта. Имеющиеся технические задачи распределяются между сотрудниками. План обновляется для каждого майлстоуна, т.к. входе работы над проектом ситуация может меняться. Учитывается overhang для всей команды. Если сильно не успеваем, то некоторые фичи могут быть отменены.

Какими инструментами вы пользуетесь для выполнения всех этих работ?

Если есть желание, можно устроить обсуждение вживую или по скайпу. Так мне будет проще ответить на все вопросы.
Я тут прикинул во время прогулок (это около 10 часов размышлений). что чтобы ответить на изначальный вопрос обсуждения, мне нужно написать порядка 30 000 слов. Это явно не пост в форуме. Ах, да, а потом это должно пройти проверку и знатоков ТОС, психологии, теории вариаций и т.д.

Желание есть огромное.
Только как его осуществить? Я живу не в Москве - в регионе.
Давайте по скайпу

Я бы предпочел фасетную классификацию.

Какое ПО позволяет делать фасетную классификацию задач?