Показать фронтенд-разработчикам вызовы апи, а потом после того, как фронтенд начал внедрять апишечку, узнать, что апи "чуть-чуть" отличается от спецификации и переделывать его ;) Мне кстати, всегда казалось, что должен демонстрироваться уже синтегрированный кусочек функциональности, а не отдельно апи, отдельно фронтенд. Возможно, я не очень правильно понимаю scrum.

Задача: В профиле пользователя указано имя и фамилия, но разделяются они уже в приложении (исходя из пробела, т.е. возможны ошибки). Необходимо изначально хранить имя фамилию раздельно Что имеем в результате: Имя фамилия хранятся отдельно, ошибок при отображении в профиле в будущем быть не должно.

именно в этой задаче — вполне можно показать новую структуру таблицы, как мне кажется

если бэк+фронт — демонстрировать надо сразу и то, и то

то есть это одна user story бэк+фронт

это очень уныло и грустно смотреть на демо на код, таблички и api

хотяя можно взять и на демо запилить через форму юзера, который раньше должен был сломать систему, а теперь корректно работает

это очень уныло и грустно смотреть на демо на код, таблички и api

это так, да просто тут задача скорее как баг-фикс подозреваю, что основная масса задач все-таки не такие)

Для вариантов демонстрации API можно сделать простой тестовый веб-клиент. Без упоротости на дизайн, главное - функционал

Юзер стори от слова юзер

Таким образом доработка апи - это не оно

если только юзеры данного продукта не внешние системы, работающие с апи)

Не трожьте святое! )

Назовите тех стори

Или таск в рамках какой-либо ЮС

тогда весь бэклог будет только из тех.стори. Если делаешь API, твои пользователи - другие разработчики из внешних систем, так что, все норм

http://scaledagileframework.com/enablers/

вот кто-то про энейблеры спрашивал

http://scaledagileframework.com/story/ вот тут внизу хорошо про энейблер-стори

а кто как ретро проводит? какие веселые штуки используете, что б уныния не было?

Иван, спасибо за ссылку

а кто как ретро проводит? какие веселые штуки используете, что б уныния не было?

Лего классно использовать, всем становится весело) но если часто применять - приестся

На последнем Agile Days был доклад про бодрую ретроспиктиву, видео нет, только слайды остались: http://www.slideshare.net/DmitryPavlov9/ss-59607262?qid=bc25b6cf-fa6b-4f9f-83da-e5a49cc128da&v=&b=&from_search=2

спасибо

говорят, что когда-нибудь и видео будет)

http://www.slideshare.net/DmitryPavlov9/ss-59607262?qid=bc25b6cf-fa6b-4f9f-83da-e5a49cc128da&v=&b=&from_search=2

надеюсь )

Диман, ты популярен

http://scaledagileframework.com/enablers/

Спасибо, почитаю

На ретроспективах (вся команда удаленная) в общем гуглдоке каждый emoji-иконками описывает свои "впечатления" от спринта, типа 👮💪🚀👍, потом по-очереди рассказываем что эти картинки значат. Дальше уже переходим к обычным "что прошло хорошо, что могло бы быть лучше". Первая часть и дает время заполнить вторую часть, и подключает людей к дальнейшему обсуждению.

http://www.slideshare.net/DmitryPavlov9/ss-59607262?qid=bc25b6cf-fa6b-4f9f-83da-e5a49cc128da&v=&b=&from_search=2

Без комментариев мало что понятно)))

http://timble.us

Эта штука тягает таски из джиры и ты делаешь стоп старт по мере выполнения?

А в джиру улетают трудозатраты?

С добрым утром всех!) 🎉

Да, хотел бы такую штуку для GitHub

есть ещё toggl.com, который умеет интегрироваться много с чем

Вот ещё нашёл тулз) https://gitprime.com/user-interface-for-git/

Назовите тех стори

+1

