Comments 28
Планирование, в классическом виде, как диаграмма Ганта в Agile нет, более того в Lean вообще есть только здесь и сейчас.
Управляемость — кем? Тут только команда разработчиков принимает решение без менеджеров.
Предсказуемость — смотря с чем сравнивать, а если смотреть на принцип «изменения приветствуются» — то, как можно что-то предсказать, если в Kanban нет понимания, что будет дальше — это известно только в миг, когда мы берем новую задачу, а в Scrum — есть набор задач на спринт, но это опять же только обязательства команды выдать какую-то ценность за фиксированный промежуток времени, чтобы им не мешали.
Agile — это про людей, все описанное, это просто выраженное словами нормальное продуктивное взаимодействие людей. И тут, как в программировании, либо пишешь свой велосипед или делаешь костыли, а можешь взять лучшие практики и готовое решение.
Про продуктивность, тут такой момент — если все работает и все устраивает — не трогай, а если проблемы, то для них есть решения.
Проблемы с которыми я сталкивался:
— зависимость команд Мобильного приложения и Бекенда
— команда не выпускает ничего, но работа кипит и все заняты делом
— заказчик не доволен и не понимает, что происходит
и т.д. Их можно решить самостоятельно с помощью «скотча», но есть люди, кто уже проходил подобный путь, у них уже есть красивые решения ими-то и нужно воспользоваться.
Agile — это люди.
Бюрократия это процедура.
Обязательный скрам, обязательные ретроспективы, на которых надо написать что понравилось, а что нет. После того, как напишешь, то, что понравилось, наклеят на доску и забудут, а для того, что не понравилось, будут искать решения. Ты так никогда и не поймёшь зачем ты выделял хорошие моменты. И ты не можешь не написать ничего, даже если тебя всё устраивает, потому что тогда ты не involved не proactive и тебе надо больше team spirit.
На планнинг покере надо давать оценки задачам о наличии которых ты вчера даже не подозревал, а сегодня знаешь только название и краткое описание из джиры, но устраниться от этого ты не можешь. Ибо если сказать, что в общем-то занимаешься другим и данную задачу оценивать не в состоянии, то не исключено, что тебе её и дадут, для улучшения bus factor и collective code ownership, а потом, когда ты будешь ковыряться с задачей раза в два дольше, чем человек, который в теме — сделают выговор за уменьшение velocity.
И, не дай бог программирования, после описанных выше событий ты скажешь, что agile это не весело и не exiting. Это значит, что ты inflexible, что у тебя low communication skills и возможно даже что ты не совсем client faced а греха выше нет и быть не может.
Это — тоже Agile
Что я тут могу спросить.
Можно ли пропустить скрам?
Можно ли не устраивать ретроспективу?
Можно ли на ретроспективе не говорить про хорошие моменты?
Можно ли устраниться из оценки непонятных тебе задач?
Можно ли не брать непонятные задачи?
Ну, если два человека хотят одну и ту же задачу, надо же как-то решать, чья она.
Некоторые задачи стоит, чтобы распределял тим-лид, некоторые просто брать из буфера.
У нас сейчас буфер разбирается по дням по очереди.
Без тим-лида в команде — это бред. :)
Если команда различается по компетенциям, то в начале спринта для улучшения планирования можно задачки разбрасывать на людей, которые все равно будут их делать (чтобы посмотреть, что они не перегружены). Задачи, которые может делать больше одного человека не назначаем.
Bus factor — отдельная история.
Agile — методологии создания продукта, методологии управления проектом, а не методологии разработки, не методологии проектирования, программирования и кодирования. Agile — это методологии контроля процесса разработки и управления им.
А об этом: «Вот это Agile. Вот это Lean.»
В таком же духе можно написать статьи «Вот это Водопад. Вот это Agile. Вот это Scrum. и т.п»
Редкая IT компания имеет инженерный подход к производству ПО. И вообще в текущих реалиях я бы даж на эту тему посморил, а надо ли это в принципе? Для большой компании возможно, хотя бы с сотнями разработчиков. Но это не будет ни Aglie ни Lean. В текущих реализях разработка ПО больше напоминает работу бригады мастеров, и инженерии тут на копейки, важно правильно подобрать людей в команду, а уж они потом договорятся и настроят процесс так как им надо.
В больших же компаниях именно инженерные процессы будут далеки от Agile потому, что при внесении изменений в core framework потребуется осознать кучу зависимостей и аджайл тикеты на доске в этом никак не помогут.
Аджайл в том числе как раз и об этом. Меньше управления, больше самоорганизации. Как бы такой ненавязчивый инструмент для помощи в самоорганизации. И работает это именно для маленьких команд или выделенных из больших команд маленьких рабочих групп (где члены команды «на одной волне»).
Сильная команда из ниоткуда — это несистемный подход. Как не потерять (при естественной смене людей время от времени) силу команды? Как сделать вторую сильную команду? Один из системных ответов на эти вопросы — Scrum. Это исключительно организационный фреймворк для формирования «сильных» команд.
Agile или Lean: Ага ага, какая разница-то?