В Харькове на втором тренинге нас долго мучили вопросами типа: "Так кто же и когда уточняет и пережёвывает элементы беклога?".
Есть две стратегии:
*Стратегия 1. Уточнять верхнюю часть беклога во время планирования очередного спринта.*
Это работает. Но фаза планирования при этом может стать довольно болезненной и непредсказуемо растянутой. Причиной служит большое количество вопросов, на которые необходимо будет дать ответы в очень сжатые сроки (ведь между спринтами команда формально простаивает, а значит нужно как можно скорее запустить спринт).
В лучшем случае у заказчиков и команд хватает терпения доделать эту работу, правильно спланировав спринт.
В худшем же (к несчастью приходилось видеть такое на проектах) - планирование останавливается на фразе: "всё, пора. там посмотрим" и начинается спринт. Спринт, в котором нет ни чётких обещаний (заказчику и членов команды друг другу), ни детального спринт беклога с оценками времени (ибо какие там оценки если ещё 10 фич висит в воздухе!). В итоге такой ситуации не представляется возможным построить burndown, и таким образом теряется предсказуемость и адаптивность процесса.
Результат - естественно, куча недоделанных фич ибо не было чётко понятно попадают ли они в спринт или нет. Такие спринты демотивируют и заказчиков и команды.
Команды, начинающие свой Скрам-путь, обычно сталкиваются с этой проблемой довольно быстро и когда понимают, что книги не дают ответов, начинают искать ответы, применяя свой здравый смысл. Если конечно к этому моменту не утонут в незавершённых фичах и критике Скрама. * Стратегия 2. Распараллеливать разработку беклога и проработку его будущих частей*.
Столкнувшись с проблемой, описанной выше, и уделив ей достаточной внимание, команды могут принять решение прорабатывать элементы беклога для следующего спринта до завершения предыдущего.
Это работает. только естественно, на это нужно выделить время в текущем спринте. Но это не так сложно - в спринт беклоге появляются задачи типа: * уточнить фичу А, потратив не более 4 часов, ответственный Миша * С первого взгляда этот подход ничем не отличается от первого. На самом же деле здесь у команды есть чёткий план борьбы с хаосом и неопределённостью. Плюс на выходе спринта всегда есть начальный план, сделанные задачи, не сделанные задачи и уточнённый беклог, готовый для планирования следующего спринта. Ни это ли что нам нужно? * *Майк Кон (Mike Cohn) в своей последней статье разъясняет эту же задачу - задачу постепенного уточнения элементов беклога. http://www.mountaingoatsoftware.com/article/36-writing-the-product-ba...
-- Alexey Krivitsky, Coordinator of AgileUkraine.org Scrum coach at SCRUMguides.com Phone: +380 50 358 92 12 Skype: alexeykrv LinkedIn: http://www.linkedin.com/in/alexeykrivitsky
> В Харькове на втором тренинге нас долго мучили вопросами типа: > "Так кто же и когда уточняет и пережёвывает элементы беклога?".
> Есть две стратегии:
> *Стратегия 1. Уточнять верхнюю часть беклога во время планирования > очередного спринта.*
> Это работает. Но фаза планирования при этом может стать довольно > болезненной и непредсказуемо растянутой. Причиной служит большое количество > вопросов, на которые необходимо будет дать ответы в очень сжатые сроки (ведь > между спринтами команда формально простаивает, а значит нужно как можно > скорее запустить спринт).
> В лучшем случае у заказчиков и команд хватает терпения доделать эту > работу, правильно спланировав спринт.
> В худшем же (к несчастью приходилось видеть такое на проектах) - > планирование останавливается на фразе: "всё, пора. там посмотрим" и > начинается спринт. Спринт, в котором нет ни чётких обещаний (заказчику и > членов команды друг другу), ни детального спринт беклога с оценками времени > (ибо какие там оценки если ещё 10 фич висит в воздухе!). В итоге такой > ситуации не представляется возможным построить burndown, и таким образом > теряется предсказуемость и адаптивность процесса.
> Результат - естественно, куча недоделанных фич ибо не было чётко понятно > попадают ли они в спринт или нет. Такие спринты демотивируют и заказчиков и > команды.
> Команды, начинающие свой Скрам-путь, обычно сталкиваются с этой проблемой > довольно быстро и когда понимают, что книги не дают ответов, начинают искать > ответы, применяя свой здравый смысл. Если конечно к этому моменту не утонут > в незавершённых фичах и критике Скрама. > * > Стратегия 2. Распараллеливать разработку беклога и проработку его будущих > частей*.
> Столкнувшись с проблемой, описанной выше, и уделив ей достаточной > внимание, команды могут принять решение прорабатывать элементы беклога для > следующего спринта до завершения предыдущего.
> Это работает. только естественно, на это нужно выделить время в текущем > спринте. Но это не так сложно - в спринт беклоге появляются задачи типа: > * > уточнить фичу А, потратив не более 4 часов, ответственный Миша > * > С первого взгляда этот подход ничем не отличается от первого. На самом же > деле здесь у команды есть чёткий план борьбы с хаосом и неопределённостью. > Плюс на выходе спринта всегда есть начальный план, сделанные задачи, не > сделанные задачи и уточнённый беклог, готовый для планирования следующего > спринта. Ни это ли что нам нужно? > * > *Майк Кон (Mike Cohn) в своей последней статье разъясняет эту же задачу - > задачу постепенного уточнения элементов беклога.
Если планировать следующий спринт в ходе предыдущего всей командой (а иначе это не SCRUM, я так понимаю - каждый планирует/оценивает за себя ведь), то есть некоторый риск размыть выполнение работ по текущему спринту. Просто потому, что оценка иногда включает копание в коде/моделях, а при этом хочется сразу исправить очевидные ошибки (а разве бывает без них?). И вот таким нехитрым образом разработка 10 фич за 2 недели превращается в разработку 10 + 0,5 + 0,5 + 0,2 (+...) фич за 2 недели с хвостиком ( + 1 день на подчистку хвостов и завершение оценки)... А это уже расходится с идеей спринтов...
Что можно сделать? 1. Запретить править код при оценке/планировании. Вместо этого записывать баг. 2. Относить оценку/планирование поближе к концу спринта, но на последнюю задачу все же оставлять разработку фичи/фикс бага. 3. Консолидировать усилия по оценке/планированию во что-то формальное, объединяя свои усилия с SM.
Где-то так :)
В принципе, то же самое относится не только к спринтам, но и к итерациям по MSF. У нас как раз сейчас такой период - завершаем работы по текущей итерации, и оцениваем работы на следующую. :) В итоге итерации накладываются, фазы смешиваются и вроде как должны происходить всякие гадости :) Но, в отличии от SCRUM (и Agile), у нас присутствует планирование и проектирование с формальными результатами (которые как бы совсем не Agile, а очень даже old-school), и это снимает риски, шатания и метания :)
> > В Харькове на втором тренинге нас долго мучили вопросами типа: > > "Так кто же и когда уточняет и пережёвывает элементы беклога?".
> > Есть две стратегии:
> > *Стратегия 1. Уточнять верхнюю часть беклога во время планирования > > очередного спринта.*
> > Это работает. Но фаза планирования при этом может стать довольно > > болезненной и непредсказуемо растянутой. Причиной служит большое количество > > вопросов, на которые необходимо будет дать ответы в очень сжатые сроки (ведь > > между спринтами команда формально простаивает, а значит нужно как можно > > скорее запустить спринт).
> > В лучшем случае у заказчиков и команд хватает терпения доделать эту > > работу, правильно спланировав спринт.
> > В худшем же (к несчастью приходилось видеть такое на проектах) - > > планирование останавливается на фразе: "всё, пора. там посмотрим" и > > начинается спринт. Спринт, в котором нет ни чётких обещаний (заказчику и > > членов команды друг другу), ни детального спринт беклога с оценками времени > > (ибо какие там оценки если ещё 10 фич висит в воздухе!). В итоге такой > > ситуации не представляется возможным построить burndown, и таким образом > > теряется предсказуемость и адаптивность процесса.
> > Результат - естественно, куча недоделанных фич ибо не было чётко понятно > > попадают ли они в спринт или нет. Такие спринты демотивируют и заказчиков и > > команды.
> > Команды, начинающие свой Скрам-путь, обычно сталкиваются с этой > > проблемой довольно быстро и когда понимают, что книги не дают ответов, > > начинают искать ответы, применяя свой здравый смысл. Если конечно к этому > > моменту не утонут в незавершённых фичах и критике Скрама. > > * > > Стратегия 2. Распараллеливать разработку беклога и проработку его > > будущих частей*.
> > Столкнувшись с проблемой, описанной выше, и уделив ей достаточной > > внимание, команды могут принять решение прорабатывать элементы беклога для > > следующего спринта до завершения предыдущего.
> > Это работает. только естественно, на это нужно выделить время в текущем > > спринте. Но это не так сложно - в спринт беклоге появляются задачи типа: > > * > > уточнить фичу А, потратив не более 4 часов, ответственный Миша > > * > > С первого взгляда этот подход ничем не отличается от первого. На самом > > же деле здесь у команды есть чёткий план борьбы с хаосом и > > неопределённостью. Плюс на выходе спринта всегда есть начальный план, > > сделанные задачи, не сделанные задачи и уточнённый беклог, готовый для > > планирования следующего спринта. Ни это ли что нам нужно? > > * > > *Майк Кон (Mike Cohn) в своей последней статье разъясняет эту же задачу > > - задачу постепенного уточнения элементов беклога.
Я не имел в виду выполнение детального планирования следующего спринта во время предыдущего. Я имел в виду проработку (пусть даже подмножеством команды) верхней части беклога с тем, чтобы во время фактического планирования следующего спринта эти элементы беклога были I.N.V.E.S.T. (см ниже).
Я не имел в виду разбиение фич на задачи и оценивание задач - это командная задача, иначе, я согласен, это не Скрам, и есть риск размыть спринты.
> Если планировать следующий спринт в ходе предыдущего всей командой (а > иначе это не SCRUM, я так понимаю - каждый планирует/оценивает за себя > ведь), то есть некоторый риск размыть выполнение работ по текущему спринту. > Просто потому, что оценка иногда включает копание в коде/моделях, а при этом > хочется сразу исправить очевидные ошибки (а разве бывает без них?). И вот > таким нехитрым образом разработка 10 фич за 2 недели превращается в > разработку 10 + 0,5 + 0,5 + 0,2 (+...) фич за 2 недели с хвостиком ( + 1 > день на подчистку хвостов и завершение оценки)... А это уже расходится с > идеей спринтов...
> Что можно сделать? > 1. Запретить править код при оценке/планировании. Вместо этого записывать > баг. > 2. Относить оценку/планирование поближе к концу спринта, но на последнюю > задачу все же оставлять разработку фичи/фикс бага. > 3. Консолидировать усилия по оценке/планированию во что-то формальное, > объединяя свои усилия с SM.
> Где-то так :)
> В принципе, то же самое относится не только к спринтам, но и к итерациям > по MSF. У нас как раз сейчас такой период - завершаем работы по текущей > итерации, и оцениваем работы на следующую. :) В итоге итерации > накладываются, фазы смешиваются и вроде как должны происходить всякие > гадости :) Но, в отличии от SCRUM (и Agile), у нас присутствует планирование > и проектирование с формальными результатами (которые как бы совсем не Agile, > а очень даже old-school), и это снимает риски, шатания и метания :)
> > > В Харькове на втором тренинге нас долго мучили вопросами типа: > > > "Так кто же и когда уточняет и пережёвывает элементы беклога?".
> > > Есть две стратегии:
> > > *Стратегия 1. Уточнять верхнюю часть беклога во время планирования > > > очередного спринта.*
> > > Это работает. Но фаза планирования при этом может стать довольно > > > болезненной и непредсказуемо растянутой. Причиной служит большое количество > > > вопросов, на которые необходимо будет дать ответы в очень сжатые сроки (ведь > > > между спринтами команда формально простаивает, а значит нужно как можно > > > скорее запустить спринт).
> > > В лучшем случае у заказчиков и команд хватает терпения доделать эту > > > работу, правильно спланировав спринт.
> > > В худшем же (к несчастью приходилось видеть такое на проектах) - > > > планирование останавливается на фразе: "всё, пора. там посмотрим" и > > > начинается спринт. Спринт, в котором нет ни чётких обещаний (заказчику и > > > членов команды друг другу), ни детального спринт беклога с оценками времени > > > (ибо какие там оценки если ещё 10 фич висит в воздухе!). В итоге такой > > > ситуации не представляется возможным построить burndown, и таким образом > > > теряется предсказуемость и адаптивность процесса.
> > > Результат - естественно, куча недоделанных фич ибо не было чётко > > > понятно попадают ли они в спринт или нет. Такие спринты демотивируют и > > > заказчиков и команды.
> > > Команды, начинающие свой Скрам-путь, обычно сталкиваются с этой > > > проблемой довольно быстро и когда понимают, что книги не дают ответов, > > > начинают искать ответы, применяя свой здравый смысл. Если конечно к этому > > > моменту не утонут в незавершённых фичах и критике Скрама. > > > * > > > Стратегия 2. Распараллеливать разработку беклога и проработку его > > > будущих частей*.
> > > Столкнувшись с проблемой, описанной выше, и уделив ей достаточной > > > внимание, команды могут принять решение прорабатывать элементы беклога для > > > следующего спринта до завершения предыдущего.
> > > Это работает. только естественно, на это нужно выделить время в > > > текущем спринте. Но это не так сложно - в спринт беклоге появляются задачи > > > типа: > > > * > > > уточнить фичу А, потратив не более 4 часов, ответственный Миша > > > * > > > С первого взгляда этот подход ничем не отличается от первого. На самом > > > же деле здесь у команды есть чёткий план борьбы с хаосом и > > > неопределённостью. Плюс на выходе спринта всегда есть начальный план, > > > сделанные задачи, не сделанные задачи и уточнённый беклог, готовый для > > > планирования следующего спринта. Ни это ли что нам нужно? > > > * > > > *Майк Кон (Mike Cohn) в своей последней статье разъясняет эту же > > > задачу - задачу постепенного уточнения элементов беклога.
Estimatable - как это установить без оценки? Без WBS? :) Если доказать, что фичу можно оценить, но при этом не оценивать ее никак, даже приблизительно, то это будет однозначным ОБМАНОМ.
Testable - это вообще комментировать нет смысла. :)
Я надеюсь, ты понимаешь что написал глупость? Или будем начинать спорить? :) Если второе, я сразу говорю - я не прав, ты прав, делай как считаешь нужным (и сниму какую либо ответственность за свое мнение, высказанное выше). Надеюсь, сэкономил нам обоим нервы и время :)
> Я не имел в виду выполнение детального планирования следующего спринта во > время предыдущего. Я имел в виду проработку (пусть даже подмножеством > команды) верхней части беклога с тем, чтобы во время фактического > планирования следующего спринта эти элементы беклога были I.N.V.E.S.T. (см > ниже).
> Я не имел в виду разбиение фич на задачи и оценивание задач - это > командная задача, иначе, я согласен, это не Скрам, и есть риск размыть > спринты.
> > Если планировать следующий спринт в ходе предыдущего всей командой (а > > иначе это не SCRUM, я так понимаю - каждый планирует/оценивает за себя > > ведь), то есть некоторый риск размыть выполнение работ по текущему спринту. > > Просто потому, что оценка иногда включает копание в коде/моделях, а при этом > > хочется сразу исправить очевидные ошибки (а разве бывает без них?). И вот > > таким нехитрым образом разработка 10 фич за 2 недели превращается в > > разработку 10 + 0,5 + 0,5 + 0,2 (+...) фич за 2 недели с хвостиком ( + 1 > > день на подчистку хвостов и завершение оценки)... А это уже расходится с > > идеей спринтов...
> > Что можно сделать? > > 1. Запретить править код при оценке/планировании. Вместо этого > > записывать баг. > > 2. Относить оценку/планирование поближе к концу спринта, но на последнюю > > задачу все же оставлять разработку фичи/фикс бага. > > 3. Консолидировать усилия по оценке/планированию во что-то формальное, > > объединяя свои усилия с SM.
> > Где-то так :)
> > В принципе, то же самое относится не только к спринтам, но и к итерациям > > по MSF. У нас как раз сейчас такой период - завершаем работы по текущей > > итерации, и оцениваем работы на следующую. :) В итоге итерации > > накладываются, фазы смешиваются и вроде как должны происходить всякие > > гадости :) Но, в отличии от SCRUM (и Agile), у нас присутствует планирование > > и проектирование с формальными результатами (которые как бы совсем не Agile, > > а очень даже old-school), и это снимает риски, шатания и метания :)
> > > > В Харькове на втором тренинге нас долго мучили вопросами типа: > > > > "Так кто же и когда уточняет и пережёвывает элементы беклога?".
> > > > Есть две стратегии:
> > > > *Стратегия 1. Уточнять верхнюю часть беклога во время планирования > > > > очередного спринта.*
> > > > Это работает. Но фаза планирования при этом может стать довольно > > > > болезненной и непредсказуемо растянутой. Причиной служит большое количество > > > > вопросов, на которые необходимо будет дать ответы в очень сжатые сроки (ведь > > > > между спринтами команда формально простаивает, а значит нужно как можно > > > > скорее запустить спринт).
> > > > В лучшем случае у заказчиков и команд хватает терпения доделать эту > > > > работу, правильно спланировав спринт.
> > > > В худшем же (к несчастью приходилось видеть такое на проектах) - > > > > планирование останавливается на фразе: "всё, пора. там посмотрим" и > > > > начинается спринт. Спринт, в котором нет ни чётких обещаний (заказчику и > > > > членов команды друг другу), ни детального спринт беклога с оценками времени > > > > (ибо какие там оценки если ещё 10 фич висит в воздухе!). В итоге такой > > > > ситуации не представляется возможным построить burndown, и таким образом > > > > теряется предсказуемость и адаптивность процесса.
> > > > Результат - естественно, куча недоделанных фич ибо не было чётко > > > > понятно попадают ли они в спринт или нет. Такие спринты демотивируют и > > > > заказчиков и команды.
> > > > Команды, начинающие свой Скрам-путь, обычно сталкиваются с этой > > > > проблемой довольно быстро и когда понимают, что книги не дают ответов, > > > > начинают искать ответы, применяя свой здравый смысл. Если конечно к этому > > > > моменту не утонут в незавершённых фичах и критике Скрама. > > > > * > > > > Стратегия 2. Распараллеливать разработку беклога и проработку его > > > > будущих частей*.
> > > > Столкнувшись с проблемой, описанной выше, и уделив ей достаточной > > > > внимание, команды могут принять решение прорабатывать элементы беклога для > > > > следующего спринта до завершения предыдущего.
> > > > Это работает. только естественно, на это нужно выделить время в > > > > текущем спринте. Но это не так сложно - в спринт беклоге появляются задачи > > > > типа: > > > > * > > > > уточнить фичу А, потратив не более 4 часов, ответственный Миша > > > > * > > > > С первого взгляда этот подход ничем не отличается от первого. На > > > > самом же деле здесь у команды есть чёткий план борьбы с хаосом и > > > > неопределённостью. Плюс на выходе спринта всегда есть начальный план, > > > > сделанные задачи, не сделанные задачи и уточнённый беклог, готовый для > > > > планирования следующего спринта. Ни это ли что нам нужно? > > > > * > > > > *Майк Кон (Mike Cohn) в своей последней статье разъясняет эту же > > > > задачу - задачу постепенного уточнения элементов беклога.
будем спорить для поиска правды. и давай без перехода на личности, ок?
1. estimatable я уверен, что те, кто ревьювают фичу и готовят её к планированию вполне могут прикинуть вместиться ли они в спринт или нет. на много ли больше она других фич, которые уже делали или нет. на данном этапе этого будет достаточно (где "достаточность" - ключевое слово). они могут собраться и, играя в planning poker, дать ей оценку. для начала этого будет достаточно.
также у некоторых команда есть практика оценивать фичи из беклога до начала планирования спринта.
мы сейчас говорим о подготовке фичи к планированию. не о разбиении её на задачи и т.п. так что wbs тут неуместен, даже со смайликом. :)
2. testable
каждая история (или фича) должна обладать критериями приёма (acceptable criteria), только при наличии их можно понять границы фичи и прикинуть, что нужно будет сделать, чтоб её реализовать.
> Estimatable - как это установить без оценки? Без WBS? :) Если доказать, > что фичу можно оценить, но при этом не оценивать ее никак, даже > приблизительно, то это будет однозначным ОБМАНОМ.
> Testable - это вообще комментировать нет смысла. :)
> Я надеюсь, ты понимаешь что написал глупость? Или будем начинать спорить? > :) Если второе, я сразу говорю - я не прав, ты прав, делай как считаешь > нужным (и сниму какую либо ответственность за свое мнение, высказанное > выше). Надеюсь, сэкономил нам обоим нервы и время :)
> > Я не имел в виду выполнение детального планирования следующего спринта > > во время предыдущего. Я имел в виду проработку (пусть даже подмножеством > > команды) верхней части беклога с тем, чтобы во время фактического > > планирования следующего спринта эти элементы беклога были I.N.V.E.S.T. > > (см ниже).
> > Я не имел в виду разбиение фич на задачи и оценивание задач - это > > командная задача, иначе, я согласен, это не Скрам, и есть риск размыть > > спринты.
> > > Если планировать следующий спринт в ходе предыдущего всей командой (а > > > иначе это не SCRUM, я так понимаю - каждый планирует/оценивает за себя > > > ведь), то есть некоторый риск размыть выполнение работ по текущему спринту. > > > Просто потому, что оценка иногда включает копание в коде/моделях, а при этом > > > хочется сразу исправить очевидные ошибки (а разве бывает без них?). И вот > > > таким нехитрым образом разработка 10 фич за 2 недели превращается в > > > разработку 10 + 0,5 + 0,5 + 0,2 (+...) фич за 2 недели с хвостиком ( + 1 > > > день на подчистку хвостов и завершение оценки)... А это уже расходится с > > > идеей спринтов...
> > > Что можно сделать? > > > 1. Запретить править код при оценке/планировании. Вместо этого > > > записывать баг. > > > 2. Относить оценку/планирование поближе к концу спринта, но на > > > последнюю задачу все же оставлять разработку фичи/фикс бага. > > > 3. Консолидировать усилия по оценке/планированию во что-то формальное, > > > объединяя свои усилия с SM.
> > > Где-то так :)
> > > В принципе, то же самое относится не только к спринтам, но и к > > > итерациям по MSF. У нас как раз сейчас такой период - завершаем работы по > > > текущей итерации, и оцениваем работы на следующую. :) В итоге итерации > > > накладываются, фазы смешиваются и вроде как должны происходить всякие > > > гадости :) Но, в отличии от SCRUM (и Agile), у нас присутствует планирование > > > и проектирование с формальными результатами (которые как бы совсем не Agile, > > > а очень даже old-school), и это снимает риски, шатания и метания :)
> > > > > В Харькове на втором тренинге нас долго мучили вопросами типа: > > > > > "Так кто же и когда уточняет и пережёвывает элементы беклога?".
> > > > > Есть две стратегии:
> > > > > *Стратегия 1. Уточнять верхнюю часть беклога во время планирования > > > > > очередного спринта.*
> > > > > Это работает. Но фаза планирования при этом может стать довольно > > > > > болезненной и непредсказуемо растянутой. Причиной служит большое количество > > > > > вопросов, на которые необходимо будет дать ответы в очень сжатые сроки (ведь > > > > > между спринтами команда формально простаивает, а значит нужно как можно > > > > > скорее запустить спринт).
> > > > > В лучшем случае у заказчиков и команд хватает терпения доделать > > > > > эту работу, правильно спланировав спринт.
> > > > > В худшем же (к несчастью приходилось видеть такое на проектах) - > > > > > планирование останавливается на фразе: "всё, пора. там посмотрим" и > > > > > начинается спринт. Спринт, в котором нет ни чётких обещаний (заказчику и > > > > > членов команды друг другу), ни детального спринт беклога с оценками времени > > > > > (ибо какие там оценки если ещё 10 фич висит в воздухе!). В итоге такой > > > > > ситуации не представляется возможным построить burndown, и таким образом > > > > > теряется предсказуемость и адаптивность процесса.
> > > > > Результат - естественно, куча недоделанных фич ибо не было чётко > > > > > понятно попадают ли они в спринт или нет. Такие спринты демотивируют и > > > > > заказчиков и команды.
> > > > > Команды, начинающие свой Скрам-путь, обычно сталкиваются с этой > > > > > проблемой довольно быстро и когда понимают, что книги не дают ответов, > > > > > начинают искать ответы, применяя свой здравый смысл. Если конечно к этому > > > > > моменту не утонут в незавершённых фичах и критике Скрама. > > > > > * > > > > > Стратегия 2. Распараллеливать разработку беклога и проработку его > > > > > будущих частей*.
Я полностью на стороне Алексея в данном споре. Целью такой процедуры
является прежде всего уменьшение интервала между спринтами и
уменьшения времени на планирование спринта. Очень часто в этом
принимает участие только малая часть команды (чтобы не отрывать
остальных от текущей разработки). При этом снижается качество
проработки стори из бэклога, но зато и не появляется рисков по
текущему спринту. Иногда продукт оунеру интересна экспертная оценка
(которая никак не будет влиять на саму стори, а только на ее
приоритет) по набору стори из бэклога. Данная оценка является довольно
субъективной, но если команда довольно высокого уровня, то она может
подсказать продукт оунеру какие стори выбрать для следующего спринта,
а какие не стоит. По поводу Testable приведу пример. Мы используем для
каждой стори дополнительное поле 'How to demo', которое как раз дает
первоначальное представление о тестировании. Это поле также очень
помогает при планировании. Так вот обработка верхней части бэклога и
продумывание описания для данного поля является задачей довольно
трудоемкой, поэтому на помощь продукт оунеру могут придти члены
команды. Опять таки не в полном составе, потому что это не
планирование, а всего лишь примерный набросок. А спорить это дело
неблагодарное. :)
On Feb 16, 1:14 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> будем спорить для поиска правды. и давай без перехода на личности, ок?
> 1. estimatable
> я уверен, что те, кто ревьювают фичу и готовят её к планированию вполне
> могут прикинуть вместиться ли они в спринт или нет. на много ли больше она
> других фич, которые уже делали или нет. на данном этапе этого будет
> достаточно (где "достаточность" - ключевое слово). они могут собраться и,
> играя в planning poker, дать ей оценку. для начала этого будет достаточно.
> также у некоторых команда есть практика оценивать фичи из беклога до начала
> планирования спринта.
> мы сейчас говорим о подготовке фичи к планированию. не о разбиении её на
> задачи и т.п. так что wbs тут неуместен, даже со смайликом. :)
> 2. testable
> каждая история (или фича) должна обладать критериями приёма (acceptable
> criteria), только при наличии их можно понять границы фичи и прикинуть, что
> нужно будет сделать, чтоб её реализовать.
> > Estimatable - как это установить без оценки? Без WBS? :) Если доказать,
> > что фичу можно оценить, но при этом не оценивать ее никак, даже
> > приблизительно, то это будет однозначным ОБМАНОМ.
> > Testable - это вообще комментировать нет смысла. :)
> > Я надеюсь, ты понимаешь что написал глупость? Или будем начинать спорить?
> > :) Если второе, я сразу говорю - я не прав, ты прав, делай как считаешь
> > нужным (и сниму какую либо ответственность за свое мнение, высказанное
> > выше). Надеюсь, сэкономил нам обоим нервы и время :)
> > > Я не имел в виду выполнение детального планирования следующего спринта
> > > во время предыдущего. Я имел в виду проработку (пусть даже подмножеством
> > > команды) верхней части беклога с тем, чтобы во время фактического
> > > планирования следующего спринта эти элементы беклога были I.N.V.E.S.T.
> > > (см ниже).
> > > Я не имел в виду разбиение фич на задачи и оценивание задач - это
> > > командная задача, иначе, я согласен, это не Скрам, и есть риск размыть
> > > спринты.
> > > > Если планировать следующий спринт в ходе предыдущего всей командой (а
> > > > иначе это не SCRUM, я так понимаю - каждый планирует/оценивает за себя
> > > > ведь), то есть некоторый риск размыть выполнение работ по текущему спринту.
> > > > Просто потому, что оценка иногда включает копание в коде/моделях, а при этом
> > > > хочется сразу исправить очевидные ошибки (а разве бывает без них?). И вот
> > > > таким нехитрым образом разработка 10 фич за 2 недели превращается в
> > > > разработку 10 + 0,5 + 0,5 + 0,2 (+...) фич за 2 недели с хвостиком ( + 1
> > > > день на подчистку хвостов и завершение оценки)... А это уже расходится с
> > > > идеей спринтов...
> > > > Что можно сделать?
> > > > 1. Запретить править код при оценке/планировании. Вместо этого
> > > > записывать баг.
> > > > 2. Относить оценку/планирование поближе к концу спринта, но на
> > > > последнюю задачу все же оставлять разработку фичи/фикс бага.
> > > > 3. Консолидировать усилия по оценке/планированию во что-то формальное,
> > > > объединяя свои усилия с SM.
> > > > Где-то так :)
> > > > В принципе, то же самое относится не только к спринтам, но и к
> > > > итерациям по MSF. У нас как раз сейчас такой период - завершаем работы по
> > > > текущей итерации, и оцениваем работы на следующую. :) В итоге итерации
> > > > накладываются, фазы смешиваются и вроде как должны происходить всякие
> > > > гадости :) Но, в отличии от SCRUM (и Agile), у нас присутствует планирование
> > > > и проектирование с формальными результатами (которые как бы совсем не Agile,
> > > > а очень даже old-school), и это снимает риски, шатания и метания :)
> > > > > > В Харькове на втором тренинге нас долго мучили вопросами типа:
> > > > > > "Так кто же и когда уточняет и пережёвывает элементы беклога?".
> > > > > > Есть две стратегии:
> > > > > > *Стратегия 1. Уточнять верхнюю часть беклога во время планирования
> > > > > > очередного спринта.*
> > > > > > Это работает. Но фаза планирования при этом может стать довольно
> > > > > > болезненной и непредсказуемо растянутой. Причиной служит большое количество
Ну, собственно, я уже ответил. Могу и промолчать :)
Но лучше объясню свою позицию. Не для спора :)
Я не написал подробно ранее - то что вы описали как "прикинуть" я не считаю оценкой. Вот и все. Если вы счичтаете оценкой, и ваш product owner разделяет это мнение - не вижу никаких причин называть это по-другому. Но только у вас, без обобщений на весь SCRUM/Agile/что-нибудь_еще ;)
То же самое касается тестирования. Я различаю понятия "критерии успешности реализации заданий проекта и достижения его целей" и "тест-кейс". Для меня (и, если я правильно понимаю позицию создателей MSF - для них) эти понятия из двух разных областей деятельности, из двух разных секторов ответственности. Вполне возможно, в ваших проектах они совпадают на 100%, и вы к этому привыкли. Но, видимо, у нас разные проекты.
P.S. Правда - у каждого своя. Без перехода на личности ;)
P.P.S. Прошу прощения, Алексей, если я тебя задел. Я не умею обсуждать "чистые" абстракции, я не ученый. И не преподаватель :) Поэтому строю общение всегда на личных примерах и с личностями, а не с их идеями/концепциями.
> будем спорить для поиска правды. и давай без перехода на личности, ок?
> 1. estimatable > я уверен, что те, кто ревьювают фичу и готовят её к планированию вполне > могут прикинуть вместиться ли они в спринт или нет. на много ли больше она > других фич, которые уже делали или нет. на данном этапе этого будет > достаточно (где "достаточность" - ключевое слово). они могут собраться и, > играя в planning poker, дать ей оценку. для начала этого будет достаточно.
> также у некоторых команда есть практика оценивать фичи из беклога до > начала планирования спринта.
> мы сейчас говорим о подготовке фичи к планированию. не о разбиении её на > задачи и т.п. так что wbs тут неуместен, даже со смайликом. :)
> 2. testable
> каждая история (или фича) должна обладать критериями приёма (acceptable > criteria), только при наличии их можно понять границы фичи и прикинуть, что > нужно будет сделать, чтоб её реализовать.
> > Estimatable - как это установить без оценки? Без WBS? :) Если доказать, > > что фичу можно оценить, но при этом не оценивать ее никак, даже > > приблизительно, то это будет однозначным ОБМАНОМ.
> > Testable - это вообще комментировать нет смысла. :)
> > Я надеюсь, ты понимаешь что написал глупость? Или будем начинать > > спорить? :) Если второе, я сразу говорю - я не прав, ты прав, делай как > > считаешь нужным (и сниму какую либо ответственность за свое мнение, > > высказанное выше). Надеюсь, сэкономил нам обоим нервы и время :)
> > > Я не имел в виду выполнение детального планирования следующего спринта > > > во время предыдущего. Я имел в виду проработку (пусть даже подмножеством > > > команды) верхней части беклога с тем, чтобы во время фактического > > > планирования следующего спринта эти элементы беклога были I.N.V.E.S.T. > > > (см ниже).
> > > Я не имел в виду разбиение фич на задачи и оценивание задач - это > > > командная задача, иначе, я согласен, это не Скрам, и есть риск размыть > > > спринты.
> > > > Если планировать следующий спринт в ходе предыдущего всей командой > > > > (а иначе это не SCRUM, я так понимаю - каждый планирует/оценивает за себя > > > > ведь), то есть некоторый риск размыть выполнение работ по текущему спринту. > > > > Просто потому, что оценка иногда включает копание в коде/моделях, а при этом > > > > хочется сразу исправить очевидные ошибки (а разве бывает без них?). И вот > > > > таким нехитрым образом разработка 10 фич за 2 недели превращается в > > > > разработку 10 + 0,5 + 0,5 + 0,2 (+...) фич за 2 недели с хвостиком ( + 1 > > > > день на подчистку хвостов и завершение оценки)... А это уже расходится с > > > > идеей спринтов...
> > > > Что можно сделать? > > > > 1. Запретить править код при оценке/планировании. Вместо этого > > > > записывать баг. > > > > 2. Относить оценку/планирование поближе к концу спринта, но на > > > > последнюю задачу все же оставлять разработку фичи/фикс бага. > > > > 3. Консолидировать усилия по оценке/планированию во что-то > > > > формальное, объединяя свои усилия с SM.
> > > > Где-то так :)
> > > > В принципе, то же самое относится не только к спринтам, но и к > > > > итерациям по MSF. У нас как раз сейчас такой период - завершаем работы по > > > > текущей итерации, и оцениваем работы на следующую. :) В итоге итерации > > > > накладываются, фазы смешиваются и вроде как должны происходить всякие > > > > гадости :) Но, в отличии от SCRUM (и Agile), у нас присутствует планирование > > > > и проектирование с формальными результатами (которые как бы совсем не Agile, > > > > а очень даже old-school), и это снимает риски, шатания и метания :)
> > > > > > В Харькове на втором тренинге нас долго мучили вопросами типа: > > > > > > "Так кто же и когда уточняет и пережёвывает элементы беклога?".
> > > > > > Есть две стратегии:
> > > > > > *Стратегия 1. Уточнять верхнюю часть беклога во время > > > > > > планирования очередного спринта.*
> > > > > > Это работает. Но фаза планирования при этом может стать довольно > > > > > > болезненной и непредсказуемо растянутой. Причиной служит большое количество > > > > > > вопросов, на которые необходимо будет дать ответы в очень сжатые сроки (ведь > > > > > > между спринтами команда формально простаивает, а значит нужно как можно > > > > > > скорее запустить спринт).
Николай. То что ты описал, с моей колокольни выглядит как экспернтая помощь Product Owner-у в его работе - составить Product backlog как можно точнее, описать каждую user story как можно качественнее, расставить приоритеты как можно эффективнее. Это все прекрасно. Но это не является целью спринта. Скажу даже больше - это идет в разрез с целью спринта. Это противоположные по своей природе цели, за которые отвечают участники с разной компетенцией. Противопоставление этих компетенций и является основой данной методологии (впрочем, как структура ролевых кластеров в MSF). Я ничего не имею против экспертной помощи. Но "помощь", которая определяет работу в следующем спринте (верхние задачи беклога) - это уже не точка зрения Product Owner-а, а точка зрения разработчика, и она неминуемо размоет спринт, уменьшит формализацию user story, повлияет на понимание самим Product Owner-ом тех рамок, которые достигнуты в текущем спринте, и будут достигнуты в следующем. Да еще и (при регулярной организации подобной "оценки") сделает такую ключевую позицию как Product Owner полностью зависимой от позиции разработчика. Разве это Agile? :)
16.02.08, Alimenkou Nikolay <lumii.subscri...@gmail.com> написал(а):
> Я полностью на стороне Алексея в данном споре. Целью такой процедуры > является прежде всего уменьшение интервала между спринтами и > уменьшения времени на планирование спринта. Очень часто в этом > принимает участие только малая часть команды (чтобы не отрывать > остальных от текущей разработки). При этом снижается качество > проработки стори из бэклога, но зато и не появляется рисков по > текущему спринту. Иногда продукт оунеру интересна экспертная оценка > (которая никак не будет влиять на саму стори, а только на ее > приоритет) по набору стори из бэклога. Данная оценка является довольно > субъективной, но если команда довольно высокого уровня, то она может > подсказать продукт оунеру какие стори выбрать для следующего спринта, > а какие не стоит. По поводу Testable приведу пример. Мы используем для > каждой стори дополнительное поле 'How to demo', которое как раз дает > первоначальное представление о тестировании. Это поле также очень > помогает при планировании. Так вот обработка верхней части бэклога и > продумывание описания для данного поля является задачей довольно > трудоемкой, поэтому на помощь продукт оунеру могут придти члены > команды. Опять таки не в полном составе, потому что это не > планирование, а всего лишь примерный набросок. А спорить это дело > неблагодарное. :)
> On Feb 16, 1:14 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com> > wrote: > > будем спорить для поиска правды. и давай без перехода на личности, ок?
> > 1. estimatable > > я уверен, что те, кто ревьювают фичу и готовят её к планированию вполне > > могут прикинуть вместиться ли они в спринт или нет. на много ли больше > она > > других фич, которые уже делали или нет. на данном этапе этого будет > > достаточно (где "достаточность" - ключевое слово). они могут собраться > и, > > играя в planning poker, дать ей оценку. для начала этого будет > достаточно.
> > также у некоторых команда есть практика оценивать фичи из беклога до > начала > > планирования спринта.
> > мы сейчас говорим о подготовке фичи к планированию. не о разбиении её на > > задачи и т.п. так что wbs тут неуместен, даже со смайликом. :)
> > 2. testable
> > каждая история (или фича) должна обладать критериями приёма (acceptable > > criteria), только при наличии их можно понять границы фичи и прикинуть, > что > > нужно будет сделать, чтоб её реализовать.
> > > Estimatable - как это установить без оценки? Без WBS? :) Если > доказать, > > > что фичу можно оценить, но при этом не оценивать ее никак, даже > > > приблизительно, то это будет однозначным ОБМАНОМ.
> > > Testable - это вообще комментировать нет смысла. :)
> > > Я надеюсь, ты понимаешь что написал глупость? Или будем начинать > спорить? > > > :) Если второе, я сразу говорю - я не прав, ты прав, делай как > считаешь > > > нужным (и сниму какую либо ответственность за свое мнение, высказанное > > > выше). Надеюсь, сэкономил нам обоим нервы и время :)
> > > > Я не имел в виду выполнение детального планирования следующего > спринта > > > > во время предыдущего. Я имел в виду проработку (пусть даже > подмножеством > > > > команды) верхней части беклога с тем, чтобы во время фактического > > > > планирования следующего спринта эти элементы беклога были > I.N.V.E.S.T. > > > > (см ниже).
> > > > Я не имел в виду разбиение фич на задачи и оценивание задач - это > > > > командная задача, иначе, я согласен, это не Скрам, и есть риск > размыть > > > > спринты.
> > > > > Если планировать следующий спринт в ходе предыдущего всей > командой (а > > > > > иначе это не SCRUM, я так понимаю - каждый планирует/оценивает за > себя > > > > > ведь), то есть некоторый риск размыть выполнение работ по текущему > спринту. > > > > > Просто потому, что оценка иногда включает копание в коде/моделях, > а при этом > > > > > хочется сразу исправить очевидные ошибки (а разве бывает без > них?). И вот > > > > > таким нехитрым образом разработка 10 фич за 2 недели превращается > в > > > > > разработку 10 + 0,5 + 0,5 + 0,2 (+...) фич за 2 недели с хвостиком > ( + 1 > > > > > день на подчистку хвостов и завершение оценки)... А это уже > расходится с > > > > > идеей спринтов...
> > > > > Что можно сделать? > > > > > 1. Запретить править код при оценке/планировании. Вместо этого > > > > > записывать баг. > > > > > 2. Относить оценку/планирование поближе к концу спринта, но на > > > > > последнюю задачу все же оставлять разработку фичи/фикс бага. > > > > > 3. Консолидировать усилия
Мне кажеться, вопрос недостаточно сфокусирован : Ты говориш о продакт беклоге или спринт беклоге ?
Ты хочешь иметь детализацию наиболее приоритетных задач продакт беклога - то есть, того, что нужно сделать для того, чтобы было понимание для разработчиков, что означает, что фитча сделана? - Какие самые важные задачи для заказчика?
Или
Детализация спринт беклога? - то есть, детальный план того, как команда собирается атаковать задачу, и какие есть риски ?
По описанию я вижу в предложенных стратегиях и то, и другое. Мое мнение, что эти две разные задачи, требующие разных подходов для их решения
> В Харькове на втором тренинге нас долго мучили вопросами типа: > "Так кто же и когда уточняет и пережёвывает элементы беклога?".
> Есть две стратегии:
> *Стратегия 1. Уточнять верхнюю часть беклога во время планирования > очередного спринта.*
> Это работает. Но фаза планирования при этом может стать довольно > болезненной и непредсказуемо растянутой. Причиной служит большое количество > вопросов, на которые необходимо будет дать ответы в очень сжатые сроки (ведь > между спринтами команда формально простаивает, а значит нужно как можно > скорее запустить спринт).
> В лучшем случае у заказчиков и команд хватает терпения доделать эту > работу, правильно спланировав спринт.
> В худшем же (к несчастью приходилось видеть такое на проектах) - > планирование останавливается на фразе: "всё, пора. там посмотрим" и > начинается спринт. Спринт, в котором нет ни чётких обещаний (заказчику и > членов команды друг другу), ни детального спринт беклога с оценками времени > (ибо какие там оценки если ещё 10 фич висит в воздухе!). В итоге такой > ситуации не представляется возможным построить burndown, и таким образом > теряется предсказуемость и адаптивность процесса.
> Результат - естественно, куча недоделанных фич ибо не было чётко понятно > попадают ли они в спринт или нет. Такие спринты демотивируют и заказчиков и > команды.
> Команды, начинающие свой Скрам-путь, обычно сталкиваются с этой проблемой > довольно быстро и когда понимают, что книги не дают ответов, начинают искать > ответы, применяя свой здравый смысл. Если конечно к этому моменту не утонут > в незавершённых фичах и критике Скрама. > * > Стратегия 2. Распараллеливать разработку беклога и проработку его будущих > частей*.
> Столкнувшись с проблемой, описанной выше, и уделив ей достаточной > внимание, команды могут принять решение прорабатывать элементы беклога для > следующего спринта до завершения предыдущего.
> Это работает. только естественно, на это нужно выделить время в текущем > спринте. Но это не так сложно - в спринт беклоге появляются задачи типа: > * > уточнить фичу А, потратив не более 4 часов, ответственный Миша > * > С первого взгляда этот подход ничем не отличается от первого. На самом же > деле здесь у команды есть чёткий план борьбы с хаосом и неопределённостью. > Плюс на выходе спринта всегда есть начальный план, сделанные задачи, не > сделанные задачи и уточнённый беклог, готовый для планирования следующего > спринта. Ни это ли что нам нужно? > * > *Майк Кон (Mike Cohn) в своей последней статье разъясняет эту же задачу - > задачу постепенного уточнения элементов беклога.
> Мне кажеться, вопрос недостаточно сфокусирован : > Ты говориш о продакт беклоге или спринт беклоге ?
> Ты хочешь иметь детализацию наиболее приоритетных задач продакт беклога - > то есть, того, что нужно сделать для того, чтобы было понимание для > разработчиков, что означает, что фитча сделана? - Какие самые важные задачи > для заказчика?
Я говорил про product backlog. И про стратегии проработки историй, которые с высокой вероятностью войдут в следующий(ие) спринты
2 стратегия рекомендуема на CSM (по крайней мере, рекомендовалась на тренинге Йенса Остергаарда) Йенс рекомендовал также выделять порядка 5 % времени на нее Йенс также рекомендовал не начинать спринт планнинг, если продукт оунер не подготовлен.
Для второй стратегии требуется наличие релиз беклога, который, как показывает моя практика, далеко не всегда возможно иметь (иногда заказчики больше ценность гибкость планирования, чем наличие релиз беклога)
Возможное (не идеальное решение) Стратегия разбиения внешнего и внутреннего планинга. Бить планнинг на 2 части - приоритизация задач на неделю с продакт оунер. Затем люди подписываються на задачи, и подкомманды, подписанные на задачи, формализируют их, а затем проводять дизайн сессии для планирования (такая стратегия работает в условиях работы над несколькими потоками задач, из которых выбираються задачи для испольнения).Также команда определяет, какая часть работ может быть выполнена за неделю, и дает коммитмент на нее
Стратегия комманды продакт оунера. Выделяется команда для продакт оунера, которая для (порядка 30 %) существенно новых/значимых задач готовит функциональные спецификации задач на следующую итерацию. Это стратегия использовалась в Patient Keeper, и описана у Сазерланда
> > Мне кажеться, вопрос недостаточно сфокусирован : > > Ты говориш о продакт беклоге или спринт беклоге ?
> > Ты хочешь иметь детализацию наиболее приоритетных задач продакт беклога > > - то есть, того, что нужно сделать для того, чтобы было понимание для > > разработчиков, что означает, что фитча сделана? - Какие самые важные задачи > > для заказчика?
> Я говорил про product backlog. И про стратегии проработки историй, которые > с высокой вероятностью войдут в следующий(ие) спринты
Мы пробовали разные стратегии на разных этапах "зрелости" в
использовании Скрама. Могу рассказать, как мы делаем это сейчас (т.е.
в последних спринтах).
- Между спринтами вся команда занимается оценкой задач, появившихся в
бэклоге в течение последнего спринта. Точнее, всех неоцененных задач,
которые, по мнение команды, должны войти в ближайший релиз и по
которым более-менее ясны требования (настолько, что можно их брать в
спринт и оценивать complexity, по которой мы дальше считаем velocity).
Это удобно еще и тем, что можно этим занять все свободное время
команды между спринтами, в паузах между sprint review/retrospective/
planning митингами.
- Если по какой-то задаче требования либо необходимость в ближайшем
спринте не ясны, переводим в статус More Info, с указанием списка
вопросов, которые нужно выяснить, и у кого выяснить. Чаще всего
вопросы адресованы продакт оунеру.
- Список задач в статусе More Info подвергается отдельному review
командой, после того, как по остальным задачам comlexity проставлена.
Это занимает не много времени. Дальше:
+ Если мы считаем, что какая-та задача может иметь высокий
приоритет, сразу назначаем того, кто в ближайшее время (до
планирования следующего спринта) посылает обозначенный список вопросов
компетентному человеку (обычно, как уже сказано, это PO).
+ По некоторым задачам требуется обсуждение внутри команды, мы
проводим это обсуждение тут же. Только до тех пор, пока не становятся
яснее scope и требования.
+ Выяснение подробностей по остальным задачам в статусе More Info
остается на ответственности SM. Он неспешно посылает запросы и
напоминания по ним продакт овнеру в течени ближайшего спринта. При
необходимости подключаются члены команды для уточнения технических
деталей. Но это, на текущий момент, не отнимает у них столько времени,
чтобы требовалась какая-то специальная поддержка в процессе.
- Конечно, есть задачи, где уточнение требований само по себе - целое
дело. И необходимо назначить на это полноценного девелопера или там
архитектора. В таком случае задача разбивается на две, с зависимостью
между ними. Первая задача - выяснение требований, берем ее в ближайший
спринт. Обычно задачи очень разумного размера. Вторая - остается в
статусе More Info до завершения первой.
- В случае, если требования или scope "немного неясны", но оценку
complexity сделать можно, смело берем задачу в спринт, с учетом
времени, необходимого на выяснение оставшихся подробностей. Подзадачу
по выяснению подробностей обычно обозначаем на доске бумажкой
специального цвета как impediment - ибо время ответа продакт оунера не
всецело зависит от команды, это как бы внешний фактор.
Вот. Интересно мнение о таком подходе уважаемой общественности. У нас
он вроде бы пока работает.
On Feb 16, 1:54 am, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> > В Харькове на втором тренинге нас долго мучили вопросами типа:
> > "Так кто же и когда уточняет и пережёвывает элементы беклога?".
> > Есть две стратегии:
> > *Стратегия 1. Уточнять верхнюю часть беклога во время планирования
> > очередного спринта.*
> > Это работает. Но фаза планирования при этом может стать довольно
> > болезненной и непредсказуемо растянутой. Причиной служит большое количество
> > вопросов, на которые необходимо будет дать ответы в очень сжатые сроки (ведь
> > между спринтами команда формально простаивает, а значит нужно как можно
> > скорее запустить спринт).
> > В лучшем случае у заказчиков и команд хватает терпения доделать эту
> > работу, правильно спланировав спринт.
> > В худшем же (к несчастью приходилось видеть такое на проектах) -
> > планирование останавливается на фразе: "всё, пора. там посмотрим" и
> > начинается спринт. Спринт, в котором нет ни чётких обещаний (заказчику и
> > членов команды друг другу), ни детального спринт беклога с оценками времени
> > (ибо какие там оценки если ещё 10 фич висит в воздухе!). В итоге такой
> > ситуации не представляется возможным построить burndown, и таким образом
> > теряется предсказуемость и адаптивность процесса.
> > Результат - естественно, куча недоделанных фич ибо не было чётко понятно
> > попадают ли они в спринт или нет. Такие спринты демотивируют и заказчиков и
> > команды.
> > Команды, начинающие свой Скрам-путь, обычно сталкиваются с этой проблемой
> > довольно быстро и когда понимают, что книги не дают ответов, начинают искать
> > ответы, применяя свой здравый смысл. Если конечно к этому моменту не утонут
> > в незавершённых фичах и критике Скрама.
> > *
> > Стратегия 2. Распараллеливать разработку беклога и проработку его будущих
> > частей*.
> > Столкнувшись с проблемой, описанной выше, и уделив ей достаточной
> > внимание, команды могут принять решение прорабатывать элементы беклога для
> > следующего спринта до завершения предыдущего.
> > Это работает. только естественно, на это нужно выделить время в текущем
> > спринте. Но это не так сложно - в спринт беклоге появляются задачи типа:
> > *
> > уточнить фичу А, потратив не более 4 часов, ответственный Миша
> > *
> > С первого взгляда этот подход ничем не отличается от первого. На самом же
> > деле здесь у команды есть чёткий план борьбы с хаосом и неопределённостью.
> > Плюс на выходе спринта всегда есть начальный план, сделанные задачи, не
> > сделанные задачи и уточнённый беклог, готовый для планирования следующего
> > спринта. Ни это ли что нам нужно?
> > *
> > *Майк Кон (Mike Cohn) в своей последней статье разъясняет эту же задачу -
> > задачу постепенного уточнения элементов беклога.
> Estimatable - как это установить без оценки? Без WBS? :) Если доказать, что > фичу можно оценить, но при этом не оценивать ее никак, даже приблизительно, > то это будет однозначным ОБМАНОМ.
Если история довольно маленькая, и команда компетентна в её отношении, то оценка прекрасно делается с помощью игры в planning poker. Причём большая точность в оценке отдельных историй не так и важна: в покере используют обычно что-то вроде 0,1/2,1,2,3,5,8,13,20,40,100. Точность увеличивается с ростом кол-ва историй (ошибки взаимно компенсируются).
Если история слишком большая для того, чтоб быть оценена - её разбивают на меньшие. Если история слишком сложная, то разбивают её на две истории - первая - это research, вторая - собственно реализация, и для того, чтобы спринты были предсказуемы, их имеет смысл помещать в разные спринты.
Обещание, что некоторая фича будет сделана за 12.75 человеко-дней будет обманом в любом случае, даже если до этого проведён research. Можно лишь предполагать, что у команды будет примерно одинаковое velocity. Риск отдельного спринта невелик за счёт его малости, так что не нужно бояться за небольшое отклонение от оценки.
Мне кажется, что такая боязнь может симптомом слишком прохладных как для Agile отношений с заказчиком, и/или того же внутри организации - есть риск сильно поплатиться за неверно сформулированное ожидание, поэтому приходится защищать себя глубоким research-ем, тщательным планированием, подробной документацией, буферами в сроках etc. Под прохладными отношениями я понимаю ограниченную либо некачественную коммуникацию.
> 2008/2/16 Артур Ракицкий <arty...@gmail.com>: > > Estimatable - как это установить без оценки? Без WBS? :) Если доказать, > что > > фичу можно оценить, но при этом не оценивать ее никак, даже > приблизительно, > > то это будет однозначным ОБМАНОМ.
> Если история довольно маленькая, и команда компетентна в её отношении, > то оценка прекрасно делается с помощью игры в planning poker. Причём > большая точность в оценке отдельных историй не так и важна: в покере > используют обычно что-то вроде 0,1/2,1,2,3,5,8,13,20,40,100. Точность > увеличивается с ростом кол-ва историй (ошибки взаимно компенсируются).
> Если история слишком большая для того, чтоб быть оценена - её > разбивают на меньшие. > Если история слишком сложная, то разбивают её на две истории - первая > - это research, вторая - собственно реализация, и для того, чтобы > спринты были предсказуемы, их имеет смысл помещать в разные спринты.
> Обещание, что некоторая фича будет сделана за 12.75 человеко-дней > будет обманом в любом случае, даже если до этого проведён research. > Можно лишь предполагать, что у команды будет примерно одинаковое > velocity. Риск отдельного спринта невелик за счёт его малости, так что > не нужно бояться за небольшое отклонение от оценки.
> Мне кажется, что такая боязнь может симптомом слишком прохладных как > для Agile отношений с заказчиком, и/или того же внутри организации - > есть риск сильно поплатиться за неверно сформулированное ожидание, > поэтому приходится защищать себя глубоким research-ем, тщательным > планированием, подробной документацией, буферами в сроках etc. Под > прохладными отношениями я понимаю ограниченную либо некачественную > коммуникацию.
Алексей Тигарев, я так и не понял к чему вы рассказали истину, заложенную в основу SCRUM? Мы на оценку выделяем время всей команды (покер, исследование с обсуждениями - форма не важна), или не выделяем (про мелкие шаблонные истории вообще нет смысла говорить - их оценка не рисковая)?
Если выделяем, и делаем это МЕЖДУ спринтами - нет вопросов, подход работает великолепно, все занимаются своим делом :-), короткие спринты снимают риски.
Если выделяем, и делаем это ВО ВРЕМЯ спринтов - то читайте мой пост двухдневной давности. И риски здесь выходят за рамки разной производительности. Появляются НОВЫЕ риски, о которых я и написал.
Пока что, только Юрий описал практический подход, который решает (у них в проекте) описанную проблему не выходя за рамки SCRUM.
Мы поступаем аналогично, разделяя реализацию требования на исследование (с детальной оценкой) и разработку. При этом оперируем рисками и рамками в ходе фазы разработки (это MSF, не SCRUM). То есть, начиная проект мы заведомо знаем, что часть требований будет исследована и оценена, но выйдет за рамки итерации (а может и проекта). Также, исследование может быть неуспешным. Декларируем это в рисках.
Но мы обязательно формализируем результаты исследования (либо в виде протестированного и принятого Продактом прототипа, либо в виде логического-физического дизайна), и таким образом в разработку поступает две части требования, или по сути - два требования - функциональное (или бизнес-) и техническое/системное. В SCRUM этих понятий не существует. Не существует подчинений уровней требований. Не существует меры покрытия бизнес-заданий историями. Формально не существует. Неформально, в голове у Poduct Owner - может быть :)
Этот системный конфликт я и хотел подчеркнуть. И, как по мне, лучше дольше планировать между спринтами, чем рисковать, ввязывая PO в выполнение спринта, и отнимая у него часть ответственности за Product backlog... Вот такая вот финальная мысль :)
> 2008/2/16 Артур Ракицкий <arty...@gmail.com>: > > Estimatable - как это установить без оценки? Без WBS? :) Если доказать, > что > > фичу можно оценить, но при этом не оценивать ее никак, даже > приблизительно, > > то это будет однозначным ОБМАНОМ.
> Если история довольно маленькая, и команда компетентна в её отношении, > то оценка прекрасно делается с помощью игры в planning poker. Причём > большая точность в оценке отдельных историй не так и важна: в покере > используют обычно что-то вроде 0,1/2,1,2,3,5,8,13,20,40,100. Точность > увеличивается с ростом кол-ва историй (ошибки взаимно компенсируются).
> Если история слишком большая для того, чтоб быть оценена - её > разбивают на меньшие. > Если история слишком сложная, то разбивают её на две истории - первая > - это research, вторая - собственно реализация, и для того, чтобы > спринты были предсказуемы, их имеет смысл помещать в разные спринты.
> Обещание, что некоторая фича будет сделана за 12.75 человеко-дней > будет обманом в любом случае, даже если до этого проведён research. > Можно лишь предполагать, что у команды будет примерно одинаковое > velocity. Риск отдельного спринта невелик за счёт его малости, так что > не нужно бояться за небольшое отклонение от оценки.
> Мне кажется, что такая боязнь может симптомом слишком прохладных как > для Agile отношений с заказчиком, и/или того же внутри организации - > есть риск сильно поплатиться за неверно сформулированное ожидание, > поэтому приходится защищать себя глубоким research-ем, тщательным > планированием, подробной документацией, буферами в сроках etc. Под > прохладными отношениями я понимаю ограниченную либо некачеств&
|
