Blog from May, 2013

В новой версии Confluence 5.1 появились новые шаблоны, которые называются Blueprints. И вот теперь возник вопрос - как это перевести на могучий русский? Голосуем:

Сегодня компания Atlassian представила новую мажорную версию своего фалгманского продукта JIRA.

Новый внешний вид, новые ощущения - обновленный дизайн без лишних деталей позволяет сосредоточиться только на работе. Плюс она теперь адаптирована для мобильных устройств и теперь очень просто работать на ходу.

Современно

Новый внешний вид

Как перед этим новые версии Confluence и Stash, JIRA 6.0 приобрела тот же внешний вид  - новые иконки, кнопки, шрифты, и те же принципы организации рабочего пространства.

Навигация

С новым хидером, наиболее часто посещяемые страницы и последние действия теперь на расстоянии одного клика. Плюс к этому появился быстрый доступ к любому приложению, с которым связана ваша JIRA, будь то продукт Atlassian или любого стороннего разработчика.

Быстро

Детальный вид: оптимизация работы с запросами

С функцией "детальный вид" (detail view) Вы сможете просматривать запросы как на лету, так и подробно, одновременно. Детальный вид дает Вам все преимущества: онлайн редактирование полей, напоминания для вовлечения других пользователей в обсуждение и горячие клавиши для навигации, редактирования и сортировки запросов на лету.

Компактный режим

Ничто так не помогает продуктивности, как правильный вид рабочего экрана. С новым компактным режимом в JIRA 6.0 экономиться около 20% пространства, чтобы можно было состредоточиться на главном: запросах. При показе списка запросов компактный режим позволяет добавить больше столбцов на экран, при детальном виде - больше полей запроса без прокрутки.

Мобильно

Повсеместный доступ к JIRA с новым видом для мобильных устройств. Фокусировка на том, что надо, когда Вы не в офисе - комментарии, напоминания; возможность назначить срочную задачу с телефона, если вы застряли на совещании. Плюс ко всему при проверке запросов и уведомлений в почте, при клике на название запроса, Вы быстро переходите в новый мобильный вид JIRA. 

Просто

Легкий старт

По принципу новых блюпринтов Confluence, наиболее частоиспользуемые проекты в JIRA теперь запускаются в 2 клика.

Бизнес-процесс

Тысячи команд используют JIRA из-за лучшей настройки бизнес-процессов. Но теперь не надо начинать с нуля - все виды бизнес-процессов и лучшие практики есть на Atlassian Marketplace. Находите, загружайте, пробуйте, меняйте. Все просто!

Еще больше в JIRA 6.0

• Редактируемые имена пользователей - вторая по количеству голосов фича наконец-то появилась в новой версии. Администраторы могут править имена пользователей во внутренних директориях.
  
• Глобальная схема процессов - редактирование схемы активного процесса нескольких проектов. Если у вас много проектов с одной схемой бизнес-процесов это фича для вас.
• Перевод пользовательских полей  - если ваши пользователи используют JIRA на разных языках, теперь вы можете переводить на разные языке названия и описания пользовательских полей.
• Копирование запросов из одной инсталляции в другую (плагин с Marketplace) - для клиентов, у которых больше одного JIRA сервера, могут копировать запросы из одного проекта в другой, даже если эти проекты находятся в разных инстансах
  
  

Скачать JIRA 6.0

Купить JIRA 6.0

оригинал статьи на сайте Atlassian:http://blogs.atlassian.com/2013/05/stash-git-forking-development-workflow/

GIT, как система распределенной работы, предлагает множество вариантов взаимодействия разработчиков в проекте. Команды переходят на GIT в поисках большей гибкости работы с кодом в условиях крупной компании. Распространенной практикой стало использование веток и форков, при этом не утихают споры о том, как лучше их использовать в рамках всей компании.

Сегодня мы рады представить Stash 2.4, который обеспечит необходимую гибкость большим командам для управления их бизнес-процессами разработки с использованием GIT. Этот релиз включает несколько важных функций для управления вашими GIT репозиториями, расположенными за фаерволом:

• использование форков  (вилок) - способ распределенного создания кода, популярный в проектах с открытым исходным кодом;
• персональные репозитории;
• права доступа на репозитории.

Альтернатива, гибкость, контроль - да, это Stash 2.4.

Попробуйте Stash 2.4 сегодня

Совместная разработка в GIT с использованием форков

