?

Log in

No account? Create an account

Previous Entry | Next Entry

В свое время gaperton писал про загадочную вещь с непонятным названием Auftragstaktik. Почитал и мне понравилось. Немногим позже в личной беседе gaperton поделился со мной своим опытом составления плана в виде сложного логического выражения (с использованием темпоральной логики и прочих прелестей науки). Мне эта идея показалась очень интересной и я решил опробовать это в деле, выбрав небольшой, но важный проектик.

Идея Auftragstaktik проста:
"Суть Auftragstaktik в нашем случае в том, что все управление ведется от проблем. Проблема - единица планирования. Из них состоит весь план. Вы не ставите человеку задачу сделать что-то. Вы поручаете ему решить проблему."
Дословно списано отсюда

И так. Цель проекта заключается в том, что нужно модифицировать имеющийся программный комплекс для реализации простого сценария: Поставщик хочет пересылать дополнительную информацию Клиенту.
Имеющееся решение способно принимать команды от Поставщика, меняющие состояние Клиента, посредством модификации чудо-файлов, который Клиент периодически стягивает из хранилища. Существующая архитектура решения примерно такая:
Поставщик <-> Фронтенд <-> Бэкенд -> Чудо-модуль генерации чудо-файлов -> хранилище чудо-фалов -> Клиент

Понимаю, что ничего не понятно, но, думаю, для описания сути такого уровня подробностей достаточно.

Фактически, линия передачи информации от Поставщика к Клиенту есть, но в текущем виде задачу не решает, так как в каждом узле цепочки есть свои ньюансы, требующие допила.

Каким может быть план? Самый плохой вариант плана, который я только могу себе представить, это что-то вроде этого (дословно):
  1. Фронтенд
  2. Синхронизация Фронтенда с бекендом
  3. Бэкенд
  4. Синхронизация Бэкенда с чудо-модулем
  5. Клиент
Здесь меня коробит не говорящая формулировка задач (кстати, встречаю такое очень часто). Я являюсь сторонником формулировать задачи, как ответ на вопрос: "Что сделать?" (именно Сделать, а не делать). Список задач в виде существительных вызывает у меня отвращение. Что бы сделать план еще более ужасным, нужно эти 5 строчек как есть скопипастить в программу рисования диаграмм Гантта, расставить связи и добавить в конце кусочки "Тестирование" и "Исправление ошибок" (естественно, вставив конкретную цифру в графу "длительность" - ну а фигле, мы же и так знаем сколько займет исправление еще не найденных ошибок в еще не написанном софте!) ...

Если бы я не играл в Auftragstaktik, то я бы составил план примерно так:
  1. Реализовать поддержку новой команды фронтендом
  2. Модифицировать модуль синхронизация фронтенда с бекендом для передачи новых параметров
  3. Дополнить модуль бэкенда логикой обработки нового параметра
  4. Реализовать механизм передачи новых параметров в чудо-модуль
  5. Создать модуль чтения новых параметров из чудо-файла
Теперь каждая задача своим ответом отвечает на вопрос "Что сделать?". Дальше останется выставить относительные оценки  трудозатрат по задачам и рисовать по ним берн-даун для наблюдением за ходом работ.

Мое понимание Auftragstaktik родило следующий план:
  1. Параметры из новой команды сохраняются во временном хранилище фронтенда
  2. Модуль синхронизация фронтенда с бекендом получает параметры новой команды
  3. Бэкенда генерирует необходимую информацию по новым параметрам
  4. Чудо-модуль принимает новую информацию от бекенда
  5. Клиент считывает новые параметры из чудо-файла
Опять, казалось бы, словоблудие и банальная перетасовка слов. Однако теперь каждая задача содержит ответ на вопрос "Как я пойму, что я это сделал?". Получается своеобразный чек-лист, задача выполнена, когда проставлены все галки, другими словами логическое выражение (он же план) выглядит так: проект завершен, если справедливо "1" И "2" И "3" И "4" И "5".

Предыдущий вариант формулирования задач в терминах действия обладал одним мерзким недостатком - когда приходит время человеку нужно ответить на вопрос: "Я смог Реализовать поддержку новой команды фронтендом?". Не многие по отношению к задачам мыслят бинарно:
- Да, смог
- Все готово?
- Да, все
- А что еще осталось?
- ...
И в ряде случаев на последний вопрос находится что ответить...

Тут проще. Спрашиваем себя: "Правда ли что Параметры из новой команды сохраняются во временном хранилище фронтенда?". Если ответ "Да", то ставим галку и идем дальше (будет вообще прелестно, если на этот вопрос будет отвечать автоматический тест).

