The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
В этом посте я постараюсь рассказать вам о проекте, управляемом с духом разработки на основе головоломок (Puzzle Driven Development, PDD). При этом я попытаюсь передать типичные точки зрения различных участников проекта.
В общем, в любой команде разработки программного обеспечения есть несколько ключевых ролей:
Системный аналитик — документирует идеи владельца продукта.
Архитектор - определяет, как взаимодействуют компоненты системы.
Designer - реализует наиболее сложные компоненты.
Программист — реализует все компоненты.
Тестировщик — находит и сообщает ошибках
Все, кроме руководителя проекта, влияют на проект двумя способами: они исправляют его и одновременно ломают. Позвольте мне объяснить это на простом примере.
Давайте предположим, для простоты, что проект - это простой программный инструмент, написанный мной для близкого друга. Я создал первую черновую версию 0.0.1 и передал ее ему. Для меня проект закончен. Я выполнил работу и, надеюсь, больше никогда не придется возвращаться к ней.
Однако реальность проекта совсем иная. Через несколько часов я получаю звонок от друга, говорящего, что обнаружил несколько ошибок в инструменте. Он просит меня их исправить. Теперь я понимаю, что проект не закончен. Фактически, он сломан. В нем есть несколько ошибок, что означает несколько задач для выполнения.
Я собираюсь исправить проект, устраняя ошибки. Я создаю новую версию программного обеспечения, называю ее 0.0.2 и отправляю другу. Опять же, я считаю, что мой проект закончен. Он исправлен и должен быть закрыт.
Этот сценарий повторяется снова и снова, пока друг перестает звонить мне. Другими словами, пока он перестает ломать мой проект.
Очевидно, что чем больше друг ломает мой проект, тем выше качество программного обеспечения, которое в конечном итоге будет доставлено. Версия 0.0.1 была только очень предварительной версией, хотя я считал ее окончательной в то время, когда выпустил ее. Через несколько месяцев, после того как я узнаю и исправлю сотни ошибок, версия 3.5.17 станет намного более зрелой и стабильной.
Это результат такого подхода “исправить и сломать”.
Диаграмма показывает связь между временем и беспорядком в проекте. Ошибки, о которых мой друг сообщает мне, ломают проект, увеличивая его нестабильность (или просто беспорядок). Новые версии, которые я выпускаю, исправляют ошибки и исправляют проект. Динамика ваших коммитов в GitHub должна напоминать этот график, например:
Когда проект только запускается, беспорядок в нем достаточно низкий, а затем начинает расти. Беспорядок достигает своего пика и начинает снижаться.
проблемы, недочеты, несоответствия, погрешности и другие неполадки, которые могут возникнуть во время выполнения проекта. Когда я говорю о “bugs” (багах), я имею в виду не только ошибки в программном обеспечении, но и все возможные проблемы и несоответствия, которые могут возникнуть в проекте.
функции еще не реализованы
функциональные и нефункциональные ошибки
отсутствие тестового покрытия
нерешенные маркеры
@todoотсутствие анализа рисков
etc.
Руководитель проекта дает мне задания, которые он хочет выполнить, чтобы исправить и стабилизировать проект и вернуть его в состояние без ошибок.
Моя работа, как участника программной команды, заключается в том, чтобы помочь ему выполнить необходимые исправления и в то же время сделать все возможное, чтобы разрушить проект! В примере с моим другом он постоянно разрушал проект, сообщая мне об ошибках. Таким образом, он помогал нам обоим повысить конечное качество продукта.
Я должен делать то же самое и всегда пытаться сообщать о новых ошибках, когда работаю над определенной функцией. Я должен исправлять и разрушать одновременно.
Теперь давайте ближе рассмотрим роли в проекте.
Владелец продукта отправляет неформальный запрос на функцию, который обычно начинается со слов “было бы неплохо иметь…”. Я системный аналитик, и моя задача - перевести английский язык владельца на формальные спецификации в СТЗ, понятные как программистам, так и мне самому. Моя ответственность не включает реализацию функции.
Моя задача завершена, когда новая версия СТЗ подписана Бордом контроля изменений. Я переводчик для владельцев продукта, переводящий из их языка на формальный язык, необходимый в документе СТЗ. Моим единственным клиентом является владелец продукта. Как только она закрывает запрос на функцию, мне выплачивается вознаграждение.
Помимо запросов на функции от владельцев продукта, я часто получаю жалобы на качество СТЗ. Документ может быть недостаточно понятным для некоторых участников команды. Поэтому моя задача - устранить проблемы с ясностью и исправить СТЗ. Эти участники команды также являются моими клиентами. Когда они закрывают свои сообщения об ошибках, мне выплачивается вознаграждение.
В обоих случаях (запрос на функцию или ошибка) я могу сразу вносить изменения в СТЗ - если у меня есть достаточно времени. Однако это не всегда возможно. Я могу отправить сообщение об ошибке и ждать ее устранения, но я не хочу заставлять своих клиентов ждать.
В этом мне помогает разработка, основанная на головоломках. Вместо отправки сообщений об ошибках я добавляю в документ СТЗ головоломки “[TBD] (https://ru.wikipedia.org/wiki/To_be_announced)”. Головоломки - это неформальные замены обычно очень строгих формальных требований. Они удовлетворяют моего клиента, так как написаны на простом английском языке и понятны техническим специалистам.
Таким образом, когда у меня нет времени, я не жду. Я изменяю СТЗ, используя головоломки там, где я не могу создать правильное и формальное описание требований или просто не знаю, что именно написать.
Теперь я архитектор, и моя задача - реализовать требование, которое было формально определено в СТЗ. РП ожидает от меня работающую функцию, которую я могу предоставить только тогда, когда архитектура станет ясной, и классы будут разработаны и реализованы.
Как архитектор, я отвечаю за сборку всех компонентов вместе и убеждаюсь, что они соответствуют. В большинстве случаев я сам их не создаю, но я рассказываю всем, как их следует создавать. Мой рабочий процесс состоит из следующих артефактов:
[СТЗ] -> [UML] [UML] -> [Исходный код]
Я получаю требования из СТЗ, создаю диаграммы UML и объясняю дизайнерам, как создавать исходный код в соответствии с моими диаграммами. Мне на самом деле не важно, как реализован исходный код. Меня больше интересует взаимодействие компонентов и то, насколько хорошо вся архитектура удовлетворяет функциональным и нефункциональным (!) требованиям.
Моя задача будет закрыта и оплачена, когда системный аналитик изменит ее состояние на “реализовано” в СТЗ. Системный аналитик - мой единственный клиент. Мне нужно продать ему свое решение. Руководитель проекта закроет мою задачу и оплатит меня, когда системный аналитик изменит статус функционального требования с “определено” на “реализовано”.
Задача звучит большой, и у меня есть всего полчаса. Очевидно, что подход, основанный на головоломках, должен мне помочь. Я создам много тикетов и головоломок. Например:
Нефункциональные требования не ясны.
UML-диаграммы недостаточно понятны.
Компоненты не реализованы.
Сборка не автоматизирована.
Непрерывная интеграция не настроена.
Качество кода не находится под контролем.
Тестирование производительности не является автоматизированным.
Когда все мои головоломки будут разрешены, я смогу вернуться к основной задаче и завершить реализацию функции. Очевидно, что это может занять длительное время - дни или даже недели.
Но затраты времени на основную задачу составляют менее часа. В чем смысл всей этой тяжелой работы? Все просто; я заработаю свои часы на основе всех сообщенных ошибок. Из этой небольшой полуторачасовой задачи я создам много тикетов, и каждый из них принесет мне дополнительные деньги.
Единственные реальные различия между дизайнером и программистом заключаются в сложности их задач и часовой ставке, которую они получают. Дизайнеры обычно выполняют более сложные и высокоуровневые задачи, в то время как программисты реализуют все низкоуровневые детали.
Я программист, и моя задача - реализовать класс или метод или исправить функциональную ошибку. В большинстве случаев у меня есть всего полчаса. И, как правило, задачи больше и требуют больше времени, чем это.
Разработка на основе головоломок помогает мне разбить мою задачу на более мелкие подзадачи. Я всегда начинаю с модульного теста. В модульном тесте я пытаюсь воспроизвести ошибку или моделировать функцию. Когда мой тест не проходит, я фиксирую его и определяю, сколько времени у меня осталось. Если у меня еще есть время, чтобы сделать его проходящим - я делаю это, фиксирую изменения и сообщаю руководителю проекта.
Если у меня нет времени для реализации исправления, я помечаю участки кода, которые еще не имеют маркеров @todo, фиксирую их и сообщаю руководителю проекта, что я закончил.
Как видите, я исправляю код и одновременно его ломаю. Я исправляю его с помощью нового модульного теста, но ломаю его с помощью головоломок @todo.
Таким образом, я помогаю повысить общее качество проекта - исправляя и ломая одновременно.
Я тестировщик, и моя основная мотивация - находить ошибки. Это может противоречить тому, что вы раньше слышали, но в XDSD мы планируем находить определенное количество ошибок на каждом этапе проекта.
Как тестировщик, я получаю задачи от моего менеджера проекта. Эти задачи обычно заключаются в том, чтобы “проверить функцию X и найти в ней 10 ошибок”. Менеджер проекта нуждается в определенном количестве ошибок, чтобы исправить проект. С его точки зрения, проект считается исправленным, когда, скажем, найдено 200 ошибок. Вот почему он просит меня найти больше.
Таким образом, чтобы откликнуться на запрос, я нахожу ошибки, чтобы выполнить свою часть в рамках “исправления” в большой картине. В то же время, я могу найти дефекты самостоятельно и сообщить о них. Это “нарушение” части моей миссии.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:14
