Друзья, у меня есть довольно нубский вопрос, поэтому может быть подскажете куда можно копать, что фундаментального почитать/посмотреть? Собственно, история такая: работаем по канбану, но проект длится уже какое-то неприличное количество времени (софтланч довольно сложного продукта). Чувствую, что команда выдыхается и работает как конвейер в плохом смысле этого слова: ребята совершают довольно досадные ошибки и подчас не очень внимательно читают джоб стори, а потому и перетестировать приходится по несколько раз — в общем, тяжко. Вопрос такой: что имеет смысл делать в данном случае? Опыт подсказывает, что можно было бы ввести более короткие итерации и таким образом "встряхнуть" команду, но здравый смысл говорит, что итерации без релизов - это чушь собачья. Может быть есть какие-то общеизвестные и более здравые способы?

Друзья, у меня есть довольно нубский вопрос, поэтому может быть подскажете куда можно копать, что фундаментального почитать/посмотреть? Собственно, история такая: работаем по канбану, но проект длится уже какое-то неприличное количество времени (софтланч довольно сложного продукта). Чувствую, что команда выдыхается и работает как конвейер в плохом смысле этого слова: ребята совершают довольно досадные ошибки и подчас не очень внимательно читают джоб стори, а потому и перетестировать приходится по несколько раз — в общем, тяжко. Вопрос такой: что имеет смысл делать в данном случае? Опыт подсказывает, что можно было бы ввести более короткие итерации и таким образом "встряхнуть" команду, но здравый смысл говорит, что итерации без релизов - это чушь собачья. Может быть есть какие-то общеизвестные и более здравые способы?

лучше скрам-коуча или аджайл-мастера

Канбан подразумевает применение метрик, формализацию процессов и применение какой-либо модели улучшения (кай-дзен). Иначе с канбана толку мало. У вас там как с этим? В целом конечно звучит как необходимость звать на помощь аджайл-коуча или скрам-мастера.

@dmitriyabr @beskov 👆

Кстати попробуйте не писать джоб стори. Делайте моки интнрфейса и кратко без лишней воды что нужно собственно сделать. Джоб стори были хайпом, который сходит на нет последнее время.

Главное, когда метрику подберёте, не использовать её как плётку. А то с неё толку будет мало. Надо чтоб все понимали - никого наказывать не будут. Метрики нужны только для того, чтоб подкручивать (всмысле, настраивать) процессы.

@DenisIzmaylov у Димы нет прав

Спасибо! Моки и так делаем, само собой, под джоб стори я скорее понимаю, что задача всегда содержит в себе не только что нужно сделать, но и то, как это должно помочь пользователю в конечном итоге. Ну и, да, часто в формате "когда что-то, я хочу того-то, чтобы то-то". Иногда ещё с припиской "а не того-то, чтобы что-то другое", если речь идёт о баге )

Несмотря на угасший хайп, мне кажется это довольно важно обозначать

Если проблемы с качеством, то подберите метрику для качества. Начните измерять. Затем договоритесь, какую модель будете применять для улучшения. И потом по этой модели постепенно коллективными усилиями удастся вылечить недуг.

Кстати, Сергей. По поводу того, что команда выдыхается. У вас разработчики задачи тянут с предыдущего этапа, или толкают вперёд после завершения работы на этапе? Wip без вытягивающей системы по-моему не работает.

А на тестинге есть wip лимит?

Денис говорил, у тебя есть права

спасибо! только я так и не понял насколько в итоге это будет быстрее или медленее в разработке, если уже научились юнит тестам, когда надо 1) будет переделывать периодически функционал 2) в сравнении с обычным процессом разработки

Только что закончился мастер-класс http://ndcoslo.com/workshop/noestimates/ но двоякие впечатления

Хорошая книга)

Также на Демо, за вопросы раздаю чокопаи в зал