![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
Декларативное планирование: презентация
Posted on 2009.05.21 at 23:56
Как и обещал, выкладываю презентацию к своему докладу.
http://files.rsdn.ru/20496/Auftragsplan
Краткое содержание.
Текущее состояние дискуссии о процессах разработки - специалисты разбились на два лагеря. defined process (CMMI), empiric process (Agile).
defined - процедуры контроля качества, взгляд как на доставку артефактов, акцент на повторяемость и воспроизводимость процесса, понимаемого как набор активностей, планирование, соблюдение технологии гарантирует качество.
empiric - соблюдение технологии не может гарантировать повторяемого результата. Акцент на итеративность и быструю обратную связь.
Каждые из них по своему прав. Проблема координации и планирования деятельности больших групп разработки остается открытой, и не решается средствами empiric.
Сетевой график, состоящий из активностей, в духе defined, не адекватен проектам разработки ПО - он из альтернативной реальности, в которой работает waterfall. Процесс разработки ПО представляет собой по сути процесс решения проблем, а не процесс доставки артефактов, и характер активностей так же как и структура артефакта может меняться по ходу работ. Активности просто нельзя заранее расписать.
Таким образом, проблема координации и планирования деятельности больших групп остается открытой, и не решается адекватно средствами defined.
Truth is out there. Как на проблему глядят военные. Более практичный взгляд.
Auftragstaktik vs Beheflstaktik. Приказ в терминах действий. Приказ - миссия.
- как отдавать приказы
- как исполнять приказы, тип подчиненного, и корпоративная культура.
- Behefldtaktik как микроменедмент.
В настоящее время все армии мира адаптировали auftragstaktik. Это наиболее совершенный командный принцип, известный на данный момент, который может и должен быть адаптирован в корпоративном контексте, на уровне всей организации, а не отдельных групп разработки.
Как решается проблема планирования. Сетевое планирование = befehlstaktik. Потому и плохо работает. Активности -> цели = решение проблем = auftragstaktik = разработка ПО. Альтернатива традиционному подходу к группировке задач. Разработка плана от конечной цели. Свойства предлагаемой модели.
Паттерны в планах = "процессы". То, что будет часто встречаться в ваших планах. Цикл разработки RUP - как общий процесс решения проблем. Как обходится с итеративной активностью. Как выражается параллельная активность, и "параметрические" планы (aka процессы). Семантика "декларативного" плана и его связь с активностями.
Планы в разработке ПО. Как их все-таки составлять. Подход к составлению плана от функций и тестов. "Декларативное" определение понятия связности. Общие "системные" функции, и как отражать их в плане.
http://files.rsdn.ru/20496/Auftragsplan
Краткое содержание.
Текущее состояние дискуссии о процессах разработки - специалисты разбились на два лагеря. defined process (CMMI), empiric process (Agile).
defined - процедуры контроля качества, взгляд как на доставку артефактов, акцент на повторяемость и воспроизводимость процесса, понимаемого как набор активностей, планирование, соблюдение технологии гарантирует качество.
empiric - соблюдение технологии не может гарантировать повторяемого результата. Акцент на итеративность и быструю обратную связь.
Каждые из них по своему прав. Проблема координации и планирования деятельности больших групп разработки остается открытой, и не решается средствами empiric.
Сетевой график, состоящий из активностей, в духе defined, не адекватен проектам разработки ПО - он из альтернативной реальности, в которой работает waterfall. Процесс разработки ПО представляет собой по сути процесс решения проблем, а не процесс доставки артефактов, и характер активностей так же как и структура артефакта может меняться по ходу работ. Активности просто нельзя заранее расписать.
Таким образом, проблема координации и планирования деятельности больших групп остается открытой, и не решается адекватно средствами defined.
Truth is out there. Как на проблему глядят военные. Более практичный взгляд.
Auftragstaktik vs Beheflstaktik. Приказ в терминах действий. Приказ - миссия.
- как отдавать приказы
- как исполнять приказы, тип подчиненного, и корпоративная культура.
- Behefldtaktik как микроменедмент.
В настоящее время все армии мира адаптировали auftragstaktik. Это наиболее совершенный командный принцип, известный на данный момент, который может и должен быть адаптирован в корпоративном контексте, на уровне всей организации, а не отдельных групп разработки.
Как решается проблема планирования. Сетевое планирование = befehlstaktik. Потому и плохо работает. Активности -> цели = решение проблем = auftragstaktik = разработка ПО. Альтернатива традиционному подходу к группировке задач. Разработка плана от конечной цели. Свойства предлагаемой модели.
Паттерны в планах = "процессы". То, что будет часто встречаться в ваших планах. Цикл разработки RUP - как общий процесс решения проблем. Как обходится с итеративной активностью. Как выражается параллельная активность, и "параметрические" планы (aka процессы). Семантика "декларативного" плана и его связь с активностями.
Планы в разработке ПО. Как их все-таки составлять. Подход к составлению плана от функций и тестов. "Декларативное" определение понятия связности. Общие "системные" функции, и как отражать их в плане.