Текст книги "Гибкое управление IT-проектами. Руководство для настоящих самураев"

Для настройки системы непрерывной интеграции требуется несколько вещей:

♦ репозиторий исходного кода;

♦ процесс постановки кода на учет;

♦ автоматизированная сборка;

♦ готовность обрабатывать небольшие фрагменты.

В репозиториях исходного кода хранится ваша программа и ведется контроль ее версий. Именно здесь команда «учитывает» код. Это точка интеграции всего кода, и здесь же содержится его контрольный экземпляр. В данном случае вам очень пригодятся свободные репозитории исходного кода, такие как Git или Subversion.

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

Гораздо интереснее типичный процесс постановки кода на учет (check-in process). Рассмотрим, как он может строиться в обычной гибкой команде.

Как правило, для разработчика в составе гибкой команды процесс постановки кода на учет выглядит примерно так.

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

2. Внесение изменений. Затем вы выполняете свою работу: добавляете в программу новую функцию, исправляете ошибку или делаете что-то еще, что собирались.

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

4. Проверка на наличие обновлений. Удостоверившись, что измененная программа работает, вы берете из репозитория еще одно обновление, чтобы проверить, не внес ли кто-нибудь в код новые изменения, пока вы работали.

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

6. Постановка кода на учет. Итак, все работает. Сборка происходит. Тесты выполняются. У нас в руках – новейшая версия. Ее можно ставить на учет.

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

В конечном счете все сводится к внимательному отношению к сборке. Нужно гарантировать, что она всегда находится в рабочем состоянии, и помогать товарищам, если она ломается (что время от времени происходит).

Следующий этап – организация автоматизированной сборки. На самом деле именно она образует каркас процесса непрерывной интеграции, проводимого вашей командой.

Хорошая автоматизированная сборка компилирует код, выполняет тесты и вообще делает все, что регулярно требуется в процессе сборки проекта.

В процессе разработки на основе тестирования программисты постоянно пользуются такой сборкой, а агенты сборки (например, CruiseControl[26]26
  http://cruisecontrol.sourceforge.net/.


[Закрыть]) применяют данный механизм всякий раз, когда обнаруживают изменения в репозитории с исходным кодом.

Подобные сборки также позволяют автоматизировать развертывание программы для промышленного использования и избавиться от множества человеческих ошибок.

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

В большинстве современных языков программирования есть собственные фреймворки автоматизированной сборки (automated build frameworks): Ant в Java, NAnt или MS-Build в. NET, rake в Rails. Если в языке, с которым вы работаете, такого фреймворка нет, вы обычно можете сами его создать с помощью BAT-файлов DOS или скриптов Unix.

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

Как и тестирование при разработке на основе тестирования, так и интеграция протекают гораздо лучше, если делать все небольшими фрагментами.

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

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

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

Где подробнее изучить эту тему

Непрерывная интеграция стала такой распространенной практикой, что почти любую информацию о ней можно найти в Интернете.

Об этом методе хорошо рассказано в статье англоязычной «Википедии»[27]27
  http://en.wikipedia.org/wiki/Continuous_integration. Русскоязычный вариант: http://ru.wikipedia.org/wiki/Непрерывная_интеграция.


[Закрыть], а одна из первых статей о непрерывной интеграции размещена на сайте Мартина Фаулера[28]28
  http://martinfowler.com/articles/continuousIntegration.html.


[Закрыть].

УЧЕНИК: Мастер, мы определенно не сможем подготовить весь код к реальному использованию за одну лишь первую итерацию. Что же на самом деле понимается под «реальным использованием»?

МАСТЕР: Это отношение к работе. Когда вы пишете готовый к использованию код, вы сегодня же тестируете и интегрируете свою программу. Если вы замечаете ошибку, то исправляете ее сразу же. Вы не откладываете ее в долгий ящик и не думаете, что еще сможете вернуться к ней когда-нибудь потом. Вы относитесь к программе так, как будто она должна работать уже сегодня, а не в далеком будущем. Да, после первой итерации у вас, конечно же, не будет проработано все и вся и вы можете не приступать к развертыванию, пока в программе не наберется определенного количества функций. Но если перед вами стоит перспектива развертывания и вы знаете, что ваша программа работает, то вы признаете, что большую часть своего существования эта программа проведет не в разработке, а в действии. Так вы привыкаете к мысли, что все изменения вносятся в практически значимую систему.

УЧЕНИК: Что, если я не могу построить целостную систему, так как моя работа – лишь часть большого проекта?

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

Вот и все, народ!

Итак, вы прочитали книгу. Мы превосходно поработали над важнейшими практиками гибкой разработки программ.

♦ Тестирование компонентов – чтобы убедиться, что написанная нами программа работает.

♦ Рефакторинг – искусство простоты и сохранения кода чистым и удобочитаемым.

♦ Разработка на основе тестирования – для проектирования и работы со сложными деталями.

♦ Непрерывная интеграция – регулярное приведение работы к общему знаменателю и обеспечение готовности программы к реальному использованию.

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

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

Дальнейший путь избираете вы сами.

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

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

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

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

Так чего же вы сидите?

Действуйте!

И напоследок

Это вопрос выбора.

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

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

Не проповедуйте.

Не учите людей жить.

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

Да, чуть не забыл…

Не зацикливайтесь на гибкой разработке

Во многих командах, обращающихся к этой методологии, часто возникает вопрос: «А мы уже стали гибкой командой?»

И этот вопрос совершенно оправдан. Когда делаешь что-то впервые, то, разумеется, хочешь знать, как ты это делаешь и все ли получается «по науке».

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

Это путешествие, а не рейс. Вы никогда его не завершите.

