Точно!! Именно это я и видел. Большое спасибо. Теперь не буду мучиться. Зато: такой кусок ностальгии. (Я сам не игроман. Сейчас, немного жалею, что не увлекался. Надо было на чём-то "зависнуть". Было бы чего вспомнить. Да и некоторая тренировка внимания, реакции и многозадачности не помешала бы...)
А где искать информацию по таким играм? Помню, как ещё в ДЛТ (это такой ленинградский дом торговли) стоял автомат и в нём была такая игра типа "вид сверху", где надо было всё время идти вперёд и отстреливаться, а в конце уровня движение останавливалось и появлялся босс. Я смог углядеть только трёх боссов. Одного звали Винчестер (от имени марки ружей, он и стрелял из ружья), второго — Кнайф (наверное, Джек Кнайф, так что он кидал ножики), третьего — Динамит (он кидался бомбочками). Хотя... я могу путать место. Может быть этот автомат стоял на Большой морской улице (улице Герцена) в здании, которое Лидваль построил для банка (почти у самой арки Главного Штаба).
Представьте ситуацию: ваша команда только что выпустила новую версию продукта, а через неделю техподдержка завалена тикетами от недовольных пользователей. Знакомо, не правда ли? Сегодня недостаточно просто разрабатывать качественное ПО — нужно уметь эффективно поддерживать его и оперативно реагировать на изменения потребностей пользователей.
А можно задать один вопросик?
Кто-нибудь потом собирал эти "тикеты" и анализировал, почему они все возникли, где что-то пошло не так, что было пропущено или упущено в предыдущих рассуждениях, и можно ли было сначала что-то такое сделать, чтобы эти "тикеты" не возникли?
Использование любой методологии легко заменить магическими заклинаниями, а потом удивляться тому, что откуда-то всё-равно возникают проблемы. А что можно ожидать, если вместо обсуждения конкретных примеров и анализа того, что пошло так/не так, снова звучит набор общих слов. Может быть, проблема в том, что к делу-то и не переходят? В результате, всякая, даже, здравая методология становится сборником магических заклинаний.
Когда пользователь добавляет товар в корзину, front-end service связывается с сервисом продуктов, чтобы собрать подробную информацию, и с сервисом корзины (cart service), чтобы обновить корзину пользователя.
Здесь очень не хватает предварительного описания каждого сервиса. Надо понять, зачем нужен конкретный сервис. (А не то, чтобы сервис есть, потому как архитектура такая!)
На первый взгляд, корзина — это просто некое хранилище. Что корзина может делать такого?
... в условиях быстро меняющегося мира технологий ...
А в чём, собственно, заключается это изменение? Задачи, ведь, как это представляется на первый взгляд, остаются теми же самыми. Что же меняется? Почему нельзя один раз получить удовлетворительное решение и, потом, растиражировать его?
По завершении спринта проводим ретроспективу, где обсуждаем успехи и области для улучшения. QA может предложить оптимизацию процесса тестирования или выявить узкие места, которые затрудняют тестирование.
Беда в том, что, когда одна команда разработчиков выявила узкие места и добралась до финиша, другая команда в другом месте начинает свои "круги ада", и как-то не удаётся тиражировать положительный опыт.
После завершения спринта команда проводит демо для бизнеса, на котором демонстрируются новые функции. QA может предоставить информацию о найденных дефектах и предложить улучшения на основе обратной связи пользователей. Это позволяет команде адаптировать функционал под реальные потребности клиентов.
А можно дать в руки заказчику некое ПО (типа конструктора), чтобы он сам всё описал? Несбыточная мечта? Маниловщина? (Языковые модели будут здесь, как раз, очень кстати. К этому всё и идёт?)
Команда QA использует фреймворк для автоматизации тестов (в нашем случае Playwright), что позволяет нам быстро проверять, не нарушены ли существующие функции при добавлении новых.
Как он это делает? Он это делает лучше, чем другие? И кто такие другие?
Тестирование проводится на протяжении всего спринта, а не только в конце. Это позволяет быстро выявлять и устранять проблемы.
Безграничное тестирование! Когда же мы пишем код?
Я не спорю. Вполне возможно, так и нужно действовать, постоянно что-то тестировать, то есть — проверять. Тут бы и хотелось бы услышать, какие бывают тесты, что именно тестируется, каковы сценарии тестирования? И кто-нибудь тестировал тестирование?
Разработчики регулярно интегрируют свои изменения в основной код, что позволяет быстро обнаруживать и исправлять ошибки.
Как можно что-то просто так интегрировать в основной код? Опять же, здесь очень не хватает сравнительного анализа: вот мы здесь исправили локальные ошибки, но, зато потом столкнулись с ошибками в другом месте и потом долго ковырялись и выяснили, что дело было в ранних и, вроде бы, уже проверенных изменениях.
На самом деле, всё это — яркий пример отсутствия какой-либо теории проектирования. Была бы теория, мы бы знали, какие изменения являются допустимыми, и с каждым допустимыми изменением была бы связана своя оценка риска, учитывающего взаимосвязи компонентов. Кстати, это говорит ещё и о необходимости некоторого над-уровня разработки, когда организуются поток изменений в определённом направлении, при этом, обязательно должны быть свои инварианты.
В начале каждого спринта мы собираемся, чтобы определить, какие задачи будут выполнены в течение этого периода. Команда оценивает сложность каждой задачи и определяет, сколько задач можно выполнить за спринт. QA активно участвуют в обсуждении, помогая уточнить критерии приемки для новых функций.
Практически дословное воспроизведение алгоритма работы порождающей языковой модели! Отсюда становится понятным успех применения таких моделей. Это же — общепринятая практика!
Создание бэклога продукта. Сюда включаем общий список функций и улучшений, ранжированных по приоритетам. Например, в верхней части бэклога могут быть такие функции, как создание инвойсов, отслеживание расходов и интеграция с банковскими счетами.
Разработка программного продукта по описываемой схеме, по своей сути, превращается в очень случайный процесс, когда поток реализации никак не упорядочен, а локальные "улучшения" могут оборачиваться глобальными ухудшениями.
Мой текущий проект помогает предпринимателям управлять своими финансами, отслеживать проекты и взаимодействовать с клиентами.
А Вы можете поточнее определить, что именно значит "управлять своими финансами", как здесь возникают "проекты" и кто такие "клиенты"?
Традиционная разработка начинается с определения сущностей и отношений между ними. Было бы неплохо, сначала, увидеть, как выглядит такая схема в начале пути, и во что она превращается в конце пути.
Ключевой и самые главный вопрос: можно ли каким-нибудь (волшебным?) способом сразу получить конечную схему?
В этой статье я расскажу об основных принципах Agile, как они меняют подход к тестированию и какие преимущества это дает командам.
Мне тут, как-то, уже намекнули на то, что все уже перешли на Agile, а всё остальное — устарело. Давайте, посмотрим...
Эти принципы привели к появлению различных фреймворков, таких как Scrum, Kanban и Extreme Programming (XP), каждый из которых предлагает уникальные подходы к реализации ценностей Agile.
Ценностей, говорите? В чём же эти ценности заключаются?
Давайте рассмотрим, как Agile изменил подход к тестированию и какие преимущества это принесло.
Подождите! А какие подходы были до того как?
Тестирование начинается с самых ранних этапов жизненного цикла программного обеспечения. Преимущества: это позволяет выявлять и решать проблемы раньше, сокращая время и затраты.
1.1 А какие, вообще, есть этапы жизненного цикла?
1.2 Я предполагаю, что классический подход заключается в том, чтобы сначала полностью спроектировать целую систему, и садиться за кодирование/программирование строго послед того, как проектирование полностью завершено. Правильно ли я понимаю, что Agile допускает написание кода (и последующее его тестирование) на самых ранних этапах?
1.3. Стоп! А разве этап проектирования не заключается в том, что мы выявляем проблемы и, когда они выявлены, мы предлагаем их решение? Мне всегда казалось, что проектирование в этом и заключается, чтобы, сначала, ответить на вопрос, что мы хотим сделать, и, потом, на вопрос, как мы хотим это сделать. Ответ на вопрос как и показывает, что у разных вариантов реализации будут и разные проблемы.
В Agile тестирование проводится постоянно, параллельно с разработкой. Преимущества: позволяет быстро получать обратную связь и вносить необходимые изменения.
2.1 С точки зрения системного подхода и анализа, и, вообще, традиционного подхода, здесь идёт речь о тестировании вербальных моделей. Если представить процесс создания системы, то, сначала, мы описываем функции и процедуры и, постепенно, уточняя детали, тестируем их на непротиворечивость. Разница здесь заключается в том, что в Agile начинают рано писать код, но что такое проектирование как ни литературное программирование?!
Акцент на автоматизации. Agile-методологии часто используют автоматизированные тесты для повышения эффективности. Преимущества: позволяет быстро выполнять регрессионные тесты и получать обратную связь о работоспособности новых функций.
3.1 Чем же традиционный подход отличается от Agile? Можем обратиться к языковой модели и получить на выходе... Кстати, а что мы получим?
3.2 Неужели всё сводится к одним только тестам? Может быть, существует другой подход к построению качественного программного кода? Например, доказательное программирование? Можно представить себе работу проектировщика, как оператора базы данных. Только, в БД хранятся не данные, а код. Оператор заполняет БД сведениями, описывающими проектируемую систему и проверяет условия целостности. Как только получено полное и непротиворечивое описание (спецификацию), то можно будет передать такую базу программистам, а те изготовят конкретное изделие по спецификации. (Или это сделает языковая модель.)
3.3 Что такое "регрессионные тесты"? Это имеет отношение к доказательному программированию?
В Agile все члены команды, включая разработчиков, тестировщиков и бизнес-аналитиков, несут ответственность за качество продукта. Преимущества: это приводит к более тесному сотрудничеству и улучшению качества.
4.1 В чём же заключается ответственность?
4.2 Качество продукта зависит от квалификации сотрудников. Либо она есть, либо её нет (и тогда никакая ответственность не поможет). Если заказчик приходит с новыми "хотелками", то бизнес-аналитики плохо поработали. Здесь бы понять, почему пришёл заказчик...
4.3 Получается, что большую часть рабочего времени люди заняты исправлением своих "недодумок". Может быть, следует семь раз подумать, а уже потом начать "кодить"?
Учитывая ограниченное время в каждом спринте, команды Agile часто применяют подходы к тестированию, основанные на оценке рисков. Преимущества: позволяет командам сосредоточиться на тех аспектах продукта, которые могут вызвать наибольшие проблемы или иметь наиболее серьезные последствия в случае сбоя.
5.1 Откуда мы (у)знаем, что вызывает/вызовет наибольшие проблемы? Кто-нибудь анализировал реальные примеры разработки? кто-нибудь сопоставлял ожидания и реальность?
Agile-проекты обычно используют пользовательские истории для определения требований. Тестировщики должны адаптироваться к тестированию на основе этих пользовательских историй, гарантируя, что критерии приемки выполнены.
6.1 Пользовательские истории — это, конечно же, очень хорошо. Но у любой деятельности есть свои цели, процедуры и регламентам. Формализация всего этого приводит к чётким протоколам. Другими словами, нужно изначально иметь достаточно полное покрытие пользовательскими историями, а уже потом, доказав полноту, что-то делать дальше.
Точно!! Именно это я и видел. Большое спасибо. Теперь не буду мучиться. Зато: такой кусок ностальгии. (Я сам не игроман. Сейчас, немного жалею, что не увлекался. Надо было на чём-то "зависнуть". Было бы чего вспомнить. Да и некоторая тренировка внимания, реакции и многозадачности не помешала бы...)
А где искать информацию по таким играм? Помню, как ещё в ДЛТ (это такой ленинградский дом торговли) стоял автомат и в нём была такая игра типа "вид сверху", где надо было всё время идти вперёд и отстреливаться, а в конце уровня движение останавливалось и появлялся босс. Я смог углядеть только трёх боссов. Одного звали Винчестер (от имени марки ружей, он и стрелял из ружья), второго — Кнайф (наверное, Джек Кнайф, так что он кидал ножики), третьего — Динамит (он кидался бомбочками). Хотя... я могу путать место. Может быть этот автомат стоял на Большой морской улице (улице Герцена) в здании, которое Лидваль построил для банка (почти у самой арки Главного Штаба).
Здравствуйте! ;-)
А можно задать один вопросик?
Кто-нибудь потом собирал эти "тикеты" и анализировал, почему они все возникли, где что-то пошло не так, что было пропущено или упущено в предыдущих рассуждениях, и можно ли было сначала что-то такое сделать, чтобы эти "тикеты" не возникли?
"У каждого свои недостатки" (с)
И свои нейросети, тоже. ;-)
Использование любой методологии легко заменить магическими заклинаниями, а потом удивляться тому, что откуда-то всё-равно возникают проблемы. А что можно ожидать, если вместо обсуждения конкретных примеров и анализа того, что пошло так/не так, снова звучит набор общих слов. Может быть, проблема в том, что к делу-то и не переходят? В результате, всякая, даже, здравая методология становится сборником магических заклинаний.
Здесь очень не хватает предварительного описания каждого сервиса. Надо понять, зачем нужен конкретный сервис. (А не то, чтобы сервис есть, потому как архитектура такая!)
На первый взгляд, корзина — это просто некое хранилище. Что корзина может делать такого?
А что делает этот сервис?
Нативный, значит, родной для определённой вычислительной среды.
Наивный, значит, наиболее простой, но и, как это часто бывает "по жизни", расточительный по времени (да и по памяти).
А в чём, собственно, заключается это изменение? Задачи, ведь, как это представляется на первый взгляд, остаются теми же самыми. Что же меняется? Почему нельзя один раз получить удовлетворительное решение и, потом, растиражировать его?
Беда в том, что, когда одна команда разработчиков выявила узкие места и добралась до финиша, другая команда в другом месте начинает свои "круги ада", и как-то не удаётся тиражировать положительный опыт.
А можно дать в руки заказчику некое ПО (типа конструктора), чтобы он сам всё описал? Несбыточная мечта? Маниловщина? (Языковые модели будут здесь, как раз, очень кстати. К этому всё и идёт?)
Здесь очень хорошо пригодился бы реальный пример пересмотра планов. Вот, шли-шли, а потом пошли в другом направлении? И как это выглядит?
Так часто? И какую отдачу это даёт?
Как он это делает? Он это делает лучше, чем другие? И кто такие другие?
Безграничное тестирование! Когда же мы пишем код?
Я не спорю. Вполне возможно, так и нужно действовать, постоянно что-то тестировать, то есть — проверять. Тут бы и хотелось бы услышать, какие бывают тесты, что именно тестируется, каковы сценарии тестирования? И кто-нибудь тестировал тестирование?
Волга впадает в Каспийское море. Без примеров никак?
Как можно что-то просто так интегрировать в основной код? Опять же, здесь очень не хватает сравнительного анализа: вот мы здесь исправили локальные ошибки, но, зато потом столкнулись с ошибками в другом месте и потом долго ковырялись и выяснили, что дело было в ранних и, вроде бы, уже проверенных изменениях.
На самом деле, всё это — яркий пример отсутствия какой-либо теории проектирования. Была бы теория, мы бы знали, какие изменения являются допустимыми, и с каждым допустимыми изменением была бы связана своя оценка риска, учитывающего взаимосвязи компонентов. Кстати, это говорит ещё и о необходимости некоторого над-уровня разработки, когда организуются поток изменений в определённом направлении, при этом, обязательно должны быть свои инварианты.
Практически дословное воспроизведение алгоритма работы порождающей языковой модели! Отсюда становится понятным успех применения таких моделей. Это же — общепринятая практика!
Разработка программного продукта по описываемой схеме, по своей сути, превращается в очень случайный процесс, когда поток реализации никак не упорядочен, а локальные "улучшения" могут оборачиваться глобальными ухудшениями.
А Вы можете поточнее определить, что именно значит "управлять своими финансами", как здесь возникают "проекты" и кто такие "клиенты"?
Традиционная разработка начинается с определения сущностей и отношений между ними. Было бы неплохо, сначала, увидеть, как выглядит такая схема в начале пути, и во что она превращается в конце пути.
Ключевой и самые главный вопрос: можно ли каким-нибудь (волшебным?) способом сразу получить конечную схему?
Мне тут, как-то, уже намекнули на то, что все уже перешли на Agile, а всё остальное — устарело. Давайте, посмотрим...
Ценностей, говорите? В чём же эти ценности заключаются?
Подождите! А какие подходы были до того как?
1.1 А какие, вообще, есть этапы жизненного цикла?
1.2 Я предполагаю, что классический подход заключается в том, чтобы сначала полностью спроектировать целую систему, и садиться за кодирование/программирование строго послед того, как проектирование полностью завершено. Правильно ли я понимаю, что Agile допускает написание кода (и последующее его тестирование) на самых ранних этапах?
1.3. Стоп! А разве этап проектирования не заключается в том, что мы выявляем проблемы и, когда они выявлены, мы предлагаем их решение? Мне всегда казалось, что проектирование в этом и заключается, чтобы, сначала, ответить на вопрос, что мы хотим сделать, и, потом, на вопрос, как мы хотим это сделать. Ответ на вопрос как и показывает, что у разных вариантов реализации будут и разные проблемы.
2.1 С точки зрения системного подхода и анализа, и, вообще, традиционного подхода, здесь идёт речь о тестировании вербальных моделей. Если представить процесс создания системы, то, сначала, мы описываем функции и процедуры и, постепенно, уточняя детали, тестируем их на непротиворечивость. Разница здесь заключается в том, что в Agile начинают рано писать код, но что такое проектирование как ни литературное программирование?!
3.1 Чем же традиционный подход отличается от Agile? Можем обратиться к языковой модели и получить на выходе... Кстати, а что мы получим?
3.2 Неужели всё сводится к одним только тестам? Может быть, существует другой подход к построению качественного программного кода? Например, доказательное программирование? Можно представить себе работу проектировщика, как оператора базы данных. Только, в БД хранятся не данные, а код. Оператор заполняет БД сведениями, описывающими проектируемую систему и проверяет условия целостности. Как только получено полное и непротиворечивое описание (спецификацию), то можно будет передать такую базу программистам, а те изготовят конкретное изделие по спецификации. (Или это сделает языковая модель.)
3.3 Что такое "регрессионные тесты"? Это имеет отношение к доказательному программированию?
4.1 В чём же заключается ответственность?
4.2 Качество продукта зависит от квалификации сотрудников. Либо она есть, либо её нет (и тогда никакая ответственность не поможет). Если заказчик приходит с новыми "хотелками", то бизнес-аналитики плохо поработали. Здесь бы понять, почему пришёл заказчик...
4.3 Получается, что большую часть рабочего времени люди заняты исправлением своих "недодумок". Может быть, следует семь раз подумать, а уже потом начать "кодить"?
5.1 Откуда мы (у)знаем, что вызывает/вызовет наибольшие проблемы? Кто-нибудь анализировал реальные примеры разработки? кто-нибудь сопоставлял ожидания и реальность?
6.1 Пользовательские истории — это, конечно же, очень хорошо. Но у любой деятельности есть свои цели, процедуры и регламентам. Формализация всего этого приводит к чётким протоколам. Другими словами, нужно изначально иметь достаточно полное покрытие пользовательскими историями, а уже потом, доказав полноту, что-то делать дальше.