QA Fest — конференция №1 по тестированию и автоматизации. Финальная программа уже на сайте >>
×Закрыть

Kanban как основа для производства software

Привет! Я Сергей Алексеев, автор пяти, на мой взгляд, интересных статей из мира IT. В этой статье расскажу о Kanban с примерами и описанием. Это поможет вам внедрить методологию у себя или немного улучшить то, что есть у вас сейчас.

Предисловие

Задайте себе вопрос: по какой методологии или фреймворку мы ведем разработку программного обеспечения? Наверняка многие из вас ответят: Scrum. Это можно объяснить несколькими фактами:

  • Scrum у всех на слуху как в интернете, так и в офлайне. Kanban, Waterfall или другие подходы менее популярны.
  • Количество курсов по Scrum просто зашкаливает. Курсы не только об основах фреймворка, но и о разных ролях в нем, таких как Product Owner или Scrum Master. Их названия зачастую начинаются c «Как стать...», «Что делать...» или «Agile...». Зайдите, например, на scrum.ua, там о Kanban всего 2 курса.
  • Опрос среди аналитиков и проектных менеджеров в чате дал цифру в 34% в пользу Scrum. Опрос был проведен в апреле, тогда в чате было около 500 человек.

Убедил? А теперь задайте еще несколько вопросов себе или своему менеджеру:

  • Устраивает ли нас нынешний подход в разработке программного обеспечения?
  • Насколько эффективно работает наша команда? (О том, что я считаю эффективным, написано в другой моей статье.)
  • Выполняются ли поставленные задачи вовремя?

И так далее обо всем, что связано с метриками и процессами.

Давайте я немного расскажу о том, как я вижу картину мира, где есть 3 подхода в разработке software, и о том, для чего нужен каждый из них (мое скромное мнение):

  • Waterfall;
  • Scrum;
  • Kanban.

Конечно же, их больше, но пока что поговорим об этих.

НазваниеМое мнение
Waterfall

Видел и участвовал при внедрениях в госпроектах. Это были решения на разных платформах типа CRM, ERP от мощных поставщиков, таких как IBM, SAP, Microsoft.

Неприменим в текущих реалиях украинского IT-рынка и требований западных клиентов.

Особенность: каждый следующий этап SDLC не выполняется до тех пор, пока текущий этап не закончится и не сдастся под подпись.

Уже давно не встречал.
Scrum

Лучшее применение находит в случае, когда есть команда или несколько команд, которые работают только над одним проектом.

Например, у вас есть 2 и более полноценные команды, один Project Manager и один проект.

Пример состава команд:

  • FE — 2 FTE;
  • BE — 2 FTE;
  • QA — 1 FTE;
  • BA — 1 FTE.

Повышения производительности можно достичь при масштабировании количества команд и накоплении доменной экспертизы. Основной принцип — итерационность.

Kanban

Используется, когда нет определенного количества проектов: они то появляются, то исчезают. Есть более или менее стабильная команда. Соответственно, есть просто поток задач, которые необходимо сделать, основываясь на приоритетах проектов.

Приоритетом может служить дедлайн или негодование клиента.

Повышения производительности можно достичь увеличением пропускной способности сервиса (QA/BE/FE) или формированием скоупа для разработки с горизонтом 2–4 недели вперед.

Проблематика

Эту статью я начал писать не для того, чтобы рассказать примитивные вещи о Kanban. Наша команда столкнулась с разного рода задачами, и я хочу поделиться способом решения некоторых из них.

StakeholderПроблемаСтатус
МенеджментСдвиги в сроках по взаиморасчетам с клиентамиIn Progress
Отсутствие понимания соотношения выполняемых работ в проекте (BE/FE/CRZ/QA/BA)Done
Project ManagerНет понимания загрузки команды в цифрах. Есть понимание на уровне gut feeling и только на сегодняIn Progress
Отсутствие понимания готовности проекта в определенную точку времениDone
Все проекты сдаются не вовремяIn Progress
Команда разработкиНет четкого понимания процесса взаимодействия между участниками команды (кто, с кем, когда и что делает)Done
Нет понимания, какая разница между Task/Story/Sub-TaskDone
Нет понимания, какие задачи необходимо делать сегодня и каков план на завтраIn Progress
Плохо описаны или отсутствуют User StoryIn Progress
ПроблемаПричиныПричины второго уровняРешение
Нет четкого понимания процесса взаимодействия между участниками команды (кто, с кем, когда и что делает)Отсутствие лидера с видением процесса delivery Нанят лидер с таким видением и всеми полномочиями
Нет понимания, какая разница между Task/Story/Sub-TaskОтсутствие правил ведения backlog Была рассказана идея ведения backlog и надобности каждого типа в нем. Проведены воркшопы
Нет понимания, какие задачи необходимо делать сегодня и каков план на завтраОтсутствие утвержденного backlog с горизонтом хотя бы на неделю вперед

