Командный старт

Ограничение: 25 человек (кто успел того и тапки) У нас новый проект и делать его будет новая команда.  Возможно, мы давно работаем  в одной организации, но мы впервые будем делат…

На доклад идут: 17

 

Новые доклады

 
 

Доклады

#1

Agile Distribution Risk Score - планируйте распределенность осознанно

Scrum давно используется для разработки программного обеспечения в распределенном режиме и когда речь заходит о проекте с участием нескольких распределенных команд, то понятно что проект будет непростым.  Но насколько непростым и как четко и грамотно построить взаимодействие между заказчиком, командами и руководством проекта? Каков на самом деле уровень риска такого проекта? Проанализировав личный опыт разработки распределенных Agile проектов и опыте Exigen Services,  я выделила несколько факторов влияющих на такие проекты что позволило сформулировать  Agile Distribution Risk Score как четкую метрику сложности распределенного проекта.  Пользуясь этой формулой любой руководитель проекта сможет наглядно  в цифрах увидеть сложность проекта и работая над факторами входящими в рассчет Distribution Risk Score сделать проект более грамотно организованным.  Этот подход позволяет рассчитать когда распределенная команда будет эффективна, а когда стоит настаивать чтобы проект не был распределенным. …

Уровень аудитории: новички, практикующие, эксперты
Направление: Agile Process, Team
Докладчик: Анна Обухова, Exigen Services

На доклад идут: 3

Задать вопрос

#2

Для тех, кто в танке — что такое Agile lighting talk

Yet Another введение в Agile. Не очень короткое (не «Скрам за 5 секунд» и т.п.), но зато вполне вдумчивое, на хорошем уровне, для достаточно подготовленной (как выяснилось) аудитории. …

Уровень аудитории: новички, практикующие
Докладчик: Асхат Уразбаев, ScrumTrek

На доклад идут: 0

Задать вопрос

#3

Все в ваших руках: быть готовым к изменениям в системах БД.

Использование накопленных данных является основой современных информационных систем.  Обработка данных  заложена в фундамент информационных технологий. Казалось бы, нет ничего более стабильного, чем данные, но  современный мир устроен так, что основной линией развития является потребность в изменении. Бурное развитие AGILE-технологий в 00-е годы нашего столения вызвано потребностями ИТ-промышленности в резком повышении эффективности процессов разработки и использования компьютерных систем в условиях необходимости частого внесения изменений в соответствии с меняющимся внешним миром, потребностями бизнеса, быстрым развитием технологий, возрастающей глобализацией недостатком ресурсов и времени.   Изложенные в АGILE manifesto характеристики направлены на борьбу с недостатком текущих знаний у разработчиков и некомпетенцией, организацию продуктивного сотрудничества создателей систем и их заказчиков. Следование этим принципам подразумевает использование эволюционного подхода и сокращение времени циклов при увеличении их количества.   В области управления данными применяются такие передовые AGILE-технологии, как рефакторинг БД, Agile-моделирование данных, управление конфигурациями и изменениями, организация тестовых площадок (sandbox), Agile master data management (MDM) и др. …

Уровень аудитории: новички, практикующие
Направление: Product Management, Engineering & Quality, Experience Report
Докладчик: Андрей Совцов, Embarcadero Technologies

На доклад идут: 2

Задать вопрос

#4

Сказка о maven, jetty, web-сервисах и интеграционном тестировании

В Тридевятой компании, в тридесятой команде жил был проект. И использовался maven, как инструмент для сборки проекта этого. И был это корпоративный стандарт Тридевятой компании. Было все и складно, и ладно пока не попал этот проект на аутсорсинг к трем богатырям. Жили богатыри за тридевять земель от корпоративной сети тридевятой компании. И выполнялись тесты интеграционные семь дней и семь ночей. И стали богатыри думу думать как бы облегчить себе жизнь и ускорить тесты интеграционные...   ...И нашли они решение проблемы непростой. О нем поведаю вам в сказке этой. О том, как организовали работу они в проекте своем. Как научили билд-сервер дружить с разными проектами с тестами интеграционными. Как организовали работу тестов с данными дабы предсказуемым было базы состояние.  …

Уровень аудитории: практикующие, эксперты
Направление: Engineering & Quality, Agile Process, Team
Докладчик: Руслан Пилин, фрилансер

На доклад идут: 16

Задать вопрос

#5

Agile с фиксированной стоимостью: это реально!

