В нашей компании есть команда, работающая над 3-мя различными проектами одновременно, где обычно в каждом проекте участвует только один или два человека. Работа над проектом часто включает освоение новых технологий и / или устранение ошибок, что приводит к задачам, которые очень сложно оценить. В этой ситуации руководство все еще настаивает на использовании SCRUM и не позволяет выделять буфер безопасности в конце спринта для непредвиденных ситуаций. Заседание проводится для всей команды, хотя почти все работают над не связанными друг с другом программными компонентами или разными программными проектами.
Мне было интересно, видел ли кто-то, что SCRUM хорошо работает для проекта с одним разработчиком и нечеткими задачами, и как вы заставили процесс работать хорошо?
Как оценить задачи, связанные с исследованием / освоением новых технологий (это включает изучение новых языков программирования, платформ и инструментов разработки)?
Удалось ли кому-нибудь убедить руководство не использовать SCRUM для конкретных проектов, и если да, то какие аргументы были наиболее успешными?
Благодарность!
Ответы:
Посмотрите "Personal Scrum" ... Я видел пару или три сообщения в блоге людей, делающих это. У Full Scrum есть некоторые понятия, которые не будут идеально соответствовать командам из одного человека. (Мой опыт - определенная «критическая масса» из примерно 4 человек, кажется, заставляет команды работать хорошо.)
http://blog.jgpruitt.com/tag/personal-scrum/ например.
Но такие вещи, как оценка задач, скорость и временные спринты, во время которых список задач «защищен», хорошо работают даже для 1.
источник
Конечно, нет. Ваши ежедневные неприятности будут очень короткими и невероятно скучными!
Вы можете выбрать те фрагменты, которые, по вашему мнению, могут вам помочь, карты имеют смысл, хотя вам не нужно заполнять их полностью; остановка через определенное время, чтобы проверить свой прогресс, также имеет смысл. Но если вы делаете это, проверьте Kanban, Crystal и все другие Agile-методы на предмет битов, которые могли бы вам помочь.
источник
Нет, вы не можете делать разборки без команды. Команда, определенная SCRUM, является «кросс-функциональной группой людей, ответственных за управление собой для разработки продукта», которая играет важную роль в SCRUM.
Согласно http://www.scrum.org/storage/scrumguides/Scrum_Guide%202011.pdf
Однако вы все еще можете быть гибкими и, возможно, использовать другие характеристики SCRUM, такие как ведение журнала невыполненных работ по продукту / спринту, планирование и работа в рамках спринтов / итераций, проверка и получение отзывов от всех заинтересованных сторон, перепланирование и так далее. Пожалуйста, прочитайте больше о схватках, так как это гораздо больше, как описано здесь.
источник
Я работаю в аналогичном магазине. Как отмечали другие, то, что вы описываете, может быть гибким, но не бесполезным. Я также добавил бы, что имеет ли смысл возвращать журналы и спринты, зависит от того, будет ли это новая работа или техническое обслуживание и постоянная поддержка. Если первое, то подход с водопадом будет иметь больше смысла для команды из одного человека. Если нет, с точки зрения премьер-министра, то, что они делают, кажется хорошим подходом, если в их портфеле несколько проектов.
Для ловких энтузиастов простое упоминание об использовании водопада является кощунством. Но люди должны использовать здравый смысл.
Позвольте мне привести пример из недавнего моего проекта. Я возглавлял команду из 3 разработчиков на агрессивной 5-месячной шкале времени, чтобы перепроектировать два главных веб-сайта. У нас были ежедневные фуршеты. Но это был водопадный проект, потому что это была небольшая команда, ограниченный жизненный цикл, и все разработчики были краткосрочными подрядчиками, приверженными проекту только до запуска. Проект следовал за очень традиционным жизненным циклом водопада. Абсолютно ничего плохого в этом нет. За исключением того, что мы работали «гибким» образом, мы проводили постоянные встречи и сохраняли лучшие практики гибкой разработки. Наша небольшая команда была освобождена от еженедельных встреч по планированию спринта. Почему? Потому что у нас не было еженедельных развертываний. И наша команда не зависела и не влияла на работу, выполняемую любой другой командой. На самом деле мы работали практически автономно. После запуска веб-сайтов мы перешли к быстрому процессу непрерывного обслуживания и поддержки. Другие разработчики сейчас работают в других местах. Все улучшения планируются в соответствии с периодическими развертываниями.
Дело в том, что лучше использовать процессы, которые наиболее разумны для размера, сложности и зрелости каждого проекта. Если вы проводите много исследований, то сложно сделать оценку на следующие пять месяцев, поэтому гибкая версия, вероятно, лучше, чем водопад.
Отчасти проблема в том, что некоторые люди думают, что вы сможете заранее спланировать следующие пять спринтов. Это было со мной раньше. Вы не должны планировать более двух спринтов, потому что если вы это делаете, то вы побеждаете всю цель иметь спринты. Предполагается, что спринт - это обязательство предоставить реалистичное количество улучшений в течение заданного промежутка времени. Вы не должны совершать то, в чем вы не уверены. Планирование спринта по своей природе является краткосрочным планированием, но это своего рода точка. Если у вас есть долгосрочный график, подумайте о том, чтобы разбить вещи на более мелкие результаты. Или настройку встреч контрольных точек в зависимости от того, где вы находитесь в SDLC.
Планирование спринта должно быть реалистичным обязательством относительно того, что гарантированно будет выполнено в течение определенного периода времени. Если вы обнаружите, что планирование не учитывает неизвестные переменные, возможно, вам следует начать давать диапазоны или пессимистические оценки. Или, как другие предложили, используйте сюжетные очки. Спринты также не должны быть забронированы полностью, чтобы учесть проскальзывание и другие важные задачи, которые возникают.
источник
В вашей команде не должно быть только одного человека, и я сомневаюсь, что это действительно так. «Команда» в SCRUM - это не только разработчики. Вы представитель заказчика, Scrum Master, разработчик и т. Д ...? Вы действительно единственный человек, занимающийся чем-то связанным с этим продуктом, принимающий решения или пытающийся его продать?
Что касается оценки исследования, вы делаете это как рассказ. Вы создаете историю специально для «Исследования XXX» и даете за нее исторические баллы (помните, что здесь вы не оцениваете время, а трудность). Вы также должны быть в состоянии достаточно адекватно оценить сложность реализации некоторых функций, даже если вам нужно исследовать технологии. Иногда этот последний факт просто превращает историю в «максимальную сложность».
Нет, вы действительно не должны встречаться со всеми разработчиками в качестве своего противостояния. Вы должны встретиться с вашей командой , которая опять-таки не только разработчики.
Удачи. Надеюсь, вы, ребята, поняли это.
источник
Предполагая, что у вас есть владелец продукта и мастер схватки (если нет, то это не схватка), схватка может работать для команды из одного человека. Скрам-артефакты (backlogs, burddown chart) будут использоваться точно так же, как они используются в многопользовательской команде. Теперь о встречах:
Ежедневные заезды: вы будете использовать ежедневные заезды, чтобы обновлять всех, например, владельца продукта, мастера схватки или всех, кто интересуется прогрессом. Скрам мастер будет использовать эти встречи, чтобы узнать о любых препятствиях, которые у вас есть. Владелец продукта может помочь вам с пересмотром объема, если / когда это необходимо.
Обзор спринта. В конце каждого спринта вы передаете рабочую часть вашего программного обеспечения владельцу продукта или клиенту. Если целью спринта было изучение «чего-то», вы продемонстрируете PoC, который может использоваться руководством (то есть, как правило, клиентом для PoC).
источник