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

1. BPMS platform

1.1. Алексеев Виктор, PO

1.1.1. Планирование, потери, планирование релиза

1.1.2. Scrum - Гибкий :)

1.1.3. Участие в ретроспективах - команда не всегда за

1.2. Сальников Максим, QA

1.2.1. Старается на перёд

1.2.2. Лазарев - лид QA

1.2.2.1. Сидит возле Ключника

1.2.3. Молчит - значит всё хорошо

1.2.4. Любит учавствовать в инициативах

1.3. Репко Артём

1.3.1. очень давно в компании

1.3.2. Любит Q2A

1.3.3. Любит регламенты

1.3.4. Любит качество

1.3.5. инициатор Английского

1.3.5.1. Speaking club

1.3.5.1.1. по средам

1.3.6. Соглашение по код ревью

1.3.6.1. Письмо от Наташи

1.3.7. Не любит пересаживаться

1.3.8. http://tscore-task/browse/CRM-23465

1.4. Лемешко Вячеслав

1.4.1. Возможно самый крутой технически

1.4.2. Давно в компании

1.4.3. Разговорить тяжело

1.4.4. Надо почаще говорить

1.4.5. Учится в университете

1.4.6. Были конфликты по код ревью

1.4.6.1. Шаповалов

1.4.6.2. Репко

1.4.6.3. Есть соглашение по код ревью

1.4.7. Учить говорить "Нет"

1.4.7.1. Часто приходят к советами

1.4.7.2. Дежурство по спринтам - именно чтобы говорил нет

1.4.8. Учить давать конструктивную обратную связь

1.4.8.1. Устно и в Ревью

1.4.9. Будет заниматься архитектурой

1.5. Тимбилдинги - на ретро

1.6. Александр Бондаренко, техлид

1.7. Jira

1.8. Confluence

1.9. ST

1.10. EP

1.11. Обсудить на ретро

1.11.1. Перенести все встречи на один день

1.11.2. Ребята, проблема комплексных заливок в наших командах – вами не решается. Раз за разом каждый из вас впуливает заливку и ревью по изменениям, которые касаются 2-х, 3-х задач одновременно + вы еще чего то попутно улучшили и к текущему ревью приплюсовали. В результате разбираться в этом ворохе иногда – сущий ад. Примите, пожалуйста, решения по этому поводу в ближайшее время. Выберите способ контроля и правила ограничения сами.  Михаил Павлов

1.11.3. У коллег процессы спроектированы давно, об ошибке они сообщают только сегодня!!?

1.11.4. Обсудить ценности команды

1.11.5. Обсудить соглашения команды

1.11.6. Соглашение с командой - какой спринт мы считаем успешный.

1.12. План последнего ретро

1.12.1. Вынести на планёрку предложения по решению проблемы с мигающими конфигурационными C# тестами: а) создать вирутуальную группу стабилизирующую тесты; б) подумать про прекоммит хуки

1.12.2. Попинговать инфраструктуру про емейл оповещения от Тимсити

1.12.3. Узнать роадмап по запуску грида

1.12.4. Начать делать кейсы для тестирования производительности?

1.12.5. Отменить обязательное поздравление с ДР

2. Tools

2.1. Цели

2.1.1. Перетащить в культивацию

2.1.2. Последнее Ретро

2.1.2.1. Проблема виртуалок - придумать как измерять скорость, нужны объективные показатели

2.1.2.2. Сборка trunk/stable, Dashboards - нужно объяснение как оно работает

2.1.2.3. Стараемся не затягивать разговор про технические нюансы на Daily Scrum, а обсуждать их индивидуально после митинга.

2.1.2.4. Хочется чтобы задачи пришедшие во время спринта обсуждались на Daily Scrum

2.1.2.5. Шум в кабинете - куда можно пересадить людей постоянно говорящих по телефону?

2.2. Кравчук Александр

2.2.1. 10 лет на Террасофте

2.2.2. Евангелист перфекционизма

2.2.3. Тролль

2.2.3.1. это значит что ты в ближнем круге

2.2.4. Инициативен

2.2.5. Большой авторитет для Беспалого

2.3. Беспалый Александр

2.3.1. Выдаёт идеи

2.3.1.1. Производительность

2.3.1.2. Внутреннее совершенство

2.3.1.3. По командообразованию

2.3.2. Иногда его не слышат - помогать чтобы услышали

2.3.3. Делает таски вне спринта и не расписывает их

2.3.4. Обучение по тестам. RegExp и extjs

2.3.5. Заливается никого не спрашивая

2.4. Крестов Дмитрий

2.4.1. Давно в компании

2.4.2. Не лидер

2.4.3. Любит побухтеть

2.5. Дудка Александр

2.5.1. Авторитет для Димы Крестова

2.5.2. Может переоценивать общие задачи

2.5.2.1. Смотря на то, как делаются задачи касающиеся других команд

2.5.3. Классный ментор для новичков

2.5.4. Пытается решить всегда сам

2.5.4.1. Помогать обращаться за помощью

2.5.5. Бывают долги по код ревью

2.5.5.1. tscore-review

2.5.5.2. 4 часа на ответ

2.5.5.3. 8 часов на решение

2.5.6. Карточки скучновато

2.5.6.1. Ждёт кейс-менеджмента

2.5.6.2. Хочет куда-то внедрять node.js

2.5.6.3. Переписать все свг (например на Rafael)

