В последнее время мы увидели, что наша команда разработчиков опасно близка к идеям типа > второго системного синдрома, пока мы планируем следующую версию нашего продукт. Хотя я все делаю улучшения и отменяю некоторые из ошибок нашего прошлого, я бы не хотел, чтобы мы застряли в бесконечной петле переписывания и никогда ничего не запускали.
Есть ли хороший метод разработки/разработки, который позволяет создавать лучшую версию 2.0, избегая при этом вторых системных сценариев?
"Мне бы очень хотелось, чтобы мы застряли в бесконечной петле переписывания и никогда ничего не запускали".
Вот почему люди используют Scrum.
Определите отставание в построении.
Приоритет, так что сначала начнутся события, которые приводят к выпуску. Вещи, которые должны быть исправлены, являются вторыми.
Выполняйте спринты, чтобы перейти к релизу. Выполните спринт выпуска.
У меня есть второй синдром системы с обеих сторон как клиент/спонсор и часть команды разработчиков.
Основной причиной проблем является то, что команда заходит в утопическое видение версии 2, например, желание сделать новое программное обеспечение "гибким". В этом сценарии все абстрагируется до n-й степени. Например, вместо объектов данных, которые представляют объекты реального мира, создается общий объект "item", который может представлять что угодно. Одна из ошибочных идей заключается в том, что мы можем создать такую гибкость в программном обеспечении, чтобы предвосхищать будущие потребности, что не-программисты смогут просто настраивать новые возможности. Часто одна цель, такая как "гибкость", затмевает усилия, направленные на то, что полученное программное обеспечение не работает.
Сбалансированное практическое рассмотрение возможностей использования, производительности, масштабируемости, возможностей, ремонтопригодности и гибкости может вернуть команду на Землю. "Было бы здорово, если бы..." должен быть запрещен лексикон команды. Задержка Scrum - хороший инструмент, и команда должна быть услышана часто, говоря часто: "Пусть отставание, что... нам не нужно это для версии 2."
Постарайтесь сосредоточиться на коротких циклах доставки, т.е. заставить себя доставлять что-то ощутимое и полезное пользователям каждые несколько недель или месяц. Приоритет задач, основанных на их ценности для клиента. Таким образом, у вас всегда есть удобное, функциональное приложение с удовлетворенными пользователями, а под капотом вы можете реорганизовать архитектуру небольшими шагами, если хотите (и если вы можете обосновать необходимость в ней, то есть к руководству/клиентам, а не просто товарищи по команде!).
Это очень помогает, если у вас есть стабильный процесс сборки с хорошим набором тестов (unit/integration).
Агильные методы разработки, такие как Scrum, делают это, и они горячо рекомендуются. Но, конечно, не всегда легко или даже возможно адаптировать такой метод в вашей команде. Даже если вы не можете, вы все равно можете взять его элементы и применить его к своему проекту (возможно, даже без упоминания слов "agile" или "Scrum" публично; -)
Получите того, кто написал по крайней мере три системы, чтобы возглавить проект.
Обязательно задокументируйте требования. Хотя очевидно, что вам нужно также управлять тем, что входит в требования, чтобы избежать чрезмерного проектирования, наличие фиксированного объема помогает предотвратить запуск разработчиками идей или позолота, что необходимо сделать, и это помогает держать управление или клиентов от введения области ползучести, Определите все требования и способы изменения областей.
Я все для коротких циклов разработки (убедитесь, что вы пишете тесты) и гибкой методологии, но ни один из них не является щитом против второй синдрома. В некотором смысле, легче продолжать добавлять функцию после функции, если вы работаете в короткие спринты, не останавливаясь, чтобы посмотреть общую картину. Используйте гибкие методы для создания простейшей вещи, которая работает, а затем продолжайте добавлять свои другие требования как можно проще. Помните YAGNI, потому что, когда вы создаете систему во второй раз, когда вы, скорее всего, создадите что-то, вы уверены, что в какой-то момент вам понадобится что-то, что сделает систему "расширяемой", поэтому никогда не должно быть третья сборка. Это лучшее из намерений, но путь в ад и все такое.
Сосредоточение внимания на архитектуре системы должно помочь, например,
Следовательно, не переходя на общий своп, текущая система может быть "модернизирована" с более подходящими интерфейсами, чтобы способствовать будущему росту.
Еще один хороший способ сосредоточиться: назначить $$$ фигуру каждой функции и определить приоритет соответственно; -)
Во всяком случае, только мои 2cents
Вы не можете приблизиться ко второму системному синдрому. Либо ты в ней, либо ты от него. Вы узнаете, когда будете в ней, но только после того, как потратили много ресурсов.
Подсказки: знать об этом (так что в основном мы получили, что уже охвачены). Это бесценная информация, чтобы знать, что такое "вторая система", и даже больше иметь некоторый опыт в этом. Я думаю, что у всех нас есть некоторый опыт в этом, надеюсь, доброкачественный.
Это знание часто заставит вас дважды подумать, и вы найдете решение, не вдаваясь в неопределенность второй системы.
PS: Также знайте, как использовать вашу текущую систему, включая, возможно, документальные решения и другую документацию.
Я проголосовал за S. Lott и хотел бы добавить еще несколько предложений:
Доставляйте рабочий продукт своему клиенту как можно чаще. Итерации длительностью от нескольких недель до двух месяцев идеальны. Гибкие методологии, такие как Scrum, хорошо подходят для этого.
Используйте FogBugz для отслеживания функций и ошибок. Его функции очень практичны для гибких проектов. FogBugz позволяет легко определять приоритеты в соответствии с версиями и приоритетами. Если ваша команда вносит свои оценочные уровни усилий для каждой задачи, вы также можете использовать ее для расчета разумных дат корабля.
Определите, какие функции вы разработаете в соответствии с правило 80/20 (20 процентов функций будут использоваться на 80 процентов времени) и самый сильный удар для доллара. Это помогает максимально упростить систему, помогает предотвратить функцию bloat и экономит время разработки и тестирования.
Дайте аналогичную мысль как новым функциям, так и ошибкам при определении приоритета проблемы. Одним из пунктов теста Joel является "Вы исправляете ошибки перед написанием нового кода?". В большинстве магазинов этого не происходит, но не отлаживайте систему после запоздалой мысли. Кроме того, сохраните рабочую копию старой системы для сравнения с тем, когда в новой системе обнаружены ошибки.
Также учитывается уровень усилий, необходимых для поддержания и, при необходимости, перезаписи существующего кода. Если вы еще этого не сделали, дайте команде некоторое время, чтобы просмотреть все файлы, которые они находят неприятными для изменения. Если системный код был трудно поддерживать в первый раз, это только ухудшится и заставит вашу команду тратить больше времени на новые функции в будущем.
Его никогда нельзя избежать во всей полноте. Но осторожность могла бы облегчить проблему. Вы должны сформулировать правило большого пальца, основанное на жизненно важных параметрах (кратчайший ресурс), которые определяют успех системы. Например, уменьшение потенциального количества ошибок может напрямую снизить эксплуатационные расходы (потенциальные вызовы службы в центр поддержки). Но это может быть не в случае других систем. Другим примером является то, что в некоторых случаях может оказаться полезным использование CPU, памяти и других ресурсов, но могут быть среды, где они могут быть доступны в изобилии.
Так просто избегать "соблазнов", идентифицировать скудный ресурс (время, усилие, деньги и т.д.) и рассмотреть возможность внедрения только тех, которые превышают пороговое значение. [f (s1, s2...) > порог]
Несмотря на итеративное развитие, я хотел бы подчеркнуть, как обрабатываются технические долги.
Ссылки, связанные с этим:
Tech Debts: Effort Vs Time
Квадрант технического долга