Цели спринта команда же задаёт каждый раз сама

Задачи спринта, они же из бэклога спринта, а цель работоспособное ПО

Из бэклога не задачи, а user story (давайте не будем терминологию смешивать, чтобы не запутаться). Целью у скрам-команд не в IT не может быть работоспособное ПО, поэтому нельзя всех под одну гребёнку (не будем сейчас затрагивать вопрос целесообразности скрама в не-IT)

Из бэклога не задачи, а user story (давайте не будем терминологию смешивать, чтобы не запутаться). Целью у скрам-команд не в IT не может быть работоспособное ПО, поэтому нельзя всех под одну гребёнку (не будем сейчас затрагивать вопрос целесообразности скрама в не-IT)

А двигают по скрам доске что?

Что есть скрам-доска?

Канбан != Скрам. Насколько я знаю, скрамгайд вообще не регламентирует декомпозицию US и инструментарий для таск-трекинга

А бывает скрам без юзер стори?

А документирование остается на уровне юзерстори?

Это же фреймворк, в теории может быть, я думаю)

В гайде о нем ничего не было)

А документирование остается на уровне юзерстори?

Скрамгайд документирование не описывает, насколько я помню

Т.е. на усмотрение команды

Спринт же подразумевает в результате какой-то полезный инкремент. Если инкремент требует тестирование, то логично включать его в спринт

Ну, допустим включили тестировщика. И уже в самом конце он находит глобальные ошибки, несовместимые с (жизнью) целями спринта. Что делать? Расширять время спринта? Считать миссию проваленной и начинать заново?

в самом конце? а по-хорошему должен найти в начале

Ну, допустим включили тестировщика. И уже в самом конце он находит глобальные ошибки, несовместимые с (жизнью) целями спринта. Что делать? Расширять время спринта? Считать миссию проваленной и начинать заново?

Я на истину не претендую, лучше коучей спросить, в этом чате такие были, вроде) Я бы запустила "перепланирование спринта" - не помню точное название, но короче в скрамгайде это описано. Типа понять, что нужно, переопределить цели, накидать новых US и т.п. Но это не оч хорошая практика, поэтому такие внезапности, имхо, лучше не допускать) Вообще можно просто US по доработке в следующие спринты взять. Насколько я помню, релизы не обязательно совпадают со спринтами

в самом конце? а по-хорошему должен найти в начале

По-хорошему - это не гибко) Всякое бывает, в конце тоже могут найти

Извиняюсь. Случайно)

В скраме нет user stories

Перепланирования спринта тоже не бывает

Бывает закончили спринт, посмотрели на велосити в ноль, обсудили как такогот не допустить в будущем, начали новый спринт

Ну, допустим включили тестировщика. И уже в самом конце он находит глобальные ошибки, несовместимые с (жизнью) целями спринта. Что делать? Расширять время спринта? Считать миссию проваленной и начинать заново?

Идея с короткими итерациями не в том, что это маленький ватерфолл, а что максимальное количество активности, которые генерят риск делается вначале. То есть тестировщик должен максимально рано включаться в рамках спринта.

Вообще на отсутствие ошибок больше всего влияет не тестировщик, а то как код пишется, сопровождается, дорабатывается. Если вдруг случаются глобальные фейлы, то уже надо разбираться с первопричинами.

Ойойой Чего-то тут все смешалось Кони, люди, истории, спринты, цели, планирование

кони, люди, истории, спринты - все что вы хотите знать о современных подходах в change and run management

Ойойой Чего-то тут все смешалось Кони, люди, истории, спринты, цели, планирование

Попробуем разрулить) 1. US (user story) - это один из вариантов, как вести backlog producta. PO (product owner) волен вести его так как его угодно, главное чтобы Scrum Team понимала этот артефакт. 2. Sprint - временной промежуток за который Scrum Team подписывается доставить ценность заказчику. Ценность сильно варьируется от этапа развития продукта, это могут быть как новые функции в продукте, так и улучшения старых. 3. Про тестирование ребята выше описали, тут решает сама команда, если получается за спринт доставить ценность без тестировщика, своими силами, то окей. Если нет, то включайте его в команду. 4. Оценка элементов backlog. Тут так же нет единственно верного ответа. Мерийте в чём вам удобнее: часы, сторипоинты, попугаи и т.д. Главное понимать зачем вы это измеряете? ИМХО лучшим измерителем является довольный заказчик.

5. Релизы, так же не обязаны совпадать с окончанием спринта. НО инкремент в конце спринта, должен быть готовым к использованию и соответствовать критериям Готовности, которые определяет Scrum Team. 6. Перепланироваться нельзя, так как такого термина нет в Скрам Гайде, можно прервать Спринт, если его цель потяряла свою актуальность. После начинается новый спринт.

А кто-то работает четко по гайдам? Если да, то, какой у вас продукт и как часто происходят релизы конечному пользователю?

У нас SaaS, если количество релизов поделить на количество дней в году, то получается по 2-3 релиза в день

не могу сказать что это хорошо, но изначально рельсы сделали такими :)

четко по гайдам работает мало, больше - стремятся, еще больше - скатываются в "по гайду, НО"

2-3 релиза в день - жестко, у вас терпеливые тестировщики))

