Core

Solve your problems or get new ideas with basic brainstorming

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

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. Итоги ретро релиза 7.8

2.1. Планирование

2.1.1. Необходимо внедрить в работу Команд прототипирование, как обязательный этап подготовки к разработке.

2.1.2. Необходим следющий порядок разработки: 1) бизнес-постановка; 2) прототип; 3) архитектурная постановка; 4) реализация; 5) архитектурная постановка должна соответствовать реальности в конце разработки (в т.ч. ри сдаче DoD).

2.1.3. В каждом Спринте выделяем 1 день на развитие разработчиков: Тех.день.

2.1.3.1. до 08.07 - Обсудить с каждой командой отдельно.

2.1.4. Обязательное проведение внутр обучений в Командах Core

2.2. JIRA

2.2.1. Привести к соответствию доски в JRIA и прохождение задачи по DoD-ам эпика.

2.3. Презумпция виновности

2.3.1. Улучшить систему логирования (чтобы было сразу понятно, кто виноват)

2.3.1.1. в логах должна быть инф, - 1) с какими системными данными произошла ошибка; 2) логин Пользователя; 3) механизм логирвоания выполняется в том же потоке, в котором выполняется работа Приложения - необходимо его вынести (реализовать работу через пулы Log4Net); 4) определить части системы, которые показывают действия пользователя, а не просто системную ошибку.

2.3.1.1.1. Добавить в список вопросов DevClub.

2.3.1.1.2. Выбрать из разработчиков TWR - кто сделает эту задачу, например: - согласовать с Курильчиком план работы над задачей; - раздробить задачу на мелкие части; - заниматься задачей в рамках тех дней Команды.

2.3.2. Требуем доказать передачу ошибки на команды Core

2.4. Тех.долг

2.4.1. Проанализировать результаты анализа Инцидентов (список Жаренко и Кричко).

2.4.1.1. Жаренко Д. - выслать на команды результаты анализа.

2.4.1.2. Большинство причин возникновения причин давно известно - можно отдавать в рамках тех дней.

2.5. ИНЦИДЕНТЫ

2.5.1. На дежурство по 4-й линии уходить всей командой.

2.5.1.1. Аргументы в пользу идеи: http://tswiki/pages/viewpage.action?pageId=56134118

2.5.1.2. Согласовать порядок смены дежурств между командами.

2.5.1.2.1. Договорились с командами, что начинают дежурство TWR, потом CC и потом PD.

2.5.1.2.2. Непонятно как передавать дежурство после PD.

2.5.1.3. Согласовать с Ключником.

2.5.2. Идея: сформировать отд постоянную команду по решению инцидентов

2.5.2.1. Выгоды: - скрам-команды не будут отвлекаться на непродуктивные задачи: - большая часть инцидентов - это неэффективнеая трата времени; - такая команда детальнее углубится в причины инцидентов; - сейчас идет постоянный поток новых инцидентов; а надо - анализировать и устранять причины; - много времени уходит на конслуьтации, общение, сбор информации; - никто не делает ошибки специально - на инциденты команды идут как на наказание; - причины инцидентов часто кроются в планировании релизов и условиях работы (срочность, спешка, давление из вне) - так было по 7.8.0. - "бракоделов" надо "наказывать" иначе, и работа на 4-й линии их не исправит;

2.5.2.2. Сергеев, Курильчик, Жаренко, Браславский, Седневец - подготовить аналитику и обсудить с Ключником+Старун необходимость выделить разработчиков на 3-ю линию поддержки.

2.6. Инфраструктура

2.6.1. Integration Tests

2.6.1.1. Уточнить у Тим.лидов планы по использованию Integration Tests.

2.6.2. Покрытие UT

2.6.2.1. Sonar!

2.6.2.1.1. Выяснить статус - кто его должен был внедрять - Курильчик/Седневец. - и сообщить командам Core.

2.6.3. Автоматизировать сдачу DoD-ов.

2.6.4. Необходим отдельный сервер (железо) для тестирования

2.6.5. Сервера разработки: не выдерживают нагрузку; не хватает дискового пространства.

2.6.5.1. Обсудили вопрос с Рыбачек/Малафеевым и Ключником. Будет выделен отд сервер для обновления клиентов. Держать на контроле сроки.

2.6.5.2. Необходимо выяснить причины тормозов.

