О коммуникации в среде разработчиков
На меня на днях свалилась задача, довольно рядовая. Но она наглядно показала, насколько важна для качественной работы инженеров-программистов коммуникация. Почему сидение и ковыряние задачи за закрытыми дверями было бы контрпродуктивно.
Итак задача: запилить новую виртуальную машину для разработчиков. Критерии приёмки: все тесты продукта, которые успешно выполнялись на старой машине, должны выполняться и на новой.
Делаю бокс, выкладываю на сервер, говорю парню A из QA, где взять обновленный Vagrantfile. Коллега A запускает тесты и говорит “у меня половина не проходит”. Но он это дело не бросает, а прикладывает некоторое количество усилий, чтобы выяснить, чем новая виртуалка принципиально отличается от старой. И замечает, что количество функционала в административной панели старой и новой виртуалок отличается радикально. Старая соответствует тому, что используется в QА на серверах, а в новой функционала в два раза больше. И если лишнее отключить, то тесты проходят на ура.
Обращаемся к начальнику QA, коллеге D: какой набор функционала более “правильный”? Тот говорит, что абсолютным источником правды является публичный сервер. А как программно поменять этот набор функционала? Не знает.
Я иду к коллеге-старожилу С из команды бэк-офиса, который имеет доступ к производственным серверам. Его нет. Смотрю его календарь - у него весь день под завязку забит совещаниями. Сообщаю о своём “прогрессе” по вопросу на утренней пятиминутке нашей команды. В тот же день у нашего отдела было совещание по планированию работы на месяц. Посреди совещания сквозь стеклянную стену замечаем проходящего коллегу С. Мои парни хором: Ольга, беги за ним!
Отлавливаю коллегу C, тот показывает мне админку производственного сервера. Выясняется, что наша новая виртуальная машина почти в точности повторяет то, что работает в производстве.
Но откуда оно у меня?! И почему раньше было по-другому, ведь я в этом куске кода провиженинга ничего не трогала и другие тоже. Тут натыкаюсь на коллегу E, из моей команды, который говорит: да это ж я сливал конфигурацию с производственных серверов, чтобы всё унифицировать. Да? А почему все машинки в облаке, даже самые свежие, имеют нормальный (урезанный) набор функционала? Ах… оказывается они его нововведение 3-х месячной давности не используют. Никто не заметил!
Ладно, проехали. Как это всё починить-то? Последним узнаёт о проблеме коллега B. Он тоже старожил, хотя один из самых молодых в команде. Объяснили вдвоём с E ему ситуацию, минут 15 поспорили, как же всё должно быть. Хорошо бы в конфигурации виртуалок повторять конфигурацию производства, да выясняется одно “но” - многие тесты требуют определенной конфигурации. По-хорошему их нужно переписать, чтобы такого не происходило, но в мою задачу это точно не входит.
Что делать? Коллега B показал, откуда взять рабочую конфигурацию и как её поменять, я дописала в код провиженинга добавление этой конфигурации. Новая виртуальная машина готова.
Выводы: потребовалось шесть человек (A, B, C, D, E и я), чтобы идентифицировать проблему, найти приемлемое решение и его имплементировать. Ни один из нас в одиночку не смог бы с ней разобраться. В результате нескольких дней коммуникации сразу несколько человек теперь знают, что у нас с конфигурацией, почему, на что это влияет, какие шаги следует предпринять, чтобы ситуацию улучшить и как это тестировать. Эта задача зависла бы на многие недели, если бы я пыталась её решить “силой мысли”, сидя за закрытыми дверями.
Итак задача: запилить новую виртуальную машину для разработчиков. Критерии приёмки: все тесты продукта, которые успешно выполнялись на старой машине, должны выполняться и на новой.
Делаю бокс, выкладываю на сервер, говорю парню A из QA, где взять обновленный Vagrantfile. Коллега A запускает тесты и говорит “у меня половина не проходит”. Но он это дело не бросает, а прикладывает некоторое количество усилий, чтобы выяснить, чем новая виртуалка принципиально отличается от старой. И замечает, что количество функционала в административной панели старой и новой виртуалок отличается радикально. Старая соответствует тому, что используется в QА на серверах, а в новой функционала в два раза больше. И если лишнее отключить, то тесты проходят на ура.
Обращаемся к начальнику QA, коллеге D: какой набор функционала более “правильный”? Тот говорит, что абсолютным источником правды является публичный сервер. А как программно поменять этот набор функционала? Не знает.
Я иду к коллеге-старожилу С из команды бэк-офиса, который имеет доступ к производственным серверам. Его нет. Смотрю его календарь - у него весь день под завязку забит совещаниями. Сообщаю о своём “прогрессе” по вопросу на утренней пятиминутке нашей команды. В тот же день у нашего отдела было совещание по планированию работы на месяц. Посреди совещания сквозь стеклянную стену замечаем проходящего коллегу С. Мои парни хором: Ольга, беги за ним!
Отлавливаю коллегу C, тот показывает мне админку производственного сервера. Выясняется, что наша новая виртуальная машина почти в точности повторяет то, что работает в производстве.
Но откуда оно у меня?! И почему раньше было по-другому, ведь я в этом куске кода провиженинга ничего не трогала и другие тоже. Тут натыкаюсь на коллегу E, из моей команды, который говорит: да это ж я сливал конфигурацию с производственных серверов, чтобы всё унифицировать. Да? А почему все машинки в облаке, даже самые свежие, имеют нормальный (урезанный) набор функционала? Ах… оказывается они его нововведение 3-х месячной давности не используют. Никто не заметил!
Ладно, проехали. Как это всё починить-то? Последним узнаёт о проблеме коллега B. Он тоже старожил, хотя один из самых молодых в команде. Объяснили вдвоём с E ему ситуацию, минут 15 поспорили, как же всё должно быть. Хорошо бы в конфигурации виртуалок повторять конфигурацию производства, да выясняется одно “но” - многие тесты требуют определенной конфигурации. По-хорошему их нужно переписать, чтобы такого не происходило, но в мою задачу это точно не входит.
Что делать? Коллега B показал, откуда взять рабочую конфигурацию и как её поменять, я дописала в код провиженинга добавление этой конфигурации. Новая виртуальная машина готова.
Выводы: потребовалось шесть человек (A, B, C, D, E и я), чтобы идентифицировать проблему, найти приемлемое решение и его имплементировать. Ни один из нас в одиночку не смог бы с ней разобраться. В результате нескольких дней коммуникации сразу несколько человек теперь знают, что у нас с конфигурацией, почему, на что это влияет, какие шаги следует предпринять, чтобы ситуацию улучшить и как это тестировать. Эта задача зависла бы на многие недели, если бы я пыталась её решить “силой мысли”, сидя за закрытыми дверями.