Blog

Статья от компании K15t Software, эксперта Atlassian и создателя таких приложений как Scroll Office, Scroll Versions, Scroll PDF Exporter и многих других.

Если вы работаете со сложным, многовариантным контентом в Confluence, то приложение Scroll Versions вам просто необходимо. Это приложение для организации контента помогает управлять конкурирующими версиями страниц и документов в одном пространстве, повышает повторное использование контента, улучшает поисковую оптимизацию (SEO), а теперь еще и позволяет публиковать контент, созданный в одном пространстве, в другие пространства.

Мы рассмотрели все отзывы, полученные с момента запуска Scroll Versions в прошлом году, и теперь готовы рассказать, что нового в Scroll Versions 2.0.

Инфопанель  страницы

Один из компонентов Scroll Versions - это Инфопанель страницы, в версии 2.0 мы полностью ее перестроили. Ее главная задача остается прежней: показывать рабочие версии, в которых вы вносите изменения, но теперь она также отображает всю важную информацию, которую полезно знать о текущей странице, включая:

• Перечень всех версий страницы
• Какие варианты страницы доступны
• Где страница была переиспользована
• Где страница была опубликована

И самое важное: С новой Инфопанелью приятно работать! Мы использовали принципы разработки Atlassian, чтобы придать ей приятный вид и дружественный интерфейс.

(Мое любимое нововведение -  теперь двойным щелчком можно раскрывать и сворачивать инфопанель)

Управление вариантами

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

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

Посмотрите на функцию управления вариантами в действии

Оптимизация поискового механизма

Описание заголовка HTML-страницы (тег <title>) особенно важно для оптимальной работы поискового механизма. Этот тег влияет на то, как страница будет отображаться в результатах поиска. Используя  Scroll Versions 2.0, можно отдельно определить заголовок страницы и отдельно то, как страница будет отображаться в результатах поиска.

.

Что еще?

Да много всего.

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

Также, мы потратили некоторое время, чтобы улучшить юзабилити:

• Дерево страниц запоминает открытые узлы и при следующем обращении показывает их развернутыми.
• Отображаются предупреждения для страниц со статусом, отличным от "Завершена".
• Добавлен индикатор процесса публикации страницы

Ознакомьтесь с документацией по Scroll Versions 2.0, чтобы получить полное представления о всех новых функциях и исправленных ошибках.

PS: Вам нужна возможность создавать страницы с одинаковым заголовком?

При использовании Scroll Versions можно создать несколько страниц с одним и тем же названием в одном пространстве Confluence. Это стало возможным благодаря тому, что мы отделили URL страницы  от отображаемого заголовка страницы.

Начните использовать Scroll Versions

В новой версии 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

Каждый год я стараюсь договориться со своим доктором о ежегодном профилактическом осмотре. Каждый раз я выхожу из его кабинета с формой для анализа крови. Эти анализы помогают моему доктору заметить начало заболевания, например, высокий холестерин или диабет. Около двух лет назад я начал подозревать, что моя agile команда страдает от такой болезни как Хаотичная оценка. К сожалению, я не мог просто назначить нужный анализ, как это делает доктор, чтобы диагностировать проблему, поэтому я просто продолжал наблюдать и собирать данные. Через несколько недель, я начертил график. Каждый столбец на графике - это разброс времени, которое потребовалось на реализацию задач, получивших определенное значение story point при оценке. Я также рассчитал некоторые статистические данные, такие как максимум и минимум времени, потраченного на задачи, а также среднее значение и стандартное отклонение. Эти наглядные графики стали бесценным оружием в моей борьбе с «Хаотичной оценкой». В этой статье рассмотрим некоторые «патологии» процесса оценки, которые могут быть выявлены благодаря таким графикам.

Патология «Фаворитизм»

У некоторых команд замыливается взгляд, и они видят все задачи примерно одинаковыми. В итоге, у них появляется парочка любимых значений story points, которые они присваивают подавляющему числу задач.

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

Также у команды с этой патологией могут наблюдаться значительные колебания в скорости работы, так как по факту слишком разное время требуется для выполнения одинаково оцененных задач. Особенно это будет заметно, если ваш спринт будет включать задачи (user stories), расположенные на разных концах разброса.

Экспоненциальная патология

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

Если у вашей команды хорошо получается планировать и выполнять небольшие user stories, но преследуют проблемы с более трудоемкими, это как раз может быть Экспоненциальный синдром.

