Или страх и ненависть в отдельной команде
С одной стороны от планирования сплошной профит: оно помогает определить путь достижения цели, избежать нестыковок и заранее выявить проблемные места, оценить сроки (это отдельная больная тема). Опять же, планирование есть решительно во всех методологиях, отличается только детальностью. С необходимостью этого этапа спорить странно.
Сегодня в обсуждении пытались понять что же не так. Я для себя это сформулировал как "запланированные задачи не мапятся на процесс их решения". Так как мы сейчас активно рисуем интерфейс, то задачи накидываются во время вдумчивого созерцания интерфейса. Естественным образом выходит, что задачи группируются по компонентному признаку. При этом решение задачи подразумевает работу со сценариями, которые затрагивают сразу несколько компонентов и внутренние механизмы. Необходимость постоянно переключать мышление дает немалый вклад в раздражение.Когда задачи разбиты по компонентам есть два сценария: делать всё строго по плану в лучшем случае тестируя все компоненты в автономной среде, либо забить за план (нахрена ж столько усилий потратили) и начать реализовывать сценарии. В первом случае не особо понятно куда отнести интегрцию и риск того, что компонент работает правильно, но придется его переписать, потому что он никак не вписывается в работающее приложение (надо было лучше планировать блеать, в следующий раз уж старайтесь). Во втором случае оценки времени и так показывающие температуру по больнице будут показывать температуру на марсе и вообще непонятно какая от них будет польза, а ведь качество оценок напрямую влияяет на зарплату.
Когда открываешь задачу на создание компонента, первая реакция - полнейший ступор, вторая - послать всё это нахер и почитать ленту, третья - собраться, открыть всяческие прототипы, доки и таки постараться накидать сценариев (опять же бессмысленная трата времени, которая должна была быть на этапе планирования). В итоге выяснится, что нужно предварительно реализовать другие компоненты, переписать внутренний API и поковырать сервер, чтобы можно было постепенно продвигаться в решении задачи. Самое интересное, что мы пытались описывать сценарии, но на чем-то зафейлились.
Если планировать более детально, то неизбежно начинаешь скатываться в сценарии, и если их все записывать, то, по сути, это ничем кроме языка не будет отличаться от непосредственной реализации. А дублирование работы только для того, чтобы показать начальству оценку времени не добавляет восторга.
Быть может, это специфика нашего подхода и того, что задачи сейчас ГУЙовые, но, помнится, при планировании и реализации API была точно такая же проблема: какой смысл проектировать интерфейс без практической реализации, и в итоге регулярно переписывать, потому что чего то не хватает, либо, наоборот, не нужно.
