Персональные инструменты
 

Как сервисному отделу не стать бутылочным горлышком (Юля Нечаева, AgileDays-2011) — различия между версиями

Материал из CustisWiki

Перейти к: навигация, поиск
м
 
(не показано 5 промежуточных версий этого же участника)
Строка 1: Строка 1:
 
== Аннотация ==
 
== Аннотация ==
;Докладчик: [http://2011.agiledays.ru/members/profile/1024/ Юля Нечаева]
+
;Докладчик: [http://julia-nechaeva.moikrug.ru/ Юля Нечаева]
 
<blockquote>
 
<blockquote>
 
Основной идеей Agile является увеличение ценности разработки для бизнеса. Ваш Капитан.
 
Основной идеей Agile является увеличение ценности разработки для бизнеса. Ваш Капитан.
Строка 37: Строка 37:
 
== Примечания и отзывы ==
 
== Примечания и отзывы ==
 
* [http://2011.agiledays.ru/reports/view/94/ страничка доклада на сайте конференции]
 
* [http://2011.agiledays.ru/reports/view/94/ страничка доклада на сайте конференции]
* {{link-if-exists|Максим Цепков - AgileDays-2011/Как сервисному отделу не стать бутылочным горлышком}}
+
 
 +
Обсуждение доклада в блоге докладчицы + посты разъясняющие тему доклада:
 +
* http://jnechaeva.blogspot.com/2011/03/blog-post.html
 +
* http://jnechaeva.blogspot.com/2011/03/2.html
 +
 
 +
{{include-review|Максим Цепков - AgileDays-2011/Как сервисному отделу не стать бутылочным горлышком}}
  
 
<references/>
 
<references/>
  
 
[[Категория:AgileDays-2011 (наша запись)]]
 
[[Категория:AgileDays-2011 (наша запись)]]
{{feedback-appeal|AgileDays}}
+
 
 
{{replicate-from-custiswiki-to-lib}}
 
{{replicate-from-custiswiki-to-lib}}
 +
[[Категория: Тестирование (доклады)]]
 +
[[Категория: Менеджмент (доклады)]]

Текущая версия на 20:06, 10 октября 2011

Аннотация

Докладчик
Юля Нечаева

Основной идеей Agile является увеличение ценности разработки для бизнеса. Ваш Капитан.

Тестирование никогда не было созидательной службой. Если тестирование хорошее – оно уменьшает расходы бизнеса. Но дополнительное «value» в продукт тестированием привнести очень трудно.

А вот помешать – очень легко. Неграмотно построенная организация работы может сделать тестирование бутылочным горлышком в проекте, а то и в компании.

Значит, помимо поиска багов, ключевой задачей тестирования является сделать этот поиск настолько гармонично вписанным в общий процесс, чтоб не увеличивать операционные расходы.

Если тестировщики являются частью команды разработки – это просто: планируй тестирование как часть задачи на разработку – да и все. Но что делать, если отдел тестирования обслуживает несколько потоков задач? И у всех заказчиков разные процессы? И все они одинаково требовательные!

У нас получилось построить такой отдел тестирования, который принимает большинство задач принимает в работу сразу же после их постановки.

Ничего необычного, если не уточнить, что:

  • подавляющее большинство времени ребята в отделе заняты полезной работой
  • планирование практически отсутствует

Я не открою вам секреты, не расскажу про серебряные пули. Я лишь расскажу, какой микс из agile практик и принципов мы используем, чтобы быть успешным отделом тестирования. И буду рада, если это Вам пригодится в работе.

Видео


Для этого доклада нужен подкаст (аудиозапись)?

  •  Да, многое понятно и без видео части, есть смысл его прослушать.
  •  Нет, аудиозапись бесполезна (не понять без видео или вообще мало смысла в докладе).

Презентация


Примечания и отзывы

Обсуждение доклада в блоге докладчицы + посты разъясняющие тему доклада:

  • Как сервисному отделу не стать бутылочным горлышком (Юля Нечаева, AgileDays-2011)

Слушал частично. Юля возглавляет не слишком давно созданный отдел тестирования, общий для нескольких команд разработки, которые живут каждая в своем ритме. Судя по всему, до этого были большие проблемы с качеством, которые сейчас их отдел решает. А она делилась опытом организации этого процесса. К сожалению, в докладе было много о проблемах, но не так много о решениях. Кроме того, относительно четкое противопоставление «мы-они» — про разработчиков и тестеров, а не про «мы вместе». И, соответственно, договоренности, как у сторон, которым надо отстроить приемлемые правила взаимодействия в условиях противоречащих требований, а сотрудничество для выпуска продукта — оно где-то за рамками. Наверное, оно есть, но в докладе его видно не было.

Из забавного. С точки зрения разработчика, хороший тестер должен заранее знать не только время тестирования, но и количество найденых багов — чтобы разработчики могли заранее запланировать их исправление. И не проверяет повторно — ведь исправили наверняка хорошо.

Из позитивных практик — выявлять те тесты, где работа наиболее неустойчива и начинать с них. Например, web тестировать под chrome.



Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Как сервисному отделу не стать бутылочным горлышком (Юля Нечаева, AgileDays-2011)»