Ответ 1

• Большие и более распределенные или более гибкие команды нуждаются в более строгих стандартах кодирования и тестирования, небольшие команды могут (и должны) использовать меньше.
• Документация по процессам должна быть минимальной, текущей и текущей.
• Подробные статистические контрольные индикаторы - лишние накладные расходы: раннее освобождение неполного программного обеспечения является лучшим показателем прогресса.
• В идеале разработчики должны быть близки к клиенту без специальных промежуточных ролей. Дополнительные роли следует использовать только в том случае, если клиенты специализируются таким образом, что разработчики также перестают быть пользователями.
• Итерации должны быть гибкими, если только не выгодно согласовывать выпуски с другими отделами или другими процессами.
• Разработчики должны иметь возможность легко и регулярно общаться, но встречи должны быть нечастыми (ежемесячно и еженедельно, а не ежедневно).
• Программирование пар должно использоваться только для учебных и исследовательских задач.
• Эти руководящие принципы являются лишь отправной точкой: для дальнейшего адаптации адаптивного варианта к конкретным обстоятельствам следует использовать непрерывное совершенствование.

Стандарты кодирования/тестирования IMO необходимо внедрять независимо от размера и распределения команды. Наличие стандартов кодирования/тестирования приводит к более управляемому/стабильному коду.

Я согласен с документацией. Используя некоторые методы "Чистого кода", такие как значимые комментарии и намерения, раскрывающие соглашения об именах в вашем коде, вы удаляете некоторую потребность в документации самого кода. Документация должна быть на уровне бизнеса, и я предпочитаю, чтобы она была в форме Приемочных испытаний.

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

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

Тип собрания должен определять частоту собрания. Ежедневные стойки должны быть ежедневно. Они обеспечивают отчетность и прозрачность для команды, которая жизненно важна для успешной команды. Ретроспектива должна произойти в конце каждой итерации, и эта частота диктуется размером вашей итерации. Другие встречи, такие как обзоры кода, демо должны никогда не продиктовать вовремя, а скорее нуждаться и заканчивать.

Паровое программирование никогда не должно прибиваться к определенным типам. Мы делаем пару программ с нашими тестировщиками QA, нашей командой BA, чтобы обе стороны лучше понимали UAT и Stories. Мы также занимаемся парным программированием для обмена знаниями, прототипирования, исследовательских задач и т.д. В нашей среде парное программирование стало второй натурой.

Непрерывное совершенствование Agile станет во второй раз природой, поскольку вы научитесь модифицировать методы Agile для своих бизнес-потребностей. Пока вы не отклоняетесь от Манифеста, ваш Agile должен быть успешным.

Ответ 2

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

Кроме того, парное программирование не должно использоваться JUST для учебных и исследовательских задач. Паровое программирование имеет много преимуществ, таких как обмен знаниями/передача и право собственности на код. Два умы на одной проблеме могут выявить множество интересных точек зрения и могут помочь изолировать потенциальные недостатки дизайна. На мой взгляд, парное программирование недооценивается, и большинство эгоистичных программистов не любят парное программирование. Это преимущество для проекта и команды, а не для одного. Хорошее программное обеспечение написано коллективными командами, а не одним кретином.

Ответ 3

В рамках своей кандидатской диссертации вы должны также рассмотреть, как Agile используется в разных командах, которые размещены в разных частях земного шара. Итак, если у вас есть команда продуктов на восточном побережье, команды разработчиков в Индии и России, команда QA в Сингапуре и так далее и так далее. Это для меня совершенно другая игра с мячом и нуждается в совершенно разных шаблонах.

Например, некоторые из шаблонов:

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

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

• Создавайте команды таким образом, чтобы у вас был один из них и один из нас. Это означает, что вы пар российский разработчик с индийским разработчиком, и они работают вместе над модулем.

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

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

Ответ 4

О, мальчик. Удачи.

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

Я бы сказал, что любой такой подход должен быть адаптирован к конкретным обстоятельствам. Никто не должен делать что-то только потому, что кто-то другой сказал, что нужно. Мышление для себя всегда должно быть на переднем крае, ИМХО.

Прошло некоторое время с тех пор, как я работал со Школой Школы МВА, но я понял, что их учили, что программистов нужно "управлять", а не "культивировать". То, что мы были чем-то вроде неприятного товара, а не полноценных членов команды. Надеюсь, у вас есть лучший опыт, чем это.

Ответ 5

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

Мы разработали набор гибких практик, составленных из практики SCRUM (управление проектами) и практик XP (инженерии). Многие из систем, которые мы развертываем, используют традиционные процессы водопада.

Относительно вашей структуры я отвечу на каждый элемент:

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

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

Документация процесса должна быть минимальной, текущей и текущей.

Если по документации по процессу вы имеете в виду документацию по гибкому процессу, все наши приспособления на стене. Мы показываем манифест, сопоставление с 12 принципами и, наконец, 21 практику, которую мы выполняем. Тот факт, что они подходят к стене, и они очень заметны, позволяет команде понять их и, что более важно, фактически применить их на практике.

"Подробные статистические контрольные индикаторы - лишние накладные расходы: раннее освобождение неполного программного обеспечения является лучшим показателем прогресса".

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

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

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

