Sergey
в данном случае команда = компетенция?
не понял, что имеете в виду.
Daria
ну можно делить команду, как — команда проекта1, команда проекта2, команда проекта3. У каждой команды своя доска, где двигаются и ставятся задачи. + каждый день стендап у этой доски. Правильно ли будет разработчиков бекенд, которые работают на все три проекта, тянуть на 3 стендапа по каждому проекту?
Daria
А можно бекенд выделить, сделать им свою доску и отдельно с ними раз в день общаться, типо для какого проекта сейчас они делают задачу и тп. А другие члены проектных команд на стендапе только о своем, без бека говорят, не слушая их
Natalya
Всем доброго дня! Переезжаем из редмайна в jira (Jira Software). Опытные jira-воды, подскажите, как трекаете время (если используете нестандартные решения) и снимаете отчеты по часам? Стоит задача смотреть и отчитываться в экселе по финальным цифрам за месяц (по проектам/пользователям/спринтам/задачам). Встроенные отчеты неудобны (или я не умею их готовить).
Daria
Это нарушает основной принцип формирования команды - она должна быть кроссфункциональной, чтобы проблемы проекта можно было решать сообща
а я и не поддерживаю это. Но я беспокоюсь, что бекенд трижды в день в стендапах будет участвовать
Ilya
Жиры)
Ilya
все плагинами добивается там
Natalya
Простите за отступление. :) жира вроде как agile-инструмент, подумала, что не совсем оффтоп
Natalya
)))))
Dmitry
а я и не поддерживаю это. Но я беспокоюсь, что бекенд трижды в день в стендапах будет участвовать
если я правильно понял, то backend - это ботлнэк у вас, и конечно не правильно дергать их на митинги. Вам в какой части scrum нужен? сколько народу на все 3 "команды / проекты"? вы одним стендапом не можете обойтись? просто сделайте структуру доски соотвествующую вашим реалиям.
Daria
если я правильно понял, то backend - это ботлнэк у вас, и конечно не правильно дергать их на митинги. Вам в какой части scrum нужен? сколько народу на все 3 "команды / проекты"? вы одним стендапом не можете обойтись? просто сделайте структуру доски соотвествующую вашим реалиям.
веб: 9 чел с беком, моб: 9 чел с беком, смарты пока не ясно. Одним стендапом не обойтись, тем более, по спринтам работать будет только моб команда, а веб решил по канбану (но с ежедневными статусами=стендапами)
Igor
вообще делить надо продукт а не команду. команда пусть сама поделится :D
Daria
один стендап на все 18 человек?
Это как раз не мое предложение
Igor
Это как раз не мое предложение
просто судя по всему вы достигли того момента когда надо делить продукт на куски функционала и разрабатывать каждый кусок своей командой
Igor
Сделать из одной проектной команды 2 скрам?
зависит от бизнес условий в которых вы находитесь
Igor
куски функционала можно потом продавать как отдельный продукт - когда оно вырастет достаточно.
Daria
куски функционала можно потом продавать как отдельный продукт - когда оно вырастет достаточно.
Разработка с нуля( боюсь сейчас невозможно разделить или я не умею
Oleg
тимлида нет?
Igor
Разработка с нуля( боюсь сейчас невозможно разделить или я не умею
зачем с нуля? вы делите продукт на бизнес уровне. каждая скрамкоманда отвечает за свой кусок продукта(по бизнесу а не по платформе). соответственно в каждой такой команде должны быть спецы которые смогут выполнить задачу ( например реализовать месседжинг на всех нужных платформах ).
Igor
и к этому можно вполне постепенно идти. да ребятам придется договорится как устроить у себя workflow на компонентном уровне и придется сделать эти процессы открытыми и понятными для всей организации. да это дохрена работы :D ну чо делать. дележкой команд - проблемы бизнеса не решить.
Oleg
если короче, то зовите тимлида, делите на сервисы и распределите на команды
Daria
Спасибо, коллеги. Завтра попробую это сформулировать и обсудить с заинтересованными. Ранее не было практики такой у меня..
Oleg
Странно конечно как вообще такая команда могла появится изначально. Никто из 18 человек не был против? Тимлид или ИТдир должны были не допустить такое.
Oleg
Сейчас окажется еще что на сервисы не поделишь, потому что монолит.
Oleg
))
d
Господа вопрос ✓ A Scrum Team’s service level expectation (SLE) is an input into the various Scrum events. In which event will SLE provide the most benefit toward helping a Development Team achieve good flow (the best answer) 1.       Sprint retro 2.       Sprint review 3.       Sprint planning 4. Daily scrum
d
Колеблюсь между несколькими вариантами
Yuriy
какими? почему именно? 😉
Igor
Сейчас окажется еще что на сервисы не поделишь, потому что монолит.
монолит не монолит не важно. с монолитом будет сложнее наладить общую разработку разного функционала но всё же возможно.
Oleg
возможно все, только на это потребуется время и деньги, последнее будет трудно обосновать перед заказчиками, если команда была с начала проекта.
Igor
так команду же не выгоняют :D
Igor
возможно конечно кому то придется уйти если он не примет новые ценности и будет настаивать на старых порядках
Igor
но тут важно правильно объяснить почему по старому больше нельзя
Oleg
я бы сразу тимлида и ит-дира кикнул за такой капитальный косяк.)
Oleg
если делали по скраму с нуля и только сейчас появился этот вопрос. Значит вопрос компетентности
Oleg
Это как бы основа основ и грубейшая ошибка
Igor
рыба с головы гниет.
Oleg
команда из 18 хах)
Igor
я правда хз как может быть тимлид или ит дир если у тебя там скрум :D
Oleg
А почему это при скраме не может быть ИТ-дира?
Igor
Oleg
А с чего это ИТ дир должен быть в команде?
Igor
я не говорю что он в команде :D я спрашиваю чем он будет заниматься?
Oleg
Странный вопрос :)
Oleg
Вы точно в ИТ работаете?)
Igor
Вы точно в ИТ работаете?)
абсолютно не странный :D что IT директор будет делать организации в которой принят scrum?
Oleg
архитектура, стратегия, управление и распределение ресурсами
Oleg
как минимум это в первую очередь он должен был принять скрам для компании
Oleg
топ манагером тогда уж
Igor
кто занимается менеджментом в скраме?
Akkedis
скрам это способ организации команды разработки. кроме команды разработки в бизнес-структуре еще дофига кого есть.
Oleg
вот-вот, поэтому и странный вопрос
Igor
скрам это способ организации команды разработки. кроме команды разработки в бизнес-структуре еще дофига кого есть.
ноуп :D скрам это фрейморк для создания продуктов. разработку он на самом деле огранизует в последнюю очередь
Akkedis
выпусти слова "процессы внутри"
Oleg
))
Akkedis
)
Igor
кек нету никаких процессов внутри
Igor
советую почитать кто такой product owner и почему он не product manager :D
Akkedis
ну нет так нет
Oleg
советую прочитать кто такой СТО, CIO итд, и почему они не являются ПМ, ПО или CM
Oleg
))
Oleg
каким? у каждого есть своя доля менеджмента
Igor
доли? мы сейчас делим ответственность?)
Oleg
омайгад да что это за угадайка пошла. Вам теорию надо подтянуть или что?
Igor
теорию подтянуть стоит вам
Oleg
ок
Igor
особенно классно слышать про топманагера в плоской организации :D
Igor
прям вот угар