Для тех везунчиков, которые пока не имели дела с Jira (если тут такие есть), сообщаю: Jira это инструмент для управления проектами, и на первый взгляд всё в этой системе выглядит весьма солидно и пристойно.
Но неприятности начинаются с первых же минут работы. На днях я попытался сотворить элементарную вещь открыть задачу и разместить её на доске проекта. Я провозился минут десять, но сделать ничего не смог, пришлось обращаться за помощью к коллеге. В этой истории всё правда.
Опыт показывает, что проблемы с доской задач в Jira возникают не только у меня. Jira настолько сложная система, что некоторые компании нанимают специальных людей, единственной обязанностью которых является управление этой системой. Другие вообще отдают управление системой Jira на откуп сторонним фирмам:
Но вот что примечательно: Jira преподносит себя как "рабочий инструмент номер один для гибких команд". Гибких? Хм-мм... Если для управления Jira нужен особый человек или даже целая аутсорсинговая компания, о какой гибкости можно говорить?
Давайте разберёмся, что вообще означает термин "гибкий" (Agile) и почему про него все сегодня говорят?
Последовательная разработка
Сегодня только и разговоров, что про методику Agile, как раньше про методику Waterfall. Впервые каскадная методика Waterfall была описана Уинстоном Ройсом в статье, опубликованной в 1970 году. Хотя термин Waterfall (каскад) не был употреблён в статье ни разу, описание метода напомнило многим каскадную схему:
Уинстон охарактеризовал такую модель как несовершенную, и разработанные им конечная модель и видение довольно сильно отличались от исходного варианта, но именно эта концепция послужила основой так называемой методики Waterfall (каскадной).
Основная идея методики: любое планирование процессов разработки программного обеспечения должно осуществляться заранее, после чего должны выполняться последовательные шаги по созданию и поставке программного обеспечения. Данная концепция отлично вписывается в старые идеи научных методов управления, заложенные Фредериком Уинслоу Тейлором ещё в 1911 году. Если опустить детали, его идея состоит в следующем: организацию работ нельзя доверять исполнителям, нужна отдельная группа людей группа организаторов процесса, которая разработает последовательность действий, после чего безукоснительное выполнение таких действий поручается исполнителям.
Единственной проблемой при применении такого подхода к разработке программного обеспечения является его малая эффективность как в прошлом, так и сейчас эта методика постоянно даёт сбои.
Встреча в Сноубэрд
Причина, по которой модель Waterfall оказалась малоэффективной, кроется в том, что её можно применять только в случае, если требования к разработке будут оставаться неизменными. Если вы хоть раз принимали участие в программном проекте, то наверняка знаете, что единственное, в чём абсолютно уверены программисты, так это в том, что требования в любом случае поменяются.
Это хорошо понимала группа разработчиков, собравшихся на горнолыжном курорте Сноубэрд в США в 2001 году. Они согласились с тем, что при изменении требований процесс разработки пойдет насмарку, а, так как препятствовать изменению требований невозможно, любая используемая методика управления процессом изначально обречена на провал. Так как же быть? Выход подсказал Александр Великий, разрубивший некогда Гордиев узел.
Выход был предложен нужно создать другой способ разработки программного обеспечения, который не будет зависеть от изменяющихся требований, но будет подстраиваться под изменения.
Изменение требований на поздних этапах является конкурентным преимуществом
-Мэри Поппендик
Группа Сноубэрд выработала определённые ценности и принципы, получившие известность как Манифест гибкой разработки программного обеспечения.
Основные положения манифеста:
-
Люди и взаимодействие важнее процессов и инструментов.
-
Работающий продукт важнее исчерпывающей документации.
-
Сотрудничество с заказчиком важнее согласования условий контракта.
-
Готовность к изменениям важнее следования первоначальному плану.
В Манифесте ничего не говорится о том, что слова справа имеют меньшее значение, а слова слева большее. Такой образ мыслей был вдохновлён моделью Бережливого производства, основным принципом которой было постоянное стремление предприятия к устранению любых видов потерь. Всё, что не добавляет ценность для потребителя, считается потерями. Зачастую слова справа могут быть связаны именно с потерями.
Что произошло?
Если первым (основным) принципом манифеста является "Люди и взаимодействие важнее процессов и инструментов", то почему все гибкие команды, в которых мне (или вам) приходилось работать, так высоко ценят процессы и инструменты? И тут я опять поминаю недобрым словом Jira. Не дай бог составить задачу вразрез с требованиями Jira, не дай бог добавить хоть одну строку кода без разрешения Jira...
Корень зла, согласно прагматическому замечанию Дэйва Томаса, кроется в том, что слово agile прилагательное, превратилось в Agile (собственное) существительное. Существительные продаются лучше, чем прилагательные, и даже возник "Промышленный комплекс Agile", приторговывающий маркой "Agile".
Прошу понять меня правильно. Я не вижу ничего плохого в том, что люди монетизируют свои знания. Проблема в том, что большинство таких agile-экспертов навязывают нам определённый процесс (как универсальное решение).
Если идея гибкости возникла в результате признания того факта, что мы не можем предвидеть, как именно могут измениться требования, то единого решения (процесса), которое подошло бы для всех возможных сред, не может быть просто по определению. "Agile-эксперты" навязывают нам определённый процесс, и такое состояние Мартин Фаулер называет неприкрытой пародией на "гибкость".
Как же так, вообще без процесса?
Но нужен же какой-то процесс, разве нет? Нужен, но какой? Да очень простой использовать всё, что работает! Но как узнать, будет ли он работать? Тут следует применить эвристический подход.
Соберите группу надёжных людей, хорошо срабатывающихся в команде, и пусть они сами решат, какой процесс использовать. Затем выполните работу до какого-то этапа и подумайте, что можно улучшить. Повторите цикл.
Инструменты
А что с инструментами? Да то же самое, что и с процессом используйте всё, что работает. Или, если говорить точнее, используйте любой инструмент, который лучше всего подходит для процесса. Но будьте осторожны. Поскольку ваш процесс, скорее всего, изменится, гибкость такого инструмента должна быть достаточно высока, чтобы подстроиться под такие изменения. Также не следует делать ставку на какой-либо конкретный инструмент, ведь рано или поздно придётся переключиться на другой инструмент, лучше подходящий для (изменённого) процесса.
Инструмент, подходящий под это описание и имеющийся в каждом офисе, уже имеется!
Вот этот инструмент лекционная доска, несколько стикеров / каталожных карточек и пара-тройка маркеров. И это всё, что нужно. Инструмент просто отличный, так как каждый хорошо знает, как им пользоваться, и он максимально гибок. Если потребуется цифровой инструмент (для удалённой работы), я бы остановился на более универсальном инструменте достаточно гибком, но обязательно специализированном. Причём вы должны быть уверены, что такой инструмент подходит для вашего процесса.
Что не так с Jira?
Если не вдаваться в детали, Jira не нравится мне тем, что она навязывает пользователю определённый процесс. Но этим дело не ограничивается. Я даже был свидетелем того, как команды разработчиков были вынуждены подстраивать свои процессы под Jira, что является грубым нарушением принципа "Люди и взаимодействие важнее процессов и инструментов".
Неприязнь к Jira у меня накопилась потому, что именно от общения с этим инструментом у меня больше всего разбаливается голова, однако не лучше обстоят дела с другими специализированными инструментами управления программным обеспечением. Если конкретный используемый вами инструмент не подходит (в каком-то смысле) к вашему процессу, как долго вы будете пытаться побороть инструмент, прежде чем плюнуть и настроить процесс под требования инструмента?
Если Jira действительно эффективно сопровождает процесс и помогает достичь гибкости в работе, отлично пользуйтесь системой в своё удовольствие. Но заклинаю вас не доверяйтесь Jira только по той причине, что какой-то эксперт по методике Agile рассказал, что Jira это хорошо и что на этой системе работают гибкие команды.
Между прочим, Atlassian (компания-разработчик Jira) постоянно ищет себе инженеров по различным направлениям, в числе прочих нужны Fullstack-разработчики и Java-разработчики. Если одна из ваших целей релоцироваться в компанию с мировым именем, то приходите учиться, прокачаем ваши скилы и поможем выгодно представить их в резюме.
Узнайте, как прокачаться в других специальностях или освоить их с нуля:
Другие профессии и курсыПРОФЕССИИ
КУРС
