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). При этом я попытаюсь передать типичные точки зрения различных участников проекта.
В основном, в любой команде разработки программного обеспечения есть несколько ключевых ролей:
Проектный менеджер — назначает задачи и выплачивает вознаграждение по завершении.
Системный аналитик — документирует идеи владельца продукта.
Архитектор определяет взаимодействие компонентов системы.
Дизайнер — реализует самые сложные компоненты.
Программист — реализует все компоненты.
Тестер — находит и сообщает ошибках.
Каждый, кроме менеджера проекта, влияет на проект двумя способами: они исправляют его и одновременно ломают. Позвольте мне объяснить это на простом примере.
Fix and Break
Давайте, для простоты, предположим, что проект - это простой программный инструмент, написанный мной для близкого друга. Я создал первую черновую версию 0.0.1 и передал ее ему. Для меня проект закончен. Я выполнил работу и, надеюсь, больше не придется к ней возвращаться.
Однако реальность проекта совсем иная. Через несколько часов я получаю звонок от друга, который говорит, что он обнаружил несколько ошибок в инструменте. Он просит меня исправить их. Теперь я вижу, что проект еще не закончен. На самом деле, он сломан. В нем есть несколько ошибок, что означает несколько задач для выполнения.
Я собираюсь исправить проект, устранить ошибки. Я создаю новую версию программного обеспечения, называю ее 0.0.2 и отправляю другу. Опять же, я считаю, что мой проект закончен. Он исправлен и должен быть закрыт.
Этот сценарий повторяется снова и снова, пока друг не перестает звонить мне. Другими словами, пока он не перестает ломать мой проект.
Очевидно, что чем больше друг ломает мой проект, тем выше качество программного обеспечения, которое в конечном итоге будет доставлено. Версия 0.0.1 была всего лишь очень предварительной версией, хотя я считал ее окончательной в момент ее выпуска. Через несколько месяцев, после того, как я узнаю и исправлю сотни ошибок, версия 3.5.17 будет намного более зрелой и стабильной.
Это результат такого подхода “исправить и сломать”.
Диаграмма показывает связь между временем и беспорядком в проекте. Ошибки, о которых сообщает мой друг, ломают проект, увеличивая его нестабильность (или просто его беспорядочность). Новые версии, которые я выпускаю, исправляют ошибки и восстанавливают проект. Ваши динамики коммитов на GitHub должны быть похожи на этот график, например:
Когда проект начинается, его беспорядочность довольно низкая, а затем начинает расти. Беспорядочность достигает своего пика и начинает снижаться.
Project Manager
Проектный менеджер должен сделать все возможное, чтобы исправить проект. Он должен использовать время и деньги спонсора, чтобы устранить все ошибки и несоответствия и вернуть проект в «исправленное» состояние.
Когда я говорю о «ошибках», я имею в виду не только ошибки программного обеспечения, но и:
неясные или двусмысленные требования
“функции еще не реализованы”
функциональные и нефункциональные ошибки
недостаток тестового покрытия
неразрешенные маркеры
@todoотсутствие анализа рисков
etc.
Руководитель проекта дает мне задачи, которые он хочет выполнить, чтобы исправить и стабилизировать проект и вернуть его в безошибочное состояние.
Моя работа, как участника программной команды, заключается в том, чтобы помочь ему выполнить необходимые исправления и, в то же время, сделать все возможное, чтобы сломать проект! В примере с моим другом, он постоянно ломал проект, сообщая мне об ошибках. Таким образом, он помогал нам обоим повысить конечное качество продукта.
Я должен сделать то же самое и всегда пытаться сообщать о новых ошибках, когда я работаю над некоторой функцией. Я должен исправлять и ломать одновременно.
Теперь давайте ближе рассмотрим роли в проекте.
System Analyst
Владелец продукта отправляет неформальный запрос на функциональность, который обычно начинается со слов “было бы хорошо иметь…”. Я - системный аналитик, и моя задача - перевести английский владельца на формальные спецификации в SRS, понятные как программистам, так и мне самому. Моя ответственность не включает реализацию функциональности.
Моя задача считается выполненной, когда новая версия SRS подписана контрольной комиссией по изменениям. Я выступаю в роли переводчика для владельцев продукта, переводя их язык на формальный язык, необходимый в документе SRS. Моим единственным клиентом является владелец продукта. Как только она закрывает запрос на функциональность, я получаю оплату.
Помимо запросов на функциональность от владельцев продукта, я часто получаю жалобы на качество SRS. Документ может быть недостаточно понятным для некоторых членов команды. Поэтому моя задача - устранить проблемы с ясностью и исправить SRS. Эти члены команды также являются моими клиентами. Когда они закрывают свои сообщения об ошибках, я получаю оплату.
В обоих случаях (запрос на функциональность или ошибка) я могу вносить изменения в SRS немедленно - если у меня есть достаточно времени. Однако это не всегда возможно. Я могу отправить сообщение об ошибке и ждать ее устранения, но я не хочу заставлять своих клиентов ждать.
В этом мне помогает разработка на основе головоломок. Вместо отправки сообщений об ошибках я добавляю в документ SRS головоломки “TBD”. Головоломки являются неформальной заменой обычно очень строгим формальным требованиям. Они удовлетворяют моего клиента, так как написаны простым английским языком и понятны техническим специалистам.
Таким образом, когда у меня нет времени, я не жду. Я изменяю SRS с помощью головоломок там, где я не могу создать правильное и формальное описание требований или просто не знаю, что именно написать.
Architect
Сейчас я архитектор, и моя задача - реализовать требование, которое было формально описано в SRS. PM ожидает от меня работающую функцию, которую я могу предоставить только тогда, когда архитектура ясна, и классы были спроектированы и реализованы.
В своем качестве архитектора я отвечаю за сборку всех компонентов и убеждаюсь, что они подходят друг другу. В большинстве случаев я не создаю их сам, но я говорю всем, как они должны быть созданы. Мой рабочий процесс артефактов следующий:
[SRS] -> [UML] [UML] -> [Исходный код]
Я получаю требования из SRS, создаю диаграммы UML и объясняю дизайнерам, как создавать исходный код в соответствии с моими диаграммами. Мне не важно, как реализован исходный код. Меня больше интересует взаимодействие компонентов и то, насколько хорошо вся архитектура удовлетворяет функциональным и нефункциональным (!) требованиям.
Моя задача будет закрыта и оплачена, когда системный аналитик изменит ее статус на “реализовано” в SRS. Системный аналитик - мой единственный клиент. Мне нужно продать ему свое решение. Менеджер проекта закроет мою задачу и заплатит мне, когда системный аналитик изменит статус функционального требования с “указано” на “реализовано”.
Задача звучит большой, а у меня есть всего полчаса. Очевидно, что метод “разработка пазлов” должен помочь мне. Я буду создавать множество тикетов и головоломок. Например:
SRS не объясняет требования должным образом.
Нефункциональные требования не ясны.
UML диаграммы недостаточно понятны.
Компоненты не реализованы.
Сборка не автоматизирована.
Непрерывная интеграция не настроена.
Качество кода не под контролем.
Тестирование производительности не автоматизировано.
Когда все мои головоломки решены, я смогу вернуться к основной задаче и завершить реализацию новых функций. Очевидно, это может занять много времени - дни или даже недели.
Однако, время, затраченное на основную задачу, составляет менее часа. В чем смысл всей этой тяжелой работы? Все просто: я заработаю свои часы на основе всех ошибок, которые будут докладывать. Из этой небольшой полуторачасовой задачи я сгенерирую множество заявок, и каждая из них принесет мне дополнительные деньги.
Designer and Programmer
Единственная настоящая разница между дизайнером и программистом заключается в сложности их задач и почасовой ставке, которую они получают. Дизайнеры обычно занимаются более сложными и высокоуровневыми задачами, в то время как программисты реализуют все низкоуровневые детали.
Я программист и моя задача заключается в реализации класса, метода или исправлении функциональной ошибки. В большинстве случаев у меня есть только полчаса свободного времени. И, как правило, задачи более объемные и требуют больше времени, чем это.
Разработка на основе головоломок помогает мне разбить задачу на более мелкие подзадачи. Я всегда начинаю с модульного теста. В модульном тесте я пытаюсь воспроизвести ошибку или смоделировать функцию. Когда мой тест не проходит, я фиксирую его и определяю, сколько времени у меня осталось. Если у меня все еще есть время, чтобы сделать его проходящим – я делаю это, фиксирую изменения и докладываю руководителю проекта.
Если у меня нет времени для реализации исправления, я помечаю куски кода, которые еще не имеют маркеров @todo, фиксирую их и сообщаю руководителю проекта, что я закончил.
Как видите, я исправляю код и одновременно его ломаю. Я исправляю его с помощью нового модульного теста, но ломаю с помощью головоломок @todo.
Таким образом, я помогаю повысить общее качество проекта - исправляя и ломая его одновременно.
Tester
Я тестировщик и моя основная мотивация - находить ошибки. Это может противоречить тому, что вы слышали раньше; но в XDSD мы планируем находить определенное количество ошибок на каждом этапе проекта.
Как тестировщик, я получаю задачи от моего менеджера проекта. Эти задачи обычно заключаются в том, чтобы “проверить функцию X и найти в ней 10 ошибок”. Менеджеру проекта необходимо, чтобы было найдено определенное количество ошибок для исправления проекта. С его точки зрения, проект исправлен, когда, скажем, найдено 200 ошибок. Вот почему он просит меня найти больше.
Таким образом, чтобы откликнуться на запрос, я нахожу ошибки, чтобы выполнить свою часть в связи с “исправлением” части общей картины. В то же время, я могу находить дефекты самостоятельно и сообщать о них. Это “разрушающая” часть моей миссии.
Translated by ChatGPT gpt-3.5-turbo/36 on 2023-10-01 at 08:18
