Управление большим числом задач в проектах по разработке прогррамного обеспечения — 0

(Из ленты 255 ступеней)

А что значит большим? Или как справшивала мартышка из “38 попугаев”: что такое куча? Вот десять — это куча? И отличается ли управление большим числом мелких задач от управления малым числом больших задач? А большая задача это сколько? Есть масса вопросов. Но если постоянно не задавать эти вопросы и не отвечать на них, то будут получаться мертворожденные схемы, которые работают только в теории.

В теории между теоррией и практикой нет никакой разницы. На практике же разница огромна.

Столяр пользуется множеством инструментов. Он не пытается закручивать гвозди рубанком. И не пытается вырезать пазы шурупом. Чем мы хуже? Почему мы пытаемся применить SCRUM там, где он не применим? Управление разработкой ПО — это огромная мозаика. Ее можно складывать сразу из нескольких мест и совсем не обязтельно слева направо. Науку управления не обязательно учить по схеме PMBoK. В любом случае однуи ту же тему придется пройти несколько раз, рассматривая ее с разных аспектов.

ГОСТ 34.603 (виды испытаний автоматизированных систем) вполне применим. В определенных ситуациях. И ГОСТ 9126 (характеристики качества и руководства по их применению) тоже применим. В других ситуацих. Но есть ещ и третья ситуация, когда отличным вариантом будет не XP или RUP, а ГОСТ Р 50779.42 (контрольные карты Шухарта) от 99 года.

Я попробую разложит свой опыт на цикл статей. в каждой из которых осветить маленький аспект управления. Управления не обязательно проектами. Возможно управления процессами. Или НИР-ами. Короче, разработкой ПО.

Источник: Управление большим числом задач в проектах по разработке прогррамного обеспечения — 0