Чтобы подтвердить этот диагноз, посмотрите на график и попробуйте найти большой отрыв в данных. На представленном справа графике наблюдается очень хороший линейный тренд для небольших значений story points (0.5, 1, 2, 3 и даже 5), но присутствует значительное отклонение для больших значений. Эти большие значения, гораздо лучше укладывались бы в линейный тренд, если сдвинуть их немного вправо.

Если скорость работы команды с такой патологией будет оцениваться по спринтам, содержащим задачи с низкими story points, то вполне вероятна ошибка при расчете даты завершения бэклога проекта. Особенно велика будет ошибка, если бэклог проекта содержит много задач с высокими значениями story points.

Патология Венна

Эта патология берет свое название от диаграмм Венна. Диаграммы Венна используют в тех случаях, когда необходимо понять принадлежит ли некая величина определенному набору данных. Следовательно, график, отображающий данную патологию, покажет большое перекрытие временных интервалов для двух или множества story points.

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

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

То что доктор прописал

Если вы обнаружили, что ваша команда страдает от одной из описанных выше патологий, не отчаивайтесь. Немного усилий и терпения и болезнь будет побеждена. Прописанное лекарство – это перекалибровать ваши story points и начать использовать Triangulation. В любом случае, также как с анализами крови, такие проверки необходимо повторять периодически, так как вы никогда не знаете, когда болезнь может вернуться.

 ЧТОБЫ НАЧАТЬ ИСПОЛЬЗОВАТЬ TRIANGULATION С JIRA НАЖМИТЕ ЗДЕСЬ >

By Rich Manalang, Developer Relations, Atlassian

Несколько недель назад я занимался реструктуризацией кода, написанного моим коллегой из Боулдера (сам я нахожусь в Сан-Франциско).

Я вообще-то довольно нетерпеливый, поэтому мне хотелось, чтобы коллега сразу посмотрел на те изменения, что я вношу. Сразу - то есть без всяких лишних церемоний и официальных бизнес-процессов, которые принято называть "ревью кода" и т.п. Я понял, что мне бы хотелось, чтобы коллега просто видел мой экран с кодом, видел, какие я вношу изменения в реальном времени. Я мог бы сделать следующее:

1. Предложить ему сеанс демонстрации моего рабочего стола.
2. Скопировать код на какой-нибудь хост-сайт и обсудить его через HipChat (сервис группового чата).
3. Закоммитить измененный код в репозиторий Stash и послать коллеге запрос на подтверждение.

Один из этих вариантов  вполне устроил бы большинство разработчиков, но не меня. Мы с Бобом и так детально обсуждаем изменения кода через HipChat, добавление возможности писать код совместно – вот это было бы идеально.

Воплощение в жизнь

Ситуация, описанная выше, случается со мной не в первый раз. Вообще-то она случается постоянно, и я уверен, не только со мной. Я давно мечтал о редакторе, который позволял бы совместное написание кода в реальном времени. Многие пытались создать нечто подобное, но, на мой взгляд, все было не то.

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

Stash Realtime Editor позволяет в реальном времени редактировать файлы напрямую из интерфейсов Stash, никаких копирований-клонирований, никаких IDE, никаких локальных редакторов. Вы можете  поделиться ссылкой с коллегой и редактировать или проверять код вместе. После того, как нужные изменения сделаны, вы можете сразу закоммитить их в Stash  без необходимости выполнять push в репозиторий. Ваш коммит будет сохранен отдельной веткой (branch) и впоследствии можно будет провести слияние простым pull-запросом.

Stash Realtime Editor  встраивает real-time редактор напрямую в Stash, используя легендарный сервис  Firebase и их крутой редактор Firepad, построенный на базе  operaional transform (OT - теоретическая основа для управления конкуренцией в контексте группового редактирования).

OT делает real-time редактирование файлов надежным и предсказуемым и позволяет пользователю видеть, чем заняты другие пользователи (например, выделение, подчеркивание, правка и так далее).  

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

Stash Realtime Editor – бесплатная надстройка для Stash. Ищите на Atlassian Marketplace…

Узнать больше

Оригинал статьи на сайте Atlassian: http://blogs.atlassian.com/2013/04/meet-the-stash-realtime-editor-add-on/

