Недавно Фил Ранжин написал в твиттере тредик, что мол все аджайл-практики и книги по ним - говно, и только мудрый руководитель на опыте может всё разрулить.
Естественно, без опыта руководства всё пойдет по пизде. Но и на одной практике далеко не уедешь. Классическая поговорка "Теория без практики - мертва, практика без теории - слепа" работает и в менеджменте. Я наблюдал такую картину не раз: когда опытные умные люди не могли справиться с хаосом.
Я согласен, что куча аджайл-практик - говно, а уж книги и подавно, но всё же далеко не все. Опишу то, что реально работает в нашей команде. Буквально в двух словах, чтобы не получилась очередная говнокнига.
Отсюда главная мысль: не давать большому количеству задач застревать в разработке.
Без грамотной разбивки задач на стадии, и без визуализации этой картины проще сдохнуть, чем управлять.
Если при работе над крупной доработкой продукта взаимодействуют сразу несколько команд, и у каждой команды свой цикл разработки, свой проект в жире и т.д. (что часто бывает при микросервисной архитектуре), нужно заводить отдельную доску под эту мега-задачу, чтобы суммарно понимать, что вообще происходит. Без этого - капец.
Также нужны диаграммы, показывающие, сколько времени занимает разработка задач в тех отделе. Если существенная часть в % задач висит месяцами, то звиздец. Долгая задача не просто расход, она может уже потерять бизнес-актуальность, то есть дохода никогда не принести!!!
Это может быть блокировка между командами (фронтенд ждет бекенд, бекенд ждет, когда отдуплятся админы, а админы заняты другой задачей). Это может быть блок внутри команды. Банально - задача долго-долго ожидает код-ревью, а когда код-ревью уже завершилось, то всё поросло конфликтами с рефакторингом из другой задачи.
Тут же автоматически напрашивается главная аджайл-практика. Вводить ограничение на количество задач в каждой из стадий. Например, в стадии написании кода может быть только x задач, на код ревью y задач, в тестировании z задач. x, y и z настраиваются опытным путем, с небольшим запасом на всякий случай. Потому что нет смысла делать 10 задач в неделю, если есть стадия тестирования, которая справляется лишь с двумя. Чем меньше задач в работе, тем меньше они друг друга блочат. Чем меньше задач в работе, тем яснее картина: понятно, что именно делать, чтобы протолкнуть зависшее.
Кстати, практика гугла по код ревью: если есть чего ревьювить, то ревьювить важнее чем делать свою (новую) задачу.
Естественно, без опыта руководства всё пойдет по пизде. Но и на одной практике далеко не уедешь. Классическая поговорка "Теория без практики - мертва, практика без теории - слепа" работает и в менеджменте. Я наблюдал такую картину не раз: когда опытные умные люди не могли справиться с хаосом.
Я согласен, что куча аджайл-практик - говно, а уж книги и подавно, но всё же далеко не все. Опишу то, что реально работает в нашей команде. Буквально в двух словах, чтобы не получилась очередная говнокнига.
Отсюда главная мысль: не давать большому количеству задач застревать в разработке.
Без грамотной разбивки задач на стадии, и без визуализации этой картины проще сдохнуть, чем управлять.
Если при работе над крупной доработкой продукта взаимодействуют сразу несколько команд, и у каждой команды свой цикл разработки, свой проект в жире и т.д. (что часто бывает при микросервисной архитектуре), нужно заводить отдельную доску под эту мега-задачу, чтобы суммарно понимать, что вообще происходит. Без этого - капец.
Также нужны диаграммы, показывающие, сколько времени занимает разработка задач в тех отделе. Если существенная часть в % задач висит месяцами, то звиздец. Долгая задача не просто расход, она может уже потерять бизнес-актуальность, то есть дохода никогда не принести!!!
Это может быть блокировка между командами (фронтенд ждет бекенд, бекенд ждет, когда отдуплятся админы, а админы заняты другой задачей). Это может быть блок внутри команды. Банально - задача долго-долго ожидает код-ревью, а когда код-ревью уже завершилось, то всё поросло конфликтами с рефакторингом из другой задачи.
Тут же автоматически напрашивается главная аджайл-практика. Вводить ограничение на количество задач в каждой из стадий. Например, в стадии написании кода может быть только x задач, на код ревью y задач, в тестировании z задач. x, y и z настраиваются опытным путем, с небольшим запасом на всякий случай. Потому что нет смысла делать 10 задач в неделю, если есть стадия тестирования, которая справляется лишь с двумя. Чем меньше задач в работе, тем меньше они друг друга блочат. Чем меньше задач в работе, тем яснее картина: понятно, что именно делать, чтобы протолкнуть зависшее.
Кстати, практика гугла по код ревью: если есть чего ревьювить, то ревьювить важнее чем делать свою (новую) задачу.