Судя по всему, Nexus содержит отдельную команду под интеграцию между командами. Имхо, это заведомо неверно, потому что подразумевает наличие технических проблем в продукте, которые будет к проблемам с интеграцией между командами, либо неверно сформированным приоритетам.
Я думаю что нужен архитектор + грамотные лиды + нормальное следование Agile, минимум включая разработку через тестирование, рефакторинг, и CI. Если всё верно, команды будут работать раздельно на расширение и изменение функциональности и не должны значительно пересекаться.
Agile сам по себе это всего-лишь принципы проверенные практикой, не более того.
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
Поэтому работа по Agile это прежде всего следование здравому смыслу, стремление к эффективности, а не следование бюрократии и палкам в колеса. Вы можете работать по Agile без Скрама и Канбана, представьте себе J
Поэтому всё что вы говорите, это уже про конкретные методологии, Скрам или Канбан или еще что другое, но опять же, методологии строятся вокруг этих четырех идей выше, и это не про экономию на ТЗ и бизнес аналитиках, потому что это можно сделать и без Agile.
Я вам скажу по своему опыту. Когда я работал с процессами, я понял что бюрократия это проблема, и лучше потратить 5 минут, пойти на встречу, и вообще надо очень желательно двигаться на встречу людям, продукту и качеству, даже если это иногда идет вразрез с принятыми процессами. Так вот эти правила из привычки можно конвертировать во вполне конкретные процессы, через итерации, приоритеты, события и прочее.
Поэтому Agile, не Agile, везде сама суть это люди и как они работают. Если навык специалистов недостаточен чтобы сделать качественное решение, то никакой Agile не спасет, но с Agile можно вовремя это увидеть и скорректировать план действий.
twoone, вот и я к тому пришел, что без нормальной команды и делегирования хорошей каши не сварить. Под архитектором подразумеваю человека, который формирует структуры данных, описывает связи сущностей, алгоритмы работы приложения (не только код, но и всё приложение, в том числе интеграции). Вопрос был о том, что ребята часто не соблюдают ограничения, которые им устанавливаешь, поэтому не проверяя изменения нельзя сразу выгрести такие проблемы (остается только через планирование).
В любом случае услышал ровно то, о чем думал. Наверное, это действительно правильный вариант, других не найти. Спасибо.
twoone, я давно работаю с Agile, и вижу как раз за разом проталкиваются объективно плохие решения если делегировать всё команде. Делегирование и доверие определенно правильные вещи, но если довериться хреново работающей команде, это часто приводит к большим проблемам, в перспективе.
Лишь ищу более приемлемые варианты, чем пускание всего на самотек и создания коллективной экспектизы.
Рекомендую переписать на CSS @keyframes и описать всю анимацию от её старта и до конца. Тогда, вероятно, JS не понадобится от слова совсем (разве что классы повесить при наведении мышки), и работать будет стабильно (всё будет на стороне браузера).
Напишите алгоритм. Например, формирование набора строк не превышающих ширины канваса. Сначала дробите строку по словам, потом формируете раздельные строки нужной длины.
Это не конкретно про использование `null`.
С таким же успехом можно проинициализировать с null или false, и условие выхода сделать на проверку значения.
Вопрос, почему именно undefined, или почему именно null использовать в примере :)
Мы можем сказать при `var a = null` что значение так и не найдено по результату работы цикла (если значение так и осталось null).
При `var a` мы скажем ровно тоже самое, даже если там `undefined`.
Я думаю что нужен архитектор + грамотные лиды + нормальное следование Agile, минимум включая разработку через тестирование, рефакторинг, и CI. Если всё верно, команды будут работать раздельно на расширение и изменение функциональности и не должны значительно пересекаться.
Я могу ошибаться, но у меня такое видение.