Сообщение Re[3]: Вопросы к тим лидам от 23.12.2016 0:15
Изменено 23.12.2016 0:16 Джеффри
Здравствуйте, Джеффри, Вы писали:
Д>(продолжение следует)
Напоследок некоторый общие замечания:
* Продумай стратегию релизов и тестирования. Очень хорошо, если получится релизить код на продакшн, после каждого спринта (например, каждые две недели). С одной стороны, это дисциплинирует команду. С другой стороны, это производит очень хорошее впечатление на заказчика. Соответственно, если вы даже зафейлите какой-то кусок функционала в одном спринте, то заказчик это воспримет спокойно, т.к. будет знать, что получить его через две недели.
* Старайся держать фокус команды. Кмк, лучше не распыляться на большое кол-во задач, а лучше всем навалиться на одну задачу и сделать ее сразу. Если в одном спринте команда будет перегружена, постарайся след. спринт сделать разгрузочным. Иначе люди быстро выгорят и не смогут поддерживать sustainable pace.
* Насчет CI/билдов/авто-тестов — обязательно продумай это с самого начала, потом по ходу дела это окупится стократ. У нас для этого дела была отдельная команда ДевОпс, если у вас такого не будет, то придется сделать самому. Но скорей всего, в компании уже будут какие-то стандартные инструменты — JIRA, Confluence, Git, Jenkinks, TeamCity, Nexus, Artifactory, SonarQube, etc. Обязательно настройте нормально интеграцию между всеми ними, чтобы например все комиты были привязаны к JIRA тикету и были видны в билдах и т.д.
* Насчет code review — сделай обязательным ревью при коммите в основной бранч и пусть люди в команде ревьювят код друг-друга.
Я сознательно опускаю моменты связанные со стартом проекта, т.к. не знаю на какой он стадии и что уже сделано, а что еще нужно сделать.
И в завершение насчет главного вопроса — "Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем". У меня нет на него четкого ответа, т.к. я сам постоянно сталкиваюсь с ситуациями, когда приходится прогибаться под заказчика (а что делать, если он деньги платит и музыку заказывает?). Но лично я бы попробовал в самом начале, как только начнут возникать такие ситуации сделать такой жесткий push back. Например, я был свидетелем, когда на одном проекте product owner тупил с бэклогом и планирование спринтов. На что тим лид, когда не было понятно какие бизнес нужны для очередного спринта, тупо сделал пустой спринт без единой задачи и написал письмо на всех, где просто указал, что спринт начался, задач нет, т.к. ПО ничего не сделал, команда девелоперов будет отдыхать. Казалось бы в такой ситуации, этого тим. лида должны были бы четвертовать, но нет. ПО всполошился, быстро набросал требований и в следующие спринты уже делал все вовремя и нормально взаимодействовал с командой.
Д>(продолжение следует)
Напоследок некоторый общие замечания:
* Продумай стратегию релизов и тестирования. Очень хорошо, если получится релизить код на продакшн, после каждого спринта (например, каждые две недели). С одной стороны, это дисциплинирует команду. С другой стороны, это производит очень хорошее впечатление на заказчика. Соответственно, если вы даже зафейлите какой-то кусок функционала в одном спринте, то заказчик это воспримет спокойно, т.к. будет знать, что получить его через две недели.
* Старайся держать фокус команды. Кмк, лучше не распыляться на большое кол-во задач, а лучше всем навалиться на одну задачу и сделать ее сразу. Если в одном спринте команда будет перегружена, постарайся след. спринт сделать разгрузочным. Иначе люди быстро выгорят и не смогут поддерживать sustainable pace.
* Насчет CI/билдов/авто-тестов — обязательно продумай это с самого начала, потом по ходу дела это окупится стократ. У нас для этого дела была отдельная команда ДевОпс, если у вас такого не будет, то придется сделать самому. Но скорей всего, в компании уже будут какие-то стандартные инструменты — JIRA, Confluence, Git, Jenkinks, TeamCity, Nexus, Artifactory, SonarQube, etc. Обязательно настройте нормально интеграцию между всеми ними, чтобы например все комиты были привязаны к JIRA тикету и были видны в билдах и т.д.
* Насчет code review — сделай обязательным ревью при коммите в основной бранч и пусть люди в команде ревьювят код друг-друга.
Я сознательно опускаю моменты связанные со стартом проекта, т.к. не знаю на какой он стадии и что уже сделано, а что еще нужно сделать.
И в завершение насчет главного вопроса — "Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем". У меня нет на него четкого ответа, т.к. я сам постоянно сталкиваюсь с ситуациями, когда приходится прогибаться под заказчика (а что делать, если он деньги платит и музыку заказывает?). Но лично я бы попробовал в самом начале, как только начнут возникать такие ситуации сделать такой жесткий push back. Например, я был свидетелем, когда на одном проекте product owner тупил с бэклогом и планирование спринтов. На что тим лид, когда не было понятно какие бизнес нужны для очередного спринта, тупо сделал пустой спринт без единой задачи и написал письмо на всех, где просто указал, что спринт начался, задач нет, т.к. ПО ничего не сделал, команда девелоперов будет отдыхать. Казалось бы в такой ситуации, этого тим. лида должны были бы четвертовать, но нет. ПО всполошился, быстро набросал требований и в следующие спринты уже делал все вовремя и нормально взаимодействовал с командой.
Re[3]: Вопросы к тим лидам
Здравствуйте, Джеффри, Вы писали:
Д>(продолжение следует)
Напоследок некоторый общие замечания:
* Продумай стратегию релизов и тестирования. Очень хорошо, если получится релизить код на продакшн, после каждого спринта (например, каждые две недели). С одной стороны, это дисциплинирует команду. С другой стороны, это производит очень хорошее впечатление на заказчика. Соответственно, если вы даже зафейлите какой-то кусок функционала в одном спринте, то заказчик это воспримет спокойно, т.к. будет знать, что получить его через две недели.
* Старайся держать фокус команды. Кмк, лучше не распыляться на большое кол-во задач, а лучше всем навалиться на одну задачу и сделать ее сразу. Если в одном спринте команда будет перегружена, постарайся след. спринт сделать разгрузочным. Иначе люди быстро выгорят и не смогут поддерживать sustainable pace.
* Насчет CI/билдов/авто-тестов — обязательно продумай это с самого начала, потом по ходу дела это окупится стократ. У нас для этого дела была отдельная команда ДевОпс, если у вас такого не будет, то придется сделать самому. Но скорей всего, в компании уже будут какие-то стандартные инструменты — JIRA, Confluence, Git, Jenkinks, TeamCity, Nexus, Artifactory, SonarQube, etc. Обязательно настройте нормально интеграцию между всеми ними, чтобы например все комиты были привязаны к JIRA тикету и были видны в билдах и т.д.
* Насчет code review — сделай обязательным ревью при коммите в основной бранч и пусть люди в команде ревьювят код друг-друга.
Я сознательно опускаю моменты связанные со стартом проекта, т.к. не знаю на какой он стадии и что уже сделано, а что еще нужно сделать.
И в завершение насчет главного вопроса — "Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем". У меня нет на него четкого ответа, т.к. я сам постоянно сталкиваюсь с ситуациями, когда приходится прогибаться под заказчика (а что делать, если он деньги платит и музыку заказывает?). Но лично я бы попробовал в самом начале, как только начнут возникать такие ситуации сделать такой жесткий push back. Например, я был свидетелем, когда на одном проекте product owner тупил с бэклогом и планированием спринтов. На что тим лид, когда не было понятно какие бизнес фичи нужны для очередного спринта, тупо сделал пустой спринт без единой задачи и написал письмо на всех, где просто указал, что спринт начался, задач нет, т.к. ПО ничего не сделал, команда девелоперов будет отдыхать. Казалось бы в такой ситуации, этого тим. лида должны были бы четвертовать, но нет. ПО всполошился, быстро набросал требований и в следующие спринты уже делал все вовремя и нормально взаимодействовал с командой.
Д>(продолжение следует)
Напоследок некоторый общие замечания:
* Продумай стратегию релизов и тестирования. Очень хорошо, если получится релизить код на продакшн, после каждого спринта (например, каждые две недели). С одной стороны, это дисциплинирует команду. С другой стороны, это производит очень хорошее впечатление на заказчика. Соответственно, если вы даже зафейлите какой-то кусок функционала в одном спринте, то заказчик это воспримет спокойно, т.к. будет знать, что получить его через две недели.
* Старайся держать фокус команды. Кмк, лучше не распыляться на большое кол-во задач, а лучше всем навалиться на одну задачу и сделать ее сразу. Если в одном спринте команда будет перегружена, постарайся след. спринт сделать разгрузочным. Иначе люди быстро выгорят и не смогут поддерживать sustainable pace.
* Насчет CI/билдов/авто-тестов — обязательно продумай это с самого начала, потом по ходу дела это окупится стократ. У нас для этого дела была отдельная команда ДевОпс, если у вас такого не будет, то придется сделать самому. Но скорей всего, в компании уже будут какие-то стандартные инструменты — JIRA, Confluence, Git, Jenkinks, TeamCity, Nexus, Artifactory, SonarQube, etc. Обязательно настройте нормально интеграцию между всеми ними, чтобы например все комиты были привязаны к JIRA тикету и были видны в билдах и т.д.
* Насчет code review — сделай обязательным ревью при коммите в основной бранч и пусть люди в команде ревьювят код друг-друга.
Я сознательно опускаю моменты связанные со стартом проекта, т.к. не знаю на какой он стадии и что уже сделано, а что еще нужно сделать.
И в завершение насчет главного вопроса — "Хотелось понять как не завернуть проект в сторону, что хочет заказчик — так и пляшем". У меня нет на него четкого ответа, т.к. я сам постоянно сталкиваюсь с ситуациями, когда приходится прогибаться под заказчика (а что делать, если он деньги платит и музыку заказывает?). Но лично я бы попробовал в самом начале, как только начнут возникать такие ситуации сделать такой жесткий push back. Например, я был свидетелем, когда на одном проекте product owner тупил с бэклогом и планированием спринтов. На что тим лид, когда не было понятно какие бизнес фичи нужны для очередного спринта, тупо сделал пустой спринт без единой задачи и написал письмо на всех, где просто указал, что спринт начался, задач нет, т.к. ПО ничего не сделал, команда девелоперов будет отдыхать. Казалось бы в такой ситуации, этого тим. лида должны были бы четвертовать, но нет. ПО всполошился, быстро набросал требований и в следующие спринты уже делал все вовремя и нормально взаимодействовал с командой.