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

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

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

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

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

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

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

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

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

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

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

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

и т. д.

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

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

Такие вещи, как XP, предоставляют более подробную информацию о конкретных методах, поэтому я бы также сказал, что прочитайте книгу: http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/ref=sr_1_1?s= книги и т = UTF8 & QID = 1304359834 & стер = 1-1

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

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

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

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

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

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

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

Я попробовал это, когда работал в одиночку. Вещи, которые работали хорошо, были:

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

То, что не сработало, было:

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

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

Я думаю, что все должны вести бэк-лог и делать TDD.

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

1. Иметь доску, на которой вы упорядочиваете свои пользовательские истории / элементы активных журналов, на учетных карточках, таких как канбан.

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/

Вы можете найти больше информации в этом блоге.

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

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

Многие из этих ответов упускают важный момент.

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

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

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

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

Вы могли бы сделать процесс схватки с вами тремя.

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

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

Тонн причин использовать скрам имхо.

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

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

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

Для вашего контекста у меня есть несколько мыслей:

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

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

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

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

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

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

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

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

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

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

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

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

• Итерации и постоянное совершенствование. Концепция итераций, в которых постоянно проводится проверка и адаптация, неоценима. Эта практика поощряет экспериментирование, и она строится на продолжении обучения. Скрам в церкви, страница 4

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

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

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

Scrum - это не scrum, если вы не можете приспособить его к вашим потребностям и адаптироваться к вашей текущей ситуации.