0. MariaTemchina 837 13.11.18 16:21 Сейчас в теме

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

12-ый принцип Agile-манифеста, как известно, гласит: "Каждый раз в конце заранее определенного интервала времени команда размышляет, как повысить результативность своей работы, и затем вносит коррективы в процессы." Попробуем разобраться, как это стоит, а как не стоит делать на практике.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. slozhenikin_com 13.11.18 17:02 Сейчас в теме
Классная статья! Хотелось бы немного добавить.

При каких условиях у вас ничего не получится?
- команда не следит за выполнением выработанных решений.

Как контролируем это мы:
1. Все выработанные решения превращаются в задачи и вешаются в бэклог с конкретным исполнителем (если возможно назначить);
2. Скрам-мастер контролирует исполнение задач и напоминает команде о том что выработанные решения не исполняются;
3. После открытия ретроспективы можно проверять выполнение домашних заданий с прошлых ретро.

Плюс неочевидное: ретроспективу можно проводить на конкретные мероприятия скрама. Например, ретроспектива на обзор спринта или ретроспектива на ретроспективу. И эту тему стоит обозначить в начале мероприятия.

Для начинающих скрам-мастеров есть такая штукенция - ретромат https://retromat.org/ru/
Там своеобразная рулетка по проведению ретроспектив, если все уже испробовали и команда скучает и перестает генерить проблемы.
MariaTemchina; Vladimir Litvinenko; +2 Ответить
2. acanta 67 13.11.18 17:51 Сейчас в теме
(1) Если вы так делаете, у вас должна быть статистика причин неисполнения решений. (доля отмазок / найденных неоптимальностей / таймауты, превышающие объективно необходимые сроки, необходимость серьезной подготовительной работы и что-либо другое).

Мне очень понравилась аналогия APDEX и Agile. Клиент назначает требуемую максимальную продолжительность выполнения операции в APDEX.
Так же клиент имеет право установить срок выполнения в Agile какого то участка работ ("К вечеру надо создать.").
Но для того чтобы подобная оценка была возможной, должны быть результаты "замеров" именно этой операции или "предыдущего спринта" именно в этом направлении.
3. slozhenikin_com 13.11.18 18:30 Сейчас в теме
(2)
(1) Если вы так делаете, у вас должна быть статистика причин неисполнения решений. (доля отмазок / найденных неоптимальностей / таймауты, превышающие необходимые сроки, необходимость серьезной подготовительной работы и что-либо другое)


Как в сериале "Кремниевая долина" один из героев говорил: "Стало похоже на работу":)

Тут надо от целей: если цель найти виновного и наказать, тогда можно самому по конкретным исполнителям вести реестр. Но это не совсем по скраму. Если цель воспитать ответственность в команде, то, возможно, стоит подсветить проблему и команда сама решит что ей делать с этим. Дело такое...

Так же клиент имеет право установить срок выполнения в Agile какого то участка работ ("К вечеру надо создать.").
Но для того чтобы подобная оценка была возможной, должны быть результаты "замеров" именно этой операции или "предыдущего спринта" именно в этом направлении.


Вы про какой фреймворк? В скраме есть спринт и вкидывать туда "к вечеру надо создать" не совсем правильно, если говорите о velocity, то возможно. Если речь о канбан, то там есть типы задач, которые могут иметь разный lead time и этот lead time желательно улучшать.
8. MariaTemchina 837 14.11.18 10:04 Сейчас в теме
(3)
Вы про какой фреймворк? В скраме есть спринт и вкидывать туда "к вечеру надо создать" не совсем правильно, если говорите о velocity, то возможно. Если речь о канбан, то там есть типы задач, которые могут иметь разный lead time и этот lead time желательно улучшать.

Не знаю о чем говорит автор комментария, но в Канбан-систему такой подход как раз хорошо вписывается - что может быть "срочная" задача, и специальная плавательная дорожка для срочных задач с небольшим WIP-лимитом (допустим, одна или две). Мы так делали, хотя в итоге пришли от физической разметки дорожек к цветовой разметке и разметки в виде тэгов - так оказалось удобнее.
4. acanta 67 13.11.18 18:38 Сейчас в теме
Насколько оправдано разделять поток задач на разные фреймворки? Часть работ (грубо говоря разработка) отдается под канбан, а текучка ложится под velocity?
И главное - как вы бы предложили совмещать указанные вами цели в процессе работы?
Поиск виновного, оценка ущерба и наказание - это типичный бизнес процесс, никак не связанный с процессом разработки, но возможно присутствующий перманентно в атмосфере (как часть корпоративного стиля "Никто не выйдет отсюда чистеньким") и прорабатывающий каждую обнаруженную ошибку по цепи взаимодействий и причинно-следственных связей.
В таком случае возникает вопрос, является ли 1с (в любом ее виде) самодостаточным мотивом для того, чтобы плодотворно работать в подобной атмосфере?
И насколько разработчики 1с (защищая собственные интересы даже не столько авторские, сколько в вопросах об ответственности в причинении ущерба третьим лицам) это, по-вашему, понимают.
5. slozhenikin_com 13.11.18 18:41 Сейчас в теме
(4)
Насколько оправдано разделять поток задач на разные фреймворки? Часть работ (грубо говоря разработка) отдается под канбан, а текучка ложится под velocity?