2.5.7. Семья

2.5.8. Мотивировался деньгами

2.5.8.1. Интересные задачи - создать новую структуру классов

2.6. Абасова Валерия (QA)

2.6.1. Недавно

2.6.2. Становится активной

2.6.3. Анализ тестов

2.6.3.1. tsbuild-app

2.6.4. Не хочет делать, если не видит цели

2.6.4.1. И может не сделать

2.6.5. Не молчит

2.6.6. Увольняется

2.7. Бельмега Марина (PO)

2.7.1. Паника, если что-то не успевается

2.8. Командное

2.8.1. Не верят в доску

2.8.1.1. Считают пещерным веком

2.8.2. Не верят во внутренние изменения

2.9. Jira

2.10. Confluence

2.11. ST

2.12. EP

2.13. Обсудить на Ретро

2.13.1. Платформа завалена инцидентами, а Tools решает минимум. При этом в матрице ответственности не прописаны конкретные команды, которые занимаются ими. В итоге претензии по инцидентам идут целиком ко всем командам BPMS

2.13.2. Техническое

2.13.2.1. Договориться как правильно писать конфигурационные JS тесты

2.13.2.2. Инфраструктура моков против интеграционных тестов

2.13.2.3. Ребята, проблема комплексных заливок в наших командах – вами не решается. Раз за разом каждый из вас впуливает заливку и ревью по изменениям, которые касаются 2-х, 3-х задач одновременно + вы еще чего то попутно улучшили и к текущему ревью приплюсовали. В результате разбираться в этом ворохе иногда – сущий ад. Примите, пожалуйста, решения по этому поводу в ближайшее время. Выберите способ контроля и правила ограничения сами. Михаил Павлов

2.13.2.3.1. Заливаться с задачами

2.13.2.4. Single Exit Point vs поменьше вложенности. CR-26177: #CRM-22967

2.13.2.5. Виталий Гдуля попросил нас прочекать на протяжении 2х недель сколько времени мы тратим на поиск причины упавших авто-тестов или любой другой ошбки на trunk

2.13.2.6. Feature toggling - используем ли мы его? Если нет - почему, и что надо сделать чтобы использовать

2.13.3. Мы постоянно обсуждаем внешнее и игнорируем внутреннее

2.13.4. SDK в DoD

2.14. План последнего ретро

2.14.1. Составить список проблем по существующим unit-тестам Команда

2.14.2. Составить список всего, что может влиять на скорость работы с приложением с точки зрения разработчика Команда

2.14.3. Обсудить с Иваном Малафеевым наше видение воронки автоматического тестирования

3. UX

3.1. Цели

3.1.1. Продумать каким образом будем растить команду

3.1.2. Стартовать команду

3.2. Яцульчак Владислав

3.2.1. Только вышел

3.2.2. Его ментор Саша Кравчук

3.2.3. Похоже ещё студент, защищает диплом и пропадает

3.2.4. Нужно оберегать от троллинга команды, Миша Павлов говорит, что могут это делать с серьёзным лицом.

3.2.5. Очень устаёт из-за того что долго добираться домой

3.2.6. Расстроен техническим выбором решений - EJ-диаграмы

3.2.7. Хочется делать продукт качественнее

3.3. Тарас Дворян

3.3.1. Робототехника

3.3.2. Ужгород - Львов - Киев

3.4. Роман Ионенко

3.4.1. Переживает

3.5. Баранов Евгений (QA)

3.5.1. некоторое время был скраммастером

3.5.2. испытательный

3.5.3. софтскилс с проблемами

3.5.4. Под контролем - делает

3.5.5. Готов помогать мне с пониманием функциональности 7.х/3.х

3.5.6. В отпуске

3.6. Бельмега Марина (PO)

3.7. Павлов Дмитрий (Техлид)

4. Гдуля Виталий (SH)

5. Парное программирование по компетенциям

5.1. Самостоятельность!

5.2. Хочется чтобы не только эксперты брались за задачи

5.2.1. Совместное владение кодом

6. Ретро релиза 7.8

7. Обсудить с Алексеем Ключником

7.1. DoD-ы и релизы

7.2. Из обновлений нужно вытащить пользу в виде нормальной документации. И нужно понять какой регламент получения информации по ним, поскольку разработчики занимались поиском информации вплоть до названия конфигурации и на что хотелось обновляться.

7.3. Вики - много старого и непонятно актуального ли. Надо провести чистку.

7.4. Номер первой сборки в которой появились изменения бага/таска/юзерстори должен подставляться в Jira автоматически. Александр Кравчук предложил на планёрке R&D

7.5. В результатах спринта должно быть кол-во юзерстори, дефектов, ресерчей, количество пришедших инцидентов, решенных инцидентов, количество тиммейтов, велосити планируемое, фактическое

7.6. Нет ощущения причастности к разработке - команде выдаются фактически готовые ТЗ

8. Сквозной бэклог 7.9

9. Velocity BPMS

10. ДР

11. 1 to 1

11.1. Как работается с ПО

11.2. Как работается с техлидами

11.3. Как работается со скраммастерами

11.4. Как работается с командой

11.5. Что нужно сделать, чтобы наш продукт стал лучше

11.6. Что нужно изменить в нашем процессе

11.7. Какую видишь пользу от планерок R&D, что понравилось, какое отношение к рейтингам по инцидентам?