В презентации:
• Что такое Концепция требований, для чего она нужна и что туда должно войти?
• Какие техники сбора и анализа требований можно использовать на старте проекта?
• Как можно формировать ТЗ к такому проекту и что туда должно войти?
• Какие моменты нужны учесть и какие инструменты можно использовать при управлении требований?
* Показаны и рассказаны реальные примеры докладчика.
5 правил успешной разработки приложений для бренда Heads&Hands
Презентация о правилах разработки мобильных приложений для крупных брендов. Основные ошибки и проблемы, с которыми сталкивается компания-разработчик и способы их решения.
Докладчик:
Александр Сапронов
Описание:
Язык Python отлично подходит для прототипирования: простой синтаксис, множество батареек, много готовых решений. Это отлично для бизнеса и для разработчика.
Но давайте снимем розовые очки и озвучим негатив, который вас ждет, когда вы возьмете Python для проекта.
Видео:
https://www.youtube.com/watch?v=YE9Q78QlZiE
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
Джоэл Спольски много лет назад придумал тест на качество и адекватность IT-компании, но ценности он не теряет и по сей день.
Сентябрь 2014, TechTalks NSU, Новосибирск
5 правил успешной разработки приложений для бренда Heads&Hands
Презентация о правилах разработки мобильных приложений для крупных брендов. Основные ошибки и проблемы, с которыми сталкивается компания-разработчик и способы их решения.
Докладчик:
Александр Сапронов
Описание:
Язык Python отлично подходит для прототипирования: простой синтаксис, множество батареек, много готовых решений. Это отлично для бизнеса и для разработчика.
Но давайте снимем розовые очки и озвучим негатив, который вас ждет, когда вы возьмете Python для проекта.
Видео:
https://www.youtube.com/watch?v=YE9Q78QlZiE
Алексей Трошин. Менеджер не нужен: быстрые шаблоны правильных коммуникацийScrumTrek
Алексей Трошин.
Первый коммерческий сайт создал в 2002 году, первый интернет-магазин вывел в плюс в 2005, участвовал в развитии крупнейших порталов Рунета - АВТО.РУ (www.auto.ru) и Банки.ру (www.banki.ru), развивал конструктор сайтов Сетап (www.setup.ru), создавал первый российский интернет-магазин, вышедший на IPO - Ютинет.ру (www.utinet.ru), поучаствовал в развитии SaaS-системы управления задачами Мегаплан (www.megaplan.ru). Успел нанести непоправимую пользу нескольким стартапам, запустить новые продукты в B2B-Center.ru. Сейчас в ФИНАМ. Выступал на AgileDays в 2012, 14, 15, 16, Agile с 2009-го года (CSM, CSPO), в работе и по жизни :)
Джоэл Спольски много лет назад придумал тест на качество и адекватность IT-компании, но ценности он не теряет и по сей день.
Сентябрь 2014, TechTalks NSU, Новосибирск
Почему оно не находится! / Андрей Аксенов (Sphinx)Ontico
HighLoad++ 2017
Зал «Конгресс-Холл», 7 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/3000.html
...и что сделать, чтобы уже находилось?
И снова про качество поиска. Поменьше скучной теории (ну, чтобы не более 60%); больше практических примеров. Как оценить типа-качество "на пальцах"; почему это плохая идея. Как построить оценивалку; насколько это просто; где взять готовую (нигде); зачем человечеству Толока или Mechanical Turk.
...
Картинки к моему рассказу о том, что такое фреймворки и с чем их едят, что лучше не есть и как выбрать приправы для приготовления. Тезисы тут: http://backendconf.ru/2016/abstracts/2123.html
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Картинки к моему рассказу о том, как мы делаем Банки.ру. Некоторые слайды очень неоднозначны без текста. Тезисы тут: http://nastachku.ru/lectures?lecture_id=630#lecture_630
Видео тут https://www.youtube.com/watch?v=m5QuiTZwMrU
Как потратить 4 года и мешок денег на рефакторинг и ничего не запустить / М.Ч...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 17:00
Тезисы:
http://backendconf.ru/2017/abstracts/2636.html
Итак, вам повезло - у вас большой проект с многолетней историей. Проблема в том, что многолетняя история - это чаще всего значит много legacy кода, на который стыдно смотреть и тяжело делать всё остальное. И вот в один прекрасный момент все понимают, что так жить больше нельзя и нужно (всё) менять. Здесь самое опасное - начать всё переписывать заново. Почему это плохо и к чему это привело у нас, в Ultimate Guitar, и будет посвящён этот доклад.
...
Картинки к моему рассказу о том, что не всегда круто спешить и бежать впереди паровоза при оптимизации и внедрении новых модных решений. Тезисы тут: http://junior.highload.ru/2016/abstracts/2221.html
- почему PHP программисты снискали дурную славу;
- что делать, чтобы стать хорошим программистом;
- как писать идеальный код;
- что такое командная разработка проекта;
- учет позиции бизнеса при разработке проекта;
- основные задачи, который должен решать программист;
Поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.
Рассмотрим следующие темы и поищем ответы на вопросы:
1) Что такое фреймворк, и зачем их пишут.
2) Почему для некоторых языков их десятки, а для некоторых — единицы.
3) В чём плюсы и минусы применения.
4) Наиболее распространённые мифы.
5) Использовать или нет — примеры из жизни.
6) Как выбрать из множества доступных вариантов, на что стоит обратить внимание.
Михаил Ермоленко (Noveo) рассказывает о том, как проходить собеседования и устраиваться на первую в вашей жизни работу, 13.05.2013
Видеозапись: http://www.youtube.com/watch?v=F2YptTuVM6A
Software Industry 101 — это серия обзорных лекций для студентов Новосибирского государственного университета о профессиях в IT и о реалиях коммерческой разработки софта.
Более подробную информацию, материалы лекций и раписание занятий можно посмотреть на http://bit.ly/industry101
Сложный проект с нуля: сквозь воду, огонь и медные трубы / Филипп ДельгядоOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 16:00
Тезисы:
http://backendconf.ru/2017/abstracts/2703.html
Последние два года я делаю платежную систему с нуля.
Подобные проекты при создании проходят через несколько различных стадий (создание каркаса, запуск и доработка напильником, развитие и сопровождение), каждая из которых требует специальных инструментов, отдельных подходов к организации разработки, своих особенностей в декомпозиции задач и даже разных навыков от разработчиков.
...
Основные ошибки внедрения ATDD, BDD, CI, CD на проектах, Резчиков Алексей
Каждый новый проект, к которому Алексей подключается в качестве консультанта, уже имеет свою историю внедрения автоматизации тестирования, CI и CD. Истории очень разные, каждая интересна по-своему, каждая рассказывает об ошибках. О самых распространенных из них, а также о том, как их не допустить, Алексей расскажет в своем докладе.
Есть мнение, что совещание - это лучшее место отдохнуть от работы, показать себя, порисовать у доски, перекусить и произвести впечатление на коллег. На самом деле, совещание - это тяжелая работа всех его участников. И чтобы эта работа привела к успешному результату, необходимо знать и применять несложные приемы проведения совещаний.
В докладе будет раскрыта психология проведения совещаний, техники, позволяющие собрать максимальное число мнений и приемы для принятия решения, которое бы удовлетворяло всех его участников.
Requirements Engineering: People Processes ToolsAlexander Baikin
Треугольник работы с требованиями: люди, процессы, инструменты
Многие начинающие аналитики и менеджеры делают огромную ошибку, возлагая большие надежды на инструменты управления требованиями и проектом. На самом деле нужно сначачала найти (сделать) хороших людей, потом наладить процессы, а далее уже искать способы автоматизации рутинных операций (инструменты).
В докладе:
почему аналитики любят инструменты,
рекомендации по тому, что должен знать и уметь хороший аналитик,
как наладить процесс разработки и управления требованиями
какие необходимы инструменты управления требованиями и для каких проектов
Описание бизнес-правил и дополнительных требований в вариантах использования (use cases)
Все прекрасно знают, что варианты использования (ВИ) отлично описывают функциональные требования, но что делать с не функциональными требованиями? Кто-то пишет их отдельно, кто-то включает в текст спецификации ВИ, кто-то про них вообще забывает. В докладе будет рассказано про основные подходы описания бизнес-правил в ВИ:
* Отделенные бизнес-правила
* Размазанные бизнес-правила
* Привязанные бизнес-правила
* Группированные бизнес-правила
* Решения вместо бизнес-правил
* Как делаю я?
Из данной презентации Вы узнаете:
Кто такой Аналитик?
Чем он занимается?
Что он должен знать и уметь?
Почему требования так важны?
Что Вас ждет дальше?
Презентация предназначена для знакомства с ролью Аналитика (или ИТ специалиста, работающего с требованиями) и презентации полного курса «Разработка и управление требований к ПО".
Запись вебинара: http://vimeo.com/61915197
Аналитики не нужны требования (поставь запятую, где нужно)Alexander Baikin
Я часто слышу: «А зачем нам Аналитики? Хорошие разработчики — вот это сила!» или «Зачем нам требования? Мы и так по Agile шарашим!».
Тогда почему многие жалуются:
«Мы одно и тоже по нескольку раз переделываем!»,
«Заказчик все время орет, что мы делаем не то, что ему нужно!»,
«Мы как будто разговариваем с Заказчиком на разных языках!»,
«Да блин, этот Заказчик сам не знает, что хочет!»,
«У нас постоянно расширяется скоуп проекта!»,
«Мы развиваем большой проект, но уже никто не знает, как он работает! В одном месте правим, в другом ломается!»,
«Но мы же договаривались о другом!!!»
и т. д.
Чтобы решить эти и другие проблемы на проекте как раз нужны Аналитики, которые пишут правильные требования.
Я вас не убедил, что вам нужны правильные Аналитики и хорошие требования?! Тогда послушайте вебинар:
Задача Джоэля Спольски
Зачем нужны аналитики?
Кто такой хороший аналитик?
Как бороться с извечными проблемами?
Как быть с Agile?
Большие компании и корпорации имеют сложную Орг структуру, множество Бизнес-процессов (БП), Систем, Данных. Все это очень тесно переплетно и сильно влияет друг на друга. Изменили структуру отдела или заменили людей, забыли про БП - получили проблему. Изменили Систему, забыли про другую Систему - получили проблему. Поменяли БП, забыли про людей и Системы - получили проблему. И т.д....
Чтобы все это увязать и управлять придумано много фреймворков - Zachman, TOGAF, FEA и т.д. И везде требования ставятся во главу угла. Но нужны ли все практики и такие сложные фреймвоки? В каких российских компаниях они внедрены? Мне кажется, что можно взять из этих фреймворков все самое лучше и необходимо и построить свой подход по управлению корпоративной архитектурой.
Я хочу рассказать про опыт использования продуктов Atlassian (JIRA и Confluence) в контексте нашего процесса управления требованиями.
Кому будет интересно: пользователи Atlassian, участникам небольших команд и проектов.
Кому может быть не интересно: фанатам Rational, исполнителям на госзаказах (тема с ТЗ раскрыта не будет), большим командам.
Будут рассмотрены следующие этапы процесса:
* Специфицирование требований
* Согласование требований
* Разработка и тестирование
* Контроль изменений
Для каждого этапа я расскажу про возможности и недостатки этих продуктов с точки зрения пользователя с шестилетним стажем эксплуатации продуктов Atlassian.
Почему оно не находится! / Андрей Аксенов (Sphinx)Ontico
HighLoad++ 2017
Зал «Конгресс-Холл», 7 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/3000.html
...и что сделать, чтобы уже находилось?
И снова про качество поиска. Поменьше скучной теории (ну, чтобы не более 60%); больше практических примеров. Как оценить типа-качество "на пальцах"; почему это плохая идея. Как построить оценивалку; насколько это просто; где взять готовую (нигде); зачем человечеству Толока или Mechanical Turk.
...
Картинки к моему рассказу о том, что такое фреймворки и с чем их едят, что лучше не есть и как выбрать приправы для приготовления. Тезисы тут: http://backendconf.ru/2016/abstracts/2123.html
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Картинки к моему рассказу о том, как мы делаем Банки.ру. Некоторые слайды очень неоднозначны без текста. Тезисы тут: http://nastachku.ru/lectures?lecture_id=630#lecture_630
Видео тут https://www.youtube.com/watch?v=m5QuiTZwMrU
Как потратить 4 года и мешок денег на рефакторинг и ничего не запустить / М.Ч...Ontico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 17:00
Тезисы:
http://backendconf.ru/2017/abstracts/2636.html
Итак, вам повезло - у вас большой проект с многолетней историей. Проблема в том, что многолетняя история - это чаще всего значит много legacy кода, на который стыдно смотреть и тяжело делать всё остальное. И вот в один прекрасный момент все понимают, что так жить больше нельзя и нужно (всё) менять. Здесь самое опасное - начать всё переписывать заново. Почему это плохо и к чему это привело у нас, в Ultimate Guitar, и будет посвящён этот доклад.
...
Картинки к моему рассказу о том, что не всегда круто спешить и бежать впереди паровоза при оптимизации и внедрении новых модных решений. Тезисы тут: http://junior.highload.ru/2016/abstracts/2221.html
- почему PHP программисты снискали дурную славу;
- что делать, чтобы стать хорошим программистом;
- как писать идеальный код;
- что такое командная разработка проекта;
- учет позиции бизнеса при разработке проекта;
- основные задачи, который должен решать программист;
Поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.
Рассмотрим следующие темы и поищем ответы на вопросы:
1) Что такое фреймворк, и зачем их пишут.
2) Почему для некоторых языков их десятки, а для некоторых — единицы.
3) В чём плюсы и минусы применения.
4) Наиболее распространённые мифы.
5) Использовать или нет — примеры из жизни.
6) Как выбрать из множества доступных вариантов, на что стоит обратить внимание.
Михаил Ермоленко (Noveo) рассказывает о том, как проходить собеседования и устраиваться на первую в вашей жизни работу, 13.05.2013
Видеозапись: http://www.youtube.com/watch?v=F2YptTuVM6A
Software Industry 101 — это серия обзорных лекций для студентов Новосибирского государственного университета о профессиях в IT и о реалиях коммерческой разработки софта.
Более подробную информацию, материалы лекций и раписание занятий можно посмотреть на http://bit.ly/industry101
Сложный проект с нуля: сквозь воду, огонь и медные трубы / Филипп ДельгядоOntico
РИТ++ 2017, Backend Conf
Зал Кейптаун, 5 июня, 16:00
Тезисы:
http://backendconf.ru/2017/abstracts/2703.html
Последние два года я делаю платежную систему с нуля.
Подобные проекты при создании проходят через несколько различных стадий (создание каркаса, запуск и доработка напильником, развитие и сопровождение), каждая из которых требует специальных инструментов, отдельных подходов к организации разработки, своих особенностей в декомпозиции задач и даже разных навыков от разработчиков.
...
Основные ошибки внедрения ATDD, BDD, CI, CD на проектах, Резчиков Алексей
Каждый новый проект, к которому Алексей подключается в качестве консультанта, уже имеет свою историю внедрения автоматизации тестирования, CI и CD. Истории очень разные, каждая интересна по-своему, каждая рассказывает об ошибках. О самых распространенных из них, а также о том, как их не допустить, Алексей расскажет в своем докладе.
Есть мнение, что совещание - это лучшее место отдохнуть от работы, показать себя, порисовать у доски, перекусить и произвести впечатление на коллег. На самом деле, совещание - это тяжелая работа всех его участников. И чтобы эта работа привела к успешному результату, необходимо знать и применять несложные приемы проведения совещаний.
В докладе будет раскрыта психология проведения совещаний, техники, позволяющие собрать максимальное число мнений и приемы для принятия решения, которое бы удовлетворяло всех его участников.
Requirements Engineering: People Processes ToolsAlexander Baikin
Треугольник работы с требованиями: люди, процессы, инструменты
Многие начинающие аналитики и менеджеры делают огромную ошибку, возлагая большие надежды на инструменты управления требованиями и проектом. На самом деле нужно сначачала найти (сделать) хороших людей, потом наладить процессы, а далее уже искать способы автоматизации рутинных операций (инструменты).
В докладе:
почему аналитики любят инструменты,
рекомендации по тому, что должен знать и уметь хороший аналитик,
как наладить процесс разработки и управления требованиями
какие необходимы инструменты управления требованиями и для каких проектов
Описание бизнес-правил и дополнительных требований в вариантах использования (use cases)
Все прекрасно знают, что варианты использования (ВИ) отлично описывают функциональные требования, но что делать с не функциональными требованиями? Кто-то пишет их отдельно, кто-то включает в текст спецификации ВИ, кто-то про них вообще забывает. В докладе будет рассказано про основные подходы описания бизнес-правил в ВИ:
* Отделенные бизнес-правила
* Размазанные бизнес-правила
* Привязанные бизнес-правила
* Группированные бизнес-правила
* Решения вместо бизнес-правил
* Как делаю я?
Из данной презентации Вы узнаете:
Кто такой Аналитик?
Чем он занимается?
Что он должен знать и уметь?
Почему требования так важны?
Что Вас ждет дальше?
Презентация предназначена для знакомства с ролью Аналитика (или ИТ специалиста, работающего с требованиями) и презентации полного курса «Разработка и управление требований к ПО".
Запись вебинара: http://vimeo.com/61915197
Аналитики не нужны требования (поставь запятую, где нужно)Alexander Baikin
Я часто слышу: «А зачем нам Аналитики? Хорошие разработчики — вот это сила!» или «Зачем нам требования? Мы и так по Agile шарашим!».
Тогда почему многие жалуются:
«Мы одно и тоже по нескольку раз переделываем!»,
«Заказчик все время орет, что мы делаем не то, что ему нужно!»,
«Мы как будто разговариваем с Заказчиком на разных языках!»,
«Да блин, этот Заказчик сам не знает, что хочет!»,
«У нас постоянно расширяется скоуп проекта!»,
«Мы развиваем большой проект, но уже никто не знает, как он работает! В одном месте правим, в другом ломается!»,
«Но мы же договаривались о другом!!!»
и т. д.
Чтобы решить эти и другие проблемы на проекте как раз нужны Аналитики, которые пишут правильные требования.
Я вас не убедил, что вам нужны правильные Аналитики и хорошие требования?! Тогда послушайте вебинар:
Задача Джоэля Спольски
Зачем нужны аналитики?
Кто такой хороший аналитик?
Как бороться с извечными проблемами?
Как быть с Agile?
Большие компании и корпорации имеют сложную Орг структуру, множество Бизнес-процессов (БП), Систем, Данных. Все это очень тесно переплетно и сильно влияет друг на друга. Изменили структуру отдела или заменили людей, забыли про БП - получили проблему. Изменили Систему, забыли про другую Систему - получили проблему. Поменяли БП, забыли про людей и Системы - получили проблему. И т.д....
Чтобы все это увязать и управлять придумано много фреймворков - Zachman, TOGAF, FEA и т.д. И везде требования ставятся во главу угла. Но нужны ли все практики и такие сложные фреймвоки? В каких российских компаниях они внедрены? Мне кажется, что можно взять из этих фреймворков все самое лучше и необходимо и построить свой подход по управлению корпоративной архитектурой.
Я хочу рассказать про опыт использования продуктов Atlassian (JIRA и Confluence) в контексте нашего процесса управления требованиями.
Кому будет интересно: пользователи Atlassian, участникам небольших команд и проектов.
Кому может быть не интересно: фанатам Rational, исполнителям на госзаказах (тема с ТЗ раскрыта не будет), большим командам.
Будут рассмотрены следующие этапы процесса:
* Специфицирование требований
* Согласование требований
* Разработка и тестирование
* Контроль изменений
Для каждого этапа я расскажу про возможности и недостатки этих продуктов с точки зрения пользователя с шестилетним стажем эксплуатации продуктов Atlassian.
Atlassian jira как полностью раскрыть возможностиAndrew Fadeev
Atlassian jira как полностью раскрыть возможности. Jira в базовой поставке не реализует огромное количество заложенных в нее возможностей. Возникает вопрос, прав ли был Гартнер так высоко ставя её в своих "магических квадратах". Гартнер как всегда прав, но для раскрытия потенциала Jira необходимо значительное кол-во внешних плагинов. Удобно это или нет - решать Вам.
Requirement Managament System based on Wiki (Confluence+Jira)Alexander Baikin
Что такое Система Управление Требованиями (СУТ)?
Какие есть еще СУТ кроме Telelogic Doors, Rational RequisitePro и Borland Together?
Как Wiki + Issue Tracker + SVN использовать для СУТ?
QA Fest 2016. Алексей Виноградов. Цель тестирования. А на самом деле?QAFest
Дорогие начинающие коллеги-тестировщики! Уважаемые коллеги со „средним“ стажем! В данном докладе я постараюсь поменять ваше традиционно неполное, и местами неверное представление о том, зачем и для чего мы занимаемся тестированием, и может быть даже достучаться до сердец некоторых сеньоров нашего ремесла.
Курсы, ISTQB, Википедия, скороспелые статьи на коммерческих и бесплатных сайтах, и знаменитые „исторические причины“ - внесли неоценимый вклад в дело хаоса понятий и поверхностности „лучших практик“ в области тестирования.
В докладе я донесу свой взгляд на современное тестирование, который поддерживают некоторые из очень ведущих специалистов. Понимание целей поможет вам стать лучшими тестировщикам и не только. Давайте сдвигать парадигму вместе уже сегодня! Так победим.
Виды QA: Всё что вы не знали и боялись спроститьGoIT
19.02.2015 состоялось очередное событие, посвященное тематике Тестирования ПО.
Встреча помогла участникам
• разобраться в видах QA;
• получить информацию о «подводных» камнях каждого из направлений;
• узнать о специфике работы тестеровщика;
• перенять опыт тестировщиков с многолетним стажем;
• узнать о нововведениях в мире QA;
• выбрать свой путь развития в тестировании.
Спикерами выступили:
Александр Майданюк – QA Lead, Manager, QA Consultant и Trainer. Занимает позицию Head
of Quality Assurance Solution в Ciklum. Эксперт и судья QA секции чемпионатов UA Web
Challenge. Соучредитель Киевского Клуба тестировщика QA Club.
Николай Ковш – QA Engineer в Ciklum. Является ярким примером свитчера - человека,
который сменил область деятельности. Со-организатор ивентов в QA Club - самом большом
киевском сообществе тестировщиков. Николай расскажет, почему тестировщику важно
научиться программировать.
Марина Шевченко – Mobile QA Engineer в Ciklum. QA з досвідом тестування веб, дестопних
та мобільних додатків. Співорганізатор заходів в QA Club – найбільшій київській спільності
тестувальників.
Хорошо поддерживаемое в продакшне приложение / Николай Сивко (okmeter.io)Ontico
Исторически сложилось так, что одни люди разрабатывают приложения (Dev), а другие эксплуатируют их в продакшне (Ops). И у последних есть немало проблем с тем, что невозможно понять, что происходит.
Причем это касается как собственных разработок, так и популярных open source решений.
Я расскажу, как устроена диагностика у некоторых популярных софтин:
- nginx
- postgresql
- mongodb
Мы попробуем разобраться, что там сделано хорошо, и чего не хватает для полного счастья.
Во второй части доклада мы поговорим про то, как нужно инструментировать собственное приложение для прозрачной работы в продакшне:
- что считать и зачем: ошибки, тайминги, разные состояния приложения,
- инструментарий: your_lang-metrics, your_lang-statsd-client, логи,
- как не перемудрить и не убить прод диагностикой.
Может показаться, что этот доклад про DevOps, но нет - про docker не будет ни слова :)
В этом докладе рассмотрен опыт NetCracker по выбору инструмента для изучения причин проблем производительности.
Рассмотрены критерии по которым не подошли имеющиеся инструменты и показаны примеры того, чего не хватает при анализе результатов обычными профайлерами.
http://jeeconf.com/program/implement-your-own-profiler-with-blackjack-and-fun/
BDD. The Outer Limits. Iosif Itkin at Youcon (in Russian)Iosif Itkin
Exactpro is supporting the 3rd annual IT-conference YouCon to take place on 14th October in Saratov, Russia. Over 900 programmers, systems engineers and architects, software QA engineers, and marketing specialists will gather to discuss the latest trends in programming technology. It is the largest IT industry event in Saratov.
Iosif Itkin, CEO of Exactpro, part of London Stock Exchange Group, will deliver a "BDD. The Outer Limits" presentation named after Iosif's favorite Sci-Fi series.
The topics to be covered are:
Behavior Driven Development concepts
Applying BDD in trading and clearing systems
Specification by Example and using production data
Combining Model-based testing and BDD
The Outer Limits
There will be an opportunity to ask questions, share thoughts and expertise in BDD, or just chat with a representative at the Exactpro stand at any time during the event.
Don't miss out, stop by and ask how you can get your Exactpro souvenir :)
We look forward to meeting you there!
#Exactpro #Youconsaratov
В современном мире все меняется очень быстро. Слишком быстро. И требования заказчика в том числе. Гибкие методологии разработки позволяют адаптироваться к быстро меняющимся требованиям. Но как сохранить стабильность приложения в данных условиях, как оставить заказчика удовлетворенным и при этом сберечь психическое здоровье разработчиков? Этот доклад о том, как быстро двигаться вперед без опаски оступиться.
Презентация подготовлена по материалам выступления Евгения Гавриленко на витебской конференции “Developer's Software Conference” (12.11.2016).
Опыт разработки SEO софта на примере FastTrust и ComparseRАлександр Алаев
Рассказываю про свой непростой опыт разработки десктопных программ на примере FastTurst и ComparseR. Всем, кто собирается заняться разработкой инди приложения или сервиса рекомендую.
Similar to Работа с требованиями в Интернет стартапе (20)
* Классификация нефункциональных требований
* Шаблоны нефункциональных требований
* Численные значения нефункциональных требований
* Связи между нефункциональными и функциональными требованиями
* Влияние различных категорий нефункциональных требований друг на друга
* Атрибуты качества продукта и нефункциональные требования
* Роли в проекте, с которыми взаимодействует аналитик при выявлении и уточнении нефункциональных требований
Варианты Использования (use cases) - это наиболее популярный метод описания пользовательских требований в последние нескольких лет. Но только единицы владеют этим <<искусством>>. Да-да, не побоюсь этого слова, т.к. при правильном применении варианты использования дают неоспоримые преимущества: интуитивно понятны заказчикам и разработчикам; помогают выявить функциональные требования; диаграмма
помогает представить требования в целом; Аналитик фокусируется на потребностях Пользователя, а не на Системе и т.д.
На мастер классе будут даны основные понятия вариантов использования, их шаблоны и конечно будет разобран пример моделирования и описания вариантов использования для одной из популярных веб систем.
Для проведения полноценного тренинга обращайтесь ко мне.
Типичные проблемы Выявления Требований и их РешениеAlexander Baikin
На протяжении многих лет написано огромное количество книг и статей по методам Выявления Требований и их применению, но все хорошо в теории. На практике же Аналитики, раз за разом, натыкаются на одни и те же грабли: не выявлены все требования; заказчик не знает, что хочет; «да, но …» синдром и т.д. В данном докладе описаны основные проблемы, с которыми сталкиваются Аналитики на этапе Выявления Требований и предложены пути их решения.
В докладе предложены последовательность и практические действия по созданию и описанию процесса управления требованиями для работы конкретной команды, а так же описаны действия по планированию и адаптации процесса управления требованиями для использования в условиях конкретного проекта.
Место Аналитика в разработке
Почему так получается?
Требования
Работа с требованиями
Кто такой Аналитик?
Системный Ан. vs Бизнес Ан.
Основные функции Бизнес Ан.
Литература и Профстандарты
Управление требованиями в новой экономической ситуацииAlexander Baikin
Что делать когда издержки снижают, а развиваться надо?! В данной презентации рассказывается о том как можно повысить эффективность на этапе Анализа ПО и других фазах разработки ПО.
2. Кто я?
• Разработчик и сисадмин
• Аналитик
• Менеджер проектов
• CIO
• Идеолог uml2.ru
• Тренер, консультант
• Докладчик на многих конференциях
bas@uml2.ru
http://baikin.moikrug.ru
Байкин Александр
3. Различия
• Разработчики
• Процесс не поставлен
• Время критично
• Частые изменения
• Нет аналогов
• Разные специалисты
• Процесс налажен
• Время ставим сами
• Фикс. рамки
• Проект не первый
Плановая разработка Разработка в Старапе
4. Проект №1
• Факт
– Заказчик пришел с «готовым» ТЗ
– После 3 месяцев тр. кардинально изменились
– После 6 месяцев проект закрыли
• Проблемы
– Непонятны ЗЛ
– Непонятны цели
– Непонятны преимущества продукта
5. Рецепт №1
• Создайте перед стартом концепцию
– Для кого?
– Зачем?
– Что?
– Чем лучше?
8. Анализ проблем
• 5 Why’s
– Зачем, для чего, каким образом…?
• 5 Ws
– Who, what, when, where, why?
• Д Ишикавы
9. Проект №2
• Факт
– Требования рождались спонтанно
– Требования не хранились
– Через 1 год нельзя дальше развивать проект
• Проблемы
– Изменения происходят долго и бесконтрольно
– Изменяют в одном месте, рушится в другом
– Сложно вводить нового разработчика
10. Рецепт №2
• Документирование и хранение требований
– Wiki или Система версионного контроля
– Ссылки
– Согласование/Презентации
– Требования за итерацию до разработки
11. Рецепт №3
• Система управления задачами
– Выдача и контроль задач
– Приоритезация задач и требований
– Контроль изменений
– Связь задач и требований
• Требование -> Задача -> Код
12. Проект №3
• Факт
– Долгий процесс разработки требований
– Готовое решение показало много проколов
– Изменения не фиксировались
• Проблемы
– Опоздание запуска на 3 месяца
– Непонятно, что в итоге реализовано
– Реализовались фичи хаотично
13. Рецепт №4
• Итерационная разработка
• Как можно раньше в тест
• Привлекать бета тестеров
• Приоритезация требований
• Хранение изменений требований
14. Проект №…
• Нет времени на требования
• Нет выделенного аналитика
15. Рецепт №5
• Планируйте время на требования
• Требованиями могут заниматься все
• Доступность требований для всех
• Больше диаграмм
• Договаривайтесь о рамках требованиях
• Не забывайте про нефункциональные тр.
16. Сохранность границ
• Решение корневых проблем, а не хотелок
• Правильно определяйте цели разработки
• Baseline требований и приоритет
• Управление изменениями требований
• Больше объем – на много больше изменений
• Изменения будут – это естественно
• Научитесь говорить НЕТ
17. Нефункциональность
• Не забывайте про НФТ
– Требования к производительности
– Требования к браузерам
– Требования к железу и доп софту
– Требования к интрефейсу
– И т.д.
23. Д Данныхclass Пользователи
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Version EA 9.0 Unregistered Trial Versio
Пользователь
- логин :string
- пароль :string
- мыло :string
Заемщик
Кредитор
Статус пользователя
- Название :string
- Описание :string
Группа
- Название :string
- Описание :string
Аккредит пользователь
- Дата рождения :date
- ИНН :string
- Номер СНИЛС :string
- Моб телефон :string
- Дом телефон :string
- Раб телефон :string
- Адрес регистрации :struct
- Адрес проживания :struct
«паспорт»
- Серия П :string
- Номер П :string
- Дата выдачи П :date
- Кем выдан П :date
- Скан П :blob
«загран паспорт»
- Нет загран паспорта :byte
- Номер ЗП :string
- Дата выдачи ЗП :date
- Кем выдан ЗП :date
- Скан ЗП :blob
«вод удостоверение»
- Нет вод удостоверения :byte
- Серия ВУ :string
- Номер ВУ :string
- Дата выдачи ВУ :date
- Кем выдан ВУ :date
Оператор
Админ
Редактор
Сообщение
- Тема :string
- Сообщение :string
- Файлы :blob
Профиль
Пользователя
- Фамилия :string
- Имя :int
- Отчество :string
- пол :int
- Фото :blob
- О себе :string
Рейтинг
- Название :string
- Описание :string
Владелец
Город
Область
Регион
Транзакции::Счет
- Наименование :string
- ФИО в счете :string
Еще есть куча
атрибутов
0..*
кому
1
0..*
1
0..* 1
0..*
от кого
1
проживания
0..*1
рождения
0..*
владелец
0..1
26. Итого
• Понимайте корневые проблемы
• Договоритесь о целях
• Работайте с требованиях
• Применяйте методы анализа
• Организуйте процесс изменений требований
• Смотрите немного наперед