Ниже представлена запись вебинара, проводившегося на Atlassian Enterprise Workshop в марте 2013. Вебинар "Концепция Agile вместе с JIRA и GreenHopper" проводил Роджер Симондс из компании Customware, имеющий статус Atlassian Enterprise Expert.

Вебинар знакомит с методологиями Scrum и Kanban, а также рассказывает, как можно применить итерационный подход и подход управления потоками (flow based), используя Atlassian GreenHopper. Рассмотрены такие инструменты как: Рабочие столы GreenHopper, Эпосы (Epics) и Спринты (Sprints), а также три новых режима: Планирование, Работа и Отчетность. Прослушав вебинар, вы узнаете, как ваша команда может использовать GreenHopper, чтобы стать Agile

Участие в подобных сессиях - это эксклюзивное право пользователей корпоративных редакций продуктов Atlassian - Atlassian Enterprise. Этот воркшоп, а также многие другие доступны на сайте Atlassian в разделе Enterprise Resources.

Как растущим стартапам, так и компаниям в списке Fortune 100 - Atlassian предлагает поддержку и услуги, организованные так, чтобы удовлетворить запросы самых крупных предприятий. С теми возможностями, которые дает редакция Enterprise для JIRA, Confluence и Stash, Atlassian покрывает все потребности вашей компании в совместной работе сотрудников и в управлении разработкой программного обеспечения.

Узнай больше об Atlassian Enterprise

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

Помощник администратора JIRA - это бесплатный плагин, который отвечает на такие вопросы как:

• Почему какое-то поле не отображается при создании, редактировании или просмотре запроса?
• Почему пользователь может или не может видеть запрос?
• Почему пользователь получает или не получает определенное почтовое уведомление?

Тройка помощников готова ответить на эти вопросы.

Помощник по полям (Field Helper)

Если вы залогинились как администратор, то каждый раз при создании, редактировании или просмотре запроса, вы можете увидеть Помощника по полям. 

	Помощник не только укажет причины (их может быть несколько), по которым какое-то поле не отображается, но и даст исчерпывающие инструкции, как все исправить. Помощник работает как со стандартными полями JIRA, так и с пользовательскими.
Ссылка Where is my field? ( Где мое поле?) доступна: При создании запроса (всплывающее окно Настройка полей) При редактировании запроса (всплывающее окно Настройка полей) При просмотре запроса (меню Другие действия) Из Навигатора запросов (меню Инструменты)

Помощник по разрешениям (Permission Helper)

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

Помощник по разрешениям отвечает на все эти вопросы. К Помощнику можно перейти с экрана просмотра запроса, из Навигатора запросов, а также из раздела администрирования (JIRA Administration).

Помощник по уведомлениям (Notification Helper)

Почему пользователь не получил уведомление о добавлении комментария? Чтобы узнать ответ на этот вопрос, используйте Помощника по уведомлениям.

Этот помощник также доступен с экрана просмотра запроса, из Навигатора запросов и из раздела администрирования (JIRA Administration).

Присоединяйтесь!

Плагин JIRA  "Помощник Администратора"  уже доступен для администраторов, работающих с JIRA 5.2, а также с облачной версией JIRA. Присоединяйтесь!

 Если вы используете более раннюю версию JIRA, то вы можете загрузить плагин с Atlassian Marketplace.

Мы не шутили, когда говорили, что новый обновленный Confluence это только начало.

Confluence 5 заложил фундамент для Blueprints, а Blueprints - это именно то,чего не хватало, чтобы, наконец, вовлечь всех ваших сотрудников в работу с Confluence.

Уже работаете с Confluence?
 Загрузите Confluence и обновитесь сегодня!

Облачным пользователям
Вы автоматически обновлены и уже используете Confluence Blueprints!

Контент - вот основа

Именно контент объединяет людей вместе и помогает двигаться к общим целям. Последние десять лет мы изучали, как наши клиенты используют Confluence в своей ежедневной работе. Мы выделили наиболее удачный опыт и включили его в Confluence - мы назвали это "Blueprints" (в переводе с английского -"образцы", "матрица")

Пообщавшись с многими нашими клиентами, мы поняли, что приоритетом номер один для нас должно являться разъяснение пользователям, что они могут делать с Confluence, почему это может быть полезно и как начать это делать.

Bill Arconati, Confluence Product Manager
Atlassian Inc.

Что такое Blueprints и как они могут помочь моей команде?

Confluence Blueprints вовлечет в процесс создания контента всех пользователей. Blueprints:

1. Помогает пользователю понять, какой тип контента можно создавать - отчеты о встречах, списки файлов, списки требований и прочее.
2. Разъясняет как создать этот контент.
3. Автоматически структурирует контент, тем самым облегчая его поиск в будущем.

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

1. Совещания: повестка совещания, список участников, план мероприятий

Мы в Atlassian ненавидим бесполезные, отнимающие время совещания. Мы создали  Blueprint "Совещания" чтобы помочь организаторам совещаний:

1. Создавать и рассылать повестку совещания перед встречей, чтобы участники могли подготовиться.
2. Фиксировать принятые в течение совещания решения, чтобы позже любой участник мог их перечитать.
3. Назначать ответственных за выполнение принятые решений, чтобы ответственным было удобно отслеживать свои задачи.

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

2. Списки файлов: общий доступ, версии, безопасность.

Слишком часто необходимые файлы теряются в почтовых ящиках или в паутине сетевых папок. Еще сложнее с актуальными версиями - это современный вариант поиска иголки в стоге сена. Страницы Confluence -  это превосходный инструмент для обмена важными файлами: автоматическая версионность, онлайн просмотр, полнотекстовый поиском. Документы PDF, документы Office, рисунки - файлы вашей команды доступны всем, кто в них нуждается, в любой момент.

Также как с  Blueprint "Совещания", Confluence автоматически собирает все списки файлов пространства в одном месте. Никогда еще не было так просто держать файлы упорядоченными и доступными. Попрощайтесь с тем временем, которое вы тратили на поиск файлов и документов.

3. Требования к продукту: определения, дискуссии, отслеживания.

Создание превосходных продуктов требует еще более превосходного планирования. Многие наши клиенты  составляют описание требований и планируют новые функции продукта,  используя Confluence.  Blueprint "Требования" поможет команде разработчиков совместно создавать, обсуждать и упорядочивать требования к продукту. С помощью нового макроса Page Priperties теперь можно добавлять пользовательские свойства страницам - для управления требованиями добавьте версию продукта, статус документа, владельца и прочее.

Confluence автоматически собирает все требования к продукту на одной странице, здесь вы можете сортировать документацию с описанием требований по любому пользовательскому свойству. Теперь в одном месте можно увидеть, что должно быть реализовано и кем.

Больше Blueprints на Atlassian Marketplace

Не все работают одинаково, одни и те же бизнес-процессы могут существенно отличаться. Каждая команда уникальна.  Confluence Blueprints - это каркас, который позволит выстроить собственные процессы. Пользовательские Blueprints (платные или бесплатные) могут без ограничений распространяться через Atlassian Marketplace. Четверо участников Marketplace уже стали партнерами Atlassian и создали собственные Blueprints, доступные для загрузки уже сегодня:

• Strategy canvases от Comalatech для управления задачами и визуализации бизнес-процессов.
• Online diagrams от Gliffy для создания качественных диаграмм,  структуры организации.
• Polls от Simplenia для создания простых голосований, принятия групповых решений.
• Evernote Importer  от StiltSoft для того, чтобы делиться заметками Evernote через Confluence.

Полистайте, найдите и попробуйте разные Blueprints

Blueprints могут сделать вашу работу продуктивнее. Чтобы поиск полезных Blueprints был как можно проще, мы встроили  Atlassian Marketplace в Confluence.

Любой пользователь может найти подходящие Blueprints и запросить установку у своего системного администратора. Возможности безграничны.

Кастомизируйте Blueprints

Мы сделали Blueprints гибкими. Любой системный администратор или администратор пространства может изменить шаблон любого Blueprint, чтобы лучше подогнать его под бизнес-процесс организации. Можно даже создать свой.

Впереди светлое будущее

Мы уже в процессе создания новых Blueprints. Также мы всячески поддерживаем сторонних разработчиков в создании своих Blueprints. Мы ограничены вселенной.  

И еще…

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

Незнакомы с Confluence?

Это дело нескольких минут с бесплатной 30-дневной лицензией облачной версии Confluence.

Готовы обновиться?

Изучите полную документацию на релиз и используйте все преимущества Confluence 5.1 сегодня

Облачным пользователям: Вы автоматически обновлены на Confluence 5.1!