Проведены воркшопы с BA на тему утверждения User Story в кратчайшие сроки, а также удержания backlog-горизонта.

Были созданы Kanban-борды, которые позволяли видеть задачи в разных группировках:

  • by assignee;
  • by project
Плохо описаны User StoryНизкая квалификация BA Воркшопы/лекции/менторинг
Нет понимания загрузки команды в цифрах. Есть понимание на уровне gut feeling и только на сегодняОтсутствие созданных сабтасков.
Отсутствие плановых оценок в часах
Планирование в Tempo
Отсутствие понимания, насколько выполнен проект/релиз в определенную точку времениНет оцифрованных данных Ведение всех задач через сабтаски + настройка дашбордов в Jira
Все проекты сдаются не вовремяПлохое планированиеПлохое понимание доступности ресурсовПланирование в Tempo
Сдвиги в сроках по взаиморасчетам с клиентамиНесвоевременная сдача проектовПлохое планированиеПланирование в Tempo
Плохой контроль выполненияДашборды в Jira
Плохое понимание доступности ресурсов на период (неделя / две недели / месяц)Отчеты в Tempo
Несвоевременная оплата клиентамиОшибки персонала на стороне клиента...
Ошибки персонала на нашей стороне...
Отсутствие понимания соотношения выполняемых работ в проекте (BE/FE/CRZ/QA/BA)Нет оцифрованных данныхНикто не знал, как оцифровать данныеСоздана специальная структура в Jira, которая позволяет увидеть количество запланированных и затраченных ресурсов по каждому из видов работ (BE/FE/CRZ/QA/BA)

Конечно же, этот список проблем был сформирован спустя время в тот момент, когда я писал эту статью. В реальности задачи появлялись одна за одной по мере решения предыдущих.

Размышления

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

До 2019 года я работал в проектах двух типов: Waterfall и Scrum. Я думал, что так работают все и другого пути нет, но я ошибался. Ошибался не только в том, что нет другого пути, но и в том, что многие работают по Scrum. Я утверждаю это, потому что много общаюсь с ребятами из разных компаний, мы обсуждаем моменты взаимодействия между членами проекта, методики и принципы, по которым работают команды.

Пример. Часть людей, с которыми я пересекался, думали, что работают по Scrum, хотя на самом деле это был Kanban. Такая иллюзия была обусловлена тем, что они создавали тип проекта Scrum в Jira, помещали в активный спринт Story, Task, Sub-Task и никогда не закрывали этот спринт.

Когда я пришел в компанию, то все мои знания о Scrum и Waterfall не вкладывались в реальность, с которой я столкнулся. Мне срочно нужно было принять решение, как я буду делать delivery проектов, ибо состояние дел было примерно такое же, как у нас в государстве с медициной.

Проанализировав структуру моих проектов, состав команды и необходимость быть гибким, я четко осознал, что мне нужно идти по пути Kanban вместо Scrum.

Несколько недель все работало так, как до моего прихода. Я пытался вникнуть в то, что происходит, и проанализировать ситуацию. Я ничего не трогал, дабы не сломать :) Сидел вечером на работе и думал над тем, как бы решить эту задачу, вывести все в понятный и прозрачный процесс, где каждый понимает свою роль и происходящее вокруг. Я вспомнил, что совсем недавно читал вот эту статью, где ребята поделились своим подходом к организации процесса разработки. Мне понравилась идея с кросс-продуктовыми командами, где есть общие сервисы (Design/Dev/QA). Меня эта идея более чем устраивала, поскольку количество ресурсов было небольшим, а продуктами для меня были проекты. Я тоже решил привязаться к релизам и запустить работу по Kanban. В тот момент я практически ничего не знал о Kanban, кроме общих принципов, которые звучат следующим образом: To Do => In Progress => Done.

