7212
правок
Изменения
Новая страница: «Прошел двенадцатый IT Global Meetup - очередная встреча IT-сообществ Санкт-Петербурга. Помещение…»
Прошел двенадцатый IT Global Meetup - очередная встреча IT-сообществ Санкт-Петербурга. Помещение, в котором проводили расширилось, добавился еще один зал - и потому участников было больше, чем в прошлые разы - 850 участников. Было много интересны докладов, и очень много общения. Дальше - мои впечатления о докладах.
{{RightNote|[https://www.facebook.com/mtsepkov/posts/1692096747513939 Пост на FB]}}
Доклад "'''Blockchain для корпоративных решений: варианты применения'''" - хороший концептуальный обзор технологии blockchain - общие составляющие (распределенность, блоки, транзакции и др.), точки вариации - алгоритмы консенсуса (ресурсные и голосовательные в разных вариантах) и содержание транзакции, смарт-контракты как транзакции, содержащие вызов кода, который тоже хранится в системе и варианты версионирования и сохранения данных в реализациях. И платформы (hyperledger, ethereum, finchain), которые дают готовые реализации и позволяют строить свои в разных вариантах. С преимуществами, проблемами и примерами применений. На мой взгляд, если представить учебник по blockchain, то в докладе - введение в каждую из глав. При этом учебника по blockchain - нет, потому что технология развивается и учебник непрерывно дописывается. И в этом смысл доклада - он позволяет в целом, в контексте твоего проекта понять - стоит посмотреть на применение blockchain в конкретном варианте для них, наряду с другими, или смысла нет. Естественно, об этом есть статьи, могут быть альтернативные способы знакомства. Но мне доклады на конференциях нравятся больше. Спасибо Александр Урмазов (если я верно записал имя, в программе нет :( )
{{RightNote|[https://www.facebook.com/mtsepkov/posts/1692102807513333 Пост на FB]}}
'''Ping yourself''' [https://www.facebook.com/irina.matveeva.796 Ирина Матвеева] на островке [https://www.facebook.com/groups/spbcoa/ СПб СоА (Сообщество аналитиков Санкт-Петербурга)] - работа по рефлексивному самоопределению по пирамиде Дилтса, индивидуально, с обсуждением в парах и группах. Это как раз к вопросу об уровне самосознания IT-шников - работа со специальными инструментами soft skill на уровне рядовых сотрудников. А я, заглянув на это выступление, соотнес для себя пирамиду Дилтса со схемой самоопределения Щедровицкого, о которой рассказывал прошлой весной на #sqadays и недавно на #teamleadconf, и которую мы будем обсуждать с [https://www.facebook.com/exsel9 Алексей Фёдоров] на островке тестировщиков позднее. А еще эти активности показывают профит #itgm как точку кооперации сообществ - Ирина из IT HR, и ее позвали к аналитикам.
{{RightNote|[https://www.facebook.com/mtsepkov/posts/1693417877381826 Пост на FB]}}
На #itgm был очень интересный трек [https://www.facebook.com/spbsqa/ SPB SQA Group]. У него была сквозная тема - '''разделение труда в тестировании''', и доклады и обсуждения нанизывались на эту тему. Я был только на последнем слоте, где мы вели обсуждение про схемы самоопределения, но открывая слот [https://www.facebook.com/exsel9 Алексей Фёдоров] повторил для всех, включая вновь пришедших, содержание предыдущих серий - углубление специализаций, выделение отдельных, подвижность границ между тестировщиками и смежными специализациями - разработчиками, менеджерами, аналитиками. И потом как раз перешел к теме слота - схемам, которые помогают в этом самоопределиться.
[[Файл:Responsibility for Quality in IT-Projects Tsepkov SQAdays-20 (2016-11).pdf|right|page=36|400px]]
[[Файл:SelfDet-Tsepkov-TeamLead2018.pdf|right|page=20|400px]]
И началось все как раз с определения тестирования, которое я нарисовал на V-диаграмме - между разработкой и эксплуатацией, и тоже с подвижными границами. И тут же был пойман на несоответствии современным практикам, включающим тестирование требований, тестирование дизайна и другие подобные вещи, которые на V-диаграмме особо нет - и пришлось уже диаграмму жизненного цикла альф OMG Essence, показать путь по ней от гипотезы о возможности через требования к системе, и назад во внедрение, и там кусочки, к которым в принципе применимо слово тестирование - а уж делают их тестировщики, или аналитики, или кто-то еще - вопрос второй.
И дальше мы пошли по схеме самоопределения, которую я уже рассказывал на #SQAdays, а тут мы по ней проходили конкретный кейс - предположим тестировщик хочет ввести практику тестирования требований и занять это место. Для начала - эту позицию как отдельную надо ввести в систему разделения труда. И показать, в чем ее ценность. И тут могут быть разные ситуации: может быть, что требования в проекте не тестируют и из-за этого есть проблемы, когда реализуют не то и не так. А может быть, это уже неявно делает аналитик - и тогда, если это захотел сделать тестировщик, надо понять самому и показать другим, что от такого перераспределения обязанностей будет выигрыш и для команды в целом, и для ее участников, в частности для аналитика. Дальше - розочка компетенций - тех, которые требуются, и тех, которые у тебя уже есть, и, из их сравнения - для тех компетенций, которые будут у тебя, занимающегося тестированием требований. Вернее, не у тебя, а у твоей марионетки. Потому что в этот момент ты раздваиваешься: ты по-прежнему продолжаешь занимать позицию тестировщика продукта и начинаешь занимать новую позицию тестировщика требований, и это делают две твоих разных марионетки, с разными компетенциями. И еще решить, как ты будешь компенсировать недостаток компетенций, который есть на входе, например, коммуникаций с заказчиком, или знание предметной области на бизнес-уровне. Чему-то требуется научиться на входе, а что-то можно прокачивать в процессе работы, в том числе - за счет постепенного изменения обязанностей. А где-то можно просто подвинуть границы позиции. А потом, если практика оказывается удачной, и ей следуют другие команды - то уникальная позиция в конкретном проекте превращается в роль, распространенную в компании. А ты сам, накапливая опыт, превращаешь разовую марионетку в свое амплуа. Последнее превращение фиксируется в резюме отдельной строкой опыта.
А в ответах на вопросы вернулись к тому, как убеждать других участников команды, что тестирование требований - это правильно. Тут я вспомнил ценностного предложения - Деятельность пользователя, в данном случае - команды, в ней - боли и выгоды, о которых надо договориться, потому что это ты можешь думать, что постоянные переделки - это боль, а оказывается - это источник дохода компании. А дальше против них - Тестирование требований как Средство, которое как-то снимает боли и увеличивает выгоды.
{{wl-publish: 2018-03-18 19:18:53 +0300 | MaksTsepkov }}
{{RightNote|[https://www.facebook.com/mtsepkov/posts/1692096747513939 Пост на FB]}}
Доклад "'''Blockchain для корпоративных решений: варианты применения'''" - хороший концептуальный обзор технологии blockchain - общие составляющие (распределенность, блоки, транзакции и др.), точки вариации - алгоритмы консенсуса (ресурсные и голосовательные в разных вариантах) и содержание транзакции, смарт-контракты как транзакции, содержащие вызов кода, который тоже хранится в системе и варианты версионирования и сохранения данных в реализациях. И платформы (hyperledger, ethereum, finchain), которые дают готовые реализации и позволяют строить свои в разных вариантах. С преимуществами, проблемами и примерами применений. На мой взгляд, если представить учебник по blockchain, то в докладе - введение в каждую из глав. При этом учебника по blockchain - нет, потому что технология развивается и учебник непрерывно дописывается. И в этом смысл доклада - он позволяет в целом, в контексте твоего проекта понять - стоит посмотреть на применение blockchain в конкретном варианте для них, наряду с другими, или смысла нет. Естественно, об этом есть статьи, могут быть альтернативные способы знакомства. Но мне доклады на конференциях нравятся больше. Спасибо Александр Урмазов (если я верно записал имя, в программе нет :( )
{{RightNote|[https://www.facebook.com/mtsepkov/posts/1692102807513333 Пост на FB]}}
'''Ping yourself''' [https://www.facebook.com/irina.matveeva.796 Ирина Матвеева] на островке [https://www.facebook.com/groups/spbcoa/ СПб СоА (Сообщество аналитиков Санкт-Петербурга)] - работа по рефлексивному самоопределению по пирамиде Дилтса, индивидуально, с обсуждением в парах и группах. Это как раз к вопросу об уровне самосознания IT-шников - работа со специальными инструментами soft skill на уровне рядовых сотрудников. А я, заглянув на это выступление, соотнес для себя пирамиду Дилтса со схемой самоопределения Щедровицкого, о которой рассказывал прошлой весной на #sqadays и недавно на #teamleadconf, и которую мы будем обсуждать с [https://www.facebook.com/exsel9 Алексей Фёдоров] на островке тестировщиков позднее. А еще эти активности показывают профит #itgm как точку кооперации сообществ - Ирина из IT HR, и ее позвали к аналитикам.
{{RightNote|[https://www.facebook.com/mtsepkov/posts/1693417877381826 Пост на FB]}}
На #itgm был очень интересный трек [https://www.facebook.com/spbsqa/ SPB SQA Group]. У него была сквозная тема - '''разделение труда в тестировании''', и доклады и обсуждения нанизывались на эту тему. Я был только на последнем слоте, где мы вели обсуждение про схемы самоопределения, но открывая слот [https://www.facebook.com/exsel9 Алексей Фёдоров] повторил для всех, включая вновь пришедших, содержание предыдущих серий - углубление специализаций, выделение отдельных, подвижность границ между тестировщиками и смежными специализациями - разработчиками, менеджерами, аналитиками. И потом как раз перешел к теме слота - схемам, которые помогают в этом самоопределиться.
[[Файл:Responsibility for Quality in IT-Projects Tsepkov SQAdays-20 (2016-11).pdf|right|page=36|400px]]
[[Файл:SelfDet-Tsepkov-TeamLead2018.pdf|right|page=20|400px]]
И началось все как раз с определения тестирования, которое я нарисовал на V-диаграмме - между разработкой и эксплуатацией, и тоже с подвижными границами. И тут же был пойман на несоответствии современным практикам, включающим тестирование требований, тестирование дизайна и другие подобные вещи, которые на V-диаграмме особо нет - и пришлось уже диаграмму жизненного цикла альф OMG Essence, показать путь по ней от гипотезы о возможности через требования к системе, и назад во внедрение, и там кусочки, к которым в принципе применимо слово тестирование - а уж делают их тестировщики, или аналитики, или кто-то еще - вопрос второй.
И дальше мы пошли по схеме самоопределения, которую я уже рассказывал на #SQAdays, а тут мы по ней проходили конкретный кейс - предположим тестировщик хочет ввести практику тестирования требований и занять это место. Для начала - эту позицию как отдельную надо ввести в систему разделения труда. И показать, в чем ее ценность. И тут могут быть разные ситуации: может быть, что требования в проекте не тестируют и из-за этого есть проблемы, когда реализуют не то и не так. А может быть, это уже неявно делает аналитик - и тогда, если это захотел сделать тестировщик, надо понять самому и показать другим, что от такого перераспределения обязанностей будет выигрыш и для команды в целом, и для ее участников, в частности для аналитика. Дальше - розочка компетенций - тех, которые требуются, и тех, которые у тебя уже есть, и, из их сравнения - для тех компетенций, которые будут у тебя, занимающегося тестированием требований. Вернее, не у тебя, а у твоей марионетки. Потому что в этот момент ты раздваиваешься: ты по-прежнему продолжаешь занимать позицию тестировщика продукта и начинаешь занимать новую позицию тестировщика требований, и это делают две твоих разных марионетки, с разными компетенциями. И еще решить, как ты будешь компенсировать недостаток компетенций, который есть на входе, например, коммуникаций с заказчиком, или знание предметной области на бизнес-уровне. Чему-то требуется научиться на входе, а что-то можно прокачивать в процессе работы, в том числе - за счет постепенного изменения обязанностей. А где-то можно просто подвинуть границы позиции. А потом, если практика оказывается удачной, и ей следуют другие команды - то уникальная позиция в конкретном проекте превращается в роль, распространенную в компании. А ты сам, накапливая опыт, превращаешь разовую марионетку в свое амплуа. Последнее превращение фиксируется в резюме отдельной строкой опыта.
А в ответах на вопросы вернулись к тому, как убеждать других участников команды, что тестирование требований - это правильно. Тут я вспомнил ценностного предложения - Деятельность пользователя, в данном случае - команды, в ней - боли и выгоды, о которых надо договориться, потому что это ты можешь думать, что постоянные переделки - это боль, а оказывается - это источник дохода компании. А дальше против них - Тестирование требований как Средство, которое как-то снимает боли и увеличивает выгоды.
{{wl-publish: 2018-03-18 19:18:53 +0300 | MaksTsepkov }}
