;
Иван Алякскин
Чек-лист для Knowledge Transfer
15.05.2017 4278
Другие статьи автора
Возможные способы реализации мобильных приложений
Джентльменский набор мобильного проекта
Исключаем фактор «так исторически сложилось» на Android/Mobile-проекте
Android Security
Android Legacy
Задорный ReactNative вносит летние краски в “кровавый enterprise”
Архитектура, рефакторинг, или Что действительно важно
Dynamic Systems Development Method (DSDM)
Документация в картинках
Последние статьи в блоге
Как оценивать работу тестировщиков по науке
Учебный центр IBS получил сертификат ГОСТ Р ИСО 9001-2015
Совет по развитию сертификации ИТ-специалистов при АПКИТ аккредитовал «Платформу сертификации IBS»
Java-сертификация: IBS в сравнении с Oracle
Исследование IBS: число новых ИТ-решений в реестре ПО выросло в 2023 году более чем на треть
6 суперспособностей Fullstack-тестировщиков, которые напоминают навыки животных
5 мифов о системных аналитиках
Методология 12 факторов: как успешно разрабатывать облачные приложения
Баги, которые стали фичами
Шаблоны облачного проектирования
Рано или поздно каждому приходится сталкиваться с задачей принятия или же передачи проекта. Для того чтобы это сделать эффективно, я следую моему чек-листу, чтобы ничего не упустить из виду, чтобы заказчик/владелец проекта не заметил замены команды.
Сперва стараюсь разобраться со следующим набором информации/доступов.
• Структура команды:
- Состав команды;
- Иерархия и зона ответственности, репортинг;
- Контактные лица у заказчика / в соседних командах / у вендора.
- Описанию бизнес-требований;
- Пользовательской документации;
- Тест-кейсам.
- Адреса репозиториев;
- Создание учетных записей со всеми правами;
- Получение всех конфигурационных скриптов и требований для рабочих станций разработчиков;
- По возможности создание автоматических скриптов развертки окружения либо же создание образов систем – чтобы не тратить драгоценное время разработчиков.
- Архитектура системы;
- Архитектура подсистем;
- Архитектура с точки зрения технических примитивов;
- Архитектура с точки зрения бизнес-задач, use cases;
- Технический долг команды;
- Все технические изыскания и предложения по существующей системе;
- Возможно провести эксперимент, и новой команде дать задание создать «выкройку» системы с целью выделить инфраструктурные компоненты, обеспечивающие работоспособность системы, а также наложить на это бизнес-требования – по своему опыту - народ въезжает в проект быстрее.
- Сервера CI/CD;
- Тестовая инфраструктура;
- Варианты сборок.
- Система обработки пользовательских запросов;
- Система bug-трекинга;
- Система хранения знаний / информационный портал;
- Система мониторинга;
- Система аналитики пользовательских действий;
- Очень важно выявить контактных лиц по всем вопросам, связанных с каждой системой;
- А также все процедуры и церимонималы: flow-обработки пользовательского запроса; flow-согласования новой технической документации.
- Процедуры и список ЛПР, связанных с ежедневными рутинами;
- Процедуры и список ЛПР, связанных с закрытием спринта / итерации / этапа работ;
- Процедуры и список ЛПР, связанных с планированием нового релиза / итерации;
- Процедуры, связанные с обработкой Change Requests, и список ЛПР;
- Процедуры и церимониалы, связанные с выпуском нового релиза.
- Необходимо получить доступ ко всем базам тестовых сценариев;
- Необходимо получить описание процедур выпуска релизов.
- Тестовые / стейджинг / продакшн пользовательские учетные записи для тестирования продукта;
- Учетки в системы аналитики / системы вендоров / партнеров.
- План работ;
- Роадмап;
- Целеполагание с технической точки зрения;
- Целеполагание с точки зрения продукта.
- Доступ ко всем третьесторонним системам в правах администратора – для возможности добавлять своих пользователей;
- Контакты всех вендоров и партнеров, их ЛПР, график взаимодействия с ними, структура их команды, зон ответственности, а также краткое описание предметной области взаимодействия и целей команды.
- Что требуется от команды разработки, тестирования, поддержки;
- Какие задачи стоят перед новой командой.
Стоит заметить, что лучше всего получается провести KT, когда возможно параллельно держать 2 команды, тогда возможно всей команде постепенно влиться в процесс разработки, разобраться совместно с носителями знаний с конфигурированием систем, процессными системами – к примеру с JIRA: разобраться с жизненным циклом дефекта и т.д.
Если команда работает по Scrum или Scrumban, я рекомендую провести 1-2 спринта с соблюдением всех церемониалов: planning, groomings, triage, retrospectives, demos.
В целом все, спасибо за внимание!
Расскажи друзьям:
Как не пропустить самое интересное?
Подписывайтесь на наш ежемесячный дайджест!