Берем заказчика, который за свой определенный бюджет хочет разработать некий программный продукт. Требования, как водится, самые высокоуровневые, про Agile заказчик не слышал никогда и его это слово интересует мало - он оперирует классическим треугольником: бюджет, сроки и нужная бизнесу функциональность (которая, конечно, по ходу проекта будет меняться).   Понятно, что для нас, как разработчиков, риски в таком проекте крайне высоки: как дать правильные оценки, как построить открытые отношения с заказчиком, как бороться с изменениями в скоупе.. как, наконец, выстроить эффективный процесс на основе Scrum и не облажаться?  …

Уровень аудитории: практикующие, эксперты
Направление: Product Management, Experience Report, Agile Process
Докладчик: Дмитрий Лобасев, ScrumTrek

На доклад идут: 4

Задать вопрос

#6

Enterprise Scale Agile. Lessons learned

Переход к Agile и Lean методологиям успешно доказали свою эффективность в новых и небольших компаниях, для которых гибкие методологии это на сегодняшний день стандарт де-факто. За изменениями в небольших организациях следует новая волна, которая изменяет огромные транснациональные корпорации, включая крупнейшие инвестиционные банки с десятками тысяч людей. Такие изменения масштабны, в большинстве случаев включая массивный редизайн организаций, изменение мышления и стереотипы огромного количества людей. В этой презентации я расскажу об одной из успешных трансформаций группы проектов в крупнейшем инвестиционном банке которая включала 200 человек. Я расскажу о cross-component, cross-functional feature teams, объедененных архитектурных воркшопах, множественных бэклогах и двух десятках командах одновременно работающих в одной базе кода на пяти разных сайтах у трех вендоров и при этом каждые 2 недели выпускающих новую версию платформы. Я поделюсь опытом о полученных уроках, успехах и достижениях, ошибках, улучшениях и, конечно, инновациях. …

Уровень аудитории: практикующие, эксперты
Направление: Agile Process, Team
Докладчик: Константин Гурнов, Люксофт

На доклад идут: 4

Задать вопрос

#7

Как сервисному отделу не стать бутылочным горлышком

Основной идеей Agile является увеличение ценности разработки для бизнеса. Ваш Капитан.   Тестирование никогда не было созидательной службой. Если тестирование хорошее – оно уменьшает расходы бизнеса. Но дополнительное «value» в продукт тестированием привнести очень трудно.   А вот помешать – очень легко. Неграмотно построенная организация работы может сделать тестирование бутылочным горлышком в проекте, а то и в компании.   Значит, помимо поиска багов, ключевой задачей тестирования является сделать этот поиск настолько гармонично вписанным в общий процесс, чтоб не увеличивать операционные расходы.   …

Уровень аудитории: практикующие
Направление: Experience Report, Team
Докладчик: Юля Нечаева, Иннова

На доклад идут: 0

Задать вопрос

#8

Трехуровневое планирование в Agile из реальной практики и как реагировать на изменения заказчика.

На сегодняшний день Agile является основным мейнстримом в процессе разработки ПО. Существует большое количество статей и книг, описывающих SCRUM, Kanban и Lean, но после прочтения вы, возможно, задумаетесь о том, как на практике адаптировать эту замечательную методологию. В своем докладе я расскажу, как я изучал и внедрял Agile, а также поделюсь реальным опытом многоуровневого планирования в Agile, который был адаптирован и проверен в реальном центре разработки.  …

Уровень аудитории: практикующие, эксперты
Направление: Product Management, Agile Process, Team
Докладчик: Дмитрий Овечкин, Innova Systems

На доклад идут: 7

Задать вопрос

#9

На доклад идут: 2

Задать вопрос

#10

Agile без брака, или как внедрить личную ответственность

Как научить программистов выполнять задачи с первого раза? Как получать меньше замечаний по итогам демо? Как не получать «пожары» после релиза? Как перестать быть нужным для выполнения любой задачи? . Если эти вопросы есть у менеджера, у остальных в команде есть свои «отражения»: как не возиться с глупыми багами программистов? (тестировщик), почему докопались до каких-то мелочей? (программист/ верстальщик/дизайнер), и так далее. . Источники вопросов не зависят ни от бюджета, ни от владениями технологий: то, что в одном случае вылезает на пользователя как баг, в другом – просто создает лишние затраты на исправление. . Решение – общее для всех: принцип «сделал — проверь», заряженный личной ответственностью каждого. Это — ключ к успеху в любой отрасли, но в разработке его внедрить сложнее всего. Но если внедрить — счастливее все. . В докладе: …

Уровень аудитории: практикующие, эксперты
Направление: Product Management, Engineering & Quality, Experience Report, Agile Process
Докладчик: Антон Белоусов, EasyFinance.ru

На доклад идут: 4

Комментарии: 2

#12

