Pull to refresh
80
0
Алексей Лосев @Teacher

Руководитель разработки

Send message
Могу ошибаться, но это из-за того, что в США действует прецедентное право. Видимо кто-то где-то принял решение, что если в EULA написано что низя, а ответчик это разобрал, то асисяй. Все, теперь все ссылаясь на этот прецедент в суде и получают то-же самое решение.
«Отстаньте уже от нас со своей безопасностью, мы сами разберемся», – вот что на самом деле думают вендоры.

С обобщениями как то полегче надо… Вот пара картинок для размышлений:
1. Кол-во уязвимостей, обнаруженных в СУБД Oracle и Microsoft SQL Server по состоянию на 16 июля 2009. Рассматривались Microsoft SQL Server 2000, 2005, 2008 и Oracle 8i, 9i, 9iR2, 10g, 10gR2, 11g. Источник — Национальный институт стандартов и технологий США
Картинка
image

2. Ну и чуть постарше картинку можно глянуть здесь.
Это не холивара ради, а только в плане снижения уровня категоричности высказываний.
А, спасибо. Теперь понятно. Ок, тогда с остальными вопросами подожду до следующей статьи с описанием процессов.
Не очень понял, у вас текущая деятельность идет по процессам, а если там нет (редкие ситуации), то это все собирается в матрице ответственности? Если да, то не получается ли дублирования (например, у вас в матрице если установка вашего ПО, а это, на мой взгляд, регламентированная повседневная деятельность)?
Подскажите пожалуйста, сколько сейчас у вас в компании: сотрудников, ролей, строк в матрице ответственности?
Матрица ответственности это просто файлик на портале (страничка в вики)?
Спасибо
Здесь еще может сказываться режим биологических часов и рабочего графика. Я жаворонок. На работе уже в восемь, а основной шквал звонков/писем идет после десяти, когда приходит на работу основная масса коллег. У меня сдерживанием от эффективной работы является именно отвлечение от текущей задачи в следствии всего этого. Самые эффективные дни, это когда придешь в субботу и 4-6 часов на одну задачу. Вот это эффективность.
Видимо действительно, все индивидуально. Мне проще несколько часов утром посвятить важной задаче, а вот потом уже почта, телефон и мелкие задачи с наполовину выключенным мозгом.
Давайте, тоже начну с метафоры:
Господь диктует Моисею Тору:- … не вари козленка в молоке матери его…
Моисей:- O, погоди, минуточку… А-а-а-а, я понял! Это означает — не ешь мясного с молочным?!
Господь:- Hе фантазируй. Пиши, что говорят — не вари козленка в моло…
Моисей:- Aааа, сейчас, ага, все — понял: надо иметь отдельную посуду для мяса и молока!
Господь (раздраженно):- Послушай, что ты несешь? Я же тебе ясно сказал! Не выдумывай, пиши, что диктуют: не вари козлен…
Моисей:- Bсе, все, вот теперь — понял: после мясного надо подождать шесть часов, прежде чем есть молочное, а после молочного…
Господь (устало, махнув рукой):- Э, делайте, что хотите…

