Организация бизнес-процессов
«Это все городские проверяющие такие красивые?»
Монтгомери Бернс из м/с «Симпсоны»
После небольшого перерыва возобновляем серию «Организация бизнес-процессов», и в этом году в ее рамках вас ожидает несколько приятных сюрпризов. Сегодня мы продолжаем некогда начатую тему разработки программного обеспечения и рассмотрим некоторые постулаты Кента Бека, Уорда Кеннингема, Марина Фаулера и их детища, известного как «Экстремальное программирование» (далее мы будем также давать аббревиатуру XP, образованную от eXtreme Programming, не путайте с Windows XP). Напомню, что до этого, в прошлых материалах серии, мы достаточно подробно рассмотрели набор рекомендаций Microsoft Solutions Framework (MSF) и при этом указали, что это не единственный вариант из возможных и используемых в реальности. Об экстремальном программировании начали широко говорить в начале 00-х. По существу, это одна из наиболее известных гибких методологий разработки программного обеспечения, причем достаточно внятно изложенная и разложенная, как говорится, по полочкам. В одной из книг Бека приводится очень иллюстративное сравнение, а именно, разработка ПО похожа на вождение автомобиля, при котором нельзя просто указать направление и ничего не делать, нужно все время держаться за руль. Принципы, лежащие в основе экстремального программирования, отличаются от MSF. При этом определимся сразу, XP мы выделили из множества всего того, что скрывается под модным словом Agile, подразумевающем не что иное, как семейство гибких процессов разработки. Впрочем, для тех, кто не очень знаком с этим термином, скажем так: семейство подразумевает множество вариантов, при этом в 2001 году был разработан и принят манифест Agile Manifesto, в котором задекларированы ключевые ценности, на базе которых после сформировались более детализированные и технические принципы гибкой разработки (их двенадцать). Если вас интересует подробная информация по манифесту, рекомендую обратиться к Wiki, хотя основные постулаты мы можем предложить вашему вниманию и в рамках данного материала.
Итак… «Манифест…
Разрабатывая программное обеспечение и помогая другим делать это, мы стараемся найти наилучшие подходы к разработке. В процессе этой работы мы пришли к тому, чтобы ценить:
. личности и их взаимодействия важнее, чем процессы и инструменты,
. работающее программное обеспечение важнее, чем полная документация,
. сотрудничество с заказчиком важнее, чем контрактные обязательства,
. реакция на изменения важнее, чем следование плану.
Понятия справа важны, но мы больше ценим понятия слева».
Выглядит красиво, что же дальше?
«Принципы, которые разъясняет Agile Manifesto:
1. Удовлетворение клиента за счет ранней и бесперебойной поставки ценного ПО.
2. Приветствие изменения требований, даже в конце разработки. Это может повысить конкурентоспособность полученного продукта.
3. Частая поставка рабочего ПО (каждый месяц или неделю или еще чаще).
4. Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта.
5. Проекты должны строиться вокруг мотивированных личностей, которые обеспечены нужными условиями работы, поддержкой и доверием.
6. Рекомендуемый метод передачи информации — это личный разговор (лицом к лицу).
7. Работающее ПО — лучший измеритель прогресса.
8. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.
9. Постоянное внимание на улучшение технического мастерства и удобный дизайн.
10. Простота — искусство НЕ делать лишней работы.
11. Лучшие архитектура, требования и дизайн получаются у самоорганизованной команды.
12. Постоянная (частая) адаптация (улучшение эффективности работы) к изменяющимся обстоятельствам».
Лично я очень осторожно отношусь к манифестам, декларациям, банальностям с серьезным лицом и имитацией деятельности, а также сектам и тому подобному. Кстати, познакомившись поближе с Agile-сообществами, вы можете найти очень много графоманства, объяснения тривиальных истин. Особенно прельщают статьи, начинающиеся с чего-то типа: «Вам нравится разрабатывать ПО, которое никому не нужно? Вы любите участвовать в проектах, которые вам изначально не интересны? Вам нравится работать в командах, где вы чувствуете себя одиночкой?...» После чего так и хочется добавить: «Тогда идите в наш храм! Аллилуйя!».
Хотя встречаются и зерна.
Именно таким можно назвать экстремальное программирование. Между тем, книги того же Бека больше напоминают творения Дейла Карнеги, Михаила Веллера и тому подобное. То есть это больше рассуждения на тему, при этом каждый читатель невольно начинает становиться ведомым, восклицая: «Какая правда! Это же все про меня!». То есть, кто бы что ни говорил про Майкрософт, но их подход в объяснении несколько лучше.
Вместе с тем, экстремальное программирование — это набор здравых концепций-приемов, коих в классическом представлении двенадцать, и все разбито на четыре группы:
1. Короткий цикл обратной связи (Fine scale feedback)
. Разработка через тестирование (Test driven development).
. Игра в планирование (Planning game).
. Заказчик всегда рядом (Whole team, Onsite customer).
. Парное программирование (Pair programming).
2. Непрерывный, а не пакетный процесс
. Непрерывная интеграция (Continuous Integration).
. Рефакторинг (Design Improvement, Refactor).
. Частые небольшие релизы (Small Releases).
3. Понимание, разделяемое всеми
. Простота (Simple design).
. Метафора системы (System metaphor).
. Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership).
. Стандарт кодирования (Coding standard or Coding conventions).
4. Социальная защищенность программиста (Programmer welfare)
. 40-часовая рабочая неделя (Sustainable pace, Forty hour week).
Вообще, большинство Agile-моделей основаны на коротких итерациях (в некоторых из них такие итерации называют спринтами), частых обновлениях, близком общении с заказчиками и так далее. В принципе, в манифесте и его расшифровке все отражено.
Отдельно стоит объяснить некоторые понятия. Например, разработка через тестирование подразумевает достаточно уникальную технику программирования, а именно, модульные тесты для программы или ее нового модуля пишутся до написания самой программы или этого нового модуля. Непрерывная интеграция — это не что иное, как частые, например ежедневные, сборки проекта.
Отдельно стоит сказать о ноу-хау, присущем именно экстремальному программированию, а именно, организации командной работы в рамках парного программирования. Этот вариант подразумевает, что за одним компьютером сидят два программиста, один из которых непосредственно пишет код, а второй рассматривает написанное более глобально и при этом проверяет действия первого. Через некоторое время они меняются ролями. При этом пары постоянно переключаются на решения различных задач проекта. То есть меняются, также периодически изменяются и их составы. Смысл такой новации достаточно прост. Во-первых, как утверждают авторы методологии, в паре программисты работают более организованно и тратят меньше времени на перерывы. Во-вторых, в паре они дают более качественный код. В-третьих, между ними происходит обмен опытом, потому как каждый человек знает то, чего не знают другие. В-четвертых, переключения между различными участками программы каждому дают представление о продукте в целом. В результате каждый программист чувствует на себе ответственность за всю программу, а не за какой-то ее небольшой фрагмент. В остальном все понятно. Отдельно стоит отметить, что также существует экстремальное управление проектами и экстремальное управление качеством.
Интересна в данном случае идея именно парного программирования, так, как она представлена. Конечно, есть много «но», и данный вариант разительно отличается от стандартных моделей, например, той же Team Model от Microsoft, где каждый отвечает за свой участок. При этом у Microsoft тоже есть «своя заморочка» — коллектив там рассматривается как группа равноправных сотрудников, то есть фактически труды Маркса, и при этом работа каждого сотрудника зависит от работы другого. Обратите внимание, что в рамках экстремального программирования такой зависимости явно не присутствует, и тут, скорее, больше применим закон «незаменимых нет», а главным правилом является «проект не должен останавливаться». При этом главным в каркасе, а это не готовая к работе структура, Team Model от Microsoft является слово «коллектив», в XP — «продукт». И после только что прочитанного просмотрите заново манифест, вернее, вчитайтесь внимательно, и поймете, что основной расходный материал, которого не жалко — люди, работающие над проектом. Этим грешат очень многие Agile-модели — гибкие внешне и достаточно жесткие изнутри.
Во-вторых, не совсем понятен пункт тесного общения с заказчиком. В некоторых ситуациях это может играть только в минус. Мы обсуждали этот вариант, а именно, есть заказчики, такой их тип, которые, вмешавшись в разработку, все время меняют и модифицируют первоначальный план, вносят коррективы. Не сказать, что это ведет к сильному улучшению продукта, а вот время разработки растягивается значительно. К тому же есть угроза того, что продукт вообще не будет доведен до конца.
В общем, да поможет Иннос Agile-моделям, а мы перейдем к реальным примерам из жизни, напомню, что вам на обдумывание даются реальные ситуации.
Стартапы…
Создатель Gmail и автор прототипа оригинального движка GoogleAdSense Пол Бакхайт (Paul Buchheit) буквально недавно занялся собственным стартапом — компанией FriendFeed (http://friendfeed.com — один из новых проектов в области социальных сетей), и в своем блоге (http://paulbuchheit.blogspot.com/) поместил несколько интересных заметок. Нужно сказать, что пишет он довольно ярко и импульсивно. Например, хождение на неинтересную работу с 9 до 6 он сравнил по уровню истощения с постоянным сидением перед телевизором. Основная концепция высказываний: «Зачем жертвовать существенной частью своей жизни просто для того, чтобы заработать сколько-то денег? У некоторых нет другого выхода, но те, кому повезло с мозгами и образованием, могут найти вариант получше… Существуют причины, благодаря которым структура и системная организация крупных компаний приводит к тому, что работа обессмысливается и становится неинтересной».
В принципе, прочитать вы можете все сами на соответствующем блоге, а подумать предлагается вот над чем: какие реальные мотивации у Пола Бакхайта к созданию FriendFeed и работе над ним?
Как разбогател Красс?
Тем, кто знает историю Древнего Рима, наверняка известен такой человек, как Красс, на первых этапах, как бы это сказали современники, спонсировавший Гая Юлия Цезаря для того, чтобы самому попасть на вершину власти. Интересен один из методов, благодаря которому Красс получил часть своего богатства. Он организовал… собственную городскую пожарную службу, прототип ныне существующих. Хотя нужна она Крассу была тогда для другого. Дома в Древнем Риме были в основной своей массе деревянными лачугами. Когда один из них загорался, на место пожара приезжал Красс и… начинал торговаться с владельцем о выкупе этого дома. И только взяв строение за бесценок, Красс принимался за тушение. Причем зачастую он покупал и соседние дома, поскольку они также могли сгореть. Таким образом, Красс стал владельцем большой части недвижимости в Риме. Подумайте и опишите, какие программы и разработчики ведут себя похожим образом? Причем или осознанно, или нет. Например, новая версия какой- нибудь программы требует новую разновидность ОС и так далее.
Кристофер, christopher@tut.by
Монтгомери Бернс из м/с «Симпсоны»
После небольшого перерыва возобновляем серию «Организация бизнес-процессов», и в этом году в ее рамках вас ожидает несколько приятных сюрпризов. Сегодня мы продолжаем некогда начатую тему разработки программного обеспечения и рассмотрим некоторые постулаты Кента Бека, Уорда Кеннингема, Марина Фаулера и их детища, известного как «Экстремальное программирование» (далее мы будем также давать аббревиатуру XP, образованную от eXtreme Programming, не путайте с Windows XP). Напомню, что до этого, в прошлых материалах серии, мы достаточно подробно рассмотрели набор рекомендаций Microsoft Solutions Framework (MSF) и при этом указали, что это не единственный вариант из возможных и используемых в реальности. Об экстремальном программировании начали широко говорить в начале 00-х. По существу, это одна из наиболее известных гибких методологий разработки программного обеспечения, причем достаточно внятно изложенная и разложенная, как говорится, по полочкам. В одной из книг Бека приводится очень иллюстративное сравнение, а именно, разработка ПО похожа на вождение автомобиля, при котором нельзя просто указать направление и ничего не делать, нужно все время держаться за руль. Принципы, лежащие в основе экстремального программирования, отличаются от MSF. При этом определимся сразу, XP мы выделили из множества всего того, что скрывается под модным словом Agile, подразумевающем не что иное, как семейство гибких процессов разработки. Впрочем, для тех, кто не очень знаком с этим термином, скажем так: семейство подразумевает множество вариантов, при этом в 2001 году был разработан и принят манифест Agile Manifesto, в котором задекларированы ключевые ценности, на базе которых после сформировались более детализированные и технические принципы гибкой разработки (их двенадцать). Если вас интересует подробная информация по манифесту, рекомендую обратиться к Wiki, хотя основные постулаты мы можем предложить вашему вниманию и в рамках данного материала.
Итак… «Манифест…
Разрабатывая программное обеспечение и помогая другим делать это, мы стараемся найти наилучшие подходы к разработке. В процессе этой работы мы пришли к тому, чтобы ценить:
. личности и их взаимодействия важнее, чем процессы и инструменты,
. работающее программное обеспечение важнее, чем полная документация,
. сотрудничество с заказчиком важнее, чем контрактные обязательства,
. реакция на изменения важнее, чем следование плану.
Понятия справа важны, но мы больше ценим понятия слева».
Выглядит красиво, что же дальше?
«Принципы, которые разъясняет Agile Manifesto:
1. Удовлетворение клиента за счет ранней и бесперебойной поставки ценного ПО.
2. Приветствие изменения требований, даже в конце разработки. Это может повысить конкурентоспособность полученного продукта.
3. Частая поставка рабочего ПО (каждый месяц или неделю или еще чаще).
4. Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта.
5. Проекты должны строиться вокруг мотивированных личностей, которые обеспечены нужными условиями работы, поддержкой и доверием.
6. Рекомендуемый метод передачи информации — это личный разговор (лицом к лицу).
7. Работающее ПО — лучший измеритель прогресса.
8. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.
9. Постоянное внимание на улучшение технического мастерства и удобный дизайн.
10. Простота — искусство НЕ делать лишней работы.
11. Лучшие архитектура, требования и дизайн получаются у самоорганизованной команды.
12. Постоянная (частая) адаптация (улучшение эффективности работы) к изменяющимся обстоятельствам».
Лично я очень осторожно отношусь к манифестам, декларациям, банальностям с серьезным лицом и имитацией деятельности, а также сектам и тому подобному. Кстати, познакомившись поближе с Agile-сообществами, вы можете найти очень много графоманства, объяснения тривиальных истин. Особенно прельщают статьи, начинающиеся с чего-то типа: «Вам нравится разрабатывать ПО, которое никому не нужно? Вы любите участвовать в проектах, которые вам изначально не интересны? Вам нравится работать в командах, где вы чувствуете себя одиночкой?...» После чего так и хочется добавить: «Тогда идите в наш храм! Аллилуйя!».
Хотя встречаются и зерна.
Именно таким можно назвать экстремальное программирование. Между тем, книги того же Бека больше напоминают творения Дейла Карнеги, Михаила Веллера и тому подобное. То есть это больше рассуждения на тему, при этом каждый читатель невольно начинает становиться ведомым, восклицая: «Какая правда! Это же все про меня!». То есть, кто бы что ни говорил про Майкрософт, но их подход в объяснении несколько лучше.
Вместе с тем, экстремальное программирование — это набор здравых концепций-приемов, коих в классическом представлении двенадцать, и все разбито на четыре группы:
1. Короткий цикл обратной связи (Fine scale feedback)
. Разработка через тестирование (Test driven development).
. Игра в планирование (Planning game).
. Заказчик всегда рядом (Whole team, Onsite customer).
. Парное программирование (Pair programming).
2. Непрерывный, а не пакетный процесс
. Непрерывная интеграция (Continuous Integration).
. Рефакторинг (Design Improvement, Refactor).
. Частые небольшие релизы (Small Releases).
3. Понимание, разделяемое всеми
. Простота (Simple design).
. Метафора системы (System metaphor).
. Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership).
. Стандарт кодирования (Coding standard or Coding conventions).
4. Социальная защищенность программиста (Programmer welfare)
. 40-часовая рабочая неделя (Sustainable pace, Forty hour week).
Вообще, большинство Agile-моделей основаны на коротких итерациях (в некоторых из них такие итерации называют спринтами), частых обновлениях, близком общении с заказчиками и так далее. В принципе, в манифесте и его расшифровке все отражено.
Отдельно стоит объяснить некоторые понятия. Например, разработка через тестирование подразумевает достаточно уникальную технику программирования, а именно, модульные тесты для программы или ее нового модуля пишутся до написания самой программы или этого нового модуля. Непрерывная интеграция — это не что иное, как частые, например ежедневные, сборки проекта.
Отдельно стоит сказать о ноу-хау, присущем именно экстремальному программированию, а именно, организации командной работы в рамках парного программирования. Этот вариант подразумевает, что за одним компьютером сидят два программиста, один из которых непосредственно пишет код, а второй рассматривает написанное более глобально и при этом проверяет действия первого. Через некоторое время они меняются ролями. При этом пары постоянно переключаются на решения различных задач проекта. То есть меняются, также периодически изменяются и их составы. Смысл такой новации достаточно прост. Во-первых, как утверждают авторы методологии, в паре программисты работают более организованно и тратят меньше времени на перерывы. Во-вторых, в паре они дают более качественный код. В-третьих, между ними происходит обмен опытом, потому как каждый человек знает то, чего не знают другие. В-четвертых, переключения между различными участками программы каждому дают представление о продукте в целом. В результате каждый программист чувствует на себе ответственность за всю программу, а не за какой-то ее небольшой фрагмент. В остальном все понятно. Отдельно стоит отметить, что также существует экстремальное управление проектами и экстремальное управление качеством.
Интересна в данном случае идея именно парного программирования, так, как она представлена. Конечно, есть много «но», и данный вариант разительно отличается от стандартных моделей, например, той же Team Model от Microsoft, где каждый отвечает за свой участок. При этом у Microsoft тоже есть «своя заморочка» — коллектив там рассматривается как группа равноправных сотрудников, то есть фактически труды Маркса, и при этом работа каждого сотрудника зависит от работы другого. Обратите внимание, что в рамках экстремального программирования такой зависимости явно не присутствует, и тут, скорее, больше применим закон «незаменимых нет», а главным правилом является «проект не должен останавливаться». При этом главным в каркасе, а это не готовая к работе структура, Team Model от Microsoft является слово «коллектив», в XP — «продукт». И после только что прочитанного просмотрите заново манифест, вернее, вчитайтесь внимательно, и поймете, что основной расходный материал, которого не жалко — люди, работающие над проектом. Этим грешат очень многие Agile-модели — гибкие внешне и достаточно жесткие изнутри.
Во-вторых, не совсем понятен пункт тесного общения с заказчиком. В некоторых ситуациях это может играть только в минус. Мы обсуждали этот вариант, а именно, есть заказчики, такой их тип, которые, вмешавшись в разработку, все время меняют и модифицируют первоначальный план, вносят коррективы. Не сказать, что это ведет к сильному улучшению продукта, а вот время разработки растягивается значительно. К тому же есть угроза того, что продукт вообще не будет доведен до конца.
В общем, да поможет Иннос Agile-моделям, а мы перейдем к реальным примерам из жизни, напомню, что вам на обдумывание даются реальные ситуации.
Стартапы…
Создатель Gmail и автор прототипа оригинального движка GoogleAdSense Пол Бакхайт (Paul Buchheit) буквально недавно занялся собственным стартапом — компанией FriendFeed (http://friendfeed.com — один из новых проектов в области социальных сетей), и в своем блоге (http://paulbuchheit.blogspot.com/) поместил несколько интересных заметок. Нужно сказать, что пишет он довольно ярко и импульсивно. Например, хождение на неинтересную работу с 9 до 6 он сравнил по уровню истощения с постоянным сидением перед телевизором. Основная концепция высказываний: «Зачем жертвовать существенной частью своей жизни просто для того, чтобы заработать сколько-то денег? У некоторых нет другого выхода, но те, кому повезло с мозгами и образованием, могут найти вариант получше… Существуют причины, благодаря которым структура и системная организация крупных компаний приводит к тому, что работа обессмысливается и становится неинтересной».
В принципе, прочитать вы можете все сами на соответствующем блоге, а подумать предлагается вот над чем: какие реальные мотивации у Пола Бакхайта к созданию FriendFeed и работе над ним?
Как разбогател Красс?
Тем, кто знает историю Древнего Рима, наверняка известен такой человек, как Красс, на первых этапах, как бы это сказали современники, спонсировавший Гая Юлия Цезаря для того, чтобы самому попасть на вершину власти. Интересен один из методов, благодаря которому Красс получил часть своего богатства. Он организовал… собственную городскую пожарную службу, прототип ныне существующих. Хотя нужна она Крассу была тогда для другого. Дома в Древнем Риме были в основной своей массе деревянными лачугами. Когда один из них загорался, на место пожара приезжал Красс и… начинал торговаться с владельцем о выкупе этого дома. И только взяв строение за бесценок, Красс принимался за тушение. Причем зачастую он покупал и соседние дома, поскольку они также могли сгореть. Таким образом, Красс стал владельцем большой части недвижимости в Риме. Подумайте и опишите, какие программы и разработчики ведут себя похожим образом? Причем или осознанно, или нет. Например, новая версия какой- нибудь программы требует новую разновидность ОС и так далее.
Кристофер, christopher@tut.by
Компьютерная газета. Статья была опубликована в номере 20 за 2010 год в рубрике технологии
