Роберт Мартин - Чистый Agile. Основы гибкости

И все же, несмотря на богатый функционал и коммерческий успех, ALM невозможно назвать хорошим инструментом. Эта неудача будет нам хорошим уроком.

Хороший инструмент можно изучить достаточно быстро. ALM, как правило, громоздки и требуют специальной подготовки перед их использованием (давайте-ка вспомним, когда мы в последний раз были на обучении по индексным карточкам). Даже несмотря на обучение, команде приходится отвлекаться на поиск в интернете, чтобы выяснить, как выполнить ту или иную простую задачу. Многие нехотя принимают сложность этих систем, пытаясь вникнуть глубже и во всем разобраться, но в конце концов мирятся с тем, что работа идет медленно и неповоротливо.

Хорошие инструменты стремятся к прозрачности для пользователей . Мы постоянно видим, как члены команды выискивают какую-то ведущую логику в попытке разобраться в программе. Во время работы с карточками с историями они ведут себя словно пьяницы, размахивающие кулаками. Они слоняются по веб-страницам, повсюду вставляя скопированный текст, стараются связать истории между собой или с их родительскими эпиками. Они теряются в историях, задачах и заданиях в попытке выстроить их в слаженную систему. Это бардак. Эти средства требуют слишком много внимания.

Хорошие инструменты способны адаптироваться и экзаптироваться. Хотите добавить поля в виртуальной карточке в ALM? Вам придется найти программиста экспертного уровня, который посвятил (или даже пожертвовал) себя поддержке необходимой программы. Или все закончится тем, что вы отправите запрос на изменение поставщику. Дело пяти секунд при использовании простых физических инструментов оборачивается пятидневной, а может и пятинедельной, задержкой при использовании ALM. Эксперименты с быстрой обратной связью в ходе работ становятся невозможными. И, само собой, если вам вообще не нужны дополнительные поля, кто-то должен обратить изменения и перевыпустить программу в измененной конфигурации. Системы ALM плохо адаптируются.

Хорошие инструменты доступны по стоимости. Лицензия на ALM, которая может стоить несколько тысяч долларов в год, — только начало. Установка и использование этих систем может потребовать значительных дополнительных расходов на подготовку, поддержку и, иногда, настройку под ваши потребности. Текущее обслуживание и администрирование выльются в дополнительные затраты к уже немалым имеющимся.

Хорошие инструменты помогают достигать людям своих целей. ALM редко работает таким же образом, как ваша команда, а режим по умолчанию частенько не согласован с самими методами Agile. Например, многие системы ALM считают, что у каждого из членов команды есть свое рабочее задание, что делает невозможным их использование командами, члены которых работают совместно, перемежая задания между собой.

В некоторых системах ALM даже есть доски позора, которые показывают нагрузку, загруженность и объем выполненных работ (или нехватку их) для каждого участника команды. Вместо того чтобы мотивировать на ударную работу и поощрять коллективную ответственность, как это на самом деле принято в Agile, ALM становится средством пристыдить программиста и выжать из него все соки. Там, где команда раньше собиралась на утренний стендап-митинг (или ежедневный скрам), теперь она собирается, для того чтобы внести поправки в ALM. Система заменила личное взаимодействие автоматизированным отчетом о состоянии пользователя.

Хуже того, системы ALM часто не могут транслировать информацию, в отличие от физических средств. Вам нужно выполнить вход и копаться в данных, чтобы найти нужные сведения. Когда вы находите нужные сведения, они часто идут вместе с кучей ненужных. Иногда два-три графика или изображения, которые вам нужны, могут находиться на разных страницах. Нет повода думать, что ALM никогда не станут хорошим инструментом. Но если вам нужна доска с карточками и нужно использовать ПО, я бы посоветовал какое-нибудь универсальное средство вроде Trello [65] Опять же на 2019 год. Времена меняются. . Оно простое, быстрое, дешевое, расширяемое и неплохо выглядит.

Наши способы вести работы постоянно изменяются. Сначала была SCCS, потом RCS, потом CVS, потом Subversion и потом уже Git. В течение многих лет мы видели море изменений в способах управления исходным кодом. Похожую эволюцию мы наблюдали на примере инструментов тестирования, средств развертывания и прочего (не будем перечислять). Вероятно, мы увидим и похожее развитие систем ALM.