Обсуждение космических программ
9,138,635 41,202
 

  перегрев ( Слушатель )
13 дек 2011 21:41:10

Тред №370707

новая дискуссия Дискуссия  107

Свои две копейки, по поводу позорно мной пропущенной дискуссииУлыбающийся
Во-первых - респект уважаемому Stalky за очень точную, ясную, и на мой взгляд, безупречную формулировку.
Во-вторых - привычный респект уважаемому НАлЕ, за точное и детальное понимание ситуации, толерантность и понимание. И просьба убрать АУ.
Ну и собственно два слова уважаемому kostroma. Видите ли дело в том, что попытки создать некую, абсолютно универсальную методику управления предпринимались неоднократно. Равно как и попытки распространить некоторые успешные прецеденты на все сразу - тоже. Результат вполне описывается известным в узких кругах анекдотом: "Достоинства конструкции - простота, надежность, технологичность. Недостатки - не работает..."Веселый
Вы меня простите, но вот этот рефрен
Цитата
Личности и их взаимодействия важнее, чем процессы и инструменты;
Работающее программное обеспечение важнее, чем полная документация;
Сотрудничество с заказчиком важнее, чем контрактные обязательства;
Реакция на изменения важнее, чем следование плану.


На жаргоне называется "лозунгом" и единственным вариантом его использования является размещение на заборе на доске объявлений. Подобные концептуальные подходы к проектированию РКТ неприменимы в принципе, потому как  они описывает принципы существующей и работающей системы проектирования, а не принципы проектирования вообще. Я Вас уверяю, что сплошь и рядом, последовательное выполнения плана (для РКТ) имеет совершенно принципиальное значение для создания надежной техники, а вот оперативная реакция  на малейшее изменение конъюнктуры - наоборот, может привести к тяжелейшим последствиям. Что мы и видим на примере  ФГ, когда для того что уложиться в директивные сроки беспощадно кромсали не только программы испытаний (уповая на "всесилие человеческого" разума в плане "на пальцах" предусмотреть все возможные ситуации) но и похоже конструкцию. К слову, я в свое время, положил немало сил, доказывая, что нельзя РК-98 в чистую применять к разработке, испытаниям и производству программного обеспечения.
P.S. Удивительно, что мы, одними и первых, создавшие и успешно использовавшие такие СМК как "самарская система",  КС УКП теперь раскрыв рот внимаем заокеанским таинствам типа ИСО 9000...
P.P.S. Stalky, не знаю как Фрегату присваивали литеру, знаю как присваивали 14Д30. Мама, не горюй! О1 и без МВИ и без МВК это надо суметь!
  • +0.62 / 5
  • АУ
ОТВЕТЫ (1)
 
 
  kostroma ( Слушатель )
14 дек 2011 13:14:55
Чертоку земля пухом. 99 лет - сильно.

Отвечу перегреву и про aglie наверно всё.

про абсолютно универсальную методику я не говорю.
по моему мнению в разработке ПО и КА есть некоторое сходство
исходя из этого можно самые здравые подходы к управлению разработкой (возможно с некоторой адаптацией) применять и в космической отрасли. возможно не на всех участках отрасли. как-то так.

ЦитатаВы меня простите, но вот этот рефренНа жаргоне называется "лозунгом" и единственным вариантом его использования является размещение на заборе на доске объявлений. Подобные концептуальные подходы к проектированию РКТ неприменимы в принципе, потому как  они описывает принципы существующей и работающей системы проектирования, а не принципы проектирования вообще.

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

ЦитатаЯ Вас уверяю, что сплошь и рядом, последовательное выполнения плана (для РКТ) имеет совершенно принципиальное значение для создания надежной техники, а вот оперативная реакция  на малейшее изменение конъюнктуры - наоборот, может привести к тяжелейшим последствиям. Что мы и видим на примере  ФГ, когда для того что уложиться в директивные сроки беспощадно кромсали не только программы испытаний (уповая на "всесилие человеческого" разума в плане "на пальцах" предусмотреть все возможные ситуации) но и похоже конструкцию.

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

в общем я сильно не настаиваю
был бы я в системе я бы поборолся
а так просто предлагаю посмотреть на различные варианты
  • -0.02 / 1
  • АУ