Так вот, читая принципы Agile, редко кто читает обе части принципа. Ах, там написано: люди и их взаимодействие важнее процессов. Поэтому давайте на процессы забьем, ведь люди важнее. Вот где в этом принципе написано, что процессы не важны? Где? Да, люди важнее, но без адекватных процессов вы получите те самые T которые приводите. При классных людях и процессах соответствующих потребностям ваших проектов, при постоянном процессе улучшения этих людей и процессов, вы вообще покорите весь мир.
У нас не любят золотую середину. А давайте классический метод, да еще со всеми практиками, да и workflow согласования изменения из 56 этапов. Или, а давайте мы Agile, поэтому инженерные практики, документирование, процессы — побоку. Во все нужна золотая середина. Я бы не хотел жить рядом с атомной электростанцией на которую систему управления вот прямо сейчас пишут по Scrum…
Добрый день.
Если не читали, то на эту и очень близкие темы есть «Быстрое решение проблем при помощи стикеров».
Ну, а так, впервые я на эту идею наткнулся в Цели, более строгое и формальное описание методики в страшной красной книжке «Теория ограничения Голдратта». Кстати он, да и я к тому же мнению склоняюсь, говорит что причиной можно признать и элемент цикла.
Вот, например (т.к. с картинкой, то убираю под спойлер):
Пример ДТР
image
Исходя из предложенного вами критерия, первопричиной является «Не читаются описания PBI и Test Case перед разработкой». Но, если требования определены не очень, то оба цикла продолжат крутиться. А вот если поработать с одним из элементов цикла, то его влияние можно ослабить. А дальше обратная связь, которая до этого цикл раскручивала, теперь будет его сжимать.
Добрый день.
Вариант с допродажей услуг — неплох. Но судя по опыту, да и вы как-то осторожно про это говорите, срабатывает он нечасто. Раз у вас оплата time&materials, то логично явно включать в договор накладные расходы. Если заказчика напрягает пункт «сопровождение сделки», то можно и неявно, увеличивая стоимость нормо-часа ваших сотрудников. Но неявный вариант, на мой взгляд, хуже.
За все надо платить, главное, чтобы затраты окупались. Когда заказчик контактирует напрямую с программистами, то мы получаем отвлечение программистов от их основных обязанностей. Введение РП позволяет команде итерацию писать код, тестировать его, документировать и т.д. А новые требования обсуждать с привлечением заказчика (или без) только раз в две недели. Что результативность команды, обычно, повышает. С другой стороны, как вы правильно заметили, снижение скорости прохождения информации и потери. Поэтому нельзя бросаться из крайности в крайность. Заказчик -> программисты — крайность, заказчик -> 100500 промежуточных звеньев -> программисты — тоже крайность.
О! Точно, Спольски. Сегодня про него статья, кстати, проскакивала, что он инвестиции получил на SO. Видимо, подсознание и вытолкнуло этот пример.
Спасибо за статью. Как ни крути Тойота на пути применения Кайдзен продвинулась дальше всех и у нее стоит многому поучится.
Если позволите, по памяти процитирую где то вычитанный пример про упомянутый Excel и 95%. Правда в том примере был Word и применялись привычные 80% и 20%…
Итак, узнав, что 80% пользователей Word пользуются только 20% функций, вы решились и выпустили свой текстовый процессор. Он быстрый, простой в использовании, ведь вы реализовали только 20% функций. Для PR своего детища, вы обратились к знакомому журналисту. Он написал в целом хвалебную статью, но вот в конце, вас просто убила фраза: «Но, я этим редактором пользоваться не буду. Ведь в нем нет подсчета знаков в документе.».
К чему это я? Да к тому, что эти 20% для разных пользователей свои. Журналистам важен подсчет знаков, для студентов и научных сотрудников важна возможность автоматически перенумеровывать рисунки и т.д.
Серебрянной пули нет, поэтому все чекины у нас, например, проходят через CodeReview, да и тестирование никто не отменял. Я, если честно, не помню ошибок связанных с тем сценарием который вы привели.
А еще проще, пишется Snippet и при написании свойств используем его:
Snippet
<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>Define a Property for SL MVVM</Title>
      <Shortcut>propsl</Shortcut>
      <Description>Code snippet for a property using INotifyPropertyChanged. Property have comment</Description>
      <Author>al</Author>
      <SnippetTypes>
        <SnippetType>Expansion</SnippetType>
      </SnippetTypes>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>myField</ID>
          <ToolTip>Field Name</ToolTip>
          <Default>myField</Default>
        </Literal>
        <Literal>
          <ID>type</ID>
          <ToolTip>Property Type</ToolTip>
          <Default>int</Default>
        </Literal>
        <Literal>
          <ID>property</ID>
          <ToolTip>Property Name</ToolTip>
          <Default>MyProperty</Default>
        </Literal>
        <Literal>
          <ID>comment</ID>
          <ToolTip>Commentary</ToolTip>
          <Default>Коментарий свойства</Default>
        </Literal>
      </Declarations>
      <Code Language="csharp">
        <![CDATA[
/// <summary>
/// $comment$
/// </summary>
private $type$ _$myField$ = null;

/// <summary>
/// Возвращает и задает свойство: $comment$
/// </summary>
public $type$ $property$
{
    get
    {
        return _$myField$;
    }
    set
    {
        if (_$myField$ != value)
        {
            _$myField$ = value;
            RaisePropertyChanged("$property$");
        }
    }
}
$end$]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>


Спасибо, познавательно. С описанной системой не работал, но насколько я понял, вы просто свели все многообразие папок к шести. Входящие и пять контекстов. А по срокам вы как-то задачи распределяете? Классическое: сегодня, неделя, позже?
Есть куча классификаций и, к сожалению, серебренной пули нет. Вот, например, один из способов поклассифицировать проекты и подходы к их реализации.
Супер, особенно как система для «изобретения» в процессе обучения бухгалтерского учета. Ну а после того как обучающийся его изобрел, то можно добавить план счетов и вуаля, получаем толкового бухгалтера.
Статья просто обрывается 2001 годом (хотя RUP начали использовать в 1996), поэтому более свжие документы я и не упоминал. Ну а если до 2001, то вот так это все выглядит:
Картинка
image

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity