Комментарии 17
Рад, что вы развиваетесь.
TargetProcess один из лучших решения для agile процесса.
Все же хотелось бы узнать поподробнее про «Оценки» — как вам все же удается делать estimates для фич, исли вы не делаете planning game и не используете итерации?
TargetProcess один из лучших решения для agile процесса.
Все же хотелось бы узнать поподробнее про «Оценки» — как вам все же удается делать estimates для фич, исли вы не делаете planning game и не используете итерации?
выпустить любой бакфикс в течение дня
Если «бакфикс» от слов бак или бакс, то это здорово — прямо онлайн-монетизация получается :)
А если от слова баг, то чуть по другому пишется
Как долго вы работали по SCRUM и какие проблемы вынудили от него отказаться?
У нас был XP сначала, но в принципе процесс планирования там и в Scrum практически одинаковые. Итерации у нас были года 3. Отказались по разным причинам. Во-первых, частенько не успевали сделать все, что запланированно. Как мы ни старались улучшить эстимейты, все равно бывали ошибки и в полтора и в два раза. Во-вторых, хотелось иметь возможность выпускать релизы в любое удобное время, без итераций это делать гораздо проще. В-третьих, легче совмещать длинные и сложные фичи с небольшими улучшениями. Можно часто выпускать небольшие улучшения, параллельно работая над серьезными фичами.
Я думаю, что Scrum хорош для начала проекта и разработки с нуля. Но для матерых продуктов лучше Kanban.
Я думаю, что Scrum хорош для начала проекта и разработки с нуля. Но для матерых продуктов лучше Kanban.
Не совсем понятно ваше стремление делать релизы в любое удобное время, на что это может повлиять?
Ну например пофиксили 10 багов за неделю. Почему бы не выпустить? Людям польза.
ну только если с этой позиции, и если люди слишком нетерпеливы, чтобы подождать 1-2 недели до очередного выпуска :)
Ну во-первых в скраме не обязательно после каждого спринта происходит релиз. Во-вторых что делать, если фича занимает 2 спринта?
Так и в Канбане у вас продукт релизится не через неделю после начала работ над ним, верно? И фича, занимающая 2 спринта, это нечто :) Такие вещи декомпозируются на более мелкие в обязательном порядке и делаются в порядке приоритета. Прошу понять меня правильно, я не противник канбана, просто я сторонник правильного использования практик и инструментов, так, как это и было задумано создателями :)
Это все хорошо звучит в теории, но так себе реализуемо на практике. Единственный способ реализовать это — сделать механизм выключения фич, что требует дополнительных затрат.
Просто пример. Вот есть у вас система плагинов. Понадобилось ее полностью переписать (например, хотите SOA внедрить для нее) Ну как ни крути нельзя ее разбить на маленькие стори сначала. Пока не готов фреймворк, вы не сможете переписывать отдельные плагины. Можно поставлять старые плагины вместе с новыми. Но зачем? А можно просто делать их в отдельном бранче и выпустить, когда все будет готово.
Просто пример. Вот есть у вас система плагинов. Понадобилось ее полностью переписать (например, хотите SOA внедрить для нее) Ну как ни крути нельзя ее разбить на маленькие стори сначала. Пока не готов фреймворк, вы не сможете переписывать отдельные плагины. Можно поставлять старые плагины вместе с новыми. Но зачем? А можно просто делать их в отдельном бранче и выпустить, когда все будет готово.
разбить на 2 фичи
отличный рабочий процесс
Мы разрабатываем каждую фичу и фиксим каждый баг в отдельном бранче. Мастер всегда готов к релизу.
А в какой момент вливаете фикс в основную ветку?
Спасибо за статью. Приятно осознавать, что мы не одни во вселенной.
Пришли почти к тому же. Было 2 года экспериментов с XP и Scrum. За это время адаптировали все под себя. Теперь уже 4 месяца вырисовывается Kanban.
Пришли почти к тому же. Было 2 года экспериментов с XP и Scrum. За это время адаптировали все под себя. Теперь уже 4 месяца вырисовывается Kanban.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наш рабочий процесс