Часто задаваемые вопросы

Так с чего же начать? Как узнать, какие шаги делать в первую очередь?

Многие команды, впервые сталкивающиеся с ХР, задают эти вопросы, но на них нет однозначного ответа. Он зависит от конкретных проблем. На первой странице этой главы приведена цитата, в которой говорится о том, как люди ненавидят перемены. Не стоит это недооценивать.

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

Итак, каким должен быть первый шаг? Если вы рассматриваете ХР в качестве инструмента для решения проблем, то логично предположить, что они у вас есть. Каковы эти проблемы? Какие ХР-практики могут помочь вам их решить?

Если проблемы связаны с ошибками, то попробуйте начать с разработки через тестирование. А может, члены вашей команды не общаются между собой или удивляются изменению требований? Тогда добавьте истории, но пробуйте практики по одной – и не только для галочки. Соберитесь всей командой и поговорите о ценностях и принципах ХР.Убедитесь, что все понимают, чего вы пытаетесь добиться при помощи этой практики. Если каждый человек понимает, в чем заключается проблема, которую вы пытаетесь решить, и как она влияет на него самого, то вы сможете оценить, насколько хорошо эта практика будет работать.

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

Меня беспокоит, что я не понимаю, как применить парное программирование к моему проекту. Что оно может дать?

Когда команда пытается внедрить XP, но в конце концов возвращается к прежним методам работы, практика парного программирования, как канарейка в угольной шахте, погибает первой. Так случается часто, потому что эта практика наиболее явно демонстрирует разницу между мышлением команды и ценностями ХР. Поэтому если вы не видите смысла в парном программировании, то обдумайте ценности ХР заново.

Коммуникация

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

Простота

Считаете ли вы нормальным, если кто-то говорит, что код, который вы только что написали, очень сложный? Готовы ли вы выделить время, чтобы исправить его немедленно, или оставите комментарий «сделать» либо «решить позднее»? А если поджимают сроки, вы все равно готовы заняться упрощением кода?

Обратная связь

Хорошо ли вы себя чувствуете, если кто-то говорит вам – возможно, проявляя бестактность, что характерно для многих программистов, – что ваш код не очень хорош?

Мужество

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

Уважение

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

Если в вашей команде не все гладко с реализацией этих принципов, то их анализ поможет вам понять, что необходимо делать, прежде чем внедрять ХР.

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

Существует наихудший сценарий, когда образ мыслей не позволяет команде использовать парное программирование, но дает внедрить какую-то иную практику XP. Однако недостаточно просто внедрить практику, кажущуюся бессмысленной. Нужно убедиться, что вся ваша команда обсуждает ХР-ценности и серьезно относится к принципам. Есть надежда, что спустя некоторое время вы вернетесь к парному программированию и обнаружите, что ваше мышление изменилось благодаря маленьким шагам, сделанным в применении других практик.

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

Разработка через тестирование – это не просто добавление тестов и проверка того, что они выполняются. Чувствуете ли вы дискомфорт от идеи разработки через тестирование? Если да, то это показатель того, что вам нужно пересмотреть свои взгляды на ценности и принципы. Вероятно, вы обнаружите, что не поняли один из них. Может быть, у вас проблема с принципом качества, который означает, что каждый член команды отвечает за качество проекта. Вы не можете просто «перекинуть» код на этап тестирования и назначить ответственного за поиск ошибок. Возможно, вас тревожит избыточность – кажется, что эти тесты добавляют дополнительный, потенциально дублирующий код. Потратьте немного времени на переосмысление принципов и ценностей и попытайтесь сформулировать, что именно вам не вполне понятно.

Действительно, написание модульных тестов требует времени, и очень часто разработчики считают, что это напрасный труд[55]. Но самое забавное происходит, когда программисты все-таки начинают заниматься разработкой через тестирование. В какой-то момент модульный тест дает сбой, тем самым выявляя маленькую, но неприятную ошибку, которая потом могла бы отнять массу времени. Несколько подобных случаев переубедят любого скептика. Когда это происходит, многие agile-разработчики говорят, что вы «заражаетесь тестами», и разработка через тестирование становится естественным способом создания программного обеспечения.

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

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме Часто задаваемые вопросы:

  1. Часто задаваемые вопросы
  2. Часто задаваемые вопросы
  3. Часто задаваемые вопросы
  4. Часто задаваемые вопросы
  5. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  6. Часто задаваемые вопросы
  7. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  8. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  9. Часто задаваемые вопросы
  10. Часто задаваемые вопросы
  11. Часто задаваемые вопросы
  12. Часто задаваемые вопросы
  13. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  14. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  15. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  16. ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ
  17. Часто задаваемые вопросы