Ilya
Это только часть решения
Ilya
Даже первая история ей не покроется
Артём
просто это подход "пять зачем", который абсурден тем, что на последнее зачем можно ответить "заработать денег", но потом можно дальше спросить зачем и получить ответ для покупки еды, а дальше чтобы не умереть
Артём
и как бы решение первичной задачи можно поменять на увольнение и поехать житьв деревню и там самому выраживать еду чтобы выжить
Артём
тогда тебе скажут я еще на машину хочу заработать
Артём
ты придумаешь решение в виде устроитсья на работу
Ilya
Ну неумение пользоваться этим подходом не говорит о том, что он плохой
Артём
а проблема в деревне и надо будет вернуться в город и найти работу не менее Х руб в месяц
Артём
ну так я и не увидел что он хороший
Ilya
Так я и не дораскрутил вашу первую историю
Артём
я ее раскрутил до работы на грядке )
Артём
когда надо было остановиться ?
Pavel
MVP, не?:)
Pavel
когда продакт овнер скажет "ну это мы делать сейчас не будем".
Артём
Если у заказчика так раскручивать историю то мне скажет - за**бал, иди на *й))
Ilya
когда надо было остановиться ?
Сначала надо было ответить на мой вопрос выше
Pavel
А вообще раскручивают до минимально впихуемого в спринт состояния.
Ilya
Это разбивают
Ilya
А раскручивают пока бизнес ценность не появится, а её пока еле еле видно
Pavel
Бизнес-ценность в исходной должна быть. Если ее нет, она в бэклог попасть не должна.
Артём
То есть у заказчика должна быть полная картина с процессами, чтобы он сказал почему есть задача Подписи документа
Pavel
Нет, можно value stream map
Pavel
Это можно нарисовать за пару часов интервью обычно.
Pavel
Из vsm уже можно понять, где бизнес ценность у решения и есть ли оно.
Pavel
Но это уже не скрам, и даже не agile :)
Артём
Ну я не понимаю как без понимая всех процессов, основанных на законодательных документах, существующих процессах описать историю, которая должна нести ценность и уложиться в спринт. Организовать подпроцесс генерации и передачи сертификата нужно больше спринта, так ещё и сам сертификат не несёт бизнес ценности без его использования, т к это всего лишь инструмент гарантирующий авторство и неизменность данных
🦠
Все внешние процессы могут быть вынесены за скоуп
Артём
Ну так вся задача разобраны и стало ясно, что одна из история - подписать документ юридически значимой подписью
Артём
Мне спать пора)
🦠
Эту работу делаете не вы и не ваша команда, в скоуп попадает дать возможность пользователю заверить подписью документ
Артём
Я с этого и начал
🦠
Является ли оно юридически значимым действием — к отделу разработки не относится
🦠
Есть документ, есть смены состояния на подписанный одной из сторон
🦠
На подписанный второй стороной
Ⓢⓔⓡⓖ
Ну неумение пользоваться этим подходом не говорит о том, что он плохой
Подход интересный но имхо непрактичный, и годится скорее для сеансов психотерапии, а не для разработки софта
Ⓢⓔⓡⓖ
Попробуй спросить у бухгалтера, зачем ей нужны сальдо по счёту
Артём
Является ли оно юридически значимым действием — к отделу разработки не относится
Если не сослаться на юридически значимую, то разработчики сделают подпись как удобно - генерация пары ключей и подпись. По итогам, бизнес скажет что нам не такая нужна, а разработчики скажут что нигде не было о юридически значимой
Ilya
Попробуй спросить у бухгалтера, зачем ей нужны сальдо по счёту
Это и так известно, домен не тот, где нужно 5 why
Артём
Приходим к тому, что скрам это не таблетка для всех организаций рабочего процесса разработки, а инструмент, который эффективно работает в определённых условиях
Артём
Не все руководители понимают и слышат о модном слове и начинают говорить что работаем по скраму, избавляя себя от планирования и управления процессом
Артём
Точно.
Есть статьи про условия? Чтобы взять свою обстановку, прогнать по условиям и сделать вывод
Ilya
Cynefin
Ilya
https://www.unusual-concepts.ru/blog/2012/12/cynefin/
Артём
Там не ощущается предвзятость?
Артём
Когда компания занимается продвижением какого-то подхода, то её посыл будет склонить к этому подходу
Ilya
Читайте
Артём
Потом напишите про впечатления;)
Считаю систему, о которой говорил выше - упорядоченной сложной системой. Руководители видят запутанной или хаотичной, но моё ощущение, что такой вывод от нежелания разбираться
Артём
Эксперты есть
Артём
Нужно со всеми поговорить и описать что есть сейчас
Anonymous
Всем привет. Я хочу разобраться с основами всех подходов к разработке, описанных в заглловке чата. Из этого (http://agilemasters.ru/agile-scrum-kanban-basic-terminology/) материала я понял, что agile это не конркетная методология, а философия, система ценностей. Её детищами являются скрам и канбан. Есть книга по скраму на 600 страниц, но это сейчас не для меня, т.к. я для начала хочу понять принципи подходов, их отличия. Возможно ли это узнать из материала объёмом до 100 страниц?
Артём
Есть скрам гайд на 15 страниц
Артём
У меня вообще ощущение, что аджайл это как предвыборный политик с хорошим маркетингом, обещает как будет хорошо, а на практике относительных доказательств нет
Артём
Поделитесь?
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-RUS.pdf
Anonymous
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-RUS.pdf
Большое спасибо, 17 страниц это немного совсем, то что нужно
Алекс
Попробуй спросить у бухгалтера, зачем ей нужны сальдо по счёту
Используя подход 5 почему мы пытаемся разобраться в причинах проблемы, а не как вещах которые являются частью БухУчета.
Артём
Ага, 11% из который - оглавление и название
Ⓢⓔⓡⓖ
Используя подход 5 почему мы пытаемся разобраться в причинах проблемы, а не как вещах которые являются частью БухУчета.
Изначально говорили про сбор требований и их декомпозицию, а не про решение проблем
Алекс
Собирать требования или писать пользовательские истории используя "5 почему" революционный подход к решению вопроса.
🦠
Если не сослаться на юридически значимую, то разработчики сделают подпись как удобно - генерация пары ключей и подпись. По итогам, бизнес скажет что нам не такая нужна, а разработчики скажут что нигде не было о юридически значимой
Еще раз, это не проблема разработки, принимать решения по поводу юридически признанной подписи. Разработка это способ перевести с человеческого на машинный, если нет решения от владельца продукта — получится как всегда. Не играйте в футбол ответственности
Denis
Артём видимо интересуется работой Product Owner'а
Denis
которая описана в литературе так себе
Артём
Артём видимо интересуется работой Product Owner'а
да, это работа РО, но РО, с которыми я успел столкнуться, видят работу на уровне - я хочу что-то, а команде разобраться во всех аспектах бизнеса, связать с существующими прцессами, докомпозировать на зачачи для спринта и начать делать. получается ватерфолл в скрам-команде
Denis
почему ватерфол?
Denis
груминг бэклога делается ДО планирования спринта
Denis
декомпозиция — во время планирования
Denis
если информации совсем недостаточно — не берём в спринт, грумим дальше
Denis
в общем, чтобы не страдать от плохих PO — становитесь PO сами
Артём
потому, что в бегкоге задача непроработанная - нужно разбираться в процессах взаимодействия разных подразделений, систем, в которых они работают, понять последовательность и ограничения законодательства и в текущей функциональности, потом в эти процессы внедрить изменения, а эти изменения разложить на задачи, при этом задачи на разные системы для разных команд
Dmitry
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-RUS.pdf
Зачем постить устаревший плохой перевод, если на сайте новый есть?
Dmitry
Scrum Guide Downloads | Scrum Guides http://www.scrumguides.org/download.html
Dmitry
не судите, там не мой ресурс
Там ресурс верный, а ссылка нет
Кир
#whois Всём, привет! Зовут меня Кирилл, работаю РП в интеграторе, отучился на Agile и проникся. Дальнейшее развивитие вижу в Скрам мастера. Узнал о Вас в поиске Телеграмм. Будем знакомы)