Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
Core PD создатель Mind Map: Core PD

1. Культура (ЧТО от нас ОЖИДАЮТ)

1.1. Feature Toggling любой разрабатываемой функциональности до переноса в ветку current release.

1.2. Остановка разработки и исправление ошибок, если не собирается сборка.

1.3. Каждый день - 100% зеленые тесты .

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

1.5. Мы НЕ соглашаемся "индусить"

2. CONTINUOUS IMPROVEMENT

2.1. Refinement

2.1.1. Некачественный рефайнмент

2.1.1.1. Непрогнозируемое время выполнения задач

2.1.2. Refinement - причина всего

2.1.3. Нет критериев, когда надо остановиться в refinement -е

2.1.4. Его одновременно и мало и много

2.1.5. Какой критерий качества рефайна?

2.2. Release

2.2.1. Не идеальный CI

2.2.1.1. Во время релиза сложно собрать сборку

2.2.2. Временные потери на релизы

2.2.3. Не учитываем в Спринте время на тестирование RC

2.2.4. Тестирование RC

2.3. Знание своего функционала (Серые зоны)

2.3.1. Нет базы знаний по архитектуре

2.3.2. Не можем понять, как работает функционал

2.3.3. Не можем понять, как должен работать функционал

2.4. Нет долгосрочных планов улучшения и развития команды. Нет целей у Команды.

2.5. Legacy Code

2.5.1. Отсутствует рефакторинг

2.5.2. Дедлайны приводят к тех.долгу

2.5.3. Боль = ESQ Боль = metascript

2.5.3.1. Слабое покрытие старого кода тестами

2.5.4. Сильная связанность кода

2.5.4.1. Что именно?

2.5.5. Нарушается принцип Single в SOLID

2.5.6. Автотесты (Какое покрытие? Кол-во и кач-во integration test -ов)

2.6. Реализация Improvement

2.6.1. Пока нет свободного времени (а его нет всегда) или приритета или четко выделенного времени на это, improvement-ы не выполняются

2.6.2. Ожидаемая бесплатность решений

2.6.3. Не хватает времени на поддержку, реализацию, улучшения

2.6.4. Отсутствует процесс автоматизации ручного тестирования

2.6.5. Отсутствие веры, что можно все улучшить

2.6.6. Отсутствует внедрение плана улучшений по итогам Sprint Retrospective

2.6.7. Ожидаемая бесплатность решений

2.6.7.1. Часть задач планируем неявно. В итоге и время на них уходит, и задачи не закрываются.

2.7. Расфокусировка

2.7.1. Отсутствует понимание важности Commitment - обязательство выполнить запланированне задачи

2.7.2. Проблема с фокусировкой, приоритезацией и планированием в работе QA

2.7.3. Консультации и обработка других вопросов, не связанных со Спринтом

2.7.4. Кол-во консультаций

2.7.5. Мало информации описано в документации

2.7.6. Закрываем Спринт в последние минуты

2.8. 1 день в Спринте работать удаленно

2.9. Технический день

2.9.1. Не проводим тех.день. Плохой тех.день.

2.9.2. Свой проект в тех.день

2.9.3. Потеряла квалификацию в JS

2.10. Инциденты

2.10.1. Количество

2.10.2. Работа с проблемами

2.10.2.1. Как использовать проблемы для решения инцидентов, а не после

2.10.3. Шеринг решений по инцидентам

2.10.4. Передача инцидентов другими командами "наобум"

2.10.5. Длительность и частота дежурств.

2.10.5.1. Изменить срок дежурства на инцидентах.

2.10.6. Инциденты по старым вресиям отнимают больше всего времени

2.10.7. Большая часть инцидентов решаются временными решениями

2.10.8. Мало улучшений по результатам работы по problem mngmnt

2.11. Отсутствуют обучения