Scrum для одного программиста? [закрыто]

Мне объявили «Windows Expert» в моей небольшой компании, состоящей из меня, инженера-механика, работающего в сфере продаж и обучения, и президента компании, работающего в области разработки, разработки и поддержки .

Моя роль в равной степени является общей, но в первую очередь я разрабатываю и внедряю любое программирование на нашем продукте, которое нужно сделать, чтобы наши вещи могли работать в зависимости от того, какие версии Windows являются текущими.

Я только что закончил просмотр высокоуровневого обзора парадигмы Scrum, данный в веб-трансляции. Мой вопрос: стоит ли мне узнать больше об этом подходе к разработке продукта, учитывая, что мои работы по разработке обычно даются на очень высоком уровне, например, «интернационализировать и локализовать продукт».

Если это так, как бы вы предложили адаптировать Scrum для использования только одного программиста? Какие инструменты, облачные или другие, были бы полезны с этой целью?

Если это не так, какой подход вы предложили бы одному программисту организовать свои усилия изо дня в день? (Возможно, вопрос сводится к этому простому вопросу.)

31 голос | спросил Rob Perkins 28 AMpThu, 28 Apr 2011 01:46:13 +040046Thursday 2011, 01:46:13

11 ответов


14

Изучите Scrum: да. Если только узнаете об этом, добавьте в свой общий набор навыков. (но вкус этого «Scrum-ban» - это, вероятно, то, что вы ищете ...)

Scrum - хорошая структура, но основной принцип - «Итерации (Спринты) должны быть фиксированными.« Я никогда не видел эту работу в очень маленьких командах, которые больше прерываются, чем нет. Если вы действительно можете зарегистрироваться и зафиксировать работу в фиксированном поле времени (1 неделя?), То Scrum - классная среда. Если вы не можете ... тогда Scrum приятно узнать, потому что у него есть хорошие концепции, которые хорошо переносятся на другие вещи ... например ....

Backlog - Scrum или нет, сохраните список приоритетов, который вам нужно сделать. Мне нравится Excel (или Google Doc Spreadsheet ...) Вам может понравиться что-то еще. Я бы держал очень маленький инструмент, если вы очень маленькая команда. (Spreadsheet>), потому что вы можете легко сортировать.)

Разделение планирования и фиксации - Планирование абстрактной нотации (точек) и последовательное (8 пунктов - это примерно 2 раза в 4 раза, а 4 раза - 2 балла). Когда время «выполнять работу» пересматривает проблему и эскиз его в часах. Не меняйте точки.

Обязательство - быть видимым другим, когда вы совершаете, и выполнять свои обязательства

Ретроспектива - после того, как вы поставили, подумайте о том, что можно было бы сделать лучше.

и т. д.

Scrum достаточно легко понять, что это может быть хорошей отправной точкой. Если вам это нравится, я бы подумал использовать вариант «Scrum-ban» - http: //ru. wikipedia.org/wiki/Scrum-ban#Scrum-ban . Ничто другое не поражает меня как «настолько хорошо документированное» с достаточно активным сообществом для его поддержки.

Я хотел бы также рекомендовать Кристичные методологии Алистера Кокберна (http://alistair.cockburn.us/Crystal+methodologies+main+foyer и http://www.amazon.com/Crystal-Clear-Human-Powered-Methodology-Small/dp/0201699478/ref=ntt_at_ep_dpt_3 ), но это связано с еще большим количеством чтения и копания.

Такие вещи, как XP, дают более подробную информацию о конкретных практиках, поэтому я также хотел бы прочитать книгу: http: //www .amazon.com /Экстрим-программирование-Разъяснения-Объятия-Change /дп /0321278658 /исх = sr_1_1 s = книги & амп;? т = UTF8 & амп; QID = 1304359834 & амп; ср = 1-1

Заключительный совет по чтению: пока вы соглашаетесь с манифестами Agile и следуете принципам: http://agilemanifesto.org/principles. html , вы должны быть в приличной форме.


Личные рекомендации:     Принять TDD (не подлежащий обсуждению, IMHO)     Сохранять отставание (согласно Scrum)         Всегда сохраняйте размер и сортируйте по приоритету         Разделение вещей «слишком велико, чтобы делать между перерывами» int small chunks         У кого-то еще установлен приоритет приоритета (ни один из двух элементов не получает одинаковый приоритет.)     Создайте среду сборки, способную создавать /тестировать /развертывать (в лаборатории env) в 5-10 минут     Покажите своим клиентам (внутренним и внешним) результаты завершения истории         История не выполняется, пока ваш клиент не согласится.     Потяните Истории с вершины кучи и работайте над ними, когда вы завершаете текущую историю     Не открывайте одновременно более двух вещей.         Завершите одно отвлечение перед началом другого.     Возьмите на себя гордость за свою работу и раз в месяц покажите команде /компании все продукты /функции, которые вы выполнили.

надеюсь, что это поможет

ответил Al Biglan 2 Maypm11 2011, 22:21:56
13

Вы можете использовать некоторые методы, используемые в Scrum, как отставание продукта, приоритетность, относительная оценка, добавочная доставка, но использование целого Scrum в качестве процесса управления разработкой продукта группой самоорганизованных функциональных групп с перекрестными функциональными возможностями, вероятно, не является возможным шоу одного человека.

Вопрос в том, можете ли вы разбить свои рабочие предметы на мелкие кусочки, которые могут быть доставлены постепенно? Если не использовать большинство практик, это не имеет смысла. Также Scrum о высоком сотрудничестве с владельцем /клиентом. Это не должно выглядеть так: «Здесь у вас есть задание и возвращайся, когда это будет сделано».

ответил Ladislav Mrnka 28 AMpThu, 28 Apr 2011 01:57:56 +040057Thursday 2011, 01:57:56
5

Пока я ничего не скажу ни за или против 1-го уровня Srum, я скажу, что система тяги Kanban с 1 человеком работает очень хорошо. Kanban в сочетании с автоматизированным Unit-Testing сделал меня намного более продуктивным и «документированным». Хотя ни одна из них не является методологией, но больше инструментов (и очень разных в этом), оба заставляют меня разбивать крупные сольные проекты на кусочки размером с укусом, а также дают мне своего рода ритуал, который побуждает меня делать больше вещей каждый день. Нет ничего столь же удовлетворительного, как щелчок «запустить все тесты» и увидеть, что каждый элемент станет зеленым ... ничего, кроме взятия карты из колонки «In Progress» на моей плате Kanban на «In Testing» (или полностью закрытой) .

Я думаю, что реальная проблема с рабочим соло - это то, что вы выбираете из нескольких методов, которые действительно предназначены для групп разработчиков, и адаптируйте их, чтобы лучше всего подойдет вам. Конечная цель состоит в том, чтобы просто быть ответственным, продуктивным и счастливым. Кто знает, как это сделать лучше, чем вы сами (немного оттянувшись отсюда и немного оттуда).

ответил Morgan Herlocker 2 Maypm11 2011, 21:50:26
5

Я пробовал это, когда однажды работал один. Хорошо работали:

  1. Наличие всех рабочих элементов на доске. Я мог очень быстро увидеть, какая выдающаяся работа там была; где были зависимостей и блокировок. Кроме того, многие люди останавливались у моего доски и читали его - и мы поговорили об этом. Я думаю, это помогло им понять, что «выродка» делала весь день; -)
  2. Сжатая диаграмма также была отличной. Я просто использовал Excel для этого. Это позволило мне лучше понять оценки в этой среде. Это дало мне отличный обзор того, куда я направлялся с итерацией. Мой менеджер, который не был техническим специалистом, также любил это, поскольку она могла видеть все разные вещи, связанные с функцией, и где они были.
  3. Ежедневный взлет. Как можно лучше. Каждое утро я обновлял все рабочие элементы и таблицу выгорания и делал заметку о всех препятствиях, которые необходимо было решить.
  4. Автоматическое тестирование и непрерывная интеграция (MSTest /TFS), предпочтительно TDD, помогут любой команде разработчиков, используя любую методологию, но стоит упомянуть здесь.
  5. Короткие итерации (1 неделя) действительно помогли мне сосредоточиться на доставке чего-то.
  6. Поддержание отставания было замечательным, так как когда мне была дана новая работа, я смог разместить ее в контексте всей другой работы и заставить владельца продукта переопределять приоритеты.

Что не получилось:

  1. Работая самостоятельно, вы никогда не получите такого эффекта от сотрудничества с единомышленниками; или это чувство конкуренции и внимания, которое приходит от команды с действительно большим моральным духом и культурой. У вас нет другого мозга, когда вы застреваете, поэтому блокировки, подобные этому, не могут быть устранены мастером схватки в повседневной борьбе.
  2. Нет мастера схватки - так что некому прекратить перерывы. У меня было много проблем с людьми, которые постоянно задавали вопросы о других вещах и нарушали мой поток. Под хорошим мастером схватки, такие вещи перехватываются, и вы можете продолжать. Я никогда не хотел быть груб с людьми (может быть, я мягкий), так что это была проблема. Кроме того, без мастера схватки вы можете легко покинуть процесс.

Это было интересное упражнение, но я немного прекратил это делать. Я думаю, что преимущества Scrum следует рассматривать в отличие от традиционных команд водопада. Но оба являются спорными, когда вы сами. Там нет связи или проблем сотрудничества - вы просто пахаете работу, которая установлена, а затем вы закончили.

Я думаю, что каждый должен поддерживать back-log и делать TDD.

ответил sheikhjabootie 5 Maypm11 2011, 15:44:41
2

Элементы Agile /Scrum /Kanban, которые, я думаю, имеют смысл в одном мире разработчиков:

  1. У вас есть доска, на которой вы организуете ваш пользователь историй /активных периодов, на индексные карты, например, канбан.

  2. Получите бай-ин от не-разработчиков по стоимости этих принципов:

    • Дайте мне время для работы, не меняя приоритетов на меня или микроменеджмент (точка спринта). Дайте мне время, и я постараюсь заранее выяснить, как много я могу сделать, и я сделаю все возможное, чтобы сделать так много.

    • Если мне что-то нужно (я заблокирован), и я прихожу к вам, и вы не можете сортировать его для меня, тогда спринт, возможно, придется отменить ненормально. (Это просто означает, что нам нужен новый план.)

    • Никто не меняет ничего в середине спринта. Или, если мы это сделаем, мы просто отменим спринт, и мы создадим новый. если это происходит много, производительность падает.

    • Общение между людьми, которые являются заинтересованными лицами, может происходить на обычных ежедневных стендовых заседаниях, которые связывают большинство тех же вещей, что и регулярный схваток, включая ваши достижения разработчика за день. По сути, вы можете сообщать о вещах, которые занимают больше времени, чем вы думали, или хорошо, и каких-либо корректировок, которые вы вносите в свои планы реализации. (Я обнаружил четыре новых ошибки и зарегистрировал их, я думаю, что они важнее этой дополнительной функции, поэтому я думаю, что потрачу время и исправлю их и вытащу эту дополнительную функцию.)

Я проделал большую работу как один разработчик, и я могу точно сказать, что доверие между единственным разработчиком и его не-разработчиками /боссами и хорошая коммуникация - это ключи, а не методология. Но вы всегда можете быть более эффективными, если будете следовать хорошим принципам.

ответил Warren P 5 Mayam11 2011, 06:26:11
2

Я читал об этом блоге, и я думаю, что он может помочь вам в вашем вопросе.

Первая часть: http: //www. 21apps.com/agile/doing-agile-in-a-team-of-one/

Вторая часть: http: //www.21apps.com/agile/doing-agile-in-a-team-of-one-day2/

Вы можете найти дополнительную информацию об этом блоге.

Я никоим образом не связан; просто что-то у меня было в моих любимых. Надеюсь, это может вам помочь.

ответил Rodi 5 Maypm11 2011, 13:30:27
1

Да. И имейте в виду, что Scrum не должен привлекать привлекательные инструменты, это может быть просто 15-минутная стоячая встреча, на которой все говорят о том, над чем они работают. Преимущество Scrum заключается в том, что каждый знает, что происходит, и это облегчает решение проблем до их возникновения и предвосхищает проблемы в будущем.

ответил CamelBlues 28 AMpThu, 28 Apr 2011 07:13:09 +040013Thursday 2011, 07:13:09
1

В большинстве этих ответов отсутствует важный момент.

Команда схватки не должна состоять исключительно из программистов.

Один из ваших коллег делает «дизайн» /«развитие», а один делает «продажи».

Возможно, ваш коллега по продажам может быть владельцем продукта (прокси). Каковы ожидания клиента?

Дизайн и разработка вашего другого коллеги действительно звучат как дисциплина для занятий в команде. Разработка Scrum не поэтапная, а вертикальная (требования к утюгу, проектирование и реализация в одном спринте).

Вы можете выполнить процесс схватки с тремя из вас.

Что нужно, чтобы сделать это? Встречи Scrum по планированию спринта увеличивают масштаб вопроса о том, что это такое. Что ожидает владелец продукта, считая это выполненным?

Во время совещания по планированию спринта вы можете дать другим коллегам контекст, почему «интернационализировать и локализовать продукт» может быть сложно технически сложно реализовать.

Тонны причин использовать scrum imho.

ответил Joppe 6 Mayam11 2011, 04:56:44
1