По сути создание форка - это создание копии репозитория на сервере, включая всю накопленную историю. С помощью форка в Stash выстраивается бизнес-процесс, который позволяет разработчикам внести свой код в репозиторий, к которому у них нет прав на запись. При этом в процесс разработки добавляется этап контроля (см.рисунок ниже). Клик по кнопке "Fork" в репозитории создает копию, которая будет отслеживаться и модифицироваться независимо от оригинального репозитория, избавляя код в основном репозитории от случайных изменений и ошибок. Вы можете сделать форк репозитория и связать его с любым другим проектом в Stash, для которого обладаете правами администратора. Вы можете создать персональный форк и дать другим разработчикам доступ. Stash позволяет легко объединять изменения между форками с помощью pull-запросов.

Почему форки?

• Удобно для подрядчиков. Позвольте сторонним разработчикам участвовать в проекте, при этом только у членов основной команды будут права записи в репозиторий. Подрядчики смогут сделать форк репозитория, а потом добавить созданные изменения обратно через pull-запрос.
  
  
• Удобно для больших команд. Когда сотни разработчиков работают в одном репозитории, количество веток и прочей деятельности в репозитории зашкаливает и начинает мешать. Форки позволяют командам работать обособленно, периодически синхронизируя новые изменения из основного репозитория в свой проект.
  
  
• Удобно для экспериментов. Участвуете ли вы в ShipIt или работает над прототипом функции, эксперименты на форках дают разработчикам возможность портить код, не загрязняя основной репозиторий коммитами на случай, если эксперимент не удастся.
  

Подробнее о том, почему крупным организациям стоит принять на вооружение использование форков, можно посмотреть в статье “Why Forks?“.

Вносите изменения через pull-запрос

Прелесть использования форков заключается в том, что изменения, сделанные в форк-копии репозитория, никак не затрагивают основной код. Когда форк-копия готова выйти на сцену, можно сделать запрос, чтобы передать изменения в основной репозиторий. Использование pull-запросов в Stash облегчает внесение изменений. Такой подход позволяет другим разработчикам просмотреть и обсудить изменения перед тем как они станут официальной частью кода. Таким образом, абсолютно все изменения могут вноситься в основной репозиторий опираясь на настройки pull-запроса и разрешения веток.

Персональные репозитории

В Stash 2.4 мы добавили возможность создавать персональные репозитории. Персональный репозиторий не относится ни к одному проекту. У разработчиков появляется свобода пробовать новшества или хранить свою незавершенную работу, начинать свои проекты, участвовать в отладке чужих проектов  или добавлять функции в общие компоненты. Персональные репозитории могут быть открытыми или закрытыми, используйте разрешения на уровне репозиториев, чтобы взаимодействовать с другими пользователями и группами так, как вам удобно.

Поскольку теперь у пользователя появилась возможность создавать персональные репозитории и персональные форки, необходимо было обеспечить удобный доступ ко всем этим штукам. Так что пользовательские профили мы тоже подправили.

Репозитории и разрешения

Разрешения в Stash нужны для того, чтобы обеспечить безопасность вашего кода и дать вам уверенность, что нужные разработчики имеют нужные права. Раньше существовало два уровня разрешений глобальные разрешения чтобы обеспечить контроль или передать права на проект пользователю или группе и разрешения проекта, чтобы контролировать доступ на чтение и запись внутри проекта. В Stash 2.0 мы добавили более глубокий уровень доступа - разрешения веток - чтобы определить, кто может делать коммит в конкретных ветках репозитория. Stash 2.4 добавляет еще более детальный уровень настройки доступа - вы можете устанавливать разрешения на уровне репозитория. 

Администраторы могут делать проекты настолько закрытыми или открытыми, насколько это нужно. Предоставьте доступ к отдельным репозиториям в пределах проекта, не давая прав на весь проект. Ниже приведены несколько сценариев, когда это может пригодиться:

• Внешние разработчики –   широкий доступ к репозиториям может заставить вас нервничать, если вы работаете с внешними разработчиками. Для некоторых проектов ваша основная команда должна иметь доступ ко всем репозиториям, тогда как внешним разработчикам можно оставить доступ только к нескольким выделенным репозиториям..
  
  
• Открыть доступ –  Многие команды открывают доступ на запись к определенным проектам только небольшой группе разработчиков. Чтобы привлечь к работе других разработчиков, вы можете открыть доступ на чтение всем сотрудникам организации, так чтобы разработчики, не вошедшие в основную команду, могли создавать форки и таким образом привносить свой вклад.
  
  
• Передача администрирования – Сохраните свое время, передав администрирование репозитория надежным членам команды.

Stash предлагает вашей команде на выбор несколько вариантов распределенной работы, и эта гибкость позволяет вам выдавать результат быстрее.

Всегда делайте форк перед коммитом в Stash 2.4

Незнакомы со Stash? Начните создавать форки уже сегодня с бесплатной триальной версией

