Алексей Крученок рассказывает о концепции минимально жизнеспособного продукта (MVP, minimum viable product), инструмента валидации бизнес-идей, который позволяет сократить время запуска проекта за счет создания только необходимых функций и начать получать реальный фидбек по своему продукт
----
В рамках проведения «Научного Хакатона» мы приглашаем вас на митапы, где будут проводиться обучающие и консультационные сессии под руководством экспертов в области науки, бизнеса и ИТ.
У вас будет возможность обсудить задачи, получить экспертную помощь, объявить о вакантных местах в команде и не только.
Присоединяйтесь и решайте научные задачи командами!
Cайт: http://sciencehit.by/hackathon
Денис Тучин - Внедрение изменений: семь раз отмерь – один отрежь на UlCamp.Wi...Denis Tuchin
В докладе рассмотрим два ключевых момента: решение о целесообразности внедрения изменений и лучшие практики самого процесса внедрения. В том числе разберём отдельные элементы модели Коттера, проверку цели на экологичность и модель ADKAR. Также обсудим, как внедрение изменений на разных этапах развития команды влияет на его динамику.
Денис Тучин - Проверка гипотез Kanban Method с помощью имитационной моделиDenis Tuchin
Видео: https://www.youtube.com/watch?v=79Joxx6gTeU
Используя имитационную модель на докладе мы проверим, что лучше работает:
- Что делать если команда не сбалансирована
- Может ли сбалансированная команда работать без ограничения WIP
- Как подобрать оптимальные ограничения WIP
- Помогает ли приоритезация бизнесу
Денис Тучин - Лучшие практики внедрения изменений на уровне командDenis Tuchin
1. Правильная постановка цели (Больше чем SMART)
2. Взвешиваем все за и против
3. Ищем единомышленников
4. Создаём атмосферу безотлагательности действий
5. ADKAR
6. Инструменты, процессы, борьба с бюрократией
7. Маленькие победы (планируем, осуществляем и распространяем)
8. Другие поощрения изменений
9. Кадровые перестановки
10. Институционализация
Вячеслав Пресняков. Тестирование в эпоху Agile.ScrumTrek
В моём выступлении я расскажу, как трансформировался наш подход к тестированию, чтобы команда тестирования начала приносить пользу agile проекту и перестала быть узким местом в процессе разработки продукта, как подружить тестирование и короткие итерации, как инженеру-тестировщику не остаться за бортом в agile команде, откуда берётся тестерский долг и как его победить, почему из-за команды тестирования съезжают сроки итераций/релизов и что с этим делать.
Денис Тучин - Как внедрить Agile, чтобы никто не заметилDenis Tuchin
Видео: https://www.youtube.com/watch?v=ielCPWnMQts
Часто сталкиваюсь с вопросом коллег, а что делать, если в компании никто не хочет/не заинтересован внедрять Agile, начальство не поддерживает и т.д. Этот доклад чтобы помочь людям разрешить такие кейсы с максимальной эффективностью и минимальными моральными усилиями.
На докладе постараюсь ответить на следующие вопросы:
- Что делать, если в компании или команде есть ярые противники Agile?
- Что делать, если никто ничего не хочет менять в процессах проекта, отдела, компании?
- Как не "внедряя Agile" привнести Agile принципы и практики в проект?
Алексей Крученок рассказывает о концепции минимально жизнеспособного продукта (MVP, minimum viable product), инструмента валидации бизнес-идей, который позволяет сократить время запуска проекта за счет создания только необходимых функций и начать получать реальный фидбек по своему продукт
----
В рамках проведения «Научного Хакатона» мы приглашаем вас на митапы, где будут проводиться обучающие и консультационные сессии под руководством экспертов в области науки, бизнеса и ИТ.
У вас будет возможность обсудить задачи, получить экспертную помощь, объявить о вакантных местах в команде и не только.
Присоединяйтесь и решайте научные задачи командами!
Cайт: http://sciencehit.by/hackathon
Денис Тучин - Внедрение изменений: семь раз отмерь – один отрежь на UlCamp.Wi...Denis Tuchin
В докладе рассмотрим два ключевых момента: решение о целесообразности внедрения изменений и лучшие практики самого процесса внедрения. В том числе разберём отдельные элементы модели Коттера, проверку цели на экологичность и модель ADKAR. Также обсудим, как внедрение изменений на разных этапах развития команды влияет на его динамику.
Денис Тучин - Проверка гипотез Kanban Method с помощью имитационной моделиDenis Tuchin
Видео: https://www.youtube.com/watch?v=79Joxx6gTeU
Используя имитационную модель на докладе мы проверим, что лучше работает:
- Что делать если команда не сбалансирована
- Может ли сбалансированная команда работать без ограничения WIP
- Как подобрать оптимальные ограничения WIP
- Помогает ли приоритезация бизнесу
Денис Тучин - Лучшие практики внедрения изменений на уровне командDenis Tuchin
1. Правильная постановка цели (Больше чем SMART)
2. Взвешиваем все за и против
3. Ищем единомышленников
4. Создаём атмосферу безотлагательности действий
5. ADKAR
6. Инструменты, процессы, борьба с бюрократией
7. Маленькие победы (планируем, осуществляем и распространяем)
8. Другие поощрения изменений
9. Кадровые перестановки
10. Институционализация
Вячеслав Пресняков. Тестирование в эпоху Agile.ScrumTrek
В моём выступлении я расскажу, как трансформировался наш подход к тестированию, чтобы команда тестирования начала приносить пользу agile проекту и перестала быть узким местом в процессе разработки продукта, как подружить тестирование и короткие итерации, как инженеру-тестировщику не остаться за бортом в agile команде, откуда берётся тестерский долг и как его победить, почему из-за команды тестирования съезжают сроки итераций/релизов и что с этим делать.
Денис Тучин - Как внедрить Agile, чтобы никто не заметилDenis Tuchin
Видео: https://www.youtube.com/watch?v=ielCPWnMQts
Часто сталкиваюсь с вопросом коллег, а что делать, если в компании никто не хочет/не заинтересован внедрять Agile, начальство не поддерживает и т.д. Этот доклад чтобы помочь людям разрешить такие кейсы с максимальной эффективностью и минимальными моральными усилиями.
На докладе постараюсь ответить на следующие вопросы:
- Что делать, если в компании или команде есть ярые противники Agile?
- Что делать, если никто ничего не хочет менять в процессах проекта, отдела, компании?
- Как не "внедряя Agile" привнести Agile принципы и практики в проект?
Мир меняется очень быстро. То, что казалось нормальным еще несколько лет назад, перестало быть таковым. Например, наши родители не считают, что работа должна приносить удовольствие. Они уверены, что работа должна приносить деньги.
Все поменялось. Теперь все уверены, что работа должна нравится. Если это не так, нужно немедленно эту работу сменить на другую, более развлекающую.
С этим можно спорить и несоглашаться, но победить это уже нельзя. Вопрос в том, можем ли мы это использовать и как это сделать?
Мы поговорим о геймификации, одном из способов этого добиться. Геймификация — это использование игровых подходов вне игрового контекста.
Вот и мы с вами посмотрим, как практики гейм дизайна использовать для улучшения процесса разработки ПО.
Вы слышали о движении #NoEstimates? Разработчики во всем мире отказываются от оценки! Не надо оценивать проекты, фичи и таски — говорят они. Это занимает много времени, да и процесс это не особо приятный.
Вам нравится эта идея? Вижу, что нет.
Вот например, как объяснить заказчику свое новое безоценочное восприятие? Хотите вы или нет, сроки придется называть! Что делать с обязательствами на спринт? А как же прозрачность? Предсказуемость?
По большому счету вы правы. Нельзя просто выкинуть оценку и все. Идея #NoEstimate в том, что можно увеличить прозрачность и предсказуемость разработки, если заменить оценку более эффективными инструментами.
Мы поговорим, что такое на самом деле #NoEstimate и чем практически можно заменить оценку.
Лилия Алексеева. Вальс Mrs. Agility и Mr. Waterfall - управление производство...ScrumTrek
Agile не развертывается водопадным методом, переход к гибким практикам также должен быть построен инкрементально. Вам не удастся перевести сразу много команд на гибкие практики. Поэтому возникает вопрос синхронизации работ agile-команд с waterfall-структурами и пересмотра всех процессов, таких как управление релизами, архитектурой, требованиями, проектами и прочих для работы в бимодальном режиме. Сложность вопроса возрастает в арифметической прогрессии в зависимости от количества команд и в геометрической — в зависимости от архитектурного и инфраструктурного ландшафтов, а также от сложившейся культуры взаимодействий. Мы расскажем о нашем опыте трансформации производственного процесса в условиях портфеля в несколько сотен проектов. На текущий момент в Agile работают более 1500 человек и 150 команд и еще около 5000 человек продолжают работать в waterfall-режиме. Как перейти от культуры контроля к культуре прозрачности? Как начать маленькими шагами двигаться в сторону гибкости, шаг за шагом увеличивая степень принимаемого риска, параллельно делая его управляемым? И, наконец, как все-таки повысить скорость без ущерба надежности, когда у вас нет права на ошибку? Ответы на эти и другие вопросы дадим в нашем рассказе.
Выступление на семинаре в Яндексе
Как -то получается, что (по большому счету) альтернативы Agile-подходам при построении эффективных процессов нет. А что делать, если Agile применить невозможно? Причин может быть множество: "неправильная" структура организации, "не те" люди, негибкие начальники и так далее.
Невозможно построить скрам? Но придумать вам свой собственный скрам никто запретить не может!
Мы рассмотрим 3 реальных кейса провала внедрения Agile и вместе обсудим, как можно было бы поступить в каждой конкретной ситуации. По каждому случаю я расскажу, что произошло в реальности.
Сергей Рогачев; Лилия Алексеева. Дизайн и запуск Agile-команд.ScrumTrek
Запуск в Agile — это одно из ключевых событий в жизни команды: от него зависит, взлетит ли Agile? Но запуск дает только 30% гарантии успеха, около 60% зависит от правильного дизайна команды. Мы расскажем, как проводить дизайн команды. Причем покажем на цифрах реального статистического исследования, как ошибки при дизайне отражаются на эффективности команд. Мы поделимся опытом, как непосредственно при запуске команды можно исправить кривой дизайн. И что делать, если нужно запустить одновременно много команд.
Николай Фабричев. Внедряем Agile. Как можно влиять на мотивацию команды при в...ScrumTrek
Внедряя Agile, мы много говорим про ценности и mindset, про особый тип мотивации. Процесс обычно строится на базе принципов мотивации 2.0 (Daniel Pink Drive) и, к сожалению, он не работает. Опыт показывает, что в головах людей Agile ценности часто не могут найти отражения в реальности. Люди воспринимают все как красивую теорию, не имеющую применимость в реальной жизни, но главное, не имеют внутренней мотивации изменяться и изменять окружение вокруг себя. И это проблема на пути внедрения Agile, потому что без желания двигаться к цели любая преграда становится непреодолимой. Давайте поговорим про мотивацию команды внедрять изменения на простом языке. Я приведу примеры, как заинтересовать людей изменяться самим и изменять свою команду
7 Способы проведения ретроспектив для анализа и улучшения процессаMagneta AI
Ретроспектива играет большую роль в развитии команд, работающих в Agile проектах. В большинстве случаев, успех проекта зависит от того, насколько команда умеет совместно выявлять проблемы и улучшать свою работу от итерации к итерации.
Мы рассмотрим различные практики проведения ретроспектив, обсудим часто возникающие вопросы в организации работы команды и коллективного принятия решения.
Энтропия растет. Так устроена вселенная. Команда или организация сначала использует Agile, и переполнена энтузиазмом. Она успешно решает свои проблемы. Но время идет и процесс перестает улучшаться. Возможно, команда выбралась в свою зону комфорта. Или улучшение процесса не так уж и нужно команде и деградация - часть закономерного процесса восстановления статус-кво?
А можно ли сделать улучшение процесса действительно непрерывным? И что для этого нужно сделать?
Мы рассмотрим в докладе особенности процесса улучшения процесса и рассмотрим, каким должен быть лидер этого процесса, его задачи и инструменты.
IT talk Spb #34 «Performance Based Hiring» Саша Зверев, сооснователь 2DiggersDataArt
О чем пойдет речь?
Performance Based Hiring — метод найма персонала, основанный на анализе фактических данных:
-кто такие «лучшие» сотрудники и кандидаты;
-концентрируемся на производительности кандидата, в противовес его навыкам;
-интервью на основе фактических данных;
-зачем нам HR?
Почему я про это говорю?
HR и IT-специалисты друг друга не понимают, и главное, даже не представляют, как договориться. И ответственность за это — на обеих сторонах.
Очень низкий уровень проблематики при разговорах об HR.
Карго-культ — делаем, как делали до нас, но почему — никто не знает, не понимает и не может объяснить.
Результат: на основе своего опыта и под большим влиянием идей Лу Адлера я рассказываю, как надо расставить акценты и какие задать друг другу вопросы, чтобы:
-преодолеть упомянутое непонимание между нанимающими менеджерами, HR и кандидатами;
-сделать процесс найма более экологичным, эффективным;
-а крутых специалистов — более доступными для разговора.
http://it-talk.dataart.ru/events/events-spb/2015/09/priglashaem-druzej-na-34-j-it-talk-v-peterburge/
Внедрение Agile на разных этапах развития компанииAskhat Urazbaev
Адизес сравнивает развитие организации с взрослением человека – от стадии ухаживания и зачатия до самой смерти. На разных этапах требуется по разному управлять компанией.
В последнее время (с приходом Lean) гибкие практики выходят на уровень управления организацией. Однако, как показывает опыт (сын ошибок трудных), тот Agile, который подходит молодой, полной надежд организации может совсем не подойти покрытой шрамами и растерявшей все свои зубы компании.
Мы поговорим о том, какие потребности в проектном управлении есть у компании на разных этапах ее развития, когда имеет смысл применять Agile, когда это опасно и рассмотрим несколько практических советов по управлению проектами.
Алексей Ионов. Agile в масштабе корпорации: как не создать хаос?ScrumTrek
Когда-то давно на заре Agile многие (и я в том числе) часто начинали разговор про внедрение проворно-гибких подходов с того, что переход на них полностью зависит от поддержки высшего менеджмента организации. Сегодня по опыту работы очень разных крупных компаний становится совершенно очевидно, что основные препятствия на пути трансформации находятся не только и не столько на уровне первых лиц. Они выходят далеко за рамки Манифеста и широко известных подходов для управления эффективными командами. Я поделюсь идеями и наработками, которые позволяют разрешать проблемы (а они есть!) с масштабированием Agile на сложный ландшафт организации в условиях, когда одновременно самые разные исполнители ведут разработку множества интегрируемых решений. Как на практике выстроить первые шаги, на каких принципах основываться, и чего избегать? Давайте обсудим, как вместо повышения эффективности не создать хаос!
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
Software craftsmanship фиксит проблемы AgilePavel Veinik
На 6м митапе мы подойдем к проблеме говна со стороны команды и процессов, а не со стороны технологий и архитектуры, и рассмотрим поближе, чем и как нам могут помочь принципы Software Craftsmanship. Мы увидим, что суть всех процессов - это коммуникации, а суть коммуникации - это настроенные каналы передачи информации. Мы рассмотрим, как настраивать эти каналы передачи информации, и увидим, что процессы - это отношения между людьми, прописанные на бумаге.
Мир меняется очень быстро. То, что казалось нормальным еще несколько лет назад, перестало быть таковым. Например, наши родители не считают, что работа должна приносить удовольствие. Они уверены, что работа должна приносить деньги.
Все поменялось. Теперь все уверены, что работа должна нравится. Если это не так, нужно немедленно эту работу сменить на другую, более развлекающую.
С этим можно спорить и несоглашаться, но победить это уже нельзя. Вопрос в том, можем ли мы это использовать и как это сделать?
Мы поговорим о геймификации, одном из способов этого добиться. Геймификация — это использование игровых подходов вне игрового контекста.
Вот и мы с вами посмотрим, как практики гейм дизайна использовать для улучшения процесса разработки ПО.
Вы слышали о движении #NoEstimates? Разработчики во всем мире отказываются от оценки! Не надо оценивать проекты, фичи и таски — говорят они. Это занимает много времени, да и процесс это не особо приятный.
Вам нравится эта идея? Вижу, что нет.
Вот например, как объяснить заказчику свое новое безоценочное восприятие? Хотите вы или нет, сроки придется называть! Что делать с обязательствами на спринт? А как же прозрачность? Предсказуемость?
По большому счету вы правы. Нельзя просто выкинуть оценку и все. Идея #NoEstimate в том, что можно увеличить прозрачность и предсказуемость разработки, если заменить оценку более эффективными инструментами.
Мы поговорим, что такое на самом деле #NoEstimate и чем практически можно заменить оценку.
Лилия Алексеева. Вальс Mrs. Agility и Mr. Waterfall - управление производство...ScrumTrek
Agile не развертывается водопадным методом, переход к гибким практикам также должен быть построен инкрементально. Вам не удастся перевести сразу много команд на гибкие практики. Поэтому возникает вопрос синхронизации работ agile-команд с waterfall-структурами и пересмотра всех процессов, таких как управление релизами, архитектурой, требованиями, проектами и прочих для работы в бимодальном режиме. Сложность вопроса возрастает в арифметической прогрессии в зависимости от количества команд и в геометрической — в зависимости от архитектурного и инфраструктурного ландшафтов, а также от сложившейся культуры взаимодействий. Мы расскажем о нашем опыте трансформации производственного процесса в условиях портфеля в несколько сотен проектов. На текущий момент в Agile работают более 1500 человек и 150 команд и еще около 5000 человек продолжают работать в waterfall-режиме. Как перейти от культуры контроля к культуре прозрачности? Как начать маленькими шагами двигаться в сторону гибкости, шаг за шагом увеличивая степень принимаемого риска, параллельно делая его управляемым? И, наконец, как все-таки повысить скорость без ущерба надежности, когда у вас нет права на ошибку? Ответы на эти и другие вопросы дадим в нашем рассказе.
Выступление на семинаре в Яндексе
Как -то получается, что (по большому счету) альтернативы Agile-подходам при построении эффективных процессов нет. А что делать, если Agile применить невозможно? Причин может быть множество: "неправильная" структура организации, "не те" люди, негибкие начальники и так далее.
Невозможно построить скрам? Но придумать вам свой собственный скрам никто запретить не может!
Мы рассмотрим 3 реальных кейса провала внедрения Agile и вместе обсудим, как можно было бы поступить в каждой конкретной ситуации. По каждому случаю я расскажу, что произошло в реальности.
Сергей Рогачев; Лилия Алексеева. Дизайн и запуск Agile-команд.ScrumTrek
Запуск в Agile — это одно из ключевых событий в жизни команды: от него зависит, взлетит ли Agile? Но запуск дает только 30% гарантии успеха, около 60% зависит от правильного дизайна команды. Мы расскажем, как проводить дизайн команды. Причем покажем на цифрах реального статистического исследования, как ошибки при дизайне отражаются на эффективности команд. Мы поделимся опытом, как непосредственно при запуске команды можно исправить кривой дизайн. И что делать, если нужно запустить одновременно много команд.
Николай Фабричев. Внедряем Agile. Как можно влиять на мотивацию команды при в...ScrumTrek
Внедряя Agile, мы много говорим про ценности и mindset, про особый тип мотивации. Процесс обычно строится на базе принципов мотивации 2.0 (Daniel Pink Drive) и, к сожалению, он не работает. Опыт показывает, что в головах людей Agile ценности часто не могут найти отражения в реальности. Люди воспринимают все как красивую теорию, не имеющую применимость в реальной жизни, но главное, не имеют внутренней мотивации изменяться и изменять окружение вокруг себя. И это проблема на пути внедрения Agile, потому что без желания двигаться к цели любая преграда становится непреодолимой. Давайте поговорим про мотивацию команды внедрять изменения на простом языке. Я приведу примеры, как заинтересовать людей изменяться самим и изменять свою команду
7 Способы проведения ретроспектив для анализа и улучшения процессаMagneta AI
Ретроспектива играет большую роль в развитии команд, работающих в Agile проектах. В большинстве случаев, успех проекта зависит от того, насколько команда умеет совместно выявлять проблемы и улучшать свою работу от итерации к итерации.
Мы рассмотрим различные практики проведения ретроспектив, обсудим часто возникающие вопросы в организации работы команды и коллективного принятия решения.
Энтропия растет. Так устроена вселенная. Команда или организация сначала использует Agile, и переполнена энтузиазмом. Она успешно решает свои проблемы. Но время идет и процесс перестает улучшаться. Возможно, команда выбралась в свою зону комфорта. Или улучшение процесса не так уж и нужно команде и деградация - часть закономерного процесса восстановления статус-кво?
А можно ли сделать улучшение процесса действительно непрерывным? И что для этого нужно сделать?
Мы рассмотрим в докладе особенности процесса улучшения процесса и рассмотрим, каким должен быть лидер этого процесса, его задачи и инструменты.
IT talk Spb #34 «Performance Based Hiring» Саша Зверев, сооснователь 2DiggersDataArt
О чем пойдет речь?
Performance Based Hiring — метод найма персонала, основанный на анализе фактических данных:
-кто такие «лучшие» сотрудники и кандидаты;
-концентрируемся на производительности кандидата, в противовес его навыкам;
-интервью на основе фактических данных;
-зачем нам HR?
Почему я про это говорю?
HR и IT-специалисты друг друга не понимают, и главное, даже не представляют, как договориться. И ответственность за это — на обеих сторонах.
Очень низкий уровень проблематики при разговорах об HR.
Карго-культ — делаем, как делали до нас, но почему — никто не знает, не понимает и не может объяснить.
Результат: на основе своего опыта и под большим влиянием идей Лу Адлера я рассказываю, как надо расставить акценты и какие задать друг другу вопросы, чтобы:
-преодолеть упомянутое непонимание между нанимающими менеджерами, HR и кандидатами;
-сделать процесс найма более экологичным, эффективным;
-а крутых специалистов — более доступными для разговора.
http://it-talk.dataart.ru/events/events-spb/2015/09/priglashaem-druzej-na-34-j-it-talk-v-peterburge/
Внедрение Agile на разных этапах развития компанииAskhat Urazbaev
Адизес сравнивает развитие организации с взрослением человека – от стадии ухаживания и зачатия до самой смерти. На разных этапах требуется по разному управлять компанией.
В последнее время (с приходом Lean) гибкие практики выходят на уровень управления организацией. Однако, как показывает опыт (сын ошибок трудных), тот Agile, который подходит молодой, полной надежд организации может совсем не подойти покрытой шрамами и растерявшей все свои зубы компании.
Мы поговорим о том, какие потребности в проектном управлении есть у компании на разных этапах ее развития, когда имеет смысл применять Agile, когда это опасно и рассмотрим несколько практических советов по управлению проектами.
Алексей Ионов. Agile в масштабе корпорации: как не создать хаос?ScrumTrek
Когда-то давно на заре Agile многие (и я в том числе) часто начинали разговор про внедрение проворно-гибких подходов с того, что переход на них полностью зависит от поддержки высшего менеджмента организации. Сегодня по опыту работы очень разных крупных компаний становится совершенно очевидно, что основные препятствия на пути трансформации находятся не только и не столько на уровне первых лиц. Они выходят далеко за рамки Манифеста и широко известных подходов для управления эффективными командами. Я поделюсь идеями и наработками, которые позволяют разрешать проблемы (а они есть!) с масштабированием Agile на сложный ландшафт организации в условиях, когда одновременно самые разные исполнители ведут разработку множества интегрируемых решений. Как на практике выстроить первые шаги, на каких принципах основываться, и чего избегать? Давайте обсудим, как вместо повышения эффективности не создать хаос!
Владимир Завертайлов. Выравнивание нагрузки в IT-компании: впихнуть невпихуемое.ScrumTrek
Доклад нацелен на подготовленных слушателей, руководителей проектов или директоров студий с десятком и более сотрудников, в общих чертах что-то слышавших про LEAN и ТОС. Выстройте поток единичных изделий, выравнивайте его и оптимизируйте скорость — говорит нам LEAN и производственная система Тойоты. Найдите ограничение и подчините ритму его работы все остальные звенья производственной цепи, Сбалансировать поток невозможно, говорит нам теория ограничений (ТОС). Все это очевидно работает, в примерах производства серийной продукции. Но и то и другое непонятно как применить на практике в сфере услуг. Тем более таких высоко кастомизируемых, как наша сфера — digital. Нам, директорам, больно смотреть, когда штатный сотрудник остаётся без задач, т.к. не готовы или не согласованы работы предыдущего этапа. Мы стремимся загрузить всех и максимально. Порой это приводит к тому, что мы хватаемся за огромное число проектов. А вдруг какой-то застрянет на согласовании — такой логикой руководствуемся мы. Это приводит либо к большим очередям (клиенты вынуждены ждать и ненавидеть it-шников за неповоротливость). Либо к необходимости перегружать сотрудников, а это приводит к повышенному проценту брака в их работе, и, как следствие, к дополнительной перегрузке, низкой скорости и ненависти к it-шникам со стороны клиента. Впихнуть невпихуемое и не стать студией, где считается преступлением быть «не затраханным». В этом докладе мы разберемся с вами, что можно автоматизировать для балансировки нагрузки. Что можно выбрать за единичное изделие. Как построить поток, визуализировать его, найти узкое звено и научиться предсказывать, где и когда у вас в
Software craftsmanship фиксит проблемы AgilePavel Veinik
На 6м митапе мы подойдем к проблеме говна со стороны команды и процессов, а не со стороны технологий и архитектуры, и рассмотрим поближе, чем и как нам могут помочь принципы Software Craftsmanship. Мы увидим, что суть всех процессов - это коммуникации, а суть коммуникации - это настроенные каналы передачи информации. Мы рассмотрим, как настраивать эти каналы передачи информации, и увидим, что процессы - это отношения между людьми, прописанные на бумаге.
Екатерина Иванова, Евгений Джамалов. Разработка прототипа по Agile в условиях...ScrumTrek
На реальном кейсе рассмотрим пример разработки мобильного приложения силами небольшой продуктовой команды внутри компании с Waterfall принципами управления. Расскажем, как эволюционировал продукт от эксперимента к эксперименту, и как мы в итоге пришли к его масштабной версии. Расскажем, с какими подводными камнями столкнулись и какие вызовы нам пришлось принять в ходе работы. В докладе затронем тему изменения компаний, тему внедрения новых методологий разработки и перестройки «неповоротливой» и «закостенелой» структуры компании в сторону быстрого реагирования на потребности пользователей.
Постановка и улучшение скрам процесса для группы проектов в большой компании,...viktor_bezhenar
Презентация с конференции Lviv PM Day весны 2014 года:
- Что мешает организациям начать использовать гибкие методологии и почему это сложно?
- Преобразование методологий разработки портфеля проектов к Scrum методологии с помощью ЕТС (enterprise transition community - сообщество по изменениям на предприятии):
* наш путь
* его пересечение с моделью Майка Кона и работа по модели
* обязанности и методы работы ЕТС
Agile Vector - внедрение agile разработки в РайффайзенбанкеAlexey Deryushkin
Доклад на 60 минут с пошаговым описанием процесса внедрения гибких методологий разработки в окружении, работающем по «водопаду», проблем такого точечного внедрения и их способов решений на примере нескольких связных проектов, а также влияние такого внедрения на IT банка в целом. Затрагиваются все темы, связанные с постановкой производства ПО -- от технических практик до образа мышления, на примерах из жизни. История успеха длинной в два года, которая не собирается завершаться.
Как попасть на следующий уровень карьеры и зарплаты в C#geekfamilyrussia
Есть ли потолок заработной платы? Что делать, если Вы уперлись в него. Как преодолевать уровни сопротивления и избегать в ловушек в карьере .net разработчика. Результат анализа более 6.000 резюме C# разработчиков в Москве.
Mykola Mytko — "Быть, а не казаться Agile" it-network
Николай рассказал, что же значит Agile и как правильно его внедрять.
✔️Agile — это обучение и выполнение работы через опыт.
✔️Изменения - это нормально, нужно ошибаться, делать выводы и учиться.
✔️Agile — это мышление. Есть 2 подхода к Agile: делать и быть.
✔️Попробуйте модель обучения СюХаРи.
✔️Задача Agile коучей - научить людей мыслить.
You probably know what is iteration Zero.
Everybody uses this term but a few can define it clearly. Some use it to designate a special time for building infractructure, others as an iteration for assembling a team and sharing a product vision or elaborating initial requirements. Still, you can hardly get a clear explanation how to do your iteration Zero.
We in ScrumTrek have been helping organizations to adopt Agile for more that 5 years. Our understanding of iteration Zero has evolved over time and now we understand it as a time for a team, bussiness and other stakeholders to investigate collaboratively a product that they are going to build.
Join our session to learn about our experience and practices for iteration Zero. You will see how we do product/project analysis and create product vision and backlog. We will be talking about practices for helping a team to start their first iterations and discuss how to involve stakeholders into collaborative work.
And, what is more important, how to box it into just one iteration.
What kind of team we can call a good team? Good team (incl P.O.) delivers right features to their customers. If features are wrong, or they are delivered too early you can failure your product or project.
PDA Newton has been released to the market too early and failed. Market was not ready for it. There are some other typical mistakes. For example, sometimes we are not able to understand our customer or hit wrong segment of the market.
This workshop will show how to use Innovation Games ® play with customers to understand their value, and use this information to effectively prioritize and release the feature they want and when they want.
23. Долгорочное планирование Дано: Фиксированный объем работ Фиксированный срок Вопрос: Сколько нужно ресурсов? Мы хорошо планируем толькона релиз Agile помогает рано скорректировать курс
24. Большой релиз с фиксированным объемом работ Бэклог 500+ историй Сложно оценивать Сложно расставлятьприоритеты Недостоверный прогноз
28. Новички 4 -> 12 чел Фокус на знание принципов дизайна / ООП Разный уровень подготовки Кроссфункциональность Парное программирование рулит Эксперт через 3-6 месяцев
29. Эпики Неудобно для программистов Неудобно для бизнес-аналитиков Как разбивать истории? Epic Story = Epic Fail
30. Рекомендации Понимать мотивы Разбивать по бизнес-сценариям От простого к сложному Маленькая история – хорошая история
50. Agile DB Стандартные решения не работают Миграция данных Разные environments Поддержка параллельно с разработкой Решение есть! Инкрементальный DB deploy Проблема mergeDEV <-> CONS Автоматизированные скрипты
52. Как мы построили agile? Строили 7 лет XP Начали пытаться следовать Предолели скепсис Ощутили пользу Новичков учили сразу Научились делать мелкие проектики Релиз 2-3 месяца 4-6 человек в команде
55. Перепады velocity 2-недельные итерации Время на поддержку Внутреннее тестирование Уменьшение размера историй Точный прогноз
56. Инфляция оценок Падает velocity Давление от менеджмента Соблазн завысить оценки Единая позиция команды Коммуникация Velocity vs Productivity Доверие важнее краткосрочной выгоды
