прочитав статью — первым делом захотел проверить именно habrastorage. посмотрел crossdomain, cookie, whois — все в порядке… потом увидел этот комментарий)) спасибо за пост!
definition of done — это да, но мы никак не могли «закрывать» истории из-за того, что на последних этапах продукт овнер или индуские тестировщики, вдруг, начинали делать более глубокий анализ по задаче (тем самым раздувая ее, и оттягивая acceptance).
нам помогло введение понятия «acceptance criteria». это не тест кейсы, но и не абстрактное «все сделано — когда все сделано». Это шаги/проверки, которые сделает продукт овнер чтобы убедиться что нами все реализовано правильно. Это помагает нам формализировать/конкретизировать «definition of done» на уровне одной отдельной истории.
«acceptance criteria» -это не отмазка для девелопера. мы пишем тест кейсы, стараемся оборачивать старый код в юнит-тесты, и активно юзаем селениум. просто так, разработчику легче понять чего именно от него хотят)
буквально через 2 недели после перехода на скрам(4 мес. назад), мы столкнулись с такой-же проблеммой. но мы сразу ввели 2 дополнительные роли аналитиков. (это девелоперы. каждую неделю один из них меняется. кто хочет тот и аналитик). это позволяет нам более качественно делать оценки по стори. кроме этого — после выставления более-менее правильных поинтов: продукт-овнеру легче приориетизировать беклог.
хоть наше начальство (умышленно) не комментирует наш подход, часть команды согласна с тем чтобы провести нормальную аналитику по истории/дефекту — до того как приступать к выполнению. зато после нормального анализа — задачи решаются на порядок качественее и «в одно касание».
правильно говорит dimasol. Если вы как скрам-мастер или тех/тим лид, видите — что комманда плавает по этой стори — не включайте ее. из своего опыта скажу, что 80% из них затягиваются и рвут итерацию. как результат — вы или рестартуете спринт(вы это делаете?) или включаете доп. истории… понятно, что после этого burndown диаграмма и планирование — становятся очередной формальностью… ))
это как у врача: он смотрит на ваши анализы и потом уже назначает лечение, а не наоборот)
не отказывайтесь от аналитики. скрам — это набор добрых советов и немного самоорганизации.
у вас всегда есть пространство для експериментов. заведите аналитиков) меняйте правила
ИМХО, не всегда стоит добавлять новые синтаксисы. если существует формат который более широко развит/применяется то прежде всего нужно найти аргументы почему не использовать именно его.
Даже если речь идет не о javascript-oriented-side, JSON — легко трансформируется в тот же XML. А дальше делайте с ним все что угодно… и главное быстро!
REST — удобен для визуального восприятия, прозрачности интерфесов и для администрирования сервера.
(5коп)
если нет, то что этому человеку говорит слово drupal?
хотя с доменом реально прогадали) Что-то подсказывает, что (после появления полей,) к концу 2012 года концепция нод может(должна?) еще более серьезно трансформироваться. чует мое сердечко что писать 8-ку начнут уже в конце след. года. и дописывать будут именно фрейморк под ноды!
кусал бэты и релиз-кандидаты семерки вместе со вьювами. вкусно)
но…
в ЦЦК нехватает полей-ссылок на ноды (как японял — ждем отдельные проекты drupal.org/project/cck).
редактирование вьювов без фаербага — полный пипец (все работает, но не все отображается. как я их понимаю)) )
хотя вцелом — очень быстро. друпал стал заметно быстрее и удобнее.
встроеная ццк так и зовет поиграть с таксонмией) вобщем комфортно тем кто умеет лепить структуры «на лету». ничего нового, просто все под рукой.
веб заросы на крон теперь идут с доп. секретным параметром/аргументом/ключем (наверное, чтобы хакеры не злоупотребляли, да и вообще это нормально)
почти уже все продвинутые темы/субтемы готовы.
Основные модули имеют приличные дев-версии(они просто ждут релиза, а для многих это равносильно готовому релиз-кандидату!).
вы совершенно правы. но с этим ничего не поделаешь, разве что пропускать все странички через свою веб-прокси. это безопасно для внешнего сайта, удобно для хабра, зато накладно по ресурсам.
впрочем, как я понимаю, проблематика вопроса в другом — наверное(?) из-за постов-ссылок идет большой отток посетителей. они читают чужой сайт, после этого закрывают вкладку и уже не возвращаются обратно на хабровскую страничку.
нам помогло введение понятия «acceptance criteria». это не тест кейсы, но и не абстрактное «все сделано — когда все сделано». Это шаги/проверки, которые сделает продукт овнер чтобы убедиться что нами все реализовано правильно. Это помагает нам формализировать/конкретизировать «definition of done» на уровне одной отдельной истории.
«acceptance criteria» -это не отмазка для девелопера. мы пишем тест кейсы, стараемся оборачивать старый код в юнит-тесты, и активно юзаем селениум. просто так, разработчику легче понять чего именно от него хотят)
буквально через 2 недели после перехода на скрам(4 мес. назад), мы столкнулись с такой-же проблеммой. но мы сразу ввели 2 дополнительные роли аналитиков. (это девелоперы. каждую неделю один из них меняется. кто хочет тот и аналитик). это позволяет нам более качественно делать оценки по стори. кроме этого — после выставления более-менее правильных поинтов: продукт-овнеру легче приориетизировать беклог.
хоть наше начальство (умышленно) не комментирует наш подход, часть команды согласна с тем чтобы провести нормальную аналитику по истории/дефекту — до того как приступать к выполнению. зато после нормального анализа — задачи решаются на порядок качественее и «в одно касание».
правильно говорит dimasol. Если вы как скрам-мастер или тех/тим лид, видите — что комманда плавает по этой стори — не включайте ее. из своего опыта скажу, что 80% из них затягиваются и рвут итерацию. как результат — вы или рестартуете спринт(вы это делаете?) или включаете доп. истории… понятно, что после этого burndown диаграмма и планирование — становятся очередной формальностью… ))
это как у врача: он смотрит на ваши анализы и потом уже назначает лечение, а не наоборот)
не отказывайтесь от аналитики. скрам — это набор добрых советов и немного самоорганизации.
у вас всегда есть пространство для експериментов. заведите аналитиков) меняйте правила
Аххх… если бы он еще мог этот JSON загонять обратно в JavaScript…
Даже если речь идет не о javascript-oriented-side, JSON — легко трансформируется в тот же XML. А дальше делайте с ним все что угодно… и главное быстро!
REST — удобен для визуального восприятия, прозрачности интерфесов и для администрирования сервера.
Все начали готовиться)))
если нет, то что этому человеку говорит слово drupal?
хотя с доменом реально прогадали) Что-то подсказывает, что (после появления полей,) к концу 2012 года концепция нод может(должна?) еще более серьезно трансформироваться. чует мое сердечко что писать 8-ку начнут уже в конце след. года. и дописывать будут именно фрейморк под ноды!
ну как минимум это будет drupal 7.5))))
кусал бэты и релиз-кандидаты семерки вместе со вьювами. вкусно)
но…
в ЦЦК нехватает полей-ссылок на ноды (как японял — ждем отдельные проекты drupal.org/project/cck).
редактирование вьювов без фаербага — полный пипец (все работает, но не все отображается. как я их понимаю)) )
хотя вцелом — очень быстро. друпал стал заметно быстрее и удобнее.
встроеная ццк так и зовет поиграть с таксонмией) вобщем комфортно тем кто умеет лепить структуры «на лету». ничего нового, просто все под рукой.
веб заросы на крон теперь идут с доп. секретным параметром/аргументом/ключем (наверное, чтобы хакеры не злоупотребляли, да и вообще это нормально)
почти уже все продвинутые темы/субтемы готовы.
Основные модули имеют приличные дев-версии(они просто ждут релиза, а для многих это равносильно готовому релиз-кандидату!).
Это другой друпал! Он… еще более аккуратный ;)
Спасибо что проделали такой обьем работы!!! Тема — более чем актуальна!
впрочем, как я понимаю, проблематика вопроса в другом — наверное(?) из-за постов-ссылок идет большой отток посетителей. они читают чужой сайт, после этого закрывают вкладку и уже не возвращаются обратно на хабровскую страничку.
то можно открывать «окно с фреймом»…