Обсуждение

Я знаю, чем мне не нравится decision gate. В реале это не пересмотр выделения ресурсов, не корректировка бюджета и не изменение требований. Практически ни один проект не идёт прямолинейно. Так что в определённых точках происходит выбор альтернатив. В основном по корректировке в координатах бюджет-качество-сроки-персонал. Но не только. И опять же в реале это чисто политическое мероприятие, выливающееся в борьбу разных партий. выигрыш от более частой интеграции и прогона полного набора тестов на собранной системе много выше потерь времени на эту повторяющуюся и нудную работу. Всё-таки это ни кем не доказаный на фактах миф. Точнее, может быть выше, может быть ниже. А бывают вообще проекты, которые в стадии прототипа и подыхают. В системе слишком много обратных связей. Когда люди нацеливаются на частую интеграцию, процесс интеграции становится самоцелью.

А по каким соображениям не употребляется тег <lj-cut> ?

Все эти соображения как раз рассматриваются при рекомендации практики пересмотров выделения ресурсов, и на каждое такое соображение приводится свой собственный ответ. Например, ответ "в реале это не..." сводится к тому, что в реале пересмотра выделения ресурсов "по норме" не происходит, а происходят какие-то другие действия. Например, один наш клиент с удивлением обнаружил, что очень похожие на пересмотр выделения ресурсов мероприятия (обратите внимание, какие я использую родовые слова для "пересмотра" -- "практика", "мероприятия", "дела". Это не случайно!) выполняются неформально, в виде кулуарных совещаний, а не совещаний формальных "под протокол". И этих "тайных вечерь" не штуки три-четыре за время разработки, а ровно две -- в начале и в конце при постоянных жалобах на то, что никакие другие "авральные" совещания по факту не влияют на ход проекта, хотя идут непрерывно. Конечно, в реале не выполняется эта практика потому как мало кто этим выполнением озабочен, выгоды этого выполнения не понимаются. Пересмотр выделения ресурсов не стоит путать с работой внутри стадии, где непрерывно происходит подготовка этого пересмотра -- предложение и оценка альтернатив (trade-off analysis, мы предлагаем переводить как "прохождение развилок", это образно и уже более менее закрепилось в речи -- http://yandex.ru/yandsearch?text=прохождение+%2F%2B1+развилок). Как я понял, весь вопрос, в каких точках происходит пересмотр выделения ресурсов и смена базиса (rebaselining) -- ISO 15288 предлагает считать, что это определяется формой жиненного цикла, и как раз такие решения отделяют одну стадию ЖЦ от другой. Политическое мероприятие -- а как же! Это ведь владельцы ресурсов участвуют, их решения обычно определяются отнюдь не технической целесообразностью, а межвременнЫми предпочтениями. Из-за разности этих межвременнЫх предпочтений заинтересованных сторон (stakeholders) могут возникать нешуточные споры. Насчет интеграции -- конечно, на графиках "выгоды" наверняка будет горб. Как я понимаю, авторы методов управления жизненным циклом системной инженерии (в отличие от авторов методов управления жизненным циклом софта) не настаивают на непрерывной интеграции, но предлагают иметь эту интеграцию как минимум несколько раз в ходе разработки, причем интеграцию эту делать на разных уровнях готовности описаний: начальных проанализированных на совместимость требований, архитектуры, рабочего проекта и т.д. Не непрерывно, но и не только в момент окончательной сборки "в железе". Никакой самоцели, токмо проверка целостности в момент выделения ресурсов -- чтобы ресурсы выделялись на пиджачок, а не на набор несовместимых друг с другом пуговиц, рукавов и полочек (знаменитое "к пуговицам претензий нет, но пиджачок не сидит!"). Так что предложения стандартов -- вводить праткику пересмотра выделения ресурсов. И в обоснование они приводят многочисленные успешные проекты, где такая практика выполнялась (хотя, конечно, доказать успешность этих проектов именно от проведения этой практики невозможно. Но рассуждения мне кажутся убедительными и полностью соответствуют моему опыту и опыту моих клиентов: там, где удавалось к этому идеалу приблизиться, успеха было больше, чем неудач). Насчет проектов, заглохающих на стадиях прототипа: вот-вот. Один из предписанных результатов пересмотра выделения ресурсов -- заткнуть неудачный проект на как можно более ранней стадии.

Когда-то на заре ЖЖ (году эдак в 2002) мне указали на то, что я не экономлю читателю нажатия мышкой, когда использую lj-cut. Действительно, очень неудобно тыкать мышкой, а потом ждать пять-десять секунд, пока раскроется кусок текста. Кроме того, грамотные люди определяют, стоит или не стоит им читать текст не по первому абзацу, а "по диагонали" сканируя весь текст. Так что я внял этим аргументам и перестал юзать lj-cut еще тогда, используя его лишь как средство художественной выразительности (например, под lj-cut даются тексты разгадок к загадкам). Я и сам терпеть не могу lj-cut в чужих лентах (очень, очень неудобно! ЖЖ медленно и печально отдает чуть ли не полмегабайта на каждый клик -- независимо от размеров самого полезного текста, даже не понимаю, как разработчикам ЖЖ удается набрать такой объем HTML-обвязки). Я, конечно, знаю о существовании других стилей предпочтений. Но всем не угодишь. В некоторых программах чтения лент клиппирование больших постингов происходит автоматически, вот пусть через такие программы и читают (меня, кстати, довольно много читают в трансляциях, а не прямо из ЖЖ).

Его отсутствие не напрягает. Тексты появляются не часто, пост компактен, четко форматирован, не перегружен ссылками и иллюстрациями. От него не корежит ленту, в нем нет мегабайтов фото. lj-cut раньше был более актуален при ограниченных каналах связи, чем как инструмент структурирования поста.

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

Всё-таки в тему. Опять принятие решения по одной переменной. :-) Usability, кстати, говорит немного другие вещи. Ну да ладно.

