Скотт Беркун - Искусство управления IT-проектами

Информацию об определениях и понятиях изменений процесса разработки программного обеспечения, а также об управлении этими изменениями можно найти в книге Уоттса С. Хамфри (Watts S. Humphrey) «Managing the Software Process» (Addison Wesley Professional, January 1989).

«Understanding and Controlling Software Costs», IEEE Transactions on Software Engineering, т. 14, № 10, октябрь 1988, стр. 1462–77; а также книга «Software Engineering Economics» (Prentice Hall, 1991).

Календарные планы, основанные на имеющихся работах, называются восходящими, потому что они создаются командой, а календарные планы, основанные на потребностях управления, – нисходящими. Обычно разногласия между ними согласовываются.

В зависимости от характера непредвиденных обстоятельств (просчеты проектантов, политические революции, нашествия пришельцев и т. д.), заложенных в календарный план, рабочий график может быть разным. Если возможные провалы не рассматривались, календарный план не может вызывать доверия. Его создатель не проявил должного творческого подхода или скепсиса.

Процесс проведения структурной декомпозиции работ описан во многих книгах. К этой теме я вернусь в главе 14, но если вы хотите изучить ее более обстоятельно, начните с материалов, размещенных по адресу http://en.wikipedia.org/wiki/Work_breakdown_structure, или с книги Стефана Дево (Stephen Devaux) «Total Project Control» (Wiley, 1999).

В книге Кента Бека (Kent Beck) «Extreme Programming Explained» (Addison Wesley, 1999) предлагается программно-ориентированная модель распределения работ, при которой программисты сами выбирают себе работы. В идеале должен быть выдержан компромисс между тем, что лучше для проекта, и тем, что лучше для отдельных специалистов команды.

См. книгу Кента Бека (Kent Beck) и Мартина Фоулера (Martin Fowler) «Planning Extreme Programming» (Addison Wesley, 2002), стр. 60–62.

Стандартная формула для метода PERT: лучший расчет + (4 × наиболее вероятный расчет) + худший расчет/6. Имейте в виду, что существует огромное количество разновидностей и теорий наилучших взвешенных расчетов.

Сравнить другие типы проектов вы сможете, обратившись по адресу http://www.joelonsoftware.com/articles/FiveWorlds.html.

Эндрю Стеллман (Andrew Stellman), один из научных редакторов данной книги, несколько раз угрожал мне физической расправой, если я не расскажу о качестве программного продукта, но эта глубокая тема так и не вписалась в рамки моей книги. Для начала порекомендую вам две другие книги: «Out of the Crisis» (MIT Press, 2000) У. Эдвардса Дэминга (W. Edwards Deming) и «Quality Is Free» (Signet Books, 1992) Филиппа Кросби (Philip Crosby).

Файзал Джафдат (Faisal Jawdat), один из научных редакторов данной книги, угрожал мне изощренными пытками, если я не отмечу всю иронию ситуации, в которой после всего сказанного я продолжал работать на Microsoft.

Эта сноска дана специально, чтобы заставить читателя обращать на сноски хоть какое-то внимание. А если серьезно: когда проектировщики работают на себя, они имеют склонность многократно переделывать сделанное, возможно, расслабляясь в отсутствие образа потребителя, на которого надо работать.

Обратите внимание на замечательную книгу Дональда Гауса (Donald Gause) и Джералда Вейнберга (Gerald Weinberg) «Exploring Requirements: Quality Before Design» (Dorset House, 1989).

Этот метод описан в книге Алистера Кокборна (Alistair Cockburn) «Writing Eff ective Use Cases» (Addison Wesley, 2000).

Прочтите книгу Дэниела Шактера (Daniel Schacter) «The Seven Sins of Memory» (Mariner Books, 2002) или посмотрите замечательный фильм «Помни» («Memento»). Это поможет вам осознать, сколь ограничена и ненадежна человеческая память.

Из книги «Piloting Palm: The Inside Story of Palm, Handspring and the Birth of the Billion-Dollar-Handheld Industry» авторов Андреа Баттера (Andrea Butter) и Дэвида Поги (David Pogue) (Wiley, 2002), стр. 72.

Если команда получает заказ на прорывную разработку, но подходит к планированию как к рутинной рядовой работе, нужно быть настороже. Это похоже на нейрохирургическую операцию, проводимую с использованием бытовой аптечки. Если планирование не отвечает сложности задач, так или иначе готовьтесь к провалу.

Дополнительный материал можно найти в книге Дональда Гауса (Donald Gause) и Джеральда Вейнберга (Gerald Weinberg) «Exploring Requirements: Quality Before Design» (Dorset House, 1989).

См. статью «How to give and receive criticism» по адресу http://www.scottberkun.com/essays/35-how-to-give-and-receive-criticism/.

Тем не менее изобретатель простой формулы добычи воды или создания компаса из песка получит первый приз в конкурсе на лучшую идею года при проведении соревнований «Затерявшийся в пустыне». Это пример четко обозначенной проблемы с невероятно сложным решением (простая, но трудноразрешимая). Когда люди жалуются, что требования настолько сложны, что проблему решить невозможно, значит, голова у них забита всякой чепухой. В формулировках проблем указано, на какую гору следует забраться, но там ничего не говорится о том, как взобраться на вершину.