Deadline. Роман об управлении проектами.

Изредка вношу изменения в список книг для прочтения. Обычно это происходит по чьему-то совету. На этот раз, мое внимание на Dedline Тома Демарко обратил Максим Юдин. С творчеством Тома Демарко был знаком по книге Человеческий фактор. Успешные проекты и команды, которую отношу к классике. Впечатления получились не такие яркие, как от "Цели" Голдрата, но книга однозначно интересная и стоит того, чтобы уделить ей внимание.
В Deadline используется прием выделения основных мыслей, в качестве дневника главного героя. Так что, любителям концентрата мысли достаточно будет прочитать записи мистера Томпкинса. По сути цель остальной части книги, донести контекст формирования данных идей. Идеи же по сути являются паттернами и анти-паттернами процесса управления проектами. Отдельно хотелось бы отметить социологическую составляющую правил. Короче, если в вашей методологии управления человеку выделена роль безликого инструмента - то вашу методологию необходимо спустить в унитаз.
Книгу можно рекомендовать абсолютно всем людям, участвующим в процессе разработки. Время на ее прочтение требуется немного (можно прочитать за выходные на даче). Также можно потратить пару часов и выписать себе дневник мистера Томпкинса в отдельный список. Я потратил. Буду иногда перечитывать. Люблю концентраты.

Издательство "Символ-Плюс" буквально разродилось недавно целым набором книг, среди которых и Балдеющие от адреналина, зомбированные шаблонами Тома Демарко в соавторстве с Тимоти Листером. Лично я уже забронировал для нее место в своем списке must-read книг.
Да, чуть не забыл. Deadline я готов любить только за то, что в этой книге содержится фраза:
"Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно".

Бережливое производство программного обеспечения. От идеи до прибыли.

Удивительным образом иногда получается так, что книги которые идут в каком-то случайном порядке, складываются в единый звучный аккорд. Так "бережливое производство" попало в тон предыдущих двух книг. Прежде всего хотелось бы отметить название книги. В оригинале книга называется "Implementing Lean Software Development: From Concept to Cash". Переводчик не поддался стереотипам и в результате development звучит как производство, а не как более привычное всем разработка. Именно отождествление разработки ПО с процессом производства, а точнее с наиболее успешными его практиками, является основным мотивом всей книги. Практически в каждой главе используется один и тот же прием - success story из мира промышленного производства, выделение успешных практик, лежащих в основе успеха данного случая, и проецирование данных практик в область разработки ПО. Наибольший интерес, лично для меня, представляли методы борьбы с потерями. Выделенные непроизводительные расходы в разработке ПО, сопровождаются наглядными примерами. В конце каждой главы предлагается набор предложений, ведущих к улучшению процесса. Затрагиваются вопросы отношения к персоналу, организации знания, обеспечения качества, взаимодействия. Приводится понятие квадрантов тестирования, уже знакомое по книге Гибкое тестирование, теории очередей, 14 заповедей Деминга, инициативы Шесть сигм и теории ограничений. В финале предоставляется руководство к действию в виде дорожной карты, как выжимка основных идей книги.
Таким образом мог бы посоветовать в качестве горячего прочитать Цель, на второе употребить данную книгу, и в качестве сытного десерта прочитать про гибкое тестирование.

Цель. Процесс непрерывного совершенствования.

По совету уважаемого жж-пользователя cartmendum решил выделить время на прочтение данной книги. Отзыв самого картмендума можно прочитать непосредственно здесь. Могу лишь добавить, что испытал аналогичные эмоции. Книга читается просто запоем. Настолько легко и непринужденно доносятся до читателя основные идеи. Казалось бы, ну как можно донести методологии организации производственного процесса - взять побольше формул, определений, разложить предметную область в понятийном базисе. Но нет - вот вам роман со всеми атрибутами: с первых страниц завязка, развитие сюжета, своего рода кульминация. Любовный треугольник: директор завода - завод - жена, непонимание, эмоции, переживания. Только вот концовка немного смазана, на мой взгляд. И это все про теорию ограничений. Про техническую область. Просто шикарно.
Однозначно не стоит рассматривать идеи сосредоточенные в книге прямолинейно, с позиции применимости только к промышленному производству. Разработка программного обеспечения тоже своего рода производство, и многие идеи теории ограничений находят отклики и в современных гибких методиках разработки ПО. Более того, можно провести прямые аналогии. Чтобы недалеко ходить, в "Цели" описывается момент переноса этапа проверки качества продукта в конце сборочного конвейера в точку перед станком обработки наиболее критичных деталей этого продукта. Это точ-в-точ подход к организации гибкого тестирования описанный в книге "Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд". Тестировщик подключается к разработке на самых начальных этапах, даже раньше чем разработчик начнет написание кода. Задача тестировщика след-в-след сопровождать разработчика, не допуская компромиссов по качеству и выявляя на ранних этапах возникающий брак.
Книга оказалась особенно актуальной в рамках моего знакомства с методологией разработки ПО Lean. Так что, если вы активный борец с потерями, то вот вам идеальный success-story.
Книгу можно прочитать уже только за то, что она дает яркий пример зависимости мышления человека от привычек и стереотипов, и что иногда полезно окунуться в холодный чан новых знаний и увидеть, что "король то голый".

Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких комманд.

Редко когда приходится заставлять себя дочитывать ту или иную книгу. С данной книгой пришлось побороться. Причину сложно найти - книга составлена грамотно, впрочем как и вся серия addison-wesley. Но скучно. Просто скучно. По крайней мере для меня, как человеку бесконечно далекого до области quality assurance и тестирования ПО. Мои отношения с тестированием заканчиваются ровно на модульных тестах и причин развивать эти отношения в ближайшем будущем не предвидется. Что-то нового для себя как для разработчика подчерпнуть я не сумел, хотя общие взгляды на взаимоотношения тройки заказчик-тестировщик-разработчик поменял.
Книга систематизирует понятие тестирования ПО (при помощи квадрантов тестирования), демонстрирует в определенной степени новую роль тестировщика ПО и его позицию в команде, указывает набор полезных практик в области тестирования, изобилует историями из жизни.
Однозначно советовал бы данную книгу людям, занятым в области высокоуровнего тестирования ПО (на уровне приемочных тестов), особенно тем, кто погряз в рутине ручного тестирования. Книга может придать решимости амбициозным тестировщикам, которых не устраивает надменное отношение со стороны разработчиков, занять новую уникальную роль в команде. Можно советовать данную книгу менеджерам проектов, как источник здравых идей для экспериментов. Ну и наконец людям, которые не пропускают ни одной книги из серии "подписанных", таким как я, например.