'

Декларативное планирование

Понравилась презентация – покажи это...





Слайд 0

Декларативное планирование


Слайд 1

Современное состояние дискуссии о разработке ПО Две позиции, и актуальные проблемы


Слайд 2

Две позиции “Defined” Process (CMMI) Повторяемость и воспроизводимость процесса, понимаемого как набор активностей. Взгляд на процесс как на изготовление артефактов, акцент на процедуры контроля их качества. Точное следование «зрелому» процессу повышает качество результата и снижает риски всей разработки. Процесс планируется и контролируется метриками. “Empiric” Process (Agile) Процесс креатива не воспроизводим и не повторяем, активности могут быть разные. Разработка - решение проблем пользователя, акцент на получение ранней обратной связи. Bullshit. Следование процессу не может давать никаких гарантий адекватности результата. Процесс итеративен и контролируется быстрой обратной связью.


Слайд 3

Обе по своему верны Иначе бы не было дискуссии. Планирование и координации деятельности сложных проектов является проблемой. Empiric-agile методы не дают ответа. Сетевое планирование и практики PMBoK – исходят из позиции “defined process”, и эти методы плохо подходят для разработки ПО. Они из альтернативной реальности, в которой в разработке ПО успешно работает waterfall.


Слайд 4

Разработка ПО Неполные и/или противоречивые требования. Не всегда ясно, что надо получить в конце. В том числе – неясно пользователю. Неизвестные наперед способы решения проблем. Не всегда ясно, как «это» надо делать. Иногда непонятно, можно ли сделать вообще. Неизвестные наперед проблемы. А если кажется, что ясно и понятно, то этому ощущению нельзя доверять.


Слайд 5

Разработка ПО – Problem Solving В чем мы вообще можем быть уверены? В постановке проблем. Пользователь обычно осознает свою проблему, но не всегда знает, как ее решить. Список требований –описание решения его проблем, которое ставит проблемы разработчику. Разработчик часто знает проблемы, которые мешают ему быстро спроектировать систему. Дизайн – подход к решению этих проблем. QA знает проблемы, мешающие выпуску ПО. База дефектов – описание этих проблем. Разработка в большей степени процесс решения проблем, чем изготовления артефактов.


Слайд 6

Проблема остается Заранее неизвестны: структура результата; часто – технология его «изготовления», ее еще надо придумать; список активностей по его «изготовлению». Характер активностей и структура зависят от того, каким образом будут решены проблемы. Разработка – сплошные проблемы, и активности со структурой меняются по ходу разработки. Планы в терминах активностей трудно составлять, и они быстро перестают быть актуальными. Потребность в планировании и координации деятельности на сложных проектах никуда не делась.


Слайд 7

Auftragstaktik - подход военных «Auftragstaktik - странное немецкое слово, обозначающее специфический подход к военному делу. Его почти невозможно перевести на английский, его крайне трудно объяснить, и ещё труднее — понять»


Слайд 8

Две позиции Befehlstaktik Выдача детализированных приказов в терминах действий. Исполнитель выполняет приказы руководителя, проявляя «разумную инициативу». Приказ должен быть выполнен точно, беспрекословно, и в срок. Следование приказу является оправданием в случае неудачи. Auftragstaktik Выдача «миссии», проблемы, которая должна быть решена. Выработка действий и решений – обязанность подчиненных. Исполнитель обязан руководствоваться собственным видением ситуации и намерением руководителя. Бездействие трактуется хуже, чем действие, оказавшееся впоследствии ошибкой.


Слайд 9

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


Слайд 10

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


Слайд 11

Innere Fuhrung «внутреннее руководство» Подчиненный - свободная личность. Его индивидуальность и чувство собственного достоинства уважаются так же, как и его права и свободы. Руководство у него исходит изнутри, а не снаружи. За ним не надо следить, его достаточно направлять. Только свободный человек будет действовать по собственной воле, проявляя инициативу и двигаемый чувством ответственности.


Слайд 12