[quote]Всё-таки это ни кем не доказаный на фактах миф. Точнее, может быть выше, может быть ниже.[/quote] А доказывать и не надо. Надо оценить потери времени связанные с тем, что дефекты обнаруживаются позднее чем могли бы. Иногда эти потери незначительны, иногда велики, причем в одном и том же проекте может быть верно как то, так и другое. Просто цена ошибки разная в разных случаях.

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

В системе слишком много обратных связей. Измерение по одной зависимой переменной даст в результате только чудесные показатели по этой переменной. К тому же для поиска и предупреждения ошибок существуют гораздо более эффеткивные и дешёвые методы.

Если usability говорит против того, что говорят сами люди, значит что-то не так с этой usability ;)

Это уже вопрос компетентности имплементаторов. Разумеется, любую идею можно извратить и дискредитировать тупым и шаблонным применением. Для изучения обратных связей есть аналитики (и экономисты). Грамотный аналитик нароет где и чего имеет смысл менять, а где нет. Я к примеру, легко нахожу где можно поднять производительность софта, даже если код первый раз вижу. А кто-то годами может рыться и действительно путаться в обратных связях.

Вопрос не в школах, а в культуре и философии. "Полуготовый продукт" - это архетип, а не пример. И агильщики не знают, что водопадных проектов не бывает. Будущее подвластно статистике. По крайней мере страховки именно тем и живут. База, правда, должна быть хорошая и матаппарат не левый. "Новые практики" появляются, когда "старые практики" их проповедникам уже доходов не приносят, а книжки писать и лекции читать ещё надо. Агильщики ничего нового не изобрели. Зато название звонкое. И XP в своё время маркетинговые отделы куда только не вставляли. Согласование картины мира малополезно, если этот мир существует только на бумаге. Хотя, движение стандартов к реальности происходит. Если "кто-то формочку не заполнил", к методу нужно относить причины, почему не заполнил, почему это не нашли, и почему не исправили. Иначе получается просто марш для бодрого хождения строем. PS: один из основных траблов стандартов жизненного цика в том и состоит, что первым делом как раз с "удачными бунтами" и борются.

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

Абсолютно так. Есть даже правило: пользователь не в состоянии описать свои действия. По этой причине характер его работы проверяется только эксперементальным путём.

Вопрос в устойчивости модели. В том числе и против хитрых имплементаторов.

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

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

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

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