Майк Кон - Agile - оценка и планирование проектов

— Так сколько займет проект, если мы добавим характеры? — спросил Фил. К приятному удивлению Фрэнка, этот вопрос был адресован Аллану.

— Возможно, еще восемь итераций, или всего 20 недель. За итерацию мы выполняем работу объемом 17 пунктов. Это называется скоростью. Если продлить линию, показывающую скорость 17 пунктов на итерацию, то, как видно, мы завершим проект через восемь итераций. — Аллан продолжил линию, как показано на рис. 23.8. — Это очень близко к предельному сроку, поэтому мы идентифицировали несколько низкоприоритетных элементов, от которых можно отказаться, если начнем отставать или если решим выпустить релиз через 18 недель вместо 20.

— И игра будет продаваться лучше или по более высокой цене? — спросил Фил.

— Да, я уверен в этом, — сказал Фрэнк. — Я хочу провести еще несколько исследований и построить модель, чтобы решить, следует ли нам продавать по текущей цене или можно увеличить ее на $5.

— Вы меня убедили. Спасибо за презентацию, — сказал Фил.

Аллан начал стирать нарисованную диаграмму.

— Не надо. Пусть останется, — сказал Фил. — Я хочу обновлять ее каждые две недели.

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

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

— Допускаю, что получилась отличная игра, но мне не нравится ощущение запаздывания. Первоначально мы думали, что ее можно сделать всего за 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.