Igor
вообще то пишет андроид
Igor
у них условие еще есть :D в марте айосник уйдет в отпуск
Igor
а задачи должны будут делатся )
Slava
А у вас swift или objc
Igor
objc
Alexey
начали про "чтобы не допустить информационных колодцев" а закончили "а задачи должны будут делатся )"
Slava
нуу objc после java так себе удовольствие, больший кайф на swift )
Igor
понятно что днище да
Igor
но андроиду это интересно
Igor
поэтому никаких возражений у него нет
Slava
ну вот то что команда находит интересным - это намного интереснее типовых процессов )
Slava
правда может быть дорого
Igor
пока что они все успевают - ну еще бизнес моделью занимаются с PO
Igor
ЗП им никто им тоже не задирал - пока проект не взлетел
Slava
а команда удаленная или в офисе?
Slava
Rodion
Ребят, нужен ваш совет. У меня следующие вопросы:
1. В команде работаем по скраму, перед планированием спринта весь бэклог задач составлен, но на оценку задач уходит слишком много времени, обычно пол рабочего дня. Хотелось бы узнать есть ли какие-то подходы, чтобы сократить это время?
2. Также как вы ограничиваете задачи по времени? Допустим, задачи больше 5 часов не берем в работу и дробим на более мелкие. Или есть более лучший подход?
3. Когда ваши прогеры делают код ревью? Вы отводите опреленный час на это или они в процессе просят своих коллег просматривать их код?
Slava
Феномен скрама, непостижимый :)
Slava
Slava
Вот недавно пробегала схема в фейсбуке. В этой схеме хорошо разобран процесс разбиения тасок, но плоха она тем, что автор опирается на "прогнозируемое время реализации", а это как известно... неизвестно!
Rodion
По опыту сторипоинты лучше? Просто часы для всех понятны.
Slava
Родион, а как у вас цель спринта звучит?
Timur
Типовая картина - вы просто не пообщались
подумалось, что компании пытаются разнообразным аджайлом заменить тупо недостаток нормального продуктивного общения в компании :-D (в противоположность command and obey)
Стас Щетинников
Ребят, нужен ваш совет. У меня следующие вопросы:
1. В команде работаем по скраму, перед планированием спринта весь бэклог задач составлен, но на оценку задач уходит слишком много времени, обычно пол рабочего дня. Хотелось бы узнать есть ли какие-то подходы, чтобы сократить это время?
2. Также как вы ограничиваете задачи по времени? Допустим, задачи больше 5 часов не берем в работу и дробим на более мелкие. Или есть более лучший подход?
3. Когда ваши прогеры делают код ревью? Вы отводите опреленный час на это или они в процессе просят своих коллег просматривать их код?
А оценка задач же входит в том числе и в груминг, а не только в planning, насколько я знаю. Поэтому по скраму делать оценку-прогноз можно вне planning, другой вопрос, что оценки обычно не нужны ;)
Стас Щетинников
Ребят, нужен ваш совет. У меня следующие вопросы:
1. В команде работаем по скраму, перед планированием спринта весь бэклог задач составлен, но на оценку задач уходит слишком много времени, обычно пол рабочего дня. Хотелось бы узнать есть ли какие-то подходы, чтобы сократить это время?
2. Также как вы ограничиваете задачи по времени? Допустим, задачи больше 5 часов не берем в работу и дробим на более мелкие. Или есть более лучший подход?
3. Когда ваши прогеры делают код ревью? Вы отводите опреленный час на это или они в процессе просят своих коллег просматривать их код?
у нас например, код-ревью - это часть разработки, т.е. нет отдельных часов для код-ревью. Оно происходит по ходу дела.
Стас Щетинников
Ребят, нужен ваш совет. У меня следующие вопросы:
1. В команде работаем по скраму, перед планированием спринта весь бэклог задач составлен, но на оценку задач уходит слишком много времени, обычно пол рабочего дня. Хотелось бы узнать есть ли какие-то подходы, чтобы сократить это время?
2. Также как вы ограничиваете задачи по времени? Допустим, задачи больше 5 часов не берем в работу и дробим на более мелкие. Или есть более лучший подход?
3. Когда ваши прогеры делают код ревью? Вы отводите опреленный час на это или они в процессе просят своих коллег просматривать их код?
2. Мы не дробим на более мелкие. Ибо зачем? Правило большого пальца, задача - это то, что можно запрограммировать, протестировать и выложить.
Slava
И ПРОДАТЬ
Dmitry
Ребят, нужен ваш совет. У меня следующие вопросы:
1. В команде работаем по скраму, перед планированием спринта весь бэклог задач составлен, но на оценку задач уходит слишком много времени, обычно пол рабочего дня. Хотелось бы узнать есть ли какие-то подходы, чтобы сократить это время?
2. Также как вы ограничиваете задачи по времени? Допустим, задачи больше 5 часов не берем в работу и дробим на более мелкие. Или есть более лучший подход?
3. Когда ваши прогеры делают код ревью? Вы отводите опреленный час на это или они в процессе просят своих коллег просматривать их код?
1) Если планирование занимает слишком много времени, есть PBR.
Но, если вы оцениваете задачи в часах – наверняка вам просто стоит перестать это делать =)
2) История может быть любого размера, но мы стараемся дробить ее на таски (обычно на планинге, но иногда и постфактум во время спринта), таска норм, если она меньше рабочего дня команды (субъективно, от часов отказались)
3) Ревью это часть DoD, так что любая история считается выполненной, только если отревьюена всей командой. Никаких отдельных часов)
Стас Щетинников
И ПРОДАТЬ
только наоборот, сначала продать, а потом запрограммировать, протестировать и выложить ;)
Slava
Это еще лучше
Slava
про просто перестать это делать, вспомнилось
https://www.youtube.com/watch?v=kKRukzAMprQ
Rodion
Спасибо за дельные советы 👍 Вопрос на сколько болезненным будет переход на стори поинты? Мне кажется людям свойственно сначало выражать в часах время выполнения задачи, а потом уже конверитировать это предположение в стори поинт?
Стас Щетинников
Dmitry
Спасибо за дельные советы 👍 Вопрос на сколько болезненным будет переход на стори поинты? Мне кажется людям свойственно сначало выражать в часах время выполнения задачи, а потом уже конверитировать это предположение в стори поинт?
а вы проведите с ними быструю оценку большого количества задач
когда на стене все развешивают, а уже постфактум оценивают
не помню как называется эта штука
Rodion
Наверное, это Backlog refinement meeting
Rodion
http://tim.com.ua/2011/09/team-estimation-game/
Rodion
А вообще по вашему опыту сколько обычно длится в среднем оценка спринта?
Rodion
В офисе
Dmitry
А вообще по вашему опыту сколько обычно длится в среднем оценка спринта?
<=4 часа для 2 недельного спринта
<=2 для недельного
Rodion
Вот у нас тоже выходит примерно 4 часа на 2-х недельный спринт.
Dmitry
ну так это норм
если НЕ больше
но если всегда 4 часа, то плохо, да)
Dmitry
таймбокс важен
Timur
а груминги сюда входят, не входят или вообще без них работаете?
Dmitry
это именно планирование
PBR - до 10% от спринта
У нас все по гайду ;)
Dmitry
> PBR - до 10% от спринта
1 час в недельном спринте
Rodion
Хочу поделится 2-мя классными книгами:
1. User Stories Applied - Mike Cohn: https://cloud.mail.ru/public/9m8N/bUprkCHeo
2. Agile Retrospectives - Esther Derby, Diana Larsen: https://cloud.mail.ru/public/29Sr/5gv7fyJxc
Возможно кому-то будут полезны.
Dmitry
не знаю вот, что мы думаем про пиратство, но у меня есть пдф Agile Retrospectives на русском
Timur
а на чем вы пдф читаете? у меня кроме киндл-формата и бумаги как-то не получается ничего читать длиннее лонгридов
Slava
А мне книжку по Канбан привезли, класс
Shamil ☘️
http://www.mann-ivanov-ferber.ru/books/kanban/ эту?
Slava
ага
Slava
вопрос кстати к тем, кто дошел до части про графики ) понятно о чем там написано или нет?
Dmitry
а на чем вы пдф читаете? у меня кроме киндл-формата и бумаги как-то не получается ничего читать длиннее лонгридов
мне ее как соиздателю прислали, я не просил
она с кучей картинок, так что в бумаге лучше или с компа
Anonymous
Друзья, собрал в одном месте 132 чата для программистов - @Chats_Developers. Пользуйтесь на здоровье.
Roman
всем привет!
Roman
вопрос к знатокам аджайла. можно ли как-то эффективно применить аджайл метод для быстрой реализации проекта с четко определенным набором задач но не в команде, а одному разработчику? даст ли это какой-то эффект? хочу повысить свою эффективность и ищу методы. с аджайлом знаком только в теории к сожалению
Slava
Slava
в ожидании знатоков agile'а
Slava
вопрос - в чем измеряется эффективность, наверное ответив на него, получится найти ответ на вопрос - как ее повысить )
Nariman
вопрос к знатокам аджайла. можно ли как-то эффективно применить аджайл метод для быстрой реализации проекта с четко определенным набором задач но не в команде, а одному разработчику? даст ли это какой-то эффект? хочу повысить свою эффективность и ищу методы. с аджайлом знаком только в теории к сожалению
для повышения самоорганизации больше pomodoro
Slava
скорее для борьбы с прокрастинацией ))
Игорь
вопрос к знатокам аджайла. можно ли как-то эффективно применить аджайл метод для быстрой реализации проекта с четко определенным набором задач но не в команде, а одному разработчику? даст ли это какой-то эффект? хочу повысить свою эффективность и ищу методы. с аджайлом знаком только в теории к сожалению
Чтобы Котлин изучить тебе не аджайл нужен
Roman
вопрос - в чем измеряется эффективность, наверное ответив на него, получится найти ответ на вопрос - как ее повысить )
вопрос возник так. недавно читал в сети какую-то историю одного девелопера, которому дали какой-то большой проект в момент когда уже сроки близко, ну обычная история. и вот там была фраза про то, что хороший опыт аджайла помог ему быстро маленькими кусочками этот проект съесть. стало интересно, мб действительно есть какой-то в этом смысл для одтельно взятого девелопера?
Slava
Роман, 90% успеха будет если просто выкинуть из требований вещи, которые не нужны )
Slava
10% от метода
Slava
писать маленькими кусочками или большими - это вопрос такой, скольскзий..
Igor
это кстати забавная проблема. Я давно ищу какой-нибудь онлайновый сервис управления проектами для своих пет-проектов и учёбы, но все они рассчитаны на команду. Стопицот лишних кнопок, функций, и ненужных вещей вроде шаринга задачи. Жаль, что нигде нет тарифа "никакой команды, хочу всё тащить один", который убирает весь командный функционал.
Roman
скорее для борьбы с прокрастинацией ))
ну у меня основная проблема часто в том, что расширяю скоуп задачи и за счет этого делаю больше и дольше, чем стоило. а эффективность измеряется в объеме сделанных задач (из исходного списка) за единицу времени
Slava
эффективность
Slava
=
Slava
прибыль растет, а цикл производства не увеличиваетс
Slava
а сколько вы задач в единицу времени делаете - это эфимерная пропускная способность
Slava
вот если камни таскать, то да
Slava
в общем agile как раз про ответ на вопрос ЧТО делать
Slava
и КАК выяснить это очень быстро