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