Введение
Что такое DoR
Зачем нужен DoR
Где применять DoR
Когда применять DoR
INVEST модель
Заключение
Список литературы

Введение

Наверняка вы не раз слышали, скорее даже использовали с командой артефакт Scrum — Definition of Done далее по тексту — DoD. Возможно, используете его, даже не осознавая этого. О DoD написано много русскоязычных статей. О нём говорят на конференциях, и тренингах. Разобраться для чего нужен этот артефакт, и найти примеры не трудно. DoD определяет критерии, по которой каждый член команды понимает, что задача закрыта. Глубинная цель — синхронизировать понятие Done, между каждым членом команды. Над этими критериями, часто, команда трудится во время ретроспективы. Существует похожий артефакт, о котором почему-то нет упоминания в русскоязычных ресурсах о Scrum, а там где этот артефакт упоминается, не даётся никаких разъяснений что это, зачем нужен, и как использовать.

Скорее всего, в вашей команде звучали фразы наподобие: «Мы завалили цель, потому что неправильно оценили задачу», или «Наш PO опять пришёл с задачей без должного описания». В моей команде, подобные “сигналы” появлялись не один раз, и я долго искал способ, чтобы решить эту проблему.

Если спросить тимлида, что он знает о процессах в своей компании, вероятно, вы услышите, что:

1. Процессы чаще всего наследуются. Тимлида наняли и сказали: «Вот тебе канбан».

2. Процессы редко меняются, либо меняются революционно. Например, когда скрам в командах внедрили с консультантами.

3. Процессы не рационализируются. Например, если ни у кого нет точного представления, какую проблему решает «Оценка 360», и насколько это решение оптимально.

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

Здравствуйте!

Расскажу о серии задач, которая случайно возникла в процессе решения другой задачи. Мне на глаза попалось равенство:

81 * 27 = 2187

– Интересно, – подумал я. – А бывают ли ещё такие числа, чтобы цифры слева и справа повторялись?

5 методик, которые необходимо использовать продуктовому дизайнеру в 24-м

Практическое руководство по использованию фреймворков, которые помогут вам создавать лучшие продукты с разбивкой по этапам

• Проще замечать баги
• Быстро находятся переменные и функции
• Легко опознаются специфичные для программирования символы
• Снижается нагрузка на глаза

Когда речь заходит об асинхронных операциях в Unity, на ум первым делом приходит coroutine. И это не удивительно, так как большинство примеров в сети реализованы именно через них. Но мало кто знает, что Unity поддерживает работу с async/await еще с 2017 версии.

Так почему же большинство разработчиков до сих пор использует coroutine вместо async/await? Во первых, как я уже упомянул, большая часть примеров написана с использованием coroutine. Во вторых, async/await кажется очень сложным для начинающих разработчиков. Ну и в третьих, когда речь заходит о коммерческих проектах, где основным из критериев является стабильность, предпочтение отдается проверенному годами подходу.

Но технологии не стоят на месте и появляются библиотеки, которые делают работу с async/await в Unity удобной, стабильной и самое главное высокопроизводительной.

Мало просто сменить свою сферу работы на IT, желательно еще и стать хорошим разработчиком. Бывший тимлид и консультант Александр Усков рассказывает, как понять, что перед вами плохой разработчик и что с ним вообще можно делать

В этой статье мы разберем признаки слабых разработчиков, которые можно обнаружить на собеседовании, в ходе совместной работы или даже в процессе неформального разговора в курилке. Важное уточнение — все описанное в нашей статье не стоит рассматривать как чек-лист формальных правил. Это скорее некоторые закономерности, каждая из которых не является гарантией того, что перед вами — «плохой» разработчик. Но, если в одном человеке сочетаются несколько из них, то вероятность этого сильно увеличивается. 

Если ваша задача — не просто научиться писать код, а понять, как стать тем, без кого поддержка и развитие проекта просто немыслимы, то этот текст для вас. Заодно поговорим о том, как помочь коллегам постичь дзен и досконально изучить структуру разрабатываемого приложения.

Всем привет, меня зовут Макс Кравец, я CEO IT-компании Holyweb, и сегодня хочу поделиться вредными советами о том, как стать незаменимым React-разработчиком. Поехали!

Перед началом чтения пройдите простой тест — каким будет значение свойства background-color в первом и во втором варианте, и почему именно так?

Неожиданный для многих ответ сразу после ката. Там же подробный рассказ о том, как работает каскад — фильтрует, обрабатывает и вычисляет значения свойств. Например, что будет, если указать в трёх разных местах цвет одного и того же элемента.

p.s. Если у вас отключены картинки в ленте на Хабре, то сразу заходите под кат — тест дублируется и там.

С чем бы вы ни работали – ПК, мобильным устройством или консолью, наступит такой момент, когда вы захотите оптимизировать вашу игру. В этой статье приведено несколько советов о том, что нужно и чего не нужно делать, чтобы ваш код на Unity стал бегать немного быстрее.

Эта статья родилась из внутреннего доклада для коллег, которые уже достаточно давно занимаются разработкой игр, но только недавно прикоснулись к Unity. Здесь мы собрали фишки и особенности работы с этим игровым движком разной степени капитанскости, почерпнутые из собственного опыта, которые стоит знать, чтобы эффективно им пользоваться и уже никогда ничему не удивляться.

Что такое AssetPostprocessor и чем Animation отличается от Animator? Почему не стоит доверять OnTriggerExit и зачем вам CanvasGroup? Чем хорош GameObject.Find и как вас спасут Property?

Далее в статье обсудим это, а также другие «особенности» работы с движком Unity.

Разбивая крупные числа на мелкие, исследователи превысили фундаментальное математическое ограничение скорости

Хайп по Svelte после недавнего релиза 3 версии фреймворка всё-таки имеет место быть, чему свидетельствуют сильно возросшее комьюнити и огромное количество вопросов как в официальном чате, так и в нашем рускоязычном telegram-канале. Всё больше разработчиков украдкой или всерьёз присматриваются к этой технологии и задумываются о её применении в своих новых проектах. Для этих разработчиков и всех прочих интересующихся темой максимально эффективного написания кода, Rich Harris, автор и идеолог фреймворка, опубликовал статью о том, как Svelte помогает разработчику минимизировать усилия при создании современных реактивных web-приложений, перевод которой я и предлагаю ниже.

tl;dr:

• Машинное обучение ищет закономерности в данных. Но искусственный интеллект может быть «предвзят» — то есть, находить неверные паттерны. К примеру, система обнаружения рака кожи по фотографии может обращать особое внимание на снимки, сделанные во врачебном кабинете. Машинное обучение не умеет понимать: его алгоритмы лишь выявляют закономерности в числах, и если данные не репрезентативны, таким будет и результат их обработки. А отлавливать такие баги может быть непросто из-за самой механики машинного обучения.