Идеи:
- Сложно выполнить синхронизацию если все ее участники являются мастер-источниками данных. Когда есть Java-система которая накладывает условия по протоколам взаимодействия, а остальные их должны соблюдать, и нужно лишь убедиться что нет логических противоречий, то есть ошибок на бизнес-уровне - это одно. Но что если все участники могут накладывать условия. Нужно назначить встречу для 5х. Выбираешь время - кто-то не может. Выбираешь другое время - другой не может. В результате проходит много итераций. В этот момент люди интуитивно переходят на мышление через ограничения. Нужно собрать со всех их ограничения по времени (когда они могут), принять решение на основе этих ограничений и просто уведомить всех о выбранном времени. Количество итераций минимально.
- В разработке я использую это следующим образом.
- Собираем все известные бизнес-требования, все value-feature которые есть/знаем в PBL
- Вырабатывает технические решение
- Проверяем что оно удовлетворяет всех требованиям
- Итеративно упрощаем его, проверяя что требования все еще проверяются
- Результат - есть KISS решение.
- Например, версионность оЗАГС в Java проекте, иерархия организаций и ролевая модель в Ruby проекте
- При принятии дорогих, критических решений - сформируйте несколько вариантов, сделайте их все, провалидируйте и примите решение. Ошибиться в конце и все переделать будет дороже.
- Итерация - это одно из следствий такого подхода. Да, делаем только один, самый лучший по нашему мнению вариант, но чем быстрее покажем пользователю, тем быстрее провалидируем вариант, и сможем его изменить.
- Критично. Дизайн системы должен быть доступен для внесения изменений.
- Агрессивный рефакторинг - один из подходов внесения изменений, так изменений становятся дешевле. Если в Java проекте это уже 7-ая версия архитектуры - нужно жестко удалять все старые, ненужный куски кода. Они тянут вниз, тормозят разработку.
- Код никогда не должен фризится.
Комментариев нет:
Отправить комментарий