Мне пришлось немного поменять организационную структуру департамента, чтобы новые правила вступили в игру.

Новая организационная структура

Head of Department — формирование бюджета. Формирование delivery процессов в департаменте. Развитие существующих клиентов (up-sell и cross-sell), ответственность за прибыльность департамента. Отчетность напрямую владельцам компании.

PM — корректировка процессов delivery. Ответственность за соблюдение сроков реализации проектов. Планирование ресурсов. Участие в решении вопросов, которые требуют эскалации. Формирование понимания того, как будут идти процессы взаимодействия между клиентом и компанией (change management, payments, product shipment и т. д.).

Product Manager — ответственность за формирование скоупа продукта. Выполнение активностей в разрезе инициатив Sales & Marketing (например, рассылка писем участникам презентаций продуктов, встречи с клиентом при продаже). Ежедневная работа с командой. Видение и стратегия оставались на собственниках.

Pre-Sales BA — формирование коммерческого предложения клиенту на основе скоупа и оценки проекта. Коммуникация с клиентом до подписания контракта.

Account Manager — контроль над документооборотом (оформление контрактов, выставление счетов и закрытие актов). Коллаборация с проектным менеджером, чтобы понимать, когда и что будет сдано, для выставления счетов и корректировок в плане оплат.

Corezoid BA — ведение нескольких проектов с точки зрения формирования требований и написания документации. Управление ожиданиями клиента в разрезе функциональности, которую планируется реализовать. Имплементация автоматизации бизнес-логики с помощью специальной платформы Corezoid. Демонстрация выполненной функциональности клиенту.

BE Developer — каст заклинаний и магия. Пополнение маны из кофемашины.

FE Developer — каст заклинаний и магия. Пополнение маны из кофемашины.

QA — отдельный сервис по тестированию без привязки к конкретному проекту.

Почему я не выбрал Scrum?

Ответ для меня показался очевидным из-за разношерстности проектов, их дедлайнов и неопределенности. Основная неопределенность была в том, что я мог подписать проект продолжительностью 3 недели, который надо начинать делать уже сегодня, потому что клиент подвязан под публичное событие (например, фестиваль или рекламу на ТВ/YouTube). Такого рода задачи подразумевают гибкость в планировании и реализации.

Scrum подразумевает четкую итеративность и фиксированную функциональность в итерации. К сожалению, я не мог и пока не могу так делать — как минимум из-за небольшой продолжительности проектов (1–3 месяца) и, конечно же, из-за отсутствия возможности выделить отдельную команду под каждый проект.

Внедрение

Задача: оцифровать все, что происходит в департаменте, и объяснить команде правила игры.

Поскольку все проекты были связаны с чат-ботами, а их продолжительность была невелика, я принял решение не вести отдельный проект в Jira под каждый из них, а создать один проект под названием Chat Bots, в котором будут все проекты.

Мне необходимо было иметь стандартизированный процесс выполнения работ командой и общепринятые правила в разработке программного обеспечения. Первым делом я решил создавать минимальный процесс и настроить интерфейсы для работы команды. В глубине души я понимал, что ребята из команды Atlassian уже решили почти все мои боли, осталось только найти это решение и собрать все вместе, не нужно изобретать велосипед. Первым делом я пошел на официальные ресурсы Atlassian и почитал user guides по Jira и Tempo.

Проведя несколько десятков часов ресерча после работы, я понял, что рано или поздно мне понадобится информация, которую я планирую собирать в Jira. Я не спешил и хорошенько подумал над структурой, ведь это то, чем я занимался последние несколько лет в своей работе. Через несколько дней я придумал, как мне реализовать нужную мне структуру в Jira, которая позволит анализировать данные не только в конце проекта, но и в реальном времени.

После того как я все обдумал и создал проект в Jira, я попросил команду перенести информацию по всем проектам в эту структуру. Конечно же, изначально я рассказал ребятам, как это будет работать и зачем нужны такие усилия, и предоставил им инструкцию.

Ниже приведены примеры того, как выглядела информация изначально и на промежуточном этапе.

Вот так выглядела информация для принятия операционных решений вначале:

ПроектПроцент выполненияКомментарий
XXX50%Блокер-клиент
YYY70%Ждем интеграцию

