Предисловие

Очень часто разработчик встречается с задачами, которые подразумевают изменение существуюещего функционала системы, либо же добавление нового, который переиспользует существующий функционал. В этой статье я хочу обсудить некоторые подходы к определению объема работ, которые необходимо будет сделать разработчику, чтобы корректно запланировать задачи.

Зачем планировать

Вне зависимости от того, в какой среде вы работаете, будь то гибкая среда разработки (agile) или традиционные подходы, например waterfall существуют deadline в течении которго необходимо желательно закончить работу. В Scrum, например deadlinом будет являться спринт. В любом случае, команда или разработчик предоставляют обязательства перед заказчиком, и эти обязательства нужно выполнять, в противном случае штрафных санций со стороны заказчика не избежать.

Планирование технических задач

В данной статье я опущу методики планирования задач для систем, которые пишутся с нуля, а сосредоточусь на изменениях которые необходимо сделать в существующих приложениях.
Все подходы, которые я собираюсь описать, я использовал сам в той или иной мере.

Индустрия программного обеспечения одна из самых развивающихся и на этой почве выросла не одна система менеджмента — DDD, TDD. Со временем появились еще несколько более встречаемых на практике XDD:

Cover Your Ass Engineering или Not My Problem Approach — при любых обстоятельствах виноват разработчик из соседнего отдела.

Get Me Promoted Methodology — люди пишут код стремясь увеличить видимость своей значимости в проекте.

Nerd Driven Development — любая новая технология должна быть обязательно опробована в следующей итерации.

CV Driven Development — нужно убедить заказчика в необходимости этой технологии т.к она будет неплохо смотреться в резюме.

Banana Driven Development — продукт «созревает» на стороне заказчика

Knight in Shining Armor Methodology — Программист намерено добавляет вызовы wait() в код. Затем, когда производительность приложения падает ниже ожиданий проджект менеджер просит его оптимизировать приложение. С очень серьезной физиономией он обещает сделать все что может. После двух недель чтения комиксов он убирает все вызовы wait() и появляется в офисе директора как рыцарь в сияющих доспехах готовый принять всю похвалу.

А также: