Борис Вольфсон недавно выпустил в релиз бесплатную электронную книгу про Agile. Постарался на благо сообщества, за что ему большое спасибо.
Дополнения к книге
Изначально я написал дополнения Борису на почту, когда книга еще была в бета-версии. В релизе он внес несколько изменений, но большая осталась неизменной. Главы, которые я не затронул ниже, по моему мнению, уже готовы и не требуют дополнений.
Прежде, чем читать мои дополнения, прочитайте, пожалуйста, саму книгу. В ней есть много полезной информации и объяснение тонкостей Agile «на яблоках». Если вы расплывчато представляли себе, что такое гибкие методологии разработки, то здесь они собраны воедино для создания целостной картинки.
Глава Scrum в заказной разработке
Когда заказчикам рассказываешь про Agile, они задают один и тот же вопрос: «Что я должен буду делать, как Product Owner? Мне надо знать, чтобы спланировать свое время». Мы пробовали давать материал про Agile, статьи, видео. В итоге, я нарисовал схему, на которой показаны все активности Product Owner'а во время разработки:
Глава Инженерные практики
Борис так много написал про управление в Agile и совсем крохи про инженерные практики. Баланс нарушен :)
Сколько продержится итеративная разработка, если программисты будут писать код, как и раньше, с уверенностью, что через неделю требования не поменяются? Я сходу могу вспомнить 3 примера, когда менеджеры внедрили Scrum, а программисты писали код по-старому. В результате проходило 3-4 итерации и в все понимали, что Agile не работает. Поэтому те, кто буду внедрять у себя Agile, для начала обратите внимание на инженерные практики - это фундамент для быстрой выдачи релизов и стабильной скорости разработки при меняющихся требованиях.
Непрерывная интеграция
Проводя консультации, я до сих пор вижу, что эта практика игнорируется. В компании две команды с одного проекта могут месяц делать свои модули не интегрируя код. После чего еще месяц они занимаются интеграцией. В продолжение этой темы могу посоветовать книжку .NET Delivery.
Разработка через тестирование и разработка с тестами
Главу можно дополнить парочкой популярных ответов/вопросов про TDD: TDD для начинающих. Ответы на популярные вопросы. А также специальная часть для PM'ов: Когда TDD начинает обгонять?.
Refactoring
Без этой практики код обязательно превратиться в кладбище технических долгов. После чего не помогут ни практики XP, ни Scrum, ни управление рисками. Останется только один вопрос: «Может лучше всё выкинуть и написать заново?». Про рефакторинг нужно прочитать две книжки: «Refactoring» М. Фаулер и «Refactoring to patterns» Д. Кериевски. Идею и проблематику рефакторинга можно проследить по слайдам:
Парное программирование
Про парное программирование стоит упомянуть ряд неявных достоинств. Часть перечислены на слайде из моего доклада про XP:
Еще для менеджеров неявным плюсом является, что в паре программист не будет сидеть ВКонтакте или консультировать кого-то в аське, он будет стараться сберечь время партнера.
Метафора
Очень хороший рассказ про то, что такое метафора можно посмотреть на InfoQ: Interview: Joshua Kerievsky on System Metaphor. Для программистов это одна из самых важных частей, т.к. с помощью метафоры вся команда понимает друг друга.
Коллективное владение кодом и стандарт кодирования
Важным преимуществом такого подхода является быстрое распространение знаний между участниками команды.
На самом деле суть не в распространении знаний. Как коллективное владение кодом и стандарты кодирования могут помочь распространять знания? Распространение знаний - это скорее про парное программирование и стендапы.
Суть коллективного владения кодом в том, что не надо ждать Васю, чтобы внести изменения в «его» модуль. А стандарты кодирования позволяют быстро читать код, который написал, другой член команды.
Почему до сих пор активно практикуется личное владение модулями или слоями системы? Потому что это более безопасно, вот логика:
- Вася отлично знает эту часть и может смело ее менять. Тесты на этот код не нужны, поэтому что Вася и без них знает все зависимости в коде, вносит изменения без проблем
- Весь код в этом модуле написан Васей, а он ставит скобочку после метода, а не переносит ее на следующую строку, пусть в этом модуле такие стандарты живут дальше
- Если что-то в модуле сломалось, то виноват Вася, пусть старается, чтобы всё в его модуле работало. Мы в его модуль не полезем, у нас свои есть
- Вася знает больше про UI, поэтому его модули реализуют UI, а Петя специалист по БД, у него другие модули
- ...
Такой подход влечет сразу целый букет проблем и выводов. Команда не кроссфункциональная, тестов нет, код написан везде по-разному, задержки из-за отсутствия на работе ответственного за модуль программиста, плохая архитектура, куча костылей и технических долгов и т.п. Выбраться в коллективное владение кодом на таких проектах практически невозможно. Обычно команды, которые признают вышеперечисленные проблемы, начинают с коллективного владения кодом на новых проектах.
Проверку на соответствие стандартам лучше всего осуществлять на этапе сборки проекта в автоматическом режиме.
Это не совсем так, на AgileCamp я с многими обсуждал эту тему. Если вы хотите, чтобы стандарты кодирования проверялись автоматом, то надо понимать и риски, которые связаны с борьбой инструментом против людей. Как только вы отдадите проверку стандартов на сторону инструментов, разработки начинают по-другому относиться к коду, а это должна быть 100% их зона ответственности. В нашей компании принято писать код в соответствии со стандартами кодирования. Такой подход намного сильнее, чем ожидание отчета от StyleCop.
40-часовая рабочая неделя
Тут суть не просто в переработках. Есть понятие Eight Hour Burn. Т.е. ты по полной выкладываешься 8 часов в день, но остальное время обязан восстанавливаться, чтобы эффективно сжечь следующие 8 часов.
Благодарности
Это была отличная идея написать книгу про Agile! Я рад, что Борис Вольфсон взялся за это.
Ссылки
Хабр: Бесплатная электронная книга по гибким методологиям разработки
Комментариев нет:
Отправить комментарий