Эта таблица не несла никакого смысла, кроме агрегирования всех проектов в одном месте. Процент выполнения проставлялся исключительно на калькуляциях и формулах в голове PM. Это очень субъективно и неправильно.

К слову, многие проектные менеджеры, которых я собеседовал, считают такие таблички нормальной реальностью.

А так выглядела информация до внедрения Jira и после таблицы в Excel

Эта доска была промежуточным этапом между Excel и Jira и прожила около 3 недель. Через 2 недели после ее создания я попросил команду перенести все в Jira и дал на это неделю. Через неделю информация была стерта с доски, и те, кто не успел перенести, заполняли пробелы из своей головы. И так наступила эра цифровизации.

Структура сущностей в JIRA

Entities relationship in Jira

Эта структура показывает зависимость между сущностями Jira внутри одного проекта. По факту у меня было 3 проекта.

  • Chat Bots — совокупность всех аутсорсинговых проектов, которые были проданы нашей командой.
  • Product — работы, выполняемые в разрезе будущего продукта, а также задачи типа R&D.
  • Administrative — поскольку я перестраивал процессы или выстраивал их с нуля, мне необходимо было отслеживать административные задачи и время на их выполнение. Примеры:
    • QA — формирование внутренней документации или настройка service desk.
    • Pre-Sales — понимание затраченного времени на каждый из этапов работы аналитиком в pre-sales-процессе.

Также хочу отметить, что все аналитики ведут свой backlog. Несмотря на то что все User Story находятся в одном проекте, функциональность Jira позволяет достаточно легко визуально разделять данные между людьми. Это возможно благодаря фильтрам.

Давайте перейдем к тому, почему же я все-таки решил строить отдельную структуру зависимостей и почему мне не хватило стандартной схемы. Вся структура была создана, чтобы корректно строить отчетность и понимать, куда потрачено время в конкретном разрезе времени. Те, кто строил WBS, поймут меня ;)

Project Type — позволяет разделить время (planned/fact) на уровне проекта:

  • product;
  • outsourcing.

Account
Эта сущность была создана, чтобы обозначать клиентов, по которым ведется работа. Потому что по одному клиенту могут быть разные проекты. Например, у одной компании проекты могут быть разбиты по брендам.

Component
Предназначены, чтобы описывать проект. У меня компонент — это название проекта. Соответственно, у одного аккаунта могут быть разные компоненты в один промежуток времени. Если бы вы вели проекты по Scrum, это были бы отдельные проекты в Jira. У меня это отдельные компоненты внутри одного проекта.

Fix Version
Используются, чтобы обозначать релизы в отдельных проектах (компонентах). В одном проекте может быть несколько версий. Соответственно, в одном проекте может быть несколько релизов. Они могут быть проданы как одним, так и разными контрактами, но это все равно будет один и тот же проект.

Task
Служит для фиксации времени, описания документации аналитиками или выполнения работы дизайнером.

Story
Является агрегатом бизнес-функциональности. Более подробно я рассказываю об этом в своем видео User Story canvas.

Sub-Task
Основная задача — аккумулирование времени — планируемого и фактического — на выполнение стори. Также сабтаски используются для выделения отдельных типов работ. Последнее время я делаю достаточно просто: у меня в стори создается всего несколько сабтасков (BE/FE/CRZ/QA/BA). Они аккумулируют время, потраченное на реализацию функциональности. Если ваша команда достаточно сплоченная, можно разбивать стори на более детальные сабтаски — так они будут давать более точные данные.

Tempo Time
Поскольку у меня есть приложение Tempo в Jira, в сабтасках есть возможность планирования и отслеживания времени их выполнения с использованием Tempo. Когда вы планируете сабтаски, задавая время и дату начала, Tempo автоматически показывает в календаре сабтаск по определенному сотруднику, учитывая выходные дни, количество рабочих часов и загрузку сотрудника в этот период.

Результаты

По моему мнению, этот раздел будет самым интересным в статье. Ниже приведены примеры из реальных проектов и команды.

Я начну показывать примеры полученного результата.

Tempo report — work time tracking

Этот отчет построен по структуре, которую я описывал выше в статье. Он позволяет выгрузить эту структуру в Excel с декомпозицией до сабтаска, в которых указано 3 параметра времени (Planned Estimate / Original Estimate / Remaining Estimate). Информация такого характера позволит вам рассчитать рентабельность вашего проекта почти в реальном времени, сравнить, почем продали и за сколько сделали, ну и еще много разных и полезных вещей.

