Какая главная проблема в разработке программного обеспечения (а может и вообще в любой работе)? Когда я задавал вопрос коллегам, получал разные ответы: изменения требований, несоответствия ожиданий, качество кода, взаимодействие с другими командами… суммируя для себя — коммуникация является одной из самых важных проблем.
Во время коммуникации каждый понимает все по-своему, интерпретирует как-то иначе, нежели чем было сказано. Заказчик держит в голове некий образ, который он пытается конвертировать в слова и картинки, разработчик, слыша эти слова, конвертирует их у себя в голове в какой-то свой образ. И в этой цепи может быть много звеньев.
Пытаясь решать эту проблему, люди пишут детальное ТЗ. Но решает ли это проблему? Те же вопросы, как мне видится, задавали Боб Мартин и Мартин Фаулер вместе со своими коллегами, когда писали Agile Manifest в феврале 2001 года. Попробуем разобраться вместе в этом вопросе, да и в самом Agile манифесте.
Зимой 2000 была встреча лидеров так называемого Extreme Programming, они обсуждали методологии разработки и в результате стали предлагать некие Light методологии. Мало кого это заинтересовало (не хочу никого обидеть), скорее всего больше отпускали шуточки на эту тему. Однако несколько аутсайдеров той встречи через год организовали свою. Началось все с того, что Боб Мартин (это он написал известную книжку про качество кода), сделал рассылку на лидеров прошлой встречи — давайте соберемся и поговорим. Собственно ничего конкретного. Они какое-то время препирались по поводу места и времени. В результате собрались 11го феврале 2001, в штате Юта, на горнолыжном курорте. 17 людей из сферы разработки, в том числе Боб Мартин, Мартин Фаулер, и другие. Выпили, Фаулер покатался на лыжах, и после обсуждений на свет появился Agile Manifest.
В принципе, все самое важное можно передать буквально страницей текста, который можно прочитать тут.
Но как и все краткое и скурпулезно обдуманное, понять это просто прочитав, мне лично было не легко. Поэтому рассмотрим в деталях, что же имели в виду те люди, которые подписали манифест аджайл.
На первый взгляд это может показаться призывом выбросить все Jira проекты, bug трекеры, time логгеры и прочие инструменты и все настроенные процессы. Что может быть проще — устно обсуждать с коллегами кто-что делает. Лишь бы все были счастливы. Но это выглядит несколько утопично, не так ли?
Данный принцип говорит о том, что выстраивая процесс разработки чего угодно, важно помнить о том, для чего это делается, для кого и с какой целью. Мало смысла создавать процесс ради самого процесса. Потому что работу в конечном итоге будут делать люди, мы с вами. Что будет, если всю искру, весь интерес в наших глазах заменить на таски в ютреке или баги в джире? Грош цена стройному процессу, обеспечивающему полную безопасность перед кастомером, но не решающему реальные задачи разработки. Бюрократические (формальные) детали могут легко привести к потере людей на проекте. Я склонен думать, что то же самое касается и планирования. Когда в последний раз вы делали планирование, которое в итоге хотя бы процентов на 60-70 оказалось точным?
На мой взгляд, данный принцип манифеста мог бы звучать так:
Что вообще разрабатывает команда? Продукт для заказчика.
Если трактовать как есть, в лоб, я думаю многие согласятся. Но что еще вы тут видите? Лично я тут вижу, что работающий, причем работающий вовремя продукт, важнее идеально написанного кода. Это жестокие и страшные во многом слова, я так то не должен это произносить. Но всю мою карьеру я, учась у разных людей, все больше убеждался в мысли — если выбирать между идеальным с точки зрения кода и архитектуры проектом, и проектом, пусть не очень красивым внутри, но который приносит пользу в мир, я выберу второй. И да, я буду его по мере моих сил и возможностей улучшать.
И тут следует задуматься еще на минутку. А что вообще можно сделать, чтобы эти проблемы возникали реже? Чтобы нам не приходилось выбирать между рефакторингом модуля и разработкой новый фичи?
Обратите внимание на пункт про техническое совершенство. Поддерживая код в хорошем (необходимом) и достаточном качестве, мы гораздо легче переносим изменения требований и, соответственно, изменения в коде.
Все принципы, напомню, это не отрицания. Одно не исключает другого. Это про расставление приоритетов. Все важно — и продукт, и качество кода, и документация. Но что выбрать, когда надо выбирать? Работая в неком балансе между качеством и продуктом, продукт легче поставить в приоритет, не отрицая качества.
В качестве примера из жизни вспоминается работа на банковском проекте для российского заказчика. Работа велась с участием аналитиков и строго по объемному ТЗ. Раз в полгода менеджер ездил в головной офис заказчика и показывал результаты работы. Нетрудно догадаться, что как правило результаты существенно отличались от ожиданий заказчика. Бухгалтер заказчика, впервые увидевший новую систему, и вообще узнавший что она создается, был в состоянии ужаса — ничего похожего на его привычный процесс работы в новой системе не было. Что подводит нас к следующей теме.
С этим высказыванием нужно быть весьма осторожным. И опять же помним, что правая часть высказывания не отрицается. Наоборот, мы говорим, что контракт важен. Просто когда мы взвешиваем условия контракта и сотрудничество, правильные долгосрочные партнерские отношения, то отношения будут важнее. Не отрицая второго. Я заостряю на этом такое внимание потому, что мы живем в реальном мире и нам приходится порой работать с очень разными заказчиками. Есть случаи, когда заказчик в своих корыстных целях может воспользоваться наивностью и за счет контракта выбить себе условия, неприемлемые для разработчиков.
Тем не менее, если говорить о неком абстрактном хорошем заказчикев вакууме, то поддержание долгосрочных отношений, которые приведут к новым проектам, важнее.
Как достичь понимания и соответствия ожиданий в течение всего проекта?
При этом не стоит конечно же забывать и о подтверждении договоренностей для своей же безопасности. Есть кстати (к счастью редко) заказчики, которые вообще отказываются платить после договоренностей.
Каким бы ни был заказчик, активность со стороны разработчика всегда полезна.
Я бы от себя еще добавил, что это вообще в обе стороны должно работать.
Это приводит нас к логичному продолжению — изменениям в работе и планах. Мало кто любит делать изменения, это в природе человека, если вдуматься. Любая система стремится к некой точке равновесия и неизменности. Но именно развитие всегда связано с движением и изменениями.
Наличие плана как такового не отрицается. Наоборот — план важен. Но еще более важно быть готовым его изменить, если в какой то момент мы поняли — этот план больше не работает в текущих условиях.
Пример из практики моих коллег — проект для налоговой инспекции одной из стран СНГ. Гос проект по сути, ТЗ, законодательство, ни о каком аджайле и речи не велось. Но команде пришлось проявить гибкость в тот момент, когда государство в стране заказчика изменило свое налоговое законодательство настолько, что проект не имел бы смысла вообще в том виде, в котором его запланировали. Пришлось изменять ТЗ и переделывать почти готовый проект, чтобы заказчик смог им пользоваться. Иначе — в работе не было бы смысла, ну разве кроме заработка как такового.
Возможно, это не самый показательный пример, так как изменения были спровоцированы внешними факторами. А с другой стороны — заказчик может, опять таки в силу внешних факторов, просто сам придти к необходимости изменений требований. Иначе он не получит конкурентного преимущества.
Это все затрагивает немного больную для меня тему. А что если мы вот делаем проект целый год, а потом через год заказчик говорит — окей, вы молодцы, а сейчас мы положим все это в архив, пользоваться не будем и начнем новый проект. Я довольно болезненно к такому отношусь, у меня был подобный опыт. Но на самом деле — что произошло? Проделанная работа помогла заказчику понять, что выбранный путь неверен. Или неэффективен. Чтобы получить конкурентное преимущество, нужно работать иначе, делать другой проект. И он получил это знание с нашей помощью.
Какие аспекты в нашей работе помогут сгладить эти углы и сделать гибкость не столь пугающей?
При этом мы живем в реальном мире, с реальными людьми, где никакое суждение, это в том числе, не стоит возводить в абсолют. Да, стоит приветствовать изменения, когда они ведут к добавлению ценности конечному продукту. Но важно соблюдать при этом баланс. Если мы будем бесконечно вносить изменения, мы никогда не выпустим продукт в продакшен. Поэтому в какой то момент следует говорить — стоп, мы выпускаем продукт, проверяем все на практике, и начинаем делать версию два, которая и будет содержать эти изменения. Каждый раз уточняя у заказчика — какую ценность он видит в том или ином изменении.
Прочитал недавно фразу в фейсбуке,
Создатели Agile манифеста не предписывают никаких правил, в чем то даже наоборот. Но они поднимают важные в нашей работе вопросы — взаимодействия людей, разработчиков и заказчиков, готовность к изменениям. Эти принципы важны по своей природе. При неоспоримой важности документации, контрактов, процессов и планирования, человеческое взаимодействие, готовность к ценным изменениям и привнесение в мир чего-то полезного — все таки важнее.
Во время коммуникации каждый понимает все по-своему, интерпретирует как-то иначе, нежели чем было сказано. Заказчик держит в голове некий образ, который он пытается конвертировать в слова и картинки, разработчик, слыша эти слова, конвертирует их у себя в голове в какой-то свой образ. И в этой цепи может быть много звеньев.
Пытаясь решать эту проблему, люди пишут детальное ТЗ. Но решает ли это проблему? Те же вопросы, как мне видится, задавали Боб Мартин и Мартин Фаулер вместе со своими коллегами, когда писали Agile Manifest в феврале 2001 года. Попробуем разобраться вместе в этом вопросе, да и в самом Agile манифесте.
История
Зимой 2000 была встреча лидеров так называемого Extreme Programming, они обсуждали методологии разработки и в результате стали предлагать некие Light методологии. Мало кого это заинтересовало (не хочу никого обидеть), скорее всего больше отпускали шуточки на эту тему. Однако несколько аутсайдеров той встречи через год организовали свою. Началось все с того, что Боб Мартин (это он написал известную книжку про качество кода), сделал рассылку на лидеров прошлой встречи — давайте соберемся и поговорим. Собственно ничего конкретного. Они какое-то время препирались по поводу места и времени. В результате собрались 11го феврале 2001, в штате Юта, на горнолыжном курорте. 17 людей из сферы разработки, в том числе Боб Мартин, Мартин Фаулер, и другие. Выпили, Фаулер покатался на лыжах, и после обсуждений на свет появился Agile Manifest.
В принципе, все самое важное можно передать буквально страницей текста, который можно прочитать тут.
Но как и все краткое и скурпулезно обдуманное, понять это просто прочитав, мне лично было не легко. Поэтому рассмотрим в деталях, что же имели в виду те люди, которые подписали манифест аджайл.
Принципы Agile
То есть, не отрицая важности того, что справа,Это очень важный аспект, который надо постоянно держать в голове, читая манифест, да и вообще в работе каждый день. Давайте обсудим основные заявления манифеста.
мы всё-таки больше ценим то, что слева.
Люди и взаимодействие важнее процессов и инструментов
На первый взгляд это может показаться призывом выбросить все Jira проекты, bug трекеры, time логгеры и прочие инструменты и все настроенные процессы. Что может быть проще — устно обсуждать с коллегами кто-что делает. Лишь бы все были счастливы. Но это выглядит несколько утопично, не так ли?Данный принцип говорит о том, что выстраивая процесс разработки чего угодно, важно помнить о том, для чего это делается, для кого и с какой целью. Мало смысла создавать процесс ради самого процесса. Потому что работу в конечном итоге будут делать люди, мы с вами. Что будет, если всю искру, весь интерес в наших глазах заменить на таски в ютреке или баги в джире? Грош цена стройному процессу, обеспечивающему полную безопасность перед кастомером, но не решающему реальные задачи разработки. Бюрократические (формальные) детали могут легко привести к потере людей на проекте. Я склонен думать, что то же самое касается и планирования. Когда в последний раз вы делали планирование, которое в итоге хотя бы процентов на 60-70 оказалось точным?
На мой взгляд, данный принцип манифеста мог бы звучать так:
Процессы для людей, а не люди для процессовКак манифест предлагает нам приблизиться к реализации этого принципа?
- Над проектом должны работать мотивированные профессионалы.
- Непосредственное общение является наиболее практичным и эффективным.
- Самые лучшие требования и архитектурные решения рождаются у самоорганизующихся команд.
- Команда должна постоянно анализировать свою работу и оптимизировать процесс.
Что вообще разрабатывает команда? Продукт для заказчика.
Работающий продукт важнее исчерпывающей документации
Если трактовать как есть, в лоб, я думаю многие согласятся. Но что еще вы тут видите? Лично я тут вижу, что работающий, причем работающий вовремя продукт, важнее идеально написанного кода. Это жестокие и страшные во многом слова, я так то не должен это произносить. Но всю мою карьеру я, учась у разных людей, все больше убеждался в мысли — если выбирать между идеальным с точки зрения кода и архитектуры проектом, и проектом, пусть не очень красивым внутри, но который приносит пользу в мир, я выберу второй. И да, я буду его по мере моих сил и возможностей улучшать.И тут следует задуматься еще на минутку. А что вообще можно сделать, чтобы эти проблемы возникали реже? Чтобы нам не приходилось выбирать между рефакторингом модуля и разработкой новый фичи?
- Работающий продукт следует выпускать как можно чаще.
- Работающий продукт — основной показатель прогресса.
- Постоянное внимание к техническому совершенству и качеству повышает гибкость проекта.
- Простота и минимизация необходимы.
Обратите внимание на пункт про техническое совершенство. Поддерживая код в хорошем (необходимом) и достаточном качестве, мы гораздо легче переносим изменения требований и, соответственно, изменения в коде.
Все принципы, напомню, это не отрицания. Одно не исключает другого. Это про расставление приоритетов. Все важно — и продукт, и качество кода, и документация. Но что выбрать, когда надо выбирать? Работая в неком балансе между качеством и продуктом, продукт легче поставить в приоритет, не отрицая качества.
В качестве примера из жизни вспоминается работа на банковском проекте для российского заказчика. Работа велась с участием аналитиков и строго по объемному ТЗ. Раз в полгода менеджер ездил в головной офис заказчика и показывал результаты работы. Нетрудно догадаться, что как правило результаты существенно отличались от ожиданий заказчика. Бухгалтер заказчика, впервые увидевший новую систему, и вообще узнавший что она создается, был в состоянии ужаса — ничего похожего на его привычный процесс работы в новой системе не было. Что подводит нас к следующей теме.
Сотрудничество с заказчиком важнее согласования условий контракта
С этим высказыванием нужно быть весьма осторожным. И опять же помним, что правая часть высказывания не отрицается. Наоборот, мы говорим, что контракт важен. Просто когда мы взвешиваем условия контракта и сотрудничество, правильные долгосрочные партнерские отношения, то отношения будут важнее. Не отрицая второго. Я заостряю на этом такое внимание потому, что мы живем в реальном мире и нам приходится порой работать с очень разными заказчиками. Есть случаи, когда заказчик в своих корыстных целях может воспользоваться наивностью и за счет контракта выбить себе условия, неприемлемые для разработчиков. Тем не менее, если говорить о неком абстрактном хорошем заказчике
Как достичь понимания и соответствия ожиданий в течение всего проекта?
- На протяжении всего проекта разработчики и представители бизнеса кастомера должны ежедневно работать вместе.
- Непосредственное общение является наиболее практичным и эффективным.
При этом не стоит конечно же забывать и о подтверждении договоренностей для своей же безопасности. Есть кстати (к счастью редко) заказчики, которые вообще отказываются платить после договоренностей.
Каким бы ни был заказчик, активность со стороны разработчика всегда полезна.
Я бы от себя еще добавил, что это вообще в обе стороны должно работать.
Это приводит нас к логичному продолжению — изменениям в работе и планах. Мало кто любит делать изменения, это в природе человека, если вдуматься. Любая система стремится к некой точке равновесия и неизменности. Но именно развитие всегда связано с движением и изменениями.
Готовность к изменениям важнее следованию первоначальному плану
Наличие плана как такового не отрицается. Наоборот — план важен. Но еще более важно быть готовым его изменить, если в какой то момент мы поняли — этот план больше не работает в текущих условиях.Пример из практики моих коллег — проект для налоговой инспекции одной из стран СНГ. Гос проект по сути, ТЗ, законодательство, ни о каком аджайле и речи не велось. Но команде пришлось проявить гибкость в тот момент, когда государство в стране заказчика изменило свое налоговое законодательство настолько, что проект не имел бы смысла вообще в том виде, в котором его запланировали. Пришлось изменять ТЗ и переделывать почти готовый проект, чтобы заказчик смог им пользоваться. Иначе — в работе не было бы смысла, ну разве кроме заработка как такового.
Возможно, это не самый показательный пример, так как изменения были спровоцированы внешними факторами. А с другой стороны — заказчик может, опять таки в силу внешних факторов, просто сам придти к необходимости изменений требований. Иначе он не получит конкурентного преимущества.
Это все затрагивает немного больную для меня тему. А что если мы вот делаем проект целый год, а потом через год заказчик говорит — окей, вы молодцы, а сейчас мы положим все это в архив, пользоваться не будем и начнем новый проект. Я довольно болезненно к такому отношусь, у меня был подобный опыт. Но на самом деле — что произошло? Проделанная работа помогла заказчику понять, что выбранный путь неверен. Или неэффективен. Чтобы получить конкурентное преимущество, нужно работать иначе, делать другой проект. И он получил это знание с нашей помощью.
Какие аспекты в нашей работе помогут сгладить эти углы и сделать гибкость не столь пугающей?
- Регулярная и ранняя поставка ПО.
- Изменения приветствуются даже на поздних стадиях.
- Изменения помогают обеспечить кастомеру конкурентное преимущество.
При этом мы живем в реальном мире, с реальными людьми, где никакое суждение, это в том числе, не стоит возводить в абсолют. Да, стоит приветствовать изменения, когда они ведут к добавлению ценности конечному продукту. Но важно соблюдать при этом баланс. Если мы будем бесконечно вносить изменения, мы никогда не выпустим продукт в продакшен. Поэтому в какой то момент следует говорить — стоп, мы выпускаем продукт, проверяем все на практике, и начинаем делать версию два, которая и будет содержать эти изменения. Каждый раз уточняя у заказчика — какую ценность он видит в том или ином изменении.
Прочитал недавно фразу в фейсбуке,
если вам не стыдно за свой продукт, значит вы вышли на рынок слишком поздноДовольно точно отражает суть сказанного выше. Надо искать некую точку баланса, в которой продукт будет уже достаточно готов к очередному выпуску в плане изменений, и в которой мы еще не стали слишком много усилий тратить на малозначительные изменения.
Вместо подведения итогов
Создатели Agile манифеста не предписывают никаких правил, в чем то даже наоборот. Но они поднимают важные в нашей работе вопросы — взаимодействия людей, разработчиков и заказчиков, готовность к изменениям. Эти принципы важны по своей природе. При неоспоримой важности документации, контрактов, процессов и планирования, человеческое взаимодействие, готовность к ценным изменениям и привнесение в мир чего-то полезного — все таки важнее.
