Comments 57
Мы рекомендуем этот подход всем крупным командам разработчиков.
Крупные — это >10 человек? Или >100?
Сколько, кстати, размер вашей команды?
А как вы решаете задачу синхронизации Jira и доски. У вас это каждый раз делают исполнители задач или есть просто ввыделенный человек который синхронит?
Поэтапная доска с заданиями — это до внедрения или после?
Мы пришли к похожему подходу, только у нас еще есть в workflow status Delay, для отложенных задач.
И да, Jira тормоз :(
И да, Jira тормоз :(
Аналогично, но у нас задач поменьше и народу то же. Используем Trello. Один из любимейших task менеджеров, если бы они продавали футболки с логотипами, я бы ее обязательно купил.
А почему выбрали именно Trello? Что в нём нравится больше всего?
Можно заказать принт на футболке :)
UFO just landed and posted this here
У нас redmine. Выбран давно в силу возможностей и бесплатности. Сейчас хочется иметь доску как в вашем примере. Это очень наглядно. Нравится Trello.
Но вот для редмайна такого простого инструмента нет. А съехать не сильно получается, т.к. в редмайне накоплена большая история по проектам, таскам и wiki. И хочется остаться на чем-то бесплатном. Такие дела (
За статью спасибо )
Но вот для редмайна такого простого инструмента нет. А съехать не сильно получается, т.к. в редмайне накоплена большая история по проектам, таскам и wiki. И хочется остаться на чем-то бесплатном. Такие дела (
За статью спасибо )
А как же Redmine backlogs? Вполне удобный плагин… www.redminebacklogs.net/
UFO just landed and posted this here
Мы совсем недавно выпустили плагин Redmine Agile, который позволяет вести примитивную доску и строит базовые диаграммы.
Может быть будет полезно
Может быть будет полезно
Класс! Радует, когда видишь, что в Яндексе делают так же, как и мы у себя :)
Очень здорово!
Если не секрет, для мелких задач все еще используете наши постики? :)
Если не секрет, для мелких задач все еще используете наши постики? :)
Не совсем понятно как планирование происходит, когда нет оценок для задач.
А, если не секрет, как решаются проблемы, когда одна задача ломает другую, уже оттестированную, и когда вообще гонятся регрессы? Или используется только автотесты? Что бывает с тасками, которые не прошли тестирование и не укладываются в спринт, в какой момент принимается решение, что они в спринт не войдут?
И, не очень понятно, верстку отделили от бэкенда — теперь они у вас просто в отдельных спринтах параллельно или чередуются, как решаются проблемы взаимодействия, когда один компонент нельзя катить без другого?
И, не очень понятно, верстку отделили от бэкенда — теперь они у вас просто в отдельных спринтах параллельно или чередуются, как решаются проблемы взаимодействия, когда один компонент нельзя катить без другого?
А, если не секрет, как решаются проблемы, когда одна задача ломает другую, уже оттестированную, и когда вообще гонятся регрессы?
Полные регрессы происходят при подготовке релизов. Отдельные задачи проходят code review и тестирование перед вливанием в стабильную ветку. Стараемся делать атомарные изменения, чтобы ничего не взрывалось.
Что бывает с тасками, которые не прошли тестирование и не укладываются в спринт, в какой момент принимается решение, что они в спринт не войдут?
У нас все задачи проходят тестирование, кроме совсем тривиальных syntax fix'ов. У нас, как правило, нет жестких deadline'ов, поэтому когда мы понимаем, что не успеваем сделать задачу, то просто переносим её в следующий спринт.
И, не очень понятно, верстку отделили от бэкенда — теперь они у вас просто в отдельных спринтах параллельно или чередуются, как решаются проблемы взаимодействия, когда один компонент нельзя катить без другого?
Задачи бэкэнда вёрстки живут в нашем спринте. Есть другой уровень «бэкенда», который живёт отдельно. Но мы не начинаем делать интерфейсы, пока этот уровень не готов хотя бы частично.
Вы бы объяснили, что такое Kanban заодно, раз уж на скриншотах всё по-английски. (Если кратко, Kanban — это без чёткого деления на спринты по неделе-две, для проектов где задачи прибывают ВНЕЗАПНО и СРОЧНО, a lá russe)
В JIRA есть плагин с русской локализацией, в том числе для JIRA Agile (так сейчас называется Grasshopper). Там можно и без English knowledge работать.
В JIRA есть плагин с русской локализацией, в том числе для JIRA Agile (так сейчас называется Grasshopper). Там можно и без English knowledge работать.
Ходят слухи, что у вас жира окончательно перестала справляться и вы что-то внутренее пилите. Правда?
Да, мы разрабатываем замену. Если хотите подробностей, приходите к нам работать.
Есть такой вопрос, а что вы делаете, когда становится понятно, что
формулировка задачи неправильная, вешаете её на постановщика обратно?
Сама методология Scrum замечательна.
А вот Agile Board — это костыль.
Почему?
А потому, что он, по сути, является фильтром для задач. Если бы у списка задач был гибкий, удобный фильтр, то не потребовалось бы делать отдельное решение на отдельной странице в виде Agile Board.
По сути, это напоминает некий отфильтрованный список, наложенный на недельный календарь.
Хочется взять мою бритву Оккама и отрезать лишнее.
А вот Agile Board — это костыль.
Почему?
А потому, что он, по сути, является фильтром для задач. Если бы у списка задач был гибкий, удобный фильтр, то не потребовалось бы делать отдельное решение на отдельной странице в виде Agile Board.
По сути, это напоминает некий отфильтрованный список, наложенный на недельный календарь.
Хочется взять мою бритву Оккама и отрезать лишнее.
Можете пояснить мысль как-то подробнее? В чем проблема фильтра Agile Board?
Проблема?
Да нет никакой проблемы. Это зависит от точки зрения.
— Вот есть список задач (в терминологии Scrum — Резерв проекта, далее в скобках будет терминология Scrum, хотя я не вижу смысла ее использовать).
— Задачам задается приоритет, и весь список можно выстраивать по приоритету Немедленный, Срочный, Нормальный, Высокий, Низкий.
— Периодически, из списка задач (Резерва проекта) выбираем задачи для релиза (Спринта).
— Список задач можно отсортировать таким образом, чтобы показывать только задачи релиза (Спринта) или показывать их сверху списка задач (Резерва проекта).
— Далее, в рамках списка задач релиза (Спринта) их можно сортировать по статусам Новая, В работе, Тестирование, Выполнена.
Все это делается с помощью стандартного фильтра того же Redmine, не пойму, зачем сюда еще Agile Board вставлять.
Да нет никакой проблемы. Это зависит от точки зрения.
— Вот есть список задач (в терминологии Scrum — Резерв проекта, далее в скобках будет терминология Scrum, хотя я не вижу смысла ее использовать).
— Задачам задается приоритет, и весь список можно выстраивать по приоритету Немедленный, Срочный, Нормальный, Высокий, Низкий.
— Периодически, из списка задач (Резерва проекта) выбираем задачи для релиза (Спринта).
— Список задач можно отсортировать таким образом, чтобы показывать только задачи релиза (Спринта) или показывать их сверху списка задач (Резерва проекта).
— Далее, в рамках списка задач релиза (Спринта) их можно сортировать по статусам Новая, В работе, Тестирование, Выполнена.
Все это делается с помощью стандартного фильтра того же Redmine, не пойму, зачем сюда еще Agile Board вставлять.
борд показывает данные в двух измерениях, в отличие от обычного списка. Это гораздо нагляднее. Кроме того, статусов может быть больше трех, тогда разница в визуализации работы очень заметна.
Всегда было интересно а где при ваших объемах вы сохраняете все «Nice to have»-задачи, и в чем ведете (если ведете) roadmap продукта.
Чтобы не было недопонимания. Под «nice to have» задачами что понимается?
Идеи, которые не получили детального описания, или домыслы, которые еще не были исследованы.
То есть задача еще не получила полноценного User Story и у вас есть только сообщение пользователя (а при исследовании вы понимаете что у определенной группы пользователей и почему)
— Ребята сделайте кнопку удаления фотографии справа.
Или один из разработчиков делиться идеей:
— Возможно нам следуют пользователю дать возможность искать похожие картинки лучшего качества.
После анализа, они сразу упадут в один из спринтов или же будут запланированы в большой roadmap — Эту функцию уместнее всего будет запустить одновременно на всех платформах, поэтому запускам в Апреле.
То есть задача еще не получила полноценного User Story и у вас есть только сообщение пользователя (а при исследовании вы понимаете что у определенной группы пользователей и почему)
— Ребята сделайте кнопку удаления фотографии справа.
Или один из разработчиков делиться идеей:
— Возможно нам следуют пользователю дать возможность искать похожие картинки лучшего качества.
После анализа, они сразу упадут в один из спринтов или же будут запланированы в большой roadmap — Эту функцию уместнее всего будет запустить одновременно на всех платформах, поэтому запускам в Апреле.
После анализа, они сразу упадут в один из спринтов или же будут запланированы в большой roadmap — Эту функцию уместнее всего будет запустить одновременно на всех платформах, поэтому запускам в Апреле.
Зависит от задачи очень сильно. Бывают, что предложенные (внутри, снаружи) идеи попадают в спринт, а затем и в релиз. Обычно нужно больше времени на исследовать, сделать прототип.
Что изменилось за почти 4 года? Где-то рассказывали, наверняка. Поделитесь ссылкой или новой историей?
Sign up to leave a comment.
Agile Board. Как мы планируем в Яндекс.Картинках и как к этому пришли