Capacity report — planned time

Этот отчет позволяет увидеть загрузку не только каждого человека по отдельности, но и команды целиком. Желтым цветом выделены те места, где загрузка превышает 100%.

Capacity report — resource availability

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

Tempo — resource planning view

Это представление дает возможность визуально определить, кто из ваших коллег загружен более, чем нужно, а у кого есть время поиграть в теннис :) Более детально о том, как это работает, вы можете почитать в документации или же спросить у комьюнити в этом чате.

Tempo — resource planning timeline

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

Tempo — resource planning view (by person)

Так выглядит планирование одного человека, все это основано либо на реально созданных сабтасках в Jira или же на фейковых (плановых) задачах для человека.

Планирование и отслеживание прогресса по релизам

Так выглядит сейчас информация о прогрессе работы над релизом внутри проекта.

А вот так выглядят те же релизы, если их добавить на дашборд через гаджет.

А вот так выглядит релиз изнутри. То есть нажав на название релиза, вы можете попасть в его карточку и посмотреть, что конкретно реализовано, а что нет.

User Story card

Тут я вам хотел показать, как выглядят поля в самой Jira внутри User Story. Эти поля заполняются бизнес-аналитиком при создании, а все позже созданные сабтаски наследуют значения этих полей автоматически через автоматизацию Jira.

User Story flow

Sub-Task flow

Business Analyst view

Зеленым показаны User Story, в которых прописана бизнес-функциональность. Синим цветом показаны таски.

Developer view

Вот так вот выглядит view для разработчика.

Итоги

Я не могу сказать, что мы идеально или оптимально используем Kanban в нашей повседневной работе. Мы всего лишь перешли из каменного века в эпоху промышленной революции, но еще не дошли до информационной революции.

Нам еще многому стоит научиться и придется со многим столкнуться. Спустя 5 месяцев мы только начали придерживаться принципов, которые были внедрены. А еще нам предстоят анализ и оптимизация.

В Kanban есть много разных отчетов и показателей, основываясь на которых можно делать выводы и улучшать процесс, но на это нужно время.

Спасибо, что дочитали до конца.


Читайте также: Чому варто спробувати Kanban & Monday для організації робочого процесу

LinkedIn

34 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Хорошая, детальная статья с примерами и скриншотами. Но не про Канбан, к сожалению. Jira, Tempo, User story flow... это все нре о Канбане. Канбан — это визуализация потока, ограничение одновременно выполняемой работы, ее настройка, канбан-карточки и многое другое. Но не то, что приведено в статье.

Спасибо за комментарий.
Дмитрий, чтобы вы описали в статье про Канбан?
Поток карточек на доске, показан.
Планирование работы описано.
Понимание структуры работ описано.

Нет части про анализ потоков и ресурс. Но до этого я просто ещё не добрался :)

Распишите пожалуйста подробней.

Сергей, без обид, 90% статьи к Канбану отношения не имеют. Они очень классные и подробные, но это про то, как можно планировать проект.
Канбан — это про другое, про визуализацию потока задач, про настраивание этого потока, про устранение bottle neck’ов. А еще про WIP’ы и их влияние на пропускную способность системы, на Lead Time и Circle Time, про точки принятия коммитмента и многое другое. Вот об этом я бы и писал)

Согласен. Обид у меня быть не может :)
Сейчас я попытался донести, как сделать базу для того, чтобы потом получать аналитику, основываясь на который можно принимать решения.

Это второй шаг. Пока не дошёл к этому

Возможно, учитывая проведенный анализ, как второй шаг посмотреть в сторону lean? www.lean.org/WhatsLean Канбан — это один из lean методов достижения JIT.

Такая детальная статья мне очень понравилась. Критиковать не буду. Имееет право на жизнь, тем более, если проверен и работает подход.

Ну и спасибо еще раз за детализацию, многое отсюда можно позаимствовать и заюзать.

Часть людей, с которыми я пересекался, думали, что работают по Scrum, хотя на самом деле это был Kanban

а некоторые, напротив, думают что используют Kanban и даже пишут об этом статьи

Спасибо за комментарий.
Я так понимаю вы говорите обо мне?
Если да, подскажите пожалуйста в чем не соответствие или упущение?

