Comments 19
Спасибо за DSDM, т.к. нашёл там полезную инфу для своей статьи в периодическом издании)))
Теперь критика.
1. Мне кажется, не стоит умалчивать об управлении проектами в общем. Те же PMBoK, PRINCE/PRINCE2 и прочие вполне подходят и для управления ИТ-проектами. Просто различные RUP, MSF, Agile и т.д. более подробно останавливаются на отдельных специфицеских для ИТ моментах.
2. Гляньте ещё в сторону SWEBOK.
3. Есть у меня товарищ, утверждающий, что PMBoK слизан с наработок в СССР. Мне не удалось пока найти ни подтверждений, ни опровержений этого тезиса. Если бы Вам удалось что-то найти про отечественный опыт – это бы стало дополнительной «изюминкой», которую, кстати, очень любят в наших научных кругах (ИМХО – и правильно делают).
Теперь критика.
1. Мне кажется, не стоит умалчивать об управлении проектами в общем. Те же PMBoK, PRINCE/PRINCE2 и прочие вполне подходят и для управления ИТ-проектами. Просто различные RUP, MSF, Agile и т.д. более подробно останавливаются на отдельных специфицеских для ИТ моментах.
2. Гляньте ещё в сторону SWEBOK.
3. Есть у меня товарищ, утверждающий, что PMBoK слизан с наработок в СССР. Мне не удалось пока найти ни подтверждений, ни опровержений этого тезиса. Если бы Вам удалось что-то найти про отечественный опыт – это бы стало дополнительной «изюминкой», которую, кстати, очень любят в наших научных кругах (ИМХО – и правильно делают).
Есть у меня товарищ, утверждающий, что PMBoK слизан с наработок в СССР.Не совсем точный тезис. Скажем так, наука об управлении в СССР и на Западе хоть и развивались параллельно своими путями, тем не менее имеют много общего в силу одной и той же решаемой задачи. Кроме того, хорошие управленцы всегда с интересом изучают деятельность друг друга. Таким образом, одни и те же (или похожие) концепции можно найти и там и там.
Это так. Но всё-таки есть объективный критерий: кто раньше выпустил/опубликовал документ, тот и первый.
Возможно, был в СССР некий отраслевой стандарт или внутриведомственная инструкция.
Для примера (к теме не относится). Наткнулся в своё время на ОСТ 4.071.030.
Возможно, был в СССР некий отраслевой стандарт или внутриведомственная инструкция.
Для примера (к теме не относится). Наткнулся в своё время на ОСТ 4.071.030.
Но всё-таки есть объективный критерий: кто раньше выпустил/опубликовал документ, тот и первый.Верно! Но это также не значит, что второй украл идею. Хорошие идеи приходят во многие светлые головы независимо.
Возможно, был в СССР некий отраслевой стандарт или внутриведомственная инструкция.Здесь я пас. Надо бы со старшим поколением проконсультироваться.
У меня есть некоторые документы по управлению производством, которые мне оставил дед, но это большей частью конспекты, инструкции уровня предприятия и личные заметки некоторых руководителей.
PS: там ниже в комментариях пишут про ГОСТ 34.601-90
Относительно PMBoK, PRINCE/PRINCE2 — данные стандарты будут описаны в другой моей статье, посвященной международным и национальным стандартам управления информационными проектами (данную статью, которая посвящена методологиям, назвал так до этого по ошибке, уже переименовал). Что касается связи PMBoK и других стандартов, то если вам будет инересно, есть одно исследование С. Гашика, согласно которому процессы PMBOK на 95 процентов аналогичны описанным в международном стандарте по управлению проектами ISO 21500.
Помимо обычных хочется отметить, что более реалистично чем RUP применяется OpenUP т.к. его проще адаптировать под конкретный проект.
Про Agile тоже, стоит отметить, что все они стараются адаптироваться под конкретный проект, поэтому в чистом виде в конкретных проектах имеем обычно комбинации всего и SCRUM и Canban и XP. А если быть точнее лишь те элементы, которые себя хорошо покажут в конкретной команде на конкретном проекте.
Хотя для российского рынка велика вераятность разработки без внятного Т.З, по «каскадной модели» (waterfall model) или V-model.
Про Agile тоже, стоит отметить, что все они стараются адаптироваться под конкретный проект, поэтому в чистом виде в конкретных проектах имеем обычно комбинации всего и SCRUM и Canban и XP. А если быть точнее лишь те элементы, которые себя хорошо покажут в конкретной команде на конкретном проекте.
Хотя для российского рынка велика вераятность разработки без внятного Т.З, по «каскадной модели» (waterfall model) или V-model.
Меня больше интересовало не IT в целом, а разработка ПО. Поэтому несколько комментариев.
Первая методология по разработке ПО была озвучена на Symposium on advanced programming methods for digital computers: Washington, D.C., June 28, 29, 1956 автор Herbert D. Benington. Да, там был водопад.
В 1985 году вышел стандарт DOD-STD-2167А Министерства обороны США. Про него в статье не увидел.
Про ГОСТ 34.601-90, тоже в статье нет.
Ну и по XP. Это подход применялся при разработке Chrysler Comprehensive Compensation System с марта 1996, ну а книга да, вышла в 1999.
Первая методология по разработке ПО была озвучена на Symposium on advanced programming methods for digital computers: Washington, D.C., June 28, 29, 1956 автор Herbert D. Benington. Да, там был водопад.
В 1985 году вышел стандарт DOD-STD-2167А Министерства обороны США. Про него в статье не увидел.
Про ГОСТ 34.601-90, тоже в статье нет.
Ну и по XP. Это подход применялся при разработке Chrysler Comprehensive Compensation System с марта 1996, ну а книга да, вышла в 1999.
До кучи и ГОСТ 12207 нет.
ГОСТ 34 не на разработку ПО, а на разработку автоматизированных систем.
Я бы заменил слово «стандарты» на «подходы». Ну и вот какая петрушка: собственно перечень, без анализа почему управление ИТ-проектами имеет свои подходы (и исторически, и исторически в связке с развитием технологий), а не пользуется общими практиками, — как-то суховато выходит. Вот объяснений этой загадке я могу пожалуй надумать, но поверить сам в хоть одну — вряд ли :)
Еще заметил что нет Crystal, например.
Еще заметил что нет Crystal, например.
Спасибо за замечание, статья должна называться иначе (переименовал), а «Международные и национальные стандарты управления информационными проектами» называется другая моя статья. Относительно анализа обстоятельств возникновения сложившихся подходов, интересная идея, однако это уже было бы целое исследование, а это раздел из первой (теоретической) главы моей основной работы.
В качестве рекомендации автору еще посмотреть про спиральную модель, очень близкий подход к «водопаду», но тоже про него ни слова не увидел в статье. Еще как последний этап рассмотрения Agile, на мой взгляд, стоит рассмотреть сейчас SEMAT — в России сейчас активно развивается. как и на Западе.
Довольно много IT команд используют канбан. Возможно стоит рассмотреть.
В статье не хватает выделенных разделов
Непонятно, что такое «информационный проект». Издание Большой Советской Энциклопедии — это информационный проект или нет?
Целью статьи является лишь перечисление методологий в хронологическом порядке? Без анализа данная статья может быть расценена лишь как справочная информация.
В том же 2001 году выходит методология разработки от компании IBM, называющаяся Rational Unified Process (RUP)
Справедливости для: RUP была разработана компанией Rational Software, которую в 2003 году поглотил IBM.
Sign up to leave a comment.
Методологии управления информационными проектами