Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Categories:

Встреча по PraxOS в SL: водопадная модель и гибкие методы

Что касается особенностей встречи именно в Second Life, то на эту тему смотреть http://community.livejournal.com/sl_ru/66607.html

Удалось обсудить тезис alexott: "Когда работаешь в гибких методах, то очень хочется зафиксировать хотя бы на какой-то срок коммуникацию, как это делается в водопадных методах".

Это высказывание можно уточнить следующим рассуждением:

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

2. В гибких методах, наоборот, подразумевается чуть ли не принудительная постоянная коммуникация, обеспечивающая текущее (а не фиксирующая прошлое) взаимопонимание разработчиков, и предписываются ее формы -- от парной работы до совместных сессий по формулированию stories, от стартовых встреч по проекту до "планирующей игры". Акцент делается на текущую коммуникацию, а вот формы фиксации полученных знаний -- планы как набор легко изменяемых карточек и коды. В водопадной модели планы -- это наборы многочисленных "утвержденных" документов, а вот сами коды появляются весьма не скоро и мало что фиксируют.

3. Из теории планирования известно, что постоянное перепланирование задает шум, прекращающий скоординированную работу многих исполнителей -- если их не буквально двое-трое. Это известная проблема, описанная в теории ограничений: если расчет оптимального плана работ делать ежедневно, то производство встанет (подробно обсуждается при анализе использования ERP-систем в реальном производстве, в частности в книжке Голдратта "Необходимо, но недостаточно", а также в многочисленных статьях). В агентском подходе про то же самое говорят "намерения должны сохраняться, ибо при часто меняющихся намерениях агентов взаимокоординация их становится невозможна -- все время начинает уходить не на работу, а на коммуникацию по выяснению текущей ситуации". Тут нужно обязательно учитывать, что PraxOS выделяет КомандуПроекта отдельно и СообществоПроекта отдельно -- и что ориентироваться тут нужно не только на коммуникацию по координации небольшого числа людей в КомандеПроекта, но на много большее по размеру СообществоПроекта (что обычно совершенно не учитывается).

4. Из той же теории планирования знаем, что план состоит из нескольких отдельных частей:
-- структуры работ, которая задается как иерархия целей/частных продуктов либо как иерархия операций
-- графика работ, который задается как последовательность выполнения действий (работ самого нижнего уровня структуры работ)
-- цепочек работ, которые задаются каким-то отдельным критерием выделения цепочки в структуре работ (например, критическая ресурсная цепочка -- которая проходит через ограниченный ресурс)
-- и т.д.
Важное отличие от водопадных методов -- в плане могут быть предусмотрены работы, выполнение которых необязательно (ср. планирование GTD у Дэвида Аллена, в которой в план заносятся и работы, которые будут выполняться "когда нибудь" -- в том числе и те, выполнение которых очень маловероятно. Важно, что в плане для таких работ отводится специальное место, чтобы эти работы не путались с важными и срочными!). В водопадных методах

5. В тех же самых гибких методах (в другой терминологии они сводятся к отождествлению проекта с микропрограммой и применению методов "управлению программами", ибо гибкие методы сводятся к взаимокоординации параллельно идущих микропроектов и выявлению на каждом шаге планирования, что делать в текущей ситуации успеха/неуспеха этих микропроектов) задается специальная дисциплина регулярного пересмотра планов (итерации, релизы) на основе сессий обеспечения группового понимания (коммуникационных мероприятий) каждый раз текущей ситуации. Но при этом не обеспечивается сохранение письменного контекста -- все намерения (т.е. фрагменты плана) обычно только устно обговариваются, а фиксируются лишь принятые к немедленному исполнению. Это сделано сознательно: чтобы зафиксированное намерение не было тормозом в тех случаях, когда ситуация резко изменилась, но зафиксированное намерение жалко менять. Вот, чтобы психологически не было жалко, такое намерение нигде не фиксируют -- кроме памяти тех разработчиков, которые принимали участие в устном обсуждении. Тут как минимум два недостатка:
-- не сохраняется единый контекст планирования (долгосрочные намерения разбросаны по разным документам -- Положение о проекте, карточки и т.д., хотя это все и висит на одной стене, но логически в разных местах). А ведь можно всю эту информацию давать в соответствующих разделах плана, хотя и с разной степенью детальности.
-- в моменты частых перепланирований идет потеря управления -- большой объем работы понимания (коммуникации) делается в КомандеПроекта, но СообществоПроекта от этого процесса отстает, отчего сильно страдает общая координация и связь с жизнью. Если КомандаПроекта большая и разбита на "фракции", то частое перепланирование будет не здорово и внутри КомандыПроекта.

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

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

Это рассуждение дает возможные теоретические основания по объединению сильных черт водопадной модели разработки и гибких методов: баланса постоянности Плана и учета непрерывно меняющейся ситуации, обесценивающей любые планы. Ключевым моментом при таком подходе является понимание
-- разницы в способах коммуникации (обсуждения, ведущего к пониманию ситуации ее участниками) в водопадных методах и гибких методах
-- разницы в содержании и способах фиксации планов в водопадных методах и гибких методах
-- понимании того, что гибкие методы не "управление проектами", а "управление программами", проекты же в них проходят в рамках отдельных итераций. Водопадные методы -- это именно что "управление проектами", "управления программами" в них практически нет и поэтому формально отсутствуют многие типы деятельности, ассоциирующиеся с мультипроектной работой (по факту они идут, ибо жизнь не выключишь -- и поэтому водопадные методы всегда "вылетают из графика" ровно на объем этой дополнительной коммуникации или объем переделок, связанных с отсутствием этой коммуникации).

Это все нужно почистить по логике изложения и используемому языку, а затем положить на сайт http://praxos.ru -- там для этого есть специальное (пока пустое) место: "прагматическое управление проектами", так в литературе сейчас называют разные способы совмещения классических методов управления проектами и гибких методов.

Тут нужно еще добавить, что предлагаемый подход альтернативен наиболее часто используемому сейчас: "поглядите на тип вашего проекта -- и далее используйте либо водопад, либо agile". В предлагаемом подходе говорится о том, что можно надеяться на синтез этих двух подходов в проектах/программах самых разных типов.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 4 comments