Книга уже весьма старая (бумажные карточки историй и задач), и многое из того, о чем говорит автор, является само собой разумеющимся: разработка через тестирование, рефакторинг, непрерывная интеграция, стандарты кодирования – все это стало обычными рабочими инструментами. Хотя автор и не приписывает себе изобретение методик, уже в то время они были известны, а от некоторых отказались в пользу более сложных, в заслугу ставится именно объединение их в рамках одной методологии.
Дальце, традиционно, конспект.
ХР одна из гибких методологий – в остальных иное отношение к парному программированию, итерациям, другим аспектам. Здравый смысл говорит, что вряд ли в парах удастся программировать дольше 20% времени.
4 ценности: коммуникация, простота, обратная связь и храбрость. Отдельным пунктом идет взаимное уважение – именно оно дает жизнь методологии. 5 принципов: быстрая обратная связь, приемлемая простота, постепенное изменение, приемлемое изменение, качественная работа. 4 основных рода деятельности: кодирование, тестирование, слушание, проектирование. 12 методик: игра в планирование, небольшие версии, тестирование (модульное от программистов и функциональное от бизнеса), метафора (простая, общедоступная и общеизвестная история, которая коротко описывает всю систему), простой дизайн, рефакторинг, программирование парами, коллективное владение, непрерывная интеграция, 40-часовая рабочая неделя (нельзя перерабатывать больше двух недель подряд), заказчик на месте разработки (человек, который будеть использовать систему), стандарты кодирования. Все это автор трижды повторяет с разных точек зрения в трех частях книги.
В качестве основной идеи автор советует не сосредотачиваться на методиках слишком сильно, чтобы не забыть, что основная работа программистов – программирование. Другая идея относится к качеству работы: качество работы повышается от осознания работы над качественным продуктом, в обратном случае наступит деморализация.
ХР очень сильно сосредоточена на как можно более раннем запуске минимально-достаточно-рабочего проекта в эксплуатацию, что позволит снизить риски планирования. Зачастую, в начале проекта требования заказчика не бывают четкими и ясными – ранний запуск позволит кристаллизовать видение заказчика.
Спорный момент: дизайн программы должен быть максимально простым, и не должно быть элементов, которые предположительно могут быть использованы в будущем – предположения эти в большинстве случаев не оправдываются. На мой взгляд, избегать закладывать очевидные точки гибкости и расширения это излишне, хотя усердствовать тоже не стоит – золотая середина придет с опытом. А в долгосрочной перспективе простота может сыграть злую шутку. Автор утверждает, что 2% вероятность успешного прогноза, и что сложный дизайн, спустя год, зачастую, не сожержит ни одного верного предполжения.
Автор очень часто говорит про отказ от написанного кода, конечно, с репозиториями эта проблема не настолько остра, но уединиться попрограммировать для удовольствия, а потом выбросить написанное – звучит крайне странно.
Интересная идея про ориентацию на победу или непроигрыш: изводится много бумаги, тратится много времени на совещания, все работают строго по книжке – все, для того, чтобы в случае неудачи сказать, что я все делал правильно и это не моя вина.
Открытая и честная коммуникация еще один основной принцип: программисты должны уметь объяснять последствия решений, принимаемых другими людьми.
Код является основным артефактом. Он используется для общения, чтобы объяснить тактическое намерение, указать на точки расширения и сокращения, кодом описываются тесты, которые сами, в свою очередь, являются ценной спецификацией и повышают уверенность программиста. Система (код и тесты) должна выражать собой все, что вы хотите сообщить о ней всем остальным участникам проекта. Система должна быть выгоднее, чем работа одного сотрудника, в противном случае внедрение не имеет смысла.
Автор раз за разом высказывается что ХР делает все, для того чтобы проект как можно дольше не умирал и только однажды высказывается, что будет экономически выгоднее, если смерть проекта станет очевидна раньше. Тем не менее иногда проекты умирают от энтропии, когда кончаются ресурсы на борьбу с ней.
В ХР менеджер не должен создавать излишней нагрузки, отвлекая весь отдел на регулярные и длительные совещания по текущему состоянию дел в проекте. Также менеджер должен отмечать людей не справляющихся с обязанностями и просить их уйти.
ХР тяготеет к большим открытым пространствам, с видимостью и слышимостью всех членов команды, чтобы вовремя сделать ценное замечание. В таком отделе обычно появляется уютный уголок с игрушками и сладостями, чтобы программисты могли отвлечься и вознаградить себя за успешную работу.
Наименее важные требования, как правило, являются источниками наибольшего риска, поскольку они анализируются и обдумываются меньше всего времени, что резко повышает вероятность их изменения. Часто такие требования оказываются наиболее рискованными и с технической точки зрения. Еще одним источником риска является большая свобода разработчиков в выборе технических средств - разработчики захотят опробовать технологические новинки.
Для взвешенного решения бизнес должен обладать знанием: какие ресурсы потребуются, какие имеются, возможные ограничения и стоимость каждого их вариантов. Обладая этим знанием, бизнес должен определить следующее: объем работ и время выпуска версий, приоритеты всех возможностей системы, объем работ на каждую возможность системы. Разделение ответственности между бизнесом и разработчиками - это не отказ от грязной работы. Наоборот - это отделение той работы, которая очевидно является сложной, от той, про которую еще не придумали, как её сделать простой.
При планировании необходимо добиться от каждого заинтересованного лица ощущения того, что система может быть реализована. При этом не обязательно скурпулезно планировать на годы вперед: ближайшая итерация может быть спланирована подробно, а остальные описаны несколькими тезисами. В рамках ХР планирование не может идти сверху вниз, у программистов обязательно дожна быть свободна одно из четырех ограничений (объем, время, качество, ресурсы). Команда должна сама брать на себя ответственность. Планирование всегда должно иметь цель, не должно быть планирования ради планирования: для заказчика оно может быть менее подробным, чем при анализе специфических тестовых сценариев. Распространена идея подписки: вместо фиксированных цены/даты/объема работ, команда обязуется работать на заказчика с максимальной скоростью в течение определенного промежутка времени, следя за мнением заказчика относительно направления развития разработки.
В рамках ХР проектирование - это не рисование огромного количества схем и затем реализация системы в соответствии с ними, это скорее напоминает управление автомобилем во время езды по шоссе с регулярным выравниеванием курса.
Программист, занимающийся тестированием, сущестувет не для того, чтобы написать как можно больше тестов, а написать тесты, которые лучше всего подчеркивают функциональность или, наоборот, недееспособность системы.
Общение очень важно: автор рекомендует регулярно устраивать праздники и вечеринки: в конце каждой итерации, после внедрения в эксплуатацию, по завершению проекта. Передать новичку культуру также важно как и передать знания о деталях дизайна и реализации, и это возможно только при личном контакте. Команда важнее процессов и необходимо подстроить систему, чтобы в полной мере проявить таланты каждого. Иногда руководители слишком сильно фокусируются на правильности системы, что не замечают, как она перестает работать.
Заказчик дожен оказывать мягкое влияние на систему, не будучи в состоянии контроллировать её. Силы, которые действуют вне рамок контроля заказчика, формируют то, что создается в рамках проекта, в такой же степени, как и решения, которые принимает заказчик. Каждый раз, когда влияние становится слишком сильным, участники становятся менее самостоятельными. При слишком активном руководстве команда потеряет возможность работать без жесткого контроля (повышение контроля ведет к минимальному уровню инициативности). В результате ослабеет моральный дух и снизится качество. Великое искусство - не говорить напрямую, что видите, а говорить так, что вся команда тоже начинает это видеть.
Для поддержки процесса в состоянии баланса приходится жертвовать наиболее технически опытным членом команды, поскольку это очень непростая задача.
Post Scriptum
Интересно, что у нас многие методики из ХР прижились сами собой: итерации, периодическое программирование парами на сложных задачах, непрерывная интеграция, даже стол с ништяками и игрушки чтобы можно было отвлечься.
