Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Люди любят деньги. Однако, большие деньги их портят. Не стоит полагаться на то, что изобретенная бонусная система сможет повысить продуктивность. Сотрудники всегда способны придумать 400 сравнительно честных способов максимизации бонуса. Прозрачность и понятность процесса сильно страдают.
Тем не менее в большинстве крупных компаний выстроены системы KPI для повышения финансовой заинтересованности в результате. Многим руководителям трудно представить, как можно управлять без этого инструмента. Безусловно, есть определенная доля правды. Это действительно удобный инструмент.
Приходите на доклад, мы разберемся, есть ли рациональное зерно в KPI и какими они должны быть в agile организации.
Дмитрий Грибов, Трава и грибы как средства управления разработкойScrumTrek
Управление разработкой в ЛитРес: Игровые грибы на службе управления проектами Холакратия, настоенная на травах Деревянный Agile Спринты длинною в час и ежедневный релиз Рыночная игра как альтернатива микроменеджменту KPI для разработчиков, основанный на реальных результатах (сдельная оплата программистам в штате) История о том, как команда из 27-и человек эффективно поддерживает и развивать сервис с миллиардной выручкой
Жизнь в стиле стартап в корпоративной среде: Agile в помощь?ScrumTrek
Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.
Максим Цепков, Agile - то что на самом деле нужно гос.заказчикам!ScrumTrek
Многие доклады про использование гибких методологий разработки в проектах с государственным заказчиком рассказывают о том, как изолировать команду от заказчика для обеспечения Agile-процесса. Но нужно ли это на самом деле?
Ведь для заказчика, как правило, важно работающее программное обеспечение, а не документация на него, важно сотрудничество, а не контракты, важна готовность команды к изменениям — иными словами, те ценности, что декларирует Agile-манифест. Формальные требования воспринимаются заказчиком как дополнительная нагрузка на внутренние процессы, которые долго и сложно перестраивать. Поэтому секрет долгосрочного успешного сотрудничества — в грамотной адаптации деятельности компании-разработчика к условиям заказчика. За время доклада мы рассмотрим воплощение этого тезиса на конкретных примерах из опыта работы нашей компании с такими заказчиками, как Банк России, Газпромбанк и другими.
Люди любят деньги. Однако, большие деньги их портят. Не стоит полагаться на то, что изобретенная бонусная система сможет повысить продуктивность. Сотрудники всегда способны придумать 400 сравнительно честных способов максимизации бонуса. Прозрачность и понятность процесса сильно страдают.
Тем не менее в большинстве крупных компаний выстроены системы KPI для повышения финансовой заинтересованности в результате. Многим руководителям трудно представить, как можно управлять без этого инструмента. Безусловно, есть определенная доля правды. Это действительно удобный инструмент.
Приходите на доклад, мы разберемся, есть ли рациональное зерно в KPI и какими они должны быть в agile организации.
Дмитрий Грибов, Трава и грибы как средства управления разработкойScrumTrek
Управление разработкой в ЛитРес: Игровые грибы на службе управления проектами Холакратия, настоенная на травах Деревянный Agile Спринты длинною в час и ежедневный релиз Рыночная игра как альтернатива микроменеджменту KPI для разработчиков, основанный на реальных результатах (сдельная оплата программистам в штате) История о том, как команда из 27-и человек эффективно поддерживает и развивать сервис с миллиардной выручкой
Про качество и красоту кода говорят и пишут очень многие, хотя при этом довольно часто забывают, для чего существует это качество и эта красота.
Двадцать второй онлайн митап Software Craftsmanship будет посвящен Engineering Excellence. мы рассмотрим что такое Engineering Excellence, кому и для чего оно нужно на проекте, из каких частей состоит и как определить что нужно конкретному проекту.
На митапе мы рассмотрим взаимосвязь разработчиков, тестировщиков, девопсов, разберем метрики, практики и процессы необходимы для постоянного улучшения проекта.
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
Agile Vector - внедрение agile разработки в РайффайзенбанкеAlexey Deryushkin
Доклад на 60 минут с пошаговым описанием процесса внедрения гибких методологий разработки в окружении, работающем по «водопаду», проблем такого точечного внедрения и их способов решений на примере нескольких связных проектов, а также влияние такого внедрения на IT банка в целом. Затрагиваются все темы, связанные с постановкой производства ПО -- от технических практик до образа мышления, на примерах из жизни. История успеха длинной в два года, которая не собирается завершаться.
Владимир Завертайлов. Требовательность, мозгоклюйство и провокации: уровни уп...ScrumTrek
Интерактивный мастер-класс, где будет разобрано 8 типичных, но очень не простых для любого руководителя ситуаций. 1. Провокация. 2. Продажа. 3. Жизнь после релиза. 4. Конфликт с дизайнером (я — художник, я так вижу) 5. Конфликт с программистом: требования говно! 6. Интеграция по центрирующим парадигмам 7. Учимся говорить "НЕТ!" 8. Рабочие запахи
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Василий Чепцов, PMBOK для Agile-менеджера. Чем полезен?ScrumTrek
В Agile-сообществе можно встретить немало мифов и поверхностных суждений о подходах к управлению, где не используется слово "Agile". Больше всех, пожалуй, "досталось" методологии управления проектами PMI PMBOK... "Водопад", Гант, куча документации — это же всё ужасно с точки зрения Agile! Недавно мне пришлось хорошенько проштудировать PMBOK (для подготовки к экзамену) и теперь по горячим следам хочется вдумчиво обсудить: — какие популярные суждения о PMBOK верны, а какие нет? — как же всё-таки соотносятся эти подходы? — и, главное, чем нам PMBOK может быть полезен в Agile-разработке?
Михаил Лукьянов, Дмитрий Шайхатаров, Agile среди водопадов. Использование SCR...ScrumTrek
Трудно представить возможность применения Agile в компаниях с большим количеством зарегламентированных процессов, которые, к тому же, ориентированны на водопадную модель разработки ПО. На примере разработки системы управления рисками на Финансовых рынках мы поделимся своим опытом как можно построить полноценный Agile процесс исключительно с использованием стандартного SCRUM framework. Мы расскажем об бизнес процессе, решенных проблемах и инженерных практиках, которые позволили обеспечить высокую скорость delivery в рамках данной системы.
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
Доклад предназначен для Design Team Leads, которые заинтересованы в развитии своих дизайнеров, настройке процесса обучения; и дизайнеров, которые хотят развиваться и расти в профессиональном плане.
Наш департамент вырос с 20 до 55 дизайнеров в короткие сроки. Стала актуальной задача по определению уровня конкретного дизайнера: чем отличается Middle от Senior, как выровнять эти уровни между СНГ, Британией и США. Как обучить такое количество дизайнеров, выстроить Personal Development Plan.
В докладе мы хотим рассказать, какие инструменты и методы мы разработали для этого, какие результаты это принесло.
Прикручивание колёс на ходу. Внедрение UX процессов в уже работающий продуктПрофсоUX
Доклад рассчитан на всех, кому интересна командная работа и дизайн-системы.
У себя в компании мы внедряем дизайн-систему «по-живому» — без отрыва от производства продукта. На конференции я расскажу, зачем мы на это пошли, как доказывали пользу изменений, что уже успели сделать и к чему планируем прийти.
QA Fest 2016. Александр Неделяев. Браузерные помощники тестировщикаQAFest
В темные времена доминации Internet Explorer на рынке браузеров, тестировщик оставался один на один с тестируемым приложением, и лишь усердие, трудолюбие и крепкий алкоголь могли спасти его от безумия и профессионального выгорания.
К счастью, времена изменились. Современные браузеры скрывают в себе множество полезных функций и имеют тысячи плагинов, способных помочь тестировщику веб приложений. Я расскажу вам о браузерных плагинах, которые значительно облегчили тестирование верстки, поизводительности, отзывчивости сайта, позволили мне ускорить выполнение рутинных задач, а также повысили личную эффективность.
Про качество и красоту кода говорят и пишут очень многие, хотя при этом довольно часто забывают, для чего существует это качество и эта красота.
Двадцать второй онлайн митап Software Craftsmanship будет посвящен Engineering Excellence. мы рассмотрим что такое Engineering Excellence, кому и для чего оно нужно на проекте, из каких частей состоит и как определить что нужно конкретному проекту.
На митапе мы рассмотрим взаимосвязь разработчиков, тестировщиков, девопсов, разберем метрики, практики и процессы необходимы для постоянного улучшения проекта.
Software craftsmanship 11 online: мотивация и эффектисность разработчикаPavel Veinik
Мы рассмотрим вопросы продуктивности, как командная работа и менеджеры влияют на продуктивность, как связаны оценки и эффективность решений разработчика, почему работа программиста является творческой, и как грамотно использовать инструменты тайм-менеджмента.
Agile Vector - внедрение agile разработки в РайффайзенбанкеAlexey Deryushkin
Доклад на 60 минут с пошаговым описанием процесса внедрения гибких методологий разработки в окружении, работающем по «водопаду», проблем такого точечного внедрения и их способов решений на примере нескольких связных проектов, а также влияние такого внедрения на IT банка в целом. Затрагиваются все темы, связанные с постановкой производства ПО -- от технических практик до образа мышления, на примерах из жизни. История успеха длинной в два года, которая не собирается завершаться.
Владимир Завертайлов. Требовательность, мозгоклюйство и провокации: уровни уп...ScrumTrek
Интерактивный мастер-класс, где будет разобрано 8 типичных, но очень не простых для любого руководителя ситуаций. 1. Провокация. 2. Продажа. 3. Жизнь после релиза. 4. Конфликт с дизайнером (я — художник, я так вижу) 5. Конфликт с программистом: требования говно! 6. Интеграция по центрирующим парадигмам 7. Учимся говорить "НЕТ!" 8. Рабочие запахи
Константин Бажин, ТОП 10 не могу или что нужно сделать, чтобы жить по AgileScrumTrek
"Наступать на грабли - это не про нас!" - думали мы, когда ушли в разработку программного обеспечения с головой. И вроде бы все умные и прекрасно понимают как нужно делать правильно. Но! В ситуации, когда количество работы превышает количество ресурсов, а договорные обязательства никто не отменял, в какой-то момент - ЧТО-ТО ПОШЛО НЕ ТАК.
В своем докладе я расскажу как это все произошло и какие выводы мы сделали. А также опишу конкретные шаги, которые предприняли, чтобы этого избежать в дальнейшем.
Василий Чепцов, PMBOK для Agile-менеджера. Чем полезен?ScrumTrek
В Agile-сообществе можно встретить немало мифов и поверхностных суждений о подходах к управлению, где не используется слово "Agile". Больше всех, пожалуй, "досталось" методологии управления проектами PMI PMBOK... "Водопад", Гант, куча документации — это же всё ужасно с точки зрения Agile! Недавно мне пришлось хорошенько проштудировать PMBOK (для подготовки к экзамену) и теперь по горячим следам хочется вдумчиво обсудить: — какие популярные суждения о PMBOK верны, а какие нет? — как же всё-таки соотносятся эти подходы? — и, главное, чем нам PMBOK может быть полезен в Agile-разработке?
Михаил Лукьянов, Дмитрий Шайхатаров, Agile среди водопадов. Использование SCR...ScrumTrek
Трудно представить возможность применения Agile в компаниях с большим количеством зарегламентированных процессов, которые, к тому же, ориентированны на водопадную модель разработки ПО. На примере разработки системы управления рисками на Финансовых рынках мы поделимся своим опытом как можно построить полноценный Agile процесс исключительно с использованием стандартного SCRUM framework. Мы расскажем об бизнес процессе, решенных проблемах и инженерных практиках, которые позволили обеспечить высокую скорость delivery в рамках данной системы.
Опыт госпроектов и взаимодействия с корпоративными структурамиПрофсоUX
Доклад предназначен для UX-специалистов, руководителей проектов и всех остальных.
В последнее время UX-специалисты и компании все чаще привлекаются к реализации проектов для корпораций и государственных заказчиков. На первый взгляд кажется, что при работе с ними попадаешь из мира сотрудничества в мир формальных взаимодействий. На самом деле построить с такими заказчиками настоящее сотрудничество вполне возможно. Более того, заказчик в нем заинтересован, просто не всегда представляет, как это сделать. В докладе я поделюсь практиками работы с крупными заказчиками из опыта компании CUSTIS.
Доклад предназначен для Design Team Leads, которые заинтересованы в развитии своих дизайнеров, настройке процесса обучения; и дизайнеров, которые хотят развиваться и расти в профессиональном плане.
Наш департамент вырос с 20 до 55 дизайнеров в короткие сроки. Стала актуальной задача по определению уровня конкретного дизайнера: чем отличается Middle от Senior, как выровнять эти уровни между СНГ, Британией и США. Как обучить такое количество дизайнеров, выстроить Personal Development Plan.
В докладе мы хотим рассказать, какие инструменты и методы мы разработали для этого, какие результаты это принесло.
Прикручивание колёс на ходу. Внедрение UX процессов в уже работающий продуктПрофсоUX
Доклад рассчитан на всех, кому интересна командная работа и дизайн-системы.
У себя в компании мы внедряем дизайн-систему «по-живому» — без отрыва от производства продукта. На конференции я расскажу, зачем мы на это пошли, как доказывали пользу изменений, что уже успели сделать и к чему планируем прийти.
QA Fest 2016. Александр Неделяев. Браузерные помощники тестировщикаQAFest
В темные времена доминации Internet Explorer на рынке браузеров, тестировщик оставался один на один с тестируемым приложением, и лишь усердие, трудолюбие и крепкий алкоголь могли спасти его от безумия и профессионального выгорания.
К счастью, времена изменились. Современные браузеры скрывают в себе множество полезных функций и имеют тысячи плагинов, способных помочь тестировщику веб приложений. Я расскажу вам о браузерных плагинах, которые значительно облегчили тестирование верстки, поизводительности, отзывчивости сайта, позволили мне ускорить выполнение рутинных задач, а также повысили личную эффективность.
The document discusses different topics related to animals including native animals, wild animals, pets, domestic animals, fear of animals, animal intelligence, zoos, and pests. It provides vocabulary for each section and questions to prompt discussion about various animals found in different countries and environments.
MDM Engineering contracted AGE Technologies to supply all requirements for the expansion of the Tharisa Mine, the largest known chrome deposit in the world. AGE's scope included supplying PLC hardware and SCADA software, manufacturing control panels, installing an ethernet and profibus fiber network, and commissioning engineers to assist with testing and commissioning. The fiber network installation involved over 18km of outdoor cable. The total value of the project was 5.9 million over its 8 month duration.
This message is wishing Michelle Lauren Menefee a happy birthday and expressing sadness that the sender cannot be there to celebrate. It references fun memories the two friends have shared, such as taking random photos in a car when bored, and says a favorite embarrassing photo from a year ago is included to make Michelle laugh. The sender expresses love and appreciation for their best friend.
Shannon Smith is an experienced industrial designer seeking new opportunities. She has over 15 years of experience leading design projects for companies in Australia, the UK, and Japan. Her background includes senior roles at The Alloy, Studio Conran, and CobaltNiche, where she managed teams and brought products from concept to manufacture. She has extensive skills in design, project management, and CAD software.
Empower students to write with digital tools slide shareKevin Amboe
ISTE 2011 Workshop - Empower students to write with digital tools - Reviewing tools to reach the goal of students being engaged in writing. (See handout on https://iamliterate.wikispaces.com/Engage+Students+as+Writers)
RefWorks for DEPARTMENT OF FAMILY MEDICINE - Faculty Development Naz Torabi
This document provides an overview of how to use RefWorks, a bibliographic citation manager. It describes how to set up a RefWorks account, import references from various sources directly or indirectly, organize references into folders, share folders, create bibliographies, and access RefWorks off-campus. It also summarizes the features of RefWorks for saving citations, organizing research, and creating bibliographies from included citations in papers. Contact information is provided for getting help with RefWorks.
GLOBALIZING TORTURE: CIA SECRET DETENTION AND EXTRAORDINARY RENDITION Valentin Vesa
This document summarizes a report about the CIA's secret detention and extraordinary rendition programs following the September 11, 2001 terrorist attacks. It describes how the CIA secretly detained over 100 suspected terrorists in black site prisons around the world and engaged in extraordinary rendition, transferring detainees to foreign countries without legal process for interrogation under torture. The CIA conducted these operations with the participation of at least 54 foreign governments who hosted CIA prisons, detained and tortured individuals, assisted with captures and secret flights, and more. However, the full scale of foreign government involvement and number of victims remains unknown due to extreme secrecy. The document calls for the U.S. and partner governments to acknowledge and be held accountable for their roles in these human rights violating programs
This document provides guidelines for camera buyers from the perspective of a repairer. It suggests considering your filming habits and needs, such as whether sound quality is important or broadcast quality is required. It also recommends considering the camera's type of storage, such as hard drive, flash memory, tape, or disc, as well as features like the number of image chips and connectivity. The document further advises considering camera brand and budget from the viewpoint of repair costs and reliability.
"Опыт создания системы управления сборкой и тестированием" (слайдкаст)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
John lives in London with his family. He rides his bike to work, which takes 30 minutes and is 5 miles. On weekends, he enjoys playing sports. He has lived in London for 20 years and likes it there. John's wife Mary is a teacher. They have two children, Jack and Susan, who attend Mary's school. The family also has a dog named Patch and Susan has a cat named Snowy.
Post Agile эра / Борис Вольфсон (HeadHunter)Ontico
Многие компании успешно используют Agile-методологии на протяжении многих лет. На данный момент некоторые из них переосмысливают понимание Agile, распространяя его за пределы конкретных методологий.
Я расскажу о том, как сделать компанию / подразделение по-настоящему гибкими, выстроив собственный Agile-фреймворк. Для создания такого фреймворка нужно понимать, из чего он состоит: от методологии управления проектами до организационной культуры.
Если вы уже успешно используете Scrum или Kanban и задумываетесь о том, что вам необходимо делать дальше - добро пожаловать на мой доклад!
Саша Куценко: "Cпецификация формы и поведения — зачем, кому и как?"Sasha Kutsenko
Презентация Саши Куценко для семинара «Front-end разработка. Менеджерский блок», 29 января 2014 года, Санкт-Петербург.
http://leadzeppelin.timepad.ru/event/101471/
Борис Вольфсон. Agile ценности и принципы для новичков.ScrumTrek
Это базовый доклад для новичков в Agile, которые только хотят использовать гибкие подходы, будет построен через ценности и принципы, на которых строятся отдельные практики и целые фреймворки. Понимание Agile через призму ценностей и принципов позволит не только лучше разбираться в гибком фреймворке Scrum и методе Kanban, но и после освоения основ изменять их под свою среду и нужды.
Обсуждаем главы из “97 Things Every Programmer Should Know”SPB SQA Group
Ограничимся несколькими главами:
Правило туриста (The Boy Scout Rule);
Непрерывное обучение (Continuous Learning);
Не работайте сверхурочно (Hard Work Does not Pay Off);
Наблюдайте за пользователями (Ask «What Would the User Do?» (You Are not the User));
Пишите код так, как будто вы будете сопровождать его до конца жизни (Write Code as If You Had to Support It for the Rest of Your Life);
Хороший интерфейс: легко использовать правильно, сложно использовать неправильно (Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly);
Миф о гуру (The Guru Myth);
Не надейтесь на магию (Don’t Rely on «Magic Happens Here»).
ITGM8. Всеволод Брекелов (Grid Dinamics) Component tests. let's do that!SPB SQA Group
The document discusses component testing for scalable eCommerce platforms. It defines component tests as focusing on individual units or components in isolation from their peers, providing faster test execution and easier debugging compared to integration tests. Examples are provided for implementing component tests on both the front-end and back-end of an eCommerce application, including mocking external services, databases, and other dependencies. Skills needed for component testing like TypeScript, Angular, Spring, and testing frameworks are also outlined.
Об измерениях в разработке ПО слышали все. Но какая от польза от их внедрения? И какие необходимые условия внедрения?
Вашему вниманию будут представлены различные способы измерения качества продукта, как их можно использовать для улучшений рабочих процессов, определения проблем, поддержки контрактных обязательств, оценки достижения целей индивидуума, отдела или компании. Также вы узнаете, как выбрать и внедрить действительно нужные метрики.
Автоматизируем тестирование интерфейса мобильных приложенийSPB SQA Group
В докладе рассказано, что из себя представляют автоматические тесты интерфейса мобильных приложений и когда их стоит внедрять, сделан обзор наиболее распространенных бесплатных средств автоматизации для iOS и Android.
"Опыт создания системы управления сборкой и тестированием" (полная)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
Часто о нагрузочном тестировании рассказывают через призму используемого инструментария, хорошо раскрывая слово «нагрузочное» и часто оставляя слово «тестирование» за кадром. Так давайте же попробуем поговорить о месте именно тестирования в нагрузочном тестировании.
Мы часто жалуемся, что от нас (тестировщиков и тест-менеджеров) мало что зависит, а спрос большой. Нам не хватает требований, мы не можем исправить баги и не обеспечиваем качество, нам не хватает общения с клиентами. Мы даже на коллег повлиять не всегда можем!
Для кого-то эти и другие схожие факты являются причинами не улучшать результаты своей работы. А для кого-то – просто отмазками!
Хотите узнать, как решать эти «нерешаемые» проблемы, приносить пользу компании и делать свою работу интереснее? Тогда я расскажу вам о своём опыте исправления различных проблем в тестировании, которые, как казалось, нам неподвластны. Их решение – это и новый уровень задач, и новый уровень ответственности, и море положительных эмоций.
Automating JFC UI application testing with JemmySPB SQA Group
В докладе рассказано о нескольких подходах к автоматизации тестирования через пользовательский интерфейс. Вы узнаете как автоматизировать приложения на Java Swing. Также будет рассмотрен инструмент автоматизированного тестирования Jemmy, продемонстрирована работа с ним. Еще вы познакомитесь с новыми возможностями Jemmy 3.
Domain-тестирование – формальное название методики тестирования, за которым скрывается банальная работа с классами эквивалентности. Впрочем, не такая уж и банальная. Даже в популярной литературе по тестированию часто упоминают только о существовании классов эквивалентности и о том, что с их граничными значениями работать очень полезно.
Мы знакомимся с основами этой методики, когда делаем первые шаги в тестировании, и больше никогда о ней не задумываемся, наивно считая, что она попала в нашу зону неосознанной компетентности и мы всегда используем ее правильно. А так ли это?
Оптимизация интерактивного тестирования с использованием метрики Покрытие кодаSPB SQA Group
Доклад посвящен исследованию возможности оптимизации количества запускаемых интерактивных тестов базируясь на оценке покрытия. Как пример, приведены результаты, которых мы достигли в нашей компании — обоснованное уменьшение количества запускаемых тестов с ~900 до ~130. Также освещены некоторые аспекты работы с метрикой «покрытие кода».
5. In the late 1990’s several methodologies began to get increasing public attention.
Each had a different combination of old ideas, new ideas, and transmuted old
ideas. But they all emphasized close collaboration between the programmer team
and business experts; face-to-face communication (as more efficient than written
documentation); frequent delivery of new deployable business value; tight, self-
organizing teams; and ways to craft the code and the team such that the
inevitable requirements churn was not a crisis.
6. http://agilemanifesto.org/
Agile-манифест разработки программного
обеспечения
Мы постоянно открываем для себя более совершенные методы разработки программного
обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря
проделанной работе мы смогли осознать, что:
Люди и взаимодействиеважнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.
7. Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения.
Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества.
Работающий продукт следует выпускать как можно чаще, с периодичностью
от пары недель до пары месяцев.
На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.
Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им.
Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.
Работающий продукт — основной показатель прогресса.
Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки.
Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
Простота — искусство минимизации лишней работы — крайне необходима.
Самые лучшие требования, архитектурные и технические решения рождаются
у самоорганизующихся команд.
Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать
стиль своей работы.
Agile Alliance,
http://www.agilealliance.org/
8. 3 слова для каждого принципа
Картинка
На все – 10 минут
9. - Scrum
- Kanban/Lean
- Xtreme Programming
- Crystal
- DSDM (Dymanic System
Development Met.)
- Feature Driven Development
10. 1962, Toyota
“Кан” - видимый, визуальный, и “бан” - карточка
или доска.
1. Визуализируйте производство (visualize
workflow)
— Разделите работу на задачи, каждую задачу
напишите на карточке и поместите на стену или
доску.
— Используйте названные столбцы, чтобы
показать положение задачи в производстве.
2. Ограничивайте WIP (work in progress или работу,
выполняемую одновременно) на каждом этапе
производства. (limit work-in-progress)
3. Измеряйте время цикла (среднее время на
выполнение одной задачи) и оптимизируйте
постоянно процесс, чтобы уменьшить это время.
(monitor, adapt, improve)
Tools:
Trello
Jira Agile
Kanbanflow
Kanbanize
Visual Wip
11. Набор принципов, на которых строится
процесс разработки, позволяющий в
жёстко фиксированные и небольшие по
времени итерации, называемые
спринтами, предоставлять конечному
пользователю работающее ПО с новыми
возможностями
• Возможности ПО к реализации в
очередном спринте определяются в
начале спринта на этапе
планирования и не могут изменяться
на всём его протяжении.
• строго фиксированная небольшая
длительность спринта придаёт
процессу разработки предсказуемость
и гибкость.
12.
13. Водопад – когда нужна
формализация, четкий набор задач,
«можно» менять время и цену
Agile – нет четкого набора задач,
постоянные изменения, но
выпускаем всегда в одно и тоже
время, одной и той же командой
15. Product Owner:
Представляет интересы конечных пользователей и
других заинтересованных в продукте сторон (может
быть не один человек)
Несет ответственность за значимость продукта для
пользователей
Собирает все требования в бэклог и расставляет
приоритеты
Поддерживает бэклог продукта
Участвует в демо и «подтверждает» готовность историй
Scrum Master:
Выделенный человек, ответственный за следвоании
командой процессу
Поддерживает бэклог итерации
Не менеджер, но организует все митинги, назначает
задачи
Отвечает за то, чтобы команде ничего не мешало
доставить работающий продукт продакшен качества в
срок
16. Группа мотивированных людей, которые работают друг с
другом для достижения общей цели (создания продукта), могут
участвовать в дискуссиях, должны быть готовы к изменениям
Могут брать задачи самостоятельно, им не нужен менеджер,
который назначит работу. Высокая степень ответственности за
свой выбор и результат
Управляем своими задачами как единая группа (назначить,
оценить, переоценить, переделать, доставить,..)
Команде нужен «тренер», но не нужен человек для контроля
(They still require mentoring and coaching, but they don't
require "command and control.«)
Вся команда понимает требования, никто не боится задавать
вопросы чтобы развеять сомнения
Команда постоянно развивается, улучшать свои навыки,
пробудет новые технологии, идеи, улучшения
Competency. Collaboration. Motivation. Trust and Respect.
Continuity. Do Agile Right: team structure
17.
18. Синие и красные бумажечки. Синие – должны,
красные – часто бывает
3 столбика: Product Owner, Scrum Master, Team
Раскладываем карточки за 10 минут
19. Под «сделано» каждый может подразумевать что-то
свое. И под «хорошо сделано», тоже
Нужны критерии, что продукт «готов»
1. Договор между заказчиком и командой
2. Чеклист нужных активностей
3. Могут быть на требование (есть критерии, есть
приоритет,..), задачу (код ревью, автотесты, ручные
тесты, все тесты прошли,..), итерацию (есть нужные
документы, все задачи прошли все стадии,
регрессионные тесты прошли,..)
4. Должен разрабатываться ВСЕЙ командой
http://vimeo.com/21529305
20.
21. - Story Card
- Acceptance
Criteria
- Communications!
Do Agile Right: Specifications
22.
23. INVEST theory:
Independent – Don’t mix user stories together, each
should be independent in and of itself.
Negotiable – User stories, up until they are part of an
iteration, can always be changed and rewritten.
Valuable – A user story must deliver value to the end
user
Estimable – User stories may have to be prioritized.
Small – Keep them short, user stories are not novels.
Testable – Make sure the user story actually offers
something you can analyze or test.
24. MoSCoW:
Must have
Should have
Could have
Would like
Developers will initially try to deliver all the M, S and C requirements but
the S and C requirements will be the first to go if the delivery timescale
looks threatened.
26. 15 минут
- Что делал вчера,
- Что собираюсь делать сегодня
- Есть ли вопросы?
15 минут
- Что делал вчера,
- Что собираюсь делать сегодня
- Есть ли вопросы?
30. Показываем заинтересованным лицам что сделали за
итерацию
Обычно сценарии берем из приемочных критериев
Тыкаем «вживую»
Отвечаем на вопросы
Цель: показать, что сделали и узнать,
то ли вообще сделали?
31. - Нужна для того, чтобы улучшать процесс, инструменты, результаты по ходу разработки
32.
33. За качество отвечает ВСЯ команда (вместе планируем,
вместе проводим ретро, вместе демонстрируем
заказчикам, вместе огребаем проблем)
Стараемся не находить ошибки, а предвосхищать их
появление (больше к девелоперам, но мы можем быть
рядом с ними в эти моменты: во время код ревью,
планирования)
Тестируем документацию и мокапы/прототипы!
Требования все время меняются, частые доставки ( на
кейсы обычно времени нет)
Приоритезируем еще лучше, чем в других процессах)
Больше исследований! Exploratory, Ad-hoc, Session
based
37. прежде чем писать - подумайте для кого пишем
Неофициальный: чеклист, майн-карта, записи на вики :)
стандартные разделы:
- Что тестируем? Описание системы, оборудования,..
- Какую часть тестируем? Scope тестируемых функций
- Что не тестируем
- Как тестируем? Стратегия, типы тестов, техники, уровни
- Кто тестирует? роли, команды, конкретные имена :)
- Когда тестируем? Расписание / estimation
- На чем тестируем? Описание тестового стенда, необходимых систем (нужны ли внешние
системы?), железо, инструменты (багткерер, хранение кейсов,..)
- Критерии конца: метрики (открытые/закрытые баги, покрытие кода, etc), время, etc.
- Риски
- Где искать другие документы "ленивый" тест план
38. Набор идей для тестирования
http://jira.jtalks.org/secure/StructureBoard.jspa?s=134
48. Бизнес район – места, где делаются дела
Исторический район – старые районы, достались нам от прошлый хозяев (legacy
code)
Туристический район – места, где бывают новые пользователи и не бывают
горожане
Федекс тур – тестируем, фокусируясь на тестовых данных
65. HAR (HTTP Archive)– стандарт для трейса http запросов. Цель – запись запросов
в браузере.
Как записать (Chrome):
- F12
- Rec, выполняем нужные действия
- Stop
- Right-click на запросах -> save as HAR
СпецификацияТестирование с HAR
Конвертация в jmx
66. плагин к firefox, chrome
http://chrispederick.com/work/web-developer/
Примеры:
Forms->Меняем Get на Post
Forms-> Convert Select elements to text input
Miscellaneous->Display hidden elements
Tools->Validators
16.3.15
67. Прокси
перехватываем, редактируем, посылаем запросы
эмулируем плохую сеть, ошибки в ответах,..
отправляем запросы одновременно Shift+R
аналог для браузера: tamper data
качаем тут http://www.telerik.com/download/fiddler
16.3.15
74. Scenario: When a user adds a product to the shopping cart, the product
should be included in the user's shopping cart.
Given a user
Given a shopping cart
Given a product
When the user adds the product to the shopping cart
Then the product must be included in the list of the shoppingcart's
entries
public class AddProductToShoppingCart extends JUnitStory {
private User user;
private ShoppingCart shoppingCart;
private Product product;
@Given("a user")
public void aUser() {
user = new User();
}
@Given("a shopping cart")
public void aShoppingCart() {
shoppingCart = new ShoppingCart();
}
@Given("a product")
public void aProduct() {
product = new Product();
product.setName("Coffee");
}
@When("the user adds the product to the shopping cart")
public void userAddsProductToShoppingCart() {
shoppingCart.add(user, product);
}
@Then("the product must be included in the list of the shoppingcart's entries")
public void productMustBeListed() {
List<Product> entries = shoppingCart.getProductsByUser(user);
Assert.assertTrue(entries.contains(product));
}
}
Evolution of Automation Test Engineer
JBehave
75.
76. Why
- Increase online conversions by 15% in the next
quarter
- Attract 20% more customers in the next financial
year
Who
- Students with a tablet device or smart phone in
the classroom
- Corporate employees with access to the secure
drive
How
- Get faster access to accurate information
- Have access to a wider network of colleagues to
collaborate with
What
- Online purchasing
- Registration form