Комментарии 15
доска на стене — «это универсальная система управления задачами и Scrum», все остальное от лукавого…
А если часть разработчиков не в Москве?
а такое бывает? :)
на самом деле, работал в фирме до последнего времени, в которой использовали Devprom, и все-таки практика показывает, что лучше не вести общий для распределенных команд беклог, а выделять под распределенную команду задачи, а они их уже там сами организуют…
на самом деле, работал в фирме до последнего времени, в которой использовали Devprom, и все-таки практика показывает, что лучше не вести общий для распределенных команд беклог, а выделять под распределенную команду задачи, а они их уже там сами организуют…
Могу спорить до посинения, но какой смысл? Непонятно правда, как это распределенная команда «сама организует».
Точно бывает, сам видел :-)
А если команда или product owner находится пусть и в одном городе, но не в одной комнате (здании)? Требование «все участники должны находится в одной комнате» многое упрощает, но это не всегда возможно.
Например, требование «поставщики и клиенты нашей компании должны находится в нашем здании» тоже значительно упрощает разработку и сбыт промышленной продукции, но в реальности большинство компаний все же пользуются телефонами, интернетом и транспортом — это может оказаться значительно дешевле, чем попытка собрать всех в одном месте.
А если команда или product owner находится пусть и в одном городе, но не в одной комнате (здании)? Требование «все участники должны находится в одной комнате» многое упрощает, но это не всегда возможно.
Например, требование «поставщики и клиенты нашей компании должны находится в нашем здании» тоже значительно упрощает разработку и сбыт промышленной продукции, но в реальности большинство компаний все же пользуются телефонами, интернетом и транспортом — это может оказаться значительно дешевле, чем попытка собрать всех в одном месте.
Алистер Коберн хорошо описывает такие вещи, коммуникация самый главный залог успеха команды, самая эффективная это личная, потом телефон, потом интернет.Имхо, адаптация «под наши реалии» как сейчас любят говорить, просто искажает суть методологий.Если вы хотите делать качественный софт делайте его в одном месте, желательно в одной комнате… проверено на лично опыте со всех сторон, как провальной так и с успешной…
Я уже большой и не верю в волшебную палочку. Сбор всех участников процесса в одной комнате — это удобно и эффективно, но является ли это ключом методологии?
Скажу крамольное: уверен, в большинстве своем методологии разработки ПО, основанные на взаимоотношениях — это плацебо.
Скажу крамольное: уверен, в большинстве своем методологии разработки ПО, основанные на взаимоотношениях — это плацебо.
Я не буду спорить, но опять же вычитал у Коберна, вольный перевод «плевать на методологии, если у вас что-то работает используйте это!»
Для меня лично, именно сбор всех в одном месте и создание духа работа является волшебной палочкой, все мы эмоциональны, и если народ не накачивать каждый день, то моральный дух может упасть, а если команда где-то далеко то даже видеоконференции не спасают «они там, а вы здесь».
Поэтому ко всему ПО для Agile отношусь как средству накопления данных для статистики…
Для меня лично, именно сбор всех в одном месте и создание духа работа является волшебной палочкой, все мы эмоциональны, и если народ не накачивать каждый день, то моральный дух может упасть, а если команда где-то далеко то даже видеоконференции не спасают «они там, а вы здесь».
Поэтому ко всему ПО для Agile отношусь как средству накопления данных для статистики…
Я ж не утверждаю, что митинги собирать не надо.
Средство накопления данных? Когда я делал конфигурацию, я посмотрел use cases для разных систем и, действительно, очень похоже, что они используются как копилки, а сам процесс идет «вживую». Если используется Scrum — еще полбеды, там вживую обсуждаются оценки и результаты, сами задачи фиксируются в «копилках» (что хорошо) или на бумажках (что плохо).
Средство накопления данных? Когда я делал конфигурацию, я посмотрел use cases для разных систем и, действительно, очень похоже, что они используются как копилки, а сам процесс идет «вживую». Если используется Scrum — еще полбеды, там вживую обсуждаются оценки и результаты, сами задачи фиксируются в «копилках» (что хорошо) или на бумажках (что плохо).
А open source разработчики написали что-нибудь хорошее? Какой процент open source проектов был написан командами, которые целиком находятся в одной комнате? :-)
По поводу «лучше в одной комнате» — довелось работать так и так, мой опыт скорее противоположный. В распределенной команде плохие разработчики просто не в состоянии работать: они не в состоянии сами разобраться с проектом, мотивировать себя, часто просто некому их пинать и закрывать доступ к соц. сетям :) При этом в «обычных» командах такие разработчики могут вполне успешно работать годами, система не позволяет им быстро и сильно облажаться.
Читал о подобном эффекте у автора CouchDB, правда он пишет про полезность использования экзотических языков программирования для отсеивания плохих программистов: damienkatz.net/
===
As Paul Graham explained in Beating the Averages, the exotic languages tend to attract devs who love to learn and expand their toolbox. You'll attract more of the types of devs who don't mind creating new code to fill in the gaps, or diving into source to find a bug. They aren't afraid of what they don't know, they actually get excited by the chance to learn and do something new.
But if you pick enterprisey language X, you might find you are spending more of your time fixing problems and dealing with developers who just don't «get it». If you aren't careful, this can drown your project and bring the total code quality down to the point where you can't find good devs to help you anymore. With the less popular, esoteric languages, that tends to be less of a problem and you get a higher quality of contribution in general.
====
По поводу «лучше в одной комнате» — довелось работать так и так, мой опыт скорее противоположный. В распределенной команде плохие разработчики просто не в состоянии работать: они не в состоянии сами разобраться с проектом, мотивировать себя, часто просто некому их пинать и закрывать доступ к соц. сетям :) При этом в «обычных» командах такие разработчики могут вполне успешно работать годами, система не позволяет им быстро и сильно облажаться.
Читал о подобном эффекте у автора CouchDB, правда он пишет про полезность использования экзотических языков программирования для отсеивания плохих программистов: damienkatz.net/
===
As Paul Graham explained in Beating the Averages, the exotic languages tend to attract devs who love to learn and expand their toolbox. You'll attract more of the types of devs who don't mind creating new code to fill in the gaps, or diving into source to find a bug. They aren't afraid of what they don't know, they actually get excited by the chance to learn and do something new.
But if you pick enterprisey language X, you might find you are spending more of your time fixing problems and dealing with developers who just don't «get it». If you aren't careful, this can drown your project and bring the total code quality down to the point where you can't find good devs to help you anymore. With the less popular, esoteric languages, that tends to be less of a problem and you get a higher quality of contribution in general.
====
open source что-то хорошее написали, но пишется это долго и не целенаправленно, если говорить про дев-ов, которые энтузиасты.Если говорить, про вендоров типа Red Hat, Suse то у них команды программистов как в обыкновенных компаниях.Есть три фактора: быстро, качественно, недорого.Выберете любые 2 ))
Сколько лет работаю, ни разу не видел чтобы кто-то когда, не может разобраться в задачах лез в соц.сети.Программисты по своей природе любознательный народ, возможно жизнь меня пощадила, но все с кем я работал или общался было очень хорошо прокачаны в области разработки как таковой.
Ну это заодно к цитате Дамиена, чтобы отсеять плохих прогов, достаточно нескольких недель работы в одном помещении.Однако я не утверждаю, что моя точка истина в последней инстанции, но коммуникация максимально эффективный инструмент в социальной среде, пускай даже программистов.
Хотя и у меня были фейлы, когда собиралась команда интровертов в комнате, которых невозможно было ни воодушевить не взбодрить… они больше получали кайф просто от деятельности.Поэтому эффективней всего собирать разношерстные команды
Сколько лет работаю, ни разу не видел чтобы кто-то когда, не может разобраться в задачах лез в соц.сети.Программисты по своей природе любознательный народ, возможно жизнь меня пощадила, но все с кем я работал или общался было очень хорошо прокачаны в области разработки как таковой.
Ну это заодно к цитате Дамиена, чтобы отсеять плохих прогов, достаточно нескольких недель работы в одном помещении.Однако я не утверждаю, что моя точка истина в последней инстанции, но коммуникация максимально эффективный инструмент в социальной среде, пускай даже программистов.
Хотя и у меня были фейлы, когда собиралась команда интровертов в комнате, которых невозможно было ни воодушевить не взбодрить… они больше получали кайф просто от деятельности.Поэтому эффективней всего собирать разношерстные команды
Не холивара ради, есть несколько замечаний относительно написанного вами:
Мастер — это мост между Заказчиком и командой, он играет основную роль в планировании спринта, определяет его бюджет и распределяет истории по команде.
Вы не совсем правильно понимаете себе роль Скрам Мастера — он просто хранитель церемоний, а отнюдь не мост между заказчиком и командой. Он ни в коем случае не должен распределять ЮСки по участникам команды, команда должна самоуправляться.
Каждый участник команды разработки при планировании оценивает те задачи, в которых разбирается, указывая бюджет задачи в часах. По завершении планирования каждый участник занимается только своими задачами.
Каждый участник должен оценивать все задачи, а распределение должно происходить во время спринта, а не при его планировании. Совместную консенсусную оценку обычно проводят в виде покер-планирования + необходимо кроссфункциональность участников проекта, чтобы не было «своих задач».
Затем команда просматривает созданные Заказчиком задачи и оценивает их трудоемкость, указывая бюджет. При этом участники команды видят оценки друг друга и могут на них ориентироваться, либо не видят и надеются только на себя.
Кроме вышесказанного могу посоветовать приглашать на оценивание задач еще и Product Owner'а, чтобы он четко понимал, откуда взято число + возможно вплывут недопонимание в требованиях в ЮС.
Мастер создает спринт, в котором Заказчик в обсуждении с Мастером и командой указывает сроки (deadline). К указанному сроку спринт должен быть готов для демонстрации.
В скраме спринты жестко затайбоксены — у них всегда одна и та же длина. Это необходимо, чтобы у команды и заказчиков вырабатывался определенный ритм работы.
Мастер — это мост между Заказчиком и командой, он играет основную роль в планировании спринта, определяет его бюджет и распределяет истории по команде.
Вы не совсем правильно понимаете себе роль Скрам Мастера — он просто хранитель церемоний, а отнюдь не мост между заказчиком и командой. Он ни в коем случае не должен распределять ЮСки по участникам команды, команда должна самоуправляться.
Каждый участник команды разработки при планировании оценивает те задачи, в которых разбирается, указывая бюджет задачи в часах. По завершении планирования каждый участник занимается только своими задачами.
Каждый участник должен оценивать все задачи, а распределение должно происходить во время спринта, а не при его планировании. Совместную консенсусную оценку обычно проводят в виде покер-планирования + необходимо кроссфункциональность участников проекта, чтобы не было «своих задач».
Затем команда просматривает созданные Заказчиком задачи и оценивает их трудоемкость, указывая бюджет. При этом участники команды видят оценки друг друга и могут на них ориентироваться, либо не видят и надеются только на себя.
Кроме вышесказанного могу посоветовать приглашать на оценивание задач еще и Product Owner'а, чтобы он четко понимал, откуда взято число + возможно вплывут недопонимание в требованиях в ЮС.
Мастер создает спринт, в котором Заказчик в обсуждении с Мастером и командой указывает сроки (deadline). К указанному сроку спринт должен быть готов для демонстрации.
В скраме спринты жестко затайбоксены — у них всегда одна и та же длина. Это необходимо, чтобы у команды и заказчиков вырабатывался определенный ритм работы.
Вы не совсем правильно понимаете себе роль Скрам Мастера — он просто хранитель церемоний, а отнюдь не мост между заказчиком и командой. Он ни в коем случае не должен распределять ЮСки по участникам команды, команда должна самоуправляться.
Я думал на эту тему. Команда, конечно, может распределять задачи самостоятельно на митинге при планировании, нужно тогда немного права по-другому настроить.
Каждый участник должен оценивать все задачи, а распределение должно происходить во время спринта, а не при его планировании.
В этом случае теряется смысл планирования загрузки участников команды.
В скраме спринты жестко затайбоксены — у них всегда одна и та же длина. Это необходимо, чтобы у команды и заказчиков вырабатывался определенный ритм работы.
Можно и жестко сроки выставлять.
Я понимаю, что отклонился от методики.
Я думал на эту тему. Команда, конечно, может распределять задачи самостоятельно на митинге при планировании, нужно тогда немного права по-другому настроить.
Каждый участник должен оценивать все задачи, а распределение должно происходить во время спринта, а не при его планировании.
В этом случае теряется смысл планирования загрузки участников команды.
В скраме спринты жестко затайбоксены — у них всегда одна и та же длина. Это необходимо, чтобы у команды и заказчиков вырабатывался определенный ритм работы.
Можно и жестко сроки выставлять.
Я понимаю, что отклонился от методики.
Я думал на эту тему. Команда, конечно, может распределять задачи самостоятельно на митинге при планировании, нужно тогда немного права по-другому настроить.
Лучше упорядочить их по приоритету в рамках спринта, и распределять по ходу спринта: освободившийся участник(и) берет самую приоритетную задачу, тогда при факапе, вы не сделаете только самые неприоритетные задачи в рамках спринта.
Лучше упорядочить их по приоритету в рамках спринта, и распределять по ходу спринта: освободившийся участник(и) берет самую приоритетную задачу, тогда при факапе, вы не сделаете только самые неприоритетные задачи в рамках спринта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация Scrum в TrackStudio