Artem
Второй: одна команда, но тогда вы не делите задачи на иос/андроид вообще
Artem
Бэк вперёд не должен бежать ни в одном из случаев
Artem
Как настроить трекер, это последний вопрос, который вас должен волновать
Sergey
Как быть с тем, когда для iOS нужно сделать сложную штуку с force touch, например. Для этого нужен целый спринт, а Android не может ничего нового делать, кроме багфикса, рефакторинга и тд?
Konstantin
у нас был бек общий - куча бенефитов получили
одинаковые API по разным сервисам
удобство поддержки в проде
прогнозируемые по строкам доработки
Artem
Ну да, удобней одна команда конечно, но сложнее
Artem
Как быть с тем, когда для iOS нужно сделать сложную штуку с force touch, например. Для этого нужен целый спринт, а Android не может ничего нового делать, кроме багфикса, рефакторинга и тд?
Спросите у них, чем андроид может помочь иос в этой задаче. Программисты не только по клавишам стучать умеют
Artem
Помочь с аналитикой, помочь с куа
Sergey
Общий бэк конечно, другого не рассматриваем :)
Artem
Что значит общий бэк?
Artem
Технологически? Это понятно всем
Artem
Люди общие? Это уже не так однозначно
Sergey
Люди общие
Sergey
Команда одна же :)
Artem
Это если одна
Artem
Вариант с двумя командами вполне рабочий, просто с допущениями, которые надо принять
Konstantin
ну api для разных сервисов подняли на одном приложении
Konstantin
да там есть кастомизация - но по факту одно приложение
Konstantin
хотя в начале все под свои нужны проектировали страшные апи
Artem
Это вы к чему?
Konstantin
но лень разработчиков взяла верх
Sergey
Вариант с двумя командами вполне рабочий, просто с допущениями, которые надо принять
Команды получатся из 3-4 человек
Artem
И?
Sergey
7±2 :)
Sergey
@DasBotrek, Или речь не про две о отдельные DT?
Глебка
в гайде пишут до 9 чел. 4 чел оч даже команда
Artem
По скрам.оргу от 3 до 9
Artem
И у вас будет больше 4х
Artem
Бек и куа должен быть в каждой
Artem
Да и дизайнер
Konstantin
не очень понятно зачем бек а каждой
фронт может делать отличные моки на апи методы
Konstantin
которые потом подменяются нормальными при сборке
Artem
А когда готова задача получается?
Artem
Спринт + когда сделает бэк + сборка + фикс багов после сборки?
Konstantin
ну знаете - на каждой спринт переписывать сервер - миграция данных и прочии приколы
очень дорога выходит на круг
Artem
Это не ответ на мой вопрос )
Konstantin
если не жалко на это денег и времени - то
Artem
На что?
Artem
Мне жалко денег на задачу, если я не понимаю, когда мне ее выдадут
Konstantin
прототипы UI крутится на своих тестовых апи пока не придет понимание что созрело
потом подключает настоящий сервер
авторизации
безопасность
Artem
Ну если по это устраивает
Sergey
@DasBotrek собственно все сказал. Кросс компонентные кросс функциональные команды.
Artem
Я давал выбор )
Sergey
Запускаем новый продукт. Я SM.
Нужно поставить процесс разработки на рельсы. Разработка будет вестись на бэке, Android и iOS. По каждому направлению будет 2 человека, пока. Дизайнер один, тестер один. Это и есть команда.
Продукт, как сказал, одни, бэклог один, но в нем могут быть фичи специфичные каждой платформе. Плюс разрабы iOS могут писать быстрее или медленнее чем, Android, и наоборот. Бэк должен работать на шаг впереди, имхо. И ещё всяких нюансов присущих разработке мобильных приложений.
Вопросы:
1. Как были организованы команды у вас?
2. Как декомпозировались задачи: выделяли отдельно для платформ, бэка?
3. В работу брали задачи фичами (инкремент - это готовый iOS и Android c одинаковой функциональностью) или тасками разных фичей в зависимости от производительности разработчиков платформ, готовности элементов?
4. В трэкере был один общий проект или разные в зависимости от платформы?
5. Какие принципы работы и грабли, на которые не нужно наступать, можешь обозначить с ходу?
1. Фиче команды, в командах и мобильный и фронт и бэк
2. Элементы бэклога резать фичами
3. Да, фичами сейчас делаем.
4. Один общий.
5. Да сходу сложно. Основное это грамотный PBR.
Sergey
@DasBotrek, Или речь не про две о отдельные DT?
Попробуй общей командой поработать. 9 это не догма. Может быть и больше команда. Просто управляться с ней сложнее.
Pavel
Бек и куа должен быть в каждой
Сейчас скажу ересь, но нет, куа не обязательно дожен быть в каждой команде :)
Artem
Сейчас скажу ересь, но нет, куа не обязательно дожен быть в каждой команде :)
Никто не должен, если без него можно задачи делать
Pavel
Запускаем новый продукт. Я SM.
Нужно поставить процесс разработки на рельсы. Разработка будет вестись на бэке, Android и iOS. По каждому направлению будет 2 человека, пока. Дизайнер один, тестер один. Это и есть команда.
Продукт, как сказал, одни, бэклог один, но в нем могут быть фичи специфичные каждой платформе. Плюс разрабы iOS могут писать быстрее или медленнее чем, Android, и наоборот. Бэк должен работать на шаг впереди, имхо. И ещё всяких нюансов присущих разработке мобильных приложений.
Вопросы:
1. Как были организованы команды у вас?
2. Как декомпозировались задачи: выделяли отдельно для платформ, бэка?
3. В работу брали задачи фичами (инкремент - это готовый iOS и Android c одинаковой функциональностью) или тасками разных фичей в зависимости от производительности разработчиков платформ, готовности элементов?
4. В трэкере был один общий проект или разные в зависимости от платформы?
5. Какие принципы работы и грабли, на которые не нужно наступать, можешь обозначить с ходу?
1. Обычно - смешанная кроссфункциональная (iOS, android, бекб куа, дизайнер). В вашем случае от вас зависит. Если продукт предусмартивает синхронные фичи - разделять не имеет смысла, если ассинхронные - можно разделять по платформе.
2. выделять для компонентов системы не стоит. Конкретно в мобилках это будет немного размыто, но в целом лучше придерживаться принципа "бизнес" функциональности в бэклоге, а не технической.
3. Фичами удобней фокусироваться.
4. Смотря какой трекер. В жире проще использовать поле component, например.
5. Грабли - не забивайте на валидацию iOS билда эпплом. Лучше отдавать им на валидацию и не выпускать в паблик, чем потом лихорадочно шерсть на ... сяких частях тела рвать, что не проходит. Вложитесь в CI, для эппл есть тестфлайт, для андройда вообще все решения подходят.
Pavel
Никто не должен, если без него можно задачи делать
Именно. Если куа есть только один на все команды - это печально, но в целом рабочий вариант. Просто разработчики будут более погружены в качество :)
Sergey
Спасибо, коллеги
Pavel
Какой аналог test flight для Android есть?
HockeyApp. Его, собственно, и для iOS можно использовать.
Pavel
HockeyApp хорошо интегрируется с jenkins и bamboo, кстати.
Pavel
Чем facilitating product owner отличается от скрам мастера и что это вообще за зверь такой?:)
Igor
Чем facilitating product owner отличается от скрам мастера и что это вообще за зверь такой?:)
звучит как будто у PO случилась шизофрения
Jane
😂
Artem
Artem
Выглядит как см+по, но это имхо хреновая практика
Pavel
Выглядит как см+по, но это имхо хреновая практика
Хреновая, да. С другой стороны, PO - тоже должен быть facilitator. С третьей - у них это отдельное название роли и они совершенно без объяснения что это такое спрашивали меня, в чем разница.
Pavel
Так что у меня есть ощущение, что этот фасилитирующий ПО - что-то известное.
Artem
Ну если вспомнить, что фасилитатор это в некотором роде синоним менеджера, то да )
Sergey
Denis
Sergey
Я тоже. Но вот перечитывая эту главу задумался :) Возможно это опять перевод виноват ...
Dеfault
Я предполагал, что это одна из задач Скрам Мастера, формировать активное стремление к эффективности, т е коучить и мотивировать команду(ы).
Разница, видимо, как раз, в количестве и в том, что коуч обладает бОльшим набором компетенций и знаний, которые позволяют "одновременно вести несколько команд".
Каждая команда (как и каждый человек) уникальна. В каждой свои проблемы и условия внутренние и внешние.
Коучем, как я понимаю, считается тот, кто способен быстро проводить оценку и эффективно отрабатывать максимум этих возможных вариаций
Антон
Я тоже. Но вот перечитывая эту главу задумался :) Возможно это опять перевод виноват ...
Чем Скрам Мастер отличается от Agile коуча?)
Можно поднять Скрам Гайд - там в обязанностях Скрам Мастера есть коучинг. Одно не противоречит другому. Адкинс пишет в своём стиле) тем более книга именно про Agile коучинг)
Антон
Она хорошо описывает уровни Agile коуча/ Скрам Мастера
Антон
Конечно же в зависимости от уровня команд(ы)
Mikhail
Чем Скрам Мастер отличается от Agile коуча?)
Можно поднять Скрам Гайд - там в обязанностях Скрам Мастера есть коучинг. Одно не противоречит другому. Адкинс пишет в своём стиле) тем более книга именно про Agile коучинг)
Тем что коуч про аджайл, а мастер про Скрам например. Остальное обсуждаемо
Mikhail
Это де юре. Обычно мастер больше про команды, а коуч про организацию
Антон
Это де юре. Обычно мастер больше про команды, а коуч про организацию
В гаде в обязанностях Скрам Мастера одно из направлений - работа с организацией) это и де-юре и де-факто :)
Хороший спорный вопрос)))))
Так же как: чем Agile от Scrum отличается ))))
Mikhail
В гаде в обязанностях Скрам Мастера одно из направлений - работа с организацией) это и де-юре и де-факто :)
Хороший спорный вопрос)))))
Так же как: чем Agile от Scrum отличается ))))
Аджайл это одна из форм органищационной адаптивности. Скрам это одна из форм аджайла
Mikhail
Поэтому СМ это подмножество аджайл коучей
Dеfault
Аджайл это одна из форм органищационной адаптивности. Скрам это одна из форм аджайла
Разве Скрам был описан не раньше Аджайла?
Mikhail
И?
Антон
Ребята, одно не противоречит другому. Agile это философия, Скрам - Фреймворк.
Lean - философия
КаНбАн...
ХР...