> Чистоту методик я радостно оставлю теоретикам. Пусть развлекаются. ;)
Практика в этом деле, Сергей, это как раз составление планов, а не написание программ планирования, которое по сути является теорией. :) План составляется в голове, а не в программе.
> Для того, чтобы Сергей реализовал методику в полном объёме, нужно, чтобы Сергей понимал, нахрена и (!) нуждался в оставшейся функциональности. ;)
Понимание в твоих руках, и тут все дело исключительно в желании (или нежелании) понять, вещи-то простые. Речь не о функциональности, а о том, что у тебя первична задача, имеющая начало и конец, а цель ты вообще не можешь отдельно определить. Это, когда ты перейдешь к усиленной практике, вынудит тебя: 1) Ввести отсутствующие у тебя сейчас типы отношений сетевого планирования - окончание-начало, окончание-окончание, и прочее. 2) Отдельно вводить понятие milestone как специальный случай. Например, как задачу с нулевой длительностью.
То есть, полностью воспроизвести сетевое планирование. Для того, чтобы понимать, что это означает, и чем это хорошо или плохо, а также избежать разработки велосипедов, надо для начала хорошо разбираться в классическом сетевом планировании.
>Откуда ты это вывел? Если можно, поподробней. У тебя соответствие между "целью-событием" и задачей один к одному. Всегда, и по другому быть не может. Плюс, задачи ты определять можешь, а цели - нет. Из этого следует, что понятие цели у тебя на самом деле вообще отсутствует в модели, оно существует только у тебя в голове. Ты указываешь связи в виде указания тегов, а не стрелкой в гуе - вот и вся разница.
>И второй вопрос: а зачем нужна отдельно определённая цель? Твой второй вопрос подразумевает согласие с тем, что цель ты отдельно определить не можешь.
Привожу пример:
Для илюстрации описываю простейший процесс на высоком уровне. Три цели, которые, очевидно, могут быть достигнуты только в этом порядке.
Дизайн завершен: 1. мы понимаем как мы будем делать систему, и в общих чертаз представляем, как будут работать 90% функций 2. У нас готово подразбиение на функциональные компоненты, которое прошло review. 3. Мы в общих чертах определились с подходом к их тестированию
->
Все компоненты закончены: 1. Для всех компонентов выполняется его тест.
->
Интеграция закончена: 1. Система собрана вместе, и обладает всеми функциями. 2. Проходят все системные тесты.
Эта тройка целей задает крупные этапы, за которые зацепляются более мелкие задачи. Более того. Я могу _начать_ интеграцию _до_ того, как достигну второго этапа. Я не могу ее _завершить_, пока не закончится этап 2.
Никакой _дополнительной_ работы цель 2 для своей проверки _не_ требует.
Важный момент здесь вот в чем - работы по этапам могут быть конвейеризованы, а могут идти последовательно. На этапе составления "карты целей" мне это совершенно не важно. Я даю возможность себе и другим детализировать план дальше, не указывая активностей, и это свойство будет соблюдаться рекурсивно, на любом уровне.
Как только ты вводишь задачи, имеющие начало и конец, ты сразу лишаешься этого свойства. Я о последовательности действий и о действиях могу думать потом, когда уже определился с целями, а ты - нет. Ты вынужден думать об этом сразу.
В рамках твоей интерпретации вообще нельзя отразить зависимость "окончание-окончание", кстати. Ты подобное рассуждение во время планирования вообще повторить не сможешь.
У тебя соответствие между "целью-событием" и задачей один к одному.
Процесс может произвести несколько целей.
Является ли это опровержением?
Как только ты вводишь задачи, имеющие начало и конец, ты сразу лишаешься этого свойства. Я о последовательности действий и о действиях могу думать потом, когда уже определился с целями, а ты - нет. Ты вынужден думать об этом сразу.
Процесс представляет собой связь &целиj←tE&предусловияi. Если не думать о мелкой переменной t, и об исполнителях E, то получается не думать о процессах, как таковых. Получается думать только о достижении целей через их подразбиение.
При составлении плана я работаю исключительно так, и никак иначе.
>И второй вопрос: а зачем нужна отдельно определённая цель? Твой второй вопрос подразумевает согласие с тем, что цель ты отдельно определить не можешь.
Этого я вообще не понимаю.
Ты мне объясни, что же такое цель, стоящая отдельно.
По-моему, как только ты определил цель, ты должен определить, от чего она зависит, либо сказать, что она выполнена. цель←&предусловияi. Определился со структурой целей? Добавь t и E. Получишь план.
>> У тебя соответствие между "целью-событием" и задачей один к одному. > Процесс может произвести несколько целей.
Во-первых, твой "процесс", который является на самом деле простой задачей-активностью, имеющей одно начало и один конец, не может произвести "несколько" целей в принципе. У него окончание одно и неделимое, значит, и его критерий достижения один. То, что ты его формулируешь в виде A & B & C - не имеет никакого значения, критерий достижения _одной_ цели будет A & B & C. Сами A, B, и C целями не являются, это логические условия. "Целью" же они становятся в форме утверждения, что A & B & C должны однажды случится.
> Является ли это опровержением?
Во-вторых, не надо рвать фразу из контекста, лишая ее смысла и выхолащивая дискуссию, и пытаться ее "отдельно" опровергать. Единица изложения мысли - абзац, по крайней мере моей мысли, и если ты хочешь сам разобраться, или мне что-то объяснить, а не "найти опровержения", то я предлагаю тебе отвечать на мысль, а не на цепочки слов.
Здесь не флеймовый форум, и у меня нет никакого желания общаться в таком стиле и насильно убеждать тебя в чем-то, если ты сопротивляешься. Это глупо. У нас свободная страна, не хочешь - не понимай, в конце концов.
Оно само по себе не плохо. Это один из взглядов на вещи, по своему полезный. То, что любой план может быть сведен к сетевому графику - это закон природы. Умный человек не привязывается к одному взгляду на вещи, а умеет взглянуть на одно и то же с разных сторон, выбирая оптимальный взгляд для каждой ситуации.
К примеру, глядя на карту целей как на сетевой график, ты получаешь группу безымянных задач, к каждой из которых определено событие окончания, связанных отношением "окончание-окончание". Некоторые из этих задач обладают нулевой длительностью, и являются с точки зрения сетевого планирования "майлстонами".
Существенных отличий предлагаемого взгляда на вещи - несколько. Первое - активности безымянны, в модели отсутствуют. Именно это позволяет свести четыре типа отношения задач к одному типу отношения между событиями.
Активности подразумеваются неявно, и выражаются _только_ в терминах ограничений на темпоральное отношение.
Этот подход, в свою очередь, позволяет убрать отношение подзадачи, которое есть в сетевом планировании, как класс (при переходе к сетевому планированию оно трактуется как специальный случай связи "окончание-окончание"), и заменить его вполне содержательным правилом, которое я указал в корневом посте.
В результате _комбинации_ перечисленного, и появляются все приятные свойства системы. В частности, легкость логической проверки плана. А они связаны с _разделением_ размышления о целях, и способах их достижения. Думая в терминах сетевого планирования мы думаем сразу и об одном, и о другом. Думая в терминах декларативного - мы разделяем эти проблемы, настолько, насколько это возможно, и решаем из раздельно.
Это свойство дает возможность продуктивно работать над очень объемными и сложными планами, причем - работать группой, не свернув себе шею. Такой взгляд на вещи удобен, когда составляется костяк плана. Сетевой график - более удобен и нагляден, когда составляется schedule. И он является предельным частным случаем детализации "карты целей" - нет тут никакого противоречия и противопоставления.
Я достаточно доступно объяснил разницу? А теперь несколько общих слов. Планирование - это составной элемент _практики_ управления проектами, а не теории, и чтобы понять любой подход надо проектами все-таки немного поруководить достаточное время, чтобы наловить граблей самому.
Умозрительный подход, Сергей, здесь не работает, это не та вещь, которую можно понять не имея практического опыта. Это знания высшего порядка, как магическая книга, - для мага низкого уровня будет набором кракозябров.
Ты можешь думать, что раз тебя сделали менеджером, и ты умен, то ты сразу начнешь во всем разбираться. Это не так. Ума недостаточно, чтобы понять многие вещи. Только в математике его достаточно. А здесь - требуется практический опыт. Это инженерный подход.
И если ты будешь отказываться признавать этот факт, то только затормозишь продвижение по уровням вверх, не более того. Перечитай вот этот пост, это примерно то, что я хочу тебе сказать сейчас. http://gaperton.livejournal.com/14664.html
Наличие имён у активностей требуется для демонстрации плана работ. Имена активностей указывают на подсистемы. Кстати, имя активности у меня можно отбросить. И ввести ещё одно ключевое слово relation или как угодно.
Работа над подсистемой core включает в себя работу над целями netlist_opt(...) и simulation(...). Так просто проще.
Можно указывать, конечно, что это ведёт к достижению некоторой цели core(tested,all). Можно. Но можно и так. ;)
Так мне показалось проще, потому, что если цель находится глубоко и требуется во многих системах сразу, то получится не очень удобно.
(напоминать о ле--вых St-te мо--дах не буду - к вопросу о магии;)
(напоминать о ле--вых St-te мо--дах не буду - к вопросу о магии;)
Не напоминай. Мало того, что это не имеет никакого отношения к теме, так я еще и никак не претендую на то, что лучше тебя разбираюсь в монадах. И что вообще - в них разбираюсь. Так что есть целых два повода о них не упоминать.
Практика в этом деле, Сергей, это как раз составление планов, а не написание программ планирования, которое по сути является теорией. :) План составляется в голове, а не в программе.
> Для того, чтобы Сергей реализовал методику в полном объёме, нужно, чтобы Сергей понимал, нахрена и (!) нуждался в оставшейся функциональности. ;)
Понимание в твоих руках, и тут все дело исключительно в желании (или нежелании) понять, вещи-то простые. Речь не о функциональности, а о том, что у тебя первична задача, имеющая начало и конец, а цель ты вообще не можешь отдельно определить. Это, когда ты перейдешь к усиленной практике, вынудит тебя:
1) Ввести отсутствующие у тебя сейчас типы отношений сетевого планирования - окончание-начало, окончание-окончание, и прочее.
2) Отдельно вводить понятие milestone как специальный случай. Например, как задачу с нулевой длительностью.
То есть, полностью воспроизвести сетевое планирование. Для того, чтобы понимать, что это означает, и чем это хорошо или плохо, а также избежать разработки велосипедов, надо для начала хорошо разбираться в классическом сетевом планировании.
Reply
Откуда ты это вывел? Если можно, поподробней.
И второй вопрос: а зачем нужна отдельно определённая цель?
Reply
У тебя соответствие между "целью-событием" и задачей один к одному. Всегда, и по другому быть не может. Плюс, задачи ты определять можешь, а цели - нет. Из этого следует, что понятие цели у тебя на самом деле вообще отсутствует в модели, оно существует только у тебя в голове. Ты указываешь связи в виде указания тегов, а не стрелкой в гуе - вот и вся разница.
>И второй вопрос: а зачем нужна отдельно определённая цель?
Твой второй вопрос подразумевает согласие с тем, что цель ты отдельно определить не можешь.
Привожу пример:
Для илюстрации описываю простейший процесс на высоком уровне. Три цели, которые, очевидно, могут быть достигнуты только в этом порядке.
Дизайн завершен:
1. мы понимаем как мы будем делать систему, и в общих чертаз представляем, как будут работать 90% функций
2. У нас готово подразбиение на функциональные компоненты, которое прошло review.
3. Мы в общих чертах определились с подходом к их тестированию
->
Все компоненты закончены:
1. Для всех компонентов выполняется его тест.
->
Интеграция закончена:
1. Система собрана вместе, и обладает всеми функциями.
2. Проходят все системные тесты.
Эта тройка целей задает крупные этапы, за которые зацепляются более мелкие задачи. Более того. Я могу _начать_ интеграцию _до_ того, как достигну второго этапа. Я не могу ее _завершить_, пока не закончится этап 2.
Никакой _дополнительной_ работы цель 2 для своей проверки _не_ требует.
Важный момент здесь вот в чем - работы по этапам могут быть конвейеризованы, а могут идти последовательно. На этапе составления "карты целей" мне это совершенно не важно. Я даю возможность себе и другим детализировать план дальше, не указывая активностей, и это свойство будет соблюдаться рекурсивно, на любом уровне.
Как только ты вводишь задачи, имеющие начало и конец, ты сразу лишаешься этого свойства. Я о последовательности действий и о действиях могу думать потом, когда уже определился с целями, а ты - нет. Ты вынужден думать об этом сразу.
В рамках твоей интерпретации вообще нельзя отразить зависимость "окончание-окончание", кстати. Ты подобное рассуждение во время планирования вообще повторить не сможешь.
Reply
Процесс может произвести несколько целей.
Является ли это опровержением?
Как только ты вводишь задачи, имеющие начало и конец, ты сразу лишаешься этого свойства. Я о последовательности действий и о действиях могу думать потом, когда уже определился с целями, а ты - нет. Ты вынужден думать об этом сразу.
Процесс представляет собой связь &целиj←tE&предусловияi. Если не думать о мелкой переменной t, и об исполнителях E, то получается не думать о процессах, как таковых. Получается думать только о достижении целей через их подразбиение.
При составлении плана я работаю исключительно так, и никак иначе.
>И второй вопрос: а зачем нужна отдельно определённая цель?
Твой второй вопрос подразумевает согласие с тем, что цель ты отдельно определить не можешь.
Этого я вообще не понимаю.
Ты мне объясни, что же такое цель, стоящая отдельно.
По-моему, как только ты определил цель, ты должен определить, от чего она зависит, либо сказать, что она выполнена. цель←&предусловияi. Определился со структурой целей? Добавь t и E. Получишь план.
Ты не смотри на наличие слова process. Не надо.
Помоги мне понять, что же я делаю не так.
Reply
> Процесс может произвести несколько целей.
Во-первых, твой "процесс", который является на самом деле простой задачей-активностью, имеющей одно начало и один конец, не может произвести "несколько" целей в принципе. У него окончание одно и неделимое, значит, и его критерий достижения один. То, что ты его формулируешь в виде A & B & C - не имеет никакого значения, критерий достижения _одной_ цели будет A & B & C. Сами A, B, и C целями не являются, это логические условия. "Целью" же они становятся в форме утверждения, что A & B & C должны однажды случится.
> Является ли это опровержением?
Во-вторых, не надо рвать фразу из контекста, лишая ее смысла и выхолащивая дискуссию, и пытаться ее "отдельно" опровергать. Единица изложения мысли - абзац, по крайней мере моей мысли, и если ты хочешь сам разобраться, или мне что-то объяснить, а не "найти опровержения", то я предлагаю тебе отвечать на мысль, а не на цепочки слов.
Здесь не флеймовый форум, и у меня нет никакого желания общаться в таком стиле и насильно убеждать тебя в чем-то, если ты сопротивляешься. Это глупо. У нас свободная страна, не хочешь - не понимай, в конце концов.
Reply
Чего тянешь?
Reply
К примеру, глядя на карту целей как на сетевой график, ты получаешь группу безымянных задач, к каждой из которых определено событие окончания, связанных отношением "окончание-окончание". Некоторые из этих задач обладают нулевой длительностью, и являются с точки зрения сетевого планирования "майлстонами".
Существенных отличий предлагаемого взгляда на вещи - несколько. Первое - активности безымянны, в модели отсутствуют. Именно это позволяет свести четыре типа отношения задач к одному типу отношения между событиями.
Активности подразумеваются неявно, и выражаются _только_ в терминах ограничений на темпоральное отношение.
Этот подход, в свою очередь, позволяет убрать отношение подзадачи, которое есть в сетевом планировании, как класс (при переходе к сетевому планированию оно трактуется как специальный случай связи "окончание-окончание"), и заменить его вполне содержательным правилом, которое я указал в корневом посте.
В результате _комбинации_ перечисленного, и появляются все приятные свойства системы. В частности, легкость логической проверки плана. А они связаны с _разделением_ размышления о целях, и способах их достижения. Думая в терминах сетевого планирования мы думаем сразу и об одном, и о другом. Думая в терминах декларативного - мы разделяем эти проблемы, настолько, насколько это возможно, и решаем из раздельно.
Это свойство дает возможность продуктивно работать над очень объемными и сложными планами, причем - работать группой, не свернув себе шею. Такой взгляд на вещи удобен, когда составляется костяк плана. Сетевой график - более удобен и нагляден, когда составляется schedule. И он является предельным частным случаем детализации "карты целей" - нет тут никакого противоречия и противопоставления.
Я достаточно доступно объяснил разницу? А теперь несколько общих слов. Планирование - это составной элемент _практики_ управления проектами, а не теории, и чтобы понять любой подход надо проектами все-таки немного поруководить достаточное время, чтобы наловить граблей самому.
Умозрительный подход, Сергей, здесь не работает, это не та вещь, которую можно понять не имея практического опыта. Это знания высшего порядка, как магическая книга, - для мага низкого уровня будет набором кракозябров.
Ты можешь думать, что раз тебя сделали менеджером, и ты умен, то ты сразу начнешь во всем разбираться. Это не так. Ума недостаточно, чтобы понять многие вещи. Только в математике его достаточно. А здесь - требуется практический опыт. Это инженерный подход.
И если ты будешь отказываться признавать этот факт, то только затормозишь продвижение по уровням вверх, не более того. Перечитай вот этот пост, это примерно то, что я хочу тебе сказать сейчас.
http://gaperton.livejournal.com/14664.html
Reply
Работа над подсистемой core включает в себя работу над целями netlist_opt(...) и simulation(...). Так просто проще.
Можно указывать, конечно, что это ведёт к достижению некоторой цели core(tested,all). Можно. Но можно и так. ;)
Так мне показалось проще, потому, что если цель находится глубоко и требуется во многих системах сразу, то получится не очень удобно.
(напоминать о ле--вых St-te мо--дах не буду - к вопросу о магии;)
Reply
Reply
Не напоминай. Мало того, что это не имеет никакого отношения к теме, так я еще и никак не претендую на то, что лучше тебя разбираюсь в монадах. И что вообще - в них разбираюсь. Так что есть целых два повода о них не упоминать.
Reply
Leave a comment