#whois Привет. У меня все про другое. Я - рекрутер. Помогаю люлям и работе находить друг друга. Параллельно - основатель компании PEOPLE. Кадрового агентства, которое работает по SCRUM. Специалист в рекрутменте. Могу быть полезна: а) новой работой; 2) историями о SCRUM вне ИТ. От сообщества - подумать вместе над переносом некоторых понятий SCRUM'a на внеИТшную среду. Например, что у нас продукт, я до сих пор не до конца понимаю. Откуда - Красноярск. Узнала из FB.

Sagitova как у вас тогда скрам если вы не понимаете что за продукт?

Sagitova как у вас тогда скрам если вы не понимаете что за продукт?

Пока договорились с командой о едином понимании. Продукт - кандидат соответствующий заявке. Но вопрос с инкрементом остается открытым. Мы же не может улучшать кандидата каждую неделю))

вполне можете показывать другого кандидата :D

Так и делаем. И с каждым спринтом все больше попадаем в требования PO ( он же заказчик). Но какое-то внутреннее чувство подсказывает мне, что продукт должен быть другой.

кандидат вроде вполне себе продукт, если есть чувство что есть что то другое - подумайте что является ценностью для заказчика?

кандидат вроде вполне себе продукт, если есть чувство что есть что то другое - подумайте что является ценностью для заказчика?

Спс! Завтра обсудим.

скорее всего получится так что вам придется выяснять что важно для каждого заказчика - раз он у вас PO

но вообще PO - это не заказчик - это человек который знает как повысить ценность продукта для заказчика :)

скорее всего получится так что вам придется выяснять что важно для каждого заказчика - раз он у вас PO

Это реально. Мы ведь каждый раз подробно снимаем позицию. Надо добавить вопросы с фокусом на ценность. Реально: кому-то нужен постоянный поток кандидатов, а кому-то "один из одного"

но вообще PO - это не заказчик - это человек который знает как повысить ценность продукта для заказчика :)

Т.е. в нашем случае - кто-то, кто знает, как находить 100% подходящих кандидатов? И "продавать" их заказчику?

да что то вроде

заказчик в данном случае Shareholder

да что то вроде

Тогда меня ждет шизофрения с раздвоением на РО и SM

PO и SM не может быть одним человеком :) как раз таки шизофрения это когда - человек один

SM - отвечает за процессы, PO - за ценность продукта

PO и SM не может быть одним человеком :) как раз таки шизофрения это когда - человек один

Я пока уверенно жила в роли SM, определив роль РО Клиенту. Но, следуя логике рассуждений, сделала это не верно.

значит придется отдать роль SM отдать кому то еще

В Вашей логике РО - это я.

значит придется отдать роль SM отдать кому то еще

Факт

да вполне

SM помогает команде наладить процессы

Только кто ж тогда рекрутментом заниматься будет ))

если совмещать роли - SM будет форсировать некоторые изменения процесса чтобы угодить бизнесу

а такое не совсем верно

ибо команда должна сама определять как ей лучше действовать

если совмещать роли - SM будет форсировать некоторые изменения процесса чтобы угодить бизнесу

В точку. На эти грабли мы наступаем иногда.

SM - отвечает за процессы, PO - за ценность продукта

Только я теперь не понимаю, а что чисто технически делает PO после того, как обозначит бэклог, Понедельник- планирование, пятница- обзор и ретро. А вт-чт чем человек занимается?

Определяет ценность продукта

Совещается с shareholders чтобы понять в чем эта ценность

Т.е в постоянной коммуникации с клиентом, получает ОС?

))

Ещё команде это все доносит

Уточняет требования

В вашем случае отфутболивает кандидатов которые не прошли DoD

Тогда понятно теперь, откуда наши косяки.Надо из меня выделять роль SM.

В вашем случае отфутболивает кандидатов которые не прошли DoD

Тут тоже вопрос: тогда перед каждой отправкой кандидата Клиенту, я должна провести с ним интервью, убедившись, что он соответствует DoD? Или верить команде?

Верить команде конечно же

Кстати, про Dod - они едины для всех проектов? Или в каждом рекрутмент- проекте должны быть свои DoD?

если нет доверия - нет agile

DoD по идее может быть общим для команд - но в некоторых командах он может усиливатся