2018-03-18: Прошел ITGM-12
(Из ленты MaksWiki — Блог:Максима Цепкова [ru])
Прошел двенадцатый IT Global Meetup — очередная встреча IT-сообществ Санкт-Петербурга. Помещение, в котором проводили расширилось, добавился еще один зал — и потому участников было больше, чем в прошлые разы — 850 участников. Было много интересны докладов, и очень много общения. Дальше — мои впечатления о докладах.
Доклад «Blockchain для корпоративных решений: варианты применения» — хороший концептуальный обзор технологии blockchain — общие составляющие (распределенность, блоки, транзакции и др.), точки вариации — алгоритмы консенсуса (ресурсные и голосовательные в разных вариантах) и содержание транзакции, смарт-контракты как транзакции, содержащие вызов кода, который тоже хранится в системе и варианты версионирования и сохранения данных в реализациях. И платформы (hyperledger, ethereum, finchain), которые дают готовые реализации и позволяют строить свои в разных вариантах. С преимуществами, проблемами и примерами применений. На мой взгляд, если представить учебник по blockchain, то в докладе — введение в каждую из глав. При этом учебника по blockchain — нет, потому что технология развивается и учебник непрерывно дописывается. И в этом смысл доклада — он позволяет в целом, в контексте твоего проекта понять — стоит посмотреть на применение blockchain в конкретном варианте для них, наряду с другими, или смысла нет. Естественно, об этом есть статьи, могут быть альтернативные способы знакомства. Но мне доклады на конференциях нравятся больше. Спасибо Александр Урмазов (если я верно записал имя, в программе нет :( )
Ping yourself Ирина Матвеева на островке СПб СоА (Сообщество аналитиков Санкт-Петербурга) — работа по рефлексивному самоопределению по пирамиде Дилтса, индивидуально, с обсуждением в парах и группах. Это как раз к вопросу об уровне самосознания IT-шников — работа со специальными инструментами soft skill на уровне рядовых сотрудников. А я, заглянув на это выступление, соотнес для себя пирамиду Дилтса со схемой самоопределения Щедровицкого, о которой рассказывал прошлой весной на #sqadays и недавно на #teamleadconf, и которую мы будем обсуждать с Алексей Фёдоров на островке тестировщиков позднее. А еще эти активности показывают профит #itgm как точку кооперации сообществ — Ирина из IT HR, и ее позвали к аналитикам.
На #itgm был очень интересный трек SPB SQA Group. У него была сквозная тема — разделение труда в тестировании, и доклады и обсуждения нанизывались на эту тему. Я был только на последнем слоте, где мы вели обсуждение про схемы самоопределения, но открывая слот Алексей Фёдоров повторил для всех, включая вновь пришедших, содержание предыдущих серий — углубление специализаций, выделение отдельных, подвижность границ между тестировщиками и смежными специализациями — разработчиками, менеджерами, аналитиками. И потом как раз перешел к теме слота — схемам, которые помогают в этом самоопределиться.
И началось все как раз с определения тестирования, которое я нарисовал на V-диаграмме — между разработкой и эксплуатацией, и тоже с подвижными границами. И тут же был пойман на несоответствии современным практикам, включающим тестирование требований, тестирование дизайна и другие подобные вещи, которые на V-диаграмме особо нет — и пришлось уже диаграмму жизненного цикла альф OMG Essence, показать путь по ней от гипотезы о возможности через требования к системе, и назад во внедрение, и там кусочки, к которым в принципе применимо слово тестирование — а уж делают их тестировщики, или аналитики, или кто-то еще — вопрос второй.
И дальше мы пошли по схеме самоопределения, которую я уже рассказывал на #SQAdays, а тут мы по ней проходили конкретный кейс — предположим тестировщик хочет ввести практику тестирования требований и занять это место. Для начала — эту позицию как отдельную надо ввести в систему разделения труда. И показать, в чем ее ценность. И тут могут быть разные ситуации: может быть, что требования в проекте не тестируют и из-за этого есть проблемы, когда реализуют не то и не так. А может быть, это уже неявно делает аналитик — и тогда, если это захотел сделать тестировщик, надо понять самому и показать другим, что от такого перераспределения обязанностей будет выигрыш и для команды в целом, и для ее участников, в частности для аналитика. Дальше — розочка компетенций — тех, которые требуются, и тех, которые у тебя уже есть, и, из их сравнения — для тех компетенций, которые будут у тебя, занимающегося тестированием требований. Вернее, не у тебя, а у твоей марионетки. Потому что в этот момент ты раздваиваешься: ты по-прежнему продолжаешь занимать позицию тестировщика продукта и начинаешь занимать новую позицию тестировщика требований, и это делают две твоих разных марионетки, с разными компетенциями. И еще решить, как ты будешь компенсировать недостаток компетенций, который есть на входе, например, коммуникаций с заказчиком, или знание предметной области на бизнес-уровне. Чему-то требуется научиться на входе, а что-то можно прокачивать в процессе работы, в том числе — за счет постепенного изменения обязанностей. А где-то можно просто подвинуть границы позиции. А потом, если практика оказывается удачной, и ей следуют другие команды — то уникальная позиция в конкретном проекте превращается в роль, распространенную в компании. А ты сам, накапливая опыт, превращаешь разовую марионетку в свое амплуа. Последнее превращение фиксируется в резюме отдельной строкой опыта.
А в ответах на вопросы вернулись к тому, как убеждать других участников команды, что тестирование требований — это правильно. Тут я вспомнил ценностного предложения — Деятельность пользователя, в данном случае — команды, в ней — боли и выгоды, о которых надо договориться, потому что это ты можешь думать, что постоянные переделки — это боль, а оказывается — это источник дохода компании. А дальше против них — Тестирование требований как Средство, которое как-то снимает боли и увеличивает выгоды.