Попробуйте Stash 2.4 сегодня

Уже работаете со Stash? Вы можете обновиться до версии  2.4 с помощью одного клика. Ознакомьтесь с документацией по релизу и вперед.

Вдохновившись популярностью Ad hoc Canvas Blueprints, компания Comalatech добавила  функциональность плагина Ad hoc Workflows в  Confluence Blueprints.

Новый релиз Ad hoc Workflows 4.1 позволяет прикрутить автоматизированные бизнес-процессы напрямую к вашим Blueprints!

Взгляните сами:

Добавьте бизнес-процессы к вашим Blueprints

Чтобы добавить workflow-функциональность на страницу, достаточно просто прикрепить бизнес-процесс Ad hoc Workflows к вашему Blueprint-шаблону.

Автоматизируйте

Автоматизируйте процесс рассмотрения\согласования страницы с помощью нового процесса  Requirements Workflow. Этот процесс позволяет назначить согласующих лиц для страницы с помощью шаблона Blueprint.

Уведомления

При создании каждого запроса на согласование, Ad hoc Workflows отправляет уведомление на почту.
 

Отчетность

Прохождение вашего бизнес-процесса можно отслеживать, просматривая историю страницы или с помощью новой строки состояния.

 Также Ad hoc Workflows предлагает расширенную отчетность, так что управлять вашими документами становится проще.

Это всего лишь небольшой трейлер того, что вас ждет. Мы по-настоящему взволнованы появлением JIRA 6.0.  Пристегнитесь покрепче в своем офисном кресле, приготовьтесь встретиться с новой JIRA.

Слава команде Confluence за идею этого видео =) 

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

Давайте сортировать

Как только на ваш продукт обрушился поток отзывов, пора принимать меры. Отзывы должны всегда идти напрямую от пользователей, для этого можно использовать такие инструменты как Bonfire, JIRA Issue Collectors, и JIRA Mobile Connect. Мы в Atlassian используем JIRA для работы с отзывами, пользователь может добавить отзыв напрямую в JIRA через https://jira.atlassian.com.  Не все оставленные отзывы имеют какую-то ценность. Организуйте простую процедуру сортировки входящих отзывов. Необходимо вчитаться в каждую часть отзыва и понять, является ли отзыв:

• Обоснованным: “Когда я кликаю по кнопке X, я ожидаю события Y, но происходит событие Z”
• Уникальным: возможно, похожий отзыв уже в работе.
• Существенным для продукта: “Должна быть другая кнопка для функции X”
• Слишком затратным для реализации: “При нажатии esc  броузер должен сохранять введенные в форму данные, на случай если я захочу повторно их использовать”
• Противоречащим принятому решению –  команда продукта приняла решение, что работать функция должна именно так, а не иначе.  Отзывы, касающиеся таких вещей, должны быть внимательно изучены.

Если бэклог продукта замусорен отзывами, по которым непонятно что делать и надо ли вообще что-то делать, вам сложно будет двигаться вперед. Отправьте малоприменимые отзывы на долговременную стоянку. Мы закрываем такие запросы с соответствующей резолюцией. Закрытый запрос  - это на потерянный запрос! Среди закрытых запросов можно искать, делать выборку,также как и среди открытых. Короткие резолюции делают поиск среди закрытых запросов гораздо эффективнее. Не стоит удалять отзыв, который вы сочли малоприменимым, ведь, возможно, вам захочется к нему вернуться. Стоит потратить на такой отзыв немного времени, чтобы позже его можно было легко найти. Поля JIRA для резолюций могут быть настроены так, чтобы удовлетворить любой из описанных выше случаев. Эпики, компоненты и метки позволят отследить те вопросы, которые в будущем могут потребовать пересмотра.

Разложим по полочкам

Каждый рассматриваемый запрос отнимает время. Команда JIRA использует трехуровневый бэклог, чтобы разделить стадии прохождения отзывов.

Если детализировать схему, приведенную выше, то вместо единой области "passes review" (отзывов прошедших проверку) появятся еще два уровня.

На стадии необработанных (raw) отзывов, владелец продукта решает, стоит ли сохранить или пропустить отзыв. Если отзыв сохранен, то он попадает в категорию неприоритизированных. Это означает, что владелец продукта собирается что-то делать по поводу этого отзыва рано или поздно, но пока отзыв не может быть передан разработчикам. Как только владелец продукта решил дать дорогу отзыву, отзыв перемещается в очередь отзывов, готовых для аналитики. Эта очередь плотная, упорядоченная, из нее можно быстро набрать функций для очередного спринта.

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

GreenHopper - не только для разработчиков

