target="_blank" rel="nofollow" href="http://www.tompeters.com/col_entries.php?note=005297&year=1991">http://www.tompeters.com/col_entries.php?note=005297&year=1991.
19
Однажды, когда мы с друзьями зашли пообедать в Pizzeria Uno в Питтсбурге, нам сказали, что столик будет готов через десять минут. Ровно через десять минут мой друг Чед МакДаниэль поинтересовался насчет обещанной готовности. Администратор снова ответила, что столик будет готов через десять минут. Чед спросил: «Это те же десять минут или другие?» Шутку она не оценила.
20
Подробное сравнение традиционных методов разработки программного продукта и agile-метода можно найти здесь: Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm and Richard Turner (Addison-Wesley, 2003).
21
ДеМарко Т., Листер Т. Человеческий фактор. Успешные проекты и команды. СПб.: Символ-Плюс, 2011.
22
Подробнее о том, как осмыслить изменения в процессе разработки софтверного продукта и управлять ими, см. Watts S. Humphrey Managing the Software Process (Addison-Wesley Professional, 1989).
23
“Understanding and Controlling Software Costs,” IEEE Transactions on Software Engineering, vol. 14, no. 10, October 1988, pp.1462–77; а также Barry Boehm Software Engineering Economics (Prentice Hall, 1991).
24
Графики, основанные на задачах программистов, принято называть графиками «снизу вверх». Графики, основанные на решении менеджмента, называются графиками «сверху вниз». Как правило, отличия между ними обговариваются и согласуются.
25
Любой график – лишь один из многих возможных вариантов. В зависимости от того, какие непредвиденные факторы (ошибка проектирования, политическая революция, нападение пришельцев и т. д.) в нем учитываются, сроки могут быть разными. Без учета вероятных ошибок график не может быть надежным: его автор не проявил достаточно креатива или скептицизма.
26
Многие учебники и руководства описывают, как выстроить структуру разделенной работы. Я коснусь этой темы в главе 14, однако если вы хотите получить более подробную информацию, начните с http://en.wikipedia.org/wiki/Work_breakdown_structure или Total Project Control, Stephen Devaux (Wiley, 1999).
27
В книге Кента Бека Extreme Programming Explained (Addison-Wesley, 1999) (Бек К. Экстремальное программирование. Разработка через тестирование. СПб.: Питер, 2017) предлагается модель распределения работы для программистов, где они сами выбирают рабочие единицы. В идеале это решение – компромисс между благом проекта и благом членов команды.
28
См. Kent Beck and Martin Fowler, Planning Extreme Programming (Addison-Wesley, 2002) (Бек К., Фаулер М. Экстремальное программирование. Планирование. СПб.: Питер, 2003), pp. 60–62.
29
PERT – Program Evaluation and Review Technique, метод оценки и анализа проектов. Стандартная формула: (оптимистический прогноз + (4 × наиболее вероятный прогноз) + пессимистический прогноз) / 6. Однако существует масса вариаций и теорий о том, как лучше рассчитывать взвешенную оценку.
