В статье мы даём рекомендации о том, на какие моменты стоит обращать внимание, работая даже с коробочным решением. В админке работают пользователи различных уровней, и мы смотрим на разработанный там функционал с точки зрения удобства их работы — например, с инфоблоками.
В статье мы не рекомендуем править ядро без крайней необходимости. Но если она есть, то нужно будет переносить изменения руками. Если все-таки случился кастом, и если это сделано, например, через события, то риск поломки функционала после обновления ядра меньше. Также мы рекомендуем сделать проверки высокорприоритетного измененного функционала и около него.
Наш опыт работы с проектами различных масштабов, разной направленности и интеграциями показывает, что с Битриксом комфортно работать не только в малом бизнесе. Вопрос стоит в построении архитектуры системы и грамотном развитии проекта.
В нашем случае FT не привязаны к сессиям пользователя, так как в этом не было необходимости. С этим инструментом работает и пользуется им одна выделенная команда.
Как смотрите на то чтобы сделать единый механизм для фиче-тоглов и аб-тестов, с плавной раскаткой
Можете рассказать подробнее?
А/Б-тестирования в нашей команде практически нет. Мы используем end-to-end тесты и тестирование компонент.
По-разному. Может поменяться статус задач — останавливается одна и включается другая (два клика), о чем и писали выше. Или в работе может быть более одной задачи одновременно: например, на разработку — большая, на пару дней, а вместе с ней одновременно задача «прочее» на съедальщиков рабочего времени. В этом случае часы второй задачи надо исключить из биллинга, здесь вопрос настроек трекера.
Так ведь списывание часов - это и есть ручное внесение информации. Это как раз тот случай, когда "составлял отчет по дню - 30минут", которое всех и раздражает.
Есть задачи со сменой статуса в трекере, где отслеживается, когда специалист приступает к выполнению работы. Эти задачи ничем не отличаются от задач на разработку — фиксация времени тоже происходит в автоматическом режиме (сколько задача была «в работе» — 2 клика). Если фиксировать 2-х минутные промежутки времени и текстом описывать комментарии, то данный процесс займет гораздо больше 30 минут.
Ссылка кажется не очень показательной. Там весь доказательный дизайн сводится к тому, что изучили конкурентов и сделали так же. Где там метрики упоминаемые у вас в статье и работа с ними, я не увидел
В статье приведены метрики для примера, как они могут использоваться =) Звучит банально, но это действительно так: набор метрик доказательного дизайна для каждого проекта свой, какие именно будут метрики зависит от целей и задач конкретного приложения. Мы передадим нашим дизайнерам идею написать статью по этой теме =)
Спасибо за отклик! 1. К теме о накладных расходах — можно использовать возможности трекера. Например, создать команде задачу «созвоны»/«простои»/«прочее» и разрешить списывать туда реально потраченное на это время без дальнейших санкций (допустим, если выяснится, что четверть рабочих часов действительно утекает). В ручном режиме сбор таких данных подойдет на небольшом отрезке времени в одну неделю или один спринт и для небольшой команды до 5 человек. 2. Про доказательный дизайн можно почитать, например, тут.
Мы как раз отметили, что сбор метрик ради метрик — это самая неэффективная трата рабочего времени. Далеко не на всех проектах нужны измерения, например, большинство стартапов вполне справляются и без них. Но если у вас большая команда, а проект сложный и требует качественной доработки, без метрик не обойтись. Иными словами, не получится измерить глубину ямы без метра.
При использовании продуктовых метрик и kpi, напрямую влияющих на зарплату, да. Но в этой статье речь больше о процессных метриках. Одна из задач менеджмента (мастер, лид, оунер и другие) — как раз расстановка приоритетов для команды в соответствии требованиями бизнеса, которые не постоянны, и это нормально в нашем нестабильном мире.
Если у вас серверная версия Jira или версия для дата-центра, то можете продолжать развивать ее в рамках количества пользователей, предусмотренного лицензией. Эти версии будут работать и после истечения годовой поддержки (ведь физически Jira уже находится на вашем оборудовании). Да, нынешняя ситуация ограничила покупку новых плагинов, но их можно писать самим. Плюс в маркетплейсе Atlassian до сих пор есть бесплатные плагины, которые, как и раньше, можно установить в свою Jira.
Мы говорим о том, что были случаи, когда упоминание (не только во внутренних файлах) приводило к разбирательствам в суде и потере времени. На наш взгляд, лучшее решение - избежать судебного разбирательства, поэтому важно сначала попытаться договариваться с людьми.
Один из примеров есть в обсуждении к прошлой статье (https://habr.com/ru/company/simbirsoft/blog/673018/comments/#comment_24468478), немало обсуждений было и по работе copilot от github. Важно учитывать, что много ПО лицензируется и создаётся не на территории РФ, а значит и подавать в суд могут не на территории РФ и не по российским законам.
Наказания за нарушение лицензий могут быть разные - от общих извинений и потери репутации с уплатой штрафов до перелицензирования всего закрытого софта под открытую версию из-за того, что этого требует вирусная лицензия. Разбирательства (иногда очень затянутые по времени) по нарушениям лицензий встречаются даже среди очень небольших компаний и разработчиков.
Поясним. По BSD-4 мы должны: Сохранять данные об авторском праве (имя авторов и соавторов) в материалах и артефактах проекта и если эти материалы каким либо образом воспримут как какую бы то ни было рекламу, то смогут подать в суд. Другими словами, упоминать авторов обязательно, как и лицензию. Но автор в любой момент может прийти и заявить о нарушении, сказать, что это выглядит как попытка пиарить ваш продукт за счет моего имени, и направит заявление в суд.
При этом его имя можно будет более свободно указывать в EULA и прочих документах (где оно должно быть указано). В этом случае разночтения при использовании его имени не будет.
В самих лицензиях BSD-3 и BSD-4 нет конкретики, что имеется ввиду под рекламой и продвижением продукта. Если вы на лендинге укажете, что используете библиотеки Василия Иванова в своём продукте, можно ли это считать как попытка пиара за чужой счёт? Не думаем. Но наличие письменного разрешения с указанными границами этого разрешения лучше, чем "расплывчатое нечто", от которого отказались в последующих версиях (BSD-2 и далее).
Если коротко, то SDET, кроме автоматизации тестирования, занимается разработкой архитектуры фреймворка и необходимых сервисов для тестирования. Также в его задачи входит тестирование производительности. А QAA выстраивает процессы тестирования на проекте, контролирует качество продукта и пишет автотесты.
Для составления отчетов о ручном прогоне тестов используем встроенный в TMS функционал — Testrail, Test IT и т.п. Для генерации отчетов о прогоне автотестов используем Allure.
На одних проектах требуется создавать промежуточные отчеты после тестирования каждой фичи, на других нужны отчеты по регрессионному тестированию, всё зависит от проекта и пожеланий клиента.
Наполнение отчетов тоже может быть разным, но, как правило, в них всегда отражаем сводку по выполненным проверкам (количество пройденных и упавших тестов) и сводку по дефектам (количество, статус, серьезность и приоритет).
Конфигурация "боевой" джиры на проекте непростая. Чтобы так же сконфигурировать тестовую джиру, нужно время. Более того, когда делают улучшения процессов (в среднем каждые два месяца),конфигурация боевой джиры немного меняется. Поэтому тестовая джира в нашем случае не особо подходит.
Дополнительную трудность для отслеживания изменений конфигурации создает то, что в джире у нас работает 6 команд из разных компаний, каждая из которых может изменять свой блок.
А для того чтобы попросить заказчика сделать бэкап с маскированием критичных столбцов, а не удалением, надо знать все критичные столбцы. В нашем случае это тоже проблематично.
К тому же, требования и процессы изменяются. И отточенное решение, даже если оно будет разработано, перестанет им быть через год-два.
Jira - это и CMS, и Issue Tracker - все зависит от того, как настроить и как использовать. Можно настроить процесс, который будет чем-то более специфичным для конкретной задачи. Удобство джиры - большие возможности настройки. Но БД остается одна и та же
ITS в целом для саппорта тоже подходит. Но мы здесь имеем в виду CMS. CMS (Jira) - предпочтение клиента. Она интегрирована на проекте уже лет 8. Служба поддержки унаследовала ее и для своей работы.
Добрый день! ReadyAPI действительно очень способный инструмент, поддерживающий работу GraphQL, интеграцию тестов с CI и многое другое. Но в статье рассмотрены только бесплатные инструменты, и это не случайно. Предложение внедрить платное решение на проекте всегда наталкивается на необходимость экономического обоснования (на самом деле, бесплатное тоже, но в меньшей степени). Если применение специализированных инструментов для тестирования API только начинается, то далеко не факт, что клиенты согласятся оплатить ReadyAPI, который стоит от 800 $ на человека.
Кроме того, сами QA-специалисты при профессиональном развитии предпочитают переходить от использования API-клиентов сразу к фреймворкам и библиотекам, становясь фулл-стеками и SDET. Так что получается, целевая аудитория платных API-клиентов очень узкая – это прокачанные специалисты, которые понимают и могут обосновать экономическую выгоду инструмента, но при этом не внедрили фреймворки.
В статье мы даём рекомендации о том, на какие моменты стоит обращать внимание, работая даже с коробочным решением. В админке работают пользователи различных уровней, и мы смотрим на разработанный там функционал с точки зрения удобства их работы — например, с инфоблоками.
В статье мы не рекомендуем править ядро без крайней необходимости. Но если она есть, то нужно будет переносить изменения руками. Если все-таки случился кастом, и если это сделано, например, через события, то риск поломки функционала после обновления ядра меньше. Также мы рекомендуем сделать проверки высокорприоритетного измененного функционала и около него.
Наш опыт работы с проектами различных масштабов, разной направленности и интеграциями показывает, что с Битриксом комфортно работать не только в малом бизнесе. Вопрос стоит в построении архитектуры системы и грамотном развитии проекта.
В нашем случае FT не привязаны к сессиям пользователя, так как в этом не было необходимости. С этим инструментом работает и пользуется им одна выделенная команда.
Можете рассказать подробнее?
А/Б-тестирования в нашей команде практически нет. Мы используем end-to-end тесты и тестирование компонент.
По-разному. Может поменяться статус задач — останавливается одна и включается другая (два клика), о чем и писали выше. Или в работе может быть более одной задачи одновременно: например, на разработку — большая, на пару дней, а вместе с ней одновременно задача «прочее» на съедальщиков рабочего времени. В этом случае часы второй задачи надо исключить из биллинга, здесь вопрос настроек трекера.
Есть задачи со сменой статуса в трекере, где отслеживается, когда специалист приступает к выполнению работы. Эти задачи ничем не отличаются от задач на разработку — фиксация времени тоже происходит в автоматическом режиме (сколько задача была «в работе» — 2 клика). Если фиксировать 2-х минутные промежутки времени и текстом описывать комментарии, то данный процесс займет гораздо больше 30 минут.
В статье приведены метрики для примера, как они могут использоваться =) Звучит банально, но это действительно так: набор метрик доказательного дизайна для каждого проекта свой, какие именно будут метрики зависит от целей и задач конкретного приложения. Мы передадим нашим дизайнерам идею написать статью по этой теме =)
Спасибо за отклик!
1. К теме о накладных расходах — можно использовать возможности трекера. Например, создать команде задачу «созвоны»/«простои»/«прочее» и разрешить списывать туда реально потраченное на это время без дальнейших санкций (допустим, если выяснится, что четверть рабочих часов действительно утекает). В ручном режиме сбор таких данных подойдет на небольшом отрезке времени в одну неделю или один спринт и для небольшой команды до 5 человек.
2. Про доказательный дизайн можно почитать, например, тут.
Мы как раз отметили, что сбор метрик ради метрик — это самая неэффективная трата рабочего времени. Далеко не на всех проектах нужны измерения, например, большинство стартапов вполне справляются и без них. Но если у вас большая команда, а проект сложный и требует качественной доработки, без метрик не обойтись. Иными словами, не получится измерить глубину ямы без метра.
При использовании продуктовых метрик и kpi, напрямую влияющих на зарплату, да. Но в этой статье речь больше о процессных метриках. Одна из задач менеджмента (мастер, лид, оунер и другие) — как раз расстановка приоритетов для команды в соответствии требованиями бизнеса, которые не постоянны, и это нормально в нашем нестабильном мире.
Если у вас серверная версия Jira или версия для дата-центра, то можете продолжать развивать ее в рамках количества пользователей, предусмотренного лицензией. Эти версии будут работать и после истечения годовой поддержки (ведь физически Jira уже находится на вашем оборудовании).
Да, нынешняя ситуация ограничила покупку новых плагинов, но их можно писать самим. Плюс в маркетплейсе Atlassian до сих пор есть бесплатные плагины, которые, как и раньше, можно установить в свою Jira.
Мы говорим о том, что были случаи, когда упоминание (не только во внутренних файлах) приводило к разбирательствам в суде и потере времени. На наш взгляд, лучшее решение - избежать судебного разбирательства, поэтому важно сначала попытаться договариваться с людьми.
Фото и изображения в статье взяты с открытого паблика реддита (https://www.reddit.com/r/MemeRestoration/comments/rfjhs0/hd_meme_templates_database_800_files/), где криэйторы перерисовывают старые мемы и выкладывают под открытой лицензией.
а вы заявляли о своих правах на ваши произведения?
Один из примеров есть в обсуждении к прошлой статье (https://habr.com/ru/company/simbirsoft/blog/673018/comments/#comment_24468478), немало обсуждений было и по работе copilot от github. Важно учитывать, что много ПО лицензируется и создаётся не на территории РФ, а значит и подавать в суд могут не на территории РФ и не по российским законам.
Наказания за нарушение лицензий могут быть разные - от общих извинений и потери репутации с уплатой штрафов до перелицензирования всего закрытого софта под открытую версию из-за того, что этого требует вирусная лицензия. Разбирательства (иногда очень затянутые по времени) по нарушениям лицензий встречаются даже среди очень небольших компаний и разработчиков.
Поясним. По BSD-4 мы должны:
Сохранять данные об авторском праве (имя авторов и соавторов) в материалах и артефактах проекта и если эти материалы каким либо образом воспримут как какую бы то ни было рекламу, то смогут подать в суд. Другими словами, упоминать авторов обязательно, как и лицензию. Но автор в любой момент может прийти и заявить о нарушении, сказать, что это выглядит как попытка пиарить ваш продукт за счет моего имени, и направит заявление в суд.
При этом его имя можно будет более свободно указывать в EULA и прочих документах (где оно должно быть указано). В этом случае разночтения при использовании его имени не будет.
В самих лицензиях BSD-3 и BSD-4 нет конкретики, что имеется ввиду под рекламой и продвижением продукта. Если вы на лендинге укажете, что используете библиотеки Василия Иванова в своём продукте, можно ли это считать как попытка пиара за чужой счёт? Не думаем. Но наличие письменного разрешения с указанными границами этого разрешения лучше, чем "расплывчатое нечто", от которого отказались в последующих версиях (BSD-2 и далее).
Если коротко, то SDET, кроме автоматизации тестирования, занимается разработкой архитектуры фреймворка и необходимых сервисов для тестирования. Также в его задачи входит тестирование производительности. А QAA выстраивает процессы тестирования на проекте, контролирует качество продукта и пишет автотесты.
Добрый день! Рассказываем:
Для составления отчетов о ручном прогоне тестов используем встроенный в TMS функционал — Testrail, Test IT и т.п. Для генерации отчетов о прогоне автотестов используем Allure.
На одних проектах требуется создавать промежуточные отчеты после тестирования каждой фичи, на других нужны отчеты по регрессионному тестированию, всё зависит от проекта и пожеланий клиента.
Наполнение отчетов тоже может быть разным, но, как правило, в них всегда отражаем сводку по выполненным проверкам (количество пройденных и упавших тестов) и сводку по дефектам (количество, статус, серьезность и приоритет).
Спасибо за комментарий! На наших проектах QA и QA fullstack выполняют реальные задачи и настраивают реальные процессы. Об этом и рассказали в статье.
Конфигурация "боевой" джиры на проекте непростая. Чтобы так же сконфигурировать тестовую джиру, нужно время. Более того, когда делают улучшения процессов (в среднем каждые два месяца),конфигурация боевой джиры немного меняется. Поэтому тестовая джира в нашем случае не особо подходит.
Дополнительную трудность для отслеживания изменений конфигурации создает то, что в джире у нас работает 6 команд из разных компаний, каждая из которых может изменять свой блок.
А для того чтобы попросить заказчика сделать бэкап с маскированием критичных столбцов, а не удалением, надо знать все критичные столбцы. В нашем случае это тоже проблематично.
К тому же, требования и процессы изменяются. И отточенное решение, даже если оно будет разработано, перестанет им быть через год-два.
Jira - это и CMS, и Issue Tracker - все зависит от того, как настроить и как использовать. Можно настроить процесс, который будет чем-то более специфичным для конкретной задачи. Удобство джиры - большие возможности настройки. Но БД остается одна и та же
ITS в целом для саппорта тоже подходит. Но мы здесь имеем в виду CMS. CMS (Jira) - предпочтение клиента. Она интегрирована на проекте уже лет 8. Служба поддержки унаследовала ее и для своей работы.
Добрый день! ReadyAPI действительно очень способный инструмент, поддерживающий работу GraphQL, интеграцию тестов с CI и многое другое. Но в статье рассмотрены только бесплатные инструменты, и это не случайно. Предложение внедрить платное решение на проекте всегда наталкивается на необходимость экономического обоснования (на самом деле, бесплатное тоже, но в меньшей степени). Если применение специализированных инструментов для тестирования API только начинается, то далеко не факт, что клиенты согласятся оплатить ReadyAPI, который стоит от 800 $ на человека.
Кроме того, сами QA-специалисты при профессиональном развитии предпочитают переходить от использования API-клиентов сразу к фреймворкам и библиотекам, становясь фулл-стеками и SDET. Так что получается, целевая аудитория платных API-клиентов очень узкая – это прокачанные специалисты, которые понимают и могут обосновать экономическую выгоду инструмента, но при этом не внедрили фреймворки.