Что такое разработка ПО? Часть 2

И еще одна мысль от Стива Макконнелла о том, что такое разработка ПО:

"Те, кто считает программирование искусством, указывают на эстетические аспекты разработки ПО и утверждают, что наука не допускает такого воображения и творческой свободы, а те, кто считает программирование наукой, указывают на огромное количество ошибок в программах, утверждая, что столь низкая надежность недопустима, и черт с ней с творческой свободой. Обе эти точки зрения грешат неполнотой и ставят во главу угла неверный тезис. Разработка ПО– это искусство, наука, ремесло, археология, тушение пожаров, социология и еще много других видов деятельности человека, взятые вместе. В некоторых областях это любительство, в других – профессионализм. Это столько же различных вещей одновременно, сколько существует программистов. Но правильно поставленный вопрос состоит не в том, что такое есть разработка ПО на данный момент, а скорее в том, чем должна быть профессиональная разработка ПО. С моей точки зрения, ответ на этот вопрос ясен: профессиональная разработка ПО должна быть инженерией. Такова ли она сегодня? Нет. А должна быть? Несомненно."

Что есть разработка ПО

Читаю книгу Стива Макконнелла "Профессиональная разработка ПО", вот одна из любопытных цитат:

"Один из моих любимых вопросов во время собеседования с претендетами на должность программиста, следующий: "Как бы вы описали ваш подход к программированию?" ... Мне больше всего нравится такой ответа: "При проектировании ПО я архитектор. Когда я конструирую интерфейс пользователя, я художник. Когда я пишу код я ремесленник. А когда я тестирую программу, я ужасная сволочь."

Совершенный код. Часть 1

В компьютерной индустрии существует не такое уж большое количество книг, не нуждающихся в представлении, и книга Стива Макконнелла “Совершенный код” входит в их число. Если в любой поисковой системе ввести название этой книги, то вы получите сотни отзывов и тысячи мнений. Мое мнение будет простым и коротким однозначно “Must have”, ну а приведенные цитаты смогут доказать (или опровергнуть) мое мнение по отношению к этой книге.

С концептуальной точки зрения каждая программа уникальна, поэтому трудно или даже невозможно разработать общий набор директив, приводящих к решению во всех случаях. Так что знание общего подхода к проблеме не менее, а то и более ценно, чем знание точных решений конкретных проблем.
Глава 2.2 Как использовать метафоры?

Не зависимо от экономических подъемов и спадов хороших программистов всегда не хватает, а жизнь слишком коротка, чтобы тратить ее на работу в отсталом учреждении при наличии множества лучших вариантов.
Глава 3.1 Причины неполной подготовки

Как сказал Дэвид Грайс, подход к программированию не должен определяться используемыми инструментами. В связи с этим он проводит различие между программированием на языке (programming in language) и программирование с использованием языка (programming into language). Разработчики, программирующие "на" языке, ограничивают свое мышление конструкциями, непосредственно поддерживаемым языком. Если предоставляемые языком средства примитивны, мысли программистов будут столь же примитивными.
Разработчики, программирующие "с использованием" языка, сначала решают, какие мысли они хотят выразить, после чего определяют, как выразить их при помощи конкретного языка.
Глава 4.3 Волны развития технологий

Хорст Риттел и Мелвин Беббер определили "грязную" проблему как проблему, которую можно ясно определить только путем полного или частичного решения. По сути данный парадокс подразумевает, что проблему нужно "решить" один раз, чтобы получить ее ясное определение, а затем еще раз для создания работоспособного решения.
Глава 5.1 Проектирование - "грязная" проблема

Дейкстра пишет, что ни один человек не обладает интеллектом, способным вместить все детали современной компьютерной программы, поэтому нам - разработчикам ПО - не следует пытаться охватить всю программу сразу. Вместо этого мы должны попытаться организовать программы так, чтобы можно было безопасно работать с их отдельными фрагментами по очереди. Целью этого является минимизация объема программы, о котором нужно думать в конкретный момент времени. Можете считать это своеобразным умственным жонглированием: чем больше умственных шаров программа заставляет поддерживать в воздухе, тем выше вероятность того, что вы уроните один из них и допустите ошибку при проектировании или кодировании.
Глава 5.2 Важность управления сложностью

