Мы с коллегами периодически готовим короткие статьи для внутренних сотрудников компании, где я работаю, где разбираем различные случаи применения гибких подходов, в том числе случаи использования метода Канбан для улучшения и управления процессами.
Мы называем такие статьи «Agile-шортами».
И я подумал: «Почему бы не открыть мои статьи для более широкой аудиторииЭ» И сегодня я публикую свою первую статью из этой серии.
Сегодня я расскажу вам один из случаев, почему использование таких практик, как «Ограничение объема незавершенной работы» или WiP-лимитов, не дает результатов.
Оговорюсь, что это не единственная причина, но, в моей практике, она весьма распространена.
В будущих статьях я, возможно, раскрою эту тему дополнительными интересными ситуациями.
Мало кто из работающих в ИТ-сфере не слышал о гибких подходах к созданию продуктов.
Слова Agile, Kanban, Scrum уже прочно вошли в лексикон современных компаний.
Кто-то говорит их с гордостью, кто-то с иронией, а кто-то сквозь зубы.
Последние, вероятно, испытали на себе неудачное использование какого-либо инструмента управления и спроецировали свой негативный опыт на все будущие идеи.
Но эта заметка не для них.
Эта заметка для вас, тех, кто понимает, что инструменты можно использовать по-разному, и готов учиться на ошибках.
Ограничиваем пользовательские истории и работаем с подзадачами
Часто, познакомившись с основными практиками и методами, которые используются в Agile-культуре, у людей складывается впечатление, что, нажав Ctrl+C и Ctrl+V, они получат ту же чудесную вещь, которую они видели в кейсе.На деле получается, что «Ctrl+V» нужно аккуратно модифицировать файлом, как в анекдоте.
Визуализируя работу команды, неофиты часто совмещают на одном уровне задачи, ценные для Заказчика, с задачами, ценными только внутри процесса.
Почему, спросите вы, они объединяются? Главным образом потому, что они привыкли работать в парадигме – «Мне дали задание – я делаю задание – я выполнил задание», в которой для его выполнения не обязательно думать о ценности: «Ведь, начальник уже сам об этом подумал, раз дает задание работать».
В конце концов, на одном уровне управления Вы можете столкнуться со следующими задачами:
- «Сделать MVP продукта» — задача ценна для Заказчика, так как пользователь получит в руки что-то, чем сможет начать пользоваться.
- Проведение нагрузочного тестирования не является самостоятельной задачей, а требует выполнения какой-либо другой задачи.
- Заключение договора с поставщиком ХХХ не является самостоятельной задачей, а необходимо для начала работы над другой задачей.
- Реализовать функционал голосового ввода — пользователь получит новый функционал для использования.
Так вот, новички часто начинают использовать этот инструмент именно в таком контексте, что характерно для многих.
Ограничили, надеясь, что работа пойдет быстрее, но в итоге почему-то происходит обратное — работа застревает, все путаются.
Пример работы в такой системе: менеджер говорит, что задача «функция голосового ввода» приоритет задания «проведение нагрузочного тестирования» , поэтому первый берем в работу (включаем в лимит), а второй ждет. Но в какой-то момент становится понятно, что реализовать функционал без нагрузочного тестирования невозможно (конечно, это часть работы, которую нужно проделать для реализации функционала), задача заблокирована и ждет, когда мы начнем тестирование.
Но лимит полон! Как говорит нам теория, чтобы за что-то взяться, нужно сначала что-то завершить.
Текущий задача срочная , внимание переключается на что-то другое, и заказчик в итоге не получает никакого результата.
В итоге заказчик недоволен, сроки изготовления хуже, чем раньше - практика плохая, инструмент фигня.
Что делать, спросите вы? Ответ заключается в том, чтобы разделить разные уровни управления и понять, чтобы какую проблему мы решаем? .
Какие уровни:
- Работа на уровне выполнения задачи одним человеком.
- Чтобы снять перегрузку используются от сотрудника личные ограничения .
В этом случае мы рассматриваем взгляд исполнителя – задачи рассматриваются с точки зрения сотрудника, выполняющего работу.
- Чтобы снять перегрузку используются от сотрудника личные ограничения .
- Работа на уровне команды.
Для нормализации работы команды используются:- ограничения на система/команда/сервис (Отставание спринта — это частный случай системного ограничения)
- ограничения на тип задач (Цитаты)
- ограничения на этап (работаем с узкими горлами)
- и другие, более экзотические виды ограничений
Появляется такой объект, как узнаваемый Заказчиком товар – задание, глядя на которое, Заказчик понимает, что это именно то, что он заказал, и видит, что происходит с заказом.
- Работа на уровне портфолио.
- Для эффективного распределения ресурсов на реализацию портфеля инициатив используются лимиты.
для предметов портфолио .
- Для эффективного распределения ресурсов на реализацию портфеля инициатив используются лимиты.
Хотя, конечно, это уже вопрос маркетинговой стратегии.
Или на портфельных инициативах — сосредоточиться на скорости проверки гипотез и, в свою очередь, отобрать те, которые дадут нам конкурентное преимущество.
Подводя итог этой заметки, хотелось бы подчеркнуть три вещи, которые помогут вам избежать ошибок и получить положительный опыт:
- Постарайтесь понять, для чего нужен инструмент и в каком контексте он работает.
- Знайте проблему, которую хотите решить с помощью инструмента
- Если что-то не получается, считайте, что дело не в инструменте плохо, а в том, что вы что-то не учли
Теги: #Управление разработкой #Управление продуктом #agile #kanban #метод канбан #wip
-
Как Удалить Угонщик 9O0Gle.com
19 Oct, 24 -
Видео 2000 - Не Та Видеокассета
19 Oct, 24 -
Вопросы Илье Сегаловичу (Яндекс)
19 Oct, 24