2.6.6. Сеть: есть предположение, что ВМ тормозят из-за сети.

2.6.6.1. 14.06 - Проконтролировать - кто хочет продемонстрировать тормоза ВМ админам?

2.6.6.1.1. Продемонстрировать параллельно работу железки и ВМ - Иванов А./Серебрянский Г.

2.6.6.2. ВМ ни в какое сравнение не идут с работой на железных машинах.

2.6.6.2.1. Карло: До конца Июля введут в эксплуатацию 3-4 новых сервера. У всех разработчиков будет по 4 процессора. У всех, кто на Win10 - по 10 Gb оперативки. По сетке - инф.нет, буду отдельно говорить с админами. По сети: Для пользовательского кластера Карло планирует вводить в эксплуатацию 10 Гбитные свичи. Мы это вряд ли заметим, но для R&D это необходимо для нового типа файлового хранилища, которое требует таких свичей.

2.6.6.3. ВМ крутятся на старых дисках - проверить с on-demand!

2.6.6.4. Заказать исследование у админов.

3. Value Stream Map

3.1. Перевод ядровых ресурсов

3.1.1. Не можем самостоятельно залить перевод ядровых ресурсов.

3.2. Поддержка часто некорректно заполняет поля Тема/Подтема в инциденте.

3.3. Перенос настройки конфигурационных файлов при переносе или обновлении приложений.

3.4. Временные потери

3.4.1. Ручное тестирование. Много времени тратим на тестирование.

