У меня давно зреет идея написать несколько статей (я думаю выйдет эдак 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’ом как с волшебной палкой.
Хочется знать, на сколько она «волшебная».
Ну, могу сразу сказать, что она не слишком волшебная.
Да-да, хочется
Обязательно пишите, причем, мое личное пожелание — с упором на последние два пункта.