Ну я пытался донести такую мысль: скрам многими воспринимается как серебряная пуля - вот мы заживём по-скрамовски и всё у нас будет круто. На самом деле в неподготовленной команде скрам внедрить очень сложно - возникает вагон неочевидных трудностей, которые надо решать, используя психологию и умные книжки, а в это время сроки факапятся и наступает беда. Т.е. идея в том, что скрам надо внедрять только, когда, как минимум, ядро команды состоит из крутых профессионалов, которые уже знают как организовывать процесс разработки. Об этом как раз и пишет Денис
( ... )
"Когда тимлид и пм с этим разберутся, скорее всего дальнейшие реформы уже не понадобятся." Далеко не так, если конечно никто не хочет через полгодика-год разойтись по домам.
Ну, скажем так: большинство проблем, которые хочется решить когда "всё плохо", к этому моменту будут сняты и экстренных переделок уже не понадобится. Дальше уже можно будет аккуратно экспериментировать без риска зафейлить все реформы.
Кстати, зря Вы так категоричны, поскольку скрам скрамом а слабости людские все равно остаются, вот с ними как раз и можно бороться. Например, использованием инструмента, который сам считает все что нужно, например, определяет дату завершения релиза по скорости команды.
Скорость команды сама считается по отчетным часам. То есть, все просто вписывают часы и ни о чем не парятся, а система говорит, когда будет завершен релиз и позволяет увидеть где находятся слабые места.
Мы уже давно используем http://devprom.ru и забыли о проблемах с недооценками и переоценками.
Приятно, что вы сами пользуетесь своими продуктами)))
У вас очень интересный проект, он, правда, вряд ли нам подойдёт - у нас пока что команда не распределённая и проблемы с коммуникациями и единым хранением проектной инфы нет, а задачи трекинга багов и ведения техдокументации пока что решаются с помощью простого трекера и wiki. Хотя мне интересно, какие преимущества есть у интегрированной системы. Расскажете?
Кстати немного сбивает с толку, что у вас на сайте пришлось искать статью про стоимость и поддержку, обычно первым делом как-то ищешь цену) Но радует что для небольших команд всё бесплатно.
Соглашусь с тем, что интеграция wiki и багов в одном месте, тема достаточно тонкая, но для профессиональной разработки, имхо, обязательная.
Концептуально - Wiki используется для хранения текста, а работают люди с некими issue (tickets). Возьмем, например, требования. В чем мы выигрываем имея непосредственную связь с issue?
- видим какие issue связаны с требованием - как развивалось требование, кто, когда и какие вносил предложения. - видим какие ошибки при реализации требования были допущены, сколько их - видим плановую и фактическую трудоемкость по реализации требования - позволяем определять степень покрытия требованиями функционала - позволяем отслеживать изменения в требованиях в изменения в остальных артефактах (документации, тестовых сценариях и т.п.).
В целом все тоже самое касается и тестирования, и написания документации. Когда эти вещи связаны, то навигация, управление доступом и подобные вещи существенно упрощаются.
Спасибо за замечание про стоимость, постараемся исправиться в ближайшее время.
Comments 28
Reply
Reply
Далеко не так, если конечно никто не хочет через полгодика-год разойтись по домам.
Reply
Reply
Мусаев просветляет иногда...
Reply
Скорость команды сама считается по отчетным часам. То есть, все просто вписывают часы и ни о чем не парятся, а система говорит, когда будет завершен релиз и позволяет увидеть где находятся слабые места.
Мы уже давно используем http://devprom.ru и забыли о проблемах с недооценками и переоценками.
Reply
Reply
У вас очень интересный проект, он, правда, вряд ли нам подойдёт - у нас пока что команда не распределённая и проблемы с коммуникациями и единым хранением проектной инфы нет, а задачи трекинга багов и ведения техдокументации пока что решаются с помощью простого трекера и wiki. Хотя мне интересно, какие преимущества есть у интегрированной системы. Расскажете?
Кстати немного сбивает с толку, что у вас на сайте пришлось искать статью про стоимость и поддержку, обычно первым делом как-то ищешь цену) Но радует что для небольших команд всё бесплатно.
Reply
Концептуально - Wiki используется для хранения текста, а работают люди с некими issue (tickets). Возьмем, например, требования. В чем мы выигрываем имея непосредственную связь с issue?
- видим какие issue связаны с требованием - как развивалось требование, кто, когда и какие вносил предложения.
- видим какие ошибки при реализации требования были допущены, сколько их
- видим плановую и фактическую трудоемкость по реализации требования
- позволяем определять степень покрытия требованиями функционала
- позволяем отслеживать изменения в требованиях в изменения в остальных артефактах (документации, тестовых сценариях и т.п.).
В целом все тоже самое касается и тестирования, и написания документации. Когда эти вещи связаны, то навигация, управление доступом и подобные вещи существенно упрощаются.
Спасибо за замечание про стоимость, постараемся исправиться в ближайшее время.
Reply
Reply
Leave a comment