Да философия разная просто. И метрики.
6. slozhenikin_com 13.11.18 18:59 Сейчас в теме
(4) не совсем понятно о чем Вы.
7. acanta 67 13.11.18 19:02 Сейчас в теме
(6) о том, что думать некогда.
9. MariaTemchina 837 14.11.18 10:08 Сейчас в теме
(4)
фреймворки? Часть работ (грубо говоря разработка) отдается под канбан, а текучка ложится под velocity?

По мне так наоборот, текучкой логичнее управлять по Канбан (ибо задачи прибегают в неустановленное время, и подгонять релизы к фиксированным датам не всегда удобно), а разработкой, которую можно заранее спланировать и структурировать, можно управлять по скраму (хотя по мне я Канбан больше люблю). Но совмещать одно и другое - это же неудобно!... Чем дальше вам удалось уйти от многозадачности, тем лучше команде работается. Другой вопрос, что есть идеальная модель, а есть суровая реальность, когда разработчики вынуждены сидеть на техподдержке...
16. Rustig 1195 15.11.18 18:49 Сейчас в теме
(4)
В таком случае возникает вопрос, является ли 1с (в любом ее виде) самодостаточным мотивом для того, чтобы плодотворно работать в подобной атмосфере?
И насколько разработчики 1с (защищая собственные интересы даже не столько авторские, сколько в вопросах об ответственности в причинении ущерба третьим лицам) это, по-вашему, понимают.

вот тут ответ https://infostart.ru/video/w878512/
10. acanta 67 14.11.18 18:05 Сейчас в теме
Разработчики никогда не сидят на техподдержке. Если один сидит на техподдержке это уже не разработчик.
11. MariaTemchina 837 15.11.18 09:49 Сейчас в теме
(10)
Разработчики никогда не сидят на техподдержке. Если один сидит на техподдержке это уже не разработчик.

Вы сейчас применяете знаменитую логическую уловку "Ни один истинный шотландец"

Мне больше нравится формулировка "Разработчики не должны сидеть на техподдержке. Если им приходится это делать - значит, процесс организован не самым разумным образом..."
12. DenisCh 15.11.18 09:52 Сейчас в теме
(11)А если разработчик - на второй линии и отвечает за то, что он пропустил в продакшн?
13. MariaTemchina 837 15.11.18 09:54 Сейчас в теме
(12) Да, спасибо. Я подумала про то, что точнее написать "на первой линии техподдержки", но поленилась ))).
На второй линии, возможно, тоже лучше сидеть службе сопровождения специально организованной. Но тогда понадобится третья линия, для тех косяков, которые все-таки без автора не решить ))).
14. acanta 67 15.11.18 11:15 Сейчас в теме
(11) не совсем так. Сформулированная вами логическая уловка описывает ЧСВ.
Я говорю о причинно-следственной связи (курица или яйцо). Невозможно осуществлять техподдержку какой-либо линии если нет уже разработанного продукта.
Техподдержка осуществляется когда продукт уже есть (т.е. это отладка/решение конфликтов и обеспечение успешной приемки работ, выполняемых разработчиком).
То что днем один человек может быть техподдержкой, а ночью разработчиком ни для кого не секрет (а вот здесь уже играет некоторую роль и ЧСВ).
Но одновременно это невозможно.
15. MariaTemchina 837 15.11.18 11:20 Сейчас в теме
(14)
Невозможно осуществлять техподдержку какой-либо линии если нет уже разработанного продукта.

И да и нет. Потому что если у нас разработка осуществляется по Agile, то есть итеративно и инкрементально, то после первого же промежуточного релиза у нас уже есть продукт в эксплуатации (опытной или промышленной) и продолжение разработки параллельно...
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Программист 1С
Москва
зарплата от 130 000 руб. до 200 000 руб.
Полный день

Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день

Консультант-методолог 1С
Краснодар
зарплата от 110 000 руб.
Полный день

Консультант 1 С
Краснодар
зарплата от 50 000 руб. до 150 000 руб.
Полный день