Тред №370826

Цитата: НАлЕ
А по каким результатам? Да, это год можно считать неудачным, аварийность таки повышенная: ФГ загнулся, Прогресс упал (ну этому-то и пора уж было хоть раз) ... . А ГЛОНАСС функционирует в полном объеме, Радиоастрон работает, Союз "прописался" на Гвиане. Всего в 2011 году произведено 29 пусков

началось всё с ФГ. я не говорил что полохо всё.

ЦитатаТам же про итерации говорилось и в конце каждой итерации продукт считается готовым.
Да ЖРД отрабатывается по частям (камера, ТНА, зажигание и пр ...) и там тоже идет отслеживание взаимного влияния каждого элемента на "соседние".

где там написано что продукт считается готовым не вижу. вижу "Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации." но кроме того "Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование." т.е. продукт готов по итогам данной итерации.
если все задачи итерации решены. и можно переходить к следующей итерации и так до победного конца.
к тому же "Подход Agile к управлению требованиями не подразумевает далеко идущих планов (по сути управление требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно, в конце каждой итерации, выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим "авралам" с массовым рефакторингом и переделками практически на каждой очередной итерации."

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

к тому же, чтобы вы так буквально не рассматривали, можно разработать свой тех процесс. который будет учитывать особенности разработки АМС или отдельных частей той АМС (например туже двигательную установку).

Цитата
Сетевой график, который постоянно отслеживается и корректируется (при необходимости). А как разбить на итерации процесс разработки топливного отсека, например?

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

ЦитатаИменно так всю жизнь и делается. Любая работа начинается с разработки план-графика работ.

ессно, так и делается. это была часть ответа на ваши вопросы насчёт законченного продукта.
ау всётаки лучше снять. а то разговор наш канет в лету а я дело говорю  ;)

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

я про комплексный подход к введению уловной новой методики разработок. на всех этапах и на всех уровнях.

Цитата"Все украдено до нас": Заказчик - Головной исполнитель - Смежные предприятия (подразделения).
(см.scrum)

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

ЦитатаНу да, а Вы думаете, что в остальное время эта орава "бездельников" (а их чуть-ли не больше, чем непосредственно конструкторов и расчетчиков) ни хрена не делает, а только ждет, когда их пригласят водки попить "на приемку изделия"?

ну вы наговорили тут. а помимо работы водку пить религия не позволяет?
под куратором я подразумевал Владелец Продукта (Product Owner)
так вот он сам или его представитель (тот кто в курсе как _надо_ сделать не хуже самого) каждый день, каждый на своём уровне приходит в команду и выясняет все ли понимают что нужно сегодня сделать и отвечает на вопросы от команды. кстати эти встречи так и называются - scrum. можно их назвать планёркой, летучкой как угодно. главное чтобы смысл дошёл. и это не ради галочки или проформы делается.

ЦитатаТакие проблемы возникают из-за неудовлетворительной работы "головников"

по разной причине могут быть такие проблемы. тут важно вовремя проблему обнаружить и решить.

ЦитатаКак все сразу и на одном совещании, или все-таки партиями по паре-тройке сотен человек?

а у вас что, в одной группе которая исполняет конкретную задачу сразу от 100 человек?  :D

ЦитатаИ что тут нового?

тут ничего, но это слагаемое будущего успеха  :)

ЦитатаЕму и не надо. Более того, зачастую он и не имеет права видеть дальше своего носа.

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

ЦитатаВы согласны, что процесс разработки массовой легковушки и 8-осного "ракетовоза" - это весьма разные процессы?

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

ЦитатаА в чем я путаю? В отличие от , допустим, автомобиля, в РКТ практически любой "винтик" может оказаться критичным для работоспособности "изделия".

в том что речь идёт о подходе к разработке а не о условиях эксплуатации.

ЦитатаПравильнее будет так: никто не должен кормить. Что касается "Лавки", то выводы будут и не только по ней, но и по Роскосмосу и по всей "своре" смежников.

надеюсь разум возобладает

ЦитатаPS. Все, что Вы тут высказали, все это (или почти все) правильно, но это все разговор на тему "как должно быть" ( а это , в принципе, давно известно), а сейчас важнее тема" как сделать так, чтобы все было, как должно быть".

понятно что всё должно быть хорошо и правильно
я просто попытался навести на мысли как можно улучшить положение с менеджментом