Блог:Максима Цепкова/2011-11-20: Agile и CMMI - История изменений

MaksTsepkov: Массовая правка: добавление Категория:Управление проектами

2017-09-14T08:08:54Z

Массовая правка: добавление Категория:Управление проектами

MaksTsepkov: Массовая правка: добавление Категория:Agile

2016-12-28T21:41:40Z

Массовая правка: добавление Категория:Agile

MaksTsepkov в 05:17, 18 февраля 2016

2016-02-18T05:17:58Z

MaksTsepkov в 21:47, 19 ноября 2011

2011-11-19T21:47:26Z

MaksTsepkov в 21:39, 19 ноября 2011

2011-11-19T21:39:38Z

MaksTsepkov: Новая страница: «Подготовка выступления к [http://it-conf.ru/ru/sqadays_main/sqadays_10/sqa10_agenda/ SQA Days] и, особенно, [http://software-testing.r...»

2011-11-19T21:37:32Z

Новая страница: «Подготовка выступления к [http://it-conf.ru/ru/sqadays_main/sqadays_10/sqa10_agenda/ SQA Days] и, особенно, [http://software-testing.r...»

Новая страница

Подготовка выступления к [http://it-conf.ru/ru/sqadays_main/sqadays_10/sqa10_agenda/ SQA Days] и, особенно, [http://software-testing.ru/forum/topic/21066/page__pid__96783#entry96783 обсуждение] на форуме http://software-testing.ru моей статьи, помещенной в качестве анонса к докладу, вызвало пару мыслей про Agile, которыми хочу поделиться. Именно про agile - хотя само выступление про совмещение ролей аналитика и тестировщика, в я активно апеллирую к agile-процессу и это вызвало отдельную ветку обсуждений.

Мысль первая. Для меня качественное отличие agile-подхода от предыдущего общего мнения состоит в следующем. Agile заявил, что процесс следует настраивать в соответствии с проектом. Что никакой унифицированный процесс, пригодный для IT-разработки - невозможен, даже в варианте "возьмите только нужное, используйте решения адекватного уровня сложности". До этого достаточно продолжительное время IT-сообщество искало именно унифицированный процесс, из которого конкретный процесс строился бы вычеркиванием ненужного и выбором вариантов. А agile заявил, что так невозможно, что есть только рамочные, заведомо общие варианты, от которых тоже можно отступать, и различные практики, и из всего этого надо собирать конкретный процесс.

Надо сказать, что мысль о принципиальном отсутствии унифицированного процесса звучит не слишком ярко. И, более того, не воспринимается многими как сторонниками так и противниками agile. Сторонники получаются догматическими приверженцами определенных вариантов, а противники - указывают на провалы и вообще на "проблемы с методологией". Потому что многим людям очень хочется, чтобы было некоторое "правильное государство", "правильная методология", "правильный процесс" - такая постановка близка их мышлению.

Мысль вторая. Я тут пересмотрел презентацию Джефа Сазерленда на [http://www.secr.ru/lang/ru-ru/program/presentations SECR], и вспомнил вещь, на которую обратил внимание еще на конференции. Для Джефа развитие компании идет так: CMM I-1 → CMMI 5 → CMMI 5+SCRUM. Я обсудил это с коллегами и для ряда из них CMMI5 и SCRUM - вещи слабо совместимые. На самом деле, тут вопрос оценки CMMI. CMMI 4 говорит о том, что в компании должна быть настроена оптимизация процессов на основе показателей. А CMMI 5 - что сам процесс оптимизации тоже должен оптимизироваться. Дальше вопрос - что именно мы вкладываем в понятие "оптимизация". Максималисткий подход - рассматривать оптимизацию как поиск оптимума (логично, правда), который еще должен быть достаточно быстрым - чтобы придти близко к оптимуму за то время, пока окружение можно считать квазистатичным.

А можно рассматривать это иначе, понимая под оптимизацией всего лишь процесс, направленный на улучшение чего либо. То есть некоторые регулярные мероприятия, в рамках которого формулируются шаги по улучшению некоторого процесса, которые потом воплощаются. И достаточно, если шаги будут в среднем правильными. И если оценивать так, то CMMI 4 в SCRUM есть - это ретроспектива. На которой, в числе прочего, следует обсуждать показатели работы команды - burndown (и другие показатели), придумывая меры по их исправлению, которые затем будут воплощены. А чтобы получился CMMI 5 - нужно еще ретро по ретре, и процесс обмена всем этим опытом в рамках компании (процесс обмена и для CMMI 4 нужен).

Естественно, так происходит не в любом SCRUM, нужно как минимум желание и усилия в этом направлении. И надо сказать, что слушая истории о конкретных командах от Джефа (и от Книберга тоже) - вполне допускаешь, что в конкретных компаниях, в них фигурирующих, SCRUM действительно означает CMMI 5.

← Предыдущая		Версия 08:08, 14 сентября 2017
Строка 15:		Строка 15:
	[[Категория:Люди]]		[[Категория:Люди]]
	[[Категория:Agile]]		[[Категория:Agile]]
		+	[[Категория:Управление проектами]]

← Предыдущая		Версия 21:41, 28 декабря 2016
Строка 14:		Строка 14:

	[[Категория:Люди]]		[[Категория:Люди]]
		+	[[Категория:Agile]]

← Предыдущая		Версия 05:17, 18 февраля 2016
Строка 12:		Строка 12:

	{{wl-publish: 2011-11-20 01:39:38 +0400 \| MaksTsepkov }}		{{wl-publish: 2011-11-20 01:39:38 +0400 \| MaksTsepkov }}
		+
		+	[[Категория:Люди]]

@@ Строка 5: / Строка 5: @@
 Надо сказать, что мысль о принципиальном отсутствии унифицированного процесса звучит не слишком ярко. И, более того, не воспринимается многими как сторонниками так и противниками agile. Сторонники получаются догматическими приверженцами определенных вариантов, а противники - указывают на провалы и вообще на "проблемы с методологией". Потому что многим людям очень хочется, чтобы было некоторое "правильное государство", "правильная методология", "правильный процесс" - такая постановка близка их мышлению.
-Мысль вторая. Я тут пересмотрел презентацию Джефа Сазерленда на [http://www.secr.ru/lang/ru-ru/program/presentations SECR], и вспомнил вещь, на которую обратил внимание еще на конференции. Для Джефа развитие компании идет так: CMM&nbsp;I-1 &rarr; CMMI&nbsp;5 &rarr; CMMI&nbsp;5+SCRUM. Я обсудил это с коллегами, с их точки зрения CMMI5 и SCRUM - вещи слабо совместимые. На самом деле, тут вопрос оценки CMMI. CMMI&nbsp;4 говорит о том, что в компании должна быть настроена оптимизация процессов на основе показателей. А CMMI&nbsp;5 - что сам процесс оптимизации тоже должен оптимизироваться. Дальше вопрос - что именно мы вкладываем в понятие "оптимизация". Максималисткий подход - рассматривать оптимизацию как поиск оптимума (логично, правда), который еще должен быть достаточно быстрым - чтобы придти близко к оптимуму за то время, пока окружение можно считать квазистатичным.
+Мысль вторая. Я тут пересмотрел презентацию Джефа Сазерленда на [http://www.secr.ru/lang/ru-ru/program/presentations SECR], и вспомнил вещь, на которую обратил внимание еще на конференции. Для Джефа развитие компании идет так: CMMI&nbsp;1 &rarr; CMMI&nbsp;5 &rarr; CMMI&nbsp;5+SCRUM. Я обсудил это с коллегами, с их точки зрения CMMI5 и SCRUM - вещи слабо совместимые. На самом деле, тут вопрос оценки CMMI. CMMI&nbsp;4 говорит о том, что в компании должна быть настроена оптимизация процессов на основе показателей. А CMMI&nbsp;5 - что сам процесс оптимизации тоже должен оптимизироваться. Дальше вопрос - что именно мы вкладываем в понятие "оптимизация". Максималисткий подход - рассматривать оптимизацию как поиск оптимума (логично, правда), который еще должен быть достаточно быстрым - чтобы придти близко к оптимуму за то время, пока окружение можно считать квазистатичным.
 А можно рассматривать это иначе, понимая под оптимизацией всего лишь процесс, направленный на улучшение чего либо. То есть некоторые регулярные мероприятия, в рамках которого формулируются шаги по улучшению некоторого процесса, которые потом воплощаются. И достаточно, если шаги будут в среднем правильными. И если оценивать так, то CMMI&nbsp;4 в SCRUM есть - это ретроспектива. На которой, в числе прочего, следует обсуждать показатели работы команды - burndown (и другие показатели), придумывая меры по их исправлению, которые затем будут воплощены. А чтобы получился CMMI&nbsp;5 - нужно еще ретро по ретре, и процесс обмена всем этим опытом в рамках компании (процесс обмена и для CMMI&nbsp;4 нужен).

@@ Строка 5: / Строка 5: @@
 Надо сказать, что мысль о принципиальном отсутствии унифицированного процесса звучит не слишком ярко. И, более того, не воспринимается многими как сторонниками так и противниками agile. Сторонники получаются догматическими приверженцами определенных вариантов, а противники - указывают на провалы и вообще на "проблемы с методологией". Потому что многим людям очень хочется, чтобы было некоторое "правильное государство", "правильная методология", "правильный процесс" - такая постановка близка их мышлению.
-Мысль вторая. Я тут пересмотрел презентацию Джефа Сазерленда на [http://www.secr.ru/lang/ru-ru/program/presentations SECR], и вспомнил вещь, на которую обратил внимание еще на конференции. Для Джефа развитие компании идет так: CMM&nbsp;I-1 &rarr; CMMI&nbsp;5 &rarr; CMMI&nbsp;5+SCRUM. Я обсудил это с коллегами и для ряда из них CMMI5 и SCRUM - вещи слабо совместимые. На самом деле, тут вопрос оценки CMMI. CMMI&nbsp;4 говорит о том, что в компании должна быть настроена оптимизация процессов на основе показателей. А CMMI&nbsp;5 - что сам процесс оптимизации тоже должен оптимизироваться. Дальше вопрос - что именно мы вкладываем в понятие "оптимизация". Максималисткий подход - рассматривать оптимизацию как поиск оптимума (логично, правда), который еще должен быть достаточно быстрым - чтобы придти близко к оптимуму за то время, пока окружение можно считать квазистатичным.
+Мысль вторая. Я тут пересмотрел презентацию Джефа Сазерленда на [http://www.secr.ru/lang/ru-ru/program/presentations SECR], и вспомнил вещь, на которую обратил внимание еще на конференции. Для Джефа развитие компании идет так: CMM&nbsp;I-1 &rarr; CMMI&nbsp;5 &rarr; CMMI&nbsp;5+SCRUM. Я обсудил это с коллегами, с их точки зрения CMMI5 и SCRUM - вещи слабо совместимые. На самом деле, тут вопрос оценки CMMI. CMMI&nbsp;4 говорит о том, что в компании должна быть настроена оптимизация процессов на основе показателей. А CMMI&nbsp;5 - что сам процесс оптимизации тоже должен оптимизироваться. Дальше вопрос - что именно мы вкладываем в понятие "оптимизация". Максималисткий подход - рассматривать оптимизацию как поиск оптимума (логично, правда), который еще должен быть достаточно быстрым - чтобы придти близко к оптимуму за то время, пока окружение можно считать квазистатичным.
 А можно рассматривать это иначе, понимая под оптимизацией всего лишь процесс, направленный на улучшение чего либо. То есть некоторые регулярные мероприятия, в рамках которого формулируются шаги по улучшению некоторого процесса, которые потом воплощаются. И достаточно, если шаги будут в среднем правильными. И если оценивать так, то CMMI&nbsp;4 в SCRUM есть - это ретроспектива. На которой, в числе прочего, следует обсуждать показатели работы команды - burndown (и другие показатели), придумывая меры по их исправлению, которые затем будут воплощены. А чтобы получился CMMI&nbsp;5 - нужно еще ретро по ретре, и процесс обмена всем этим опытом в рамках компании (процесс обмена и для CMMI&nbsp;4 нужен).
-Естественно, так происходит не в любом SCRUM, нужно как минимум желание и усилия в этом направлении. И надо сказать, что слушая истории о конкретных командах от Джефа (и от Книберга тоже) - вполне допускаешь, что в конкретных компаниях, в них фигурирующих, SCRUM действительно означает CMMI&nbsp;5.
+Естественно, так происходит не в любом SCRUM, нужно как минимум желание и усилия в этом направлении. И я не уверен, что во всех командах у нас в компании действительно есть оптимизация процесса на основе показателей - потому как идеи высказываются, а воплощение они получают не всегда. Хотя стремления - есть. Но, надо сказать, что слушая истории о конкретных командах от Джефа (и от Книберга тоже) - вполне допускаешь, что в конкретных компаниях, в них фигурирующих, SCRUM действительно означает CMMI&nbsp;5.