Почему жестко-то, маленькие баг-фиксы проскакивают, тестировщиков никто не ждет

выясняется что в IE какая-то бяка, которую не регистрирует наш автотрекер ошибок

разработчик пофиксил и оно улетело

тестировщик никогда в жизни такие баги не найдет

как только вы даете программисту кнопку для релиза, у него на психологическом уровне появляется новая связь в мозгу - я ответственнен за релиз

и каждый раз перед нажатием подтягивает его предыдущий негативный опыт прямо перед нажатием

это творит чудеса

как только вы даете программисту кнопку для релиза, у него на психологическом уровне появляется новая связь в мозгу - я ответственнен за релиз

+

А кто имел опыт использования DevProm? Они, в том числе, позиционируют себя, как замену Confluence: http://devprom.ru/features/Wiki-%D0%B4%D0%BB%D1%8F-%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%D0%BC%D0%B8

Замена confluence

А кто-то работает четко по гайдам? Если да, то, какой у вас продукт и как часто происходят релизы конечному пользователю?

мы работаем по гайду b2b SaaS Релизы раз в день-два

Что входит в гайд?

я имел в виду скрам-гайд

DevProm себя так противопоставляет wiki:

DevProm себя так противопоставляет wiki:

Тут есть некоторая сермяжная правда. Вопрос в том у всех ли требования до буквы соответствуют коду? На мой взгляд единственной нормальной документацией должен быть исходный код. Все остальное очень быстро устаревает и для поддержки достаточно иметь общие документы архитектурного плана. Wiki подходит для этого как нельзя лучше. Другое дело, если жесткий вотерфолл - талмуды ТЗ и тест-кейсов, а в коде непонятно что, тронь неизвестно где рванет. В последнем случае с wiki сложнее

есть сложные алгоритмы

есть код-стандарты

есть справочная информация по компании

Какие проблемы хранить это в wiki?

Это не отменяет того, что основной документацией является исходный код (включая unit-тесты)

Я к тому, что вики нужна

И код должен быть простым и понятным, но нет крайности в этом вопросе :)

А я не говорил, что не нужна. Я говорил, что не нужна сложная система управления требованиями коей wiki не является.

ну тут нюанс наверное в слове сложная

конфлюенс функциональная, не сложная :)

Денис Бесков думаю в курсе про требования и девпром

Я прочитал текст по devprom, чем он лучше. Основная идея - не позволяет организовать работу большого управления аналитики, которое уверено, что система работает именно так как они написали на бумаге

На практике аналитик этот тот же разработчик, только хорошо знающий предметную область и имеющий развитые коммуникационные навыки. Отсюда следует и подход к формированию документации. Тут Сергей Баранов хорошо написал про главную деталь в танке. К документации это тоже относится.

Ну безусловно - лучший код, ненаписанный код, лучшая документация - ненаписанная :)

https://vc.ru/p/kanbanchi-app

Да. Про русский язык многие забывают.

https://m.habrahabr.ru/post/319232/ злые менеджеры и плохой скрам

https://m.habrahabr.ru/post/319232/ злые менеджеры и плохой скрам

Там комментарии очень в тему. Сразу понятен уровень "внедренцев". По моему опыту, правильное внедрение гибкой методологии управления как раз ведёт к повышению мотивации разработчиков и большей ответственности за продукт. Ну и к таким результатам приведет неверное внедрение любой системы управления.

https://vimeo.com/110554082

Это про тоже самое, но с точки зрения очень крутого разработчика

Мне нравится логика изложения "все было хорошо и тут решили внедрить agile"

то что люди уходят - это не всегда плохо :D

https://m.habrahabr.ru/post/319232/ злые менеджеры и плохой скрам

это кстати очень тру стори и самое что забавное - дело не во внедренцах совсем :D в конце лета у нас произошла похожая ситуация и разрабы начали бомбить из за скрама. в итоге выяснилось что скрам тут вообще не при делах :D но со стороны разрабов виноват был именно скрам и именно тот человек который его принес - самое что забавное этот человек уже скрам в компании не внедрял у разработчиков :)

Удобный способ найти виноватого :)

А как в вашем случае команде продавали Скрам, Игорь? Ну то есть была какая-та сессия на которой проблемы были привязына к действиям и из этого следовало, что Скрам в принципе может эти проблемы решать ?

У нас скажем так CEO принес agile как решение проблем которые возникли в разработке проекта. Изначально делали проект без особого менеджмента и разработчики были предоставлены сами себе. Это вылилось в кучу проблем со сроками, организацией работы (две команды которые кидали друг в друга какахи). Потом CEO посоветовался с друзьями у которых был agile в головах и на деле. Скрам продавали как решение проблем с разработкой продукта.

Там уже был нанят коуч, который нанял первого скраммастера

Сессии были, но в головах разрабов это все складывается в надуманные проблемы

надуманные проблемы и надуманный аджайл :D

сколько человек в штате?

сейчас порядка 11 человек

это чисто дев тим

в худшее время их было порядка 18 человек разделенных на две DT

Ну то есть психологического момента в головах разработчиков - "да нам точно scrum надо" не было?

Или хотя бы - "да давайте попробуем, посмотрим чо получится"? :)

в среднем по больнице было "давайте попробуем"