Сообщение Re[4]: SEMAT – Единая Теория Всего Программирования? от 01.04.2015 8:07
Изменено 01.04.2015 8:09 vdimas
Здравствуйте, Sinix, Вы писали:
V>>Это фундаментальные инженерные процессы, которые относятся не только к разработке ПО. Ничего нового они не выдумали, но собираются упорядочить уже имеющееся. Так же неплоха ориентация на полноту методологии, в отличие от всяких модных-однобоких.
S>Эта бла-бла-грамма выше ещё больший сфероконизм чем паттерны от GoF.
Паттерны от GoF никакой не сфероконизм. Это сборник уже имеющихся на тот момент полезных практик. Полезность GoF — в попытке упорядочить эти практики, классифицировать и дать им именования, некий "алфавит". Любая предметная область начинается с терминологии и в этом плане заслуга GoF отнюдь не сфероконическая.
S>А тут всё заканчивается ИБД + кучей трюизмов, они не станут теорией всего, как ты их на глобус не натягивай.
Блин, иногда хочется коллегам сказать "заткнись и внимай". ))
Какой в опу глобус? Ничего нового я у них не увидел, но увидел попытку обобщить имеющееся. Я в разные годы отсылал коллег к 19-м и 34-м ГОСТ-ам. Почему? Не секрет, что в любой более-менее серьезной конторе полно своих правил по организации рабочего процесса. Зачастую эти правила рождаются в муках, путём проб и ошибок. Знаешь, как военный устав всегда писался кровью и только кровью реальных людей. В этом смысле ГОСТ-ы, RUP, MSF были (и есть) таким же "уставом, писанным кровью".
Например, одно дело опытные разработчики с 15-20-летним стажем, другое дело — команда из относительно молодых спецов, которая будет вынуждена запарывать проекты вовсе не из-за недостаточной технической подготовки, а именно из-за недостаточной организационной. Современный разработчик обычно очень хорошо знает, что делать на стадии макетирования и технического эксперимента, знает как решать конкретные технические вопросы, но плохо представляет себе весь процесс разработки программных систем уровня выше мелких (по современным меркам) проектов. Т.е., "чуйка" и техническая подготовка зачастую плохо работают в командах из более 5-ти человек. По многим вопросам происходит "буксование" только из-за того, что нет опытного управленца, которому можно доверить хотя бы 20 спецов.
Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО. Мне довелось в начале своей карьеры поучаствовать в разработке программных систем по 19-м ГОСТ-ам, — проникся. Отпадает надобность во внешнем "кнуте и прянике" в виде достаточно опытной в управлении личности, который должен разбираться с тараканами каждого конкретного разработчика. Это как методичка к курсовому проекту, например, где для студента расписан необходимый план работ. И что мне больше всего импонировало, что эта "методичка" не исключает так любимых всеми нами стадий решения тех самых "вкусных" технических проблем. Наоборот, она помогает всем этим наработкам не трансформироваться в "работу в стол", а жесткая привязка итеративности процесса не позволяет слишком увлечься "любимой задачей".
S>Универсальные полные тяжеловесные методики мы уже проходили 15 лет назад. Популярность msf, rup и прочих uml-driven как бы намекает, что не надо так делать.
Тем не менее, эти методологии появились не из воздуха, это реальные "циркуляры", по которым была осуществлена разработка очень больших программных систем. MSF и RUP очень близки, MSF даже тяжеловесней RUP, они обе хороши тем, что обладают полнотой, т.е. описывают полный цикл разработки, начиная от "наколенных" поделок, а так же обладают неплохой масштабируемостью, т.е. подходят как командам из 2-х человек, так и командам из 20-ти человек.
(UML здесь никаким боком от слова вообще, это из разряда "слышал звон, да не знаю, где он".)
S>Они все как одна сыпятся на самом нижнем уровне из-за чрезмерной детализации и оверменеджмента.
Наоборот, эти методологии появились как результат борьбы с микроменеджментом (особенно ярко это наблюдается в MSF), чтобы над каждым разработчиком не стоял дядя-PM и не говорил ему каждый день, что ему делать дальше. Это просто "методички" по самоорганизации процесса разработки ПО.
S>Перспектива на сегодня если и есть за чем, то за скрещиванием процессного подхода сверху и управляемого бардака снизу. Читай, kanban, lean, и кадавры из тяжеловесной биз-аналитики и любого agile-подхода. Но нет, мы снова будем пытаться свести в систему носки и капусту, просто потому, что можем
RUP и MSF не могут быть противопоставлены Agile, потому что являются надмножеством практик из Agile, т.е. включают их в себя полностью (кроме таких вещей из XP, как "парное программирование" — это слишком субъективная хрень, т.е. сильно зависимая от человеческого фактора практика, которая работает далеко не для всех "пар").
Извини, но весь этот пост говорит о том, что ты не удовлетворил свою эрудицию ни разу даже по такой вещи, которую неявно рекламируешь, — по Agile. Сама постановка вопроса "противопоставление Agile и MSF" говорит о том, что тебе не стоило высказываться по этой теме до изучения азов MSF в том числе. Цимус в том, что одна из популярных Agile на сегодня — это MSF Agile, которую используют в самой MS.
Более того, Agile Manifesto не включает в себя каких-либо практик и был составлен практиками, использующими РАЗНЫЕ методологии разработки ПО. Это просто набор советов для расстановки приоритетов в рамках ЛЮБОЙ законченной методологии проектирования. Медитировать до просветления, как грится.
Даже взять SCRUM — его можно рассматривать как урезанный по артефактам RUP, где из всего RUP оставили, собственно, итеративную часть разработки. Это ВСЁ. Т.е. это ЧАСТЬ методологии, но не вся она, т.к. она не обладает полнотой, т.к. описывает лишь часть жизненного цикла ПО. Еще можно вспомнить наши 19-е и 34-е ГОСТ-ы, которые тоже предоставляли возможность разного по уровню "углубления" в подробности методологии. Т.е. при том, что "общий рисунок" по ГОСТ-ам оставался тем же, некоторые стадии могли быть реализованы с произвольной (т.е. необходимой для каждого конкретного случая) глубиной.
И да, возвращаясь с кабжу. Чем мне сразу импонирует SEMAT — это "иерархической" моделью представления модели методологии. Сорри, это не масло маслянное, а именно так. Начиная от самых общих штрихов, от каркаса самого процесса, по каждой детали можно углубляться в подробности настолько, насколько это требуется. Т.е., я ожидаю от ЭТОЙ попытки, наконец, возможность изучать "методичку" ровно с такой степенью подробности, которая будет соответствовать "размеру" разрабатываемого ПО, и не более. Думаю, именно с этой целью товарищи и подошли к станку на этот раз.
Если у них это в итоге выгорит — они покроют как бык корову все эти ГОСТ-ы, MSF, RUP и семейство Agile, по понятным причинам.
V>>Это фундаментальные инженерные процессы, которые относятся не только к разработке ПО. Ничего нового они не выдумали, но собираются упорядочить уже имеющееся. Так же неплоха ориентация на полноту методологии, в отличие от всяких модных-однобоких.
S>Эта бла-бла-грамма выше ещё больший сфероконизм чем паттерны от GoF.
Паттерны от GoF никакой не сфероконизм. Это сборник уже имеющихся на тот момент полезных практик. Полезность GoF — в попытке упорядочить эти практики, классифицировать и дать им именования, некий "алфавит". Любая предметная область начинается с терминологии и в этом плане заслуга GoF отнюдь не сфероконическая.
S>А тут всё заканчивается ИБД + кучей трюизмов, они не станут теорией всего, как ты их на глобус не натягивай.
Блин, иногда хочется коллегам сказать "заткнись и внимай". ))
Какой в опу глобус? Ничего нового я у них не увидел, но увидел попытку обобщить имеющееся. Я в разные годы отсылал коллег к 19-м и 34-м ГОСТ-ам. Почему? Не секрет, что в любой более-менее серьезной конторе полно своих правил по организации рабочего процесса. Зачастую эти правила рождаются в муках, путём проб и ошибок. Знаешь, как военный устав всегда писался кровью и только кровью реальных людей. В этом смысле ГОСТ-ы, RUP, MSF были (и есть) таким же "уставом, писанным кровью".
Например, одно дело опытные разработчики с 15-20-летним стажем, другое дело — команда из относительно молодых спецов, которая будет вынуждена запарывать проекты вовсе не из-за недостаточной технической подготовки, а именно из-за недостаточной организационной. Современный разработчик обычно очень хорошо знает, что делать на стадии макетирования и технического эксперимента, знает как решать конкретные технические вопросы, но плохо представляет себе весь процесс разработки программных систем уровня выше мелких (по современным меркам) проектов. Т.е., "чуйка" и техническая подготовка зачастую плохо работают в командах из более 5-ти человек. По многим вопросам происходит "буксование" только из-за того, что нет опытного управленца, которому можно доверить хотя бы 20 спецов.
Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО. Мне довелось в начале своей карьеры поучаствовать в разработке программных систем по 19-м ГОСТ-ам, — проникся. Отпадает надобность во внешнем "кнуте и прянике" в виде достаточно опытной в управлении личности, который должен разбираться с тараканами каждого конкретного разработчика. Это как методичка к курсовому проекту, например, где для студента расписан необходимый план работ. И что мне больше всего импонировало, что эта "методичка" не исключает так любимых всеми нами стадий решения тех самых "вкусных" технических проблем. Наоборот, она помогает всем этим наработкам не трансформироваться в "работу в стол", а жесткая привязка итеративности процесса не позволяет слишком увлечься "любимой задачей".
S>Универсальные полные тяжеловесные методики мы уже проходили 15 лет назад. Популярность msf, rup и прочих uml-driven как бы намекает, что не надо так делать.
Тем не менее, эти методологии появились не из воздуха, это реальные "циркуляры", по которым была осуществлена разработка очень больших программных систем. MSF и RUP очень близки, MSF даже тяжеловесней RUP, они обе хороши тем, что обладают полнотой, т.е. описывают полный цикл разработки, начиная от "наколенных" поделок, а так же обладают неплохой масштабируемостью, т.е. подходят как командам из 2-х человек, так и командам из 20-ти человек.
(UML здесь никаким боком от слова вообще, это из разряда "слышал звон, да не знаю, где он".)
S>Они все как одна сыпятся на самом нижнем уровне из-за чрезмерной детализации и оверменеджмента.
Наоборот, эти методологии появились как результат борьбы с микроменеджментом (особенно ярко это наблюдается в MSF), чтобы над каждым разработчиком не стоял дядя-PM и не говорил ему каждый день, что ему делать дальше. Это просто "методички" по самоорганизации процесса разработки ПО.
S>Перспектива на сегодня если и есть за чем, то за скрещиванием процессного подхода сверху и управляемого бардака снизу. Читай, kanban, lean, и кадавры из тяжеловесной биз-аналитики и любого agile-подхода. Но нет, мы снова будем пытаться свести в систему носки и капусту, просто потому, что можем
RUP и MSF не могут быть противопоставлены Agile, потому что являются надмножеством практик из Agile, т.е. включают их в себя полностью (кроме таких вещей из XP, как "парное программирование" — это слишком субъективная хрень, т.е. сильно зависимая от человеческого фактора практика, которая работает далеко не для всех "пар").
Извини, но весь этот пост говорит о том, что ты не удовлетворил свою эрудицию ни разу даже по такой вещи, которую неявно рекламируешь, — по Agile. Сама постановка вопроса "противопоставление Agile и MSF" говорит о том, что тебе не стоило высказываться по этой теме до изучения азов MSF в том числе. Цимус в том, что одна из популярных Agile на сегодня — это MSF Agile, которую используют в самой MS.
Более того, Agile Manifesto не включает в себя каких-либо практик и был составлен практиками, использующими РАЗНЫЕ методологии разработки ПО. Это просто набор советов для расстановки приоритетов в рамках ЛЮБОЙ законченной методологии проектирования. Медитировать до просветления, как грится.
Даже взять SCRUM — его можно рассматривать как урезанный по артефактам RUP, где из всего RUP оставили, собственно, итеративную часть разработки. Это ВСЁ. Т.е. это ЧАСТЬ методологии, но не вся она, т.к. она не обладает полнотой, т.к. описывает лишь часть жизненного цикла ПО. Еще можно вспомнить наши 19-е и 34-е ГОСТ-ы, которые тоже предоставляли возможность разного по уровню "углубления" в подробности методологии. Т.е. при том, что "общий рисунок" по ГОСТ-ам оставался тем же, некоторые стадии могли быть реализованы с произвольной (т.е. необходимой для каждого конкретного случая) глубиной.
И да, возвращаясь с кабжу. Чем мне сразу импонирует SEMAT — это "иерархической" моделью представления модели методологии. Сорри, это не масло маслянное, а именно так. Начиная от самых общих штрихов, от каркаса самого процесса, по каждой детали можно углубляться в подробности настолько, насколько это требуется. Т.е., я ожидаю от ЭТОЙ попытки, наконец, возможность изучать "методичку" ровно с такой степенью подробности, которая будет соответствовать "размеру" разрабатываемого ПО, и не более. Думаю, именно с этой целью товарищи и подошли к станку на этот раз.
Если у них это в итоге выгорит — они покроют как бык корову все эти ГОСТ-ы, MSF, RUP и семейство Agile, по понятным причинам.
Re[4]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, Sinix, Вы писали:
V>>Это фундаментальные инженерные процессы, которые относятся не только к разработке ПО. Ничего нового они не выдумали, но собираются упорядочить уже имеющееся. Так же неплоха ориентация на полноту методологии, в отличие от всяких модных-однобоких.
S>Эта бла-бла-грамма выше ещё больший сфероконизм чем паттерны от GoF.
Паттерны от GoF никакой не сфероконизм. Это сборник уже имеющихся на тот момент полезных практик. Полезность GoF — в попытке упорядочить эти практики, классифицировать и дать им именования, некий "алфавит". Любая предметная область начинается с терминологии и в этом плане заслуга GoF отнюдь не сфероконическая.
S>А тут всё заканчивается ИБД + кучей трюизмов, они не станут теорией всего, как ты их на глобус не натягивай.
Блин, иногда хочется коллегам сказать "заткнись и внимай". ))
Какой в опу глобус? Ничего нового я у них не увидел, но увидел попытку обобщить имеющееся. Я в разные годы отсылал коллег к 19-м и 34-м ГОСТ-ам. Почему? Не секрет, что в любой более-менее серьезной конторе полно своих правил по организации рабочего процесса. Зачастую эти правила рождаются в муках, путём проб и ошибок. Знаешь, как военный устав всегда писался кровью и только кровью реальных людей. В этом смысле ГОСТ-ы, RUP, MSF были (и есть) таким же "уставом, писанным кровью".
Например, одно дело опытные разработчики с 15-20-летним стажем, другое дело — команда из относительно молодых спецов, которая будет вынуждена запарывать проекты вовсе не из-за недостаточной технической подготовки, а именно из-за недостаточной организационной. Современный разработчик обычно очень хорошо знает, что делать на стадии макетирования и технического эксперимента, знает как решать конкретные технические вопросы, но плохо представляет себе весь процесс разработки программных систем уровня выше мелких (по современным меркам) проектов. Т.е., "чуйка" и техническая подготовка зачастую плохо работают в командах из более 5-ти человек. По многим вопросам происходит "буксование" только из-за того, что нет опытного управленца, которому можно доверить хотя бы 20 спецов.
Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО. Мне довелось в начале своей карьеры поучаствовать в разработке программных систем по 19-м ГОСТ-ам, — проникся. Отпадает надобность во внешнем "кнуте и прянике" в виде достаточно опытной в управлении личности, который должен разбираться с тараканами каждого конкретного разработчика. Это как методичка к курсовому проекту, например, где для студента расписан необходимый план работ. И что мне больше всего импонировало, что эта "методичка" не исключает так любимых всеми нами стадий решения тех самых "вкусных" технических проблем. Наоборот, она помогает всем этим наработкам не трансформироваться в "работу в стол", а жесткая привязка к итеративности процесса не позволяет слишком увлечься "любимой задачей".
S>Универсальные полные тяжеловесные методики мы уже проходили 15 лет назад. Популярность msf, rup и прочих uml-driven как бы намекает, что не надо так делать.
Тем не менее, эти методологии появились не из воздуха, это реальные "циркуляры", по которым была осуществлена разработка очень больших программных систем. MSF и RUP очень близки, MSF даже тяжеловесней RUP, они обе хороши тем, что обладают полнотой, т.е. описывают полный цикл разработки, начиная от "наколенных" поделок, а так же обладают неплохой масштабируемостью, т.е. подходят как командам из 2-х человек, так и командам из 20-ти человек.
(UML здесь никаким боком от слова вообще, это из разряда "слышал звон, да не знаю, где он".)
S>Они все как одна сыпятся на самом нижнем уровне из-за чрезмерной детализации и оверменеджмента.
Наоборот, эти методологии появились как результат борьбы с микроменеджментом (особенно ярко это наблюдается в MSF), чтобы над каждым разработчиком не стоял дядя-PM и не говорил ему каждый день, что ему делать дальше. Это просто "методички" по самоорганизации процесса разработки ПО.
S>Перспектива на сегодня если и есть за чем, то за скрещиванием процессного подхода сверху и управляемого бардака снизу. Читай, kanban, lean, и кадавры из тяжеловесной биз-аналитики и любого agile-подхода. Но нет, мы снова будем пытаться свести в систему носки и капусту, просто потому, что можем
RUP и MSF не могут быть противопоставлены Agile, потому что являются надмножеством практик из Agile, т.е. включают их в себя полностью (кроме таких вещей из XP, как "парное программирование" — это слишком субъективная хрень, т.е. сильно зависимая от человеческого фактора практика, которая работает далеко не для всех "пар").
Извини, но весь этот пост говорит о том, что ты не удовлетворил свою эрудицию ни разу даже по такой вещи, которую неявно рекламируешь, — по Agile. Сама постановка вопроса "противопоставление Agile и MSF" говорит о том, что тебе не стоило высказываться по этой теме до изучения азов MSF в том числе. Цимус в том, что одна из популярных Agile на сегодня — это MSF Agile, которую используют в самой MS.
Более того, Agile Manifesto не включает в себя каких-либо практик и был составлен практиками, использующими РАЗНЫЕ методологии разработки ПО. Это просто набор советов для расстановки приоритетов в рамках ЛЮБОЙ законченной методологии проектирования. Медитировать до просветления, как грится.
Даже взять SCRUM — его можно рассматривать как урезанный по артефактам RUP, где из всего RUP оставили, собственно, итеративную часть разработки. Это ВСЁ. Т.е. это ЧАСТЬ методологии, но не вся она, т.к. она не обладает полнотой, т.к. описывает лишь часть жизненного цикла ПО. Еще можно вспомнить наши 19-е и 34-е ГОСТ-ы, которые тоже предоставляли возможность разного по уровню "углубления" в подробности методологии. Т.е. при том, что "общий рисунок" по ГОСТ-ам оставался тем же, некоторые стадии могли быть реализованы с произвольной (т.е. необходимой для каждого конкретного случая) глубиной.
И да, возвращаясь с кабжу. Чем мне сразу импонирует SEMAT — это "иерархической" моделью представления модели методологии. Сорри, это не масло маслянное, а именно так. Начиная от самых общих штрихов, от каркаса самого процесса, по каждой детали можно углубляться в подробности настолько, насколько это требуется. Т.е., я ожидаю от ЭТОЙ попытки, наконец, возможность изучать "методичку" ровно с такой степенью подробности, которая будет соответствовать "размеру" разрабатываемого ПО, и не более. Думаю, именно с этой целью товарищи и подошли к станку на этот раз.
Если у них это в итоге выгорит — они покроют как бык корову все эти ГОСТ-ы, MSF, RUP и семейство Agile, по понятным причинам.
V>>Это фундаментальные инженерные процессы, которые относятся не только к разработке ПО. Ничего нового они не выдумали, но собираются упорядочить уже имеющееся. Так же неплоха ориентация на полноту методологии, в отличие от всяких модных-однобоких.
S>Эта бла-бла-грамма выше ещё больший сфероконизм чем паттерны от GoF.
Паттерны от GoF никакой не сфероконизм. Это сборник уже имеющихся на тот момент полезных практик. Полезность GoF — в попытке упорядочить эти практики, классифицировать и дать им именования, некий "алфавит". Любая предметная область начинается с терминологии и в этом плане заслуга GoF отнюдь не сфероконическая.
S>А тут всё заканчивается ИБД + кучей трюизмов, они не станут теорией всего, как ты их на глобус не натягивай.
Блин, иногда хочется коллегам сказать "заткнись и внимай". ))
Какой в опу глобус? Ничего нового я у них не увидел, но увидел попытку обобщить имеющееся. Я в разные годы отсылал коллег к 19-м и 34-м ГОСТ-ам. Почему? Не секрет, что в любой более-менее серьезной конторе полно своих правил по организации рабочего процесса. Зачастую эти правила рождаются в муках, путём проб и ошибок. Знаешь, как военный устав всегда писался кровью и только кровью реальных людей. В этом смысле ГОСТ-ы, RUP, MSF были (и есть) таким же "уставом, писанным кровью".
Например, одно дело опытные разработчики с 15-20-летним стажем, другое дело — команда из относительно молодых спецов, которая будет вынуждена запарывать проекты вовсе не из-за недостаточной технической подготовки, а именно из-за недостаточной организационной. Современный разработчик обычно очень хорошо знает, что делать на стадии макетирования и технического эксперимента, знает как решать конкретные технические вопросы, но плохо представляет себе весь процесс разработки программных систем уровня выше мелких (по современным меркам) проектов. Т.е., "чуйка" и техническая подготовка зачастую плохо работают в командах из более 5-ти человек. По многим вопросам происходит "буксование" только из-за того, что нет опытного управленца, которому можно доверить хотя бы 20 спецов.
Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО. Мне довелось в начале своей карьеры поучаствовать в разработке программных систем по 19-м ГОСТ-ам, — проникся. Отпадает надобность во внешнем "кнуте и прянике" в виде достаточно опытной в управлении личности, который должен разбираться с тараканами каждого конкретного разработчика. Это как методичка к курсовому проекту, например, где для студента расписан необходимый план работ. И что мне больше всего импонировало, что эта "методичка" не исключает так любимых всеми нами стадий решения тех самых "вкусных" технических проблем. Наоборот, она помогает всем этим наработкам не трансформироваться в "работу в стол", а жесткая привязка к итеративности процесса не позволяет слишком увлечься "любимой задачей".
S>Универсальные полные тяжеловесные методики мы уже проходили 15 лет назад. Популярность msf, rup и прочих uml-driven как бы намекает, что не надо так делать.
Тем не менее, эти методологии появились не из воздуха, это реальные "циркуляры", по которым была осуществлена разработка очень больших программных систем. MSF и RUP очень близки, MSF даже тяжеловесней RUP, они обе хороши тем, что обладают полнотой, т.е. описывают полный цикл разработки, начиная от "наколенных" поделок, а так же обладают неплохой масштабируемостью, т.е. подходят как командам из 2-х человек, так и командам из 20-ти человек.
(UML здесь никаким боком от слова вообще, это из разряда "слышал звон, да не знаю, где он".)
S>Они все как одна сыпятся на самом нижнем уровне из-за чрезмерной детализации и оверменеджмента.
Наоборот, эти методологии появились как результат борьбы с микроменеджментом (особенно ярко это наблюдается в MSF), чтобы над каждым разработчиком не стоял дядя-PM и не говорил ему каждый день, что ему делать дальше. Это просто "методички" по самоорганизации процесса разработки ПО.
S>Перспектива на сегодня если и есть за чем, то за скрещиванием процессного подхода сверху и управляемого бардака снизу. Читай, kanban, lean, и кадавры из тяжеловесной биз-аналитики и любого agile-подхода. Но нет, мы снова будем пытаться свести в систему носки и капусту, просто потому, что можем
RUP и MSF не могут быть противопоставлены Agile, потому что являются надмножеством практик из Agile, т.е. включают их в себя полностью (кроме таких вещей из XP, как "парное программирование" — это слишком субъективная хрень, т.е. сильно зависимая от человеческого фактора практика, которая работает далеко не для всех "пар").
Извини, но весь этот пост говорит о том, что ты не удовлетворил свою эрудицию ни разу даже по такой вещи, которую неявно рекламируешь, — по Agile. Сама постановка вопроса "противопоставление Agile и MSF" говорит о том, что тебе не стоило высказываться по этой теме до изучения азов MSF в том числе. Цимус в том, что одна из популярных Agile на сегодня — это MSF Agile, которую используют в самой MS.
Более того, Agile Manifesto не включает в себя каких-либо практик и был составлен практиками, использующими РАЗНЫЕ методологии разработки ПО. Это просто набор советов для расстановки приоритетов в рамках ЛЮБОЙ законченной методологии проектирования. Медитировать до просветления, как грится.
Даже взять SCRUM — его можно рассматривать как урезанный по артефактам RUP, где из всего RUP оставили, собственно, итеративную часть разработки. Это ВСЁ. Т.е. это ЧАСТЬ методологии, но не вся она, т.к. она не обладает полнотой, т.к. описывает лишь часть жизненного цикла ПО. Еще можно вспомнить наши 19-е и 34-е ГОСТ-ы, которые тоже предоставляли возможность разного по уровню "углубления" в подробности методологии. Т.е. при том, что "общий рисунок" по ГОСТ-ам оставался тем же, некоторые стадии могли быть реализованы с произвольной (т.е. необходимой для каждого конкретного случая) глубиной.
И да, возвращаясь с кабжу. Чем мне сразу импонирует SEMAT — это "иерархической" моделью представления модели методологии. Сорри, это не масло маслянное, а именно так. Начиная от самых общих штрихов, от каркаса самого процесса, по каждой детали можно углубляться в подробности настолько, насколько это требуется. Т.е., я ожидаю от ЭТОЙ попытки, наконец, возможность изучать "методичку" ровно с такой степенью подробности, которая будет соответствовать "размеру" разрабатываемого ПО, и не более. Думаю, именно с этой целью товарищи и подошли к станку на этот раз.
Если у них это в итоге выгорит — они покроют как бык корову все эти ГОСТ-ы, MSF, RUP и семейство Agile, по понятным причинам.