?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Auftragstaktik!

Posted on 2008.05.29 at 01:13

Comments:


Alexey Tigarev
t_gra at 2008-05-29 15:58 (UTC) (Link)
    Не являются выходом и декларации agile - фактический отказ от управления требованиями, и стратегия проигравшего на мизере - "забрать все свои", чтобы не схватить "паравоз". Нам бы помог принцип aftragstaktik - здорово было бы, если бы исполнители сами исправили неточность в требованиях, "выполнив не букву приказа, а дух", но как воплотить его в жизнь?

Как по мне, как раз в Agile что-то похожее на auftragstaktik.
Здесь нет отказа от управления требованиями. Требования просто остаются высокоуровневыми, пока не потребуется спуститься ниже.

Роль "духа приказа" в каждой User Story выполняет business value, которую каждая Story должна нести и которую должна выражать её формулировка.

Я имею в виду такую форму представления User Story:

Как роль
Я могу действие
Так что цель, польза, ценность, business value

Ну и вдобавок я безусловно считаю разумным в начале проекта/продукта писать полумаркетинговый документ, например то, что у Карла Вигерса называется Vision & Scope Document.
Gaperton
gaperton at 2008-05-31 00:36 (UTC) (Link)
За Vision & Scope Вигерса спасибо. Скачал его шаблон документа - мне очень понравилось. Великолепный шаблон. Он лучше, чем мой шаблон Project Charter - при той же установке автора. Вообще - мне уже не один раз говорят, когда я пишу про требования, что это похоже на Вигерса. :) Пожалуй, надо мне почитать Вигерса, раз все так похоже :). Закажу книгу.

Насчет agile. Отказ от управления требованиями на самом деле есть. Вы мне приводите в пример скрам, у него юзер сторисы - реально неплохая практика. Но где в скраме прописан процесс сбора, анализа и проверки этих требований? Да нигде. У них контроль - только в конце итерации. Которую в месяц при сложной продуктовой разработке не уложишь. Если, конечно, следовать хорошим практикам при разработке больших систем - таким как "метод фреймворка". Или - близкий к нему "метод DSL".

Помимо этого, для многослойных систем следование юзер стори - отольется провалом. Когда у вас этих стори много, и много вариантов настройки системы, влияющих на них - у вас будет комбинаторный взрыв. Не покроете вы юзер сторями нихрена. По хорошему - в такой ситуации надо свернуть эти стори к простым элементарным операциям, ДОКАЗАТЬ, что в их терминах выразим интересующий нас класс юзер стори, после чего спокойно приступить к проектированию, имея в виду простые операции плюс несколько основных сценариев.

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

Видите ли, auftragstaktik - это на самом деле залог успеха waterfall. Хотя он совершенно не зависит от процесса.
Previous Entry  Next Entry