1. Корневые причины медленной поставки фич
1.1. Огромный тех.долг
1.1.1. При разработке новой функциональности прорабатываем прототип, анализируем смежный тех. долг и его отдачу включаем в основную задачу - это и будет возвратом Тех.долга.
1.1.2. Не накапливаем Тех долг. Если что-то находим - делаем сразу в текущем Спринте.
1.1.2.1. Урезаем только функционал, а не качество.
1.1.2.2. Постепенно возвращаем прежнюю скорость Команд (т.к. она упадет при таком подходе).
1.1.2.3. Тим.лид: развивать в Командах чувство правильного качественного кода.
1.1.3. Доукомплектовать Команды (в Команде CC 3 из 5 разработчиков).
1.1.4. Реализовать внутр.проект: Распределенная архитектура.
1.1.4.1. Обсудить с разработчиками на планерке Core: какие блоки можно вынести/переделать?; Quarts - что делать с ним?; др.идеи.
1.1.4.2. Найти ресурсы и понять выгоды/преимущества для системы.
1.1.4.3. Презентовать идею стейкхолдерам.
1.1.5. Продолжаем менять в Командах отношение к ответственности за свой продукт.
1.1.6. Помимо развития в рамках Тех.дня Команды также закрывают тех.долг.
1.1.7. Провели детальный анализ тех долга на Командах и запланировали часть в Спринты.
1.1.8. Рабочая группа. Производительность.
1.1.8.1. Включение расширенного логирования (IIS / SQL)
1.1.8.1.1. - рекомендация по настройке логирования IIS; - настройка полного логирования приложения; - перезапуск сайта клиента. Кто: Серебрянский Г. / 29.07. Результат: Написаны статьи на вики http://tswiki/pages/viewpage.action?pageId=57509332
1.1.8.1.2. - SQL профайлинг тормозит сайт клиента; - тормозит машину, на которой он запущен; - в некоторых случаях он съедает много места на жестком диске; - у нас нет изолированного запуска профайлинга; - отказоустойчивость. Браславский В. / 29.07. Результат: есть другие механизмы профайлинга SQL запросов. Описано в статье: http://tswiki/display/TER/SQL+Profiling
1.1.8.1.3. - анализ логов процессов Попченко О.
1.1.8.1.4. Изменить уровень логирования для log4net http://tswiki/pages/viewpage.action?pageId=57509464 Кислый А.
1.1.8.1.5. - проанализировать скрипт on-demand по нагрузке БД (можем ли мы запускать этот скрипт раз в мин и хранить где-то эту инф.). Серебрянский Г. + Курильчик С. / 29.07. Результат: нет нормального решения, нужно еще смотреть
1.1.8.2. SQL/DB Maintance Plan
1.1.8.2.1. Собрать инф и предоставить тех описание этого плана. А. Сергеев. / до 05.08 Курильчик: держать на контроле до внедрения Результат: cloud реализует до 26.08 (по словам Бовшовского)
1.1.8.3. Работа с логами
1.1.8.3.1. логи приложения в scv формате
1.1.8.3.2. логи IIS в текстовом формате
1.1.8.3.3. Разница в часовых поясах
1.1.8.3.4. Придумать механизм загрузки логов БД. Расмотреть разные инструменты анализа логов и возможной перегонки логов из одного места в другое. Кислый 29/07 Кислый С. подготовыт скрипт. / до 05.08
1.1.8.4. Бизнес-процесс решения инцидентов по проблемам производительности
1.1.9. Развитие автоматизированного тестирования в Core.
1.1.9.1. Создать рабочую группу по авто тестам.
1.1.10. Необходимо заниматсья системными проблемами
1.1.10.1. Quarts
1.2. Большое число инцидентов на Командах
1.2.1. Провели анализ причин неэффективной работы на 4-й линии; обсудили результаты с поддержкой.
1.2.1.1. Согласовали с аналитиками поддержки порядок передачи инцидентов на 4-ю линию.
1.2.1.2. Поменяли подходы Команд в работе с инцидентами: проводим ежедневный анализ инцидентов.
1.2.2. Провели анализ инцидентов. Выявили проблемы, которые нужно закрыть для снижения потока новых инцидентов.
1.2.3. Необходимо системное участие тех лида на 4 линии.
1.2.4. Обучение 3 линии поддержки
1.2.4.1. Websocket – как работают у нас, архитектура
1.2.4.2. Redis – архитектура в bpm, влияние на работоспособность системы
1.2.4.3. Научиться собирать Custom сборку, dll для предоставления клиенту
1.2.4.4. Научится выявлять deadlock
1.2.4.5. Часто задаваемы вопросы 2/3 линии и кейсы их решения
1.2.4.6. Работа с ODac, как работает в bpm, как правильно работать
1.2.4.7. Анализ дампов
1.3. Демотивация Команды
1.3.1. сложно внедряются новые технологии;
1.3.2. хотели бы заниматься интересными и сложными задачами;
1.3.3. хотели бы меньше "багофиксинга";
1.3.4. хотели бы, чтобы учитывалось мнение команд в вопросах приоритетов задач.
1.3.5. Частая смена фокуса в работе
1.3.5.1. Менялись приоритеты за день до старта работ над релизом
1.3.5.2. Невыполнимые планы и сроки на релиза
1.3.5.3. Мало времени на проработку новых задач
1.3.5.4. Участники одной Команды занимаются разноплановыми несвязанными задачами
1.3.6. Отсутствие процесса улучшений в Команде
1.3.7. Не было командной работы
1.3.8. ...хотели бы профессионально развиваться в Террасофте; динамика работы не позволяет развиваться: изучать и внедрять новые технологии; эффективно проводить внутр. обучения; делиться опытом между командами;
1.4. Незнание системы
1.4.1. Внедрить в Командах прототипирование, как обязательный этап подготовки к разработке.
1.4.2. Внедрить следющий порядок разработки: 1) бизнес-постановка; 2) прототип; 3) архитектурная постановка; 4) реализация; 5) архитектурная постановка должна соответствовать реальности в конце разработки (в т.ч. при сдаче DoD).
1.4.3. В каждом Спринте выделяем 1 день на развитие разработчиков (Тех.день).
1.4.4. Системное проведение внутр обучений в Командах.
1.4.5. Пересмотреть кадровую политику для Команд Core - брать в Команду разработчиков только из числа работающих в R&D и хорошо знающих систему.
1.4.6. Пересмотреть планы по PBL Команд на ближайшие 3-6-12 мес.; углубиться в систему, изучить ее, провести рефакторинг, вернуть весь тех долг.
1.4.7. Выстраивать с разработчиками долгосрочные отношения; давать им возможность постоянно развиваться именно в Террасофт.
1.5. Отсутствует problem management
1.5.1. Отсутствуют ресурсы / нужны люди
1.6. Отсутствую необходимые навыки в командах по трансформации архитектуры, как ее рефакторить, как улучшать и тд.
2. Value Stream Map
2.1. Перевод ядровых ресурсов
2.1.1. Не можем самостоятельно залить перевод ядровых ресурсов.
2.2. Поддержка часто некорректно заполняет поля Тема/Подтема в инциденте.
2.3. Перенос настройки конфигурационных файлов при переносе или обновлении приложений.
2.4. Временные потери
2.4.1. Ручное тестирование. Много времени тратим на тестирование.
2.4.1.1. Завели статью "Ожидания от тестировщиков Core" (http://tswiki/pages/viewpage.action?pageId=52921041)
2.4.1.2. Необходимо сформировать Рабочую Группу. Цель: продумать стратегия автоматизации тестирования в командах Core
2.4.1.3. Взять за практику: в каждом Спринте анализировать возможность автоматизации тест-кейсов по текущем эпику
2.4.2. Пункутальность. Опоздание одного участника встречи на несколько минут отнимает 20-30 чел/мин рабочего времени.
2.4.3. Качество встреч. Встречи должны быть эффективными (когда достигается цель встречи, а все участники встречи привносят пользу).
2.4.4. Эмоциональное состояние участников Команды.
2.4.5. Фокусировка на задачах в течение дня.
2.4.5.1. Каждые 15-20 мин задавать себе вопрос: А не ерундой ли я сейчас занимаюсь? Это приближает меня к цели Спринта?
3. Вопросы:
3.1. Мнение Карло по развитию архитектуры: какие результаты проработки планов развития на 2 года?
3.2. Синхронизироваться со SH в едином понимании ключевых причин, над устранение которых сейчас необходимо работать.
3.3. Одного РО и аналитика на команды Core мало. Сейчас РО 80% времени тратит на поддержку.
3.4. В каждой задаче находим возможность отдать тех долг в бэклоге.
3.5. Груминги проводим и при работе с инцидентами.
4. Ценности Scrum
4.1. Courage
4.1.1. Убеждать SH принимать решения, необходимые для технического развития приложения (как вариант, рефакторинг);
4.1.2. Умение говорить НЕТ.
4.1.3. Проводить обучения - нет желания проводить внутр обучения. тк нет опыта, есть страх и неуверенность.
4.1.4. Не бояться тратить доп время на проблему - когда спешим, можем упустить из виду важные моменты. Не вестись на продавливание сроков, давление временем. Говорить НЕТ костыльным решениям и быстрым нереалистичным срокам.
4.1.5. Лобировать идею "НЕ создавать новый тех долг" и возвращать старый.
4.1.6. Не боимся напоминать о том, кому мы давали обязательства.
4.1.7. Мы часто отвечаем за функционал, который нам навязывают. Мы не можем брать ответственность за чужие решения, или костыльные решения.
4.2. Focus
4.2.1. Очень много говорим и мало делаем. Пример: категоризация тех долга.
4.2.2. НЕ отвлекаемся на разные задачи. Продумать конкретнее.
4.2.3. Заниматься тем, что мне интересно - в таком случае фокус на задачах сильнее.
4.2.4. Иметь Цели (Командную краткосрочную. Командную долгосрочную. Личную на день. Личную на Спринт).
4.2.5. Иметь видение развития платформы.
4.2.6. Задавать себе вопрос каждые 15-60 мин.: А тем ли я сейчас занимаюсь? Вести расписание.
4.2.7. Часто общатсья с SH - доводить до них инф о проблемах.
4.3. Commitment
4.3.1. Выдерживать баланс между работой и отдыхом. Отдавать себе отчет в том, когда нужно остановиться и отдохнуть.
4.3.2. Груминг - более тщательно проводить проработку задач.
4.3.3. Прямая обратная связь.
4.4. Respect
4.5. Openness
4.5.1. Максимально приглашаем всех заинтересованных на Sprint Demo.
4.5.2. Мало общаемся - надо больше общаться с SH о том, чем мы занимаемся, и какие проблемы в связи с этим возникают.
5. Обязанности тестировщика
5.1. Формирует цели и задачи тестирования
5.1.1. Убеждаюсь, что в команде присутствует единое понимание, как тестировать функционал.
5.1.2. Функциональная карта - поддерживаю в акутальном состоянии. Убеждаюсь, что команда пользуется картой.
5.1.3. Structure - поддерживаю в актуальном состояниии. Готовлю тест-кейсы. Актуализирую матрицу покрытия. Убеждаюсь, что команда понимает, как работает Structure и умеет пользоваться Structure.
5.2. Направляет и контролирует разработку функционала, указывая на возможные риски.
5.2.1. Обеспечиваю/провожу регрессионное тестирование в рамках отдельной задачи.
5.2.2. Сформировать ресурс сбора фидбэка по функционалу TWR от Разработчиков (поможет в дальнейшем тестировании, и/или находить узкие места)
5.2.3. Провести для всех разработчиков команд Core семинар - что такое тест-кейс и тест-план? (Зименко)
5.3. Понимает, на каком уровне тестирования эффективнее всего писать тесты.
5.3.1. Анализирую существующие автотесты и организовываю процесс рфакторинга в команде.
5.3.2. Задача: привести структуру авто-тестов к пирамиде тестирования.
5.3.3. визуализировать процесс работы с нашей функциональностью для понимания
5.3.3.1. Создать kanban доску и через tag привязть к ней все "хотелки" по ФС.
5.4. Формирует задачи и направляет команду в поддержании и усовершенствовании инструментов тестирования.
5.4.1. Сформировать в команде подходы к определению покрытия бизнес-функциональности юнит-тестами.
5.5. Помогает команде обнаруживать уязвимости на ранних этапах.
5.5.1. Планирую стратегии тестирования.
5.5.2. Определяю, как функционал может повлиять на соседний функционал.
5.5.3. TeamCity – контролирую прохождение тестов; запуск и анализ тестов.
5.5.4. Актуализировать функицональную карту. Завести задачи в Спринт TWR и PD. Зименко и Липатов - обсудят с командами. Нужен 1 Спринт.
5.5.5. Атиуализировать Sctructure на основании функц. карты и детализировать каждый блок. Нужен 1 Спринт.
5.5.6. Привязать тесты к sctructure согласно функци карте
5.6. Не позволяет команде идти на компромисс с качеством.
5.7. Не допускает появление багов в trunk`e.
5.7.1. Необходимо понимание качества продукта на всех этапах разработки
5.8. Зименко Сергей
5.8.1. Задачи на первые две недели работы в Core
5.8.1.1. Доработать функциональную карту по блоку мультиязычие
5.8.1.2. Инциденты
5.8.1.3. Матрица покрытия
5.8.1.4. Провести анализ асс тестов команд PD и СС и провести их рефакторинг.
5.8.1.4.1. независимые
5.8.1.4.2. проходят на гриде
5.8.1.4.3. Рефакторинг тестов СС и PD.
6. TWR
6.1. Operation tasks
6.1.1. Согласовать список с Бондарь. На TWR оставть два инцидента - текстиль и webinar. Остальные инциденты равномерно распределить на команды sales, core conf, service, marketing, bpms, contact center, с учетом наличия на этих командах критичных инцидентов.
6.1.2. Организовать. Никонов - Тарасов - Серебрянский. Согласовыват работу по оставшимся инцидентам. производительности. До окончания работы по ним.
6.1.3. Передать на клауд и обсудить с Бовшовским и Никоновым: CRM-25676 Применить параметры rollover для логов SQL
6.1.4. Согласовать с Никоновым цели проработки Синхронизации рабочей копии (ФС) и БД.
6.2. Соловей Саня
6.2.1. Получить дату заполнения ЦП
6.2.2. Запланировать встречу с Никоновым В.
6.3. Серебрянский Глеб
6.3.1. Получить дату заполнения ЦП
6.3.2. Запланировать встречу с Никоновым В.
6.4. Тарасов Павел
6.4.1. Получить дату заполнения ЦП
6.4.2. Запланировать встречу с Никоновым В.
6.5. Иванов Алексей
6.5.1. Получить дату заполнения ЦП
6.5.2. Запланировать встречу с Никоновым В.
6.6. Актуальные вопросы
6.6.1. Разработчики мостоятельно заводят под здачаи в проуцессе груминга
6.6.2. сами ведем процесс плданирования
6.6.3. большесамостоятельности -0 макс стараемсчя закрывтаь вопрос ы безп ривлечения РО и аналитика
6.6.4. Возродить встречи Core. Рабочая группа. Распределенная архитектура;
6.6.5. Несколько дней назад Саша Беспалый сделал заливку в ядро (в частности был затронут функционал команды twr) без предварительного согласования с нами. Мы понимаем важность этой заливки и то, что исправление экономит время разработчиков. Мы так же понимаем, что разработчики уже устали ждать улучшений от нас. Но нам все же хотелось бы, чтобы все такие улучшения предварительно согласовывались с Димой и Андреем. Потому что сейчас получилось так, что нас просто поставили перед фактом, вот review, если хотите можете посмотреть
6.6.6. Идеальный день
6.6.6.1. Занимаемся интересными задачами
6.6.6.1.1. Регулярно и вовремя прорабатывать задачи
6.6.6.2. Минимум отвлечений/переключений
6.7. Культура в TWR
6.7.1. Если мы переключаемся с задач Спринта, мы сообщаем РО, Тим лиду и корректируем бэклог Спринта.
6.7.2. Надо вернуть старое правило - оно не работает - презумпция невиновности - если др команды находят ошибку и не могут доказать, что она из-за наших заливок, мы не переключаемся на нее.
6.7.3. Sprint Retro проводим не более 45 мин. Каждый обязательно готовится заранее (со списокм вопросов для обсуждения и решений по ним).
6.7.4. В течение 10 мин после daily scrum каждый пишет на команду индивидуальные планы на день.
6.7.5. BL refinement: первый день (решаем на планировании - какой это будет день) - работаем индивидуально над задачами; второй день - коллективная работа, делимся результатами, оцениваем задачи.
6.7.6. На планировании выделяем одного разработчика, который автоматически подключается к решению срочных вбросов. На такого разработчика не планируем критичные задачи, от которых зависит успешность Спринта.
6.7.7. На Sprint Review фиксируем замечания/вопросы на отдельном ноуте.
6.7.8. Проработку задач заканчиваем в тч и декомпозицией задач - важно отслеживать статус по задачам и переводоить ее до стадии завершения по маленьким частям.
6.7.9. Определили критерии качественной проработки задач: - есть рабочий прототип; - отсутствуют неизвестные места/нераскрытые вопросы по задаче; - результаты проработки в команде согласованы с TL и РО; - визуализирована будущая разработка и выявлены все взаимосвязи в функционале; при такая визуализация должна быть подготовлена в рамках проработки (time-box).
6.7.10. Выделяем на проработку 2 дня или более, если это необходимо.
7. Core PD
7.1. Шведун Павел
7.1.1. Заполнить 20% ЦП по себе.
7.1.2. Запланировать встречу с Никоновым В.
7.2. Лазарев Иван
7.2.1. Получить дату заполнения ЦП
7.2.2. Запланировать встречу с Никоновым В.
7.3. Хохлов Андрей
7.3.1. Получить дату заполнения ЦП
7.3.2. Запланировать встречу с Никоновым В.
7.4. Попченко Олег
7.4.1. Запланировать встречу с Никоновым В.
7.5. Толочко Данил
7.5.1. Запланировать встречу с Никоновым В.
7.6. Зименко
7.6.1. Заполнить и защитить 100% ЦП.
8. Разработка на платформе bpm online.
8.1. ВОПРОСЫ:
8.1.1. Что входит в среду разработки?
8.1.2. Чем отличаются проимышленная среда от среды разработки?
9. Итоги ретро релиза 7.8
9.1. Планирование
9.1.1. Необходимо внедрить в работу Команд прототипирование, как обязательный этап подготовки к разработке.
9.1.2. Необходим следющий порядок разработки: 1) бизнес-постановка; 2) прототип; 3) архитектурная постановка; 4) реализация; 5) архитектурная постановка должна соответствовать реальности в конце разработки (в т.ч. ри сдаче DoD).
9.1.3. В каждом Спринте выделяем 1 день на развитие разработчиков: Тех.день.
9.1.3.1. до 08.07 - Обсудить с каждой командой отдельно.
9.1.4. Обязательное проведение внутр обучений в Командах Core
9.2. JIRA
9.2.1. Привести к соответствию доски в JRIA и прохождение задачи по DoD-ам эпика.
9.3. Презумпция виновности
9.3.1. Улучшить систему логирования (чтобы было сразу понятно, кто виноват)
9.3.1.1. в логах должна быть инф, - 1) с какими системными данными произошла ошибка; 2) логин Пользователя; 3) механизм логирвоания выполняется в том же потоке, в котором выполняется работа Приложения - необходимо его вынести (реализовать работу через пулы Log4Net); 4) определить части системы, которые показывают действия пользователя, а не просто системную ошибку.
9.3.1.1.1. Добавить в список вопросов DevClub.
9.3.1.1.2. Выбрать из разработчиков TWR - кто сделает эту задачу, например: - согласовать с Курильчиком план работы над задачей; - раздробить задачу на мелкие части; - заниматься задачей в рамках тех дней Команды.
9.3.2. Требуем доказать передачу ошибки на команды Core
9.4. Тех.долг
9.4.1. Проанализировать результаты анализа Инцидентов (список Жаренко и Кричко).
9.4.1.1. Жаренко Д. - выслать на команды результаты анализа.
9.4.1.2. Большинство причин возникновения причин давно известно - можно отдавать в рамках тех дней.
9.5. ИНЦИДЕНТЫ
9.5.1. На дежурство по 4-й линии уходить всей командой.
9.5.1.1. Аргументы в пользу идеи: http://tswiki/pages/viewpage.action?pageId=56134118
9.5.1.2. Согласовать порядок смены дежурств между командами.
9.5.1.2.1. Договорились с командами, что начинают дежурство TWR, потом CC и потом PD.
9.5.1.2.2. Непонятно как передавать дежурство после PD.
9.5.1.3. Согласовать с Ключником.
9.5.2. Идея: сформировать отд постоянную команду по решению инцидентов
9.5.2.1. Выгоды: - скрам-команды не будут отвлекаться на непродуктивные задачи: - большая часть инцидентов - это неэффективнеая трата времени; - такая команда детальнее углубится в причины инцидентов; - сейчас идет постоянный поток новых инцидентов; а надо - анализировать и устранять причины; - много времени уходит на конслуьтации, общение, сбор информации; - никто не делает ошибки специально - на инциденты команды идут как на наказание; - причины инцидентов часто кроются в планировании релизов и условиях работы (срочность, спешка, давление из вне) - так было по 7.8.0. - "бракоделов" надо "наказывать" иначе, и работа на 4-й линии их не исправит;
9.5.2.2. Сергеев, Курильчик, Жаренко, Браславский, Седневец - подготовить аналитику и обсудить с Ключником+Старун необходимость выделить разработчиков на 3-ю линию поддержки.
9.6. Инфраструктура
9.6.1. Integration Tests
9.6.1.1. Уточнить у Тим.лидов планы по использованию Integration Tests.
9.6.2. Покрытие UT
9.6.2.1. Sonar!
9.6.2.1.1. Выяснить статус - кто его должен был внедрять - Курильчик/Седневец. - и сообщить командам Core.
9.6.3. Автоматизировать сдачу DoD-ов.
9.6.4. Необходим отдельный сервер (железо) для тестирования
9.6.5. Сервера разработки: не выдерживают нагрузку; не хватает дискового пространства.
9.6.5.1. Обсудили вопрос с Рыбачек/Малафеевым и Ключником. Будет выделен отд сервер для обновления клиентов. Держать на контроле сроки.
9.6.5.2. Необходимо выяснить причины тормозов.
9.6.6. Сеть: есть предположение, что ВМ тормозят из-за сети.
9.6.6.1. 14.06 - Проконтролировать - кто хочет продемонстрировать тормоза ВМ админам?
9.6.6.1.1. Продемонстрировать параллельно работу железки и ВМ - Иванов А./Серебрянский Г.
9.6.6.2. ВМ ни в какое сравнение не идут с работой на железных машинах.
9.6.6.2.1. Карло: До конца Июля введут в эксплуатацию 3-4 новых сервера. У всех разработчиков будет по 4 процессора. У всех, кто на Win10 - по 10 Gb оперативки. По сетке - инф.нет, буду отдельно говорить с админами. По сети: Для пользовательского кластера Карло планирует вводить в эксплуатацию 10 Гбитные свичи. Мы это вряд ли заметим, но для R&D это необходимо для нового типа файлового хранилища, которое требует таких свичей.
9.6.6.3. ВМ крутятся на старых дисках - проверить с on-demand!
9.6.6.4. Заказать исследование у админов.