Декомпозиция задачи или почему добавить одно поле это приключение НЕ на одну минуту? Допустим, вы пишете приложение (как неожиданно) и вам поступила задача отобразить номер телефона в профиле пользователя. Менеджер спросит, сколько это займёт, ожидая услышать ответ сразу же. Но вы отвечаете, что нужно подумать, и ваш менеджер пассивно-агрессивно спрашивает, что тут думать — это одно же поле. «Вошли и вышли, приключение на 20 минут, Морти!» К сожалению, зачастую это не так. Особенно если данные для этого поля не хранятся локально. Во-первых, требующий немедленного ответа менеджер — не самый приятный вариант. Профессионалы своего дела понимают, почему иногда даже на такой, казалось бы, очевидный вопрос может потребоваться время. Во-вторых, причиной этого может быть непонимание этапов, которые требуется пройти разработчику/команде при реализации. При постановке вопроса из примера мы должны перечислить следующие пункты: — Реализовано ли это на сервере? Поверьте, зачастую бывают сложности коммуникации и загруженность у разных команд, парадоксально, разная. От ответа на этот вопрос оценка может взлететь по очевидной причине, ведь если фича не реализована, то пока что в прод выкатить её точно не получится. — Насколько сложно будет изменить структуру в БД? Нужна ли миграция? Тут поможет опыт прошлых апдейтов. — Нужна ли локализация этого поля? Заглушки, например. Здесь мы видим то, что как и с вопросом про реализацию на сервере не всё зависит от нас. — Нужна ли валидация этого номера телефона? Нужны ли нам регулярки, может ли номер содержать буквы, например? Сколько может быть символов? Возможно, вы и не удивитесь, но буквы в номерах возможны как минимум в рекламе. — Какой шрифт, какой цвет, как оформить вообще? Нужна ли анимация при переводе фокуса ввода? От задачи к задаче подпункты могут быть разными, но постановка вопроса — половина решения. В списке выше на самом деле можно выделить сразу два вида декомпозиции: Вертикальная: сервер, перевод от команды переводчиков, реализация на клиенте. И горизональная для приложения: подзадача про валидацию, про оформление, про хранение. Разработчик с опытом может выдать ответ быстро, если он 1 000 раз проводил подобную декомпозицию. Но вот ответ от него может различаться от ответа джуниора, готового лезть на амбразуру сразу же. Декомпозиция нужна, чтобы: — Понять последовательность выполнения задач. — Оценить сроки. — Упростить процесс тестирования. — Помочь расставить приоритеты. В спринте, но по-хорошему, изначально в бэклоге. Два небольших вывода: 1️⃣ Мы работаем на бизнес. Поэтому мы должны понимать, почему менеджер может быть недоволен медленной оценкой. 2️⃣ Хочется верить, что этот пост прочтут не только разработчики, но и проект-менеджеры. Профессионалы улыбнутся и скажут, что так и есть. Но те, кто начинает управлять командами — пожалуйста, прочтите этот пост ещё раз. Специально для @iOS Dev