Комментарии 28
Могли бы вы написать про набор, связку и последовательность внедрения программных продуктов для работы по Scrum в вашей команде кратко в пару строчек? С комментариями. Почему это или то, если возможно, применительно к вашей команде.
Пример: PM + Git + тестирование…
Пример: PM + Git + тестирование…
Про программные продукты у нас все довольно стандартно:
Bitbucket использовали с самого начала, выбрали его из-за цены и удобства, через какое-то время начали использовать JIRA для ведения бэклога. С началом внедрения Scrum немного переконфигурили JIRA, настроили там доску и прочие прелести, стали заводить ветки в Git через интеграцию JIRA+Bitbucket, что оказалось очень удобно.
Через какое-то время добавился Confluence, как хранилище документации, однако на данный момент качество документации у нас еще страдает (описано мало и очень поверхностно)
Мы пишем на питоне, поэтому в качестве тестов используем стандартные библиотеки. Для прогонки этих тестов настроен Jenkins.
Итоговая связка у нас JIRA+Confluence+Bitbucket+Jenkins+Slack
Slack начали использовать, когда всех окончательно достал скайп, оказалось это шикарнейший месенджер, с которым мы интегрировали все, что только можно и практически забросили почту. Пробовали HipChat потому что он от Атлассиана, как и остальные продукты, но он оказался для нас слишком сырым и неудобным.
В JIRA используем модули JIRA Agile для скрам доски и бэклога, JIRA Portfolio для долгосрочного планирования и JIRA Service Desk для баг репортов от пользователей.
Вроде все
Bitbucket использовали с самого начала, выбрали его из-за цены и удобства, через какое-то время начали использовать JIRA для ведения бэклога. С началом внедрения Scrum немного переконфигурили JIRA, настроили там доску и прочие прелести, стали заводить ветки в Git через интеграцию JIRA+Bitbucket, что оказалось очень удобно.
Через какое-то время добавился Confluence, как хранилище документации, однако на данный момент качество документации у нас еще страдает (описано мало и очень поверхностно)
Мы пишем на питоне, поэтому в качестве тестов используем стандартные библиотеки. Для прогонки этих тестов настроен Jenkins.
Итоговая связка у нас JIRA+Confluence+Bitbucket+Jenkins+Slack
Slack начали использовать, когда всех окончательно достал скайп, оказалось это шикарнейший месенджер, с которым мы интегрировали все, что только можно и практически забросили почту. Пробовали HipChat потому что он от Атлассиана, как и остальные продукты, но он оказался для нас слишком сырым и неудобным.
В JIRA используем модули JIRA Agile для скрам доски и бэклога, JIRA Portfolio для долгосрочного планирования и JIRA Service Desk для баг репортов от пользователей.
Вроде все
Благодарю!
А территориально все сотрудники в одном месте или есть те кто вообще в офисе не появляется?
А территориально все сотрудники в одном месте или есть те кто вообще в офисе не появляется?
Все сотрудники в одном месте и это очень важный момент. Я, конечно, слышал, но реально никогда не видел успешных, полноценных scrum-команд в удаленными сотрудниками. Все-таки находиться в одном месте, постоянно общаться в живую — очень важно для командного духа и мотивации.
Единственное исключение — наш DevOps инженер, он не входит в скрам команду и работает из другого офиса, но это работает, потому что у него абсолютно другая специфика работы. По сути, ему крайне редко надо синхронизироваться с нами.
Единственное исключение — наш DevOps инженер, он не входит в скрам команду и работает из другого офиса, но это работает, потому что у него абсолютно другая специфика работы. По сути, ему крайне редко надо синхронизироваться с нами.
МЫ вот только присматриваемся к Scrum. Какую методологию или особенности можете посоветовать для команды 5 человек без единого места работы? Все удаленно, но продуктивно.
Ну это очень сильно зависит от обстоятельств, то, что я сказал про распределенные команды — это мой опыт, и он не только про скрам, а вообще про командообразование. Если вы успешно работаете удаленно — отлично. Scrum стоит выбирать, наверное, исходя из других условий таких как жесткость сроков, гибкость бэклога, необходимая частота релизов.
Также надо учесть, что и Scrum и другие методологии всегда подстраиваются под команду. Их надо кастомизировать.
Также надо учесть, что и Scrum и другие методологии всегда подстраиваются под команду. Их надо кастомизировать.
Scrum — это не только ведение проекта, это автотесты, CI, чистый код и многоеЗолотые слова :)
У вас фулл-стек программисты, или есть разделение на бэк и фронт?
Если разделяете, то как описываете user story для двух программистов?
Если разделяете, то как описываете user story для двух программистов?
Два похожих вопроса, этот и следующий
Тут, конечно же, тоже не все было гладко
Изначально у нас бэк и фронт программисты. Немного и те и другие умеют соседнюю область. Мы очень стараемся, чтобы user story были и на бэк и на фронт, так часто получается, если это новый функционал, с новым интерфейсом и тд. Описание user story для двух программистов — не проблема, она на то и user story, описывается то, что хочет получить пользователь, там вполне может быть как интерфейс, так и бизнес логика бэка.
Но, конечно, часто бывают случаи чисто-фронт и чисто-бэк задач, в этом случае оцениваем их всей командой, но рассчитываем, что с большей долей вероятности делать эту задачу будет фронтендер/бэкендер. Если в течении спринта становиться ясно, что фронтенд не справляется — бэкенд старается помочь. Собственно проблемы были в начале внедрения именно тут, бэкендеры не хотели особо помогать фронтеду (бэкендеров больше), а в случае неудач, пытались свалить ответственность, но постепенно все наладилось.
Как правильно заметил jee — всё-таки не полная взаимозаменяемость, но мы стараемся.
Тут, конечно же, тоже не все было гладко
Изначально у нас бэк и фронт программисты. Немного и те и другие умеют соседнюю область. Мы очень стараемся, чтобы user story были и на бэк и на фронт, так часто получается, если это новый функционал, с новым интерфейсом и тд. Описание user story для двух программистов — не проблема, она на то и user story, описывается то, что хочет получить пользователь, там вполне может быть как интерфейс, так и бизнес логика бэка.
Но, конечно, часто бывают случаи чисто-фронт и чисто-бэк задач, в этом случае оцениваем их всей командой, но рассчитываем, что с большей долей вероятности делать эту задачу будет фронтендер/бэкендер. Если в течении спринта становиться ясно, что фронтенд не справляется — бэкенд старается помочь. Собственно проблемы были в начале внедрения именно тут, бэкендеры не хотели особо помогать фронтеду (бэкендеров больше), а в случае неудач, пытались свалить ответственность, но постепенно все наладилось.
Как правильно заметил jee — всё-таки не полная взаимозаменяемость, но мы стараемся.
У нас одна user story включает полный цикл — от проектирование — дизайн — верстка — программирование — тестирование.
Пока разбиваем на подзадачи, выставляем зависимости и оцениваем каждую.
Пока разбиваем на подзадачи, выставляем зависимости и оцениваем каждую.
Ну мы так делали только в самом-самом начале, все-таки это противоречит принципам скрама, оценивать надо задачу целиком, так как отдельные стадии не создают законченного функционала, кроме того — надо стараться избавляться от зависимостей. Мы тоже делим на подзадачи, в том числе часто разделяем фронт и бэк, но надо стремиться, чтобы делать можно было их в любом порядке, а не так, что мы не начинаем бэк, пока не готов фронт.
У меня в этом месте проблемы.
Полной взаимозаменяемости в моём проекте быть не может. Дело в том, что у нас очень большое клиентское приложение. Single page, конечно же. Это как другая Вселенная и перемешивать совсем не хочется.
И получается так, что пока бекенд не даст API, фронту делать особо нечего. Нет, не сказать, чтобы фронт простаивал, задач у них очень много. Тут проблема в другом: очень трудно в один недельный спринт впихнуть целую user story, потому что сначала два дня работают бекендеры, а потом два дня работают фронтендеры.
Пробовал извращаться, сначала описывая API, чтобы фронт мог всё сделать, просто замочив его, но часто получалось так, что некоторые вещи менялись в процессе работы бека и смысла в этом большого не было.
Полной взаимозаменяемости в моём проекте быть не может. Дело в том, что у нас очень большое клиентское приложение. Single page, конечно же. Это как другая Вселенная и перемешивать совсем не хочется.
И получается так, что пока бекенд не даст API, фронту делать особо нечего. Нет, не сказать, чтобы фронт простаивал, задач у них очень много. Тут проблема в другом: очень трудно в один недельный спринт впихнуть целую user story, потому что сначала два дня работают бекендеры, а потом два дня работают фронтендеры.
Пробовал извращаться, сначала описывая API, чтобы фронт мог всё сделать, просто замочив его, но часто получалось так, что некоторые вещи менялись в процессе работы бека и смысла в этом большого не было.
Я верю, что не знаю вашей ситуации, НО
У нас тоже single page, и тоже по началу были такие проблемы, но со временем все решилось очень просто.
1) Бэк делает хендлер для API, который возвращает тестовые данные, это просто заглушка, делается за 10 минут.
2) Profit — фронт работает с этой заглушкой, бэк спокойно делает API
Насчет изменений в процессе работа бэка — надо больше обсуждать на планировании, это решает 85% «внезапных» изменений в ходе работы, в остальных 15% случаев — да, придется потерпеть, но и то вряд ли меняется прям все
У нас тоже single page, и тоже по началу были такие проблемы, но со временем все решилось очень просто.
1) Бэк делает хендлер для API, который возвращает тестовые данные, это просто заглушка, делается за 10 минут.
2) Profit — фронт работает с этой заглушкой, бэк спокойно делает API
Насчет изменений в процессе работа бэка — надо больше обсуждать на планировании, это решает 85% «внезапных» изменений в ходе работы, в остальных 15% случаев — да, придется потерпеть, но и то вряд ли меняется прям все
Возможно, но пока это у нас не работает. Касательно заглушки, то у нас ровно то же самое, только на стороне фронта. Принципиальной разницы не вижу. Будем экспериментировать дальше… :-)
P.S. Спасибо за статью.
P.S. Спасибо за статью.
Как правильно заметил автор статьи, вам вероятно стоит попробовать глубже разбирать задачи на планировании/грумминге. В этот момент как правило и будет достигнут какой-то компромисс.
В этом процессе грумминг имеет очень важное значение, так как позволяет уточнять различные детали до планирования и уже на планировании можно +- определиться с тем как новая функциональность должна работать.
В этом процессе грумминг имеет очень важное значение, так как позволяет уточнять различные детали до планирования и уже на планировании можно +- определиться с тем как новая функциональность должна работать.
А как у вас фронтендер стал работать с серверной частью и наоборот? Или всё-таки не полная взаимозаменяемость?
Очень знакомо. Практически 1 в 1.
Тоже вводится не все сразу, а постепенно. Проходим по тем же граблям.
У нас проблемное место — несколько разных проектов и с этим реально головная боль. Одной большой командой работать не получается.
Тоже вводится не все сразу, а постепенно. Проходим по тем же граблям.
У нас проблемное место — несколько разных проектов и с этим реально головная боль. Одной большой командой работать не получается.
А сколько человек в «одной большой команде»?
У нас наоборот была команда — по количеству идеально для скрама, а вот проектов было столько же, сколько людей. Но тут помогло то, что проекты все — все-таки одна большая платформа, если бы это были совсем разные системы — наверно бы не вводили именно скрам, хотя бы канбан, чтобы не было спринт-коммитов (не буквально имею в виду, но все-таки задачи в спринте не меняются)
У нас наоборот была команда — по количеству идеально для скрама, а вот проектов было столько же, сколько людей. Но тут помогло то, что проекты все — все-таки одна большая платформа, если бы это были совсем разные системы — наверно бы не вводили именно скрам, хотя бы канбан, чтобы не было спринт-коммитов (не буквально имею в виду, но все-таки задачи в спринте не меняются)
в «большой команде» — 10.
Проектов — крупных 4, но есть еще мелкие, они пока вне скрама. Проекты не пересекаются. По каждому проекту свой бэклог и свои спринты.
Часть разработчиков (тестировщики, верстальщики) работают по разным проектам (либо целый спринт, либо полспринта тут, полспринта там).
Программисты выделенные под проект.
Есть ощущение, что команды по проектам должны вырасти и тогда уже каждая команда сама по себе + скрам над скрамом.
Проектов — крупных 4, но есть еще мелкие, они пока вне скрама. Проекты не пересекаются. По каждому проекту свой бэклог и свои спринты.
Часть разработчиков (тестировщики, верстальщики) работают по разным проектам (либо целый спринт, либо полспринта тут, полспринта там).
Программисты выделенные под проект.
Есть ощущение, что команды по проектам должны вырасти и тогда уже каждая команда сама по себе + скрам над скрамом.
Часть разработчиков (тестировщики, верстальщики) работают по разным проектам (либо целый спринт, либо полспринта тут, полспринта там).
Ну вот это по идее может очень вредить скраму.
Про увеличение команд — да, все верно, раз проекты разные нужны и полностью независимые команды, обычно, правда, все упирается в ресурсы
> Тут надо упомянуть, что в начале всего я был и Scrum мастером и Product owner.
А сейчас как? Вы больше не ScrumMaster?
А сейчас как? Вы больше не ScrumMaster?
Через пару месяцев мы ввели Daily Scrum (стендап), назначили его на 12:00, потому что к этому времени обычно все уже были на работе (у нас очень гибкий график)
У нас была похожая ситуация: часть разработчиков приходила к 10-ти, часть в 11, часть в 12, а уходили обедать в районе 13:30 +- все вместе. Сначала были дэйлики в 12 и вроде бы всем в команде удобно. Потом пришло понимание того, что мы сильно разбиваем время девелоперов, ведь те, кто пришел в 10, уже давно в работе и сейчас их лучше было бы не дергать, а те, кто пришел в 11, только полноценно в работу включились, получается рваный ритм. Т.к. все ходили в обед примерно в одно время, то мы перенесли время на 13:15 и получили другой результат. Во-первых, мы избежали этого рваного ритма и люди стали успевать больше, во-вторых, сами дэйлики начинали проходить продуктивнее, команда до всех доносила исключительно нужную информацию с минимум оффтопа и шуточек, ведь все понимали, что как закончим, так и пообедать можно будет и весь оффтоп перенести уже туда.
Если у вас девелоперы тоже ходят обедать +- в одно время, попробуйте подобную схему.
Спасибо за комментарий и идею, надо будет попробовать!
На самом деле в начале у нас была скорее проблема с тем, что дэйли занимал примерно 50 секунд =), но сейчас да, возможно будет полезно.
На самом деле в начале у нас была скорее проблема с тем, что дэйли занимал примерно 50 секунд =), но сейчас да, возможно будет полезно.
Интересно.
Но по ощущениям — более продуктивно с утра — в самом начале рабочего дня — настраивает разработчиков на работу.
Но по ощущениям — более продуктивно с утра — в самом начале рабочего дня — настраивает разработчиков на работу.
Конечно начинать день с дэйлика это самый продуктивный вариант, но в таком случае все члены команды должны приходить вовремя к дейлику и не сильно раньше его, иначе это время просто может потеряться из рабочего дня. Это, в свою очередь, может сильно повлиять на лояльность и настроение сотрудников, т.к. не всем удобно приходить, например, к 10-ти: транспортные причины, личные причины, много их. Из-за снижения лояльности и настроения продуктивность, как показывает практика, обычно падает. Значит в сумме мы не только не повысим продуктивность, но и еще можем получить проблемы с конкретными сотрудниками.
Если в вашей компании принято приходить в одно время, то конечно лучше начинать день с дэйлика. Если же на данный момент у вашей команды гибкий график начала рабочего дня, то стоит десять раз подумать перед тем, как это отменять, опросить сотрудников, посмотреть как они к этому отнесутся, если не будет явных возражений, то попробовать и изучить результаты, если же будут явные возражения — продумать последствия и взвесить полученные результаты.
У нас как раз гибкое начало дня и поговорив с людьми я понял, что ни к чему хорошему эта перемена не приведет, поэтому решил остановиться на предобеденных дэйликах.
Вообще Scrum относительно молодое и активно развивающееся направление. В нем можно пробовать разные гипотезы, главное тестировать их по одной и смотреть на результаты, при этом заранее просчитывать все точки невозврата относительно текущих процессов. Не всегда стоит искать от добра добра )
Если в вашей компании принято приходить в одно время, то конечно лучше начинать день с дэйлика. Если же на данный момент у вашей команды гибкий график начала рабочего дня, то стоит десять раз подумать перед тем, как это отменять, опросить сотрудников, посмотреть как они к этому отнесутся, если не будет явных возражений, то попробовать и изучить результаты, если же будут явные возражения — продумать последствия и взвесить полученные результаты.
У нас как раз гибкое начало дня и поговорив с людьми я понял, что ни к чему хорошему эта перемена не приведет, поэтому решил остановиться на предобеденных дэйликах.
Вообще Scrum относительно молодое и активно развивающееся направление. В нем можно пробовать разные гипотезы, главное тестировать их по одной и смотреть на результаты, при этом заранее просчитывать все точки невозврата относительно текущих процессов. Не всегда стоит искать от добра добра )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scrum. Из хаоса к порядку и высокой продуктивности