Опишу сейчас наверное типичный кейс, с которым сталкивается каждый разработчик ПО в любой компании имеющий дело с 1С.
Ну и надеюсь, что поможете с разрешением этого вопроса, может просто умных мыслей и практики из своего опыта накидаете.
Итак, поехали.
Безотносительно используемых в компании подходов к планированию имеем следующий диалог:
ПМ: Насть, ты когда закончишь обновление (слияние с новой стандартной 1С конфигурацией)?
Н: Блин, теперь уже не знаю, думала, что за две недели управлюсь, теперь уже сложно оценить. Чем глубже копаю, тем больше обнаруживаю того, что нужно что-то рефакторить или при обновлении что-то перестаёт работать...
ПМ: Нууу, давай уже как-то определим срок завершения, потому как указано 2 недели, выполнено на 56%, выходит неделя осталась?
Н: Не знаю, может и неделя, но если опять во что-то упрусь или что-то новое прилетит, может и три...
Хочу обратить внимание знатоков на следующие ограничения:
- Проект - это не классический проект, а просто большая пользовательская история, которую наверное стоит декомпозировать только на таски, но не стоит делить на несколько отдельных историй.
- Настя – ответственный, вполне квалифицированный работник, успешно использующий практики GTD. Это я к тому, что не нужно пенять на прокрастинацию.
- У Насти, как и любого разработчика, есть несколько параллельных проектов, в которых также есть задачи.
- Насте хорошо удаётся планировать небольшие по объему задачи, особенно те, в которых владение кодом близко к 100%
- Прочесть и попробовать на себе EBDC (http://mnogosdelal.ru/slidecasts/project-estimation/)
- Прослушать вебинар про оценку сроков, проводимый http://it-boost.com/, пароль, увы, скажу только Насте (https://vimeo.com/83733627)
- Ежедневно (еже-[выбрать своё]) пересматривать свою оценку, отсекая все необязательные задачи в рамках конкретной пользовательской истории
- Чаще практиковать "обновления" (набить руку, так сказать) и составлять чек-листы обновления (с 1С видимо так и никак иначе).