Гибкая разработка пользовательской документацииSergey Rogachev
Презентация доклада "Гибкая разработка пользовательской документации" Сергея Рогачева на конференции ALM Summit Russia в Москве 6 февраля 2014 года (http://bit.ly/MrkHSD). См. подробнее в заметке "Отчет об участии в ALM Summit Russia 2014" (http://wp.me/p1650o-eY) в персональном блоге Рогачева Сергея.
Александр Баумгертнер — Преимущества БЭМ для небольших проектов и компанийYandex
БЭМ хорош не только для крупных проектов и больших команд. БЭМ — не про именование CSS-классов и i-bem. Он вполне подходит для прототипирования. В докладе пойдет речь о библиотеке для создания основных блоков (форма регистрации, список новостей и статей, категория товаров, карточка товара, форма заказа и т.д.), сборке статичной html-версии сайта и практике разработки.
Презентация Полины Быновой, ведущего web-аналитика JetStyle с бизнес-завтрака "Интернет-магазин. Сколько стоит счастливый клиент: как посчитать и применить результат в бизнесе".
Гибкая разработка пользовательской документацииSergey Rogachev
Презентация доклада "Гибкая разработка пользовательской документации" Сергея Рогачева на конференции ALM Summit Russia в Москве 6 февраля 2014 года (http://bit.ly/MrkHSD). См. подробнее в заметке "Отчет об участии в ALM Summit Russia 2014" (http://wp.me/p1650o-eY) в персональном блоге Рогачева Сергея.
Александр Баумгертнер — Преимущества БЭМ для небольших проектов и компанийYandex
БЭМ хорош не только для крупных проектов и больших команд. БЭМ — не про именование CSS-классов и i-bem. Он вполне подходит для прототипирования. В докладе пойдет речь о библиотеке для создания основных блоков (форма регистрации, список новостей и статей, категория товаров, карточка товара, форма заказа и т.д.), сборке статичной html-версии сайта и практике разработки.
Презентация Полины Быновой, ведущего web-аналитика JetStyle с бизнес-завтрака "Интернет-магазин. Сколько стоит счастливый клиент: как посчитать и применить результат в бизнесе".
Особенности MVP в Enterprise / Владимир Васильев (Почта России)Ontico
- Зачем в Enterprise нужен MVP;
- что значит "минимально жизнеспособный" продукт для большой организации;
- как оргструктура влияет на продукт;
- какие ограничения может накладывать Enterprise на MVP;
- какие практики MVP наиболее полезны в Enterprise.
Управление - это игра. Алексей Кулаков, JetStyleJetStyle
Как посмотреть на процесс формирования и управления командой с точки зрения игры?
Кто такие и зачем нужны тролли, эльфы, гномы, маги, войны и жрецы? Кто нужен именно сейчас? Как ими руководить и как правильно балансировать команду?
MVP (минимальный жизнеспособный продукт): как не потерять деньги на разработк...dkalaev
Презентация с конференции dump-conf.ru
С первыми версиями всегда есть проблема.
Сделаешь мало функций - пользователи выкинут и второго шанса не дадут.
Или наборот запрограммировав 40 функций оказывается что только 19 из них используются, а остальные нет. Более половины бюджета разработки оказывается выкинуто.
Расширяемая платформа для создания и управления автоматизированными тестами н...jazzteam
Продукт XML2Selenium - это расширяемая, плагинная платформа для создания и управления автоматизированными тестами на основе технологии Java.
XML2Selenium имеет интеграцию с JUnit, работает поверх Selenium (это изменяемо). XML2Selenim позволяет создавать автоматизированные тесты в простом и понятном обычному (без навыков программирования) QA инженеру формате. XML2Selenium позволяет также управлять всеми стадиями работы с автоматизированными тестами, начиная от стадии создания и заканчивая управлением тестами.
Главными конкурентными преимуществами являются
- низкая стоимость вхождения. Начинающие автоматизаторы, и даже QA инженеры без навыков программирования создают качественные тесты, а значит легко поддерживаемые, легко изменяемые, с использованием DDT (Data Driven Testing) подходов, что увеличивает повторно-используемость тестов
- встроенные возможности структуризации тестов по папкам и файлам, а также по тегам, что позволяет качественно отобразить документацию на тесты. Внедряя эту платформу, вы автоматически улучшаете свои процессы управления тестами
- XML2Selenium - это плагинная, расширяемая платформа, позволяющая кастомизировать процессы под ваши нужды, создать новые плагины, добавить интеграцию с нужными системами, и многое другое
- все повторно-используемые части (инклюды, плагины) могут помещаться в репозитории, откуда ими могут пользоваться QA инженеры с других проектов компании, тем самым распространяется опыт и знания в области автоматизации
- XML2Selenium имеет широкий спектр полезных свойств в области автоматизации, таких как поддержка создания видео, снепшотов и скриншотов страниц, Groovy и JS скриптинга, поддержки объектно-ориентированного программирования на XML и многих других
Традиционно многие компании не инвестируют много в QA инженеров, при этом сложность продуктов и количество Use Cases растёт, и компании утыкаются в барьер, когда архитектура тестов становится сравнительно такого же уровня, как и архитектура приложения. Это же касается и автоматизации тестирования. Ключевыми проблемами становятся:
- вопросы поддержки и тестирования многих инсталяций продукта на стороне заказчика
- вопросы тестирования нескольких версий (бренчей) одного и того же продукта
- повторн
Nival: Как не увлечься погоней за универсализацией компонентDevGAMM Conference
Если оставить программиста одного — он будет делать суперуниверсальное нечто. Какие компоненты было бы действительно полезно сделать универсальными и как понять когда универсализация это пустая трата времени.
Проблемы и пути их решения при командной разработке проектовАгентство AlterEGO
– Кому нужна командная разработка?
– Что делать в команде?
– Решение реальных задач, распределение ответственности
– Командная разработка на 1С-Битрикс
– Миграции БД
– Проблемы и пути их решения
Особенности MVP в Enterprise / Владимир Васильев (Почта России)Ontico
- Зачем в Enterprise нужен MVP;
- что значит "минимально жизнеспособный" продукт для большой организации;
- как оргструктура влияет на продукт;
- какие ограничения может накладывать Enterprise на MVP;
- какие практики MVP наиболее полезны в Enterprise.
Управление - это игра. Алексей Кулаков, JetStyleJetStyle
Как посмотреть на процесс формирования и управления командой с точки зрения игры?
Кто такие и зачем нужны тролли, эльфы, гномы, маги, войны и жрецы? Кто нужен именно сейчас? Как ими руководить и как правильно балансировать команду?
MVP (минимальный жизнеспособный продукт): как не потерять деньги на разработк...dkalaev
Презентация с конференции dump-conf.ru
С первыми версиями всегда есть проблема.
Сделаешь мало функций - пользователи выкинут и второго шанса не дадут.
Или наборот запрограммировав 40 функций оказывается что только 19 из них используются, а остальные нет. Более половины бюджета разработки оказывается выкинуто.
Расширяемая платформа для создания и управления автоматизированными тестами н...jazzteam
Продукт XML2Selenium - это расширяемая, плагинная платформа для создания и управления автоматизированными тестами на основе технологии Java.
XML2Selenium имеет интеграцию с JUnit, работает поверх Selenium (это изменяемо). XML2Selenim позволяет создавать автоматизированные тесты в простом и понятном обычному (без навыков программирования) QA инженеру формате. XML2Selenium позволяет также управлять всеми стадиями работы с автоматизированными тестами, начиная от стадии создания и заканчивая управлением тестами.
Главными конкурентными преимуществами являются
- низкая стоимость вхождения. Начинающие автоматизаторы, и даже QA инженеры без навыков программирования создают качественные тесты, а значит легко поддерживаемые, легко изменяемые, с использованием DDT (Data Driven Testing) подходов, что увеличивает повторно-используемость тестов
- встроенные возможности структуризации тестов по папкам и файлам, а также по тегам, что позволяет качественно отобразить документацию на тесты. Внедряя эту платформу, вы автоматически улучшаете свои процессы управления тестами
- XML2Selenium - это плагинная, расширяемая платформа, позволяющая кастомизировать процессы под ваши нужды, создать новые плагины, добавить интеграцию с нужными системами, и многое другое
- все повторно-используемые части (инклюды, плагины) могут помещаться в репозитории, откуда ими могут пользоваться QA инженеры с других проектов компании, тем самым распространяется опыт и знания в области автоматизации
- XML2Selenium имеет широкий спектр полезных свойств в области автоматизации, таких как поддержка создания видео, снепшотов и скриншотов страниц, Groovy и JS скриптинга, поддержки объектно-ориентированного программирования на XML и многих других
Традиционно многие компании не инвестируют много в QA инженеров, при этом сложность продуктов и количество Use Cases растёт, и компании утыкаются в барьер, когда архитектура тестов становится сравнительно такого же уровня, как и архитектура приложения. Это же касается и автоматизации тестирования. Ключевыми проблемами становятся:
- вопросы поддержки и тестирования многих инсталяций продукта на стороне заказчика
- вопросы тестирования нескольких версий (бренчей) одного и того же продукта
- повторн
Nival: Как не увлечься погоней за универсализацией компонентDevGAMM Conference
Если оставить программиста одного — он будет делать суперуниверсальное нечто. Какие компоненты было бы действительно полезно сделать универсальными и как понять когда универсализация это пустая трата времени.
Проблемы и пути их решения при командной разработке проектовАгентство AlterEGO
– Кому нужна командная разработка?
– Что делать в команде?
– Решение реальных задач, распределение ответственности
– Командная разработка на 1С-Битрикс
– Миграции БД
– Проблемы и пути их решения
Архитектурные решения при создании облачного сервиса на Asp.NetGoSharp
На конференциях часто рассказывают, как хорошо и удобно разрабатывать облачные приложения на той или иной платформе. Однако при реальной разработке возникают вопросы, которые обычно обходят стороной. В докладе я расскажу с какими неочевидными проблемами столкнулся при разработке сервиса под Microsoft Azure, и каким образом эти проблемы были решены.
TК°Conf. Организация разработки Frontend. Виталий Слободин.TKConf
Расскажу об организации процесса разработки Frontend в единый конвейер, чтобы увеличить скорость и минимизировать затраты с рисками.
Как организовать верстку макета по фантастичному макету дизайнера при этом не вогнав в когнитивный диссонанс результатом на Bootstrap.
Каким образом объединить воинствующие стороны: Frontend, Backend и дизайнеров.
Эдуард Сергеев расскажет о том, как выработать единый подход к метрикам, что становится необходимо, когда в компании появляется хотя бы один по-настоящему крупный проект. Это позволит не только отслеживать его развитие в динамике, но и сравнивать эти показатели в дальнейшем с другими проектами.
Ссылка на видеозапись: https://youtu.be/rysvNokETnQ
Egor Fedorov "Behavior-driven development in Python"Fwdays
The goal of the BDD technique is to establish successful communication between customers, business analysts, programmers, and testers for the whole life of the project.
That is why a language was created, in which the expected behavior of the application is described in simple text form, and then through the BDD framework, the text is translated into program code, which could already be used in testing the software product.
Where BDD is applied, software requirements turn into living code, and tests instead of a programming language are written in simple human language.
In this talk, using the automation of website testing as an example, the Behave framework for Python will be shown.
The talk will be about:
writing bdd files;
performing them in behave;
running BDD as tests in pytest;
integrating everything into the CI pipeline.
6. Что мы получили
• Снижение количества коллизий
• Сокращение сроков разработки
• Уменьшение времени простоев
• Масштабируемость
• Увеличение точности оценок
7. А как это все реализовать?
И причем тут bem, node.js и python
8. Презентационная логика в Django
mytardis.readthedocs.org/en/latest/architecture.html
Для верстки «по живым
данным» необходима
работоспособность
всего стека
компонентов Django
9. — Общая логика обработки запроса
Middleware
— Представление ресурсов
URL Mapper, View
— Предметная область
Model, Business Logic
— Готовые решения Auth, Migrations,
Logger, Cache, Geodata, …
Специализация Django
10. БЭМ — верстка, которую легко
поддерживать и развивать
• Методология http://ru.bem.info/
• Node.JS https://github.com/joyent/node/wiki/
Installing-Node.js-via-package-manager
• БЭМ https://github.com/bem/project-stub
11. БЭМ
— Единая предметная область:
Блок, Элемент, Модификатор
— Библиотеки bem-bl, bem-controls, ...
— Шаблонизатор на JavaScript bemhtml
— Сервер для разработки bem server
— Сборщик ресурсов borschik
— Менеджер зависимостей bem make
— Возможности для кастомизации node.js
19. Что из это вышло
• Параллельность и асинхронность
• Сроки
• Качество
• Масштабируемость
20. Алексей Спиридонов spiridon@jetstyle.ru
Евгений Генералов lucky@jetstyle.ru
JetStyle http://jetstyle.ru
http://github.com/jetstyle/
ppa:jetstyle/pyv8
Вопросы...
— Кто делает так же?
— Как сделать ещё лучше?
— Как вы боретесь со сложностью?
Editor's Notes
Всем привет! Меня зовут Алексей Спиридонов со мной будет рассказывать Евгений Генералов. Давайте перед тем как рассказывать свой доклад поинтересуемся: 1) Кто знает что такое BEM? Кто сталкивался с ним? 2) Кто занимается разработкой на PHP? Кто на питоне? Кто на руби? Кто на с++ - шарпах и прочей? Кто не из всего вы перечисленных? А чем? кто уже когда нибудь сталкивался со связкой BEM
У нас в JetStyle есть отделы дизайнеров, верстальщиков, программистов и тестировщиков. В нашем докладе мы хотим расссмотреть этапы верстки и программирования и их взаимодействие. И как в большинстве компаний процесс разработки выглядит следующим образом: Каждая задача идет каскадным методом (по так называемому класическому "Водопаду") от постановки до тестирования: После постановки и проектирования за нее брался дизайнер и рисовал что-то. После этого, это что-то брал верстальщик и преврашал его в HTML. Псоле всего над получившимся макетом дрожал программист и обвещивал все это дело яваскриптом, разбивал это все на шаблоны в своем шаблонизаторе и получал готовый продукт на выходе. После чего менеджер и тестировщик проверял правильность выполнения задачи. Но это все в идеальном мире. На деле же происходит следующее:
ВОт такой вот ежик. Дизайнер не то или не все наривсовал, верстальщик что-то сделал не так или все так но совершенно не согласуется с виденьем программиста. ПРограммист не так натянул верстку или при такой верстке яваскрипт работает медленно и еще какие то. В итоге разбитый результат правится несколькими льюдьми и получается ад и ненависть. Когда Общее время разработки растет, затягиваются сроки, все недовольны ибо плохая предсказуемость.
Пока технологии были относительно просты и программирование фронт енда занимало маленькую часть от общего программирования приложения, мы как-то мирились с этим. Но постепенно технологии расли, появлялась фронтендная магия и становилось сложнее "разворачивать" задачу обратно верстальщику. У нас появляется куча всего нового: 1) Сложный аякс 2) Хранение данных на клиенты 3) Сокеты 4) МВЦ 5) Динамические сложные системы 6) Сложность верстки росла и приближалась (в некоторых проектах) по времени к бекендовой разработке. В общем львиная часть логики переносится на яваскрипт Граница ответсвенности становится зыбкой и непонятной, вертальщик говорит что это должен делать программист, программист говорит что это удобнее делать верстальщику и тд. В итоге после всех этих припитий кто-то делает и.... все ломает, потому что другой тоже решил это сделать.. в общем бардак и суматоха. А еще может сложиться так, что кто-то кого то ждет и все сроки идут в... Стоит так же упоминуть про масштабируемость, в настоящее время можно легко выделить несколько видов приложений, браузерное, тачевое, мобильное. И данные то одни и логика то одна но встараивать они должны все разными видами и по разному. Зачастую для каждого из типов приходиться делать большой кусок работы на бекенде. Это большая работа, случается много опять же проблем с оценкой и прочее прочее... После прихода понимая что так дальше жить нельзя мы решили все поменять. Об этом и об средствах для этого собственно наш сегодняшний доклад.
Для начала мы решили что верстака от программиста надо обособить друг от друга. Сделать их разработку независимой друг от друга.
После данного изменения в процессе мы получили: 1) Мы избавил от вредных пересечений зон отвественности разработчиков, раньше было так называемое сложение ответственности и "перекидывание задач" (когда верстальщик утверждает ) 2) Сроки, изза более раннего начала этапа программирования, проекты стали выполняться быстрее по времени, 3) Изза того что мы распралелили и изолировали версту и программинг теперь никто никого не ждал, а следовательно и простоев на осталось 4) Масштабируемость, теперь у нас одна логика для всех приложений и каждому приложению только одна своя шкурка 5) Оценка - изза независимости разработки, в оценку вкладывается меньше факторов которые влияют на ее оценку, а следовательно она стала точнее //ВО первых, данный метод прост в управлении, от постановщиков и главное от менеджеров не требуется специальных знаний или инструментов. Временные и людские затраты //относительно малы. //Во вторых, из за четкости постановки задачи и понятного конечного результата оценка, пусть даже с небольшим огрехом, достаточно верна (при отсутвии форс-мажоров и хорошем //менеджменте) //После каждого этапа идет вполне обособленный результат. Данный пункт можно частично отнести к минусам, потому изза обособленности результата, имеено после выполнения //задачи мы можем //Во первых это Масштабируемость - при вмешательстве в разработку по причинам внутренним (на предыдущем этапе что-то не доделали) и внешних (заказчик передумал и надо //все поменять). Это очень накладно, вообще у нас получается так, что чем раньше мы внесли изменения (баг это или новая функциональность) тем дешевле она на выходит. //Коллизии -, мы считаем что, если какую то задачу могут сделать 2 типа разработчиков это плохо! Это выливается в "перекидывание задачи" или в выполнении задачи менее //квалифицированным специалистом. //На сроки при таком подходе очень сильно влияют различные внешние и внутренние факторы, изменения верстки, разрезка макетов, плохое настроение заказчика и прочее... Иногда //может доходить до простоев в производстве
Для того, чтобы внедрение данных подходов в процесс разработки стало возможным на практике, нам нужны эффективные инструменты. Кто использует python и django и считает что они классные?
Использование шаблонизато
БЭМ (аббревиатура от слов Блок-Элемент-Модификатор) про "острова" Мы более трех лет делаем сайты для Яндекс с использованием методологии БЭМ и наши скиллы проверены на практике. Для разработчика Упрощение разработки и поддержки Простота переключения между проектами Ускорение разработки при повторном использовании кода Рост проекта не ухудшает качество кода Для командной работы Быстрое подключение человека к команде Совместная работа с кодом разных специалистов Независимая работа над частями проекта Использование чужого кода без погружения в детали реализации
Примерная схема работы всего такогва, !ОБЪЯСНИТЬ ЧТО ТАК А ЧТО НЕ ТАК!
Примерная схема работы всего такогва, !ОБЪЯСНИТЬ ЧТО ТАК А ЧТО НЕ ТАК!
Примерная схема работы всего такогва, !ОБЪЯСНИТЬ ЧТО ТАК А ЧТО НЕ ТАК!
Мы помогали развивать pybem и решили ряд функциональных проблем.
Что нам дало такое разделение: 1) Изоляция, теперь верстальщик и программист полностью дистанцированны друг от друга, у них разный однозначно определнный круг задач !!НАДО ЕЩЕ!!! 2) Сроки, стали немного более пресказуемыми, дизайн перестал влиять на программиста, верстак начал делать javascript и css с html для себя, что тоже немного ускорило разработку. Ошибки стали более дешевые и быстро исправляемые. 3) Внесение измений стало более быстрым и пресказумым с меньшим кол-вом ошибок. 4) Рост проекта в ширь (создание нескольких разных версий) или в глубь (увеличение функционала, увеличение команды и прочее) стало сильно менее проблематичным.
На данный момент JetStyle это 15 разработчиков (7 программистов, 8 верстальщиков), с полсотни проектов в активной доработке и поддержки, а еще с полдестяка новых проектов, часть которых наверняка добавится к проектам в доработке и поддержки. /// На этом сайте хочется показать Преимущества JetStyle // Мы используем крутые трендовые штуки и технологии от крутых разработчиков // для реализации крутых проектов крутым клиентам // и есть место для эксперимента, что позволяет придумывать новые комбинации для принесения максимальной пользы. Визуально список технологий БЕМ Django Node.js HTML5/CSS3 Компании Microsoft Yandex SAP