Сообщение Re[2]: Вопросы к тим лидам от 22.12.2016 23:47
Изменено 23.12.2016 0:46 Джеффри
Здравствуйте, Джеффри, Вы писали:
Д>(продолжение следует)
Дальше по ролям:
* Насколько я помню, в теории, на скрам-проекте может не быть тим. лида, но должен присутствовать скрам-мастер, который будет следить за соблюдением процесса. Либо может быть и лид, и скрам-мастер. Мне лично, последний вариант не нравится, т.к. он приводит к некоему двоевластию и иногда конфликтам. Поэтому я предпочитаю брать на себя роль скрам-мастера. Но нужно всегда помнить, что одна из задач СМ — это защищать свою команду от заказчика и не прогибаться под него во вред людям. Поэтому если тим-лид склонен соглашаться с ПО, бывает полезно иметь отдельного СМ, который может сказать "нет".
* Далее по выделенным ролям — хорошо иметь бизнес-аналитика, который будет экспертом в предметной области и сможет лучше доносить требования ПО до девелоперов. Также хорошо иметь своих QA тестировщиков в команде (и заодно учить их автоматизации).
* Что касается девелоперов, как я уже писал выше, мне нравится работать с full-stack разработчиками, если это возможно.
Насчет митингов. На мой взгляд, главное здесь, чтобы их было как можно меньше. Не знаю, как у других, но в нашей компании, работа тим-лида — это какой-то митинг-ад. Поэтому я стараюсь по максимуму реджектить митинги, не перегружать ими команду (в этом случае, пусть лучше один человек целый день просидит на митингах, чем вся команда пол-дня) и делать их как можно короче. Из того что необходимо на мой взгляд (внутри команды) по скраму:
* Дейли-стэндап. Каждый говорит быстро, кратко, по сути, без отвлечений. Если нужно что-то обсудить — обсуждается лицом-к-лицу сразу после стэндапа. На мой взгляд, тим-лид должен во время стэндапа убедиться, что люди действительно двигаются по задачам спринта и не отвлекаются на что-то постороннее (burndown chart). Кстати, тут было обсуждение темы мироменеджмента, так вот, на мой взгляд, в отношении мидлов и синьоров — небольшой "пуш" вполне допустим и даже полезен. Т.к. позволяет держать их в тонусе и показывает, что то что они делают действительно важно кому-то еще.
* Ретроспектива. Я лично обожаю этот митинг, лично мой опыт показывает, что он позволяет очень круто снизить напряжение/конфликты в команде и в то же время очень способствует вовлечению людей в работу. Классический формат — Что было хорошо / Что было плохо / Что улучшить — на мой взгляд, самое то.
* Планирование. Опять таки, в теории, ПО заполняет бэклог задач и определяет их приоритеты. Во время планирования, команда собирается берет задачи по приоритетам и оценивает их. В моей практике, я все же использую более директивный подход, когда я просматриваю задачи сам, примерно представляю кто их будет делать и сколько это займет. А потом во время планированию уже веду дискуссию с командой. Мне кажется, здесь важно не только набрать задач, но и дать команде понять куда двигается проект в целом, т.е. показать как каждая сторя ложиться на план проекта. И, конечно, мотивация — "ну, надо братцы. вам не надо, мне надо". Также важно не допускать, чтобы спринт перегружался задачами. В моей практике, девелоперы очень часто бывают оптимистичными в оценке и наборе задач. Здесь, мне кажется, лучше взять меньше и сделать все хорошо, а потом добраться из бэклога. Чем набрать много задач, а потом их из скопа выбрасывать. Хотя второй способ иногда позволяет сделать больше, но происходит это чаще всего в ущерб качеству. Простейший инструмент здесь — это sprint velocity.
* Демо митинги. У меня они всегда очень скомканными получаются, но такая специфика системы, что она просто делает расчеты, которые сложно нормально продемонстрировать. Но тем не менее митинг полезный, т.к. позволяет держать всех в курсе изменений.
И пара слов насчет коммуникации с заказчиком. Правильная коммуникация — здесь критически важна. Я видел проекты, у которых был отвратительный менеджмент и постоянные фейлы с деливери, но они были на хорошем счету у клиентов, т.к. на той стороне был какой-нибудь ПМ, который каждый день ходил обедать с заказчиком и просто разговаривал с ним. И точно также я видел проекты, где все было более-менее ок, но они были на плохом счету, т.к. интроверт-тимлид ни с кем не разговаривал. Так что если у тебя скилл общения не очень (особенно на английском, что может быть естественно), найди кого-нибудь кто будет постоянно в контакте с людьми с той стороны.
И, кстати, вообще культурные особенности на таких проекта бывают очень важны. Если там будет русский/украинец, то считай повезло. Если будет какой-нибудь индус, подумай, как нормально выстроить с ним общение.
(продолжение следует)
Д>(продолжение следует)
Дальше по ролям:
* Насколько я помню, в теории, на скрам-проекте может не быть тим. лида, но должен присутствовать скрам-мастер, который будет следить за соблюдением процесса. Либо может быть и лид, и скрам-мастер. Мне лично, последний вариант не нравится, т.к. он приводит к некоему двоевластию и иногда конфликтам. Поэтому я предпочитаю брать на себя роль скрам-мастера. Но нужно всегда помнить, что одна из задач СМ — это защищать свою команду от заказчика и не прогибаться под него во вред людям. Поэтому если тим-лид склонен соглашаться с ПО, бывает полезно иметь отдельного СМ, который может сказать "нет".
* Далее по выделенным ролям — хорошо иметь бизнес-аналитика, который будет экспертом в предметной области и сможет лучше доносить требования ПО до девелоперов. Также хорошо иметь своих QA тестировщиков в команде (и заодно учить их автоматизации).
* Что касается девелоперов, как я уже писал выше, мне нравится работать с full-stack разработчиками, если это возможно.
Насчет митингов. На мой взгляд, главное здесь, чтобы их было как можно меньше. Не знаю, как у других, но в нашей компании, работа тим-лида — это какой-то митинг-ад. Поэтому я стараюсь по максимуму реджектить митинги, не перегружать ими команду (в этом случае, пусть лучше один человек целый день просидит на митингах, чем вся команда пол-дня) и делать их как можно короче. Из того что необходимо на мой взгляд (внутри команды) по скраму:
* Дейли-стэндап. Каждый говорит быстро, кратко, по сути, без отвлечений. Если нужно что-то обсудить — обсуждается лицом-к-лицу сразу после стэндапа. На мой взгляд, тим-лид должен во время стэндапа убедиться, что люди действительно двигаются по задачам спринта и не отвлекаются на что-то постороннее (burndown chart). Кстати, тут было обсуждение темы мироменеджмента, так вот, на мой взгляд, в отношении мидлов и синьоров — небольшой "пуш" вполне допустим и даже полезен. Т.к. позволяет держать их в тонусе и показывает, что то что они делают действительно важно кому-то еще.
* Ретроспектива. Я лично обожаю этот митинг, лично мой опыт показывает, что он позволяет очень круто снизить напряжение/конфликты в команде и в то же время очень способствует вовлечению людей в работу. Классический формат — Что было хорошо / Что было плохо / Что улучшить — на мой взгляд, самое то.
* Планирование. Опять таки, в теории, ПО заполняет бэклог задач и определяет их приоритеты. Во время планирования, команда собирается берет задачи по приоритетам и оценивает их. В моей практике, я все же использую более директивный подход, когда я просматриваю задачи сам, примерно представляю кто их будет делать и сколько это займет. А потом во время планированию уже веду дискуссию с командой. Мне кажется, здесь важно не только набрать задач, но и дать команде понять куда двигается проект в целом, т.е. показать как каждая сторя ложиться на план проекта. И, конечно, мотивация — "ну, надо братцы. вам не надо, мне надо". Также важно не допускать, чтобы спринт перегружался задачами. В моей практике, девелоперы очень часто бывают оптимистичными в оценке и наборе задач. Здесь, мне кажется, лучше взять меньше и сделать все хорошо, а потом добраться из бэклога. Чем набрать много задач, а потом их из скопа выбрасывать. Хотя второй способ иногда позволяет сделать больше, но происходит это чаще всего в ущерб качеству. Простейший инструмент здесь — это sprint velocity.
* Демо митинги. У меня они всегда очень скомканными получаются, но такая специфика системы, что она просто делает расчеты, которые сложно нормально продемонстрировать. Но тем не менее митинг полезный, т.к. позволяет держать всех в курсе изменений.
И пара слов насчет коммуникации с заказчиком. Правильная коммуникация — здесь критически важна. Я видел проекты, у которых был отвратительный менеджмент и постоянные фейлы с деливери, но они были на хорошем счету у клиентов, т.к. на той стороне был какой-нибудь ПМ, который каждый день ходил обедать с заказчиком и просто разговаривал с ним. И точно также я видел проекты, где все было более-менее ок, но они были на плохом счету, т.к. интроверт-тимлид ни с кем не разговаривал. Так что если у тебя скилл общения не очень (особенно на английском, что может быть естественно), найди кого-нибудь кто будет постоянно в контакте с людьми с той стороны.
И, кстати, вообще культурные особенности на таких проекта бывают очень важны. Если там будет русский/украинец, то считай повезло. Если будет какой-нибудь индус, подумай, как нормально выстроить с ним общение.
(продолжение следует)
Re[2]: Вопросы к тим лидам
Здравствуйте, Джеффри, Вы писали:
Д>(продолжение следует)
Дальше по ролям:
* Насколько я помню, в теории, на скрам-проекте может не быть тим. лида, но должен присутствовать скрам-мастер, который будет следить за соблюдением процесса. Либо может быть и лид, и скрам-мастер. Мне лично, последний вариант не нравится, т.к. он приводит к некоему двоевластию и иногда конфликтам. Поэтому я предпочитаю брать на себя роль скрам-мастера. Но нужно всегда помнить, что одна из задач СМ — это защищать свою команду от заказчика и не прогибаться под него во вред людям. Поэтому если тим-лид склонен соглашаться с ПО, бывает полезно иметь отдельного СМ, который может сказать "нет".
* Далее по выделенным ролям — хорошо иметь бизнес-аналитика, который будет экспертом в предметной области и сможет лучше доносить требования ПО до девелоперов. Также хорошо иметь своих QA тестировщиков в команде (и заодно учить их автоматизации).
* Что касается девелоперов, как я уже писал выше, мне нравится работать с full-stack разработчиками, если это возможно.
Насчет митингов. На мой взгляд, главное здесь, чтобы их было как можно меньше. Не знаю, как у других, но в нашей компании, работа тим-лида — это какой-то митинг-ад. Поэтому я стараюсь по максимуму реджектить митинги, не перегружать ими команду (в этом случае, пусть лучше один человек целый день просидит на митингах, чем вся команда пол-дня) и делать их как можно короче. Из того что необходимо на мой взгляд (внутри команды) по скраму:
* Дейли-стэндап. Каждый говорит быстро, кратко, по сути, без отвлечений. Если нужно что-то обсудить — обсуждается лицом-к-лицу сразу после стэндапа. На мой взгляд, тим-лид должен во время стэндапа убедиться, что люди действительно двигаются по задачам спринта и не отвлекаются на что-то постороннее (burndown chart). Кстати, тут было обсуждение темы мироменеджмента, так вот, на мой взгляд, в отношении мидлов и синьоров — небольшой "пуш" вполне допустим и даже полезен. Т.к. позволяет держать их в тонусе и показывает, что то что они делают действительно важно кому-то еще.
* Ретроспектива. Я лично обожаю этот митинг, лично мой опыт показывает, что он позволяет очень круто снизить напряжение/конфликты в команде и в то же время очень способствует вовлечению людей в работу. Классический формат — Что было хорошо / Что было плохо / Что улучшить — на мой взгляд, самое то.
* Планирование. Опять таки, в теории, ПО заполняет бэклог задач и определяет их приоритеты. Во время планирования, команда собирается берет задачи по приоритетам и оценивает их. В моей практике, я все же использую более директивный подход, когда я просматриваю задачи сам, примерно представляю кто их будет делать и сколько это займет. А потом во время планированию уже веду дискуссию с командой. Мне кажется, здесь важно не только набрать задач, но и дать команде понять куда двигается проект в целом, т.е. показать как каждая сторя ложиться на план проекта. И, конечно, мотивация — "ну, надо братцы. вам не надо, мне надо". Также важно не допускать, чтобы спринт перегружался задачами. В моей практике, девелоперы очень часто бывают оптимистичными в оценке и наборе задач. Здесь, мне кажется, лучше взять меньше и сделать все хорошо, а потом добраться из бэклога. Чем набрать много задач, а потом их из скопа выбрасывать. Хотя второй способ иногда позволяет сделать больше, но происходит это чаще всего в ущерб качеству. Простейший инструмент здесь — это sprint velocity.
* Демо митинги. У меня они всегда очень скомканными получаются, но такая специфика системы, что она просто делает расчеты, которые сложно нормально продемонстрировать. Но тем не менее митинг полезный, т.к. позволяет держать всех в курсе изменений.
* Периодические бэклог груминги. Я их предпочитаю делать сам или вместе с ПО. Вообще, на мой взгляд, очень важно держать бэклог в хорошем состоянии и прививать команде правильную JIRA-культуру.
И пара слов насчет коммуникации с заказчиком. Правильная коммуникация — здесь критически важна. Я видел проекты, у которых был отвратительный менеджмент и постоянные фейлы с деливери, но они были на хорошем счету у клиентов, т.к. на той стороне был какой-нибудь ПМ, который каждый день ходил обедать с заказчиком и просто разговаривал с ним. И точно также я видел проекты, где все было более-менее ок, но они были на плохом счету, т.к. интроверт-тимлид ни с кем не разговаривал. Так что если у тебя скилл общения не очень (особенно на английском, что может быть естественно), найди кого-нибудь кто будет постоянно в контакте с людьми с той стороны.
И, кстати, вообще культурные особенности на таких проекта бывают очень важны. Если там будет русский/украинец, то считай повезло. Если будет какой-нибудь индус, подумай, как нормально выстроить с ним общение.
(продолжение следует)
Д>(продолжение следует)
Дальше по ролям:
* Насколько я помню, в теории, на скрам-проекте может не быть тим. лида, но должен присутствовать скрам-мастер, который будет следить за соблюдением процесса. Либо может быть и лид, и скрам-мастер. Мне лично, последний вариант не нравится, т.к. он приводит к некоему двоевластию и иногда конфликтам. Поэтому я предпочитаю брать на себя роль скрам-мастера. Но нужно всегда помнить, что одна из задач СМ — это защищать свою команду от заказчика и не прогибаться под него во вред людям. Поэтому если тим-лид склонен соглашаться с ПО, бывает полезно иметь отдельного СМ, который может сказать "нет".
* Далее по выделенным ролям — хорошо иметь бизнес-аналитика, который будет экспертом в предметной области и сможет лучше доносить требования ПО до девелоперов. Также хорошо иметь своих QA тестировщиков в команде (и заодно учить их автоматизации).
* Что касается девелоперов, как я уже писал выше, мне нравится работать с full-stack разработчиками, если это возможно.
Насчет митингов. На мой взгляд, главное здесь, чтобы их было как можно меньше. Не знаю, как у других, но в нашей компании, работа тим-лида — это какой-то митинг-ад. Поэтому я стараюсь по максимуму реджектить митинги, не перегружать ими команду (в этом случае, пусть лучше один человек целый день просидит на митингах, чем вся команда пол-дня) и делать их как можно короче. Из того что необходимо на мой взгляд (внутри команды) по скраму:
* Дейли-стэндап. Каждый говорит быстро, кратко, по сути, без отвлечений. Если нужно что-то обсудить — обсуждается лицом-к-лицу сразу после стэндапа. На мой взгляд, тим-лид должен во время стэндапа убедиться, что люди действительно двигаются по задачам спринта и не отвлекаются на что-то постороннее (burndown chart). Кстати, тут было обсуждение темы мироменеджмента, так вот, на мой взгляд, в отношении мидлов и синьоров — небольшой "пуш" вполне допустим и даже полезен. Т.к. позволяет держать их в тонусе и показывает, что то что они делают действительно важно кому-то еще.
* Ретроспектива. Я лично обожаю этот митинг, лично мой опыт показывает, что он позволяет очень круто снизить напряжение/конфликты в команде и в то же время очень способствует вовлечению людей в работу. Классический формат — Что было хорошо / Что было плохо / Что улучшить — на мой взгляд, самое то.
* Планирование. Опять таки, в теории, ПО заполняет бэклог задач и определяет их приоритеты. Во время планирования, команда собирается берет задачи по приоритетам и оценивает их. В моей практике, я все же использую более директивный подход, когда я просматриваю задачи сам, примерно представляю кто их будет делать и сколько это займет. А потом во время планированию уже веду дискуссию с командой. Мне кажется, здесь важно не только набрать задач, но и дать команде понять куда двигается проект в целом, т.е. показать как каждая сторя ложиться на план проекта. И, конечно, мотивация — "ну, надо братцы. вам не надо, мне надо". Также важно не допускать, чтобы спринт перегружался задачами. В моей практике, девелоперы очень часто бывают оптимистичными в оценке и наборе задач. Здесь, мне кажется, лучше взять меньше и сделать все хорошо, а потом добраться из бэклога. Чем набрать много задач, а потом их из скопа выбрасывать. Хотя второй способ иногда позволяет сделать больше, но происходит это чаще всего в ущерб качеству. Простейший инструмент здесь — это sprint velocity.
* Демо митинги. У меня они всегда очень скомканными получаются, но такая специфика системы, что она просто делает расчеты, которые сложно нормально продемонстрировать. Но тем не менее митинг полезный, т.к. позволяет держать всех в курсе изменений.
* Периодические бэклог груминги. Я их предпочитаю делать сам или вместе с ПО. Вообще, на мой взгляд, очень важно держать бэклог в хорошем состоянии и прививать команде правильную JIRA-культуру.
И пара слов насчет коммуникации с заказчиком. Правильная коммуникация — здесь критически важна. Я видел проекты, у которых был отвратительный менеджмент и постоянные фейлы с деливери, но они были на хорошем счету у клиентов, т.к. на той стороне был какой-нибудь ПМ, который каждый день ходил обедать с заказчиком и просто разговаривал с ним. И точно также я видел проекты, где все было более-менее ок, но они были на плохом счету, т.к. интроверт-тимлид ни с кем не разговаривал. Так что если у тебя скилл общения не очень (особенно на английском, что может быть естественно), найди кого-нибудь кто будет постоянно в контакте с людьми с той стороны.
И, кстати, вообще культурные особенности на таких проекта бывают очень важны. Если там будет русский/украинец, то считай повезло. Если будет какой-нибудь индус, подумай, как нормально выстроить с ним общение.
(продолжение следует)