3.4.1.1. Завели статью "Ожидания от тестировщиков Core" (http://tswiki/pages/viewpage.action?pageId=52921041)

3.4.1.2. Необходимо сформировать Рабочую Группу. Цель: продумать стратегия автоматизации тестирования в командах Core

3.4.1.3. Взять за практику: в каждом Спринте анализировать возможность автоматизации тест-кейсов по текущем эпику

3.4.2. Пункутальность. Опоздание одного участника встречи на несколько минут отнимает 20-30 чел/мин рабочего времени.

3.4.3. Качество встреч. Встречи должны быть эффективными (когда достигается цель встречи, а все участники встречи привносят пользу).

3.4.4. Эмоциональное состояние участников Команды.

3.4.5. Фокусировка на задачах в течение дня.

3.4.5.1. Каждые 15-20 мин задавать себе вопрос: А не ерундой ли я сейчас занимаюсь? Это приближает меня к цели Спринта?

4. Вопросы:

4.1. Мнение Карло по развитию архитектуры: какие результаты проработки планов развития на 2 года?

4.2. Синхронизироваться со SH в едином понимании ключевых причин, над устранение которых сейчас необходимо работать.

4.3. Одного РО и аналитика на команды Core мало. Сейчас РО 80% времени тратит на поддержку.

4.4. В каждой задаче находим возможность отдать тех долг в бэклоге.

4.5. Груминги проводим и при работе с инцидентами.

5. Ценности Scrum

5.1. Courage

5.1.1. Убеждать SH принимать решения, необходимые для технического развития приложения (как вариант, рефакторинг);

5.1.2. Умение говорить НЕТ.

5.1.3. Проводить обучения - нет желания проводить внутр обучения. тк нет опыта, есть страх и неуверенность.

5.1.4. Не бояться тратить доп время на проблему - когда спешим, можем упустить из виду важные моменты. Не вестись на продавливание сроков, давление временем. Говорить НЕТ костыльным решениям и быстрым нереалистичным срокам.

5.1.5. Лобировать идею "НЕ создавать новый тех долг" и возвращать старый.

5.1.6. Не боимся напоминать о том, кому мы давали обязательства.

5.1.7. Мы часто отвечаем за функционал, который нам навязывают. Мы не можем брать ответственность за чужие решения, или костыльные решения.

5.2. Focus

5.2.1. Очень много говорим и мало делаем. Пример: категоризация тех долга.

5.2.2. НЕ отвлекаемся на разные задачи. Продумать конкретнее.

5.2.3. Заниматься тем, что мне интересно - в таком случае фокус на задачах сильнее.

5.2.4. Иметь Цели (Командную краткосрочную. Командную долгосрочную. Личную на день. Личную на Спринт).

5.2.5. Иметь видение развития платформы.

5.2.6. Задавать себе вопрос каждые 15-60 мин.: А тем ли я сейчас занимаюсь? Вести расписание.

5.2.7. Часто общатсья с SH - доводить до них инф о проблемах.

5.3. Commitment

5.3.1. Выдерживать баланс между работой и отдыхом. Отдавать себе отчет в том, когда нужно остановиться и отдохнуть.

5.3.2. Груминг - более тщательно проводить проработку задач.

5.3.3. Прямая обратная связь.

5.4. Respect

5.5. Openness

5.5.1. Максимально приглашаем всех заинтересованных на Sprint Demo.

5.5.2. Мало общаемся - надо больше общаться с SH о том, чем мы занимаемся, и какие проблемы в связи с этим возникают.

6. Обязанности тестировщика

6.1. Формирует цели и задачи тестирования

6.1.1. Убеждаюсь, что в команде присутствует единое понимание, как тестировать функционал.

6.1.2. Функциональная карта - поддерживаю  в акутальном состоянии. Убеждаюсь, что команда пользуется картой.

6.1.3. Structure - поддерживаю в актуальном состояниии. Готовлю тест-кейсы. Актуализирую матрицу покрытия. Убеждаюсь, что команда понимает, как работает Structure и умеет пользоваться Structure.

6.2. Направляет и контролирует разработку функционала, указывая на возможные риски.

6.2.1. Обеспечиваю/провожу регрессионное тестирование в рамках отдельной задачи.

6.2.2. Сформировать ресурс сбора фидбэка по функционалу TWR от Разработчиков (поможет в дальнейшем тестировании, и/или находить узкие места)

6.2.3. Провести для всех разработчиков команд Core семинар - что такое тест-кейс и тест-план? (Зименко)

6.3. Понимает, на каком уровне тестирования эффективнее всего писать тесты.

6.3.1. Анализирую существующие автотесты и организовываю процесс рфакторинга в команде.

6.3.2. Задача: привести структуру авто-тестов к пирамиде тестирования.

6.3.3. визуализировать процесс работы с нашей функциональностью для понимания

6.3.3.1. Создать kanban доску и через tag привязть к ней все "хотелки" по ФС.

6.4. Формирует задачи и направляет команду в поддержании и усовершенствовании инструментов тестирования.

6.4.1. Сформировать в команде подходы к определению покрытия бизнес-функциональности юнит-тестами.

6.5. Помогает команде обнаруживать уязвимости на ранних этапах.

6.5.1. Планирую стратегии тестирования.

6.5.2. Определяю, как функционал может повлиять на соседний функционал.

6.5.3. TeamCity – контролирую прохождение тестов; запуск и анализ тестов.

6.5.4. Актуализировать функицональную карту. Завести задачи в Спринт TWR и PD. Зименко и Липатов - обсудят с командами. Нужен 1 Спринт.

6.5.5. Атиуализировать Sctructure на основании функц. карты и детализировать каждый блок. Нужен 1 Спринт.

6.5.6. Привязать тесты к sctructure согласно функци карте

6.6. Не позволяет команде идти на компромисс с качеством.

6.7. Не допускает появление багов в trunk`e.

6.7.1. Необходимо понимание качества продукта на всех этапах разработки

6.8. Зименко Сергей

6.8.1. Задачи на первые две недели работы в Core

6.8.1.1. Доработать функциональную карту по блоку мультиязычие

6.8.1.2. Инциденты

6.8.1.3. Матрица покрытия

6.8.1.4. Провести анализ асс тестов команд PD и СС и провести их рефакторинг.

6.8.1.4.1. независимые

6.8.1.4.2. проходят на гриде

6.8.1.4.3. Рефакторинг тестов СС и PD.

7. TWR

7.1. Operation tasks

7.1.1. Согласовать список с Бондарь. На TWR оставть два инцидента - текстиль и webinar. Остальные инциденты равномерно распределить на команды sales, core conf, service, marketing, bpms, contact center, с учетом наличия на этих командах критичных инцидентов.

7.1.2. Организовать. Никонов - Тарасов - Серебрянский. Согласовыват работу по оставшимся инцидентам. производительности. До окончания работы по ним.

7.1.3. Передать на клауд и обсудить с Бовшовским и Никоновым: CRM-25676 Применить параметры rollover для логов SQL

7.1.4. Согласовать с Никоновым цели проработки Синхронизации рабочей копии (ФС) и БД.

7.2. Соловей Саня

7.2.1. Получить дату заполнения ЦП

7.2.2. Запланировать встречу с Никоновым В.

7.3. Серебрянский Глеб

7.3.1. Получить дату заполнения ЦП

7.3.2. Запланировать встречу с Никоновым В.

7.4. Тарасов Павел

7.4.1. Получить дату заполнения ЦП

7.4.2. Запланировать встречу с Никоновым В.

7.5. Иванов Алексей

7.5.1. Получить дату заполнения ЦП

7.5.2. Запланировать встречу с Никоновым В.

7.6. Актуальные вопросы

7.6.1. Разработчики мостоятельно заводят под здачаи в проуцессе груминга

7.6.2. сами ведем процесс плданирования

7.6.3. большесамостоятельности -0 макс стараемсчя закрывтаь вопрос ы безп ривлечения РО и аналитика

7.6.4. Возродить встречи Core. Рабочая группа. Распределенная архитектура;

7.6.5. Несколько дней назад Саша Беспалый сделал заливку в ядро (в частности был затронут функционал команды twr) без предварительного согласования с нами. Мы понимаем важность этой заливки и то, что исправление экономит время разработчиков. Мы так же понимаем, что разработчики уже устали ждать улучшений от нас. Но нам все же хотелось бы, чтобы все такие улучшения предварительно согласовывались с Димой и Андреем. Потому что сейчас получилось так, что нас просто поставили перед фактом, вот review, если хотите можете посмотреть

7.6.6. Идеальный день

7.6.6.1. Занимаемся интересными задачами

7.6.6.1.1. Регулярно и вовремя прорабатывать задачи

7.6.6.2. Минимум отвлечений/переключений

7.7. Культура в TWR

7.7.1. Если мы переключаемся с задач Спринта, мы сообщаем РО, Тим лиду и корректируем бэклог Спринта.

7.7.2. Надо вернуть старое правило - оно не работает - презумпция невиновности - если др команды находят ошибку и не могут доказать, что она из-за наших заливок, мы не переключаемся на нее.

7.7.3. Sprint Retro проводим не более 45 мин. Каждый обязательно готовится заранее (со списокм вопросов для обсуждения и решений по ним).

7.7.4. В течение 10 мин после daily scrum каждый пишет на команду индивидуальные планы на день.

7.7.5. BL refinement: первый день (решаем на планировании - какой это будет день) - работаем индивидуально над задачами; второй день - коллективная работа, делимся результатами, оцениваем задачи.

7.7.6. На планировании выделяем одного разработчика, который автоматически подключается к решению срочных вбросов. На такого разработчика не планируем критичные задачи, от которых зависит успешность Спринта.

7.7.7. На Sprint Review фиксируем замечания/вопросы на отдельном ноуте.

7.7.8. Проработку задач заканчиваем в тч и декомпозицией задач - важно отслеживать статус по задачам и переводоить ее до стадии завершения по маленьким частям.

7.7.9. Определили критерии качественной проработки задач: - есть рабочий прототип; - отсутствуют неизвестные места/нераскрытые вопросы по задаче; - результаты проработки в команде согласованы с TL и РО; - визуализирована будущая разработка и выявлены все взаимосвязи в функционале; при такая визуализация должна быть подготовлена в рамках проработки (time-box).

7.7.10. Выделяем на проработку 2 дня или более, если это необходимо.

8. Core PD

8.1. Шведун Павел

8.1.1. Заполнить 20% ЦП по себе.

8.1.2. Запланировать встречу с Никоновым В.

8.2. Лазарев Иван

8.2.1. Получить дату заполнения ЦП

8.2.2. Запланировать встречу с Никоновым В.

8.3. Хохлов Андрей

8.3.1. Получить дату заполнения ЦП

8.3.2. Запланировать встречу с Никоновым В.

8.4. Попченко Олег

8.4.1. Запланировать встречу с Никоновым В.

8.5. Толочко Данил

8.5.1. Запланировать встречу с Никоновым В.

8.6. Зименко

8.6.1. Заполнить и защитить 100% ЦП.

9. Разработка на платформе bpm online.

9.1. ВОПРОСЫ:

9.1.1. Что входит в среду разработки?

9.1.2. Чем отличаются проимышленная среда от среды разработки?