Pull to refresh

Comments 17

Рад, что вы развиваетесь.
TargetProcess один из лучших решения для agile процесса.
Все же хотелось бы узнать поподробнее про «Оценки» — как вам все же удается делать estimates для фич, исли вы не делаете planning game и не используете итерации?
Мы не делаем эстимейты.
выпустить любой бакфикс в течение дня

Если «бакфикс» от слов бак или бакс, то это здорово — прямо онлайн-монетизация получается :)
А если от слова баг, то чуть по другому пишется
:) хорошее замечание
Как долго вы работали по SCRUM и какие проблемы вынудили от него отказаться?
У нас был XP сначала, но в принципе процесс планирования там и в Scrum практически одинаковые. Итерации у нас были года 3. Отказались по разным причинам. Во-первых, частенько не успевали сделать все, что запланированно. Как мы ни старались улучшить эстимейты, все равно бывали ошибки и в полтора и в два раза. Во-вторых, хотелось иметь возможность выпускать релизы в любое удобное время, без итераций это делать гораздо проще. В-третьих, легче совмещать длинные и сложные фичи с небольшими улучшениями. Можно часто выпускать небольшие улучшения, параллельно работая над серьезными фичами.

Я думаю, что Scrum хорош для начала проекта и разработки с нуля. Но для матерых продуктов лучше Kanban.
Не совсем понятно ваше стремление делать релизы в любое удобное время, на что это может повлиять?
Ну например пофиксили 10 багов за неделю. Почему бы не выпустить? Людям польза.
ну только если с этой позиции, и если люди слишком нетерпеливы, чтобы подождать 1-2 недели до очередного выпуска :)
Ну во-первых в скраме не обязательно после каждого спринта происходит релиз. Во-вторых что делать, если фича занимает 2 спринта?
Так и в Канбане у вас продукт релизится не через неделю после начала работ над ним, верно? И фича, занимающая 2 спринта, это нечто :) Такие вещи декомпозируются на более мелкие в обязательном порядке и делаются в порядке приоритета. Прошу понять меня правильно, я не противник канбана, просто я сторонник правильного использования практик и инструментов, так, как это и было задумано создателями :)
Это все хорошо звучит в теории, но так себе реализуемо на практике. Единственный способ реализовать это — сделать механизм выключения фич, что требует дополнительных затрат.

Просто пример. Вот есть у вас система плагинов. Понадобилось ее полностью переписать (например, хотите SOA внедрить для нее) Ну как ни крути нельзя ее разбить на маленькие стори сначала. Пока не готов фреймворк, вы не сможете переписывать отдельные плагины. Можно поставлять старые плагины вместе с новыми. Но зачем? А можно просто делать их в отдельном бранче и выпустить, когда все будет готово.
разбить на 2 фичи
Мы разрабатываем каждую фичу и фиксим каждый баг в отдельном бранче. Мастер всегда готов к релизу.

А в какой момент вливаете фикс в основную ветку?
Непосредственно перед релизом. Тогда на основной ветке запускаются тесты и все проверяется еще раз.
Спасибо за статью. Приятно осознавать, что мы не одни во вселенной.

Пришли почти к тому же. Было 2 года экспериментов с XP и Scrum. За это время адаптировали все под себя. Теперь уже 4 месяца вырисовывается Kanban.
Only those users with full accounts are able to leave comments. Log in, please.