Кто нибудь здесь? :)

видимо не дошли.

Всем привет!
Моя знакомая, архитектор, проектирующая в России и Новой Зеландии, для своей научной работы в ВШЭ ищет людей из ИТ, чтобы поговорить о влиянии пространства на человека. В частности о том, как офисная среда влияет на нас каждый день, а особенно сейчас, когда многие компании открыли "домашние" офисы, а другие думаю о переустройстве своих старых офисов.

Если вам интересно внести вклад в научный подход к проектированию офисов - пишите мне или Миладе, будем рады пригласить вас на кофе: до конца недели (до 9 августа) в Питере, после - в Москве.

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

Телефон/Телеграм/Ватсап +79173437689
ВК: https://vk.com/id90519740
Электропочта: arch_dom@mail.ru


Подробнее об идее разговора могу написать лично: это обычное глубинное интервью, можно почувствовать себя с другой стороны CustomerDevelopment о_О

Паша, не зная тебя лично, решил бы, что это спам :) привет

Написал в личку

ггг

на это и надеялся)

Карьерный рост как проект. Хороший РП даже личную жизнь может организовать  %)


https://www.facebook.com/photo.php?fbid=2646729208901548

Коллеги, а как вы в Джире задачи к сторям привязываете?

В моем опыте хорошо себя показала линковка через связь implements/is implemented in

Только важно, чтобы все использовали одинаковый тип связи и еще для работы с некоторыми аддонами (например, BigPicture) важно, чтобы у каждой дочерней задачи было не более одной родительской, иначе иерархия может отображаться в аддоне некорректно

Portfolio for Jira использует похожий подход, только через связь parent of/child of (как у сабтасок с родительской задачей), но там вроде есть свои сложности.

это кастомная ваша связь, да?

кастомная, но на сколько я знаю, BigPicture ее использует по-умолчанию (и добавляет при установке аддона)

ага, понял.

было два кейса:
1. стори = задача, разрабы если им нужно создают технические/нефункциональные таски или подзадачи
2. стори дробится на таски по принципу:
- api/backend
- frontend
- mobile
плюс если надо то подзадачи разрабы сами
у каждой таски свои acceptance criteria

собственно, разница подходов в команде: в первом случае команда делала только фронт, бэк у других команд со своими тасками.
во втором случае команда делает все, и бэк и фронт и мобилки

А если тип Story?
то привязка как ? как подзадача?

если тип story то декомпозиция идёт на тип task и их привязывают к story
подзадачи то есть subtask разработчики делают к таске

то есть, принимается что task относится к story как декомпозиция (бэк например)