Your SlideShare is downloading. ×
  • Like
как инженерные практики помогают экономить бизнесу
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

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

  • 117 views
Published

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
117
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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