Простота и эффективность использования Git привели к совершенно непредвиденному новому подходу, как создавать программное обеспечение. Линус Торвальдс подумал бы, что использовать Git как инструмент для быстрого избавления от маленьких кусочков кода — сумасшествие, но это именно то, что продвигают сторонники метода Микадо[62] и TCR (Test&&Commit || Revert)[63]. И даже, хотя ключевой стороной Git является его способность очень эффективно управлять ветками, бесчисленные команды почти без исключения ведут trunk-based разработку с помощью Git. Инструмент претерпел экзаптацию[64], то есть эффективно используется способами, которые не предполагали авторы.
Хорошие инструменты выполняют следующие задачи:
• помогают людям достигать своих целей;
• позволяют их достаточно быстро освоить;
• стремятся быть прозрачными для пользователей;
• способны адаптироваться и экзаптироваться;
• доступны по стоимости.
Мы приводим Git в качестве примера хорошего инструмента… на 2019 год. Возможно, вы читаете это уже в будущем, и на дворе другой год. Времена меняются, меняются и инструменты.
Физические инструменты Agile
Пользователи Agile известны тем, что используют маркерные доски, клейкую ленту и наклейки разных размеров (маленькие и размером с флипчарт), чтобы работа была наглядной. Эти простые «ручные орудия» обладают всеми качествами хорошего инструмента:
• Помогают сделать ход работы наглядным и управляемым.
• Интуитивно понятны и не требуют особой подготовки.
• Не требуют значительной когнитивной нагрузки. Их можно легко использовать, сосредоточившись на других задачах.
• Легко экзаптируемы. Ни одно из этих средств не было создано именно для управления ходом разработки ПО.
• Легко адаптируемы под конкретные потребности. Можно использовать клейкую ленту или офисный пластилин, прикреплять картинки или значки, добавлять различные пометки, а еще по-своему использовать различные цвета и значки, чтобы не упустить ни одного нюанса.
• Все они недороги, и их легко приобрести.
Команды, располагающиеся в одном пространстве, могут легко управлять крупным и сложным проектом с помощью лишь этих простых и недорогих физических инструментов. Вы можете транслировать ключевую информацию с помощью листа из флипчарта, закрепив его на стену клейкой лентой. Такое представление обобщает важные тенденции и факты как для членов команды, так и для спонсоров. С помощью таких представлений можно изображать и представлять новые сведения прямо на лету. Гибкость почти не ограничена.
Но ограничения есть у каждого инструмента. Одно из основных ограничений физических инструментов в том, что они не очень действенны для распределенных команд. Только для сотрудников, находящихся в пределах видимости. Еще физические инструменты не сохраняют историю автоматически, поэтому есть только текущее состояние.
А может, автоматизируем?
Проект, в котором впервые применяли экстремальное программирование (Chrysler Comprehensive Compensation System), вели преимущественно с помощью физических инструментов. По мере распространения Agile рос интерес к автоматизированным программным средствам. На это есть вполне разумные основания:
• Программные средства хорошо позволяют осуществлять сбор данных в однородном виде.
• С помощью однородных данных можно легко составлять доклады, графики и схемы, выглядящие профессионально.
• Легко вести историю и хранить данные.
• Можно мгновенно делиться данными, вне зависимости от местонахождения адресата.
• Благодаря средствам вроде электронных таблиц, доступных по сети, можно работать в полностью распределенной команде в режиме реального времени.
Некоторым ребятам, больше привыкшим к вылизанным презентациям и программам, физические инструменты кажутся чем-то отсталым. И поскольку мы работаем в отрасли разработки ПО, для многих из нас автоматизация всего, чего только возможно, — естественное стремление.
Программные средства в студию!
Или… может, не надо? Давайте остановимся и хорошенько подумаем. В программных средствах может отсутствовать часть функций, которые нужны вашей команде. Если у вас есть инструмент, то путь наименьшего сопротивления — это исходить из возможностей инструмента, вне зависимости от того, отвечает ли он потребностям команды.
Команде сперва следует определиться, каким образом она собирается вести работы, затем уже подбирать средства именно под свои потребности.
Работники используют инструменты, а не инструменты — работников.
Никому не хочется зависеть от чужого мнения. Что бы вы ни делали, вам хочется разобраться в том, как нужно работать, прежде чем что-то автоматизировать. Но вопрос не в том, какие инструменты использовать: физические или программные. Вопрос должен стоять так: хорошие инструменты у нас или нет?
Системы управления жизненным циклом приложений
Вскоре после появления Agile были созданы многочисленные программы для управления проектами, которые ведутся с помощью Agile. Существуют самые разные системы управления с жизненным циклом приложений (ALM) на базе Agile, как с открытым исходным кодом, так и в красивой блестящей обертке за приличные деньги. Они позволяют собирать данные, образующиеся в ходе работы, управлять длинными списками функций и еще не выполненных задач, создавать сложные графики, представлять сводки работы команд в совокупности, а еще выполнять некоторые операции с числами.
Автоматизированные системы, которые помогут справиться с подобной работой, возможно, упорядочат эти процессы, для нашего же удобства. Помимо своих основных, системы ALM наделены другими полезными функциями. Большая часть ALM позволяет вести удаленное взаимодействие, отслеживать историю, выполнять некоторые рутинные бухгалтерские операции, а еще их можно гибко настроить под требования пользователя. Можно с помощью графопостроителя создавать профессиональные многоцветные графики на листах огромных форматов, которые можно развешивать как стенгазеты в пространстве, в котором находится команда.
И все же, несмотря на богатый функционал и коммерческий успех, ALM невозможно назвать хорошим инструментом. Эта неудача будет нам хорошим уроком.
Хороший инструмент можно изучить достаточно быстро. ALM, как правило, громоздки и требуют специальной подготовки перед их использованием (давайте-ка вспомним, когда мы в последний раз были на обучении по индексным карточкам). Даже несмотря на обучение, команде приходится отвлекаться на поиск в интернете, чтобы выяснить, как выполнить ту или иную простую задачу. Многие нехотя принимают сложность этих систем, пытаясь вникнуть глубже и во всем разобраться, но в конце концов мирятся с тем, что работа идет медленно и неповоротливо.
Хорошие инструменты стремятся к прозрачности для пользователей. Мы постоянно видим, как члены команды выискивают какую-то ведущую логику в попытке разобраться в программе. Во время работы с карточками с историями они ведут себя словно пьяницы, размахивающие кулаками. Они слоняются по веб-страницам, повсюду вставляя скопированный текст, стараются связать истории между собой или с их родительскими эпиками. Они теряются в историях, задачах и заданиях в попытке выстроить их в слаженную систему. Это бардак. Эти средства требуют слишком много внимания.
Хорошие инструменты способны адаптироваться и экзаптироваться. Хотите добавить поля в виртуальной карточке в ALM? Вам придется найти программиста экспертного уровня, который посвятил (или даже пожертвовал) себя поддержке необходимой программы. Или все закончится тем, что вы отправите запрос на изменение поставщику. Дело пяти секунд при использовании простых физических инструментов оборачивается пятидневной, а может и пятинедельной, задержкой при использовании ALM. Эксперименты с быстрой обратной связью в ходе работ становятся невозможными. И, само собой, если вам вообще не нужны дополнительные поля, кто-то должен обратить изменения и перевыпустить программу в измененной конфигурации. Системы ALM плохо адаптируются.
Хорошие инструменты доступны по стоимости. Лицензия на ALM, которая может стоить несколько тысяч долларов в год, — только начало. Установка и использование этих систем может потребовать значительных дополнительных расходов на подготовку, поддержку и, иногда, настройку под ваши потребности. Текущее обслуживание и администрирование выльются в дополнительные затраты к уже немалым имеющимся.
Хорошие инструменты помогают достигать людям своих целей. ALM редко работает таким же образом, как ваша команда, а режим по умолчанию частенько не согласован с самими методами Agile. Например, многие системы ALM считают, что у каждого из членов команды есть свое рабочее задание, что делает невозможным их использование командами, члены которых работают совместно, перемежая задания между собой.
В некоторых системах ALM даже есть доски позора, которые показывают нагрузку, загруженность и объем выполненных работ (или нехватку их) для каждого участника команды. Вместо того чтобы мотивировать на ударную работу и поощрять коллективную ответственность, как это на самом деле принято в Agile, ALM становится средством пристыдить программиста и выжать из него все соки. Там, где команда раньше собиралась на утренний стендап-митинг (или ежедневный скрам), теперь она собирается, для того чтобы внести поправки в ALM. Система заменила личное взаимодействие автоматизированным отчетом о состоянии пользователя.
Хуже того, системы ALM часто не могут транслировать информацию, в отличие от физических средств. Вам нужно выполнить вход и копаться в данных, чтобы найти нужные сведения. Когда вы находите нужные сведения, они часто идут вместе с кучей ненужных. Иногда два-три графика или изображения, которые вам нужны, могут находиться на разных страницах. Нет повода думать, что ALM никогда не станут хорошим инструментом. Но если вам нужна доска с карточками и нужно использовать ПО, я бы посоветовал какое-нибудь универсальное средство вроде Trello