Можно настроить генерацию для разных модулей. В таком случае нужно будет описать конфигурацию в каждом модуле либо сконфигурировать в одном, но настроить пути нужным образом. На мой взгляд, выигранное время не компенсирует сложность такой настройки, так как при изменении контракта требуется всего одна пересборка зависимых модулей. В больших проектах автогенерация показывает себя особенно хорошо. Мы в своей работе используем ее в том числе в больших многомодульных проектах (200+ модулей).
Принят — это когда обе стороны удовлетворены финальным решением. Вы можете сравнивать его с изначальными требованиями, но в течение разработки скоуп работ часто меняется. Это происходит по многим причинам.
Например, если бы вы в 2019 году решили создать Android-приложение для управления sms и привлечь к этому аутсорс-компанию, то новые условия Google заставили бы вас отказаться от этой затеи. Другой пример: в 2018 году в Евросоюзе приняли GDPR — Общий регламент по защите персональных данных. Из-за этого европейские банки получили дополнительные ограничения и изменяли требования для разработчиков, которые создавали им цифровые продукты.
В целом, все IT-проекты обладают нативной сложностью: невозможно спроектировать всё сразу. Даже в государственных проектах, где чётко прописаны все требования, на этапе приёмки есть Changelog — журнал изменений, в котором указано, какие фичи были запланированы и по какой причине от них отказались в ходе разработки.
Всё правильно, именно поэтому в определении мы использовали «условно существующая». Сам Ройс, кстати, когда описывал эту модель разработки, сразу сказал, что она так не используется. Но это было на второй странице :)
Также наш материал рассчитан на новичков, поэтому у нас не было задачи дать углубленные знания. Нам кажется, что прежде чем погружаться в детали, нужно выстроить прочный фундамент.
Действительно, чтобы правильно настроить и применять скрам, должно быть понимание, что такое аджайл. Но в реальности часто бывает так, что команды не знают основных принципов философии, но пользуются скрамом, потому что это toolbox — некий набор инструментов.
Кстати, как думаете, если Daily Meeting — это пассатижи, то что такое Agile? ;)
"Благодаря этой истории мы приняли решение передать процесс согласований условий контракта аккаунт-менеджерам." - мне интересно, сколько проектов понадобилось, чтобы поручить написание кода программистам?
Действительно, это произошло не сразу. Наша компания была основана 2 людьми, которые делали всё сами. Постепенно мы масштабировались и закрывали компетенции уже конкретными специалистами. Кстати, мы до сих пор иногда не даём разработчикам писать код, просим сначала подумать ;)
Не совсем верно. Agile — это философия, у неё нет приёмов и инструментов. Scrum — один из методов, через который Agile реализуется. Что касается канбан-визуализации: её можно использовать вне Agile. Человек может совершенно не знать принципов философии, но для удобства применять этот метод, двигая карточки на доске.
По сути Kanban, Waterfall, Scrum и Agile — это как тёплое, мягкое, солёное и светлое (разные критерии, которые между собой нельзя сравнивать), на схеме показано именно их взаимодействие. И вы правы, что канбан более гибкий, чем скрам. Но мы рассматривали его как способ управления разработкой и визуализации процессов, а не отдельный фреймворк (канбан-метод), который вы имеете в виду.
И спасибо за оценку тезиса! В своей работе всегда следуем этому принципу.
Для решения задачи мы ищем баланс между временем разработки, результатом и сложностью дальнейшей поддержки продукта. В данном случае это банковское приложение, и 3D-карта — не основной его функционал.
Возможно, вы правы, что OpenGL упростил бы процесс. Мы рассматривали этот вариант, но обнаружили, что есть ряд сложностей с GLSurfaceView при использовании в RecyclerView. Поэтому нам было интересно попробовать готовое решение.
ARCore — не идеальный выбор, о чём и говорится в статье, но мы проверили библиотеку и решили поделиться своим опытом. Надеемся, было полезно!
Мы выбрали ARCore, потому что это решение хорошо показало себя в приложении Revolut и выглядело достаточно простым в использовании. Об этом мы также говорим в статье.
Всё верно, в интеренете есть много решений, но мы не нашли готовые компоненты под наши требования. Будем рады, если поделитесь одним из таких примеров.
И вам спасибо за обратную связь!
Ну просто бальзам на душу для нашего редактора... Благодарим!
Рады, что вам понравилось :)
Можно настроить генерацию для разных модулей. В таком случае нужно будет описать конфигурацию в каждом модуле либо сконфигурировать в одном, но настроить пути нужным образом. На мой взгляд, выигранное время не компенсирует сложность такой настройки, так как при изменении контракта требуется всего одна пересборка зависимых модулей.
В больших проектах автогенерация показывает себя особенно хорошо. Мы в своей работе используем ее в том числе в больших многомодульных проектах (200+ модулей).
Гре́шка, заблу́да и бубо́лечка. В статье тоже отметили.
Принят — это когда обе стороны удовлетворены финальным решением. Вы можете сравнивать его с изначальными требованиями, но в течение разработки скоуп работ часто меняется. Это происходит по многим причинам.
Например, если бы вы в 2019 году решили создать Android-приложение для управления sms и привлечь к этому аутсорс-компанию, то новые условия Google заставили бы вас отказаться от этой затеи. Другой пример: в 2018 году в Евросоюзе приняли GDPR — Общий регламент по защите персональных данных. Из-за этого европейские банки получили дополнительные ограничения и изменяли требования для разработчиков, которые создавали им цифровые продукты.
В целом, все IT-проекты обладают нативной сложностью: невозможно спроектировать всё сразу. Даже в государственных проектах, где чётко прописаны все требования, на этапе приёмки есть Changelog — журнал изменений, в котором указано, какие фичи были запланированы и по какой причине от них отказались в ходе разработки.
Всё правильно, именно поэтому в определении мы использовали «условно существующая». Сам Ройс, кстати, когда описывал эту модель разработки, сразу сказал, что она так не используется. Но это было на второй странице :)
Также наш материал рассчитан на новичков, поэтому у нас не было задачи дать углубленные знания. Нам кажется, что прежде чем погружаться в детали, нужно выстроить прочный фундамент.
Хорошие наблюдения, спасибо!
Действительно, чтобы правильно настроить и применять скрам, должно быть понимание, что такое аджайл. Но в реальности часто бывает так, что команды не знают основных принципов философии, но пользуются скрамом, потому что это toolbox — некий набор инструментов.
Кстати, как думаете, если Daily Meeting — это пассатижи, то что такое Agile? ;)
Действительно, это произошло не сразу. Наша компания была основана 2 людьми, которые делали всё сами. Постепенно мы масштабировались и закрывали компетенции уже конкретными специалистами. Кстати, мы до сих пор иногда не даём разработчикам писать код, просим сначала подумать ;)
Не совсем верно. Agile — это философия, у неё нет приёмов и инструментов. Scrum — один из методов, через который Agile реализуется. Что касается канбан-визуализации: её можно использовать вне Agile. Человек может совершенно не знать принципов философии, но для удобства применять этот метод, двигая карточки на доске.
По сути Kanban, Waterfall, Scrum и Agile — это как тёплое, мягкое, солёное и светлое (разные критерии, которые между собой нельзя сравнивать), на схеме показано именно их взаимодействие. И вы правы, что канбан более гибкий, чем скрам. Но мы рассматривали его как способ управления разработкой и визуализации процессов, а не отдельный фреймворк (канбан-метод), который вы имеете в виду.
И спасибо за оценку тезиса! В своей работе всегда следуем этому принципу.
Это отличный текст, согласны. Кстати, он есть в нашей библиотеке IT-компании.
Спасибо и вам. Рады, что было полезно!
Рады, что вам было полезно!
Спасибо, возьмём на заметку.
Мы загружали изображения в формате png — их легко увеличить на весь экран без потери качества.
Спасибо, Даша!
Мы рады, что подборка от наших тимлидов была вам полезной.
Возможно, вы правы, что OpenGL упростил бы процесс. Мы рассматривали этот вариант, но обнаружили, что есть ряд сложностей с GLSurfaceView при использовании в RecyclerView. Поэтому нам было интересно попробовать готовое решение.
ARCore — не идеальный выбор, о чём и говорится в статье, но мы проверили библиотеку и решили поделиться своим опытом. Надеемся, было полезно!