Модель принятия инженерных решений: ключ к ответам на технические вопросы

Нужен ли в дизайне моей системы паттерн Singleton? Почему при изменении требований затраты на внесение изменений возрастают? Сколько времени уделять проектированию? Зачем мне модель предметной области, ведь и без нее все работает? Чем архитектура отличается от дизайна? С чего начать проектирование? Я запутался в паттернах - они противоречат друг другу! Вся остальная команда - придурки, они ничего не понимают! Где располагать модульные тесты? Нужно ли документировать? Что именно документировать?   Мучают эти вопросы? Конфликты в команде? Тогда мы идем к вам :) Ответ есть :)   Бухтелово посвящено модели принятия инженерных решений. Ожидается, что слушатели выступления получат мощный инструмент - стройную систему, которая позволит в лучших традициях agile-подхода вырабатывать оптимальный дизайн систем и разрешать конфликты в команде. В качестве отправной точки будут представлены типичные грабли и антипаттерны разработки, которые автор считает наиболее типовыми и массовыми. Отталкиваясь от них, мы коллективно смоделируем решения, которые помогут резко снизить затраты на разработку и приведут к качественному дизайну. Полный план доклада доступен по адресу http://tinyurl.com/6l32r94  …

Уровень аудитории: практикующие
Направление: Engineering & Quality
Докладчик: Евгений Кривошеев, ScrumTrek

На доклад идут: 0

Задать вопрос

#13

В погоне за качеством. Code Review мастер-класс

Многие жалуются на качество кода, автоматизированных тестов или продукта в целом, на количество ошибок, найденных конечными пользователями или отделом тестирования. Почему это происходит? Необходимо понимать, что для того чтобы не допустить подобных ситуаций требуются дополнительные усилия – необходимо следить за качеством кода и работать над его улучшением. Code Review является одной из наиболее полезных и эффективных практик для ранней борьбы с дефектами в коде и повышению его качества. Использование Code Review на различных этапах разработки, начиная от дизайна и заканчивая написанием кода и тестов, помогает построить ранний цикл обратной связи и избежать потерь времени в будущем на исправление ошибок. …

Уровень аудитории: новички, практикующие, эксперты
Направление: Engineering & Quality, Agile Process, Team
Докладчики: Николай Алименков, Алексей Солнцев, XP Injection

На доклад идут: 13

Комментарии: 5

#14

Планирование релизов в методологиях быстрой разработки (Agile)

Казалось бы структура рилизов в командах быстрой разработки вообще не нужна, ведь в соответсвии с манифестом "Работающее ПО превыше всего". В теории внедрение должно производиться регулярными интервалами и весь контроль за рилизом - это слова заказчика: "Я доволен, выпускайте". В своем докладе Дмитрий обсудит с вами процесс управления рилизами в Аgile проектах на примерах компаний Майкрософт и Амазон, а также различные методы и подходы: "Ship when ready", "Ship when needed", "Ship when scheduled". Не стоит также забывать, что процесс управления рилизами не ограничивается одним рилизом, и команды одновременно могут работать (и работают) над несколькими одновременно. Прогнозируемость рилиза, качество внедренного кода, соответствие кода ТЗ заказчика - это залог успеха рилиза. …

Уровень аудитории: практикующие
Направление: Product Management, Experience Report, Agile Process
Докладчик: Дмитрий Никонов, Principal Program Manager

На доклад идут: 5

Задать вопрос

#15

Модель системы — архитектура для Agile-разработки

Итеративная разработка в agile ставит проблему: как создавать и поддерживать архитектуру системы. Можно работать без нее, но в сложных проектах не получаются. DDD предлагает строить каркас как доменную модель. Это — лучше, но доменная модель описывает не все аспекты системы. Мы хотим поделиться своим опытом описания архитектуры.Начиная новый проект мы, естественно, создаем vision системы, определяем границы проекта. Затем создается интересный артефакт — архитектурная модель системы в терминах бизнеса, сначала в общем виде, описывающим крупные блоки системы и выработка плана реализации. А затем выполняется уточнение фрагмента модели, а на следующей итерации — его реализация и демонстрация Заказчику.Из чего состоит модель? Наша компания занимается заказной разработкой учетно-аналитических систем, и мы выработали достаточно устойчивый шаблон, использованный в десятках проектов, который мы называем Учетной машиной. Модель состоит из трех частей: доменная модель, модель документооборота и модель учета. Первая представляется диаграммой классов. …

Уровень аудитории: практикующие, эксперты
Направление: Engineering & Quality, Experience Report
Докладчик: Максим Цепков, CustIS

На доклад идут: 7

Задать вопрос

Смотреть все доклады

123