Методология: нужна ли?
Слово "методология" (methodology) имеет несколько разных значений, главными из которых являются:
-- дисциплина, предметом которой является метод (ситуационная инженерия методов это только часть так понимаемой методологии);
-- собственно метод, как согласованный набор практик (синонимия method и methodology в этом значении оговаривается в ISO 24744. Синонимом также можно считать process в таких словосочетаниях, как software process. Даже life cycle model из ISO 15288, "вид жизненного цикла" -- это всё оно же). Русская "методика" -- это просто описание метода (рабочий продукт, а не альфа -- http://ailev.livejournal.com/1082662.html).
Я по-русски предпочту "методологией" называть дисциплину, предметом которой является "метод" -- то есть по-русски у меня эти два слова не будут синонимами (но не в моих текстах слово "методология" может быть и калькой с английского -- какая-нибудь "методология ITIL", который у меня будет "метод ITIL"). Из контекста обычно понятно, дисциплина имеется ввиду, или метод (с точностью до игнорирования тонкой разницы между методом и дисциплиной: но метод состоит из практик, а дисциплина из мы-не-обсуждали-чего).
Вопрос: нужно ли специально учить методологии в коротких образовательных программах на производстве и семестровых курсах в ВУЗах? Короткая программа на производстве тут примерно равна семестровому курсу (4 кредита, 32-36 аудиторных часов и примерно столько же самостоятельных занятий), и будем считать, что на производстве начальству не удаётся помешать попробовать изученный материал в деле -- это и будут "самостоятельные занятия".
Понятно, что "основательное образование" может включать в себя любые "мета"-дисциплины, не непосредственно касающиеся главной: в ВУЗах учат и английский язык, и даже занимаются физкультурой, да философию как-то "проходят мимо". Почему бы и методологией не заняться?
Но я тут говорю о коротких программах: у вас есть 32 аудиторных академических часа (по 45 минут каждый час), и вам нужно принять решение -- вставлять ли в эту учебную программу методологию.
Аргументы против:
-- изучать методологию совершенно необязательно. Если говоришь прозой, то знать что это "проза" необязательно. Если говоришь стихами, то знать про существование гекзаметра необязательно: это всё для особых любителей. Были бы тексты хорошими, а остальное не нужно. Рыбке нужно плавать, знание про то, что она плавает в воде излишне.
-- методология нужна только методологам. Производственникам она не нужна, а если уж кому приспичит (в какой нибудь "службе качества", где проверяющие потребуют очередной "список методов" или "список процессов") -- то и без обучения разберутся, все эти "службы качества" аналитические по принципу, никакого качества они на-гора не выдают, а просто готовят какие-то описания для разных проверяющих да инвентаризующих. Учить этих людей можно, но необязательно: свои пухленькие стандарты они и без методологии прочтут.
-- никто нигде никогда этому специально в ВУЗах или на производстве не учит, вот и мы не будем.
Аргументы за:
-- методология позволяет отмоделировать метод работы: невидимое сделать видимым. После появления модели метода работы можно обсуждать и улучшать его, осознанно меняя составляющие его практики и поддерживая коллективное обсуждение.
-- большинство людей, которые занялись методологией, были поставлены перед задачей научить какую-то новую команду работать каким-то методом, который им был известен. Проблема была в том, что они не знали, чему именно нужно учить людей: "что такое метод". Такая задача (научить новой технологии какую-то команду, адаптировав эту технологию к новым условиям) появляется перед людьми чаще, чем можно подумать. А поскольку консультационные проекты обычно связаны с управлением технологиями (дисциплина, занимающаяся тем, чтобы сделать доступными новые технологии там и тогда, где и когда они нужны), то задача переноса и адаптации практик/метода появляется практически в каждом проекте. Правильно было бы сэкономить время на изобретение велосипеда: дать людям в этой ситуации знания по методологии (а не только по конкретной технологии/методу/практике).
-- если "простой инженер" не осваивает постоянно новые технологии/методы/практики, то он порастает мхом. Чтобы он мог эффективно общаться с людьми из служб развития и отделов инноваций, ему тоже нужно иметь знания о методологии.
-- ситуационную инженерию методов (а это часть методологии) уже начинают изучать в ВУЗах: и не только неявно (то есть знакомством с разными Body of Knowledge и неявным пониманием, что они по-большому счёту устроены все как-то похоже), но явно (изучение OMG Essence как части ситуационной инженерии методов в ВУЗовских курсах software engineering становится популярным). Это очень современное начинание (движение началось буквально в прошлом учебном году), но даже в России уже есть несколько ВУЗовских курсов на этой основе. Так что нельзя говорить, что "никто нигде никогда".
-- основы инженерии (как что-то сделать) и основы методологии (как что-то сделать) очень похожи: в инженерии нужно говорить про действующих лиц, возможности, определение и воплощение системы, команду, работы, технологию -- и в методологии нужно говорить о том же самом. Так что не такой уж и большой накладной расход получается.
Меня аргументы "за" вполне убеждают. Для меня обучение методологическому знанию -- это путь к экономии времени и сил. Потратить несколько часов учебного курса или консалтингового проекта на освоение со студентами или сотрудниками клиента методологических понятий (например, language из OMG Essence -- все эти "метод", практика", "рабочий продукт" и т.д.) и понимания того, что такое инженерный проект (kernel оттуда же -- все эти "стейкхолдеры", "возможности", "определение и воплощение системы", "команда" и т.д.) вполне можно. А потом сэкономить много-много часов на более продуктивных обсуждениях, ибо о многих и многих важных понятиях уже договорились.
Но и аргументы "против" тоже учитываем: вместо необъятной "методологии всего" (в которой и СМД-методология является такой же частью, как и ситуационная инженерия методов) я бы давал только "часть от части": подход SEMAT в виде OMG Essence как наиболее продвинутую часть ситуационной инженерии методов.
Так что методология уместна и в коротких программах, но не вся, а только маленький её кусочек.
-- дисциплина, предметом которой является метод (ситуационная инженерия методов это только часть так понимаемой методологии);
-- собственно метод, как согласованный набор практик (синонимия method и methodology в этом значении оговаривается в ISO 24744. Синонимом также можно считать process в таких словосочетаниях, как software process. Даже life cycle model из ISO 15288, "вид жизненного цикла" -- это всё оно же). Русская "методика" -- это просто описание метода (рабочий продукт, а не альфа -- http://ailev.livejournal.com/1082662.html).
Я по-русски предпочту "методологией" называть дисциплину, предметом которой является "метод" -- то есть по-русски у меня эти два слова не будут синонимами (но не в моих текстах слово "методология" может быть и калькой с английского -- какая-нибудь "методология ITIL", который у меня будет "метод ITIL"). Из контекста обычно понятно, дисциплина имеется ввиду, или метод (с точностью до игнорирования тонкой разницы между методом и дисциплиной: но метод состоит из практик, а дисциплина из мы-не-обсуждали-чего).
Вопрос: нужно ли специально учить методологии в коротких образовательных программах на производстве и семестровых курсах в ВУЗах? Короткая программа на производстве тут примерно равна семестровому курсу (4 кредита, 32-36 аудиторных часов и примерно столько же самостоятельных занятий), и будем считать, что на производстве начальству не удаётся помешать попробовать изученный материал в деле -- это и будут "самостоятельные занятия".
Понятно, что "основательное образование" может включать в себя любые "мета"-дисциплины, не непосредственно касающиеся главной: в ВУЗах учат и английский язык, и даже занимаются физкультурой, да философию как-то "проходят мимо". Почему бы и методологией не заняться?
Но я тут говорю о коротких программах: у вас есть 32 аудиторных академических часа (по 45 минут каждый час), и вам нужно принять решение -- вставлять ли в эту учебную программу методологию.
Аргументы против:
-- изучать методологию совершенно необязательно. Если говоришь прозой, то знать что это "проза" необязательно. Если говоришь стихами, то знать про существование гекзаметра необязательно: это всё для особых любителей. Были бы тексты хорошими, а остальное не нужно. Рыбке нужно плавать, знание про то, что она плавает в воде излишне.
-- методология нужна только методологам. Производственникам она не нужна, а если уж кому приспичит (в какой нибудь "службе качества", где проверяющие потребуют очередной "список методов" или "список процессов") -- то и без обучения разберутся, все эти "службы качества" аналитические по принципу, никакого качества они на-гора не выдают, а просто готовят какие-то описания для разных проверяющих да инвентаризующих. Учить этих людей можно, но необязательно: свои пухленькие стандарты они и без методологии прочтут.
-- никто нигде никогда этому специально в ВУЗах или на производстве не учит, вот и мы не будем.
Аргументы за:
-- методология позволяет отмоделировать метод работы: невидимое сделать видимым. После появления модели метода работы можно обсуждать и улучшать его, осознанно меняя составляющие его практики и поддерживая коллективное обсуждение.
-- большинство людей, которые занялись методологией, были поставлены перед задачей научить какую-то новую команду работать каким-то методом, который им был известен. Проблема была в том, что они не знали, чему именно нужно учить людей: "что такое метод". Такая задача (научить новой технологии какую-то команду, адаптировав эту технологию к новым условиям) появляется перед людьми чаще, чем можно подумать. А поскольку консультационные проекты обычно связаны с управлением технологиями (дисциплина, занимающаяся тем, чтобы сделать доступными новые технологии там и тогда, где и когда они нужны), то задача переноса и адаптации практик/метода появляется практически в каждом проекте. Правильно было бы сэкономить время на изобретение велосипеда: дать людям в этой ситуации знания по методологии (а не только по конкретной технологии/методу/практике).
-- если "простой инженер" не осваивает постоянно новые технологии/методы/практики, то он порастает мхом. Чтобы он мог эффективно общаться с людьми из служб развития и отделов инноваций, ему тоже нужно иметь знания о методологии.
-- ситуационную инженерию методов (а это часть методологии) уже начинают изучать в ВУЗах: и не только неявно (то есть знакомством с разными Body of Knowledge и неявным пониманием, что они по-большому счёту устроены все как-то похоже), но явно (изучение OMG Essence как части ситуационной инженерии методов в ВУЗовских курсах software engineering становится популярным). Это очень современное начинание (движение началось буквально в прошлом учебном году), но даже в России уже есть несколько ВУЗовских курсов на этой основе. Так что нельзя говорить, что "никто нигде никогда".
-- основы инженерии (как что-то сделать) и основы методологии (как что-то сделать) очень похожи: в инженерии нужно говорить про действующих лиц, возможности, определение и воплощение системы, команду, работы, технологию -- и в методологии нужно говорить о том же самом. Так что не такой уж и большой накладной расход получается.
Меня аргументы "за" вполне убеждают. Для меня обучение методологическому знанию -- это путь к экономии времени и сил. Потратить несколько часов учебного курса или консалтингового проекта на освоение со студентами или сотрудниками клиента методологических понятий (например, language из OMG Essence -- все эти "метод", практика", "рабочий продукт" и т.д.) и понимания того, что такое инженерный проект (kernel оттуда же -- все эти "стейкхолдеры", "возможности", "определение и воплощение системы", "команда" и т.д.) вполне можно. А потом сэкономить много-много часов на более продуктивных обсуждениях, ибо о многих и многих важных понятиях уже договорились.
Но и аргументы "против" тоже учитываем: вместо необъятной "методологии всего" (в которой и СМД-методология является такой же частью, как и ситуационная инженерия методов) я бы давал только "часть от части": подход SEMAT в виде OMG Essence как наиболее продвинутую часть ситуационной инженерии методов.
Так что методология уместна и в коротких программах, но не вся, а только маленький её кусочек.