Сегодня я решил опубликовать цитаты из книги Стива Макконнелла ""Остаться в живых! Руководство для менеджера программных продуктов". Книгу я читал уже довольно давно (года три назад) и тогда она на меня произвела двоякое впечатление. Первая часть книги, в которой автор сосредотачивается на общих сведениях, мне очень понравилась, а вот вторая, более конкретная, мне понравилась не очень сильно и я не решился применять советы автора на практике. Хотя у вас может быть и другое мнение:)
В целом, нужно сказать, что интересных мыслей в книге достаточно, о чем можно будет убедиться по цитатам. Цитат набралось много, поэтому я разбил их на две части.
На первой цитате я хочу остановиться подробнее. Во-первых, автором этой цитаты является не Стив Макконнелл, а Александр Милн, а во вторых, ее нельзя публиковать без рисунка, а в третьих, несмотря на то, что Милн, мягко говоря, не имеет никакого отношения к компьютерам, эта фраза имеет непосредственное отношение к разработке ПО.
Плюшевый медвежонок вслед за Кристофером Робином спускается по лестнице, считая затылком ступеньки - бум, бум, бум. Он знает - это единственный способ перемещаться с этажа на этаж, хотя иногда ему кажется, что должен быть и другой. И он бы догадался, что это за способ, если б его перестали колотить затылком о ступени и дали хоть чуточку подумать. Но чаще ему кажется, что никакого другого способа просто нет.
Об авторе
Исследователи обнаружили, что стоимость позднего исправления ошибки, внесенной в проект на ранней стадии (например, при формировании требований или архитектуры), в 50-200 раз выше, чем стоимость ее исправления сразу же после внесения.
Глава 3. "В начале потока" и "в конце потока"
Конус неопределенности задает ряд жестких предпосылок для оценки проектов. Так, он подразумевает, что на ранних стадиях проекта точно оценить проект не просто трудно, а теоретически невозможно. После окончания формирования требований область действия проекта будет зависеть от огромного числа решений на этапах создания архитектуры, детального проектирования и конструирования. Если кто-то берется оценить влияние этих решений до их принятия, то возможны два варианта: либо этот человек обладает даром предвидения, либо попросту плохо осведомлен о сущности программной разработки
Глава 3. Предпосылки для оценки проекта
В начале проекта вы можете определить для него либо фиксированные сроки и бюджет, либо фиксированный функциональный набор. Определить и то и другое одновременно - невозможно.
Глава 3. Предпосылки для оценки проекта
Добиться успеха в небольших проектах можно при благоприятном стечении обстоятельств простым напряжением силы воли, однако средние и крупные проекты требуют более систематического подхода
Глава 4. Навыки выживания
В некоторых организациях проблема финансирования программных проектов состоит в том, что менеджеры вынуждены делать запросы финансирования раньше, чем у них появляется возможность завершить значительную часть исследовательских работ. Такие запросы обречены на "промах", поскольку для осмысленного расчета оценок бюджета и сроков проекта о желаемом продукте известно слишком мало. Опыт программной индустрии свидетельствует о том, что оценки, создаваемые на ранних стадиях проектов, могут отличаться от действительных в большую или меньшую сторону до четырех раз.
Глава 4. Двухэтапный подход к финансированию
Любой участник среднего или крупного проекта не понаслышке знает, что очень многое в нем может пойти "не так"
Глава 4. Управление рисками
В силу загадочных для меня причин люди полагают, что можно контролировать проект, не выделяя для этой цели какую-то группу или отдельное лицо. Мое мышление и опыт говорят, что это невозможно
Глава 4. Контроль над проектом
Разработка программных продуктов требует творчества, интеллекта, инициативности, настойчивости и значительной степени внутренней мотивации. Любой эффективный подход к разработке программного обеспечения должен подразумевать, что в отсутствие интереса команды к проекту его успех сомнителен.
Глава 4. "Человеческое обеспечение"
Не пытайтесь мотивировать разработчиков эффективными выступлениями, недостижимыми результатами или денежными вознаграждениями
Глава 4. "Человеческое обеспечение"
Разработка программных продуктов - это процесс постоянных исследований и поиска, поэтому лучшая его поддержка - это спокойная обстановка, располагающая к размышлениям. Эффективная разработка программ требует от разработчиков такого же уровня концентрации, как от математиков или физиков. Можете ли вы представить Альберта Эйнштейна, сидящего за рабочим столом, вокруг которого ходит менеджер и раздраженно повторяет: "Альберт, теория относительности нужна нам прямо сейчас! Поторопись!"
Глава 4. "Человеческое обеспечение"
Работа среднестатистического менеджера требует переключения внимания каждые несколько минут. Работа среднестатистического разработчика требует, чтобы переключение внимания происходило не чаще, чем раз в несколько часов.
Глава 4. "Человеческое обеспечение"
С точки зрения сложности компонентов программного продукта и их функциональности, успешная разработка проекта подчиняется принципу "чем меньше, тем лучше", действующему на всех этапах - от формирования требований до выпуска. Поскольку разработка программного продукта требует значительных интеллектуальных усилий, становится важно, чтобы участники проекта активно способствовали его максимальному упрощению, избавляя проект от излишней сложности.
Глава 4. Минимализм продукта
Французский писатель Вольтер говорил, что рассказ закончен не тогда, когда в него нечего добавить, а тогда, когда из него нечего больше выкинуть. Этот подход применим и к программному проекту.
Глава 4. Минимализм продукта
Эффективные проекты контролируют изменения; неэффективные проекты находятся под контролем изменений.
Глава 6. Стрельба по движущейся цели
Хорошо организованные проекты неизбежно ищут компромисс между функциональным набором, бюджетом и расписанием
Глава 7. Цели в области действия проекта
Все цитаты книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".
Комментариев нет:
Отправить комментарий