в канбан доска — не цель, а инструмент
а применения самой методологии я в прочтенном и не вижу
P.S. вообще на родине канбана (в Японии, хоть lean manufacturing был изначально разработан и не японцами) его применяют только на крупносерийном производстве, а на мелкосерийном/штучном — используют другие методологии
поэтому уже изначально, канбан в разработке софта (то есть по сути, каждый раз уникального продукта) — это сова на глобусе, отражающая печальное состояние методологий в данной области

Возможно вы правы. Как бы вы поступили в моей ситуации и какие подходы использовали?
Буду благодарен за совет

Хороший пример, как организован процесс. Мои представления о скраме и канабане немного другие, но в любом случае, интересно было бы узнать результат, удалось ли решить проблемы описанные в самом начале или просто добавились новые 😉

Спасибо за комментарий.
Да, удалось решить ряд проблем, в той же табличке где они описаны и есть статус. Конечно же появились и новые :)

В целом, команда перешла в автономный режим работы, и люди знают чем они должны заниматься.
Для многих это будет удивлением, но как оказалось строить с нуля не так то уж и просто.

А Вы реально тикеты пишете на русском, как на скринах? Как по мне, то это первое, что Вам нужно улучшать

Спасибо. Да реально, потому что «тикеты» являются частью документации, которая потом идёт к клиенту. Поскольку клиент находится на пост советском пространстве и плохо владеет другими языками, нам приходится писать на русском или украинском языках.
Чтобы потом не тратить время на перевод.

Скажите, а как это влияет на продуктивность команды или на прибыль компании?

Ну, эта русско-английская смесь выглядит как минимум забавно) не смотрели в Вашем случае на полную локализацию джиры?

Интерфейс на английском. Контент на русском.
Я не вижу тут проблем. До тех пор пока это не снижает продуктивность или не приносит убытки

Так же, «тикеты» являются частью документации по выполненным работам, которая идёт в бухгалтерию и далее может быть проверенна налоговой.
Это для общего понимания полного процесса разработки ПО

Поправьте заголовок — Kanban как core для производства software

Just curios, что вы вкладываете в понятие Kanban, кроме того, что у вас тикеты движутся от первой к последней стадии на доске?

Спасибо за вопрос.
Глобально ничего нового, в этом же и идея Kanban, двигать сущность от начального пункта к конечному как можно быстрее.

Мой кейс в том, что проекты разные и непрогнозируемые. Я для себя нашел такой путь

Ідея канбана — це передусім limited work in progress. А двигать сущность — це про будь-яку методологію чи фреймворк.

В первую очередь, главной идеей был переход от «толкающего» принципа движения к «тянущему». Карточки и доска — просто метод визуализации.

Спасибо. Я не собираюсь спорить об этом :) Суть статьи в том, чтобы показать как из бумаги и экселя можно перейти в хорошие инструменты и наладить работу команды.

Мне хотелось дать краткую инструкцию о том, как люди могут делать это у себя на проектах.

Посмотрите на KMM (Kanban Maturity Model) — там есть идеи про то как вам дальше можно развиваться.

Спасибо, интересная статья. Немного резюмируя, plan-driven методологии, например, вотарфол, используются при низком уровне неопределенности требований, agile методологии, например, скрам и канбан, используются при высоком уровне неопределенности. Итеративная разработка отностися к plan-driven, не к аджайлу. Дешевле итерационно по вотерфолу, если все понятно, что делать, если не понятно, то решение — аджайл, чтобы понять и сделать. Если проекты небольшие и при возможности выделений явных целей каждого спринта — скрам, например. Если есть поток задач, которые можно, примерно, сделать равными по затрачиваемым силам, — например, канбан.

Спасибо. Что именно понравилось?)

Мне понравился качественный анализ и варианты решения вопросов оптимизации рабочего процесса в матричной структуре организации. :-) И конечно диджитализация средствами джиры, как альтернатива разработки собственного софта. Часто может показаться, что разработаем свой собственный софт под процесс и он решит все проблемы. Но проблема совсем не в отсутсвии уникального софта, их множество на рынке. Вы ищите варианты решений — это отлично.

Проще говоря, «тру аджайл» в аутсорс мире встречается только на пресейлах

Ой, по присейлу могу тоже рассказать интересных историй мешок :)

Подписаться на комментарии