Agile: оценка и планирование проектов

— Спасибо, что уделил нам время, Фил, — сказал Фрэнк, когда они с Делани и Алланом покидали кабинет.

Восемнадцать недель спустя

— Отличная работа, ребята. Игра выглядит потрясающе, — сказал Фрэнк в конце совещания по анализу последней итерации. — Я не вижу недостатков. Движки функционируют очень хорошо. Роуз, я просто влюбился в твои характеры. Связь каждого из них с движком великолепна. Игроки выбирают характер игры, а не уровень сложности. Признаюсь, поначалу я скептически смотрел на мультяшные персонажи. Но мне нравится, как пираты подзадоривают игрока и как дружелюбная русалка ведет тебя к слабому движку. Ее диалог определенно будет помогать новым игрокам освоить игру. Думаю, мы готовы к отгрузке.

— Допускаю, что получилась отличная игра, но мне не нравится ощущение запаздывания. Первоначально мы думали, что ее можно сделать всего за 14 недель, но всем говорили, что за 12–20 недель. А в результате мы сдали работу еще на две недели позже, — сказал Прасад.

— Да, мы сделали ее за 22 недели, — сказала Саша. — Но мы и не говорили, что сдадим ее через 14 недель. После планирования первой итерации мы утверждали, что нам требуется от 12 до 20 недель, а более точная оценка появится только через шесть недель.

— К тому же, Прасад, не забывай, что мы могли бы закончить работу две недели назад, если бы захотели, — заметил Фрэнк. — Но мы решили внести дополнительные изменения в характеры по результатам, полученным от тестировщиков бета-версии. Им понравились характеры, но они дали нам несколько хороших рекомендаций по их улучшению. Мы заставили пиратов чаще отпускать замечания и сделали рэпера более разговорчивым. Конечно, первоначальный график был неправильным, но это же можно сказать и о дизайне продукта. Та игра не принесла бы нам такой финансовой отдачи, как эта. Вы играли в новую версию. Вы знаете, насколько лучше она сейчас, с запозданием всего на две недели по сравнению с первоначальной оценкой. Если бы мы выпустили версию 1.0 без характеров, а потом добавили их, я бы принял это. Но наша отрасль — вряд ли. Я очень доволен продуктом. Это больше, чем ожидалось, и всего на две недели позже, чем по оценке в начале проекта.

— А еще не забывайте, что Deep Black & White вышла позже на полгода, а не на две недели.

— Так что, Фрэнк, ты опять будешь угощать нас бургерами в честь этого релиза?

— Нет, на этот раз я куплю вам все, что вы пожелаете.

Список литературы

Abdel-Hamid, Tarek K. 1993. Adapting, Correcting, and Perfecting Software Estimates: A Maintenance Metaphor. IEEE Computer 26 (3): 20–29.

Ambler, Scott W. 2004. Less Is More. Software Development, November.

Anderson, David. 2004. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results. Prentice Hall.

Andrea, Jennitta. 2003. An Agile Request For Proposal (RFP) Process. Agile Development Conference.

Armour, Phillip. 2002. Ten Unmyths of Project Estimation. Communications of the ACM 45, no. 11: 15–18.

Baker, Simon. 2004. Email to agileplanning@yahoogroups.com on November 3, 2004.

Ballard, Glenn, and Gregory A. Howell. 2003. An Update on Last Planner. Proceedings of the 11th Annual Conference of the International Group for Lean Construction, pp. 1–13.

Beck, Kent. 2002. Test Driven Development: By Example. Addison-Wesley.

Beck, Kent, and Martin Fowler. 2000. Planning Extreme Programming. Addison-Wesley.

Beck, Kent, et al. 2001. Manifesto for Agile Software Development, www.agilemanifesto.org.

Bentley, Jon. 1999. The Back of the Envelope. IEEE Software 16 (5): 121–125.

Bills, Mark. 2004a. ROI: Bad Practice, Poor Results. Cutter IT Journal 17 (8): 10–15.

Bills, Mark. 2004b. Useful Back-of-the-Envelope Calculations. Cutter IT E-Mail Advisor, October 27.

Boehm, Barry. 1981. Software Engineering Economics. Prentice Hall.

Boehm, Barry. 2002. Get Ready for Agile Methods, with Care. IEEE Computer, 35 (1): 64–69.

Boehm, Barry, and Richard E. Fairley. 2000. Software Estimation Perspectives. IEEE Software 17 (6): 22–26.

Bossi, Piergiuliano. 2003. Using Actual Time: Learning How to Estimate. In Extreme Programming and Agile Processes in Software Engineering: 4^th International Conference, edited by Michele Marchesi and Giancarlo Succi.