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