Денис Тучин - Болезни Agile ретроспектив и как их лечить (2016 AgileTour.By)Denis Tuchin
Видео: http://youtu.be/CTrRzdzhj1s?list=PLu7pKL8OAoRSze5Ts9wrbcEQBvXDx-AGq
Если вы начали проводить ретроспективы в своей команде, это ещё не значит, что вы внедрили процесс постоянного совершенствования (Kaizen). Часто у начинающих и не только Agile команд возникают те или иные сложности: выявленные проблемы не существенны или находятся за пределами влияния команды, действия по решению проблем не воплощаются в жизнь.
На докладе мы рассмотрим типичные проблемы Agile ретроспектив и как с ними бороться. Начнём с такого часто встречаемого случая, когда члены команды достаточно позитивно настроены, не видят проблем в своей работе и их идеи по улучшению процесса сводятся к предложениям по организации инфраструктуры офиса: кондиционеры, видов чая и т.д.
Здесь нужно вернуть команду с небес на землю, показать, какие проблемы есть на самом деле и профасилитировать нахождение решений.
Другой частый случай почти полная противоположность первому по атмосфере, но по эффекту на ретро очень похож. Члены команды настолько сильно находятся под прессингом дефектов и постоянных "хотелок" заказчиков, что не верят, что что-то можно улучшить и видят проблемы только в других командах, но не у себя.
Здесь более сложный процесс по нормализации атмосферы в команде. Рассмотрим первые 3 важных шага, как это сделать: снижение психологического напряжения процессным путём, решение основных проблем и маленькие победы.
Третья проблема, которую успеем рассмотреть: принятые на ретроспективе решения, не претворяются в жизнь. Практики для исправления достаточно просты, но далеко не все о них знают и их соблюдают: добровольное назначение задач, голосование консенсусом и добавление задач в беклог.
Lean-разработка, система Kanban, Scrumban - все эти слова всё чаще звучат на специализированных конференециях и вебинарах. Изначально появившаяся в недрах "Тойоты" система производства с успехом перекочевала в мир разработки программного обеспечения.
Какие преимущества может дать эта системы вашей компании? Как команда разработчиков может использовать в своей деятельности принципы Kanban? Как можно скрестить Scrum с Kanban и что получится? С чего начинать?
Денис Тучин - Как внедрить Agile, чтобы никто не заметилDenis Tuchin
Видео: https://www.youtube.com/watch?v=ielCPWnMQts
Часто сталкиваюсь с вопросом коллег, а что делать, если в компании никто не хочет/не заинтересован внедрять Agile, начальство не поддерживает и т.д. Этот доклад чтобы помочь людям разрешить такие кейсы с максимальной эффективностью и минимальными моральными усилиями.
На докладе постараюсь ответить на следующие вопросы:
- Что делать, если в компании или команде есть ярые противники Agile?
- Что делать, если никто ничего не хочет менять в процессах проекта, отдела, компании?
- Как не "внедряя Agile" привнести Agile принципы и практики в проект?
Константин Назаров – Распараллеливание сборки Parallels Desktop для Mac404fest
Идея доклада — рассказать об использовании Jenkins как не типичного инструмента для построения распределенной сборки продукта, зарабатывающего миллионы долларов. Мы поделимся секретами его адаптации под сборку билдов сложных систем/продуктов с многими компонентами и ускорения в разы этой задачи.
Наша проблема: линейная сборка продукта занимает 8 часов. А Jenkins «из коробки» не умеет собирать сложные иерархии. При этом писать код самостоятельно не хочется. В итоге мы придумали, как использовать существующий инструмент, пройдясь по нему напильником.
Кому будет интересно: Эти знания могут помочь людям, которые хотят построить эффективный CI, но не хотят тратить много времени на исследования.
Мы выложим наш код и материалы на GitHub. Это будет довольно практично.
Лайфхаки:
Используем Build Flow + Groovy скрипты чтобы оркестрировать сложную иерархию с параллельными ветвями и собирать результаты
Правильное использование префиксов в названиях job-ов помогают автоматизировать группировку по бранчам
Переиспользуем окружения сборки много раз, не удаляя их
Предыдущий пункт в итоге оставляет за собой кучу мусора, которую мы периодически очищаем при помощи системных Groovy скриптов по job префиксу
Группировка большого количества job-ов в проекты и бранчи с использованием Nested View
Дамп и разворачивание job-ов из системы контроля версий по шаблону
Ну и взгляд в будущее: автоматический анализ билд проблем.
http://2014.404fest.ru/reports/jenkins/
В “классическом” энтепрайзе правят водопадные процессы. Это позволяет снизить затраты на старт новых проектов, но сильно ухудшает время Time to market. Переход на гибкие методологии позволяет это время значительно улучшить. Это очень не просто. Каждая команда разработки страдает от большого количества зависимостей. И в большой организации таких зависимостей настолько много, что представленный самому себе Agile в такой команде через какое-то время может и помереть. Перестраивать организацию процессов приходится полностью, сверху донизу.
Мы поговорим про специфику внедрения Agile в крупной организации сравнив две компании — типичную крупную веб-компанию и классический “кровавый энтепрайз”.
AzovDevMeetup 2016 | Выстраивание процесса и применение Best Practices с нуля...JSC “Arcadia Inc”
Представьте себе ситуацию: к вам приходит заказчик, у него уже есть продукт, и вам надо организовать процесс и создать соответствующую инфраструктуру так, чтобы сделать работу над продуктом максимально удобной и эффективной. Какие шаги были сделаны и почему, какие проблемы встретились и как были решены проектной командой в вышеописанной ситуации, к чему всё это привело на данный момент — об этом и будет рассказано в докладе.
О том, какие проекты являются agile, а какие – нет, а также о том, что agile очень часто путают с итеративной разработкой, хотя на самом деле это совершенно разные вещи, рассказал в своем докладе Михаил Кумсков на Stratoplan TECH&BUSINESS Summit.
Михаил Кумсков, эксперт по методологиям управления требованиями, использования методологии RUP и инструментария IBM Rational, представил доклад «Agile и RUP — мифы, легенды и вся правда».
Тезисы доклада:
«Часто, говоря об Agile разработке, имеют в виду прежде всего итеративную разработку. В докладе хочется развеять известные мифы и легенды про Agile и RUP. Хотелось бы в докладе напомнить про RUP как источник знаний, про agile-RUP – про то, что велосипед изобретен и имеется прекрасное его описание, адаптируемое под такие разные проекты разработки софта – большого и маленького. Также будет обсужден взгляд на «юзер стори» как на экземпляр сценария использования».
Выступление на семинаре в Яндексе
Как -то получается, что (по большому счету) альтернативы Agile-подходам при построении эффективных процессов нет. А что делать, если Agile применить невозможно? Причин может быть множество: "неправильная" структура организации, "не те" люди, негибкие начальники и так далее.
Невозможно построить скрам? Но придумать вам свой собственный скрам никто запретить не может!
Мы рассмотрим 3 реальных кейса провала внедрения Agile и вместе обсудим, как можно было бы поступить в каждой конкретной ситуации. По каждому случаю я расскажу, что произошло в реальности.
JS Lab2017_Алексей Зеленюк_Сбалансированное окружение для вашей продуктивностиGeeksLab Odessa
JS Lab2017, 25 марта, Одесса
Алексей Зеленюк (Application Architect at Eleks Software)
Сбалансированное окружение для вашей продуктивности
Для построения больших веб-приложений необходим хороший фундамент: процесс сборки, тестирования и интеграции, анализа качества кода и отладки. Новые технологии и безнес-требования создают новые требования к окружению, усложняя его. Как построить надежное окружение, сохранив при этом его гибкость и простоту?
Гибкие методологии разработки ПО в реальном миреTech Talks @NSU
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=ooa5qE7oTQg
8 апреля 2016. Гибкие методологии разработки ПО в реальном мире (Антон Дёмин, Xored)
На этой лекции мы рассмотрим классические модели управления проектами, поговорим о реалиях разработки и о наиболее частых проектных проблемах, с которыми сталкиваются разработчики и менеджеры.
Среди прочего мы рассмотрим гибкие методологии; как в общем, так и на примере их конкретных представителей (Scrum, XP, Kanban). Также будет рассказано о процессе перехода на Scrum на примере крупного проекта для одного из клиентов компании.
Кроме того, поскольку гибкие методологии подразумевают гибкие правила, мы прямо на лекции попробуем модифицировать одну из хрестоматийных методологий под нужды конкретного проекта, а именно — немного доработаем Scrum путем добавления в него артефактов из других методологий.
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
1. Тестирование в Scrum и
Kanban
Игорь Лукашов
Softline, Новосибирск
И никуда не надо ехать!
2. Игорь Лукашов
• Компания:Softline
• Должность: Ведущий тестировщик
• Участник различных внутренних и
внешних проектов компании
• Тестировал web/mobile/desktop
2
3. О чем доклад? Проблемы:
3
1. Незнание agile философии
2. Нет практики работы в
гибком контексте
3. Дискомфорт от внедренного
процесса
8. Kanban
8
3 принципа:
1. Визуализируйте производство
2. Ограничивайте количество одновременно
выполняющейся работы
3. Измеряйте среднее время на выполнение
одной задачи
11. Scrum Vs. Kanban
11
Различия:
Основание Scrum Kanban
Размер задач Декомпозированы до
более мелких чтобы
успеть реализовать за
итерацию
Задачи крупные.
Декомпозиция не
обязательна.
Таймбоксы Задачи, спринты Нет ограничений по
времени
Ограничение на количество задач В итерации По статусу задачи
Оценки задач Обязательны Опциональны
Используемые метрики Производительность
команды
Средняя скорость
выполнения задачи