Agile2014 Orlando обзор конференции
•Télécharger en tant que PPTX, PDF•
0 j'aime•168 vues
Мысли и выводы, подслушанные мной на конференции Agile2014 в Orlando
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Agile2014 Orlando обзор конференции
Similaire à Agile2014 Orlando обзор конференции (20)
Agile2014 Orlando обзор конференции
- 1. Agile2014 Orlando Обзор конференции и посещенных мной докладов
- 2. Впечатления Они реально старше! Они действительно танцуют! Преподаватели тоже делают это! А еще - DevOps -
- 3. День Первый Microsoft - Фидбек! - Насколько мы ушли не туда? - Definition Of Done надо прописывать - Планируйте! В том числе и техдолг. - Автоматизируйте выкладку
- 4. JohnDeere Приложение в комбайне Unit Tests - Selenium - Acceptance QA test - Release Developer Mindset - Все на продакшн! Много тестов Никакого “QA найдёт для меня баги” Поломал билд? Расстрелять! Jenkins & Sonar - не изобретайте велосипеды, все уже есть в openSource 14 минут на билд - полный цикл Маленькие изменения!
- 5. JohnDeere Маленькие изменения - маленькие проблемы FeatureToggles Бранч на фичу Дисциплина и железо Баги или фичи? Приоритет! Leo M. Marvin Baby Steps - почитать
- 6. BestGirl about Kanban А сколько у вас проектов? Squadification Block stuff in progress Приоритезируйте! Definition of Done! Working on a right stuff
- 8. Drunk under streetlight А зачем ты тут ключи ищешь? Много метрик - много шума
- 9. Drunk under streetlight Метрики нужны чтобы принимать решения Лучшие метрики в авто Метрики нужны не для людей наверху. Оставляйте их предельно простыми. Impersonal, Non-Judgemental Обязательно посмотреть презентацию!
- 10. Flow - Haakan Forss Niklas Modig - This is Lean Переключитесь с работника на процесс! Red, Yellow, Green кирпичики. Как же нам повысить эффективность? Прекратите искать локальные проблемы! Маленькие фичи! Три закона: Литтла, Ботлнек, Вариативности. Remove Iterations! Avoid Swarming on work Экспериментируйте! 50% не дает результата.
- 12. Continuous Delivery Закон Conway Делайте маленькие модули Архитектура! Legacy Code Избегайте Ада зависимостей! Микросервисы (api! rest, amqp) Postel’s law Архитектура создаётся для билда, для запуска и для Деплоя Hexagonal Architecture, Strangler Pattern Michael Nygard, Martin Fowler
- 13. Continuous Delivery Evolve your architecture! 1. Delay your decisions until the last responsible moment: Don’t make all your decisions all at once, or all up front. Care about the priorities. Don’t be an enterprise architect! One of the important things to think about are what your system shouldn’t do. 2. Architect for evolvability. Use metrics on your code. Use tools like Sonar, New Relic and the like to see where you are going wrong. 3. Postel’s Law: “Be conservative in what you send, be liberal in what you accept.” (and validate the hell out of what you get) 4. Architect for testability. Don’t put code in stupid spaces, like your database. Write test harnesses that act like real users. 5. Conway’s Law. You can’t fight it. You have to make sure your org chart looks like what you want to ship.
- 14. Mentoring Это не обучение Оставьте своё Я Людям не нужны менеджеры Вспомните своих менторов. Какие они? Сделайте так, чтобы они знали As a leader I want to help ____ So that <WE BOTH LEARN AND GROW>
- 15. Self-Selecting teams Маленькие команды Пусть сами выбирают Страхи не проявляются Принципы работают Рискуйте! Отряд должен быть самостоятельным Мы можем доверять людям, команда может нанимать людей. Проекты всегда развиваются nomad8.com
- 16. Development & Operations Improving flow is primary objective of DevOps It’s not about IF it’s about When Это взаимодействие с бизнесом Дисциплина и никакого нытья Амазон - вы сделали ПО вы его и запускаете! Компании проигрывают Не думайте над маржинальностью Инновации, майндсет и мидлМенеджмент
- 17. DevOps Уровни развития компании Если мы возьмем всех старичков, то получим старую систему Текущая инфраструктура многих компаний не Agile LeanThinking - James Womack; Lean - Mary Popper?; FLOW - Donald Reinerdsen История GM - почитать самостоятельно
- 18. MAXOS - Andy Singleton Маленькие быстрые ветки Частые релизы Облака Скрам? В баню! Юнит тесты, код ревью... Координация Integration Test Environment SAFe Matrix of Services Breaking the scale barrier
Notes de l'éditeur
- Они намного старше нас, толи индустрия такая, толи менталитет другой и они не стараются как можно быстрее стать начальником...
- Общайтесь с кастомерами! Программа “Крутые кастомеры”, звоним спрашиваем всё ли им нравится, что хотят улучшить и тп! Фидбек блеать! На доске фичи и точками помечаем насколько он нам надо и насколько мы ушли не туда. DOD - написан тест, надо это прописать. Планируйте большим куском (полтора года напр), потом меньшим (квартал) и еще меньшим. Но планируйте. Автоматизируйте выкладку, вы не должны о ней думать. Планируйте техДолг, разбивайте на мелкие задачки. http://www.youtube.com/watch?v=SDjtBnb-8co
- Build & Unit tests - Selenium - Acceptance QA test - Release. Нам нужны маленькие изменения, чтобы быстрее и безболезненнее их выкладывать. Никакого “QA найдёт для меня баги” Надо работать с продакшеном всем, чтобы понимали что черт возьми если я это сделаю плохо, то продакшн ляжет. Тесты, тесты, тесты - нам нужно много тестов. Jenkins - не изобретайте своих велосипедов. 14 минут на билд. Если чувак сломал билд, то берем пушку и расстреливаем его. А еще используем гитхаб. Обязательно сообщать, что кто то сломал билд, сирену придумать, как она будет работать и тп. Leo M. Marvin Baby Steps. - почитать! Стандартное - выкладывайте маленькие фичи. Бранч на фичу! Дисциплина и железо - залог хорошего фичаБранчинга. ФичеТоглс. Sonar - codecoverage. Баги или фичи - это не важно! Важен приоритет.
- Build & Unit tests - Selenium - Acceptance QA test - Release. Нам нужны маленькие изменения, чтобы быстрее и безболезненнее их выкладывать. Никакого “QA найдёт для меня баги” Надо работать с продакшеном всем, чтобы понимали что черт возьми если я это сделаю плохо, то продакшн ляжет. Тесты, тесты, тесты - нам нужно много тестов. Jenkins - не изобретайте своих велосипедов. 14 минут на билд. Если чувак сломал билд, то берем пушку и расстреливаем его. А еще используем гитхаб. Обязательно сообщать, что кто то сломал билд, сирену придумать, как она будет работать и тп. Leo M. Marvin Baby Steps. - почитать! Стандартное - выкладывайте маленькие фичи. Бранч на фичу! Дисциплина и железо - залог хорошего фичаБранчинга. ФичеТоглс. Sonar - codecoverage. Баги или фичи - это не важно! Важен приоритет.
- А сколько у вас реально проектов? Это нужно знать, рекомендует наложить это все на доску и посмотреть сколько их, так проще. Маленькие стабильные команды. Block stuff in progress, with tags. Приоритезируйте - слева то что наприоритезировали, справа наша работа и мы видим не соответствие. ДОД твою ж мать! Определить правила, которые соблюдаются при выкладке на продакшн (отослали письмо?) Working on a right stuff! Выбирайте проекты, над которым работать тщательнее!
- А ты зачем тут ключи ищешь - здесь света больше. Да мы просто сами ищем обычно ключи там где больше света. Избегайте большого количества метрик - это слишком много шума.
- Нам нужны метрики чтобы мониторить продвижение к цели; чтобы показать когда появляются проблемы; чтобы помочь в диагнозе! Всё остальное шум Лучшие метрики - это у вас в автомобиле “Скоро у вас закончится бензин”, "не надо так лететь” еtc… Метрики нужны не для людей наверху, а для людей внизу! Мы часто задаём правильные вопросы, но не в том контексте. Не манагер должен быть живым, а команда! Потому что команда это и есть проект! Оставляйте это предельно тупым. localized to any entity no smaller than a team not used directly to punish or reward the subject entity
- Все в мыле - поток замедляется. Все не очень загружены - поток ускоряется. Цена - это не работник, а отсроенный процесс. LT, Цифры эффективности потока. Не загружены - это не значит что люди ничего не делают, они просто занимаются менее приоритетной работой и могут её бросить в любой момент. Эстимейшн не даёт представления о том, когда задача будет закрыта, потому что там дофигища еще кирпичей красных. Чтобы выставить дату, когда задача будет сделана, ориентируйтесь на историю! Фокусируйтесь на красных кирпичиках. Потом на жёлтых (слишком большой бэклог и тп) Повышаем эффективность процесса, только сначала снижая нагрузку на работников! Потом повышаем эффективность процесса и постепенно повышаем нагрузку на воркеров Прекратите искать локальные проблемы! Ищите глобальные Переключитесь с больших задач с большим эст на маленькие и быстрые. Маленькие фичи, выкладывайтесь чаще, избегайте проектов! маленькую задачку с тестом. Возьмите и посмотрите на блокеры! Что их вызывает? Как их убрать. Чем вариативность системы, тем медленнее система. Неравномерный поток работы, большие куски работы, swarming on work.
- Система есть отражение связей в компании. Если систему разрабатывабют 3 больших команды, то и с-ма будет состоять из 3х больших модулей. Не надо делать больших модулей! Делайте маленькие. Архитектура - это то, что сложно поменять. Архитектор он думает не только о доме, но и больше о всей инфраструктуре вокруг, о дорогах, что делать если не получится, если пойдёт не так. Система - есть отражение процессов в компании! Если у вас в компании много проблем, то и в системе их будет много! Компания должна быть легкой и гибкой, чтобы создавать хорошие системы и CD. Все стремятся к легаси коду, его никто не любит, но чорт возьми он работает и работает хорошо! Прекратите трогать легаси код! Чорт с ним, пусть лежит. Ваше приложение должно иметь Умные модули и Тупые связи (простые). Сервисы должны иметь АПИ типа Rest, AMQP Золотое правило: Можете ли вы выложить часть без изменения других частей системы безболезненно? Закон: Будь консервативен в том, что посылаешь и либерален в том что принимаешь! Hexagon: это когда ядро окружено адаптерами и через адаптеры идёт связь со всеми компонентами. Strangler - это когда мы старую систему небольшими модулями окружаем и таким образом заменяем старый код.
- When you design your architecture in the beginning of your project, the irony is that you don’t know about your system at the beginning.
- Менторство - это не обучение, это выше - хай тач. Это долговременные отношения. Оставьте своё я за дверью, весь свой багаж за дверью, проблемы и тп. Людям не нужным менеджеры, продуктам нужны, людям нужны лидеры. Менторы умеют слушать! Впустите их в свой дом, вы должны быть в очень хороших отношениях. Порадуйтесь когда радуется он. Вы должны быть иницитивны чтобы помочь. Предложите свои услуги, сделайте так чтобы они знали! Ментор может превзойти лидера! Минимум 12 месяцев надо для того чтобы чтобы настроить отношения с ментором. Цель: научить их быть ментором!
- Маленькие команды. Когда вы образуете новую берите одного из самых сильных спецов и окружайте его новичками. Пусть люди сами выбирают свои команды. Принципы работают! Говорите о принципах в работе. Если вы хотите сделать что то хорошее, перестаньте спрашивать разрешения! Рискуйте! Оно стоит того. Отряд должен быть быть самостоятельным, он должен делать работу от начала до конца. 3 - 7 человек, сидящих рядом. Причем девелоперов 1 - 2 Мы можем доверять людям, команда может нанимать людей. И они лучше срабатываются друг с другом. nomad8.com Чем больше юзерСторис идёт в продакшн, тем лучше девелоперы. Мы смотрим по динамике. Гильдии и отряды! Проекты всегда развиваются, просто в приоритете падают, поэтому мы их передаём другой команде. Просто менее развиваем, потом переключаемся на него и развиваем. Т.е. получаются продукты такие как проекты. Накапливают идеи потом делаем лучшее.
- “If there’s anything all horses hate, it’s hearing stories about unicorns.” – Chris Li@le Девелопмент И Оперэйшнс - это взаимодействие с бизнесом, если бизнес не такой гибкий и не готов к этому взаимодействию, то это лишь локальная оптимизация. Амазон говорит - вы сделали ПО вы его и запускаете! Так быстрее Компании проигрывают не потому что они плохо делают вещи, но потому что они продолжают делать вещи лучше, которые привели их к росту! Размышления над маржинальностью приводят к тому что вы не будете делать то, что следовало бы делать. Инновации, а точнее майндСет должны идти свыше! МиддлМенеджмент является безусловно ключевой прослойкой в компании, но их инициатива умирает без поддержки сверху. Инновации всегда будут проходить тяжело, всегда будут люди, которые будут говорить, ооо не это тяжело, давай вернёмся назад.
- Первый уровень - The Output - Tiger Teams, Special Teams, Fires, On-demand Второй уровень - The Process - Scrum, Kanban, ITIL etc Третий уровень - метрики, награды, менеджемент и тп. Четвертый уровень - майндсет! Поведение, культура и тп. Мы обычно идём с 1 до 4, а надо идти наоборт с 4! Преданные команды, они должны состоять из старичков и новичков. Если мы возьмём старичков всех, то мы получим что система будет той же самой что и старая. Нужно новых брать! Одного старого, двух новых. Текущая инфраструктура многих компаний нифига не Agile! А она должна быть более гибкой, чтобы переходить на следующий уровень. Если люди говорят, что они не хотят быть админами или еще там что то, то пусть зарабатывают деньги в другом месте.
- Закомитить как можно быстрее! Это снижаетколичество конфликтов. Параллельный билд! Маленькие быстрые ветки. Частые релизы! Очень частые релизы. Чем чаще тем лучше, тем быстрее мы улучшаемся. Пачки - непрерывная выкладка Требования - в Юзер Стори Мегатренд - мы идём в облака! Скрам в баню! От идеи до выкладки 48 часов! Каждая команда релизится когда готова. Сотни релизов в день Обязательно юнитТесты, кодРевью. Это определенные девелоперы, которые способны на такое! Координация без больших митингов. Машина заменяет человека в управлении. КодРевью автоматизировать! Хуки гита в помощь Интегрейшн тест инвайронмент! Нужно убирать тестера как человека это долго! Нужно быстрее. 1 тестер на 10 девелоперов Интегрейшн тест инвайронмент! Нужно убирать тестера как человека это долго! Нужно быстрее. SAFe and MAXOS 1 тестер на 10 девелоперов SAFe - Scaled Agile Framework