Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Работа |
![]() ![]() |
Топик располагается на нескольких страницах: ←Ctrl назад 1 .. 15 16 17 18 19 20 [21] 22 23 24 вперед Ctrl→ |
Дмитрий Мух Member Откуда: Зеленоград Сообщений: 3820 |
Что-то вы не в тему сюда definition of done и заказчика приплетаете. Речь-то была о том, что люди у себя там между командами договорились отписываться по завершению таска в трекере, статус там менять с комментариями. То есть приняли определённые правила взаимодействия (игры). И вот кто-то эти правила систематически не соблюдает. То есть они не работают. Что делать? Либо тупо отменить (они же итак не работают), либо пересмотреть так, чтобы процесс заработал. У вас какие-то иные предложения? Высскажите их, глядишь поможете Eleanor. |
||||||||
24 ноя 19, 19:36 [22024100] Ответить | Цитировать Сообщить модератору |
Андрей Панфилов Member Откуда: Москва > Melbourne Сообщений: 3812 |
|
||||||
24 ноя 19, 20:06 [22024117] Ответить | Цитировать Сообщить модератору |
Андрей Панфилов Member Откуда: Москва > Melbourne Сообщений: 3812 |
Согласно же вашей библии такое "оповещение" должно быть включено в definition of done, вы же заявляете, что раз не получается соблюдать, то можно забить. |
||||||||
24 ноя 19, 20:11 [22024121] Ответить | Цитировать Сообщить модератору |
WebSharper Member Откуда: Сообщений: 569 |
Она много где явно описана, например вот. Еще бывает DoD по отношению к разным этапам, например, "PBI не передается на тестирование, пока не прошел code review".
Команда сама принимает definition of done. Такой, который помогает ей достигать цели спринтов.
А где вы видите логическое противоречие?
Требование заказчика к конкретному PBI это acceptance criteria. DoD это общие требования для всего вместе, которые принимаются командой, но могут отражать какие-то общие требования заказчика. PO решает что нужно делать, команда, как нужно делать. Команда может ошибиться и это не будет противоречить скраму. Например отменить code review не скомпенсировав ничем и полезут баги.
Я ухожу? Это ТС сказал:
Я пытаюсь понять, что он имел ввиду, и вообще это какой-то отдельный вопрос или часть того, что его интересовало вначале "место на ретроспективе". У меня сложилось впечатление, что на самом деле его вопрос не интересует, а он ищет к чему прицепиться, не находит и перестает интересоваться темой пока ему в голову не приходит идея зайти с другого неожиданного ракурса. Впрочем, мое впечатление может быть ложной. |
||||||||||||||||
24 ноя 19, 20:12 [22024123] Ответить | Цитировать Сообщить модератору |
Дмитрий Мух Member Откуда: Зеленоград Сообщений: 3820 |
Пфффф... Я не заявляю, что если не получается соблюдать, то можно забить. Где вы это прочитали? Я согласен с softwarer, что в такой ситуации следует провести встречу и рассмотреть этот вопрос. Понять, почему договорённость не соблюдается, даже после того как приняли предложения самой команды, что их не соблюдает. И решить что делать. А вы что предлагаете? Увольнять? Штрафовать? Что? |
||||
24 ноя 19, 20:20 [22024133] Ответить | Цитировать Сообщить модератору |
Дмитрий Мух Member Откуда: Зеленоград Сообщений: 3820 |
И при чём тут корпоративный регламент? Простыми словами definition of done отвечает на вопрос "Что мы считаем тем, что задача сделана?". Например в вашей заказной разработке это может быть нечто следующее: - Перечисленные пункты ТЗ (спецификации) реализованы; - Код прошёл ревью; - Покрыт тестами и они успешно выполнены; - Документация написана; - Заказчик увидел результат и хоть раз попробовал и убедился в работе решения. |
||||||||
24 ноя 19, 20:27 [22024139] Ответить | Цитировать Сообщить модератору |
Дмитрий Мух Member Откуда: Зеленоград Сообщений: 3820 |
Аналогичное впечатление. Я о нём уже писал выше. |
||||
24 ноя 19, 20:29 [22024140] Ответить | Цитировать Сообщить модератору |
softwarer Member Откуда: 127.0.0.1 Сообщений: 64862 Блог |
Не "с softwarer", а "со словами softwarer о рекомендованном для гибких команд способе действий в такой ситуации". Лично softwarer не считает проведение встречи эффективным способом решения проблем. |
||||
25 ноя 19, 01:56 [22024233] Ответить | Цитировать Сообщить модератору |
Андрей Панфилов Member Откуда: Москва > Melbourne Сообщений: 3812 |
|
||||||||||||||||||||||||||||||||||||||||
25 ноя 19, 05:58 [22024256] Ответить | Цитировать Сообщить модератору |
Дмитрий Мух Member Откуда: Зеленоград Сообщений: 3820 |
Хорошо. У softwarer есть своё предложение о том, как эффективно решить описанную Eleanor проблему? |
||||||||
25 ноя 19, 10:06 [22024348] Ответить | Цитировать Сообщить модератору |
Eleanor Member Откуда: Сообщений: 3196 |
Проблемы нет. Нужно было просто проговорить ее и всё. |
25 ноя 19, 10:15 [22024360] Ответить | Цитировать Сообщить модератору |
softwarer Member Откуда: 127.0.0.1 Сообщений: 64862 Блог |
softwarer не до конца эту проблему понимает, но в целом привык считать эффективным методом "автоматизировать то, что автоматизируется, а в том, что не автоматизируется, выстроить процесс таким образом, чтобы человеку (или команде) было легко, удобно и выгодно ему следовать и тяжело, сложно и дорого его нарушать". Если проблема в том, что люди не сообщают о достижении задачей определённого статуса в трекере, то нужно автоматизировать такое извещение - в самом простом виде через подписку в JIRA - и не иметь людям мозги. Если проблема в том, что люди не ставят статусы в трекере, нужно сделать этот статус необходимой частью процесса. Например, автоматизировать сборку и загребать в неё только задачи с заданным статусом. Например, при расчёте всяких метрик и KPI считать только задачи в этом статусе. Технически ограничить возможность брать в работу новые задачи при незакрытых старых. Детектировать задачи, висящие в предфинальном статусе без движения, и начать задалбывать ежедневными сообщениями "пора закрыть задачу X". В конце концов, поставить сумму премии в зависимость от чёткости и своевременности закрытия задач. В общем, способ или комбинацию способов, подходящих к ситуации, найти можно. |
||||
25 ноя 19, 10:27 [22024378] Ответить | Цитировать Сообщить модератору |
Дмитрий Мух Member Откуда: Зеленоград Сообщений: 3820 |
И вот это всё сделать никому не сказав, ни кому не сообщив, в одностороннем порядке? Или всё-таки сначала некий proposal оформить, advice process запустить? В письменном виде. |
||||||||
25 ноя 19, 10:45 [22024389] Ответить | Цитировать Сообщить модератору |
Дмитрий Мух Member Откуда: Зеленоград Сообщений: 3820 |
То есть scrum-команда заработала, поговорив с утёнком :) |
||||
25 ноя 19, 10:46 [22024393] Ответить | Цитировать Сообщить модератору |
Дмитрий Мух Member Откуда: Зеленоград Сообщений: 3820 |
Сроки соблюдены. Чистая прибыль выше плана на 11,4%. Качество на уровне. Артели используют Scrum. Что не так? Может поступим как японцы. Рассмотрим успешные компании, где практикуется Agile и Scrum, и попытаемся понять что там про что, а? |
||||
25 ноя 19, 10:51 [22024398] Ответить | Цитировать Сообщить модератору |
softwarer Member Откуда: 127.0.0.1 Сообщений: 64862 Блог |
Ну, бюрократ в лучших советских традициях действительно запустит целый процесс. Хороший же руководитель просто выполнит свои прямые обязанности и выстроит работу. Сообщение было отредактировано: 25 ноя 19, 22:57 |
||||
25 ноя 19, 22:12 [22025067] Ответить | Цитировать Сообщить модератору |
Андрей Панфилов Member Откуда: Москва > Melbourne Сообщений: 3812 |
|
||||||||
26 ноя 19, 08:47 [22025193] Ответить | Цитировать Сообщить модератору |
Дмитрий Мух Member Откуда: Зеленоград Сообщений: 3820 |
Нет, вы поняли опять на свой лад и сделали свои, не понятно на чём, основанные выводы. Вот мы делаем успешный продукт: "Wild Apricot". Это SaaS, где нет заказчика, что выставит требования, нет специально обученных людей, кто формализует эти требования и оформит в виде чёткого и понятного ТЗ (спецификации), распишет в виде задач в Jira - сиди и делай. А есть мы, разбившиеся на команды (называем их артелями), по интересам - областям в продукте. И каждая артель в своей области занимается и и исследованием, и сбором требований, и анализом, проектированием, разрботкой, тестированием, выкаткой, сбором обратной связи. То есть полным циклом разработки своей части большой системы "Wild Apricot". И артели используют Scrum. А я готов и пытаюсь рассказать как. Думаю не я один тут такой: из успешной продуктовой компании, практикующей Agile, Lean, Scrum, DevOps. И не нужен нам тут Безос и его Amazon, и Google не нужен. Куда вас, ей богу, понесло? :) |
||||||||
26 ноя 19, 10:45 [22025293] Ответить | Цитировать Сообщить модератору |
Дмитрий Мух Member Откуда: Зеленоград Сообщений: 3820 |
Окей. Вот только эта ваша работа не решила бы проблему Eleanor, если подумать. |
||||||||
26 ноя 19, 10:46 [22025295] Ответить | Цитировать Сообщить модератору |
Дмитрий Мух Member Откуда: Зеленоград Сообщений: 3820 |
У хороших руководителей видимо не принято погружаться в проблемы коллектива ![]() |
26 ноя 19, 10:47 [22025296] Ответить | Цитировать Сообщить модератору |
DaniilSeryi Member Откуда: Сообщений: 1758 |
Хороший руководитель - вещь редкая. Да ещё и мутируют частенько в ох#$%евших рукойводителей, к сожалению. А уж лидеры - нет сынок, их не существует, это фантастика! |
||||
26 ноя 19, 12:09 [22025442] Ответить | Цитировать Сообщить модератору |
softwarer Member Откуда: 127.0.0.1 Сообщений: 64862 Блог |
Конечно. Её решат только встречи и совещания ![]() |
||||
26 ноя 19, 12:30 [22025481] Ответить | Цитировать Сообщить модератору |
skyANA Member Откуда: Зеленоград Сообщений: 28368 |
Давайте без только. Только это ваше. Только то как считает softwarer, является наиболее эффективным :) |
||||||||
26 ноя 19, 13:22 [22025565] Ответить | Цитировать Сообщить модератору |
WebSharper Member Откуда: Сообщений: 569 |
Продукт это продукт, требования - это требования. Частью описания может быть то, как убедиться в том, что они выпонены. Я согласен, что в AC могут быть не только требования заказчика, но они там должны как-то отражаться, если на эти требоания согласились.
AC могут как торчать наружу так и не торчать.
Вы цитируете текст из less - надстройкой над SCRUM для координации работы нескольких команд. Там ниже есть раздел определений:
Так как PO и Dev Team составляет Scrum Team по Scrum Guide
То это не противоречит тому, что я написал - это соглашение внутри команды даже если следовать только less. В идеале оно должен содержать все, что надо сделать, чтобы выпустить версию. Но может и не содержать, если идеал не достигнут. Еще там не сказано, что оно должно содержать только это. Т.е. написано к чему надо стремиться, а не как непременное условие.
Так это и есть цель спринта "a potentially releasable Increment of "Done" product at the end of each Sprint.". Заметьте, что DoD состоит из активностей - там фактически то, что надо сделать, а не то, каким должен быть результат.
Так же туда включают часто всякие code review и прочее. Т.е. это не то, что "эксплуатант" напрямую определяет, а то, на что соглашается команда исходя из его и своих представлений о том, что надо делать, чтобы результат удовлетворял требованиям.
Скрам это некоторый организационный каркас на который можно навешать конкретные вещи в достаточно широких пределах. Я читал, что изначально в Скрам захотели добавить XP, но потом решили что так он хуже будет продаваться и в итоге там нет технических практик "XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work.". Про качество в scrum guide есть несколько ограничений общего порядка (поищите quality), остальное на выбор того кто реализовывает - как технические так и организационные практики которые не противоречат. |
|||||||||||||||||||||||||
27 ноя 19, 16:47 [22026846] Ответить | Цитировать Сообщить модератору |
mirudom Member Откуда: Сообщений: 1148 |
Уважаемые форумчане, про то, что я имел ввиду. Всегда есть возможность что - то улучшить, особенно в разработке ПО - это я про свои шкурные интересы. Ну или попытаться это( улучшение) сделать. Вижу, пришли форумчане и говорят, что мол есть чУдная вещь - называется скрам-аджайл, у нас( них ) все служит удовлетворенности желаний и потребностей и клиентов и исполнителей. Мне естественно интересно, как взять на вооружение чУдную что-то, та как деньги просто так не платят. Я не имею ввиду различные варианты аффелированности заказчика и исполнителя. Но, так как фантазеров и шарамыжников много, то мне интересны механизмы достижимости рузультата. Начинаю спрашивать: что, как, почему, зачем, и какими средствами. В ответ получаю наставление типа "Верьте мне люди" или "есть великолепная практика под названием Ретроспектива и вот на ней ....." . Задаю вопрос:
Пока получается, что и применение и понимание скрам-аджайла сильно зависит от контекста (задачи-процесса-опыта-инструментов-участников-достижимость результата). Но нет возможности добиться от skyANA или Дмитрий Мух или WebSharper внятного ответа на вопрос о соблюдении финансовой дисциплины на проектах с применением скрам-аджайл. Без чего нет коммерческой разработки. Ссылки на благодарности пенсионеров смахивают на известное выражение: "Спасибо товарищу Сталину за наше счастливое детство !". |
||
30 ноя 19, 21:37 [22029569] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: ←Ctrl назад 1 .. 15 16 17 18 19 20 [21] 22 23 24 вперед Ctrl→ |
Все форумы / Работа | ![]() |