Советы по предотвращению синдрома второй системы [закрыто]

У меня есть опыт второго системного синдрома с обеих сторон в качестве клиента/спонсора и части команды разработчиков.

основной причиной проблем является то, что команда цепляется за утопическое видение версии 2, такое как желание сделать новое программное обеспечение "гибким". В этом сценарии все абстрагируется в N-й степени. Например, вместо объектов данных, представляющих объекты реального мира, создается универсальный объект "item", который может представлять что угодно. Один порочная идея заключается в том, что мы можем встроить в программное обеспечение столько гибкости, чтобы предвидеть будущие потребности, что не-программисты смогут просто настроить новые возможности. Часто одна цель, такая как" гибкость", затмевает усилия до такой степени, что полученное программное обеспечение не работает.

сбалансированное практическое рассмотрение практичности, производительности, масштабируемости, функций, ремонтопригодности и целей гибкости может вернуть команду на землю. - Было бы здорово, если бы..." должна быть запрещено из лексикона команды. Scrum backlog-хороший инструмент,и команда должна быть услышана часто... - Давайте отложим это...нам это не нужно для версии 2."

старайтесь сосредоточиться на коротких циклах доставки, т. е. заставляйте себя доставлять что-то осязаемое и полезное пользователям каждые несколько недель или месяцев. Расставьте приоритеты задач в зависимости от их ценности для клиента. Таким образом, у вас всегда есть полезное, функциональное приложение с удовлетворенными пользователями, в то время как под капотом вы можете рефакторировать архитектуру небольшими шагами, если хотите (и если вы можете оправдать необходимость в этом - то есть к управлению / клиентам, а не только товарищам по команде!).

Это помогает, если у вас есть стабильный процесс сборки с хорошим набором автоматических (блок / интеграционных) испытаний.

гибкие методы разработки, такие как Scrum сделать это, и они горячо рекомендую. Но, конечно, не всегда легко или даже возможно адаптировать такой метод в вашей команде. Даже если вы не можете, вы все равно можете взять его элементы и применить его в интересах своего проекта (возможно, даже не упоминая слова "agile" или "Scrum" публично ;-)

найдите кого-то, кто написал по крайней мере три системы для руководства проектом.

убедитесь, что вы документируете требования, а также возможно. Хотя, очевидно, вам также нужно управлять тем, что попадает в требования, чтобы избежать чрезмерного проектирования, наличие фиксированной области помогает предотвратить запуск разработчиков с идеями или золотым покрытием, что нужно сделать, и это помогает сохранить управление или клиентов от введения области ползучести. Определите все требования и способы их изменения.

Я все для коротких циклов разработки (убедитесь, что вы пишете тесты) и гибкой методологии, но ни один из них не является щитом против второй системы синдрома. В некотором смысле легче продолжать добавлять функцию за функцией, если вы работаете в коротких спринтах, не останавливаясь, чтобы посмотреть на общую картину. Используйте гибкие методы для создания простейшей вещи, которая работает, а затем продолжайте добавлять свои другие требования как можно проще. Помните о YAGNI, потому что когда вы строите систему во второй раз, это когда вы, скорее всего, построите что-то, в чем вы уверены в какой-то момент вам понадобится что-то, что сделает систему "расширяемой", поэтому никогда не будет третьей сборки. Это самые лучшие намерения, но дорога в ад и все такое.

фокусировка на архитектуре системы должна помочь, например

• имея документированные интерфейсы, которые поддерживают "свободную связь" между подсистемами
• документировав проектные решения (избегайте повторного хэширования ранее избитых путей)

следовательно, без перехода на все свопы, текущая система может быть "обновлена" с более подходящими интерфейсами, чтобы помочь будущему росту.

еще один хороший способ сосредоточиться: назначить цифру $$$ для каждой функции и приоритизации соответственно ; -)

абы, просто мой 2cents

вы не можете приблизиться ко второму системному синдрому. Либо ты в нем, либо ты далеко от него. Вы узнаете, когда вы в нем, но только после того, как потратите много ресурсов.

советы: об этом знать (так что в основном мы это уже покрыли). Это бесценная информация, чтобы знать, что "вторая система", и даже больше, чтобы иметь некоторый опыт в этом. Я думаю, что у всех нас есть некоторый опыт в этом, надеюсь, доброкачественный.

Это знание часто заставьте себя подумать дважды, и вы найдете решение, не рискуя попасть в Лимб второй системы.

PS: также знайте, как использовать текущую систему, которая включает в себя, возможно, документированные решения и другую документацию.

Я проголосовал за ответ С. Лотта и хотел бы добавить еще несколько предложений:

1. поставить рабочий продукт к вашему клиенту как можно чаще. Итераций продолжительностью от нескольких недель до 2 месяцев идеально. Гибкие методологии, такие как Scrum, хорошо подходят для этого.

2. использовать FogBugz функции и отслеживание ошибок. Его функции очень практичны для гибких проектов. Они легко приоритезации в соответствии с релизами и приоритетами. Если ваша команда вводит оценочные уровни усилий для каждой задачи, вы также можете использовать это для расчета разумных дат отгрузки.

3. приоритет, какие функции вы будете разрабатывать в соответствии с правило 80/20 (20 процентов функций будут использоваться 80 процентов времени) и самый удар для доллара. Это помогает сохранить систему как можно проще, помогает предотвратить функция коптит, и спасает время разработки и тестирования.

4. дайте аналогичную мысль как новым функциям, так и ошибкам, когда вы определяете приоритет проблемы. Один пункт тест Джоэла " вы исправляете ошибки перед написанием нового кода?". В большинстве магазинов этого не происходит, но не делайте отладку системы запоздалой мыслью. Кроме того, сохраните рабочую копию старой системы для сравнения с обнаруженными ошибками в новой системе.

5. также фактор в уровень усилий, необходимых для поддержания и при необходимости переписывания существующего кода. Если вы еще не сделали этого, дайте команде некоторое время для просмотра кода целых файлов, которые они считают трудными для изменения. Если код системы было трудно поддерживать в первый раз, это только ухудшится и заставит вашу команду тратить больше времени на новые функции в будущем.

его никогда нельзя избежать во всей его полноте. Но осторожность могла бы решить проблему. Вы должны сформулировать некоторое правило большого пальца, основанное на жизненно важных параметрах (самый скудный ресурс), которые определяют успех системы. Например, уменьшение потенциального количества ошибок может напрямую снизить эксплуатационные расходы (потенциальные вызовы службы в Центр поддержки). Но это может быть не так во всех других системах. Другой пример, скудное использование CPU, памяти и других ресурсов может быть полезно в некоторые случаи, но могут быть среды, где они могут быть доступны в изобилии.

поэтому просто, чтобы избежать "соблазнов", определите самый скудный ресурс (время, усилия, деньги$ и т. д.) и рассмотрите возможность реализации только тех, которые превышают пороговое значение.[f (s1,s2...) > порог]

несмотря на итеративное развитие, я хотел бы подчеркнуть, как обрабатываются технические долги.
Ссылки, которые связаны с этим:
Технические Долги: Усилие Против Времени
Технический Долг Квадрант