прогресса никакого)

Во во

Потому что нужно «оценить» всей командой задачи. А оцениваешь не фичи(стори), а надроблнные 100500 задач

материте пээмов и дергайте руководство

Я уже даже смотрел кароче эти оценки в разрезе спринтов. Там от спринта к спринту просто нереальные перепады по обьему, что вырабатывет команда. Т.е по факту оценка ради оценки

материте пээмов и дергайте руководство

Ну все сводится к тому, что «мне нужны цифры, чтобы планировать» Хз хочу ща задвинуть попробовать - не мутить эти митинги, а просто брать пулл задач, приоритезировать, дать по 1 прогеру в порядке приоритета и чтобы прогер сам за себя сказал сколько времени у него это займет

Мне кажется будет не хуже, но явно быстрее

Я уже даже смотрел кароче эти оценки в разрезе спринтов. Там от спринта к спринту просто нереальные перепады по обьему, что вырабатывет команда. Т.е по факту оценка ради оценки

ну то есть у вас задачи на спринт берутся не по объёму, а по хотелкам

ну то есть у вас задачи на спринт берутся не по объёму, а по хотелкам

А обьем высчитать норм не получается по факту

А обьем высчитать норм не получается по факту

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

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

А оценки вы как даете? Тот кто делает или все к общей приходите?

А оценки вы как даете? Тот кто делает или все к общей приходите?

я сам на проекте подумал о фиче, прикинул объем работы и сказал его +20-30 процентов сверху

Ясно, вообщем всё свелось к тому, что надо пинать пма за те вещи, которые по факту нужны ему.... Жизнь боль. А я же хочу просто понимать задачи и кодить(

вот кстати говоря возник вопрос, правда хз можно ли на него однозначно ответить. Сколько времени по вашему надо, чтобы обсудить задач на 2 недели работы 5 прогеров? Закину заранее ответ сколько тратим мы: 2-3 часа

тут есть нюансы: - задачи до этого обсуждались? были ли грумминги всякие, бэклог рефайнтменты и т.д. - перед митингом пул задач на обсуждение уже был сформирован? - перед митингом все ознакомились с задачами или половина митинга это чтение задач вслух?

А оценки вы как даете? Тот кто делает или все к общей приходите?

стори поинты, но не оч правильно)

в целом проблема обсуждения задач на 2 недели вперед - первую неделю еще все все помнят а на след неделе уже чет как-то не очень) спасает написание критериев приемки теми кто будет делать задачу... но это сложно

ну мол если всеравно по ходу выясняется что не доконца обсудили - увеличивать время митинга точно нет смысла. больше часа уже фокус внимания будет не тот

тут есть нюансы: - задачи до этого обсуждались? были ли грумминги всякие, бэклог рефайнтменты и т.д. - перед митингом пул задач на обсуждение уже был сформирован? - перед митингом все ознакомились с задачами или половина митинга это чтение задач вслух?

Грумминг на часть, на грумминге только наброски задач Перед митингом он был сформирован на процентов 80, Таски видишь обычно сутра - митинг после обеда Вслух никто не читает, обычно это так - смотрим задачу номер 2, тишина, есть вопросы? Голосуем

Грумминг на часть, на грумминге только наброски задач Перед митингом он был сформирован на процентов 80, Таски видишь обычно сутра - митинг после обеда Вслух никто не читает, обычно это так - смотрим задачу номер 2, тишина, есть вопросы? Голосуем

не оч продуктивно....

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

найс)

не норм подход в целом

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

В моём понимании я на покере хочу видеть уже утвержденные, оговоренные, понятные таски

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

судя по фразе "голосуем" - вы там скрам покеры делаете. Ты же понимаешь что вся суть скрам покера в том что бы выявить насколько команда одинаково понимает задачу или совсем расходятся представления о сложности?

судя по фразе "голосуем" - вы там скрам покеры делаете. Ты же понимаешь что вся суть скрам покера в том что бы выявить насколько команда одинаково понимает задачу или совсем расходятся представления о сложности?

