У нас есть один разработчик, работающий над тремя различными проектами. Он работал над исправлениями ошибок, сопровождением и некоторыми функциями. В одном конкретном проекте он работает с еще одним младшим разработчиком.Как управлять процессом для проекта для одного человека
Наша компания хочет внедрить схватку для всех проектов. Каков наилучший способ обработки процесса схватки для проекта 1 или 2 человека?
Я согласен, что должно быть Simple Stupid, но здесь можно использовать большую часть структуры Scrum.
У меня было несколько человек, работающих таким образом как на проектах, так и на ремонтно-эксплуатационных работах.
Владелец продукта/отставание - Есть еще владелец, который отвечает за определение стоимости бизнеса и установление приоритетов, не так ли? Должна существовать отставание. Если он является частью более крупного предприятия Scrum, ему, вероятно, придется прокормить часть более крупного продукта Backlog.
Scrum Team - да, его команда 1 или 2 человека. Так что его действительно SELF-организация ... но это нормально! Ежедневная схватка? да между двумя людьми, или если это просто один человек порой, хорошее время для решения задач и проблем, подумайте о том, какие препятствия необходимо всплыть на Scrum Scrum или на владельца продукта.
Sprint - все еще хорошая идея, особенно если часть крупного предприятия Scrum работает в спринте, но даже без него. Хороший шанс догнать PO, демо, что вы получили, активизировать себя, ретроспективно и посмотреть, что вы можете сделать лучше, планировать следующий спринт. Обратите внимание, что в случае работы за пределами предприятия Scrum/Scrum of Scrum, спринт может выиграть от того, чтобы быть короче обычного, поскольку область видимости, вероятно, меньше, а накладные расходы на планирование ниже. но это зависит от ситуации.
Ретроспектива - да, это может быть проведено в одиночку. Я думаю, что программисты-убийцы должны оглядываться на свою работу/прогресс и предпринимать действия над тем, что их удерживает. Даже держите диаграмму в своем рабочем пространстве, чтобы помочь вам добиться прогресса.
Task Board/Burndown - Да, вам нужны те. Вы можете иметь их в своем рабочем пространстве на стене, они могут быть маленькими, но они действительно помогают, даже если вы один человек. Почему GTD (Getting Things Done) помогает одному человеку и TB/BDC? Если этот человек выполняет работу над проектом, то Sprint Burndown и Release Burndown дают большую ценность. Если он выполняет оперативную/техническую работу, это еще один способ проверить, что он находится на пути или нет, и соответствующим образом применять соответствующие меры.
Scrum Master - человек должен быть его собственным мастером схватки.
Тренер - если организация имела тренер помощи команд/Sms/ДДУ, то он должен также помочь этой схватки клетки ...
Подводя итог - его мне ясно, что ценности и принципы, лежащие в основе Scrum/Agile также подаются на команды 1-2 человек. Его также ясно, что большинство Scrum можно применять также.
Вопросы, о которых думают отдельные лица.
Если руководство, разработчик, ПО все находятся на борту и считают, что ценности/принципы имеют смысл и стремятся улучшить, он будет работать. Если они этого не сделают, тогда сначала дойдете до точки, где общее мышление имеет смысл, а затем разобраться с индивидуальной командой ...
+1 для объяснения того, как это можно сделать. Scrum - очень легкая структура сама по себе, и вы можете применять ее в самых разных ситуациях. Это не обязательно слишком много, даже с таким количеством людей. – Jonik
+1: Цель состоит в том, чтобы НЕ создавать массивную методологию из схватки - просто ежедневные встречи в стойке, и вы делаете схватку. –
Возможно, SCRUM здесь излишне. Организуйте в рабочие пакеты и основные задачи.
Лучший способ? Держать его просто глупо. Не раздувайте проект с большими издержками управления. Вам не нужно использовать программное обеспечение для задач схватки. Трекеры проблемы, такие как Redmine/JIRA, приятно отслеживать прогресс и назначать задачи. Но вы также можете использовать доску с несколькими магнитами и записками (имя задачи). Таким образом, вы можете назначать задания через борт;)
Идеальная команда для SCRUM составляет 8-10 человек. Итак, я не знаю, как вы можете заставить его работать для такой небольшой команды.
Как правило, проблемы управления или гибкие процессы не понятны людям управления. Просто прочитав о соотношении успехов в схватке, он создает привлекательность для людей, занятых в управлении людьми.
Есть две стороны над всеми реализации SCRUM:
IMHO, здесь ваше руководство с нетерпением ожидает инженерных практик и (может быть) некоторых процессов.
Вы можете принять их по частям, чтобы получить лучшую форму, тогда вы можете быть на данный момент. (По крайней мере, в глазах руководства ;-))
+1 для глаз руководства;) –
Согласно большинству источников, идеальный размер команды схватки составляет 7 + -2 членов. Это означает 5-9, а не 8-10. Кроме того, описанные вами (XP) технические практики не являются неотъемлемой частью схватки (хотя они очень часто практикуются в схватке). Приятно критически думать обо всех этих раздутых процессах, но в этом случае я не согласен с пессимизмом, что его нельзя заставить работать. – Jonik
с дизайном scrum, он не будет работать в отсутствие определенных практик XP, таких как Test Automation. – NileshChauhan
Scrum, безусловно, переполнен здесь. Кроме того, не думайте, что Scrum - это серебряная пуля, и вы не можете ее реализовать в своем проекте. Прочитайте «Получение реальности» по 37-значным знакам и некоторым другим ресурсам по сохранению вещей, и вы обнаружите, что работа с междисциплинарной командой из 1 или 2 на самом деле является весьма впечатляюще производительной единицей, если 1 или 2 человека готовы и способны.
Как и Мартин К. заявил: «Держите это просто глупо». Это всего лишь 1 или 2 человека, не нужно «управлять проектами» как таковое. Вырежьте дерьмо и просто сделайте это.
(Это не значит, что вы не должны следовать бюджеты, РАСХОДЫ и измерить прогресс, но не тратить время и деньги на инфраструктуру, которая не требуется)
Осторожно, что вы не бросаете ребенка с водой для ванны; есть много очень ценных аспектов SCRUM, которые имеют отношение ко всем размерам команды. И ни на минуту не думайте, что управление проектами не требуется только потому, что у вас есть только два человека в команде. В большинстве случаев клиент будет по-прежнему ожидать практики управления проектами, таких как соблюдение бюджетов и временных рамок. –
Наверняка, но есть Управление проектами, и есть «управление проектами». Scrum - это всего лишь ориентир для работы, и он подходит лучше всего, когда применяется к проектам, которые сохраняются в течение нескольких месяцев, и группами из 5-9 человек. Что-то меньшее, чем это, и есть хороший шанс, что Scrum переборщит. Как я уже сказал, это не означает, что вы должны отказаться от управления проектами в целом в рамках этого размера, но вы должны иметь возможность масштабировать свои операции как вверх, так и вверх. –
По моему опыту, Scrum все еще может иметь отношение к проектам в небольших командах пары людей с существующими обязанностями. Вот почему:
Все они одинаково важны для команды из 2 человек или 8 членов команды.Не будьте избиты людьми, говорящими «есть только один способ сделать Scrum», или вам нужно больше, чем несколько человек, чтобы заставить его работать.
Отличный, краткий ответ! Важно осознавать, что вы можете свободно сбрасывать любые «церемония схватки» - обзор спринта, планирование и ретроспектива, конечно, не должны занимать много времени для небольшой команды. – Jonik
Является ли мой ответ полезным? Мне нравится изучать разные ситуации схватки! – NileshChauhan
«Как реализовать парное программирование в проекте одного человека?» – flybywire