среда, 17 июля 2013 г.

Lean №6 - Разработка на ограничениях

Сложная тема про мышление через ограничения.

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

Комментариев нет:

Отправить комментарий