Комментарии 18
Дожили — методологию сравнивают с практикой.
Для большинства ошибок лечится установкой четких критериев серьезности ошибки
— Critical — все валится, система не работает в принципе
— High — система работает, но невозможно использовать основную функциональность (основная функциональность должна быть перечислена отдельно) — пользователь не может сделать покупку, положить в корзину и т.п.
— Low — ошибки, с которыми можно жить, сделать нужную операцию другим способом, некрасивости и т.п.
— Medium — всё остальное.
«Правильные» тестировщики находят много «правильных» багов, и это все попадает в очередь программистам. Если эти баги не проверять и оставлять в основной очереди задач, то скоро вы обнаружите, что программисты заняты какой-то неважной ерундой. Поэтому в команде обязательно должен быть человек, а лучше несколько, которые понимают, какие баги критичны, а какие должны отправиться в неопределенное будущее, в Someday.
Для большинства ошибок лечится установкой четких критериев серьезности ошибки
— Critical — все валится, система не работает в принципе
— High — система работает, но невозможно использовать основную функциональность (основная функциональность должна быть перечислена отдельно) — пользователь не может сделать покупку, положить в корзину и т.п.
— Low — ошибки, с которыми можно жить, сделать нужную операцию другим способом, некрасивости и т.п.
— Medium — всё остальное.
И как обычно, из Agile манифеста потеряли главную фразу… «Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.»
Скрам не исключает постоянную доставку фич и багфиксов, а канбан их не подразумевает.
А вообще частая ошибка (не здесь) аджайл, водопад и т.д. и подобные называть принципами и методологиями разработки. Они про управление разработкой, они для менеджеров, а не для разработчиков.
А вообще частая ошибка (не здесь) аджайл, водопад и т.д. и подобные называть принципами и методологиями разработки. Они про управление разработкой, они для менеджеров, а не для разработчиков.
Какую бы из Agile-методологий вы не выбрали, вы можете качественно реализовать ее с помощью платформы для управления проектами Hygger.io.
Если у аналитиков платформы такой же поверхностный уровень понимания scrum и kanban, как оно изложено в статье, то я сильно сомневаюсь в качестве реализации.
Можно привести хоть какие-нибудь преимущества по сравнению с JIRA + Agile add-on?
Основное отличие от Jira в том, что Jira заточена под разработку ПО и основная ЦА — это программисты, QA и project managers.
Hygger — софт для product management. Для продуктовых команд, в которых разработка начинается с вижна и стратегии:
— нужна стратегия и roadmap
— нужен actionable план для выполнения выбранной стратегии
— нужно собрать идеи от клиентов и структурировать их
— нужно приоритезировать идеи и разбить их на релизы
— нужно держать в курсе маркетинг, продажи, саппорт относительно выхода новых билдов/версий
— нужно отправить отобранные идеи в разработку и мониторить прогресс их выполнения
Этот блок называется Strategy.
И потом уже отправить таски в программинг в спринты или в Канбан. Это — execution. Сейчас в Hygger есть своя разработка — есть и Scrum и Kanban, который ни в чем не уступает Jira. Но скоро мы сделаем интеграцию с Jira и те команды, которые уже «сидят плотно» на Jira, смогут использовать Hygger для product management.
Чем Hygger отличается от Jira — наличием функционала для работы со strategy — Roadmap и Backlog доски.
Подробнее про отличия можно прочитать вот тут.
Hygger — софт для product management. Для продуктовых команд, в которых разработка начинается с вижна и стратегии:
— нужна стратегия и roadmap
— нужен actionable план для выполнения выбранной стратегии
— нужно собрать идеи от клиентов и структурировать их
— нужно приоритезировать идеи и разбить их на релизы
— нужно держать в курсе маркетинг, продажи, саппорт относительно выхода новых билдов/версий
— нужно отправить отобранные идеи в разработку и мониторить прогресс их выполнения
Этот блок называется Strategy.
И потом уже отправить таски в программинг в спринты или в Канбан. Это — execution. Сейчас в Hygger есть своя разработка — есть и Scrum и Kanban, который ни в чем не уступает Jira. Но скоро мы сделаем интеграцию с Jira и те команды, которые уже «сидят плотно» на Jira, смогут использовать Hygger для product management.
Чем Hygger отличается от Jira — наличием функционала для работы со strategy — Roadmap и Backlog доски.
Подробнее про отличия можно прочитать вот тут.
А как решается проблема с параллельной работой над «задачей»?
Пример:
Разработчик закончил задачу и передал ее сразу в 3 подразделения:
1. Тестирование
2. Документирование
3. Code review
В релиз задача уйдет когда будут выполнены п1 и п2.
На п3 она останется пока специалист занимающийся «Code review» не просмотрит ее.
Пример:
Разработчик закончил задачу и передал ее сразу в 3 подразделения:
1. Тестирование
2. Документирование
3. Code review
В релиз задача уйдет когда будут выполнены п1 и п2.
На п3 она останется пока специалист занимающийся «Code review» не просмотрит ее.
Интересно — 9 месяцев — это некропостинг? Просто глаз зацепился за вопрос без ответа.
Тут всё просто. Задача не может параллельно быть на тестировании, документировании и CodeReview.
Логика очень проста.
Девелопер закончил работу над таской.
До CodeReview её нельзя передавать в тестирование, так как результаты CodeReview могут привести к необходимости полной переделки результатов разработки, и тестировщикам придётся начинать тестирование с самого начала.
На документирование такую таску тем более нельзя отправлять — тестировщик обнаружит некий кейс, который был не учтён при разработке, а документация по функционалу уже пишется. Техрайтеру придётся переделывать описание, скриншоты и прочее.
Поэтому порядок простой: Разработка -> Ревью -> Тестирование -> Документация. И никакой параллельности между стадиями.
Тут всё просто. Задача не может параллельно быть на тестировании, документировании и CodeReview.
Логика очень проста.
Девелопер закончил работу над таской.
До CodeReview её нельзя передавать в тестирование, так как результаты CodeReview могут привести к необходимости полной переделки результатов разработки, и тестировщикам придётся начинать тестирование с самого начала.
На документирование такую таску тем более нельзя отправлять — тестировщик обнаружит некий кейс, который был не учтён при разработке, а документация по функционалу уже пишется. Техрайтеру придётся переделывать описание, скриншоты и прочее.
Поэтому порядок простой: Разработка -> Ревью -> Тестирование -> Документация. И никакой параллельности между стадиями.
Есть ряд вопросов, будет интересно узнать.
Как задачи появляются в вашем бэклоге? Как обеспеичвается постоянный поток новых задач?
Как соблюдается баланс между новыми фичами и правкой багов?
И, наконец, статья — это Ваш реальный опыт по проекту или просто обзор? На скриншотах все доски разные просто, вот и сомнения гложут.
Как задачи появляются в вашем бэклоге? Как обеспеичвается постоянный поток новых задач?
Как соблюдается баланс между новыми фичами и правкой багов?
И, наконец, статья — это Ваш реальный опыт по проекту или просто обзор? На скриншотах все доски разные просто, вот и сомнения гложут.
Как задачи появляются в вашем бэклоге? Как обеспеичвается постоянный поток новых задач?Мы используем Zendesk.com и Intercom.com для сбора обратной связи от наших пользователей. Скоро сделаем плагин для Hygger, который позволит автоматически отправлять запросы из этих систем в Hygger. А пока наш саппорт менеджер вручную переносит идеи и предложения от пользователей в Hygger на backlog-доску.
Также мы постоянно генерируем новые гипотезы роста для увеличения различных показателей. Мы используем AARRR метрики для этого.
Анализ конкурентов, чтение статей, книг, юзабилити-тестирование — все это тоже помогает генерировать новые идеи — их мы также заносим на backlog доску. И далее уже мы приоритезируем эти идеи. Более подробно процесс работы с бэклогом я описал в отдельной статье.
Как соблюдается баланс между новыми фичами и правкой багов?Если баг блокирует работу пользователей — правим его в реальном времени. Остальное все попадает в бэклог и ранжируется наряду с новыми фичами и доработками.
И, наконец, статья — это Ваш реальный опыт по проекту или просто обзор? На скриншотах все доски разные просто, вот и сомнения гложут.Опыт реальный, а на скриншотах — доски из демо-компании, которая доступна всем, кто регистрируется в Hygger.
Статья интересная.
Если разобраться, то Kanban как метод разрабатывался для решения задач в машиностроительном производстве, и только потом он был перенесен на задачи разработки ПО. Соответственно он больше подходит для проектов с большим количеством разработчиков.
Scrum же изначально был заточен для задач разработки ПО и он более гибок для этих целей, и подходит для проектов с командами разных масштабов, начиная с малых.
Если разобраться, то Kanban как метод разрабатывался для решения задач в машиностроительном производстве, и только потом он был перенесен на задачи разработки ПО. Соответственно он больше подходит для проектов с большим количеством разработчиков.
Scrum же изначально был заточен для задач разработки ПО и он более гибок для этих целей, и подходит для проектов с командами разных масштабов, начиная с малых.
Не буду вступать в долгие дискуссии про термины и чужое понимание принципов (на мой взгляд заблуждений полно и в статье и в комментариях).
У меня практический вопрос: Lead Time Distribution Chart, Run Chart, Cumulative Flow Diagram планируется внедрить как фичу? Хотя бы CFD, ибо без него Канбан не особо полезен для анализа и постоянного улучшения.
У меня практический вопрос: Lead Time Distribution Chart, Run Chart, Cumulative Flow Diagram планируется внедрить как фичу? Хотя бы CFD, ибо без него Канбан не особо полезен для анализа и постоянного улучшения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scrum vs Kanban: в чем разница и что выбрать?