Что еще круче, план такого вида может включать в себя и альтернативные сценарии развития проекта, посредством добавления утверждений и связи ИЛИ. Но про это потом...
 

В этом блоге можно найти еще что-нибудь интересное

Comments

( 40 comments — Leave a comment )
yakov_sirotkin
Jun. 15th, 2010 06:57 pm (UTC)
А разве разработчики не могли бы сами предложить архитектуру?
cartmendum
Jun. 15th, 2010 07:05 pm (UTC)
Разработчики предложили ее максимально сохранить, и использовать существующее решение по максимуму.
План составлялся по более-менее готовой архитектуре. Вариант альтернативы тоже рассматривался. Про это я напишу, когда буду раскрывать тему использования оператора ИЛИ в плане.

А вообще в такие детали я не лезу (если вопрос об этом). Желание учить разработчиков разработке меня оставило уже достаточно давно :)
gaperton
Jun. 15th, 2010 08:18 pm (UTC)
> Я являюсь сторонником формулировать задачи, как ответ на вопрос: "Что сделать?" (именно Сделать, а не делать).

"Сделать", "делать" - разница небольшая. Раз уж ты заинтересовался "тактикой миссии" - делай это правильно, и попробуй вместо этого при формулировке заданий отвечать на вопрос "как проверить, что задача завершена".

Это гораздо интереснее. Ибо, задания, для которых ты затрудняешься с ответом на данный вопрос - очевидно, не имеет смысла выдавать. И пытаясь задать этот вопрос для каждой задачи в своем плане, ты встретишь удивительно много таких задач :). Попробуй.

> другими словами логическое выражение (он же план) выглядит так: проект завершен, если справедливо "1" И "2" И "3" И "4" И "5".


Ну какой это "план". В плане есть время - это его отличительная особенность. А в твоем утверждении времени нет - это не более чем критерий завершения проекта. Ведь ты используешь обычную логику. А чтобы из этого сделать план, и он остался логическим утверждением, тебе надо использовать _темпоральную_ логику.

Это - вид модальных логик, в которых операции вроде "событие с условием А не может произойти раньше, чем событие с условием Б" введены в аксиоматику.

Выражаясь проще - имея условие вида P1 & P2 & ... & PN тебе надо понять, какие из этих Pi могут быть проверены независимо от остальных, и, соответственно, раньше.

Вот тогда ты получишь план в виде логического утверждения.

Говоря о формализме - для той логики, которую использую я (а это простейший вариант темпоральной логики), верно следующее свойство операции "раньше чем":
A -> B => A & B

То есть, если А произойдет не позже, чем В, то настанет момент, когда будет верно одновременно А и В. Другими словами, я предполагаю, что работаю с условиями событий, которые переходят в true однажды и навсегда.

Вот так.
cartmendum
Jun. 16th, 2010 05:35 pm (UTC)
попробуй вместо этого при формулировке заданий отвечать на вопрос "как проверить, что задача завершена"
Верно говоришь. Критерий завершения мы формулируем, но он записывается в детали задачи. В заголовок он стабильно не помещается.
В появление удивительно большого количества дополнительных задач при формулировании критерия завершения верю. Проверяли - это действительно так :)

А в твоем утверждении времени нет - это не более чем критерий завершения проекта.
Тут полностью согласен, да это критерий завершения.

А чтобы из этого сделать план, и он остался логическим утверждением, тебе надо использовать _темпоральную_ логику
Вот про это буду еще читать дополнительно. Про нее я только краем уха слышал, но сам аппарат никогда не вникал.



Спасибо, что появился! :)
(no subject) - gaperton - Jun. 16th, 2010 07:53 pm (UTC) - Expand
gaperton
Jun. 15th, 2010 09:25 pm (UTC)
И еще один момент. Сейчас ты занимаешься на самом деле не Auftragstaktik, а моим "декларативным планированием".

Auftragstaktik - эти принцип лидерства. Цитируя первоисточник, которым является устав немецкой армии, -
"Руководитель доводит до подчиненных свои намерения, устанавливает ясные и достижимые цели, и предоставляет необходимые силы и ресурсы. Он укажет детали относительно выполнения только в случае, если разные меры, которые служат той же самой цели, должны быть согласованы, или если этого требуют политические или военные ограничения. Он дает своим подчиненным свободу в выполнении их миссии."

Самое важное выделено болдом. Планировать свою работу - задача исполнителя. У тебя пять задач. Сколько у тебя исполнителей для твоего проекта, и каковы точки координации?

