Comments 17
Дожили — методологию сравнивают с практикой.

«Правильные» тестировщики находят много «правильных» багов, и это все попадает в очередь программистам. Если эти баги не проверять и оставлять в основной очереди задач, то скоро вы обнаружите, что программисты заняты какой-то неважной ерундой. Поэтому в команде обязательно должен быть человек, а лучше несколько, которые понимают, какие баги критичны, а какие должны отправиться в неопределенное будущее, в Someday.


Для большинства ошибок лечится установкой четких критериев серьезности ошибки
— Critical — все валится, система не работает в принципе
— High — система работает, но невозможно использовать основную функциональность (основная функциональность должна быть перечислена отдельно) — пользователь не может сделать покупку, положить в корзину и т.п.
— Low — ошибки, с которыми можно жить, сделать нужную операцию другим способом, некрасивости и т.п.
— Medium — всё остальное.
Но вот любят несмотря на все регламенты некоторые люди нереализованную возможность создавать список из 50 пунктов автоматически вместо ручного подбора в critical закинуть. Или баг требующий в систему перезайти для исправления. Понятно что утрирую немного, но в целом бывает такое не так уж редко.
В нашем случае такое случилось ровно после того, как руководство ввело KPI тестировщикам, в котором найденные High приносили больше денег, чем Medium.
И как обычно, из Agile манифеста потеряли главную фразу… «Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.»
Скрам не исключает постоянную доставку фич и багфиксов, а канбан их не подразумевает.

А вообще частая ошибка (не здесь) аджайл, водопад и т.д. и подобные называть принципами и методологиями разработки. Они про управление разработкой, они для менеджеров, а не для разработчиков.
А можно подробнее про методологии разработки, которые не связаны с управлением или моделью процесса разработки?

Различные *DD не про управление разработкой, роли менеджера в них нет.

*DD обычно называют техниками или подходами, но не принципами или методологиями.
Какую бы из 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 доски.

Подробнее про отличия можно прочитать вот тут.
А как решается проблема с параллельной работой над «задачей»?

Пример:
Разработчик закончил задачу и передал ее сразу в 3 подразделения:
1. Тестирование
2. Документирование
3. Code review

В релиз задача уйдет когда будут выполнены п1 и п2.
На п3 она останется пока специалист занимающийся «Code review» не просмотрит ее.
Интересно — 9 месяцев — это некропостинг? Просто глаз зацепился за вопрос без ответа.
Тут всё просто. Задача не может параллельно быть на тестировании, документировании и CodeReview.
Логика очень проста.
Девелопер закончил работу над таской.
До CodeReview её нельзя передавать в тестирование, так как результаты CodeReview могут привести к необходимости полной переделки результатов разработки, и тестировщикам придётся начинать тестирование с самого начала.
На документирование такую таску тем более нельзя отправлять — тестировщик обнаружит некий кейс, который был не учтён при разработке, а документация по функционалу уже пишется. Техрайтеру придётся переделывать описание, скриншоты и прочее.
Поэтому порядок простой: Разработка -> Ревью -> Тестирование -> Документация. И никакой параллельности между стадиями.
Есть ряд вопросов, будет интересно узнать.
Как задачи появляются в вашем бэклоге? Как обеспеичвается постоянный поток новых задач?
Как соблюдается баланс между новыми фичами и правкой багов?
И, наконец, статья — это Ваш реальный опыт по проекту или просто обзор? На скриншотах все доски разные просто, вот и сомнения гложут.

Как задачи появляются в вашем бэклоге? Как обеспеичвается постоянный поток новых задач?
Мы используем Zendesk.com и Intercom.com для сбора обратной связи от наших пользователей. Скоро сделаем плагин для Hygger, который позволит автоматически отправлять запросы из этих систем в Hygger. А пока наш саппорт менеджер вручную переносит идеи и предложения от пользователей в Hygger на backlog-доску.

Также мы постоянно генерируем новые гипотезы роста для увеличения различных показателей. Мы используем AARRR метрики для этого.

Анализ конкурентов, чтение статей, книг, юзабилити-тестирование — все это тоже помогает генерировать новые идеи — их мы также заносим на backlog доску. И далее уже мы приоритезируем эти идеи. Более подробно процесс работы с бэклогом я описал в отдельной статье.

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

И, наконец, статья — это Ваш реальный опыт по проекту или просто обзор? На скриншотах все доски разные просто, вот и сомнения гложут.
Опыт реальный, а на скриншотах — доски из демо-компании, которая доступна всем, кто регистрируется в Hygger.
Статья интересная.
Если разобраться, то Kanban как метод разрабатывался для решения задач в машиностроительном производстве, и только потом он был перенесен на задачи разработки ПО. Соответственно он больше подходит для проектов с большим количеством разработчиков.
Scrum же изначально был заточен для задач разработки ПО и он более гибок для этих целей, и подходит для проектов с командами разных масштабов, начиная с малых.
Не буду вступать в долгие дискуссии про термины и чужое понимание принципов (на мой взгляд заблуждений полно и в статье и в комментариях).
У меня практический вопрос: Lead Time Distribution Chart, Run Chart, Cumulative Flow Diagram планируется внедрить как фичу? Хотя бы CFD, ибо без него Канбан не особо полезен для анализа и постоянного улучшения.
Only those users with full accounts are able to leave comments. Log in, please.