Степень разработчика зависит от его знаний и опыта. Чем сложнее проект, в котором вы участвуете, тем больший ад вам предстоит пройти из-за высокой нагрузки, специфических требований, ограничений и монстра с лицом общей сложности проекта.
Но каждый хороший проект становится большим, каждый успешный проект растет, и в любом случае это может быть тот самый монстр. Если вы будете выращивать его неправильно, он может стать неподвижным зверем, поэтому давайте сделаем это правильно, шаг за шагом.
И помните, мы, разработчики программного обеспечения, должны думать о качестве, а не обо всех других вещах, таких как стоимость или сроки. Работодатель нанял нас для нашей работы хорошо.
Эй, я хочу!
Типичный проект имеет такой жизненный цикл:
- Сначала идет MVP версия проекта, т.е. минимальный проект, способный жить и удовлетворять заказчика, это самое начало для любого проекта.
- Проект должен быть изменен, чтобы предоставить новые функции в интересах бизнеса и клиентов. Он также призывал подать CR, запросы на изменение, а затем предоставить новую версию проекта.
- Выпущена новая версия продукта, доставлена клиентам.
…а затем цикл 2–3–2–3–2–3 становится бесконечным, проект растет шаг за шагом.
Это выглядит довольно просто и легко, но проблема скрывается между шагами, где наше совершенство (мы как инженеры должны думать о совершенстве) может стать ловушкой.
Мы сделали это неправильно?
Я работал с несколькими крупными проектами (2 миллиона клиентов с реальными устройствами, более 100 городов и более 1000 населенных пунктов), а также с кучей средних проектов для крупных компаний (национальные железные дороги, операторы мобильной связи и т. д.), и некоторые из их проекты умерли.
Мы потратили часы на ретроспективы причин, размышляя о своих слабостях и проблемах в процессах, и выяснили несколько основных способов убить проект:
- Игнорировать технический долг, также известный как Привет! Мы сделаем это позже! И это тоже! А это… А это… У нас нет времени…. ооо, уже слишком поздно…
- Игнорируйте рефакторинг в пользу времени/стоимости, иначе Эй! Нам это нужно сейчас! Нет времени ни на что, кроме этой задачи! …а потом наш проект становится сильно связанной недвижимой вещью.
- Игнорировать процесс и сделать это неправильно или Мы не закончили тесты? Нет проблем, я уверен, что это работает! Отправьте!
Таких причин масса, но ключ к тому, чтобы избежать проблем, заключается в том, чтобы выполнять работу постепенно, без сделок, где это возможно. Никаких технических долгов, никакого игнорирования чего бы то ни было, постепенно становись лучше (процессы, инструменты и т.д.), и делай все по инструкции.
По моему опыту, большинство проектов умерло именно по этим причинам.
Что делать?
Круто, теперь мы знаем, что должны делать все хорошо (ха-ха, чтобы делать все правильно… делать все правильно!), но что это?
Прежде всего, это процесс. На моей последней работе мы могли охватить все (каждое изменение в нашей системе), что нам нужно сделать, в следующих шагах:
- Получить требования (общие требования от клиента)
- Преобразование требований в описание решения, т.е. документ, описывающий, как система должна вести себя в результате (без технических подробностей) и что мы должны сделать для его достижения (изменения в существующей системе и т. д.).
- Получите одобрение этого описания от заказчика. Обычно это может занять несколько месяцев (документ может ходить между 10 компаниями, техническими командами, и все они должны быть удовлетворены и иметь свои комментарии; каждый комментарий запускает новый цикл в этом процессе).
- Преобразуйте Описание решения в Техническое задание. Мы конвертируем написанное человеком высокоуровневое описание задачи в низкоуровневые сущности, отношения между ними, то есть в технические термины и описания алгоритмов. Лучше запишите блок-схемы пользовательских историй и пользовательские сценарии (см. Корнишон и Пользовательская история).
- Отправить техническое задание ответственной команде и разбить ее между собой, спланировать работу.
- Начать работу под новым требованием или изменением в системе. При этом вы будете возвращаться к шагам 2–4 из-за несоответствия документов реальной системе или из-за каких-то забытых вещей в документах, а иногда и они блокируют задание, и вы должны разрешить их, чтобы продолжить разработку в соответствии с этим требованием.
- Создать набор тестов можно, чтобы убедиться, что система работает должным образом. Иногда это могут быть автоматизированные тесты, иногда нет, но всегда нужно перечислять эти тесты в документах как тесты. система должна пройти, в результате чего клиент принимает ваш продукт.
- Получить согласование с заказчиком, какие требования должна пройти получившаяся система, чтобы продукт считался готовым. Если ваша система пройдет эти тесты, заказчик должен подписать акт, а затем заплатить вам деньги.
- Проведите демонстрацию клиенту, пройдите тесты и получите список ошибок. Это список всех проблем, которые они обнаружили во время тестирования (по списку с этими тестами выше), с приоритетами (фатальные, критические, основные, второстепенные вопросы).
- Исправьте свой проект по списку ошибок и перейдите к шагу 9, и выполняйте эти шаги, пока ваш проект не пройдет все тесты успешно (т.е. без незначительных проблем).
- Подпишите акт о том, что ваше изменение успешно внедрено и работает.
- Доставка продукта клиентам (развертывание в Интернете, установка программного обеспечения и т. д., в зависимости от проекта).
Итак, есть много шагов, да… И они могут зависеть от контрактов, требований, специфики, но эти шаги основаны на моем опыте и могут быть полезны для вас.
И самое главное для нас — если вы будете нарушать какие-то из них, то у проекта будут проблемы. Могут возникнуть забытые требования, ошибки, поддержка, проблемы с обслуживанием, всевозможные проблемы.
Мол, если вы не утвердите какой-либо документ, то вы рискуете сделать что-то не так (не так, как положено), а может быть, вам нужно будет что-то стереть и сделать заново, как должно быть.
Или, если вы не будете использовать тесты, вы не можете быть уверены, что ваша система работает должным образом!
И под каждым шагом может быть много других подэтапов, таких как создание демонстраций во время разработки, создание пользовательской документации, технической документации, документации поддержки, консультационных заметок, тестов с высокой нагрузкой, нефункциональных тестов, тестов в исключительных случаях, и есть масса других. кое-что можно сделать, чтобы улучшить общее качество и сделать систему лучше.
Так где же ловушка?
Вот — все эти вещи требуют времени, но часто они избыточны. В начале статьи я сказал, что инженеры должны гнаться за совершенством, но это часто бывает излишним... Что же тогда делать?
Если мы делаем работу так хорошо, как можем, то тратим тысячи часов своего времени, берем дополнительные деньги с заказчика и доставляем новые функции раз в месяцы/годы вместо недель.
Если мы этого не делаем, то мы должны что-то отрезать и делать систему хуже по замыслу.
Это ловушка, мы не можем добиться наилучшей формы для нашего процесса и проекта, всегда есть что-то, что мы можем улучшить, и если мы хотим это сделать, то мы обрекаем наш проект и заказчика на неожиданные (почти бесконечные) дополнительные затраты ( иногда это может умножить общую сумму) и время.
Таким образом, разработка программного обеспечения связана с компромиссами и гибкостью, в отличие от строительства зданий из схем и кирпичиков. Вы должны выбрать то, что вам нужно, оценить риски и не гнаться за совершенством.
Помните: Идеальное — злейший враг достаточно хорошего.
P.S. Слишком много информации невозможно охватить в этой статье. Если вы хотите прочитать больше, прокомментируйте ниже.
