Спасибо за комментарий и идею, надо будет попробовать!
На самом деле в начале у нас была скорее проблема с тем, что дэйли занимал примерно 50 секунд =), но сейчас да, возможно будет полезно.
Я верю, что не знаю вашей ситуации, НО
У нас тоже single page, и тоже по началу были такие проблемы, но со временем все решилось очень просто.
1) Бэк делает хендлер для API, который возвращает тестовые данные, это просто заглушка, делается за 10 минут.
2) Profit — фронт работает с этой заглушкой, бэк спокойно делает API
Насчет изменений в процессе работа бэка — надо больше обсуждать на планировании, это решает 85% «внезапных» изменений в ходе работы, в остальных 15% случаев — да, придется потерпеть, но и то вряд ли меняется прям все
Один из программистов, который больше всех поддерживает и разбирается в scrum, сейчас постепенно перенимает на себя эти полномочия (Scrum мастера). Пока что переходный период.
Ну мы так делали только в самом-самом начале, все-таки это противоречит принципам скрама, оценивать надо задачу целиком, так как отдельные стадии не создают законченного функционала, кроме того — надо стараться избавляться от зависимостей. Мы тоже делим на подзадачи, в том числе часто разделяем фронт и бэк, но надо стремиться, чтобы делать можно было их в любом порядке, а не так, что мы не начинаем бэк, пока не готов фронт.
А сколько человек в «одной большой команде»?
У нас наоборот была команда — по количеству идеально для скрама, а вот проектов было столько же, сколько людей. Но тут помогло то, что проекты все — все-таки одна большая платформа, если бы это были совсем разные системы — наверно бы не вводили именно скрам, хотя бы канбан, чтобы не было спринт-коммитов (не буквально имею в виду, но все-таки задачи в спринте не меняются)
Тут, конечно же, тоже не все было гладко
Изначально у нас бэк и фронт программисты. Немного и те и другие умеют соседнюю область. Мы очень стараемся, чтобы user story были и на бэк и на фронт, так часто получается, если это новый функционал, с новым интерфейсом и тд. Описание user story для двух программистов — не проблема, она на то и user story, описывается то, что хочет получить пользователь, там вполне может быть как интерфейс, так и бизнес логика бэка.
Но, конечно, часто бывают случаи чисто-фронт и чисто-бэк задач, в этом случае оцениваем их всей командой, но рассчитываем, что с большей долей вероятности делать эту задачу будет фронтендер/бэкендер. Если в течении спринта становиться ясно, что фронтенд не справляется — бэкенд старается помочь. Собственно проблемы были в начале внедрения именно тут, бэкендеры не хотели особо помогать фронтеду (бэкендеров больше), а в случае неудач, пытались свалить ответственность, но постепенно все наладилось.
Как правильно заметил jee — всё-таки не полная взаимозаменяемость, но мы стараемся.
Ну это очень сильно зависит от обстоятельств, то, что я сказал про распределенные команды — это мой опыт, и он не только про скрам, а вообще про командообразование. Если вы успешно работаете удаленно — отлично. Scrum стоит выбирать, наверное, исходя из других условий таких как жесткость сроков, гибкость бэклога, необходимая частота релизов.
Также надо учесть, что и Scrum и другие методологии всегда подстраиваются под команду. Их надо кастомизировать.
Все сотрудники в одном месте и это очень важный момент. Я, конечно, слышал, но реально никогда не видел успешных, полноценных scrum-команд в удаленными сотрудниками. Все-таки находиться в одном месте, постоянно общаться в живую — очень важно для командного духа и мотивации.
Единственное исключение — наш DevOps инженер, он не входит в скрам команду и работает из другого офиса, но это работает, потому что у него абсолютно другая специфика работы. По сути, ему крайне редко надо синхронизироваться с нами.
Про программные продукты у нас все довольно стандартно:
Bitbucket использовали с самого начала, выбрали его из-за цены и удобства, через какое-то время начали использовать JIRA для ведения бэклога. С началом внедрения Scrum немного переконфигурили JIRA, настроили там доску и прочие прелести, стали заводить ветки в Git через интеграцию JIRA+Bitbucket, что оказалось очень удобно.
Через какое-то время добавился Confluence, как хранилище документации, однако на данный момент качество документации у нас еще страдает (описано мало и очень поверхностно)
Мы пишем на питоне, поэтому в качестве тестов используем стандартные библиотеки. Для прогонки этих тестов настроен Jenkins.
Итоговая связка у нас JIRA+Confluence+Bitbucket+Jenkins+Slack
Slack начали использовать, когда всех окончательно достал скайп, оказалось это шикарнейший месенджер, с которым мы интегрировали все, что только можно и практически забросили почту. Пробовали HipChat потому что он от Атлассиана, как и остальные продукты, но он оказался для нас слишком сырым и неудобным.
В JIRA используем модули JIRA Agile для скрам доски и бэклога, JIRA Portfolio для долгосрочного планирования и JIRA Service Desk для баг репортов от пользователей.
На самом деле в начале у нас была скорее проблема с тем, что дэйли занимал примерно 50 секунд =), но сейчас да, возможно будет полезно.
У нас тоже single page, и тоже по началу были такие проблемы, но со временем все решилось очень просто.
1) Бэк делает хендлер для API, который возвращает тестовые данные, это просто заглушка, делается за 10 минут.
2) Profit — фронт работает с этой заглушкой, бэк спокойно делает API
Насчет изменений в процессе работа бэка — надо больше обсуждать на планировании, это решает 85% «внезапных» изменений в ходе работы, в остальных 15% случаев — да, придется потерпеть, но и то вряд ли меняется прям все
У нас наоборот была команда — по количеству идеально для скрама, а вот проектов было столько же, сколько людей. Но тут помогло то, что проекты все — все-таки одна большая платформа, если бы это были совсем разные системы — наверно бы не вводили именно скрам, хотя бы канбан, чтобы не было спринт-коммитов (не буквально имею в виду, но все-таки задачи в спринте не меняются)
Тут, конечно же, тоже не все было гладко
Изначально у нас бэк и фронт программисты. Немного и те и другие умеют соседнюю область. Мы очень стараемся, чтобы user story были и на бэк и на фронт, так часто получается, если это новый функционал, с новым интерфейсом и тд. Описание user story для двух программистов — не проблема, она на то и user story, описывается то, что хочет получить пользователь, там вполне может быть как интерфейс, так и бизнес логика бэка.
Но, конечно, часто бывают случаи чисто-фронт и чисто-бэк задач, в этом случае оцениваем их всей командой, но рассчитываем, что с большей долей вероятности делать эту задачу будет фронтендер/бэкендер. Если в течении спринта становиться ясно, что фронтенд не справляется — бэкенд старается помочь. Собственно проблемы были в начале внедрения именно тут, бэкендеры не хотели особо помогать фронтеду (бэкендеров больше), а в случае неудач, пытались свалить ответственность, но постепенно все наладилось.
Как правильно заметил jee — всё-таки не полная взаимозаменяемость, но мы стараемся.
Также надо учесть, что и Scrum и другие методологии всегда подстраиваются под команду. Их надо кастомизировать.
Единственное исключение — наш DevOps инженер, он не входит в скрам команду и работает из другого офиса, но это работает, потому что у него абсолютно другая специфика работы. По сути, ему крайне редко надо синхронизироваться с нами.
Bitbucket использовали с самого начала, выбрали его из-за цены и удобства, через какое-то время начали использовать JIRA для ведения бэклога. С началом внедрения Scrum немного переконфигурили JIRA, настроили там доску и прочие прелести, стали заводить ветки в Git через интеграцию JIRA+Bitbucket, что оказалось очень удобно.
Через какое-то время добавился Confluence, как хранилище документации, однако на данный момент качество документации у нас еще страдает (описано мало и очень поверхностно)
Мы пишем на питоне, поэтому в качестве тестов используем стандартные библиотеки. Для прогонки этих тестов настроен Jenkins.
Итоговая связка у нас JIRA+Confluence+Bitbucket+Jenkins+Slack
Slack начали использовать, когда всех окончательно достал скайп, оказалось это шикарнейший месенджер, с которым мы интегрировали все, что только можно и практически забросили почту. Пробовали HipChat потому что он от Атлассиана, как и остальные продукты, но он оказался для нас слишком сырым и неудобным.
В JIRA используем модули JIRA Agile для скрам доски и бэклога, JIRA Portfolio для долгосрочного планирования и JIRA Service Desk для баг репортов от пользователей.
Вроде все