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

468 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
468
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

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

×