Как инженерные практики помогают экономить бизнесу

Хотите начать работать по TDD, но команда упирается? Не удается убедить всех, что DevOps - самая лучшая культура? Боретесь за права Selenium на проекте? Тогда этот доклад для вас. Это и многое другое внутри.

Transcript

1. Как инженерные практики помогают экономить бизнесу Ребров Андрей
3. О чем этот доклад
5. Для кого этот доклад
6. Если вы… •  dev (qa, ops) и хотите что-то внедрить •  менеджер и вам постоянно что-то «впаривают» •  коуч/консультант и никак не можете объяснить, что команде нужно что-то внедрить …то вы пришли по адресу!
7. Пришло время историй
8. История 1. Про Selenium •  Есть классный фреймворк – Selenium! Давайте его использовать у нас! •  У нас есть проработанная система на TestComplete. •  TestComplete - $#$&#! •  …
10. Don`t! •  Никогда не говори, что текущие наработки – ерунда •  Новизна технологии – не аргумент •  То, что технологию используют «вот эти ребята» не аргумент, даже если это Google
11. Как сработало •  Привлекай «ручных» тестировщиков на свою сторону – они твои заказчики •  Делай демо своих наработок как можно чаще – так ты покажешь, что фреймворк прост в использовании •  Во время демо создай позитивную обстановку – принеси чай и печеньки •  Тренируйся в обучении своему фреймворку
12. Как продали бизнесу •  Удешевляем разработку, так как быстрее находим баги •  Долгое время не понадобятся новые тестировщики – есть автотесты •  Можем брать больше задач в итерацию •  Можем быстрее выходить в релиз
13. Новые безопасны и дают преимущество
14. История 2. Про TDD • Ребята, вам нужно TDD – оно рулит! • Но нам придется переписать весь наш проект, чтобы можно было тестировать!!! • Ну и что, зато у вас будут тесты! • …
16. Don`t! • TDD ради тестов и TDD – самый глупый аргумент • TDD ради всеобщего блага – еще более глупый аргумент • То, что TDD используют «вот эти ребята» - ну вы поняли…
17. Как сработало • Просвещение в виде видео • Личный пример – сделал, засек временя, не нашел багов, повторил • Conding Dojo – пробовать что-то новое самому _ВСЕГДА_ страшно, лучше бояться вместе
18. Как продали бизнесу Партизанский TDD: • Применяем в течении 3-4 недель • Показываем, что ситуация (метрики по SLA, баги, wtf/sec) улучшилась • фиксируем договоренности
19. TDD позволяет писать код эффективно
20. История 3. Про Refactoring • Давайте отрефакторим вон тот модуль! • Зачем? Он же работает! • Но там спагетти-код и масса нарушений в коде • …
22. Don`t! •  Когда ты говоришь о рефакторинге – ты оскорбляешь чей-то код, будь готов к сопротивлению •  Переписать, потому что так написано в книге – очередной глупый аргумент •  Сразу говорю, убеждать, что на рефакторинг нужен сразу месяц не стоит
23. Как сработало •  Визуализация проблем – поставь Sonar, менеджеров пугают цифры •  Рассказать про технический долг и как он влияет в перспективе •  Подготовить план рефакторинга с объяснением почему в определенный момент времени мы переделываем именно этот код
24. Как продали бизнесу •  Показать график •  Рассказать, что делают с должниками =)
25. Рефакторинг позволяет не бояться долгов
26. История 4. Про автоматизацию • Дима, давай автоматизируем тестирование! • И зачем нам это? • Ну, мы сможем заниматься интересными задачами и будет круто! • …
28. Don`t! •  Автоматизация ради автоматизации – как TDD ради TDD, а это мы уже прошли •  Не говори, что автоматизация ничего не стоит – будешь выглядеть дураком •  Запомни! Не бывает бесплатных инструментов, как минимум они стоят твое рабочее время •  Не стоит бежать к лиду, как только прочитал про инструмент, попробуй сам
29. Как сработало •  Показать концепт как оно работает •  Знать о преимуществах и недостатках •  Показать, разные варианты использования – чем больше выбор, тем больше вероятность, что хоть один подойдет
30. Как продали бизнесу • Посчитать ROI автоматизации • Показать, что поддержка стоит дешевле, чем отдельный человек, который будет делать все вручную • Показать стоимость ОШИБКИ, которую может допустить такой человек
31. Хорошие роботы спасут в беде
32. История 5. Про Feature Toggling и ветки • Нужно перестать делать ветки под каждую новую ветку! • Почему? • Так завещал Martin Fowler! • …
34. Don`t! •  Не все знают, кто такой Фаулер =) •  Прочти Фаулера сначала сам •  Не стоит кидаться терминами cherry pick, feature branch и так далее – вы будете выглядеть как колдун вуду •  Говорить, что «feature toggle это как if, но не if, а по другому» тоже не стоит
35. Как сработало •  Экономим время на merge`ах веток – теперь их нет •  У всех разработчиков всегда последний код – все видят картину целиком •  В разы проще становится настройка Continuous Integration (о нем ниже)
36. Как продали бизнесу • Теперь в любой момент мы можем выключить тот или иной элемент функционала – у нас есть набор конфигов для этого
37. Не плодим сущностей без необходимости
38. История 6. Про Continuous Integration •  Нам срочно нужен Continuous Integration, чтобы мы знали, что ничего не сломали! •  А почему ты не проверяешь на своем компьютере? •  А зачем? •  …
40. Don`t! •  Никогда, еще раз, никогда не говорите, что CI будет находить ваши ошибки – вы выставляете себя в плохом свете •  CI не просто штука, которая запускает тесты – если ваш менеджер технарь, ему не стоит такое говорить
41. Как сработало • CI позволяет делать регрессионное тестирование на уровне кода – снимаем нагрузку с тестировщиков • Можем автоматизировать наши процессы (см. пункт 4) • Не требует поддержки
42. Как продали бизнесу • Так же, как автоматизацию • Сказали, что это путь к непрерывной поставке (будет дальше)
43. CI заботится о стабильности в коде
44. История 7. Про DevOps •  Давайте настроим Nagios, Chef, Graphite и Logstash и станем DevOps`ами! •  А как это поможет? •  Ну мы просто будем делать все быстрее •  …
46. Don`t! •  Не продавай инструменты – проблему процессов ими не решишь, а фейл за тобой останется •  Построение DevOps процесс долгий – не говори, что за неделю все станет здорово •  Не решай проблему админов за них самих – они обидятся
47. Как сработало •  Визуализация процесса – все увидят, что творится что-то не ладное и появляется поддержка всей команды •  «Затуши пожар» в течении недели - быстрая победа добавляет очков •  Как обычно, показать прототипы не помешает
48. Как продали бизнесу •  Процесс поставки становится прозрачным и управляемым •  Поставка делается за пару часов, а не дней •  Мы не потеряем данные пользователей •  Мы сможем стать «фабрикой по производству фич»
49. DevOps позволяет нам быть первыми на рынке
50. В качестве эпилога
52. Twitter @andrebrov E-mail arebrov@scrumtrek.ru Skype rebrov.andrey Вопросы?