• Like
Test Driven Development как инструмент уменьшения кадровых рисков
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Test Driven Development как инструмент уменьшения кадровых рисков

  • 644 views
Published

Как мы все знаем, одним из ключевых факторов, определяющих успех проекта по разработке программного обеспечения, является команда реализующая проект. В случае если команда фиксируется на весь срок …

Как мы все знаем, одним из ключевых факторов, определяющих успех проекта по разработке программного обеспечения, является команда реализующая проект. В случае если команда фиксируется на весь срок проекта, никто не болеет, все работают в одно и то же время, то проблем никаких не возникает. Но в реальности, команда меняется походу проекту, в проект приходят новые люди, ключевые участники проекта уходят в самый неожиданный момент, нередки случаи, когда на время надо срочно заменить выбывшего члена команды.

Ввод нового человека в проект — это всегда риски, риски, того, что у человека окажется недостаточно квалификации, риск внесения ошибок вследствие плохого знакомства с проектом. Неожиданное отсутствие члена команды проекта может, как минимум, привести к задержке сроков, а в случае, если другие не знакомы с его фронтом работ, то возможен и крах проекта. Незаменимость членов команды, введение нового человека в проект, завышенные ожидания от разработчиков - острейшие проблемы во многих проектах по разработке ПО, а особенно сильно эти проблемы проявляются на крупных проектах, где фиксировать состав команды и избежать всех неожиданностей физически невозможно.

Существенно снизить все выше перечисленные риски возможно при правильном использовании практики Test Driven Development (TDD). TDD — это техника разработки программного обеспечения, которая предполагает активное использование модульных тестов (unit-тестов), что делает их центральной частью дизайна системы. Разработка посредством тестирования при грамотном проектировании обеспечивает не только высокое качество ПО, но и стимулирует к созданию слабосвязанной архитектуры приложения. Более того, хорошо изолированными частями системы являются классы, т. е. фактически минимально возможный элемент системы. Слабая связность системы и хорошая изолированность ее частей, позволяют разработчикам быть уверенными, что их исправления или изменения будут локальными и не приведут к падению всей системы.

Хорошее покрытие тестами, а также архитектура приложения, к которой провоцирует использование TDD, обеспечивает не только качество программного обеспечения и хорошую самодокументируемость кода, но и позволяет быть у

Published in Technology , Business
  • 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
644
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
7
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. TDD как инструмент уменьшения кадровых рисков
    Гребнев Николай
  • 2. Содержание
    Кадровые риски
    Условия задачи
    Test Driven Development
    Факторы кадрового риска
    Как и почему?
    Что, где, когда и сколько?
    Итоги
  • 3. Кадровые риски
  • 4. Кадры решают все
    И.В. Сталин
  • 5.
  • 6.
  • 7.
  • 8.
  • 9.
  • 10. Риски
    Незаменимый разработчик
    «Не знал исломал»
    Квалификация ниже ожидаемой
    Обучение новых сотрудников
  • 11. Условия задачи
  • 12. Команда
    Билл Гейтс
    Мартин Фаулер
    Джеффри Рихтер
    Андерс Хейлсберг
  • 13. Мечта руководителя
  • 14. Еще одна мечта
  • 15. Реальность
  • 16. Отпуск
    Проект
  • 17. Смена сотрудника
    Проект
  • 18. Новый сотрудник
    Проект
  • 19. Test Driven Development
  • 20. Test Driven Development
    — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест. (Wikipedia)
  • 21. TDD
    Тесты не прошли
    Написать тест
    Написать реализацию
    Запустить тесты
    Все тесты проходят
  • 22. TDD – unit-тестывперед!
  • 23. Unit-тестирование
    Тестируем:
    Класс
    Поведение
    Взаимодействие
    Одновременно тестируем только один класс
  • 24. Факторы кадрового риска
  • 25. Причины
    Сильносвязная архитектура
    Позднее обнаружение ошибок
    Плохая документированность
  • 26. Сильносвязная архитектура
  • 27. Правки исходного кода ведут к непредсказуемым последствиям
    Ошибки
    Ошибки
    Изменения
  • 28. Держать все в голове
  • 29. Цена ошибки
    Разработка
    Тестирование
    Эксплуатация
  • 30. Тестирование
  • 31. Эксплуатация
  • 32. Разработка
    Тестирование
    Эксплуатация
  • 33. Отсутствие документации
    Документация устаревает сразу после своего написания
    Никто не поддерживает актуальность документации
    Зачастую вообще отсутствует
  • 34. Как и почему
  • 35. Тестируем
    Класс
    Поведение
    Взаимодействие
  • 36. Одновременно тестируем только один класс
  • 37. Зависимость
  • 38. Inversion of Control
  • 39. Декомпозиция
  • 40. Локализация ошибок
    Ошибки
    Изменения
  • 41. Раннее обнаружение ошибок
    Тесты запускаются:
    Регулярно во время разработки
    До окончания этапа разработки
  • 42. Раннее обнаружение ошибок
    Разработка
    Тестирование
    Эксплуатация
  • 43. Документация
    Всегда актуальна
    Автоматическая проверка соответствия спецификациям
  • 44. Что, где, когда и сколько
  • 45. Что?
    Высокое качество конечного продукта
    Хороший дизайн кода
    Уверенность при модификации
    Снижение рисков от незаменимых и неопытных разработчиков
  • 46. Где?
    Длительные проекты
    Высокие требования к качеству
    Опытная команда (есть опыт использования TDD)
  • 47. Когда?
    С начала проекта
    На изолированных участках в существующем проекте
  • 48. Сколько?
    Нет опыта применения TDD:
    Дорого
    Есть опыт использования TDD:
    Тратит время на написании теста
    Экономит на отладке и сопровождении
  • 49. Подводим итоги
  • 50. Вспомним риски
    Незаменимый разработчик
    «Не знал и сломал»
    Квалификация ниже ожидаемой
    Обучение новых сотрудников
  • 51. TDD
    Любого человека возможно заменить:
    Система хорошо документирована
    Слабая связность
    Покрытие тестами
  • 52. TDD
    Любые правки исходного кода безопасны:
    Высокая изолированность классов
    Обнаружение ошибок на этапе разработки
    Жесткое соблюдение контракта класса
  • 53. TDD
    Обучение на «боевых» задачах
    Скорость обучения возрастает
    Слабая связность
    Формально документированное взаимодействиев системе
  • 54. СПАСИБО
    Докладчик: Гребнев Николай
    e-mail: ngrebnev@gmail.com