У меня давно зреет идея написать несколько статей (я думаю выйдет эдак 3-4) с детальным разбором Scrum’а.
- что работает/не работает
- что нравиться/не нравиться
- что произойдет если не выполнять что-то из описанных в Scrum’е действий
- чего не пишут в книгах по Scrum’у, но нужно знать.
Пожалуйста, отзовитесь. Стоит ли такое писать или ну его?
всё равно ж напишешь…
кстати, в книгах по скраму чёрным по белому пишут – делать надо всё. если что-то не сделать, то ой.
> всё равно ж напишешь…
>кстати, в книгах по скраму чёрным по белому пишут – делать надо всё. если что-то не сделать, >то ой.
Та да. Что я хочу написать, это какой конкретно ой будет и почему он будет.
Стоит. Пиши.
пиши. будет интересно почитать
Обязательно напиши
Конечно стоит!
присоединяюсь… потому что прочитав этот топик мне в голову пришли точно такие же слова
пиши, интересно
обязательно писать!
Ну че, где уже почитать можно?
Стоит писать!
Однозначно стоит написать. Будет интересно почитать.
интересно
А если лень писать – то можно вот эту статью откомментить, тоже интересно
http://gaperton.livejournal.com/45149.html
«Что я хочу написать, это какой конкретно ой будет и почему он будет.»
Очень интересно знать.
К слову – на сколько я понимаю, в SCRUM стандартной является практика написания юз-кейсов вроде: «Пользователь вводит то-то, нажимает такую-то кнопку и затем видит то-то».
Альтернативный подход – писать требования к ПО в виде технических функций выполняемых системой («При изменении пользователем диаграммы процесса – должна идти запись всех действий, кроме тех, которые касаются перетаскивания существующих объектов»).
Мне знакомая, работающая аналитиком в SCRUM процессе упорно двигает второй вариант.
Полагаю, что одинаковы хороши могут быть оба варианта. С юз-кейсами проще работать над простой системой, т.к. ставишь себя на место пользователя. Но с более сложными функциями – нужен функциональный подход.
?
Это был вопрос =)
Ну, скорее в стандартном SCRUM – практика написания высокоуровневых тесткейсов.
А-ля,
«Как пользователь я почу иметь возможность сохранить свой пароль.»(Это идет в user story)
Плюс, более детализировано идет в acceptance criteria.
Но в целом, Scrum пытается уйти от написания требований к ПО в техническом виде (вариант N2). Это одна из мантр agile – ‘Working software over comprehensive documentation».
Конечно, пиши. Все носятся с этим scrum’ом как с волшебной палкой.
Хочется знать, на сколько она «волшебная».
Ну, могу сразу сказать, что она не слишком волшебная.
Да-да, хочется
Обязательно пишите, причем, мое личное пожелание – с упором на последние два пункта.