Могу ошибаться, но это из-за того, что в США действует прецедентное право. Видимо кто-то где-то принял решение, что если в EULA написано что низя, а ответчик это разобрал, то асисяй. Все, теперь все ссылаясь на этот прецедент в суде и получают то-же самое решение.
«Отстаньте уже от нас со своей безопасностью, мы сами разберемся», – вот что на самом деле думают вендоры.
С обобщениями как то полегче надо… Вот пара картинок для размышлений:
1. Кол-во уязвимостей, обнаруженных в СУБД Oracle и Microsoft SQL Server по состоянию на 16 июля 2009. Рассматривались Microsoft SQL Server 2000, 2005, 2008 и Oracle 8i, 9i, 9iR2, 10g, 10gR2, 11g. Источник — Национальный институт стандартов и технологий США
Картинка
2. Ну и чуть постарше картинку можно глянуть здесь.
Это не холивара ради, а только в плане снижения уровня категоричности высказываний.
Не очень понял, у вас текущая деятельность идет по процессам, а если там нет (редкие ситуации), то это все собирается в матрице ответственности? Если да, то не получается ли дублирования (например, у вас в матрице если установка вашего ПО, а это, на мой взгляд, регламентированная повседневная деятельность)?
Подскажите пожалуйста, сколько сейчас у вас в компании: сотрудников, ролей, строк в матрице ответственности?
Матрица ответственности это просто файлик на портале (страничка в вики)?
Спасибо
Здесь еще может сказываться режим биологических часов и рабочего графика. Я жаворонок. На работе уже в восемь, а основной шквал звонков/писем идет после десяти, когда приходит на работу основная масса коллег. У меня сдерживанием от эффективной работы является именно отвлечение от текущей задачи в следствии всего этого. Самые эффективные дни, это когда придешь в субботу и 4-6 часов на одну задачу. Вот это эффективность.
Видимо действительно, все индивидуально. Мне проще несколько часов утром посвятить важной задаче, а вот потом уже почта, телефон и мелкие задачи с наполовину выключенным мозгом.
Давайте, тоже начну с метафоры:
Господь диктует Моисею Тору:- … не вари козленка в молоке матери его…
Моисей:- O, погоди, минуточку… А-а-а-а, я понял! Это означает — не ешь мясного с молочным?!
Господь:- Hе фантазируй. Пиши, что говорят — не вари козленка в моло…
Моисей:- Aааа, сейчас, ага, все — понял: надо иметь отдельную посуду для мяса и молока!
Господь (раздраженно):- Послушай, что ты несешь? Я же тебе ясно сказал! Не выдумывай, пиши, что диктуют: не вари козлен…
Моисей:- Bсе, все, вот теперь — понял: после мясного надо подождать шесть часов, прежде чем есть молочное, а после молочного…
Господь (устало, махнув рукой):- Э, делайте, что хотите…
Так вот, читая принципы Agile, редко кто читает обе части принципа. Ах, там написано: люди и их взаимодействие важнее процессов. Поэтому давайте на процессы забьем, ведь люди важнее. Вот где в этом принципе написано, что процессы не важны? Где? Да, люди важнее, но без адекватных процессов вы получите те самые T которые приводите. При классных людях и процессах соответствующих потребностям ваших проектов, при постоянном процессе улучшения этих людей и процессов, вы вообще покорите весь мир.
У нас не любят золотую середину. А давайте классический метод, да еще со всеми практиками, да и workflow согласования изменения из 56 этапов. Или, а давайте мы Agile, поэтому инженерные практики, документирование, процессы — побоку. Во все нужна золотая середина. Я бы не хотел жить рядом с атомной электростанцией на которую систему управления вот прямо сейчас пишут по Scrum…
Добрый день.
Если не читали, то на эту и очень близкие темы есть «Быстрое решение проблем при помощи стикеров».
Ну, а так, впервые я на эту идею наткнулся в Цели, более строгое и формальное описание методики в страшной красной книжке «Теория ограничения Голдратта». Кстати он, да и я к тому же мнению склоняюсь, говорит что причиной можно признать и элемент цикла.
Вот, например (т.к. с картинкой, то убираю под спойлер):
Пример ДТР
Исходя из предложенного вами критерия, первопричиной является «Не читаются описания PBI и Test Case перед разработкой». Но, если требования определены не очень, то оба цикла продолжат крутиться. А вот если поработать с одним из элементов цикла, то его влияние можно ослабить. А дальше обратная связь, которая до этого цикл раскручивала, теперь будет его сжимать.
Добрый день.
Вариант с допродажей услуг — неплох. Но судя по опыту, да и вы как-то осторожно про это говорите, срабатывает он нечасто. Раз у вас оплата time&materials, то логично явно включать в договор накладные расходы. Если заказчика напрягает пункт «сопровождение сделки», то можно и неявно, увеличивая стоимость нормо-часа ваших сотрудников. Но неявный вариант, на мой взгляд, хуже.
За все надо платить, главное, чтобы затраты окупались. Когда заказчик контактирует напрямую с программистами, то мы получаем отвлечение программистов от их основных обязанностей. Введение РП позволяет команде итерацию писать код, тестировать его, документировать и т.д. А новые требования обсуждать с привлечением заказчика (или без) только раз в две недели. Что результативность команды, обычно, повышает. С другой стороны, как вы правильно заметили, снижение скорости прохождения информации и потери. Поэтому нельзя бросаться из крайности в крайность. Заказчик -> программисты — крайность, заказчик -> 100500 промежуточных звеньев -> программисты — тоже крайность.
Спасибо за статью. Как ни крути Тойота на пути применения Кайдзен продвинулась дальше всех и у нее стоит многому поучится.
Если позволите, по памяти процитирую где то вычитанный пример про упомянутый Excel и 95%. Правда в том примере был Word и применялись привычные 80% и 20%…
Итак, узнав, что 80% пользователей Word пользуются только 20% функций, вы решились и выпустили свой текстовый процессор. Он быстрый, простой в использовании, ведь вы реализовали только 20% функций. Для PR своего детища, вы обратились к знакомому журналисту. Он написал в целом хвалебную статью, но вот в конце, вас просто убила фраза: «Но, я этим редактором пользоваться не буду. Ведь в нем нет подсчета знаков в документе.».
К чему это я? Да к тому, что эти 20% для разных пользователей свои. Журналистам важен подсчет знаков, для студентов и научных сотрудников важна возможность автоматически перенумеровывать рисунки и т.д.
Серебрянной пули нет, поэтому все чекины у нас, например, проходят через CodeReview, да и тестирование никто не отменял. Я, если честно, не помню ошибок связанных с тем сценарием который вы привели.
Спасибо, познавательно. С описанной системой не работал, но насколько я понял, вы просто свели все многообразие папок к шести. Входящие и пять контекстов. А по срокам вы как-то задачи распределяете? Классическое: сегодня, неделя, позже?
Супер, особенно как система для «изобретения» в процессе обучения бухгалтерского учета. Ну а после того как обучающийся его изобрел, то можно добавить план счетов и вуаля, получаем толкового бухгалтера.
Статья просто обрывается 2001 годом (хотя RUP начали использовать в 1996), поэтому более свжие документы я и не упоминал. Ну а если до 2001, то вот так это все выглядит:
С обобщениями как то полегче надо… Вот пара картинок для размышлений:
1. Кол-во уязвимостей, обнаруженных в СУБД Oracle и Microsoft SQL Server по состоянию на 16 июля 2009. Рассматривались Microsoft SQL Server 2000, 2005, 2008 и Oracle 8i, 9i, 9iR2, 10g, 10gR2, 11g. Источник — Национальный институт стандартов и технологий США
2. Ну и чуть постарше картинку можно глянуть здесь.
Это не холивара ради, а только в плане снижения уровня категоричности высказываний.
Матрица ответственности это просто файлик на портале (страничка в вики)?
Спасибо
Господь диктует Моисею Тору:- … не вари козленка в молоке матери его…
Моисей:- O, погоди, минуточку… А-а-а-а, я понял! Это означает — не ешь мясного с молочным?!
Господь:- Hе фантазируй. Пиши, что говорят — не вари козленка в моло…
Моисей:- Aааа, сейчас, ага, все — понял: надо иметь отдельную посуду для мяса и молока!
Господь (раздраженно):- Послушай, что ты несешь? Я же тебе ясно сказал! Не выдумывай, пиши, что диктуют: не вари козлен…
Моисей:- Bсе, все, вот теперь — понял: после мясного надо подождать шесть часов, прежде чем есть молочное, а после молочного…
Господь (устало, махнув рукой):- Э, делайте, что хотите…
Так вот, читая принципы Agile, редко кто читает обе части принципа. Ах, там написано: люди и их взаимодействие важнее процессов. Поэтому давайте на процессы забьем, ведь люди важнее. Вот где в этом принципе написано, что процессы не важны? Где? Да, люди важнее, но без адекватных процессов вы получите те самые T которые приводите. При классных людях и процессах соответствующих потребностям ваших проектов, при постоянном процессе улучшения этих людей и процессов, вы вообще покорите весь мир.
Если не читали, то на эту и очень близкие темы есть «Быстрое решение проблем при помощи стикеров».
Ну, а так, впервые я на эту идею наткнулся в Цели, более строгое и формальное описание методики в страшной красной книжке «Теория ограничения Голдратта». Кстати он, да и я к тому же мнению склоняюсь, говорит что причиной можно признать и элемент цикла.
Вот, например (т.к. с картинкой, то убираю под спойлер):
Исходя из предложенного вами критерия, первопричиной является «Не читаются описания PBI и Test Case перед разработкой». Но, если требования определены не очень, то оба цикла продолжат крутиться. А вот если поработать с одним из элементов цикла, то его влияние можно ослабить. А дальше обратная связь, которая до этого цикл раскручивала, теперь будет его сжимать.
Вариант с допродажей услуг — неплох. Но судя по опыту, да и вы как-то осторожно про это говорите, срабатывает он нечасто. Раз у вас оплата time&materials, то логично явно включать в договор накладные расходы. Если заказчика напрягает пункт «сопровождение сделки», то можно и неявно, увеличивая стоимость нормо-часа ваших сотрудников. Но неявный вариант, на мой взгляд, хуже.
Если позволите, по памяти процитирую где то вычитанный пример про упомянутый Excel и 95%. Правда в том примере был Word и применялись привычные 80% и 20%…
Итак, узнав, что 80% пользователей Word пользуются только 20% функций, вы решились и выпустили свой текстовый процессор. Он быстрый, простой в использовании, ведь вы реализовали только 20% функций. Для PR своего детища, вы обратились к знакомому журналисту. Он написал в целом хвалебную статью, но вот в конце, вас просто убила фраза: «Но, я этим редактором пользоваться не буду. Ведь в нем нет подсчета знаков в документе.».
К чему это я? Да к тому, что эти 20% для разных пользователей свои. Журналистам важен подсчет знаков, для студентов и научных сотрудников важна возможность автоматически перенумеровывать рисунки и т.д.