Вот об этом ты должен думать, планируя в терминах Auftragstaktik, чтобы не удариться в микроменеджмент. Составлять планы для себя - работа исполнителя, ты как менеджер должен уделять внимание деталям только в случае, когда разные работы должны быть скоординированы.

Ибо реальное планирование начинается не тогда, когда ты рисуешь таски в MS Project - на это всем на самом деле плавать. А тогда, когда ты думаешь, как ты будешь поручать конкретную работу конкретным людям.

Чтобы поручить работу, и получить в результате то, что нужно - надо, очевидно, сделать чуточку больше, чем снабдить исполнителя названием задачи.

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

Промежуточный прогресс? ТЗ может содержать линейный набор из нескольких этапов, каждый - с проверяемым критерием завершения. Вот это - работает. Это, ironically, система планирования лежащая в основе советстких ГОСТ, по которым наша оборонка делала потрясающие проекты.

Резюмируя - Auftragstaktik, полагаясь на инициативу и "внутреннее руководство" исполнителей, ведет к уменьшению количества единиц планирования, и к увеличению информации на одно задание.
cartmendum
Jun. 16th, 2010 05:48 pm (UTC)
Сейчас ты занимаешься на самом деле не Auftragstaktik, а моим "декларативным планированием"
Тут тоже согласен. До тактики миссии тут еще далеко, мало того, на первый взгляд мой пост может попахивать микроменеджментом.

Auftragstaktik - эти принцип лидерства
И вот в этом нисколечко не сомневаюсь. А так как это принцип лидерства, то он требует и "особых" лидеров и "особой" команды.

У тебя пять задач. Сколько у тебя исполнителей для твоего проекта, и каковы точки координации?
Задачка плевая, а исполнителей 4 из 3-х "программистских княжеств", исторически сложившихся внутри отдела.
С точками синхронизации не мудрил - ежедневный стендап. За каждую цель отвечает вполне конкретный человек (один). Цели устроены так, что достоверно проверить "2" нельзя, пока достоверно не проверено "1". "3" нельзя достоверно проверить без "2" и т.п.

Чтобы поручить работу, и получить в результате то, что нужно - надо, очевидно, сделать чуточку больше, чем снабдить исполнителя названием задачи.
Это тоже понятно. Помимо названий задач есть бумажка с ТЗ из которой совместными усилиями и получился "чек-лист" завершения.

И каждое ТЗ - формулирует цель, в форме проверяемого критерия его достижения.
Ага. А так же обладает свойством полноты и непротиворечивости. Угадал?

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


Резюмируя - Auftragstaktik, полагаясь на инициативу и "внутреннее руководство" исполнителей, ведет к уменьшению количества единиц планирования, и к увеличению информации на одно задание.
Вот тут не понял, почему увеличивается количество информации на одно задание? Правильно ли я понимаю, что в ТЗ должно быть описано что-то еще, чего обычно не описывают? (объективный критерий завершения я включаю в "обычно описывают")
(no subject) - gaperton - Jun. 16th, 2010 07:44 pm (UTC) - Expand
bustor
Jul. 2nd, 2010 09:39 am (UTC)
>> Это, ironically, система планирования лежащая в основе советстких ГОСТ

Можно парой фраз и/или ссылок раскрыть этот тезис? Для более четкого понимая. Спасибо.
(no subject) - gaperton - Jul. 5th, 2010 12:48 pm (UTC) - Expand
(no subject) - bustor - Jul. 5th, 2010 05:42 pm (UTC) - Expand
gaperton
Jun. 15th, 2010 10:02 pm (UTC)
И последнее
> Немногим позже в личной беседе gaperton поделился со мной своей идеей составления плана в виде сложного логического выражения.

И в догонку. Маленькая, но значительная деталь. Поделился я с тобой не "идеей", а практическим опытом.

Из состояния "идеи" в разряд "метода" это вышло четыре года назад. Когда с этой методикой был составлен план разработки микросхемы + софта декодера цифрового ТВ в проекте с бюджетом на 8 миллионов долларов. Для чего она и была разработана - без этого план такого проекта составить и проверить тупо не получалось. Микросхема, кстати, будет выпущена этой осенью.

Метод разработан, и имеется практика его применения в разнообразных областях - микроэлектроника, системное ПО, прикладное ПО, разработка серверных корпусов, программно-аппаратные комплексы, проекты внедрения.
bialix [launchpad.net]
Jun. 16th, 2010 07:03 am (UTC)
Re: И последнее
интересуюсь: об этом методе подробнее и с примерами уже можно где-то почитать/посмотреть? если нет, то будет ли в будущем?
cartmendum
Jun. 16th, 2010 05:56 pm (UTC)
Re: И последнее
Гугл дает кое-какие намеки.