Ну типа да - пытаемся...

тут больше вопрос в том.... даются ли ответы на вопросы перед голосованием)

вот если нет - тогда надо выкидывать задачу

тут больше вопрос в том.... даются ли ответы на вопросы перед голосованием)

Неа, у нас как раз таки основное обсуждение задач на покере по факту

Хотя по идее для этого грумминги

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

С оценками тоже сложно. Часто причина завышенной оценки от чувака - я не знаю этот раздел

вполне себе. ему будет сложнее

вполне себе. ему будет сложнее

Да, но сколько ставить тогда?)

Ты же не знаешь кому она уйдёт

можно помечать себе такое и потом заставлять его работать в паре с тем кто знает, что бы трансферил знания

Ты же не знаешь кому она уйдёт

команда не общается что-ли?

Ну типо это выглядит так - набрали тасок на покер, наголосовали, пм с тл-ем расскинули зная оценки на прогеров сколько влазит

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

Хмм, интересная идея. Сейчас у нас он один

один грумминг так себе....

чем чаще тем лучше. у нас пока 2-3 раза в спринт.

А в каком виде у тебя таска на грумминг попадает? Это чисто хотелки или чтото более уже конкретное?

А в каком виде у тебя таска на грумминг попадает? Это чисто хотелки или чтото более уже конкретное?

ну тип хотелка и нарисованная оунером от руки что куда и где

иногда с мокапами

иногда без... иногда и на плэннинг не успевают мокапы сделать... но это опять же проблема с дизайнером - нам все обещают что подгонят одного

очень часто зависимости не учитываются, но зато оч легко говорить "давайте это в другой стори"...

ну тип хотелка и нарисованная оунером от руки что куда и где

Рисунок от оунера это интересно

часто эти рисунки это то что он на живом приложении прямо на звонке в зуме нарисовал

мы вообще больше всего страдаем от банального разгильдяйства... типа часто очень решения не записываем или не актуализируем описание задач)

хотя сктолько есть вариантов как это фиксить... прям уйма...

но сложно даже себя заставить)

мы вообще больше всего страдаем от банального разгильдяйства... типа часто очень решения не записываем или не актуализируем описание задач)

Ой актуализация описания это вообще боль. Часто страдаем от того что открываешь таску, а там сантабарбара с комменатами и upd

Но сейчас вроде договорились, что внося коммент - описание должны править сразу, а то потом в кучу всё собрать оч тяжко

Раз уж так сегодня вечер за задачи какойто вышел. До какого состояния обычно и кто у вас дробит стори/таски которые оцениваете?

Раз уж так сегодня вечер за задачи какойто вышел. До какого состояния обычно и кто у вас дробит стори/таски которые оцениваете?

команда дробит

ну мол, там важно зависимости понять между частями фичи. что в каком порядке делать и т.д. можно ли протестить это дело по частям

Но сейчас вроде договорились, что внося коммент - описание должны править сразу, а то потом в кучу всё собрать оч тяжко

doxygen еще не проходили? )

до какого состояния.... ну пока не кажется что вроде можно сделать)

doxygen еще не проходили? )

как это относится к описанию юзер стори и всяких критериях приемки?

это относится к документированию проекта вообще

это относится к документированию проекта вообще

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

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

ну мол, там важно зависимости понять между частями фичи. что в каком порядке делать и т.д. можно ли протестить это дело по частям

Воот - возьму тоже на заметку, у нас сейчас этим техрайтер занимается и я замечаю что это неудобно. Частенько делаешь пару задач сразу и qa тестят пару задач за раз. В итоге потом из за одного бага - может пару задач провисать

я в целом плохо отношусь к таким вещам. во всяком случае пока не вижу профита

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

сразу в головах, да. )))

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

и там так и остаёцца как правило )

сразу в головах, да. )))

