Выпустить продолжение культовой игры - нереально сложная задача. А разработка Disciples III была ещё осложнена банкротством канадской студии-разработчика культовой второй части.

Релиз был неудачным... настолько неудачным, что российская студия-разработки забрала игру на глобальный ремастеринг практически сразу же после релиза оригинала. И спустя 3 года вышла Disciples III: Reincarnation.

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

И вот, спустя 13 лет вышел El Clasico мод, призванный сделать из игры ту самую Disciples, достойного последователя культовой второй части.

Как часто оценка по задаче совпадает с реальными трудозатратами?

Умение точно оценить объём работ спасает от переработок, напряжённой обстановки на проекте, поддерживает доверительные отношения в команде и показывает вас с хорошей стороны перед заказчиком.

Но интуитивные и ставшие традиционными способы оценки задач дают низкую точность. Пора взять на вооружение другой способ, дающий 90+% точность в оценке.

Так почему же Contract First оказался не так хорош на практике?

Это связано с тем, что в теории Contract First не учитывает необходимость постоянных доработок контракта и коммуникации между командами. Основная проблема кроется не в инструментах, а в процессах разработки API: если они выстроены плохо, коммуникация нарушается. Именно процессы — а не недостаток компетенций или инструментов — являются источником проблем.

К сожалению, баги - это неотъемлемая часть процесса разработки программного обеспечения. Но я обратил внимание, что одни команды допускают значительно меньше багов, чем другие.

Почему так происходит? - задался я вопросом.

Простой и декларативный способ выполнять SQL запросы в JUnit тестах.

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

они оценивали меня.

Автоматизация процессов разработки и тестирования программного обеспечения (ПО) — лучший способ уйти от рутины и заняться действительно интересными задачами. Азарт от реализации новой функции может быть погребен под рутиной сборки, подготовкой и выпуска нового релиза. Как избежать этой неизбежной скучной задачи, но выпустить релиз ПО, не упустив при этом ни одной мелочи при его подготовке?

Выпуск релиза ПО — это не только сборка ПО в определённого формата пакет и отправка пакета на место его установки. Зачастую выпуск релиза включает в себя множество других задач, таких как: