Для успешной работы тестировщику необходимо выходить за рамки узкой задачи проверки функций софта. Ему надо представлять использование этого софта и его место в деятельности, встройку в бизнес-уровень. А для проверки устойчивости работы и удержания нагрузок — понимать сопряжение с уровнем hardware. И, наконец, тестировщику нужно уметь проектировать систему кейсов, обеспечивающую надлежащее качество софта.

Всё это требует умения понимать и строить различные модели и способы их сопряжения между собой. Мощным инструментом, который обеспечивает такую работу, является системное мышление. Понятно, что о нём невозможно рассказать в одном докладе, но мой рассказ даст обзорные представления, а главное — покажет место системного мышления в работе тестировщика и, надеюсь, даст импульс к более глубокому изучению.

Аналитику часто требуется быстро понимать мышление и эмоции людей, причём делать это быстро. Например, ты предлагаешь решение заказчику, а в ответ идёт эмоциональная реакция от тех, кого первый раз увидел на встрече. Или когда команда отказывается принять очередные требования заказчика.

Этому помогают модели softskill: они позволяют понять, как думают и действуют другие люди, которые на тебя непохожи. Модели также помогают взглянуть на себя со стороны, оценить потенциал своего развития. Польза от моделей такая же, как от знания шаблонов для проектирования: можно работать без них, но с ними — быстрее и эффективнее, хотя неуместное применение может нанести вред.

Моделей много, и у меня получилось собрать комплексную модель, объединив психологию и нейрофизиологию. И в докладе я покажу ее применение на конкретных кейсах.

Для продуктивного сотрудничества надо уметь быстро понимать других людей и вести эффективную коммуникацию с членами команды, стейкхолдерами, пользователями и смежными командами. Этому помогают многие модели softskill: они позволяют понять, как думают и действуют другие люди, которые на тебя непохожи, показывают разнообразие. Другие модели описывают конструкцию и динамику развития команды. 

Системное мышление – мощный инструмент построения моделей реального мира и проектирования его изменений. О нем, и лежащем в основе рациональном мышлении я рассказывал на осенней AnalystDays. Но действительно ли такие мощные инструменты общего характера необходимы аналитику и архитектору в повседневной работе? Может быть, достаточно более простых методик: выделение словаря предметной области, mindmap для структурирования, bpmn для процессов, с4 model и Archimate для архитектуры ИТ-ландшафта, ООП для построения структур данных, user story и use case для описания работы пользователей, DDD и Event storming для сложных предметных областей? Все они разработаны для ИТ и успешно работают. 

Мой опыт говорит, что прикладные методы – это хорошо и правильно, но без опоры на системное мышление их формальное применение приводит к ошибкам проектирования. В докладе я сделаю фокус на точках в проекте, где владение системным мышлением существенно и покажу, как прикладные методы на него опираются. 

Современный мир предполагает, что ты активно определяешь свой путь, а не следуешь по стандартной карьерной лестнице. Для успешного самоопределения надо уметь работать с многими вопросами: 

• Как понять, стоит ли двигаться дальше, или стоит еще задержаться на текущем месте? 
• Как представить варианты развития и выбрать из них? 
• Как отличить трудности обучения от усталости при выборе не своего дела? 
• Как понять, что пора сходить в отпуск, чтобы энергия не иссякла, или заняться семьей?

Ответам на такие вопросы не учат в школе и институте, это приходится осваивать самому. Я расскажу о схемах, которые позволяют обо всем этом структурировано думать и принимать решения. 

Это - далеко не первое мое выступление по теме, предыдущие можно посмотреть на моем сайте https://mtsepkov.org/Self-Det. Но при подготовке мы обсудили с ПК актуальные вопросы, с которыми тестировщики часто сталкиваются, и фокус рассказа будет на них.

Необходимое умение аналитика – выделять объекты и их взаимосвязи и определять типы и workflow документов, в общем – строить модели. Это надо делать при проведении интервью, анализе документов и Excel-файлов. Обычно для этого используют методы объектно-ориентированного подхода. ООП является частным случаем методов системного мышления, базирующегося на рациональном. Они учат структурировать информацию о мире: выполнять разметку текстов и другого нарратива, строить модели, рассматривая мир как на набор взаимодействующих систем. Понимание этих методов мышления дает мощный аппарат для аналитика для решения сложные задачи. Это аналогично с методами интегрирования: есть частные способы для конкретных интегралов и есть общие подходы. 

В докладе мы поговорим о применении методов рационального и системного мышления для решения задач аналитика. В том числе разберем ситуации, в которых надо выходить за рамки ООП, решая задачи учета, расписания, бюджетирования и другие.

Есть идея, что системы сначала надо описывать как черный ящик, и способам такого описания посвящена инженерия требований. Цель: проверив систему на соответствие требованиям, мы сможем гарантировать соответствие системы потребностям бизнеса и обеспечить гладкое внедрение. Проблема в том, что так — не работает. А значит, нет смысла чересчур углубляться в требования, а стоит быстро переходить к моделям системы, либо использовать легкие варианты фиксации требований. 

В докладе будет обзор разных подходов к написанию постановок: процедурный и объектный подходы, DDD, use case, user story и другие.

Современный мир предполагает, что человек ищет образ своего будущего и строит путь к нему самостоятельно. Стандартные карьерные лестницы неактуальны, быстрое развитие технологий требует менять специализации и осваивать новое. И, в отличие от прошлого, работа становится не просто источником дохода, но и деятельностью профессионального развития, которое дает драйв, самореализацию, энергию и счастье. Человек сам должен проявлять активность, служить драйвером собственных изменений и делать выбор, а не отдавать управление своей жизнью другим: тогда счастье и драйв получишь лишь при удаче. События этой весны сильно подняли актуальность темы, включая решение внутренних конфликтов ценности: геополитика начала гораздо активнее влиять на профессиональное самоопределение.

В докладе будут подходы и схемы, которые позволяют технологично решать задачи построения образа будущего и свою траекторию движения. 

Мы все понимаем, что изменение статуса задачи лишь отражает реальные действия, которые совершал выполнявший эту задачу: он писал постановки или код, выполнял тест-кейсы, делал что-то еще. И никогда не сводим изменение статуса просто к перевешиванию задача в другую колонку. А вот когда аналитик думает, например, про работу с заказом, то для него реальная деятельность остается за кадром, и в мыслях остается только работа с системой. И в результате рождаются решения, которые оказываются не пригодны к реальной жизни, хотя формально в системе есть все необходимые возможности. 

В докладе будут рассмотрены примеры таких проблемных ситуаций. И будет показано, как изменение статусов документов отражает task flow исполнения задач точно так же, как знакомое всем движение задачи по доске, включая декомпозицию большой задачи на несколько и объединение задач в пакеты релизов. 

Современный мир предполагает, что человек ищет образ своего будущего и строит путь к нему самостоятельно. Стандартные карьерные лестницы не актуальны, быстрое развитие технологий требует менять специализации и осваивать новое. И, в отличие от прошлого, работа становится не просто источником дохода, но и деятельностью профессионального развития, которое дает драйв, самореализацию, энергию и счастье. Человек сам должен проявлять активность, служить драйвером собственных изменений и делать выбор, а не отдавать управление своей жизнью другим: тогда счастье и драйв получишь лишь при удаче.

В докладе будут подходы и схемы, которые позволяют технологично решать задачи построения образа будущего и свою траекторию движения. Предыдущие версии доклада "Как строить свой профессиональный путь" https://mtsepkov.org/SelfDet2 фокусировались на построении пути к образу будущего, этот расширен подходами к построению такого образа будущего, который даст смысл жизни, драйв, самореализацию и энергию. 

На ваши вопросы ответят наши эксперты Максим Цепков, Григорий Печенкин, Александр Байкин, Дмитрий Безуглый.

В истории IT сменилось несколько культур разработки софтверных проектов, каждая из них породила не только свои методы ведения проектов (PMBOK, Agile), но и свои способы ведения требований и проектирования софта. Менялись парадигмы программирования: на смену процедурному подходу пришел ООП, появился DDD, позднее фокус сместился на интерфейсы, usability и UX. 

Изменялась архитектура приложения: сначала от клиент-серверной перешли к трехзвенной, затем desktop-клиент сменился вебом с концептами MVC, MVVM и многими другими, появились мобильные приложения, появляются подходы реактивного программирования, приложение состоит из множества сервисов, а пользователь при работе переходит между устройствами. 

Все это требовало новых подходов к проектированию, появлялись новые учебники, посвященные реализации новых концепций, а старые сохраняли актуальность лишь частично. 

Доклад будет посвящен логике развития методов и актуальным современным проблемам проектирования, для которых еще нет учебников.

На прошлой SQA Days я рассказывал модель, которая позволяет эффективно представить современное приложение, состоящее из интегрированного множества сервисов, обменивающихся сообщениями и вызывающими друг друга (https://mtsepkov.org/Multyparadigm-SQA). Эта модель позволяет проектировать сценарии проверки асинхронно взаимодействующих сервисов, включая проверки сложных случаев для обеспечения устойчивости приложения при различных сбоях. 

В продолжение темы доклада будет мастер-класс, в котором применение модели будет разбираться на конкретных кейсах участников. Те, чьи кейсы будут разобраны, получат идеи решения, а остальные увидят практику работы с моделью, оценят ее и смогут подумать о ее применении в своей работе.

На прошлой Analyst Days я рассказывал о модели, которая позволяет эффективно представить современное приложение, состоящее из интегрированного множества сервисов, обменивающихся сообщениями и вызывающими друг друга (https://mtsepkov.org/Multyparadigm-AD). Такая модель соответствует коду и позволяет проектировать изменения при развитии приложения и оценивать их по сложности изменения самой модели. 

В продолжение темы доклада будет мастер-класс, в котором применение модели будет разбираться на конкретных кейсах участников. Те, чьи кейсы будут разобраны, получат идеи решения, а остальные увидят практику работы с моделью, оценят ее и смогут подумать о ее применении в своей работе.

Долгое время большинство приложений разрабатывалось как большие монолиты или системы из крупных модулей (Вирт "Алгоритмы + Структуры данных = Программы"), в которых обработку запроса пользователей можно было представить как выполнение процедуры. И для тестирования было достаточно проверить ответ приложения для пользователя и изменения в базе данных. На основе такой модели можно писать тест-кейсы или чек-листы.

Сейчас чаще используется микросервисная архитектура или акторная модель с асинхронным обменом сообщениями, которые могут теряться или дважды обрабатываться со сложными эффектами. Классической модели приложения уже недостаточно для разработки тестирования приложений - она не дает представления о возникающих проблемах. Необходимы другие модели, адекватные применяемым парадигмам программирования, на основе которых можно прорабатывать сценарии проверки сложных случаев, обеспечивающих устойчивую работу приложения в  сложных ситуациях. О таких моделях пойдет речь в докладе.

Долгое время основным подходом для разработки был ООП. В этом случае объектная модель предметной области в виде структур справочников и документов и связанная с каждым объектом бизнес-логика, созданные аналитиком, служат адекватным проектом для реализации разработчиками в коде, а изменения разработчиками могут быть отражены в модель. В этом случае модель соответствует коду и сложность ее изменения для решения новых требований позволяет примерно оценить сложность разработки. 

Однако, сейчас достаточно распространенными становятся другие парадигмы реализации высоконагруженных приложений, такие как микросервисная архитектура или акторная модель. В этом случае объектной модели предметной области уже недостаточно для представления реализации и требуется иные способы, адекватные применяемым парадигмам программирования. Аналитик должен разбираться в них, чтобы создаваемая модель была адекватна реализации, и по ее изменениям можно было проводить доработки. Об этом пойдет речь в докладе.

С одной стороны, Техническое задание умереть не может. Спецификация требований есть прямое выражение сути системного подхода и мышления. Чем сложнее система тем больше аккуратности и внимательности требуется при внесении любых изменений. И создаваемые системы проще не становятся...
С другой стороны, Факты упрямая вещь - честная процессная/архитектурная работа с каскадом сформированных спецификаций, классические переходы As-Is To-be попадаются гораздо реже, из стартапов рождаются единороги, и там точно не было и не ожидается никаких спецификаций...

Приглашаем к обсуждению на круглом столе:

• Влияние на Бизнес и Системный анализ двух парадигм: проектной и продуктовой.
• Как переходить от одной парадигмы к другой с минимальными личными и организационными потерями.
  
  

При проектировании сложных корпоративных приложений эффективным является использование моделей, описывающих предметную область и само приложение в соответствии с подходом Domain Driven Design. При этом хорошая визуализация является непременным атрибутом модели. В выступлении обменяемся опытом построения архитектуры приложения с использованием трех основных моделей: доменной модели, представленной диаграммой классов, модели движения ресурсов, представленной диаграммами учета и модели документооборота на основе диаграммы состояний. Все это дополняется моделью бизнес-процессов на основе диаграммы деятельностей (activity diagram) и объединяется моделью архитектуры предприятия на основе Archimate, и дополняется метафорой системы в тех случаях, когда ее получается придумать. В рассказе будут приведены примеры диаграмм из реальных проектов.

Аналитики работают на стыке между корпоративными культурами заказчика и команды разработки. Даже в одной компании культуры в подразделениях часто сильно различаются. И аналитику надо уметь, приходя к пользователям и заказчикам на интервью или для других коммуникаций быстро определить их культуру и настроиться на нее: культура задает неявный контекст и определяет смыслы понятий. Смыслы потом надо передать команде разработки с учетом ее культуры. Еще больше понимание культуры необходимо в процессе сдачи и внедрения проекта, обеспечивая коммуникацию и совместную деятельность людей из разных культур.

Для быстрой и эффективной работы в условиях различных культур нельзя исследовать корпоративную культуру компании или подразделения отдельно, необходимо иметь в своем арсенале модели культуры. Я расскажу о спиральной динамики – модели, позволяющей работать с ценностями и культурой людей и организаций. Доклад будет развитием моих лекций и статей по этой теме, с фокусом на работе аналитика.

Заказчики часто формулируют запрос на разработку как идею конкретного функционала. Исполнители в свою очередь начинают немедленно проектировать требуемое, не выяснив, какие проблемы предполагается решить. В результате разработанное решение не устраивает клиента, и у этого может быть несколько причин. Во-первых, идея заказчика может изначально не соответствовать ситуации. Во-вторых, детали реализации могут сделать решение неверным, даже если замысел был правильным. В-третьих, бывает, что задание можно выполнить проще и быстрее. Поэтому аналитик должен выяснить проблемы у заказчика уже на первом этапе проекта.

В докладе я расскажу о том, как это сделать, и приведу примеры, как меняются пути решения после погружения в бизнес-замысел проекта.

Одна из задач тестировщика - посмотреть на систему глазами службы сопровождения, проверить, позволяют ли интерфейсы системы эффективно обрабатывать инциденты, соблюдая SLA. Тем более, что тестировщики часто сами и обеспечивают сопровождение. Хорошо обработать инцидент - это не только локализовать ошибку в системе, но и помочь пользователю решить его бизнес-задачу, найти обходной путь "здесь и сейчас". А причина проблемы может быть не только там, где возник инцидент, но и в смежной системе. Опыт показывает, что это часто является слабым местом и требует привлечения разработчиков для прямого анализа данных и их исправления непосредственно в базе.

На основе своего опыта я расскажу, какие функции полезны в системе для эффективного решения инцидентов межсистемной интеграции, а также инцидентов, связанных с обработкой особых бизнес-ситуаций и сделок, не предусмотренных в системе. Думаю, рассказ поможет слушателям взглянуть на свою систему с точки зрения соблюдения SLA.

Достаточно регулярно слышишь вопросы, подобные следующему: "У нас в проекте Scrum, мне надо писать тест-кейсы для тестировщиков, и я не понимаю, откуда брать информацию." Когда начинаешь обсуждать, то часто выясняется, что под словом "Scrum" в проекте понимают некоторую оригинальную конструкцию, при этом спрашивающий точно уверен, что именно это - и есть Scrum. Между тем, Scrum и другие Agile-методы - нормированная конструкция, о которой можно прочитать документы, и из которых можно вывести ответы на этот и другие вопросы. Но я не буду представлять документы. Я покажу, как мыслить в логике Agile mindset, получая ответы на этот и другие вопросы. При условии, конечно, что такие ценности Agile-манифеста, как работающий софт, сотрудничество с заказчикам и другие не представляются пустым звуком. Покажу на реальных кейсах от слушателей, решая их проблемы.

Когда говорят, что критерием успеха проекта вместо исполнения спецификации в заданный сроки и бюджет теперь является удовлетворенность стейкхолдеров, то многие думают, что они так и работают: в их компаниях давно нацелены на долгосрочные отношения с клиентами и выясняют степень их удовлетворения сотрудничеством. Однако, это - разные вещи, а в дискуссиях на конференции ТочкиСборки я понял, что эта разница не осознается, люди продолжают вести проектную деятельность в старых критериях качества. Поэтому решил сделать об этом краткий доклад на конференции.

Проблема самоопределения, конструирования своего будущего в современном мире становится все актуальнее, в отличие от мира прошлого, в котором ты определялся всего пару раз, выбирая профессию и создавая семью, да и то это часто делали за тебя родители. А сейчас ты должен делать это регулярно, да еще - в быстро развивающемся мире, что особенно заметно в мире IT, на фоне бурного развития технологий. У меня сформировалась сборка из схем, которые помогают это делать. Я о них быстро расскажу в докладе, а потом готов разбирать кейсы желающих в формате barcamp.

Методы проектирования и работы с требованиями должны обеспечивать эффективную коммуникацию между всеми членами команды и гибкую разработку софта с возможностью дальнейшей модернизации. Развитие IT накопило богатый набор разнообразных практик, позволяющих достичь этого в проектах разной сложности, масштаба и назначения: user story, use case, BDD, TDD, FDD, DDD, архитектурная работа в SAF, включая и более традиционные подходы. Как всегда бывает с широким набором инструментов, возникает проблема выбора подходящего. Часто просто выбирают знакомый инструмент или пытаются провести сравнение на модельных задачах, но то, что хорошо для небольшой задачи, не всегда подойдет длинному проекту.

В докладе будет сделан обзор различных практик, решаемых благодаря им коммуникационных задач и предполагаемого разделения труда в команде. Также будут представлены способы поддержки развития и модернизации продукта на долгом жизненном цикле. Доклад является развитием моего поста инженерные практики Agile.

Многие QA-специалисты убеждены, что в ИТ существует единое идеальное представление о качестве и способах его достижения. Поэтому ситуация, когда при переходе в другую компанию идеал оказывается иным, ценности подвергаются сомнению, а принятые способы работы сильно отличаются, становится неожиданным шоком.

Дело в том, что понимание критериев качества в ИТ-проектах прошло длинный путь от ориентации на совершенное инженерное изделие до удовлетворения интересов стейкхолдеров и обеспечения возможностей для бизнеса. Сегодня приходит осознание, что в разных проектах требуется разное качество, критерии которого к тому же меняются в ходе проекта.

В докладе будет представлено пространство описания критериев качества и разделения ответственности в проектах, которое мы разберем на подробных примерах.

Выступление развивает темы моих докладов (http://mtsepkov.org) про эволюцию критериев качества (AgileDays-2015) и разделению ответственности (AnalystDays-2015).

Обычно работа аналитика начинается с выстраивания иерархической системы понятий и структур, где все разложено по полочкам для всех стейкхолдеров. Так устроено научное мышление. Но есть альтернатива — облако тегов, понятий, связанных ассоциативными цепочками. Так мыслит ребенок, когда еще не может создавать стройные структуры. Раньше полагали, что профессионал должен оперировать строгими конструкциями, но сейчас пришло понимание, что второй способ тоже эффективен: так работает маркетинг, политтехнологии и масс-медиа.

Появилось даже специальное слово - фолксономии- в противовес таксономиям, отражающим строгие классификации. Представьте, что вы описываете коллеге стройную архитектуру. И вроде он понимает все слова. Только в голове у него вместо таксономий — облака фолксономий, в которые ваша конструкция ляжет совсем по-другому.

Аналитик должен уметь с этим работать, в выступлении я покажу способы работы на основе схемы мыследеятельности и других схем СМД-методологии.

Разделение ролей и ответственности в разработке — одна из самых популярных тем для обсуждений. Причем зачастую участники подобных дискуссий совершенно уверены, что другие просто неправильно понимают круг своих обязанностей, который им достоверно известен. На самом деле никакого «единственно правильного» разделения ответственности не существует — границы надо проводить с учетом особенностей конкретного проекта, поскольку пропорции аналитической работы, технического проектирования, разработки и тестирования в каждом случае разные.

За время доклада мы попробуем разобраться, как могут быть распределены функции между ролями в компании-разработчике, между подрядчиком и заказчиком, между ИТ и бизнесом на стороне клиента, и каким образом этим можно управлять. А также обратимся к историческим корням вариантов разделения ролей, поговорим о ключевых особенностях проектов, которые нужно учитывать при проектировании ролевой структуры, и о «тонких местах», возникающих при том или ином разделении.

Спиральная динамика вошла в мою картину мира осенью прошлого года и дала системный взгляд на многие тренды развития общества и менеджмента в ИТ и за его пределами. О системе в целом я рассказывал на конференции Agile Days , а тут я буду говорить о другом – о том, как она влияет на понимание процессов в компании, отрасли и в мире.

И как она позволяет позиционировать себя в этих процессах, как более осознанно принимать решения.

Я попробую сделать это из позиции тестировщика, который хочет развиваться в менеджера, и рассмотреть вопросы, которые представляются важными и ответы, которые дает спиральная динамика

Разделение ролей и ответственности в разработке — одна из самых популярных тем для обсуждений. Причем зачастую участники подобных дискуссий совершенно уверены, что другие просто неправильно понимают круг своих обязанностей, который им достоверно известен. На самом деле никакого «единственно правильного» разделения ответственности не существует — границы надо проводить с учетом особенностей конкретного проекта, поскольку пропорции аналитической работы, технического проектирования, разработки и тестирования в каждом случае разные. За время доклада мы попробуем разобраться, как могут быть распределены функции между ролями в компании-разработчике, между подрядчиком и заказчиком, между ИТ и бизнесом на стороне клиента, и каким образом этим можно управлять. А также обратимся к историческим корням вариантов разделения ролей, поговорим о ключевых особенностях проектов, которые нужно учитывать при проектировании ролевой структуры, и о «тонких местах», возникающих при том или ином разделении.

Есть много подходов к работе с требованиями — user story, use case и т. д., — но все они описывают в основном поведенческие аспекты. А что делать, если мы работаем в сфере, где бизнес-требования достаточно сложны и объекты меняют поведение в зависимости от контекста? Domain-Driven Design — подход, превращающий предметную область из «темного леса» в прозрачную систему. Единый язык устраняет трудности перевода между заказчиками, аналитиками, командой разработки и тестировщиками. Это позволяет модели, описанной на этом языке, заменить традиционные требования, которые служат лишь для построения модели, а затем теряют актуальность. Такой подход качественно упрощает процесс проектирования и значительно снижает риски IT-проектов, позволяя бизнес-специалистам заказчика полноценно верифицировать модель системы. А в процессе эксплуатации модель обеспечивает возможность эффективного развития системы на протяжении многих лет вслед за развитием бизнеса заказчика.

Кто из нас не сталкивался с ситуацией, когда реализованные требования Заказчика оказываются совсем не тем, что ему требовалось? Из-за чего реализацию приходится многократно переделать, если не выбрасывать. В докладе мы расскажем о построении отношений с Заказчиком, нацеленном на решение его проблем, а не на отработку требований. Это не просто рассказ о том, как вам жить, - доклад построен на реальных кейсах, возникающих при взаимоотношениях с Заказчиком. Предложим методы построения отношений, разберем сочетание неформальных и формальных коммуникаций, а также вопросов стоимости и оплаты работ. Еще мы затронем психологическую составляющую на разных этапах проекта. Без этого никак, ведь совместная работа предполагает не формальное взаимодействие, а коммуникации и сотрудничество, с перспективой построения партнерских отношений для совместного создания value. В соавторстве с Андреем Мясниковым и Риной Ужевко.