GreenHopper - это Agile-плагин для JIRA. Многие команды разработчиков используют его, чтобы отслеживать свою работу по методологии agile. Владельцы продукта тоже  могут использовать GreenHopper, чтобы отслеживать бэклог. PM команда JIRA для отслеживания бэклога использует Канбан-доски GreenHopper. Система Канбан - это процессный подход, поэтому легко отслеживать путь запроса от отзыва до функции.  Обратите внимание, это отдельная Канбан-доска, не та, которую используют разработчики. 

Дорожная карта бэклога JIRA имеет четыре состояния:

• Еще не готов – сырой отзыв
• Не обработан – добавлен в бэклог, но не готов для передачи в разработку
• Готов для аналитики – команда аналитиков в первую очередь должна работать над заявками с высоким приоритетом
• В разработке – ведется активная работа над функцией

Команда PM группирует запросы по Эпикам так, чтобы все связанные запросы были расположены рядом на экране. Группы могут быть легко свернуты, таким образом в случае необходимости PM смогут сфокусироваться на одном Эпике. Это помогает PM быстро пробегать весь бэклог.

Готовы перестроить свой бэклог? Попробуйте GreenHopper!

Try GreenHopper

26 апреля состоялось наше первое мероприятие, посвященное продуктам Atlassian, за пределами двух столиц.

Екатеринбург встретил искренней радостью и живым интересом ИТ-сообщества к продуктам Atlassian и всевозможным вариантам их использования.

В программе были доклады как для новичков, так и для профи в девелопменте и Agile-практиках. Не забыл поучаствовать в мероприятии и сам Atlassian в лице хорошо знакомого нам Шерали Каримова (руководителя службы технической поддержки Atlassian).

В целом мероприятие получилось дружеским и, по-хорошему, неформальным.

Надеемся еще не раз побывать в сердце России и порадовать уральское ИТ-сообщество новинками и лучшими практиками с передовой ИТ-индустрии в мире.

Всем, кто не смог лично поучаствовать в Teamlead Atlassian Day в Екатеринбурге предлагаем в течение ближайших двух недель постетить наш сайт - в разделе Мероприятия будет выложено видеозапись выступлений и презентации.

А фотографии Екатеринбурга и мероприятия можно посмотреть уже сейчас.

Мы рады сообщить о выходе бета-релиза JIRA 6.0. Если вы занимаетесь созданием плагинов для JIRA, или вам просто не терпится попробовать новые разработки - вперед!

Попробуйте новую JIRA

Интерфейсы и сценарии JIRA 6.0  были переделаны в соответствие с новыми Положениями о разработке Atlassian. Если вы разработчик, то эти изменения вас коснутся, так что начинайте вносить изменения в  свои плагины уже сейчас. Следующие документы (на английском) помогут вам с этим:

• Preparing for JIRA 6.0 – детализированная информация по применению Положений о разработке Atlassian.
• Building UI for a plugin shipping to multiple versions of JIRA  - как создавать плагины, совместимые с несколькими версиями JIRA
• Bonfire ADG Migration Guidelines – пример создания плагина, совместимого с несколькими версиями JIRA

Обновите свои плагины

Разработчики плагинов - будьте готовы!  EAP 4 (m6) - последний релиз, включающий  “ломающие изменения” для JIRA 6.0. “Ломающие изменения” - это изменения в  API JIRA, которые требуют от разработчиков проектировать свои плагины по-другому. Они включают изменения в постоянном (Java) API, изменения в  JIRA CSS стилях, изменения в компонентах JavaScript для построения UI, изменения в HTML шаблонах.

Вам следует начинать обновлять свои плагины для работы с JIRA 6.0 уже сегодня. Мы собрали вместе документы, описывающие ключевые изменения в JIRA 6.0, чтобы вам легче было обеспечивать совместимость ваших разработок с JIRA 6.0. Детальную информацию по всем изменениям можно найти в документе Preparing for JIRA 6.0. Также рекомендуем посмотреть документ Java API policy for JIRA, который содержит информацию по JIRA Java API и описывает  наш подходу к изменению API.

Говорят разработчики

Мы потратили больше года на то, чтобы сделать JIRA производительнее, проще и гибче. Этот проект, под кодовым названием Kickass*  весь был посвящен эффективности наиболее часто используемых сценариев. Посмотрите видео, в котором наши разработчики рассказывают о своей работе.

*надрать задницу, груб. показать на что ты способен

Загрузите бета-релиз сегодня

Всю информацию, которая была упомянута выше, а также ссылку на загрузку бета-релиза JIRA 6.0 можно получить по ссылке ниже.

Перейти к JIRA 6 Beta