Остаться в живых. Часть 2

Продолжение цитат из книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".

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

Лучше подождать, пока продуктивный программист не станет доступным, чем ждать, пока первый доступный программист не станет продуктивным
Глава 7. Новые разработчики: доступные и хорошие

Разработка и обеспечение качества не должны выполняться одними и теми же людьми. Ответственный за обеспечение качества играет роль "адвоката дьявола", которую трудно или невозможно совместить с деятельностью разработчиков.
Глава 7. Организация команды проекта

Используя лишь самых продуктивных разработчиков, руководители проекта способны свести их с ума постоянными отвлечениями от основной работы, существенно замедляющими развитие проекта.
Глава 7. "Команды тигров"

Самой трудной частью сбора требований является не запись пожеланий пользователей, а исследовательская деятельность, направленная на помощь пользователям в определении своих пожеланий.
Глава 8. Разработка требований

Объясните пользователям, что прототип - это "не более чем прототип". Один из рисков, связанных с созданием прототипа пользовательского интерфейса, состоит в появлении нереалистичных ожиданий пользователей по поводу будущего развития проекта.
Глава 8. Создание простого прототипа пользовательского интерфейса

Качество - это степень удовлетворения программным продуктом требований, как утвержденных официально, так и подразумеваемых.
Глава 9. Обеспечение качества

Для высококачественного программного продукта число тестировщиков должно равняться числу разработчиков.
Глава 9. Тестирование системы

Тестирование представляет собой способ определения уровня качества программного продукта, а не способ его обеспечения.
Глава 9. Тестирование системы

Поскольку целью архитектуры является упрощение программного продукта, архитектор должен сконцентрировать свое внимание на том, что можно исключить из продукта, а не на том, что можно включить в него.
Глава 10. Подсистемы и организация

В погоне за лучшим вы рискуете остаться ни с чем. Придерживайтесь минимализма, простоты, удовлетворяйте все требования и не пытайтесь найти единственное идеальное решение.
Глава 9. Определение готовности архитектуры

Лучше работать разумно и много, чем неразумно много!
Глава 12. Если микровеховый план не выполняется

В зависимости от длительности и предметной области проекта, период после выпуска - хорошее время для того, чтобы предложить команде ланч, предоставить дополнительный выходной или вовсе отправить ее в оплачиваемый отпуск на Гавайи. Ну а на досуге следует сделать выводы из накопленного опыта и заложить основу для будущего успеха.
Глава 18. Хронология проекта

Поощрение команды никогда не приведет к провалу, а ее угнетение - к успеху.
Глава 19. Желательные действия

Все цитаты книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".

Часть 1

Часть 2

Остаться в живых! Часть 1

Сегодня я решил опубликовать цитаты из книги Стива Макконнелла ""Остаться в живых! Руководство для менеджера программных продуктов". Книгу я читал уже довольно давно (года три назад) и тогда она на меня произвела двоякое впечатление. Первая часть книги, в которой автор сосредотачивается на общих сведениях, мне очень понравилась, а вот вторая, более конкретная, мне понравилась не очень сильно и я не решился применять советы автора на практике. Хотя у вас может быть и другое мнение:)

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

На первой цитате я хочу остановиться подробнее. Во-первых, автором этой цитаты является не Стив Макконнелл, а Александр Милн, а во вторых, ее нельзя публиковать без рисунка, а в третьих, несмотря на то, что Милн, мягко говоря, не имеет никакого отношения к компьютерам, эта фраза имеет непосредственное отношение к разработке ПО.

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

Об авторе

Исследователи обнаружили, что стоимость позднего исправления ошибки, внесенной в проект на ранней стадии (например, при формировании требований или архитектуры), в 50-200 раз выше, чем стоимость ее исправления сразу же после внесения.
Глава 3. "В начале потока" и "в конце потока"

