Scrum & Jira. Ведение проектов. Как не прое... проект
HTML-код
- Опубликовано: 12 янв 2020
- Как настроить #Jira для начала ведения Scrum проекта. На примере заказа #разработки #блога описываю последовательность комуникации и сдачи проекта.
Jira дает возможность пользоваться #бесплатно до 10 членов в команде. Возможно это поможет именно тебе внедрить в компанию новые инструменты облегчающие ведение проектов.
Провал проекта в наше время это частое явление. И очень часто проект невозможно сдать по вине руководства IT компании, а не плохой идеи, как это принято считать в народе.
В своей практике я постоянно ищу пути для облегчения жизни всех членов команды, по этому на моем канале можно увидеть не одно видео позволяющее оптимизировать процессы в команде и в повседневной жизни.
Привет друзья. Меня зовут Максим, я начал свой путь в IT в 2014 году.
Преподавал в ХАИ аж 6 лет, почти что решился защищать кандидатску но IT меня сманило :)
Мой канал направлен на развитие IT, повышение качества разработчиков и упрощение начала карьеры в IT индустрии.
Люблю сложные решения, однако понимаю, чтобы давать сложные решения, нужно научить типовым :) Так что толи еще будет на моем канале
в linkedIn можно посмотреть чем я знимаюсь сегодня
/ maksym-grom-7b1098112
я в фесбуке (подписывайся)
/ maksym.grom
Также меня можно найти в твиттере
/ makym_grom
И телеграмм канале
t.me/webDevGromMaxChannel
Подписывайтесь на канал, рекомендуйте друзьям, ставьте лайки и пишите коменты. Давайте вместе делать мир лучше!
#ityoutubersru
![Rich Dunk (Ft. DaBaby) - BIG DAWG [Official Video]](http://i.ytimg.com/vi/Pz2ewsSKAEM/mqdefault.jpg)
Благодарю за труд! Понятное полное видео, лучшее вступительное видео по джире из тех что я видел
Спасибо) еще бы качество было бы выше) одно из моих первых видео на канале
@@grommaks Хорошие , качественое видео.
Крутяк. Всё понятно. Пасиб
Спасибо, за урок. Простота и наглядность с примером выполнения, пускай, базовых действий - то, что нужно !
Спасибо! лучшее видео по Jira из тех что я виделa. Очень помог.
От клиента (продакт овнера) проставляются приоритеты, чаще всего штуки три, не больше, а стори поинты - это уже оценка задачи от разработчика
Большое спасибо! Очень понятно, для общего ознакомления то, что нужно. Кому нужно дальше докапают, но важно иметь общее представление и не испугаться пока это представление получаешь, изучая неделю)
Спасибо за такой отзыв, приятно)
Спасибо за видео, всё просто и понятно.
Приятно слышать, спасибо за отзыв)
лучшее вступительное видео по джире из тех что я видел
Только начал смотреть, но уже интересно.
Конструктивно и по существу. Очень помог,
Благодарю!
Опыт техлидства моего проекта, первый проект который пытались сделать по скраму, дало хороший результат
Спасибо, за урок! (Scrum & Jira)
Молодец, спасибо. Хорошо рассказал!
Спасибо.) Отличное подробное видео.
Я, правда, все ждала, когда речь пойдет про board. Спринты, как я понимаю, никак не отображаются на этой доске?
@@sabelskaya хм...я же показал доску и спринты в этом видео и на примере показал 🙄 что именно хотелось услышать по спринтам и доске?)
@@grommaks тут она называется доска (board), а в русском варианте "дорожная карта". :) Мне важно было увидеть дорожную карту проекта и отчетности по производству. Но я уже разобралась сама. По сути, для моего случая, надо начинаться с эпиков с подзадачами, они тогда автоматом появляются в беглоге и их уже кидать в спринт. Тогда все чисто в процессе и можно на карте увидеть весь масштаб проекта.
@@sabelskaya Вас понял :)
Мы не делаем дорожную карту, но если ее делать, то создаются эпики с частями проекта и на дорожной карте выставляются сроки.
Во всем остальном ничего не меняется, кроме доп фильтров по эпикам и еще одним экраном в Jira
Единственное что подзадачи нельзя прикреплять к эпикам...получается что Story прикрепляются к Epic, а уже подзадача к Story...из подзадачи не видна прямая зависимость...но это нам не мешает :)
Спасибо за подробное объяснение.
Привет друзья :)
Пишите, как работать по Scrum получается в вашей команде?
Класс! Спасибо за видео! У меня возник вопрос, если при добавлении подзадач, они не появляются на доске, что делать?
Спасибо за видео
Не первый раз смотрю ваши видео. Все быстро, качественно и четко рассказываете. Спасибо вам большое.
Спасибо за крутой отзыв)
Спасибо! Было полезно
Спасибо!
Спасибо большое. У меня один вопрос: Что делать если был найден баг после выполнения задания ? возвращать задачу на бэклог или открывать новую задачу ?
Скрам подразумевает что задачи будут вылиты за 6-8 рабочих дней, протестированы и исправлены за оставшиеся 2-4 дня
Мы возвращали задачу если баг был найден на этапе тестирования или на этапе код ревью
Если задача уже была добавлена в релиз, то создавали новую как подзадачу к той же сторе
Если сторя была закрыта и спринт сдан, в случае если баг критический, то выливался хот фиксом, если не критический, то добавлялся в новый спринт и выливался через в конце следующего спринта
@@grommaks спасибо большое. Я попробовал на практике. Стало легче управлять проектом. Если не сложно, можете выпустить видео по составлению отчёта в jira ?
@@zafaryusupov9455 я занимался техлидством проекта, отчёт составлял не я, такого опыта к сожалению у меня нет 😔
Приятно знать что на практике получилось улучшить работу команды
Сейчас бы стори поинты измерять в часах...
Увы, но большинство так и делает
Класс, спасибо за крутое видео, с первых секунд уже нравится!
Спасибо большое
Максим, спасибо. Очень полезно. Подскажите есть ли у вас лайфхак как планировать на пол года - год вперед при помощи scrum? Я могу предположить, что просто на будущее делать более крупные стори для примерной оценки и по мере продвижения уточняться и либо двигать сроки / либо сокращать функционал. Просто у нас зачастую надо заранее закомититься на конкретные сроки через пол года, а scrum больше про продуктовую разработку где за счет итераций идет улучшение продукта, и планирование корректируется по ходу дела.
Вам нужно почитать SAFe 5.0 там описано все что нужно по скраму для больших и очень больших корпораций, ну и для маленьких тоже.
Так вот, там есть такие артефакты
1) Эпик - очень большой скоуп (объем) задач
2) Фичи - большой скоуп задач
3) Стори - то что влезит в спринт
Так вот. Нам заходит проект или огромный проект, мы можем его разбить на эпики, это прям поверхностно и оценка там гигантская
Если есть больше понимания, то можем разбить эпики на фичи, одна фича это 5-6 спринтов не более, так называемая итерация разработки. Фичи уже можно оценить условно десятками, а иногда сотнями стори поинтов
P.S. Стори поинт это по SAFe 5.0 это один день работы или 4 часа разработки и 4 часа тестирования
Вот сейчас работаю с Azure DevOps доской, а не с Jira, в Jira по идее есть те же самые артефакты
Добрый день.
Очень ждал примера, когда к концу спринта какая-то сторя не была полностью завершена.
Сторипоинты используются ещё для планирования, когда команда уже научилась достаточно качественно оценивать, чтобы потом, исходя из скорости работы команды(сколько сторипоинтов успевает сделать в спринте) можно было бы понять, когда завершиться проект.
Так вот, что делать со сторипоинтами стори, которую пришлось перенести в следующий спринт? Нужно как то оценить сколько осталось и внести изменения в тикет? Или же это делается как-то по другому?
Добрый день, стори должна быть атомарная как правило
И она либо закрывается либо не закрывается, если не закрывается то переносится полностью
А вот как не испортить скорость сдачи сторипоинтов, тут нужно подумать, интересный вопрос
Супер, спасибо. Понял из урока наконец то как надо отмечать потраченое время выполнения). И очень полезный совет что не зависать с одной задачей а делать каждую по чуть чуть
Автор, ошибочка: правильнее не СЕО, а SEO - search engine optimization )
Спасибо за видео!
Записывать на одном кадре не правильно :)
Спасибо за исправление
1) Был ли у вас опыт использования плагинов для просмотра списка задач в древовидном представлении. Спринт -> Эпик -> Задача -> Подзадача. Т.к. обычно все задачи свалены в кучу...
2) есть ли какой-то плагин связанный с учетом рабочего времени, который дает более удобный интерфейс для использования?
Нажал кнопку - время пошло
Нажал кнопку - время остановилось
Сейчас приходится открывать форму - вписывать значения и т.д....
1) если смотреть на задачи как спринт, или как бэклог то задачи структурированы по типам
По другому не приходилось работать с задачами чтобы получить более удобное отображение
2) Jira у нас на проекте настраивалась не мной, но была кнопка старта учета времени и остановки трекинга. Прямо на странице задачи. Так что 100% плагин существует, но я не знаю какой)
@@grommaks Спасибо за овтет.
звук очень тихий
Story ponts - совсем не про важность
Действительно...
Я примешал Story Pont роль Business Value
Story Points - усилия которые нужны для достижения этой задачи...
Business Value - насколько ценно изменение для бизнеса
И наиболее интересная метрика для понимания отношения трудозатрат к полученным результатам = BV / SP
Самое толковое описание, которое встречала. Спасибо
Есть некоторые неточности, но в комментариях мне на них указали)
Сейчас работаю по скраму и для больших фирм эта схема гораздо сложнее, но для описанного мой проекта по этой схеме очень комфортно работать всем) в видео пример из реального проекта, который длился 8 месяцев с командой из 5 человек
печально, начиналось так хорошо, но Стори Поинты - это единица измерения оценки общих усилий, которые потребуются для полной реализации элемента незавершенной работы по продукту или любой другой работы. а не важность...
Спасибо за дополнение
согласна с вами! Мы планируем в аспро agile и там тоже ставим сторипоинты у задачек, чтобы оценить их трудозатраты
Всё круто, но говоришь ооочень тихо!
Вот твоя основная точка роста :)
А ещё в оригинальном Scrum стори-поинты читаются по числам Фибоначчи, и они относительны, это важно понимать.
@@user-bv6dv6jd4f согласен) в реальной разработке пока не встречал где строи поинты не считали бы в часах типа 1 к 4 например
На описании сторипрйнтов пропало желание смотреть дальше. Или скрам из названия уберите или нормально рассказывайте, не путая людей.
Засыпаю
Почему не использовал проект нового поколения ?
У нас Jira уже давно я использовал то с чем работал, но надо бы проанализировать разницу между проектами
Про Epic ничего. Для чего они?
Слева есть вкладка Epics. Если будет создан эпик и к нему можно будет присоеденить Story задачи. То можно будет видеть прогресс по Epic задаче.
Мы разрабатываем E-Comerce решения. По этому имеем несколько Epics
- Catalog
- User Account
- Checkout
- ERP (Это интеграции с клиентской системой)
В случае очень большого функционала мы создаем новый Epic и к нему крепим все Story которые имеют отношения к этому функционалу
Этот подход мы применили после того как я записал это видео.
Однако, этот подход используется только для визуального облегчения и ни как не помогает делать спринты или делать отчеты о затраченных часах.
@@grommaks Спасибо. Т.о. Epic появляется в случае большого единого функционала полученного из нескольких сторей? Или даже для одна сторя может создать эпик? Тогда как правильно действовать далее - делать таски уже для эпиков или попрежнему сабтаски к сторям? Плюс как я понимаю эпики теперь полезны и для некст-ген проектов джира, для построения роадмапов.
@@felixivideo Удобно когда вопросы нумеруются :) Если вы общаетесь с клиентом, то обязательно нумеруйте вопросы, если планируете пойти в разработку, то сильно поможете ПМу правильно получать ответы от клиентов :)
1) Т.о. Epic появляется в случае большого единого функционала полученного из нескольких сторей?
Мы используем именно так.
В Scrum разрабоке проекта это дает видение какие задачи какую часть сайта меняют (или фичу)
Еще мы используем для разработку модулей которые будут переиспользованы между несколькими проектами.
Мы поддерживаем 15+ магазинов, так что это необходимость
2) Или даже для одна сторя может создать эпик?
Story это тип задач именно для Scrum подхода. Только этот тип задач имеет параметр StoryPoints. Если вы разрабатываете по Scrum, то да, Story.
3) Тогда как правильно действовать далее - делать таски уже для эпиков или попрежнему сабтаски к сторям?
Если разработка ведется по Kanban или ScrumBan то тут можно выбирать задачи любого типа, или даже не использовать подзадачи.
Есть важная рекомендация. Команда должна получать облегчение труда, а не усложнение труда в результате таких разбивок.
Определите приорететы, если два подхода вредят разрабам, но помогают ПМу...кем можно пожертвовать...или если есть подход хорош для всех, то берите его.
Анализируйте полученный опыт и решайте как вашей команде лучше
4) Плюс как я понимаю эпики теперь полезны и для некст-ген проектов джира, для построения роадмапов.
Мы пока таким не пользуемся, как будет опыт, я сниму отдельное видео :)
Как я говорил ранее, мы используем эпики для общих модулей.
Потому что эпики позволяют собирать задачи с разных проектов, и отдельный модуль, это всеже не отдельный проект...а отдельная фича.
@@grommaks По нумерации принято. Спасибо. 3) переформулирую - в Вашем видео понятно изложены цели и связи стори (бизнес запрос) и сабтасков (тех задача). Но если добавляется сущность эпик, к которой линкуются стори его формирующие, то в дальнейшем куда бы линковали задачи на разработку - как таски в эпик, или так же как в видео сабтаски к стори? 4) как бы вы сейчас строили роадмапы (jira server), если бы возникла такая необходимость?
@@felixivideo
3) Если подход такой как я описал в видео, то однозначно Story + Sub Tasks
В Scrum эпик это что-то не объятное...
Если ведется разработка enterprise приложения, то возможен сценарий где Epic = Отдел...
Если по DDD - то Epic это один домен ( что соизмеримо с Отделом или одним бизнес процессом из примера на строчку выше)
А все запросы = Story. Почему так. Проще сдавать, проще аакумулировать оценку, точно есть место где нужно хранить оригинальные требвования клиентов, и есть не маловажный параметр - Story Point (при условии что вы имеете доступ к клиенту, то можно использовать его правильно)
Важно (Story) должен быть достаточно маленькой задачей чтобы вместиться в Sprint или максимум в 2 спринта...возможно с привлечением нескольких разработчиков
4) Roadmap в Jira строится только с помощью Epic (возможно я не знаю всех настроек, сложно сказать)
Если бы я вел бы проект и отвечал за сроки по частям проекта, то:
Согласовал бы с клиентом набор фич или разделов софта которые можно сдать и запустить в работу
Самое главное что можно запустить как новая рабочая система (например интеграция продуктов в магазин)
Определил бы с клиентом желаемую дату сдачи в roadmap для эпика
Определил бы с клиентом, что ему хотелось бы видеть в этм эпике
- импорт продуктов
- импорт картинок продуктов
- импорт цен
- импорт количества на складу
- импорт композитных продуктов
Каждый Story должен иметь оценку по времени и желаемый приоретет (очередность)
В результате имеем время сколько нужно, сроки, осталось вычислить есть ли столько ресурсов в команде.
Вот так несколько эпиков согласовать и распределить нагрузку в команду.
После этого, как я говорил в видео, техлид + ПМ могут разбивать стори на подзадачи и распределять часы
Класс
Ничего не слышно только, а так супер
Диз за "самое время подписаться" и "давай давай подписывайся". Если контент интересен, человек и так подпишется. Или ты думаешь, что после слов "давай давай подписывайся" подпишутся даже те, кому это не надо?
Ваше право 🥺
за "вот этот Вася поставил лайк"...дизлайк тебе, научись уважать Вась!
Спасибо!
Спасибо!