Jira Руководство Пользователя
When you subscribe to gadgets from another application, people will be able to use all those gadgets on their dashboards or pages in your application. The gadgets are those provided by the other application or via plugins installed into that application. They do not include external gadgets that the other application has added to its directory.
- Планируйте и отслеживайте agile-проекты и разработку ПО с помощью Jira. За пользователя.
- Confluence руководство пользователя на русском. Про работу с Jira и заморозку версий.
Подписывайтесь только на те приложения, которым вы доверяете! Гаджеты могут внедрить вредоносный код на Ваши страницы. You can subscribe to any Atlassian application that publishes its gadgets for other applications to find.
Кстати, на подходе jira 6. Баги на которые жаловались 1-2 пользователя, к сожалению.
Базовый URL приложения выглядит примерно так: http://example.com/jira.
Jira Руководство Пользователя
Слаженная работа — ключ к хорошему результату! После моих предыдущих статей о том, а также нескольких увольнений адских менеджеров, мне стали поступать просьбы написать о том, как именно надо управлять разработкой. Как надо — у всех свои рецепты, но как я это делаю расскажу ниже. Как и в сексе, в способе планирования у всех вкусы разные (наверное). Я предпочитаю итеративный Agile Scrum, длительность итерации классическая, двухнедельная.
Из инструментов долгое время пользовался trac’ом (очень хорошо доработанным и настроенным), затем был вынужден работать с такими зомби, как Редмайн или Ассембла. Наконец нашлось время, силы и энергия перейти на и это было прекрасно.
Поэтому я расскажу о связке скрам + джира в нашей небольшой команде. Расскажу кратко, времени на написание главы из книги нет; тут будет чисто некоторая практика, которую я нашел оптимальной для себя и для управления командой в 10-20 человек. Agile Scrum в команде Ретроспектива Собственно, тут ничего нового нет и не придумано. Раз в две недели у нас есть день на то, чтобы сделать ретроспективу, на которой мы все по очереди рассказываем о том, что сделано, какие возникли проблемы по ходу разработки и что порадовало, о достижениях прошедшей итерации. Тут же попутно выписываются проблемы и задачи на планирование, но внимание на них не заостряется, они будут обсуждаться позже. Мы пока что не устраиваем больших демонстраций с артом и прочим (заказчик обычно не присутствует, так что смысла особого на текущем этапе нет). Для чего нужна ретроспектива: чтобы все были в курсе о том, что сделано в проекте по факту, не по задачам, закрытым в Джире, могли задать вопросы, уточнить те или иные моменты.
Jira Руководство Пользователя На Русском
Вербально можно передать гораздо больше и оперативнее, чем при помощи трекера. Таким образом, все видят прогресс (если он есть). Если же возникнут проблемы, сложности, то они тоже будут выявлены и о них будет знать вся команда, иметь в виду и может быть коллективно будет предложено наилучшее решение. После ретроспективы, которая занимает от часа до двух, перерыв 10-15 минут. Затем начинается планирование. Планирование Основной инструмент на планировании — бэклог, составленный ранее.
Если кто-то не знает, то в бэклог включаются все основные задачи верхнего уровня. В идеале, он составляется сперва заказчиком, когда он описывает что хочет видеть в проекте. Далее он детализируется продюсером или другим ответственным человеком, или командой на планировании. У нас он достаточно детализированный, на текущий момент в нем 95 задач, большая часть из которых высокоуровневые фичи. Высокоуровневые фичи — это те, которые потребуется еще раскрывать, делить на подзадачи (которых может быть сотни), каждую из них описывать и так далее. То есть эти 95 задач могут превратиться и в 950, и в 9500. Например, на текущий момент со времени написания статьи, количество фич у нас выросло примерно до тысячи.
Фичи добавляются в бэклог и по мере разработки или обсуждений (так же, как и баги). На планировании берется фича и оценивается: кто лучше ее сделает; кто в ней задействован и сколько времени займет ее реализация. Мы оцениваем время не в story points, а пока что в идеальных часах с последующим переходом на поинты (попугаи), но по некоторым внутренним причинам сейчас для нас лучше часы. Если время на выполнение задачи превышает 16 часов (два дня), то задача разбивается на подзадачи. Это позволяет лучше понять, что нужно сделать в рамках этой задачи, на что потребуется время и более точно оценить задачу, не заложив на нее лишнего времени и не пролетев мимо сроков. На одного человека мы набираем от 70 до 80 идеальных часов — времени, которое ему понадобится, если он верно оценил задачу и его никто не будет отвлекать. Количество часов зависит от предыдущих итераций, от того, как каждый закончил свою итерацию.
Например, если человек закрыл свои задачи раньше срока, значит он недооценил свои силы; если он что-то не успел. Значит он переоценивает свои силы (или недооценивает сложность задач). Главное, не использовать скорость (velocity) как показатель продуктивности: это порочный путь, который из инструмента повышения точности при планировании превращается в кнут и хоронит саму суть и смысл аджайла. Тут можно дискутировать, что люди будут стараться не закрывать свои задачи вовремя, по мере исполнения. Да, такое может быть; но у нас работают взрослые, ответственные сотрудники, которым нет нужды так делать.
На ретроспективах и планировании тоже очень легко выявить завышения, сроков. С занижением сроков сложнее, тут нужно понимать человека, что ему предстоит сделать, иметь в виду его результаты по прошлым итерациям и человеческий фактор. Agile poker Аджайл покер — это замечательный инструмент для уточнения сроков и выявления недопонимания. Кроме того, это достаточно весело. Суть аджайл покера в том, что у всех есть карточки с часами: 1, 2, 4, 8, 16, а также? Когда оценивается задача, все кто может ее оценить, кладут карточки на стол цифрой вниз и затем вскрываются. Если время овпало, то задача оценивается в это время.
Если нет, и тем более если разница большая, то начинается выяснение, почему такие разные оценки. По предыдущему проекту знаю, что это очень хорошо работает и я всем рекомендовал бы использовать это игровой элемент. Иногда вскрываются дополнительные задачи, которые вообще были бы упущены и не включены в итерацию.
В этой команде мы не используем покер из-за очень узкой специализации каждого сотрудника, а также из-за того, что у всех очень разные фронты работы: есть некоторая рассинхронизация в задачах. В идеальном мире вся команда берет одну фичу и совместно ее делает. Например, все делают фичу »стрельба»: сервер синхронизацию пуль и передачу пакетов, логика — попадания и поражения, клиент — отображение на клиенте, интерфейс — изменение состояний и баров, художники — огонь выстрела и эффекты попадания. У нас не так: сейчас мы добиваем хвосты (печальное наследие изгнанного исчадия ада) и только приближаемся к синхронной работе. Поэтому покер при таких разноплановых задачах, какие приходится решать нашей команде, не подходит. Кстати покер понравился команде, никогда раньше так не работавшей, когда ради эксперимента мы так провели итерацию. Стендап митинги, ежедневные митинги Очень быстрая блиц-летучка, на которой каждый говорит что сделал вчера, что будет делать сегодня и какие (если есть) возникают проблемы.
Программисты не любят эти митинги так как им кажется, что это какая-то форма отчета, будто их призывают к доске в школе. Объяснить, что митинги нужны для повышения мотивации, синхронизации работы и выявления проблем достаточно сложно, но со временем понимание этого приходит и, если митинг пропущен, то некоторые сами спрашивают — почему пропустили и будем ли сегодня скрамить. Для команд, которые только начинают работать по аджайлу, я (личное мнение, которое идет вразрез с канонами аджайла) рекомендую делать митинги не чаще раз в 2-3 дня, или даже 3-4 дня и постепенно проводить их все чаще и чаще, без насилия над командой. Основная задача скрам мастера/ПМа сделать так, чтобы команда начала воспринимать дейли митинги как инструмент, а не как кнут.
С менталитетом русских разработчиков это, пожалуй, самое сложное в аджайле. Atlassian Jira Джира хороша всем, а особенно тем, что она умеет работать в режиме аджайла. У нее есть форма отображения бэклога, она работает с карточками, строит burndown диаграмму, настраивается как угодно и на команду в 10 человек стоит всего $10 ежемесячно. Еще один плюс — OnDemand версия не требует покупки хостинга, домена и установок, в эти $10 ежемесячно все уже включено. Достаточно только зарегистрироваться и создать проект, остальное все сделается само за 5 минут.
Бэклог В бэклоге Джиры есть такое понятие, как эпик (epic), то есть ключевая фича проекта. В эпики можно включать обычные фичи, баги, стори, задачи и вообще все прочее. Однако сейчас мне удобнее использовать эпики как рубрики разработки: например, архитектура сервера, игровая логика или арт. Почему — потому, что ключевые фичи, над которыми работала бы вся команда одновременно, или все уже реализованы, или до них еще как до Китая. Вероятно, когда определенный этап будет достигнут, появятся эпики командные, которые будут объединять задачи из разных компонентов.
Например, это может быть »полет в космосе», и туда будут входить и задачи по серверу, клиенту, арту, логике, геймдизайну, звукам и чему-то еще. Но лучше один раз увидеть чем сто раз перечитать, поэтому наш бэклог выглядит вот так (делась скриншотом, никаких секретов не раскрою): Картинка кликабельна Что тут видно: слева — эпики (категории задач), по центру — задачи в бэклоге (уже достаточно мелкие и детализированные), справа — детальная информация по задачам и возможность их редактировать. В скриншот не попали задачи из текущего спринта, но это и не сильно важно — там то же самое, только вместо Backlog написано Sprint X и завершенные задачи зачеркнуты. Вместо карточек, прилепленных к доске, используется борд Джиры. Он настраивается как угодно. Мы используем вид по умолчанию — три колонки: к выполнению, в работе и завершена.
Задачи перетаскиваются туда-сюда; завершить можно по-разному: сделана, невозможно сделать, отменена и на тестирование. Можно добавить любые другие статусы или колонки. Выглядит текущий спринт так (картинка тоже естественно кликабельна): Ну и по ходу пьесы можно смотреть прогресс разработки на burndown чарте (наверное, его можно перевести как »график производительности», но суть его в том, что задачи именно сжигаются в процессе разработки). Серая линия — идеальная разработка, если каждую секунду разработчики отмечают прогресс, но так конечно не бывает.
Красная линия — выполнение задач, где каждая точка является успешно завершенной задачей. Идеальный спринт выглядит похоже на скриншот, когда красная линия справа снизу встречается с серой в одной и той же точке.
На скриншоте ниже видно, что спринт завершился на несколько часов позже положенного (на самом деле спринт завершили немного раньше времени, но в Джире было выставлено не московское время — если будете работать в Джире, не забудьте поставить сразу же правильный часовой пояс): Как я уже писал выше, этот чарт строится ежеминутно и любой член команды может мониторить актуальный прогресс в любой момент. На спринте есть лишний пик 23-го октября — это задачи, которые по ошибке не были упущены из спринта в момент его запуска и затем добавлены. Таким образом, добавлять незаметно задачи просто не получится. Все будут это видеть, а спринт все равно волей неволей придется завершать, или будет очень некрасивая картинка: серая линия давно дошла до финиша, а красная идет где-то сильно правее сама по себе.
Jira Руководство Пользователя
Так что если вы работаете с адским менеджером, подсуньте ему Джиру в режиме аджайла и ему придется завершать спринты (если он не захочет бунта команды). Или если вы владелец бизнеса, то то же самое, но в принудительном порядке, благо мониторить разработку так можно без каких-то особых знаний и программерских навыков. Конечно, это не панацея, но инструмент очень неплохой. В Джире есть множество других инструментов для наглядного отображения прогресса — по скорости, по эпикам, по объемам и так далее, но это уже для тех, кто немного освоился с Джирой и аджайлом.
В заключение скажу, что сперва Джира кажется страшной, сложной и очень навороченной. Но вникнуть в нее дело одного дня, разобраться с настройками примерно столько же.
Иногда, когда будут возникать специфические задачи (например, сделать два разных проекта и ограничить доступы разным командам) придется почитать документацию, но тоже все делается за полчаса. Польза, которую приносит Джира, по-моему однозначно стоят этих скромных усилий и совсем небольшого времени.
Попробовать демо-режим Джиры можно, в их демонстрационном разделе, где много разных проектов, разных типов на любой вкус и цвет. Надеюсь, что эта очень сильно оптимизированная по количеству слов заметка будет вам полезна. Иерархия сущностей ограниченная очень. Работа с многими командами и проектами практически невозможна без странных вокрэраундов.
Крайняя сложность настройки (некоторые компании имеют фултайм человека на это дело). Визуализация того, что просиходит, ограниченная. В целом джира очень неплохой тул для начала, если не углубляться в него сильно. Отзывы новичков о Targetprocess 3 очень противоречивые. Если для одних все просто и легко, для других все сложно и непонятно. Я пока не разобрался до конца в чем отличие первых от вторых 🙂.