Так как это одноразовый прототип, я не стал запускать работу во фреймворке NaCl - это излишне. Само задание является достаточно полной спецификацией, для MVP будет достаточно уровня технических задач. Поэтому использую оркестратор (https://github.com/ITSalt/PepperSkills/tree/e1134fdf92346a2911163042b74d8a47b7831b46/plugins/pepper-orchestrator) для реализации MVP.
Запуск и планирование
1. Время: 11:40. Запускаем инициацию программы, отвечаем на вопросы
2. Перезапускаем оркестратора с необходимыми правами
Запускаем планирование задач по разработке
Отвечаем на ключевые вопросы:
Процесс разбиения спецификации на технически задачи запущен. Время: 11:54
Планирование заверешено, оркестратор рассказывает план:
Получаем от оркестратора команду для запуска рабочей сессии и запускаем в отдельном терминале:
Параллельно задаём оркестратору вопрос по возможному ускорению и возможности параллельного запуска задач. Это лучше делать уже после планирования - так у оркестратора есть весь необходимый контекст. Принцип “разделение задач” в действии.
Отвечаю “да”, оркестратор выполняет необходимые настройки и уведомляет рабочую сессию о произошедших изменениях самостоятельно:
Оркестратор перестроил план на параллельное выполнение
Вот так выглядит рабочее пространство с запущенным оркестратором и сессиями, которыми он управляет:
Время 12:05, оркестратор управляет процессом:
Время 12:11, первые артефакты приянты:
12:14. Агенты общаются между собой, а я прошу включить в план создание скриншотов при тестировании, чтобы посмотреть на то решение, которое будет при первом запуске и в самом конце, когда оркестратор объявит программу выполненной. Самому интересно какова будет пропасть между этими запусками :)
Оркестратор отчитывается о выполненной задаче и предлагает узнать, сколько времени осталось из дедлайна. Мечта любого чайка-менеджера :)
Я не стал просить оценить время, по моему опыту - это бессмысленно, агенты сильно ошибаются в оценках. Чтобы они оценивали время реалистично, им нужны реальные точки опоры, реальные в плане замеров на конкретных задачах. Таким образом, можно сделать оценку сопоставимых действий более-менее точной. В этом проекте мы таких опор не задавали, поэтому оценку времени я не прошу его делать.
Разработка и независимое ревью
12:18 - на ревью пришёл первый код. Оркестратор запустил сабагента с чистым контекстом, который независимо ревьювит код:
12:22 - оркестратор принял код дизайн-системы по заключению ревьювера
12:28 - независимая проверка даёт свои результаты. Оркестратор вернул на доработку движок. Причём, разостно потирая ручки, мол, сам агент движка лажанулся, несмотря на свои 53 теста, а мои падаваны всё обнаружили :)
12:37 - движок принят. Попутный оркестратор нашел ситуацию, которую воспринимает как баг самого скилла оркестратора. В репозитории можно завести issues, там есть специальная инструкция, как это делать, и все такие issues проходят независимый разбор и ревью. Что-то действительно является багами, а что-то является глюками. Соответственно, я прошу оформить issue моего агента-оркестратора.
Саморефлексия агентов. Агент-разработчик попытался сделать пуш, но у него не получилось. Он пожаловался оркестратору. Оркестратор почесал репу, говорит: «Да, тебе пуш запрещен», но зато придумал обходной путь, как это сделать. Пока я не очень понимаю, как к этому относиться. С одной стороны, это хорошо, что агенты ищут обходные пути. С другой стороны, возможно, некорректно настроены права. В общем, это пока еще остается полем для размышления и потенциального улучшения скиллов оркестратора
Первые экраны и три клиента
12:58 - прошли первые визуальные тесты в браузере
Всего 10 скриншотов. На первый взгляд выглядят адекватно.
13:25 - агенты пишут README на основе реального поведения системы
Попутно выясняется, что от меня ждут ответа на вопрос Р-1. Пытаюсь склонить оркестратора решить его самостоятельно, так как совершенно неохота погружаться в контекст и принимать какие-то решения :) Оркестратор ставит меня в очередь! Хорошо ещё, что талончик с номерком не выдал и музыку не заиграл :)
Но через некоторое время отвечает достаточно развёрнуто. Попутно предлагает закрыть программу, так как по его мнению всё сделано. Время - 13:32
Соглашаемся с выводами и рекомендациями. Но закрывать программу, на мой взгляд, еще рано. Сначала нам нужна каверза, диверсия и старуха Шапокляк. Ставим задачу посмотреть на задание глазами трех персонажей. Первый клиент будет лояльный и адекватный: он будет выполнять и проверять ровно так, как написано в исходном задании, не пытаясь нас завалить. Второй клиент — это классический «я не знаю, что вы тут наделали и что было в задании, но я хочу, чтобы это работало так, как я хочу»: он будет пытаться выполнять любые свои собственные задачи, тыкая в наши кнопочки, то есть мы должны проверить, условно, защиту от дурака. Третий клиент — это будет даже не клиент, а наш конкурент, который захочет нас завалить и будет придумывать самые каверзные проверки, которые формально должны оставаться в контексте задания, но при этом могут выходить за рамки описанного.
13:40 - процесс тестирования методом старухи Шапокляк в полном разгаре:
13:42 - лояльный клиент, ожидаемо, прошел все проверки с небольшим замечанием по интерфейсу. Ждём двух других героев
Доработки после приёмки
14:03 - пока я пил кофе, оркестратор прогнал все тесты. В целом, не всё так плохо, по идее, можно уже и сдаваться:
К исправлению берём не всё, оставляем мелочи просто списком в Readme. Заодно проверим правильност поговорки “лучшее враг хорошего” :)
14:16. Отвечаем на вопросы оркестратора, которые пришли от агента планирования. Если честно - беру просто рекомендованные значения, так как не готов глубоко вникать в суть для выполнения этого задания. Ну, и интересно проверить, что будет, если я буду просто “оператором кнопки Next” :)
14:20 - план готов, первый агент-разработчик получил задание пошёл работать. Оркестратор предусмотрел отключение разработки фичей, если будем не укладываться в срок. Я бы сделал так же.
14:33 - агент всё программирует. Задал свой любимый вопрос про ускорение через параллелизацию. Оркестратор выдал команду, запустил новую параллельную сессию. Самого оркестратора отправил готовиться к тестам, раз он сам об этом сообщил. Да, да, здесь инициатива тоже наказуема действием :)
14:37 - движок закончил изменения, сдался оркестратору, тот запустил тесты.
15:00 Получили первые тесты обновлённого функционала. На удивление, хуже не стало!
Прошу ускориться, чтобы уложиться в дедлайн
Надо также понимать, что эти проверки упираются в производительность самой машины, потому что запускаются скрипты, которые загружают память и процессор. Плюс эмуляция браузера тоже отнимает некисло ресурсов, а на моей машине работает другие проекты. Так что в целом разработку можно ускорить, просто улучшив железо.
Инфраструктура и дедлайн
15:19. За функционал я спокоен, но у меня остался ещё один “больной зуб”, который хочется проверить перед тем, как грызть яблоки в промышленных масштабах. Прошу агента проверить инфраструктурную часть с которой столкнётся клиент при проверке нашей работы.
И тут вылезает то самое пресловутое “горе от ума”. Торможу разогнавшегося оркестратора, упрощая задачу. Остаётся 20 минут, ладошки начинают потеть :)
Рабочая лошадка, закусив удила и разбрасывая пену с боков, пытается вывезти:
А оркестратор начинает ошибаться, спеша выполнить задачу. Всё как у людей
15:30. Оркестратор выдаёт утешительные новости, мол, всё почти в порядке. Правда, глядя в экран не особо им веришь :)
15:32. На самом деле всё достаточно хорошо и упираемся мы именно в лимиты машины, а не в логические цепочки. Агент предупреждает о превышении срока и это говорит о том, что я как менеджер справился со своей задачей плохо.
Принимаю управленческое решение - передать работу в том виде, что есть сейчас. Прошу агента подготовить всё к выкладке:
15:39 - Мы готовы к сдаче
Но работы по тестированию ещё продолжаются.
15:47 - материалы прибывают
15:54 - фоновый прогон тестов всё ещё идет
А ещё бывает, что агенты-исполнители не подчиняются своему оркестратору и “стучат” на него шефу. Приходится спускаться с олимпа и собственноручно подтверждать решения своего ставленника:
Последние проверки и завершение
16:14 - интересуюсь состоянием дел. Принимаю решение “сливаться”
16:37 - все тесты аки дубайский шоколад: зелёненькие :) Осталась последняя проверка - чистый запуск.
17:05. Программа завершена и закрыта
Итоги
Самое время подвести итоги:
- За 4 часа собрать такое приложение не составляет труда. Я сознательно выбрал делать его только на фронтенде, тем самым упростив работу - не нужно было синхронизировать бэк и фронт. Понятно, что при масштабировании бэк потребуется, особенно, если нужно будет сохранять какие-то данные, а не просто делать шпаргалки.
- Я, как менеджер, отработал плохо. Нужно было после прогона тремя персонажами не делать доработок, подготовить задачу к передаче клиенту, а только после этого делать доработки.
- Истина “лучшее враг хорошего” снова успешно подтверждена :)