Например:
http://www.scribd.com/doc/15670827/John-Boyd-Lessons-from-a-fighter-pilot
или
http://www.lib.ncsu.edu/theses/available/etd-03282006-212926/unrestricted/etd.pdf

Но широкой популярности у этого подхода пока нет. Под широкой популярностью я имею ввиду массу написанных книг и кучу предлагаемых тренингов.
gaperton
Jun. 16th, 2010 05:57 pm (UTC)
Re: И последнее
Я давно собираюсь систематизировать материал, и привести его в порядок. Проблема в том, что я очень ленив. Но, тем не менее:

Вот презентация с моего первого доклада по "декларативному планированию" на SWP 2009
http://www.slideshare.net/guest59129b8/auftragsplanning-pre-final

Перед просмотром презентации - полезно прочитать вот это. Это более поздний материал. http://gaperton.livejournal.com/45149.html

Есть более свежая презентация на эту тему, - из моего тренинга по организации разработки хай-тек проектов. Тренинги и конференции - вообще двигатель прогресса. Они мотивируют. Презентацию пока не выложил. Но скоро сделаю.

Пояснение по поводу темпоральной логики и "декларативного планирования". Показывает главное отличие от сетевого графика. Это важно, даже если не заморачиваться "теоретическими основами".
http://gaperton.livejournal.com/30325.html

Совсем ранний материал - я тогда еще ничего не знал про Auftragstaktik. Штука в том, что "декларативное планирование" как методика была изобретена и применена сильно раньше, чем я ознакомился с этим замечательным командным принципом. Хотя - он отлично ложится на "декларативное планирование", формируя единую философию и подход к управлению.
http://gaperton.livejournal.com/16087.html
cartmendum
Jun. 16th, 2010 05:52 pm (UTC)
Re: И последнее
Поделился я с тобой не "идеей", а практическим опытом.
Извини, конечно же опытом :) Поправил

А сколько оно шло от идеи до опыта? Сколько в итоге получилось единиц планирования на проект? Не собираешься ли как-нибудь написать ретроспективу применения этого метода? А кто-нибудь еще этот метод использует или пока это "эксклюзив"?
Re: И последнее - gaperton - Jun. 16th, 2010 07:00 pm (UTC) - Expand
Re: И последнее - gaperton - Jun. 16th, 2010 07:15 pm (UTC) - Expand
Re: И последнее - bialix [launchpad.net] - Jun. 17th, 2010 09:47 am (UTC) - Expand
Re: И последнее - cartmendum - Jun. 19th, 2010 08:31 am (UTC) - Expand
Re: И последнее - gaperton - Jun. 20th, 2010 10:42 pm (UTC) - Expand
Re: И последнее - cartmendum - Jun. 21st, 2010 09:44 am (UTC) - Expand
Re: И последнее - gaperton - Jun. 21st, 2010 08:20 pm (UTC) - Expand
Re: И последнее - gaperton - Jun. 21st, 2010 08:26 pm (UTC) - Expand
И еще - gaperton - Jun. 21st, 2010 08:32 pm (UTC) - Expand
Re: И еще - gaperton - Jun. 21st, 2010 08:38 pm (UTC) - Expand
maksim_gr
Jun. 16th, 2010 07:41 am (UTC)
Интересно, стоит подумать о том, как это использовать в тестировании - ведь мне зачастую нужен обратный результат - Нет проблем...
cartmendum
Jun. 16th, 2010 06:03 pm (UTC)
Тестирования, разработка... Какая разница? Auftragstaktik - это подход к решению проблем более высокого уровня абстракции.

Думаю этот стиль ляжет на тестирование не сложнее, чем на разработку. Нужен только объективный критерий достижения цели, то есть возможность ответить на вопрос "Правда ли, что я протестировал это достаточно хорошо?".

В качестве критерия завершения тестерской задачи можно выбрать, например, следующий:
1. Покрытие кода по уровню (вставить нужное из "Statement Coverage"/"Decision Coverage"/"Modified Condition/Decision Coverage") составляет не менее XX%
2. Покрытие требований составляет не менее YY%
3. Все аномалии, обнаруженные в ходе теста имеют описание.


ну или что-то вроде этого.
gaperton
Jun. 18th, 2010 02:08 pm (UTC)
Auftragstaktik и тестеры
Вполне себе вариант. Примерно так я формулировал эту цель пару лет назад.

