Создаем IT-продукты на заказ

За 5 лет мы создали продукты с топовыми e-commerce компаниями, ритейлом, банками и другими бизнесами по всему миру.

Специализируемся на SaaS-решениях на архитектуре микросервисов, делаем аналитику IT-проекта перед стартом.

Посмотрите, что говорят о нас клиенты и как комфортно мы стартуем проекты.

Для обсуждения проекта пишите на ceo@byndyusoft.com или звоните +7 (904) 305 5263

суббота, 4 февраля 2012 г.

Книга «Гибкие методологии разработки» от Бориса Вольфсона

Борис Вольфсон недавно выпустил в релиз бесплатную электронную книгу про 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! Я рад, что Борис Вольфсон взялся за это.


Ссылки

Хабр: Бесплатная электронная книга по гибким методологиям разработки

Комментариев нет:

Отправить комментарий

Создаем IT-продукты на заказ

За 5 лет мы создали продукты с топовыми e-commerce компаниями, ритейлом, банками и другими бизнесами по всему миру.

Специализируемся на SaaS-решениях на архитектуре микросервисов, делаем аналитику IT-проекта перед стартом.

Посмотрите, что говорят о нас клиенты и как комфортно мы стартуем проекты.

Для обсуждения проекта пишите на ceo@byndyusoft.com или звоните +7 (904) 305 5263