Про взаимодействие разработчиков внутри команды
Каждое утро наша команда собирается и каждый рассказывает, что делал вчера и что будет делать сегодня. Один разработчик провел эксперимент: на дейли он говорил не связанные по смыслу вещи. Из 10 человек заметили двое. Возникает резонный вопрос: если друг друга никто не слушает, зачем это нужно?
...
Когда-то я сходил на оффлайновые тогда еще тренинги по скраму, и стал повсюду в работе видеть неидеальность процессов. Я хотел построить коллаборацию, совместное принятие решений и работу в команде. Но каждый раз в попытке приблизиться к этому идеальному миру, что-то ломалось и случался диссонанс. Так происходило потому что работа разработчиков была скорее индивидуальной, а не общей. Не было объединяющей цели спринта.
Потом пришло понимание, что совместная работа не особо нужна, если в спринте 10 разных задач, не объединенных общей целью. Зачем на дейли вникать в работу коллеги, если у самого и так голова от своей задачи пухнет? Да и помочь вроде бы особо не можешь: погружаться в контекст дольше. Какой тогда смысл от дейли? Вот и получается, что все говорят в формате отчетности, что вчера делали и что сегодня будут. А кому эта отчетность нужна — непонятно. Вроде бы и так все взрослые люди и потребности в контроле нет.
Стали просить продакта больших амбициозных задач. Таких, чтобы можно было распараллелить работу и сделать командой значительно больше, чем мог бы сделать один. С одной стороны, это как будто подстраивание продукта под фреймворк и пожелания разработчиков. С другой стороны, кайфа от работы стало в разы больше, и полезных штук делать мы стали больше.
Попробую объяснить, почему большая общая задача решает проблему коммуникации внутри команды.
Сначала большой эпик нужно декомпозировать на такие этапы, чтобы каждый спринт был инкремент для пользователя. Потом этап нарезается в бэклог спринта. В идеале распараллелить доработку компонентов так, чтобы все были при деле. И потом интегрировать результат работы друг друга, сшивая компоненты. Чтобы нормально интегрироваться, нужно понимать, что там коллега разрабатывает.
Когда есть общая цель и предстоит интегрироваться с работой товарища, становится интересно, что там у него происходит. Причем иногда настолько, что вся инфа уже есть до дейли. Тогда вопрос, а нафига говорить, что делал вчера и что будешь делать сегодня, если все и так знают, потому что вчера вечером созванивались?
...
Мой идеал дейли — когда все и так знают, кто чего делает, а на дейли приходят, чтобы задать друг другу простой вопрос:
"Мы успеваем по цели спринта?"
Каждое утро наша команда собирается и каждый рассказывает, что делал вчера и что будет делать сегодня. Один разработчик провел эксперимент: на дейли он говорил не связанные по смыслу вещи. Из 10 человек заметили двое. Возникает резонный вопрос: если друг друга никто не слушает, зачем это нужно?
...
Когда-то я сходил на оффлайновые тогда еще тренинги по скраму, и стал повсюду в работе видеть неидеальность процессов. Я хотел построить коллаборацию, совместное принятие решений и работу в команде. Но каждый раз в попытке приблизиться к этому идеальному миру, что-то ломалось и случался диссонанс. Так происходило потому что работа разработчиков была скорее индивидуальной, а не общей. Не было объединяющей цели спринта.
Потом пришло понимание, что совместная работа не особо нужна, если в спринте 10 разных задач, не объединенных общей целью. Зачем на дейли вникать в работу коллеги, если у самого и так голова от своей задачи пухнет? Да и помочь вроде бы особо не можешь: погружаться в контекст дольше. Какой тогда смысл от дейли? Вот и получается, что все говорят в формате отчетности, что вчера делали и что сегодня будут. А кому эта отчетность нужна — непонятно. Вроде бы и так все взрослые люди и потребности в контроле нет.
Стали просить продакта больших амбициозных задач. Таких, чтобы можно было распараллелить работу и сделать командой значительно больше, чем мог бы сделать один. С одной стороны, это как будто подстраивание продукта под фреймворк и пожелания разработчиков. С другой стороны, кайфа от работы стало в разы больше, и полезных штук делать мы стали больше.
Попробую объяснить, почему большая общая задача решает проблему коммуникации внутри команды.
Сначала большой эпик нужно декомпозировать на такие этапы, чтобы каждый спринт был инкремент для пользователя. Потом этап нарезается в бэклог спринта. В идеале распараллелить доработку компонентов так, чтобы все были при деле. И потом интегрировать результат работы друг друга, сшивая компоненты. Чтобы нормально интегрироваться, нужно понимать, что там коллега разрабатывает.
Когда есть общая цель и предстоит интегрироваться с работой товарища, становится интересно, что там у него происходит. Причем иногда настолько, что вся инфа уже есть до дейли. Тогда вопрос, а нафига говорить, что делал вчера и что будешь делать сегодня, если все и так знают, потому что вчера вечером созванивались?
...
Мой идеал дейли — когда все и так знают, кто чего делает, а на дейли приходят, чтобы задать друг другу простой вопрос:
"Мы успеваем по цели спринта?"