1. проблемы
1.1. перекладывания ответственности друг на друга
1.1.1. нет единого ответственного
1.1.1.1. нет контроля за выполнением каждого шага
1.1.1.2. общий процесс не предсказуем, нет плана
1.1.2. команда не отвечает за функционал, а только за свою часть
1.1.2.1. нет взаимодействия в команде, команда не мотивирована
1.1.2.2. Функциональное деление
1.1.2.3. не учтена интеграция
1.2. долгий цикл решения задачи, баги не исправляются, т.е. задачи повисают недоделанными
1.2.1. плохое качество кода
1.2.1.1. большое количество багов
1.2.2. есть давление на разработку со стороны бизнеса по срокам
1.2.3. устаревание требований
1.3. Слишком детальное проектирование задач от аналитиков
1.3.1. аналитики могут не знать всех технических проблем
1.3.2. разработчики не могут принимать архитектурые решения
1.3.3. небходимость согласовывать изменения с разаработчиками
1.4. требования меняются, но не отражаются в ТЗ
1.4.1. код не соответствует задачам
1.4.2. тестировщики тестируют не по ТЗ
1.4.3. слишком тяжеловесный формат постановки задачи - дорого вносить изменения
1.5. тестеры заняты поддержкой клиентов
1.5.1. у них нет времени на тестирование
1.5.2. у них собственные представления о приоритетах
2. симптомы
2.1. бизнес недоволен результатами
2.2. нет предсказуемости для бизнеса
2.3. требования аналитиков не понятны разработчикам
2.3.1. "так сделать нельзя"
2.4. "у нас все хорошо, косячат где-то там"
2.5. результат не соответствует ожиданиям аналитиков
2.6. баги не исправляются
3. Окружение
3.1. Распределеннас система
3.2. Компоненты
3.2.1. касса
3.2.2. флекс
3.2.3. сервер
3.2.3.1. Работает
3.2.3.1.1. По словам программистов
3.3. Тестирование = отдел поддержки
3.3.1. Нормально, если клиентов мало
3.4. Водопад
3.4.1. agile = не работает
3.4.1.1. в местной версии
3.4.1.2. "Scrum"
3.4.1.2.1. итерации "2-3 недели"
3.4.1.3. Канбан
3.4.2. Впрочем,ничего плохого в водопаде нет
3.5. Очень большая система
3.5.1. > 40 человек-лет
4. метрики
4.1. количество выпущенных фич за промежуток времени
4.2. Цикл решения задачи
4.3. количетсво обращений в саппорт
4.4. Количество багов в готовой функциональности
5. целевое состояние
5.1. есть видимый для бизнеса результат разработки (рабочий продукт)
5.1.1. Процесс предсказуем, внедрено планирование
5.2. Есть единый ответственный за разработку продукта
5.3. эффективное взаимодействие команды, мотивация членов команды
5.4. цикл решения задачи сокращен, задачи решаются комплексно
5.5. Наличие краткосрочного/долгосрочного плана
5.6. количество багов уменьшено
6. План действий
6.1. Must Have
6.1.1. нет единого ответственного
6.1.1.1. назначить ответственного и снабдить его необходимыми полномочиями
6.2. Путь 1
6.2.1. команда не отвечает за функционал, а только за свою часть
6.2.1.1. Ввести интеграционную команду
6.2.1.1.1. занимается декомпозицией задач, делегированием другим команадам, проверкой результатов и интеграцией
6.2.1.1.2. Ограничить work in progress
6.2.1.2. Разделить команды по компонентам
6.2.1.2.1. В каждой команде выделить ответственного за компонент
6.2.1.2.2. В каждую команду ввести аналитика и тестера
6.2.1.2.3. формализовать правила готовности каждого компонента из модуля
6.2.2. Слишком детальное проектирование задач от аналитиков
6.2.2.1. Уровни проектирования разделены
6.2.2.1.1. product-level => интеграционная команда
6.2.2.1.2. Уровень компонента => команда компонента
6.2.3. слишком тяжеловесный формат постановки задачи - дорого вносить изменения
6.2.3.1. Изменений будет меньше, т.к. будет централизованный орган постановки задач
6.2.4. долгий цикл решения задачи, баги не исправляются, т.е. задачи повисают недоделанными
6.2.4.1. Ограничить Work in progress
6.2.5. тестеры заняты поддержкой клиентов
6.2.5.1. Изменить прохождение запросов на поддержку
6.2.5.1.1. Интеграционная команда принимает запрос
6.2.5.1.2. Запрос разбивается или эскалируется на команды компонентов
6.3. Путь 2
6.3.1. команда не отвечает за функционал, а только за свою часть
6.3.1.1. Выделить полнофункциональные команды с аналитиками, тестировщиками и тд
6.3.1.1.1. Команда отвечает непосредственно за результат, видимый бизнесу
6.3.1.1.2. Нет жестких внешних зависимостей
6.3.1.1.3. Scrum of Scrums для синхронизации общего направления разработки
6.3.2. долгий цикл решения задачи, баги не исправляются, т.е. задачи повисают недоделанными
6.3.3. Слишком детальное проектирование задач от аналитиков
6.3.3.1. Аналитик работает в тесном контакте с командой
6.3.3.1.1. отвечает за требования и приоритезацию
6.3.3.1.2. не навязывает технического решения
6.3.4. слишком тяжеловесный формат постановки задачи - дорого вносить изменения
6.3.4.1. перейти на формат user stories
6.3.4.1.1. поддерживать беклог и актуальный список задач на итерацию
6.3.5. тестеры заняты поддержкой клиентов
6.3.5.1. выделяем модуль саппорта
6.3.5.1.1. запросы попадают в беклог и включаются в спринт план по командам
6.3.5.1.2. либо выделить одну из команд полностью на поддержку (с ротацией)