Конус неопределенности задает ряд жестких предпосылок для оценки проектов. Так, он подразумевает, что на ранних стадиях проекта точно оценить проект не просто трудно, а теоретически невозможно. После окончания формирования требований область действия проекта будет зависеть от огромного числа решений на этапах создания архитектуры, детального проектирования и конструирования. Если кто-то берется оценить влияние этих решений до их принятия, то возможны два варианта: либо этот человек обладает даром предвидения, либо попросту плохо осведомлен о сущности программной разработки
Глава 3. Предпосылки для оценки проекта

В начале проекта вы можете определить для него либо фиксированные сроки и бюджет, либо фиксированный функциональный набор. Определить и то и другое одновременно - невозможно.
Глава 3. Предпосылки для оценки проекта

Добиться успеха в небольших проектах можно при благоприятном стечении обстоятельств простым напряжением силы воли, однако средние и крупные проекты требуют более систематического подхода
Глава 4. Навыки выживания

В некоторых организациях проблема финансирования программных проектов состоит в том, что менеджеры вынуждены делать запросы финансирования раньше, чем у них появляется возможность завершить значительную часть исследовательских работ. Такие запросы обречены на "промах", поскольку для осмысленного расчета оценок бюджета и сроков проекта о желаемом продукте известно слишком мало. Опыт программной индустрии свидетельствует о том, что оценки, создаваемые на ранних стадиях проектов, могут отличаться от действительных в большую или меньшую сторону до четырех раз.
Глава 4. Двухэтапный подход к финансированию

Любой участник среднего или крупного проекта не понаслышке знает, что очень многое в нем может пойти "не так"
Глава 4. Управление рисками

В силу загадочных для меня причин люди полагают, что можно контролировать проект, не выделяя для этой цели какую-то группу или отдельное лицо. Мое мышление и опыт говорят, что это невозможно
Глава 4. Контроль над проектом

Разработка программных продуктов требует творчества, интеллекта, инициативности, настойчивости и значительной степени внутренней мотивации. Любой эффективный подход к разработке программного обеспечения должен подразумевать, что в отсутствие интереса команды к проекту его успех сомнителен.
Глава 4. "Человеческое обеспечение"

Не пытайтесь мотивировать разработчиков эффективными выступлениями, недостижимыми результатами или денежными вознаграждениями
Глава 4. "Человеческое обеспечение"

Разработка программных продуктов - это процесс постоянных исследований и поиска, поэтому лучшая его поддержка - это спокойная обстановка, располагающая к размышлениям. Эффективная разработка программ требует от разработчиков такого же уровня концентрации, как от математиков или физиков. Можете ли вы представить Альберта Эйнштейна, сидящего за рабочим столом, вокруг которого ходит менеджер и раздраженно повторяет: "Альберт, теория относительности нужна нам прямо сейчас! Поторопись!"
Глава 4. "Человеческое обеспечение"

Работа среднестатистического менеджера требует переключения внимания каждые несколько минут. Работа среднестатистического разработчика требует, чтобы переключение внимания происходило не чаще, чем раз в несколько часов.
Глава 4. "Человеческое обеспечение"

С точки зрения сложности компонентов программного продукта и их функциональности, успешная разработка проекта подчиняется принципу "чем меньше, тем лучше", действующему на всех этапах - от формирования требований до выпуска. Поскольку разработка программного продукта требует значительных интеллектуальных усилий, становится важно, чтобы участники проекта активно способствовали его максимальному упрощению, избавляя проект от излишней сложности.
Глава 4. Минимализм продукта

Французский писатель Вольтер говорил, что рассказ закончен не тогда, когда в него нечего добавить, а тогда, когда из него нечего больше выкинуть. Этот подход применим и к программному проекту.
Глава 4. Минимализм продукта

Эффективные проекты контролируют изменения; неэффективные проекты находятся под контролем изменений.
Глава 6. Стрельба по движущейся цели

Хорошо организованные проекты неизбежно ищут компромисс между функциональным набором, бюджетом и расписанием
Глава 7. Цели в области действия проекта

Все цитаты книги Стива Макконнелла "Остаться в живых! Руководство для менеджера программных проектов".

Часть 1

Часть 2