Меня называют «Эксперт по 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-го человека работает очень хорошо. Канбан в сочетании с автоматизированным модульным тестированием сделал меня гораздо более продуктивным и «задокументированным». Хотя ни одна из них не является действительно методологией, но есть больше инструментов (и очень разных), оба вынуждают меня разбивать большие сольные проекты на куски размером с кусочек, а также дают мне своего рода ритуал, побуждающий меня делать больше вещей каждый день. Нет ничего более удовлетворительного, чем щелкнуть «выполнить все тесты» и увидеть, что каждый элемент становится зеленым… ничего, кроме как взять карту из столбца «В процессе» на моей доске Канбан и перейти к «В тестировании» (или полностью с доски) ,
Я думаю, что реальная проблема с работой соло заключается в том, что у вас есть выбор из нескольких методологий, которые действительно предназначены для групп разработчиков, и адаптируйте их так, чтобы они наилучшим образом подходили вам. Конечная цель на самом деле просто держать вас подотчетным, продуктивным и счастливым. Кто знает, как сделать это лучше, чем вы сами (немного потянув отсюда и немного оттуда).
источник
Я попробовал это, когда работал в одиночку. Вещи, которые работали хорошо, были:
То, что не сработало, было:
Это было интересное упражнение, но я перестал его делать через некоторое время. Я думаю, что преимущества Scrum следует рассматривать в отличие от традиционных команд водопада. Но оба рода тоо, когда вы по своему усмотрению. Нет проблем с коммуникацией или совместной работой - вы просто просматриваете заданную работу, и все готово.
Я думаю, что все должны вести бэк-лог и делать TDD.
источник
Элементы Agile / Scrum / Kanban, которые, на мой взгляд, имеют смысл в одном мире разработчиков:
Иметь доску, на которой вы упорядочиваете свои пользовательские истории / элементы активных журналов, на учетных карточках, таких как канбан.
Получите бай-ин от не-разработчиков на ценность этих принципов:
Дайте мне время на работу, не меняя при этом своих приоритетов и не занимаясь микроуправлением (смысл спринтов). Дайте мне время, и я постараюсь заранее выяснить, сколько я могу сделать, и я сделаю все возможное, чтобы сделать это много.
Если мне что-то нужно (меня блокируют), и я прихожу к вам, а вы не можете отсортировать это для меня, то спринт может быть отменен ненормально. (Это просто означает, что нам нужен новый план.)
Никто ничего не меняет в середине спринта. Или, если мы это сделаем, мы просто отменим спринт и создадим новый. если это случается много, производительность падает.
общение между людьми, которые являются заинтересованными сторонами, может происходить на регулярных ежедневных встречах, которые сообщают о большинстве тех же вещей, что и обычные схватки, включая ваши достижения разработчиков за день. По сути, вы можете сообщать о вещах, которые заняли больше времени, чем вы думали, или пошли хорошо, а также о любых корректировках, которые вы вносите в свои планы внедрения. (Я нашел четыре новых ошибки и зарегистрировал их, я думаю, что они более важны, чем эта дополнительная функция, и поэтому я думаю, что потрачу время и исправлю их и вытолкну эту дополнительную функцию.)
Я проделал большую работу в качестве одного разработчика, и я могу с уверенностью сказать, что доверие между одним разработчиком и его руководителями / боссами, не являющимися разработчиками, и хорошее общение - это ключи, а не методология. Но вы всегда можете быть более эффективными, если будете следовать хорошим принципам.
источник
Я читал блог об этом, и я думаю, что он может помочь вам с вашим вопросом.
Первая часть: 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 для краткого вступления.
Для вашего контекста у меня есть несколько мыслей:
Если вы хотите попробовать что-то прямо сейчас, сегодня, пока вы принимаете решение, я бы рекомендовал попробовать персональный канбан на стене или в окне или шкафу рядом с вами, как я делал на прошлой неделе ...
источник
Прочитав все остальные ответы здесь, я думаю, что простой прагматический ответ:
Используйте процессы или методы или методы, которые используются, чтобы узнать то, что поможет вам лучше выполнять свою работу.
Теперь это может означать расстановку приоритетов для ваших задач - каждый день - религиозно.
Это может означать отработать отставание.
Это может означать сообщать о прогрессе вашему боссу (даже если ему все равно ... делать это - хорошая вещь, чтобы мысленно позволить ВАМ оценить, где вы находитесь).
Вы можете использовать всевозможные методы или приемы, потому что они в конечном итоге позволят вам лучше работать, что лучше будет спать ночью.
Делайте вещи, которые работают (для вас, в ваших нынешних обстоятельствах), отбрасывайте вещи, которые не работают.
источник
Если у вас нет следующего на месте
Средства для организации и определения приоритетности поступающих требований.
Чтобы точно оценить усилия, которые будут предприняты, чтобы вы знали, что вы можете совершить в итерации
Итерации и постоянное совершенствование. Концепция итераций, в которых постоянно проводится проверка и адаптация, неоценима. Эта практика поощряет экспериментирование, и она строится на продолжении обучения. Скрам в церкви, страница 4
Ну, вы не можете проводить ежедневные скрам-встречи, но, по крайней мере, вы можете напомнить себе о задаче, которую вы будете выполнять сегодня. Ежедневные скрам-встречи используются для того, чтобы команды могли синхронизировать друг с другом то, что они делают.
Отражение после спринта - в scrum это называется Sprint Retrospective, в конце каждой итерации вы можете подумать о том, что происходит после итерации, и подумать о том, что пошло не так, и как вы можете это улучшить, как лучше всего их сохранить дела
Я бы посоветовал вам придерживаться минималистского подхода, и благодаря постоянному совершенствованию у вас может быть схватка, которая хорошо соответствует вашим потребностям.
Scrum - это не scrum, если вы не можете приспособить его к вашим потребностям и адаптироваться к вашей текущей ситуации.
источник