Микроменеджмент Недопустимо игнорировать промежуточные уровни управления, непосредственно вмешиваясь в работу исполнителей. Руководитель, кто пытается указать все детали, обречен в них запутаться. Он потеряет контроль над ситуацией и потерпит неудачу. Он подрывает основы их действий, и повышает риск тактических ошибок, не владея полной информацией. И главное, он теряет их поддержку, и остается с проблемами один на один.


Слайд 13

Микроменеджмент и IT С развитием информационных систем скорость передачи информации перестала быть проблемой. Это создает ложное впечатление, что у руководителей больше информации для принятия решений, и стимулирует микроменеджмент. Однако обработка информации – как была, так и остается проблемой. Возможности человека по ее обработке не изменились. Auftragstaktik - это ключ к успешной обработке информации и принятию решений, и, как следствие, к эффективному управлению.


Слайд 14

Декларативное планирование Модель представления плана, дружественная к Auftrastaktik.


Слайд 15

Сетевой график = befehlstaktik План - как последовательность действий, которые надо выполнить Группировка простых действий в более сложные


Слайд 16

Активности -> Цели Beheflstaktik Активность, протяженная во времени; Приказ в терминах действий - что делаем, чем занимаемся. 4 типа зависимостей (ОН, ОО, НН, НО) Auftragstaktik Событие, которое случается одномоментно; Проверяемый критерий наступления события, решения проблемы, «выполнения миссии». Единственный тип зависимости.


Слайд 17

«Карта целей» - Auftragstaktik План - как группа зависимых целей, которых надо достичь. Группировка Отделение главных целей от промежуточных


Слайд 18

Переход к общему плану Частные цели могут быть выкинуты из общего плана при сохранении семантики.


Слайд 19

Составление плана «от цели» Обратное не всегда верно; Поиск верных обратных утверждений – это поиск промежуточных целей, ведущих к главной; Выбор подхода к крупной проблеме, подразбивая ее на мелкие – и есть процесс составления плана.


Слайд 20

Свойства Фокус на критериях проверки - контроле качества, от “defined process”. Фокус на решение проблем – от “empiric process” и auftragstaktik. План не ограничивает свободу действий подчиненных. Auftragstaktik! План допускает логические проверки. Теперь при планировании надо думать. ?


Слайд 21

Основные паттерны планирования Да, в планах тоже встречаются паттерны. Это процессы.


Слайд 22

Цикл разработки RUP


Слайд 23

Процесс решения проблем


Слайд 24

Итеративные активности Итеративные активности полезно «брать в скобки» парой событий «начало-окончание», с четкими критериями достижения.


Слайд 25

Прогресс итеративной активности Можно вводить промежуточные цели для контроля прогресса, если есть четкие критерии их достижения.


Слайд 26

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


Слайд 27

Конвейерные процессы Активности по достижению целей могут начинаться до завершения предыдущих целей


Слайд 28

Планирование разработки ПО И как в конце концов составлять план?


Слайд 29

Это все хорошо, но... …как получить не общий абстрактный «процесс», а план для конкретного проекта? ...как я могу составить план, если я не знаю, как будет устроена моя программа? ...как сделать план, который не разойдется с реальнстью в первые же недели?


Слайд 30

Классы и модули? Функции и тесты! Целью является работоспособность функций ПО, и эффективное решение проблем пользователя. Критерием реализации функции и достижение цели является прохождение теста (процедуры контроля) и проверка решения проблемы. План – в каком порядке достигать целей, и как проверять их достижение.


Слайд 31

Функциональный критерий связности Цели по реализации функций A и B несвязны, если при интеграции реализованных функций не может проявится ошибок. Количество возможных ошибок при интеграции характеризует связность. Слабосвязаенные цели могут достигаются впараллель. Сильносвязные – последовательно.


Слайд 32

Общие и «системные» функции Пользовательские функции A и B полагаются на общую «системную» функцию C.


Слайд 33

Общие и «системные» функции Пользовательские функции A и B полагаются на общую «системную» функцию C. Реализация «системной» функции разделена на два этапа, и делается в рамках работ по пользовательским функциям.


Слайд 34

Выбор порядка реализации функций Квадрат риск-приоритет


Слайд 35

Спасибо за внимание! Владислав Балин, НТЦ «Модуль» gaperton@gmail.com


×

HTML:





Ссылка: