Как справиться с процессом для [закрытого] проекта холостяка
В интересах других я обнаружил, что DocFX использует jint , который не может напрямую требовать библиотеки Node. Таким образом, кажется, что плагин-маршрут - лучший путь для этого варианта использования.
5 ответов
Я согласен с тем, что его следует оставить Simple Stupid, но большую часть среды Scrum можно использовать здесь.
У меня было несколько человек, работающих таким образом как над проектами, так и над обслуживанием / оперативная работа.
Владелец продукта / Журнал ожидания - есть еще владелец, отвечающий за определение стоимости бизнеса и определение приоритетов, верно? Отставание еще должно быть. Если он является частью более крупного предприятия Scrum, то ему, вероятно, нужно покрыть часть большого отставания по продукту.
Scrum Team - да, это команда из 1 или 2 человек. Так что это действительно САМО-организация ... но это нормально! Ежедневная схватка? да, между двумя людьми, или если это всего лишь один человек время от времени, подходящее время для решения задач и проблем, подумайте о том, какие препятствия необходимо устранить для Scrum of Scrum или для Владельца продукта.
Sprint - по-прежнему хорошая идея, особенно если она является частью крупного Scrum-предприятия, работающего в спринте, но даже без него. Хороший шанс догнать ПО, продемонстрировать, что у вас есть, зарядиться энергией, оглянуться назад и посмотреть, что вы можете сделать лучше, спланировать следующий спринт. Обратите внимание, что в случае работы за пределами предприятия Scrum / Scrum of Scrum, спринты могут выиграть от того, что они короче, чем обычно, поскольку область действия, вероятно, меньше, а затраты на планирование ниже. но это зависит от ситуации.
Ретроспектива - да, она может быть проведена одна. Я думаю, что программисты-убийцы должны оглянуться назад на свою собственную работу / прогресс и принять меры к вещам, которые их сдерживают. Даже держите диаграмму в своем рабочем пространстве, чтобы помочь вам в достижении прогресса.
Task Board / Burndown - Да, вам это нужно. Вы можете иметь их в своем рабочем пространстве на стене, они могут быть маленькими, но они действительно помогают, даже если вы один человек. Почему GTD (Getting Things Done) может помочь одному человеку, а TB / BDC нет? Если этот человек выполняет проектную работу, то Burndown Sprint и Release Burndown представляют большую ценность. Если он выполняет операционные / ремонтные работы, это все еще способ проверить, работает ли он или нет, и применить соответствующие меры соответствующим образом.
Scrum Master - человек должен быть его собственным scrum master.
Тренер - если в организации есть тренер, помогающий командам / SM / PO, то он также должен помочь этой ячейке скрама ...
Подводя итог - мне ясно, что ценности и принципы, лежащие в основе Scrum / Agile подать заявку на команды из 1-2 человек. Также ясно, что большая часть Scrum может быть применена также.
Вопрос в том, что думают участвующие люди.
Если руководство, разработчик, ПО все на борту и считают, что ценности / принципы имеют смысл и стремиться к улучшению, это будет работать. Если они этого не делают, то сначала дойдут до точки, где общее мышление имеет смысл, а затем разберитесь с отдельной командой ...
Идеальная команда для SCRUM - 8-10 человек. Итак, я не знаю, как вы можете заставить это работать для такой маленькой команды.
Как правило, управленческие люди неправильно понимают схватки или гибкие процессы. Просто читая о соотношении успешности схваток, он создает привлекательность для управленцев.
Существуют две стороны всей реализации SCRUM:
- Процессы: постоянные встречи, ретроспективные встречи и т. Д.
- Инженерные практики: создание четких требований (пользовательских историй), автоматизация тестирования, непрерывная интеграция и т. Д.
ИМХО, здесь ваше руководство с нетерпением ожидает инженерных практик и (возможно) некоторых процессов.
Вы можете принять их по частям, чтобы обрести лучшую форму, чем сейчас. (По крайней мере, в глазах руководства ;-))
Может быть, SCRUM здесь излишним. Организовать в рабочие пакеты и основные задачи.
Лучший способ? Держать его просто глупо. Не раздумывайте над проектом из-за чрезмерных накладных расходов. Вам не нужно использовать программное обеспечение для ваших задач Scrum. Средства отслеживания ошибок, такие как Redmine / JIRA, позволяют отслеживать ваши успехи и назначать задания. Но вы также можете использовать доску с несколькими магнитами и записками (название задачи). Таким образом, вы можете назначать задачи через доску;)
Скрам здесь наверняка перебор. Кроме того, не думайте, что Scrum - это серебряная пуля, и чувствуйте себя обделенными, если вы не можете реализовать это в своем проекте. Прочитайте статью «Как стать реальностью» от 37signals и некоторые другие ресурсы о том, как держать вещи в тонусе, и вы обнаружите, что работа с междисциплинарной командой из 1 или 2 на самом деле является весьма впечатляюще продуктивной единицей, если 1 или 2 вовлеченных в нее человека хотят и могут.
Как сказал Мартин К.: «Делайте это просто, глупый». Это всего 1 или 2 человека, не нужно иметь «управление проектами» как таковое. Вырежьте это дерьмо и просто сделайте это.
(Это не значит, что вы не должны следить за бюджетами, расходами и оценивать прогресс, но не тратить время и деньги на инфраструктуру, которая не нужна)
По моему опыту, Scrum все еще может быть полезен для проектов в небольших группах из нескольких человек с существующими обязанностями. И вот почему:
- Это все еще поощряет разбивку по задачам и детальную оценку.
- Спринты - все еще установленные единицы работы, которые не должны изменяться в объеме или продолжительности.
- Ежедневные регулярные встречи все еще поощряют регулярное обсуждение.
- Вы по-прежнему выполняете итеративные циклы.
- Есть еще таблица сгорания, которую нужно отслеживать.
- У вас все еще есть ретроспективная фаза непрерывного улучшения.
Все они одинаково актуальны для команды из 2 человек или 8 членов команды. Не поддавайтесь избиению людьми, которые говорят «есть только один способ сделать Scrum» или что вам нужно больше, чем горстка людей, чтобы это сработало.