Я бы предложил попробовать Kanban и начать с основ: визуализация и ограничение незавершенного производства (WIP).

Даже если вы прекратите его позже, вы будете более гибкими в этом процессе. И хотя Kanban хорош для «нормальной» разработки программного обеспечения, Kanban + потоковый процесс (в отличие от итераций) затмевает другие инструменты процесса, когда у вас есть ситуация как с разработкой новых функций, так и с обслуживанием.

Во-вторых, рекомендация книги Канбана Дэвида Андерсона, и вы также можете взглянуть на мои слайды из местной встречи на почему и как начать работу с простым Kanban или crisp.se/kanban для краткого введения.

В вашем контексте у меня есть несколько соображений:

  • видимость является ключевым, поэтому скорее используйте физическую доску, чем цифровой инструмент, если вы не можете показать его на большом экране постоянно (если вы находитесь совместно)
  • начните с текущего процесса.
  • начинайте с вашей сферы влияния, в том числе вверх по течению и вниз по этапам передачи (очереди для вас, например, разработанные функции, готовые для разработчика, или очередь от вас, например, готовые функции, готовые к продажам)
  • Если ваши коллеги заинтересованы в расширении визуализации вверх или вниз по течению, тем лучше. Возможно, вы в конечном итоге визуализируете весь поток (или сеть) для вашей компании, т. Е. Как стоимость передается из концепции в денежные средства.
  • минимизировать многозадачность (!) путем ограничения WIP. Если поток работ виден вашим коллегам, они должны понять, почему и легко увидеть, что находится на вашей тарелке.
  • возможно, будет полезно разделить работу на 3 или 4 типа работы (классы обслуживания), которые имеют разные требования к ним: f.ex. ошибки, критические проблемы, работа с жесткими сроками, работа без крайних сроков.
  • наблюдать за тем, как работает ваша работа, например, если вы где-то встречаете узкие места или работаете, или вы «голодали» для работы в несколько предсказуемых шаблонах. Это проще в долгосрочной перспективе, если вы используете цифровой инструмент, верните некоторые из моих последних слайдов.
  • шаг за шагом улучшать поток работы.

Если вы хотите попробовать что-то прямо сейчас, сегодня, когда вы принимаете решение, я бы рекомендовал попробовать личный канбан на стене или окне или шкафу рядом с вами, , как я сделал на прошлой неделе ...

ответил Ingvald 6 Maypm11 2011, 20:12:42
0

Прочитав все остальные ответы здесь, я думаю, что простой прагматичный ответ:

Использовать процессы или методы или методы, которые используются для УЧЕНИЯ того, что поможет вам улучшить свою работу.

Теперь это может означать приоритизацию ваших задач - каждый день - религиозно.

Это может означать выработку отставания.

Это может означать сообщение о прогрессе - вашему боссу (даже если ему все равно ... делать это хорошо, чтобы мысленно позволить ВАМ подводить итоги, где вы находитесь).

Вы можете использовать всевозможные методы или методы, потому что они в конечном итоге позволяют вам работать лучше, что = спать лучше ночью.

Делайте то, что работает (для вас, в ваших нынешних условиях), отбрасывайте вещи, которые этого не делают.

ответил quickly_now 5 Maypm11 2011, 14:24:01
0

Если у вас нет следующего места

  • Способ организации и определения приоритетов входящих требований.

  • Чтобы точно оценить усилия, которые будут предприняты, чтобы вы знали, что можете совершить на итерации

  • Итерации и непрерывное совершенствование. Бесконечная концепция итераций, в которых постоянно проводится инспектирование и адаптация. Эта практика поощряет экспериментирование, и она развивается в процессе непрерывного обучения. Scrum in Church, страница 4

  • Ну, вы не можете делать ежедневное собрание схваток, но по крайней мере вы можете напомнить себе о задаче, которую вы совершите сегодня. Ежедневное собрание по схватке используется для того, чтобы команды могли синхронизировать друг с другом то, что они делают.

  • Отражение после спринта - в схватке это называется Sprint Retrospective, в конце каждой итерации вы можете подумать о том, что произойдет после итерации, и подумать о том, что пошло не так, и как вы можете ее улучшить, что наилучшая практика, чтобы держать их в работе

Я бы предположил, что вы придерживаетесь минималистского подхода, и благодаря постоянному совершенствованию вы можете иметь схватку, которая хорошо подходит для ваших нужд.

Scrum не схвачен, если вы не можете подходить под свои нужды и адаптироваться к вашей текущей ситуации.

ответил OnesimusUnbound 6 Mayam11 2011, 09:20:28

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132