Тока - теперь я бы плясал от другого. Глядя на данный критерий - возникает вопрос - а то ли это, что мы на самом деле хотим от тестирования? Зачем вообще нужны тестеры? Пользователю есть разница - 100% кода у нас покрыто тестами, или нет? А вдруг - на практике 95% пользователей своими действиями покрывают только 40% кода? А может быть, пользователи страдают больше от неудобства и неинтуитивности гуя, чем от его несоответствия 60% кода, который они не вызывают, вызывают редко, или вполне могут без его функциональности обойтись - нашим внутренним спецификациям?

Так зачем нам все-таки нужны тестеры? Чтобы это понять, давай тестеров уберем. Пользователь станет недоволен, не так-ли? Но скажет ли он при этом что-нибудь про "низкий процент покрытия"? Вряд ли - он будет недоволен потому, "что вашей программой невозможно пользоваться. Вот у вас в фичлисте на сайте написано вот это - а оно либо не работает, либо делается через жопу".

Мы этого не хотим, и поэтому, а не почему-нибудь еще, заводим тестеров. Получаем в результате интересную штуку. Следуя Auftragstaktik, миссия тестеров формулируется иначе.

Тестеры - это такой мегакомпетентные парни и девчонки, которые:
- вместо того, чтобы накрыть программера матюгами, способны внятно и точно описать найденную проблему. С позиции пользователя.

Это означает, что они для выполнения своей миссии должны проверять вовсе не соответствие поведения проги бумажке (пользователя волнует эта внутренняя бумажка? да пофиг ему). Он должен удостовериться в ценности реализованной фичи для пользователя - в том, что реализованная возможность решает ту проблему пользователя, ради которой создана данная фича.

Тестер, который работает по Auftragstaktik - профессионал высокого класса. Он понимает проблемы пользователя, и компетентен в предметной области. Он умеет отличать неинтуитивное поведение от простого и удобного. Он разбирается в вопросах юзабилити.

И он тестирует поведение не на соответствие бумажке, а на соответствие духу, замыслу, проблеме - ради решения которой фича сделана.

Чтобы это сделать - он должен, тестируя фичу, как минимум, быть знакомым с проблемой - так? И было бы в корне неправильно снабжать тестера информацией, которая будет недоступна пользователю. Он должен располагать той же документацией, которая есть у пользователя, чтобы в том числе найти несоответствие документации программе. И чтобы выписывать дефекты на документацию.

В работе тестера можно выделить два последовательных этапа.
1. Тестер полностью протестировал фичу, выдав обратную связь.
2. Тестер подтвердил, что фича готова к выпуску.

Продолжая предлагаемую логику, задание группе тестеров выдается в виде фичлиста. У каждой фичи - три цвета (красный, желтый, зеленый), соответствующее текущему закрытому этапу. Прогресс (и готовность продукта у выпуску) на высоком уровне отслеживается, например, по общему проценту желтости, зелености, или красности фичлиста.

План тестирования можно структурировать и упорядочить, объединяя фичи (и их юзкейсы) в группы (по самым разным признакам - здесь очень много вариантов), и упорядочивая их по времени.

И этот план тестирования может стать основой для плана разработки.

Вот один из вариантов, который на мой взгляд, в полной мере полагается на Auftragstaktik.
Re: Auftragstaktik и тестеры - cartmendum - Jun. 19th, 2010 08:35 am (UTC) - Expand
Re: Auftragstaktik и тестеры - gaperton - Jun. 20th, 2010 11:11 pm (UTC) - Expand
Re: Auftragstaktik и тестеры - gaperton - Jun. 20th, 2010 11:25 pm (UTC) - Expand
Re: Auftragstaktik и тестеры - aaa111 - Jul. 7th, 2010 12:31 pm (UTC) - Expand
Re: Auftragstaktik и тестеры - gaperton - Jul. 7th, 2010 12:46 pm (UTC) - Expand
Re: Auftragstaktik и тестеры - aaa111 - Jul. 8th, 2010 10:19 am (UTC) - Expand
Re: Auftragstaktik и тестеры - gaperton - Aug. 5th, 2010 11:20 am (UTC) - Expand
Re: Auftragstaktik и тестеры - zuzo - Jun. 23rd, 2010 10:09 pm (UTC) - Expand
Re: Auftragstaktik и тестеры - cartmendum - Jun. 24th, 2010 08:31 am (UTC) - Expand
Re: Auftragstaktik и тестеры - zuzo - Jun. 24th, 2010 01:34 pm (UTC) - Expand
Re: Auftragstaktik и тестеры - zuzo - Jun. 24th, 2010 10:05 pm (UTC) - Expand
( 40 comments — Leave a comment )