[Отзыв]: Экстремальное программирование

Это, наверное, одна из самых крутых книг, которые я читал про методологии и управление командой. Очень классно расписаны основные практики из экстремального программирования. Простые и понятные аналогии для проблем, возникающих у разработчиков и менеджеров в сфере IT.

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

Не буду вдаваться в подробности описания самой методологии, потому что это бессмысленно делать в трех абзацах. Скажу только, что книга просто must have в списке прочитанной литературы для любого уважающего себя программиста, менеджера и тим лида. Даже если вы не используете XP, нужно ознакомиться, там очень хорошо описаны повадки и особенности склада ума программистов.

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

Линк на книгу прилагается:

"Экстремальное программирование: разработка через тестирование" Кент Бек - Test-driven Development by Example ISBN 5-8046-0051-6"Экстремальное программирование: разработка через тестирование" Кент Бек - Test-driven Development by Example ISBN 5-8046-0051-6

Прочитать

XP и игра слов

Во время подготовки презентации к своему курсу "Экстремальное программирование" в книге с одноименным названием наткнулся на очень классные мысли, которые уже наверное были неоднократно высказаны кем-либо, а возможно и просто нагло скопипи*жены. Суть не в этом. Мне нравится находить игру слов и тут будет именно про неё.

К примеру, готов поставить памятник ребятам, которые сделали рекламу для РОСНО, в ней было использовано различие между корнями слов "страховая" в английском и русском языках. Слоган "РОСНО — The insurance company" до сих пор сидит в голове(к сожалению не смог отыскать ролик на просторах Youtube).

Вернемся к XP. Достаточно давно, хотя в рамках человеческой истории совсем недавно, многие компании использовали инженерный подход к разработке программного обеспечения. Сначала тонна бумаги и согласований, затем код. Это великолепно работает при проектировки зданий, мостов и других объектов, которые должны стоять в одном положении на протяжении многих лет. Это также рождает определенные трудности, как например, внесение изменений в процессе разработки. Как же так, план согласован и нельзя уже отходить от него ни на шаг.

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

Рассмотрим этот вброс подробнее:

  • Программное обеспечение на англ языке звучит как "software"
  • Аппаратное обеспечение — "hardware"

Hard - тяжелый, жесткий
Soft - легкий, гибкий, непостоянный

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

Поэтому люди все-таки пришли к гибким (см. одно из значений слова soft) методологиям и поэтому они сглаживают кривую роста затрат на внесение изменений. Такие подходы изначально рассчитаны на постоянную эволюцию ПО.

Прочитать