нет, всякие диаграммы компонентов, чуток uml и т.д. мне вот полезно из кода разве что процессы рендрить (у нас на ивентах много чего)

ERROR: S client not available

просто проблема "исчерпывающей" докумментации в том что она устаревая. а документация в исходниках часто бесполезна для бизнеса

ну короч я против таких вещей пока мне не показали как это юзается в профит

Документация в коде она 1. Находится там где нужна 2. Изменяется вместе с кодом

и да, для бизнеса полезно всё, что может облегчить/ускорить работу

Документация в коде она 1. Находится там где нужна 2. Изменяется вместе с кодом

1. как ее читать? вот есть у тебя новый чел на проекте - с чего ему начать? какую информацию ты записываешь в коде? О том какие кастыли были расставлены с течением времени? 2. увы и ах но часто это не так

ну и опять же - вот у меня event driven архитектура. я слабо представляю как ты это все в phpdoc нормально задокументируешь)

да и блин в упор не вижу что я буду в phpdoc писать

1. как ее читать? вот есть у тебя новый чел на проекте - с чего ему начать? какую информацию ты записываешь в коде? О том какие кастыли были расставлены с течением времени? 2. увы и ах но часто это не так

1. Дал еовичку таск. Ткнул первые пару раз в те места кода где ему работать с таском. Дальше он прямо там читает документацию, описание методов. По сгенеренным докам изучает объектную модель и ищет нужный функционал чтобы не писать велосипеды. 2. угугу

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

1. Дал еовичку таск. Ткнул первые пару раз в те места кода где ему работать с таском. Дальше он прямо там читает документацию, описание методов. По сгенеренным докам изучает объектную модель и ищет нужный функционал чтобы не писать велосипеды. 2. угугу

хз, не могу представить себе такой процесс документирования что бы это было эффективно. увы. Ну может быть мне еще просто многое предстоит узнать и попробовать. Но сам так делать врядли буду

до какого состояния.... ну пока не кажется что вроде можно сделать)

Ну вот допустим пример - большая таблица на 20 столбцов с кучей фильтров. Вроде понятно что делать. Оставлять это в одной задаче и тянуть её, после тестить всё сходу или разбивать на 2-3 задачи с полями и фильтрами под эти поля?

Ну вот допустим пример - большая таблица на 20 столбцов с кучей фильтров. Вроде понятно что делать. Оставлять это в одной задаче и тянуть её, после тестить всё сходу или разбивать на 2-3 задачи с полями и фильтрами под эти поля?

а как меняется сложность?

есть разница в плане сложности - 10 фильтров или 20?

представляет ли фича ценность без какой-то части этой фичи?

есть разница в плане сложности - 10 фильтров или 20?

Обьем только меняется

представляет ли фича ценность без какой-то части этой фичи?

Выкатывать будете все вместе

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

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

но это уже сами разработчики во время спринта делают

обычно в начале

но это уже сами разработчики во время спринта делают

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

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

да, как-то так. только мы во времени не оцениваем)

у нас типа CI, trunk based dev, код должен попадать в мастер хотя бы раз в день-два)

потому не важно сколько стори занимает запилить. разработчик сам обязан выделить куски и делать их.

у нас типа CI, trunk based dev, код должен попадать в мастер хотя бы раз в день-два)

Хм надо почитать, а то пока не особо понимаю что значит код должен попадать в мастер хотябы раз в день два. У нас типо дев, мастер. Все в дев. Собрали дев в релиз, затестили регрессию - влили в мастер

И проблема в том, что в этом релизе, то густо - то пусто

https://trunkbaseddevelopment.com/

https://trunkbaseddevelopment.com/trunk1.png

https://trunkbaseddevelopment.com/

Ага спс

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

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

Ну поиграться дать фидбек - у нас решаем наличием парочки тестовых с репликами базы с прода. Собираем им туда ветку с фичой и даём играться

ну у нас тоже стэйджинг для клиентов есть, но.... тут посыл в том что деплоймент != релиз.