"Итерации должны быть гибкими, если только не выгодно согласовывать выпуски с другими отделами или другими процессами".

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

"Разработчики должны иметь возможность легко и регулярно общаться, но встречи должны быть нечастыми (ежемесячно и еженедельно, а не ежедневно).

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

"Программирование пар должно использоваться только для учебных и исследовательских задач".

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

"Эти рекомендации являются лишь отправной точкой: для дальнейшего адаптации адаптивного варианта к конкретным обстоятельствам следует использовать непрерывное совершенствование.

Ретроспективы, запланированные на каждую итерацию или когда происходит событие, требующее ретроспективного вызова, а мышление нулевых дефектов ведет к постоянному улучшению. Сотрудник в области инженерных практик XP позволяет команде сохранить код здоровым, позволяя легко добавлять новые функции на неопределенный срок. Мы рассматриваем результаты проектов водопада в качестве ограничений. Чтобы справиться с ограничениями, мы заранее запросим работу у этих команд и используем инженерные методы, такие как насмешка, чтобы проверить карточные карты, которые будут интегрированы с этими результатами.

"Эти факторы меняются при применении в организации с существующими традиционными (например, BDUF или водопадом) моделями, где гибкие команды должны либо сосуществовать, либо адаптироваться от команд с использованием несовместимых методов:"

У нас есть гибкие команды, которые живут в мире водопада. Мы приглашаем проекты водопадов на наши совещания по планированию выпуска и итерации (и ретроспективы). Успех, который мы имеем и продолжаем по-прежнему привлекать новых новообращенных к гибким практикам в компании.

"Документация процесса со знаками и структурированными шагами поможет другим командам отслеживать проект".

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

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

Согласен. Гибкие команды будут делать видимые скорости и скорости. Бюджеты будут находиться в пределах 1 или 2%, а выпуски будут выполняться по расписанию, так как они помещаются в бокс.

"Исправленные итерации помогут координировать работу между командами".

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

Ответ 6

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

Agile - это принципы, а не процесс.

См. Agile Manifesto.

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

Документация по процессам является Anti-Agile

"Process documentation with sign off and structured steps 
 will help other teams track the project"

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

И, конечно же, ни один кандидат MBA не сможет избежать потока программиста без по крайней мере одной ссылки Дилберта: Дилберт встречает MBA http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/50000/4000/500/54565/54565.strip.gif

Ответ 7

• "Документация по процессам должна быть минимальной, текущей и текущей".

Что означает "минимальный"? Является ли это выражением суммы количества страниц или в смысле охвата (v.gr.doc doc, руководство по управлению конфигурацией, проект doc).

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

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

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

Ответ 8

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

Стандарты кодирования и тестирования должны существовать независимо от размера команды. Они улучшают ремонтопригодность кода и упрощают доставку новых ресурсов.

• Документация по процессам должна быть минимальной, текущей и текущей.

Согласен.

• Подробные статистические контрольные индикаторы - лишние накладные расходы: раннее освобождение неполного программного обеспечения является лучшим показателем прогресса.

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

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

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

• Итерации должны быть гибкими, если только это не способствует координации выпусков с другими отделами или другими процессами.

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

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

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

• Программирование пар должно использоваться только для учебных и исследовательских задач.

Мне нечего сказать об этом.

• Эти руководящие принципы являются лишь отправной точкой: постоянное совершенствование должно использоваться для дальнейшего адаптирования гибкого варианта к конкретным обстоятельствам. **

ТОЧНО! Agile предназначен для гибких задач организации. Постоянная настройка необходима для совершенствования процесса.

Удачи вам в вашей диссертации.

Ответ 9

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

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

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

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

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

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

• Подробные статистические контрольные индикаторы - лишние накладные расходы: раннее освобождение неполного программного обеспечения является лучшим показателем прогресса.

Статистические контрольные индикаторы имеют жизненно важное значение для раннего выявления перерасхода проекта, но их лучше всего оставлять в руках "Agile Coach" или "Scrum Master" либо на постоянной основе, либо до тех пор, пока вся команда не станет дисциплинированной при составлении точного учета прогресса и задержки.

При эффективном применении гибкие методы развития должны создавать истории и задачи, которые достаточно малы, чтобы они выполнялись через несколько часов. Эффективное управление "плановой игрой" и обратной связью, приводящее к перерасходу отдельных задач, может минимизировать накладные расходы на оценку и сбор данных о ходе.

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

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

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

• Итерации должны быть гибкими, если только это не способствует координации выпусков с другими отделами или другими процессами.

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

Однако эта практика может быть сложной для команд, когда итерации не соответствуют потребностям бизнеса. Итерации должны быть запланированы вокруг бизнес-потребностей, таких как демонстрации и рекламные акции.

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

Понедельник/четверг встреча в стойке - отличная идея. Однако для этого требуется трудная 15-30-минутная крышка. Разделите встречу по мере необходимости, чтобы сократить время. Отдельные проблемы, чтобы избежать потери времени разработчика.

Офисная собака может помочь держать людей внимательными во время встреч. Несколько лай лучше, чем люди, кивающие или текстовые.

• Программирование пар должно использоваться только для учебных и исследовательских задач.

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