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

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

Oh, boy. Good luck.

I like your approach, especially getting input from us grunts rather than the gold-watch powerpoint set.

I would say that any such approach needs to be adaptable to the specific circumstances. Nobody should do something only because somebody else said they should. Thinking for oneself should always be at the forefront, IMHO.

It's been a while since I worked with Sloan School MBAs, but I got the clear sense that they had been taught that programmers were to be "managed", rather than "cultivated". That we were something of a disagreeable commodity, rather than full team members. I hope you have a better experience than that.

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

Например, некоторые из схем:

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

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

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

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

Надеюсь на это новое. угол как-то вам поможет.

We practice agile in a large company with highly integrated software and pre-determined windows when software can be deploy to production on shared hardware environments.

We developed a set of agile practices composed of SCRUM (project management) practices and XP (engineering) practices. Many of the systems we deploy with make use of traditional waterfall processes

Regarding your framework I will reply to each item:

"Larger and more distributed or more flexible teams need stricter coding and testing standards, small teams can (and should) use less."

If by coding and testing standards you mean engineering practices (XP) such as continuous integration, pair programming, test driven development, automated functional and performance testing etc. we employee all the same practices regardless of the size of the team or project. As a result, we often release software with zero defects found during User Acceptance Test. Releasing high quality software (low defects) that remains malleable to enable continuous development at a sustainable pace drives the need for engineering practices, not the size of the organization.

"Process documentation should be minimal, real-time and current."

If by process documentation you mean the agile process documentation, all of our fits on a wall. We show the manifesto, the mapping to the 12 principles and finally the 21 practices we employee. The fact that they fit on the wall and they are highly visible enables the team to understand them and more importantly actually put them into practice.

"Detailed statistical control indicators are an unnecessary overhead: early release of incomplete software is a better indication of progress."

Percent completes on traditional work work artifacts carry little value. Demoing working software to our product owner/ business partner every two week is the best indicator of progress. Tracking actual velocity (units of story cards completed) and defect rates and displaying the data on big visible charts is very helpful. When introducing certain practices to a team it is useful to show progress. For example, the number of unit test written before the code when learning TDD.

"Ideally developers should be close to the customer with no specialised intermediate roles. Additional roles should only be used if customers are specialised in a way that stops developers from also being users."

Users, if possible, should work with the team in the open workspace. If it is not possible for the user to be with the team then a user proxy is the next best person to be on the line. No one can give better feedback than the people that will actually use the software to do their jobs.

"Iterations should be flexible unless it benefits coordination of releases with other departments or other processes."

More importantly, release dates should be alined across teams. Iterations are best if kept consistent in duration (we use every 2 weeks). Consistent length of iteration is consistent with time boxing and the calculation of velocity used to commit to story cards for the next iteration.

"Developers should be able to easily and regularly communicate but meetings should be infrequent (monthly and weekly, rather than daily)."

The team should participate in the daily stand up meeting, and every iteration the iteration planning meeting, the show & tell meeting, planning poker meeting and the retrospective meeting. Every release the team participates in the release planning meeting. Given that the user/ business partner works with the line, daily conversation can occur about the work being completed.

"Pair programming should only be used for training and investigational tasks."

The first reason to use Pair Programming is to eliminate defects. I have written a number of response regarding pair programming. To summarize, pairs less likely to become blocked, less likely to take email or web vacations, provides mechanism to transfer business domain, application domain and engineering practice skills, eliminates silos of knowledge (key in larger organizations) etc.

"These guidelines are a starting point only: continuous improvement should be used to further tailor the agile variant to the exact circumstances."

Retrospectives, planned each iteration or when an event occurs that demands a retrospective be called, and a mindset of zero defects drives continuous improvement. Employee the XP engineering practices enables the team to keep the code healthy enabling new features to be readily added indefinitely. We treat deliverables from waterfall projects as constraints. To manage the constraints we request work from these teams well in advance and use engineering techniques like mocking to test the story cards that will integrate with these deliverables.

"These factors change when applied in an organisation with existing traditional (i.e. BDUF or waterfall) models, where agile teams must either coexist with or be adapted from teams using non-agile methods:"

We have agile teams that live in a waterfall world. We invite the waterfall projects to our release and iteration planning meetings (and retrospectives). The success we have and continue to have continue to bring new converts to the agile practices within the company.

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

Disagree. The story card wall, iteration plan and release plan are all that is needed by those on the team or external to the team.

"Statistical indicators (like velocity) can help reassure non-agile teams that the process is under control."

Agree. Agile teams will make visible velocity and defect rates. Budgets will be within 1 or 2 percent and releases will be on schedule since they are time boxed.

"Fixed iterations will help co-ordination across teams."

Needed in highly integrated and large environments. Also helps the team build iteration and release plans based on velocity.

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

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

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

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

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

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

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

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

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

См. Agile Manifesto .

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

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

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

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

И, конечно же, нет Кандидат на MBA может выйти из потока программистов без хотя бы одной ссылки на Дилберта:
_{(источник: dilbert.com )}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Согласовано.

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

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

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

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

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

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

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

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

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

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

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

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

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