И не забудьте о том, что смысл заключается не в том, чтобы быть гибким, а в том, чтобы писать высококлассные программы и оказывать клиенту безупречные услуги.

Будьте осторожны: если у вас появляется ощущение, что вы все поняли и всего достигли, – это означает, что вы потеряли гибкость.

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

♦ удается ли нам каждую неделю создавать что-то ценное;

♦ есть ли у нас постоянное стремление к совершенству?

Если вы утвердительно ответили на оба этих вопроса, то вы достигли гибкости.

Приложения

Приложение А. Принципы гибкой разработки

Здесь приведены Манифест гибкой разработки[29]29
  http://agilemanifesto.org.


[Закрыть] и 12 основополагающих принципов гибкой разработки, взятые с сайта этого Манифеста[30]30
  http://agilemanifesto.org/principles.html.


[Закрыть].

А1. Манифест гибкой разработки

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

♦ личности и их взаимодействие важнее процессов и инструментов;

♦ работоспособное программное обеспечение важнее обширной документации;

♦ сотрудничество с заказчиком важнее согласования условий контракта;

♦ умение реагировать на изменения важнее следования плану.

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

А2. 12 принципов гибкой разработки

1. Нашим главным приоритетом является удовлетворение заказчика по средством ранней и непрерывной поставки работоспособного программного обеспечения.

2. Изменение требований приветствуется даже на поздних стадиях разработки. Гибкие процессы используют изменения как средство обеспечения конкурентных преимуществ для заказчика.

3. Работоспособное программное обеспечение следует выпускать часто: от раза в несколько недель, до раза в несколько месяцев, отдавая предпочтение коротким интервалам.

4. Представители бизнеса и разработчики должны работать вместе в течение всего проекта.

5. Проекты необходимо строить вокруг мотивированных профессионалов. Предоставьте свободу и поддержку, в которой они нуждаются, и доверьте им самим делать работу.

6. Наиболее эффективным способом передачи информации команде проекта (а также внутри команды) является непосредственное живое общение.

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

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

9. Непрерывное внимание к техническому совершенству и хорошему дизайну увеличивает степень гибкости.

10. Простота – искусство минимизации лишней работы – является существенным фактором.

11. Наилучшие требования, архитектура и дизайн создаются самоорганизующимися командами.

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

Приложение Б. Интернет-ресурсы

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

http://tech.groups.yahoo.com/group/extremeprogramming.

http://groups.yahoo.com/group/scrumdevelopment.

http://tech.groups.yahoo.com/group/leanagile.

http://finance.groups.yahoo.com/group/kanbandev.

http://tech.groups.yahoo.com/group/agile-testing.

http://tech.groups.yahoo.com/group/agile-usability.

http://finance.groups.yahoo.com/group/agileprojectmanagement.

Приложение В. Список литературы

[Bec00] Kent Beck. Extreme Programming Explained: Embrace Change. – Addison-Wesley, Reading, MA, 2000.

[Bec02] Kent Beck. Test Driven Development: By Example. – Addison-Wesley, Reading, MA, 2002.

[Blo01] Michael Bloomberg. Bloomberg by Bloomberg. – John Wiley & Sons, Hoboken, NJ, 2001.

[Car90] Dale Carnegie. How to Win Friends and Influence People. – Pocket, New York, 1990.

[DCH03] Mark Denne and Jane Cleland-Huang. Software by Numbers: Low-Risk, High-Return Development. – Prentice Hall, Englewood Cliffs, NJ, 2003.

[DL06] Esther Derby and Diana Larsen. Agile Retrospectives: Making Good Teams Great. – The Pragmatic Programmers, LLC, Raleigh, NC, and Dallas, TX, 2006.

[Eva03] Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software. – Addison-Wesley Professional, Reading, MA, first edition, 2003.

[FBB+99] Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts. Refactoring: Improving the Design of Existing Code. – Addison-Wesley Longman, Reading, MA, 1999.

[Fea04] Michael Feathers. Working Effectively with Legacy Code. – Prentice Hall, Englewood Cliffs, NJ, 2004.

[GC09] Lisa Gregory and Janet Crispin. Agile Testing: A Practical Guide for Testers and Agile Teams. – Addison-Wesley, Reading, MA, 2009.

[HH07] Dan Heath and Chip Heath. Made to Stick: Why Some Ideas Survive and Others Die. – Random House, New York, 2007.

[HT03] Andrew Hunt and David Thomas. Pragmatic Unit Testing In Java with JUnit. – The Pragmatic Programmers, LLC, Raleigh, NC, and Dallas, TX, 2003.

[HT04] Andrew Hunt and David Thomas. Pragmatic Unit Testing In C# with NUnit. – The Pragmatic Programmers, LLC, Raleigh, NC, and Dallas, TX, 2004.

[Joh98] Spencer Johnson. Who Moved My Cheese? An Amazing Way to Deal with Change in Your Work and in Your Life. – Putnam Adult, New York, 1998.

[Lik04] Jeffrey Liker. The Toyota Way. – McGraw Hill, New York, 2004.

[McC06] Steve McConnell. Software Estimation: Demystifying the Black Art. – Microsoft Press, Redmond, WA, 2006.

[Moo91] Geoffrey A. Moore. Crossing the Chasm. – Harper Business, New York, 1991.

[Sch03] David Schmaltz. The Blind Men and the Elephant. – Berrett-Koehler, San Francisco, 2003.

[SD09] Rachel Sedley and Liz Davies. Agile Coaching. – The Pragmatic Programmers, LLC, Raleigh, NC, and Dallas, TX, 2009.

[Sur05] James Surowiecki. The Wisdom of Crowds. – Anchor, New York, 2005.

Для заметок

_______________________________________________

_______________________________________________

_______________________________________________

_______________________________________________

_______________________________________________