Роль тестировщика в Lean

Светлана Федянина, Softline

О докладчике

• в прошлом web-developer, scrum master• в настоящем – PM / Product Owner

План доклада

1. Бережливое производство

План доклада

1. Бережливое производство2. Связь тестирования и бережливого

подхода

План доклада

1. Бережливое производство2. Связь тестирования и бережливого

подхода3. Организация бережливого

производства на основе систематизированного подхода к тестированию

Цель бережливого подхода

Минимизация издержек производства

Как достигаем цель

Минимизация издержек производства

эффективность рабочих процессов

долгосрочные перспективы

ценность для потребителя

Ценность для потребителя

Истоки Lean

История

1927 – автоматизация текстильного производства

История

1927 – автоматизация текстильного производства

1936 – выпуск первого автомобиля

История

1927 – автоматизация текстильного производства

1936 – выпуск первого автомобиля

1945 – план «догнать Америку»

История

1927 – автоматизация текстильного производства

1936 – выпуск первого автомобиля

1945 – план «догнать Америку»

1962 – принятие производственной системы Toyota (TPS)

История

1927 – автоматизация текстильного производства

1936 – выпуск первого автомобиля

1945 – план «догнать Америку»

1962 – принятие производственной системы Toyota (TPS)

1996 – создание модели Prius за 15 мес.

История

1927 – автоматизация текстильного производства

1936 – выпуск первого автомобиля

1945 – план «догнать Америку»

1962 – принятие производственной системы Toyota (TPS)

1996 – создание модели Prius за 15 мес.

2002 – Lexus имеет самый высокий спрос в США среди дорогих машин

История

1927 – автоматизация текстильного производства

1936 – выпуск первого автомобиля

1945 – план «догнать Америку»

1962 – принятие производственной системы Toyota (TPS)

1996 – создание модели Prius за 15 мес.

2002 – Lexus имеет самый высокий спрос в США среди дорогих машин

2007-2008 - крупейшая автомобильная компания мира

Принципы Lean в разработке ПО

1. Ликвидировать потери

- незавершенная работа

- изменение требований- избыточная функциональность

2. Встраивать качество- build quality into the code(тестирование кода после его создания)- делаем сразу правильно- минимальный код

3. Создавать знание- обратная связь- ежедневный выпуск сборок

4. Позднее принятие решений

- «Я всегда полагал, что при подготовке к

сражению планы бесполезны, однако планирование необходимо»

Д. Эйзенхауэр

5. Доставлять быстро

6. Уважать людей

7. Оптимизировать целое

Эффект домино

Минимизация потерь

1.Частично выполненная работа

1.Частично выполненная работа

- делим работу на небольшие этапы- участвуем в обсуждениях с аналитиками- совершенствуем процесс планирования- определяем критерий готовности

2. Избыточные функциональные возможности

2. Избыточные функциональные возможности

- список требований по приоритетам- уточнять у заказчика, что для него важно

3. Повторное приобретение знаний

3. Повторное приобретение знаний

- кроссфункциональная команда- проведение семинаров / вебинаров

4. Передача работы

- сократить такие случаи - документация:

mind maps, диаграммы, чек листы

5. Переключение между задачами

- ресурсы для ТП- задачи по приоритетам

6. Задержки

- короткие итерации- обратная связь

7. ДефектыВЫЯВЛЕНИЕ

ПРЕДОТВРАЩЕНИЕ

- smoke тесты проверяет разработчик- TDD, code review- функциональные тесты

Методы

Не играем в пинг-понгЦель: smoke tests проводит разработчик

Диаграмма ПаретоЦель: выявляем дефекты

1. Определяем список задач

Диаграмма Парето2. Определяем процент дефектов

Диаграмма Парето3. Функционал с 80% дефектов

0,00

20,00

40,00

60,00

80,00

100,00

120,00

Мас

тер

за

каза

Ко

рзи

на

по

льз

ов

ател

я

Оп

лат

а за

каза

Ли

чны

й

каб

ин

ет

Ад

ми

ни

стр

ати

вн

ый

…

Кат

ало

г

Си

нхр

он

иза

ци

я

XM

L д

ля

пар

тнер

ов

Вы

год

ны

е п

ред

л…

ТОП

10

0

Но

вост

и

Рас

сыл

ки

Бан

нер

ы

ПроцентСумма

За распространение знаний по данному методу спасибо тестировщику Softline М. Обложихину.

5 почемуТестировщик:

-определяет дефект для анализа

(баг аналитики, разработки)

- после исправления бага проводим анализ

5 почемуСхема анализа:

1. Вопрос: Почему возник дефект?

2. Ответ 1.

3. Вопрос: Почему на ответ 1.

5 почему выясняют первопричину возникновения дефекта

5 почемуАналитика

Проблема:

Неверная реализация заказанного функционала

Work In ProgressЦель:- отслеживаем количество задач в работе- превышение лимита – тушим пожар!

VSM

1 день

15 мин 2-3 ч 1 день 2-3 ч

аналитик отдел аутсорсинг отдел

маркетинга маркетинга

Эффективность ~ 50%

Цель: диагностика эффективности процессовПример: взаимодействие с дизайнером,

заявка на дизайн

Заявка на макет

Заявка на макет

ВыполнениеПередача

на верстку

Итоги1. Lean для минимизации потерь

бизнеса2. Lean для повышения качества3. Lean для профессиональной

состоятельности специалистов4. Learn Lean ;)

Спасибо за внимание!

Вопросы

Светлана Федянина

SvetlanaF@softline.ru

http://twitter.com/Fedyanina

http://fedyanina.blogspot.com/