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