Larger and more distributed or more flexible teams need stricter coding and testing standards, small teams can (and should) use less.
Process documentation should be minimal, real-time and current.
Detailed statistical control indicators are an unnecessary overhead: early release of incomplete software is a better indication of progress.
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.
Iterations should be flexible unless it benefits coordination of releases with other departments or other processes.
Developers should be able to easily and regularly communicate but meetings should be infrequent (monthly and weekly, rather than daily).
Pair programming should only be used for training and investigational tasks.
These guidelines are a starting point only: continuous improvement should be used to further tailor the agile variant to the exact circumstances.
Coding / Testing standards IMO need to be implemented regardless of the size and distribution of the team. Having coding / testing standards leads to more managable / stable code.
I agree with documentation. By using some Clean Code practices such as meaningfull comments and intent revealing naming conventions in your code then you remove some of the need for documentation of the code itself. Documentation should be at the business level and I prefer it to be in the form of Acceptance Tests.
While having developers close to the customer improves with the iteration process, you need to protect the developer from the business circomventing the process by coming directly to the developer for additions/changes/scope creep. The Business still needs to follow the process through backlog grooming/prioritization etc.
By using release iterations along with development iterations you can maintain a flexible schedule of your iterations that works for the team. Currently we work on 1 week sprint iterations with a release sprint every 3 to 4 weeks.
The type of the meeting should dictate the frequency of the meeting. Daily standups need to be daily. They provide accountablity and transparency to the team which is vital in having a successful team. Retrospectives need to happen at the end of each iteration and that frequency is dictated by the size of your iteration. Other meetings such as code reviews, demo's should never be dictated on time but rather on need and completion.
Pair programming should never be nailed down to specific types. We do pair programming with our QA Testers, our BA team so that both sides have a better understanding of the UAT's and Stories. We also do pair programming for knowledge share, prototyping, investigational tasks etc. In our environment pair programming has become second nature.
Continuous improvement in Agile will become second hand nature as you learn to modify the practices of Agile to your business needs. So long as you don't stray from the Manifesto your Agile should be successful.
The last two points I have a small problem with. Daily stand up meetings are very beneficial. It lets us go over what we worked on the previous day, and what we intend to work on until the next meeting (tomorrow). It is important to note that daily standup meetings should be kept short and to the point. We got into a situation where some people enjoyed bringing up all sorts of questions about the project, so we decided that no questions can be asked, only productivity statements. If there are questions, a further meeting is scheduled with the person in charge of that component.
Also, pair programming should not be used JUST for training and investigational tasks. Pair programming has many benefits, such as knowledge sharing/transfer and code ownership. Two minds on one problem can bring out many interesting points of views and can help isolate potential design flaws. In my opinion, pair programming is underrated and most selfish programmers do not like pair programming. It is a benefit to the project and the team, not to one's self. Good software is written by collaborative teams, not one nerd.
As part of your PhD thesis, you should also consider how Agile is used across teams that are placed in different parts on the globe. So, if you have a product team on the east coast, development teams in India and Russia, QA team in Singapore and so on and so forth. This to me is a whole different ball game and needs completely different patterns.
For example, some of the patterns are:
Based on the time zone, pair the early risers in one part of the world with late nighters of the other part or vice-versa. This is not exactly pair programming but you can call this whatever pattern you want.
Emphasis must be to make the code as readable as possible as opposed to writable. What this means is we may have to put emphasis on uniform design patterns and fluent like naming.
Create teams in such a way that you have one of them and one of us. Which means you pair the Russsian developer with the Indian developer and they work together on a module.
Inventing your own patterns over time that make agile work is really fun and takes a lot of patience and hardwork.
我已经有一段时间没有和斯隆管理学院的 MBA 一起工作了，但我清楚地感觉到，他们被教导说程序员应该被“管理”，而不是“培养”。 我们是一种令人不快的商品，而不是完整的团队成员。 我希望您有比这更好的体验。
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.
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.
Changing corporate behavior is the goal, not altering a proven process to "work with" a broken organization, so emphasize the principles behind each practice. And then don't change the practices. If the principles don't apply, then drop the practice(s) that reflect the principle. Changing the practice compromises the principle and defeats its purpose. The end result of such "adaptations" is most likely the same flawed process already being used, now wrapped in agile terminology but lacking the principles that make it work.
Process Documentation is Anti-Agile
"Process documentation with sign off and structured steps
will help other teams track the project"
I'd have to say a big fat NO to this. Documentation will take the agile right out of the process (not to mention the life and energy out of the developers). If you want to help other teams track the project, publish the iteration schedule and velocity on the intranet. Please do not waste the developers' time - and the customers' money - writing process documentation, especially for the alleged benefit of other people who are not stakeholders and have no risk.
And of course, no MBA candidate can escape a programmer thread without at least one Dilbert reference: (source: dilbert.com)
"Process documentation should be minimal, real-time and current."
What do yo mean by "minimal"? Is it in the sense of say sum of the number of pages or in the sense of coverage (v.gr. standards doc, configuration management manual, design doc).
When you assume a project where there is no turnover in the team - and in long projects this is not a reasonable assumption, you need an efficient mechanism for knowledge transfer, and the most efficient mechanism for knowledge transfer is documentation.
I have seen projects where documentation is kept minimal (in the sense of number of pages) because it is too cumbersome to develop the documentation. But if you can re-use documentation from one project to another with no changes or minimal changes (and this is reasonable for documents like programming standards, configuration management manual) there is no documentation development burden.
Process documentation should cover all of the software development process or you will risk to have processes with steps that are executed in an inconsisten way. Agile teams have agile software processes. And by software development processes I mean clear mechanisms for managing code, controlling versions, controlling reviews, checking in code, fixing bugs, etc.
Larger and more distributed or more flexible teams need stricter coding and testing standards, small teams can (and should) use less.
Continuous testing is invaluable regardless of team size. What should vary is the amount of testing based on project maturity and component criticality.
For new products periodic demonstrations are great for morale and are adequate for delivering progress feel to management.
For mature and shipping products at minimum periodic acceptance testing of major features will track a product's readiness for release.
For major system interfaces unit testing is illustrative and helps avoid surprises. When working with contracted sub-projects unit tests are better than documentation and critical to avoid finger-pointing delays.
Test-first development is a worthy experiment for the heavy lifting pieces of code. If your most valuable asset is your technology then it should be extremely thoroughly tested.
Detailed statistical control indicators are an unnecessary overhead: early release of incomplete software is a better indication of progress.
Statistical control indicators are vital to early identification of project overrun, but they are best left in the hands of the "Agile Coach" or "Scrum Master" either permanently or until the entire team becomes disciplined at producing accurate accounting of progress and delays.
When effectively applied, agile development practices should produce stories and tasks which are small enough that they are completed in hours to days. Effective management of the "planning game" and feedback resulting in individual task overrun can minimize the overhead of estimation and collecting progress data.
Finally, a historical record of customer (and/or management) decisions and an accounting of where time (days) was actually spent in reaction to these decisions will lead the way to improving both engineering and business process. A "swim lane" or "gantt" chart of blocked development and time spent will show how "but we're agile" is no excuse for rash business decisions.
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.
For once I agree! Separate dev and management meetings work well to separate concerns.
Iterations should be flexible unless it benefits coordination of releases with other departments or other processes.
Agile iterations are a valuable development rhythm for establishing a continuously releasable product. The ends of iterations are when feature decisions can be implemented and source control changes can be made to branch off features which won't make the target.
However this practice may be difficult for teams to implement when iterations to not meet up with business needs. Iterations should be scheduled around business needs like demos and promotions.
Developers should be able to easily and regularly communicate but meetings should be infrequent (monthly and weekly, rather than daily).
Monday / Thursday standup meetings are a great idea. However it needs a hard 15-30 minute cap. Split the meeting as needed to reduce the time. Separate concerns to avoid wasting developer time.
An office dog can help keep people attentive during meetings. A few barks is better than people nodding off or texting.
Pair programming should only be used for training and investigational tasks.
Pair programming, unit testing, merciless refactoring, and test driven practices are some of the most difficult agile skills for teams for adopt. The benefits of pair programming are to increase awareness and knowledge and prevent work from being done in isolation where bad decisions and assumptions can linger and cascade.
Larger and more distributed or more flexible teams need stricter coding and testing standards, small teams can (and should) use less.
Coding and testing standards should exist regardless of the team size. They improve maintainability of the code, and make it easier to bring new resources up to speed.
Process documentation should be minimal, real-time and current.
Agreed.
Detailed statistical control indicators are an unnecessary overhead: early release of incomplete software is a better indication of progress.
There aren't many statistical control indicators for software development that are consistently valuable. I would be looking for variance to time and budget, defect rate in test and in production, and variance to estimates.
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.
So often this is impractical or impossible. Customers have so much to do in their own jobs that they rarely have the time to be extremely hands on with development staff. Business Analysts have the skills necessary to consolidate business questions and get clear answers much more time effectively. If your release cycles are short enough, customers will have plenty of opportunity for feedback.
Iterations should be flexible unless it benefits coordination of releases with other departments or other processes.
There should be some flexibility, but not much. One of the benefits of an agile approach is that it forces the team to limit scope to the most valuable requirements. Adding flexibility to iteration timing introduces increased risk of scope creep.
Developers should be able to easily and regularly communicate but meetings should be infrequent (monthly and weekly, rather than daily).
Daily meetings are effective with larger teams. They keep people on track and increase collaboration. They help prevent team members from getting stuck on a problem without asking for help. They also help maintain control around the iteration, which is very useful considering the lack of other controls available.
Pair programming should only be used for training and investigational tasks.
I don't have much to say about this one.
These guidelines are a starting point only: continuous improvement should be used to further tailor the agile variant to the exact circumstances.**
EXACTLY! Agile is meant to flex to the organization's needs. Constant tweaking is essential to perfecting the process.
发布评论
评论（9）
无论团队的规模和分布如何，IMO 都需要实施编码/测试标准。 拥有编码/测试标准可以使代码更易于管理/稳定。
我同意文档。 通过在代码中使用一些“干净代码”实践，例如有意义的注释和意图揭示命名约定，您就可以消除对代码本身进行文档记录的一些需要。 文档应该处于业务级别，我更喜欢采用验收测试的形式。
虽然开发人员与客户的关系会随着迭代过程而得到改善，但您需要通过直接向开发人员寻求添加/更改/范围蔓延来保护开发人员免受业务规避流程的影响。 业务部门仍然需要通过积压整理/优先级划分等来遵循该流程。
通过使用发布迭代和开发迭代，您可以维护适合团队的灵活迭代计划。 目前，我们进行 1 周的冲刺迭代，每 3 到 4 周进行一次发布冲刺。
会议的类型应决定会议的频率。 每日站立会议必须每天进行。 他们为团队提供责任感和透明度，这对于拥有一个成功的团队至关重要。 回顾需要在每次迭代结束时进行，频率取决于迭代的规模。 其他会议（例如代码审查、演示）不应该按时间决定，而应该根据需要和完成情况决定。
结对编程永远不应该局限于特定的类型。 我们与 QA 测试人员、BA 团队进行结对编程，以便双方更好地理解 UAT 和故事。 我们还为知识共享、原型设计、研究任务等进行结对编程。在我们的环境中，结对编程已成为第二天性。
当您学习根据业务需求修改敏捷实践时，敏捷的持续改进将成为二手自然。 只要您不偏离宣言，您的敏捷就应该成功。
Coding / Testing standards IMO need to be implemented regardless of the size and distribution of the team. Having coding / testing standards leads to more managable / stable code.
I agree with documentation. By using some Clean Code practices such as meaningfull comments and intent revealing naming conventions in your code then you remove some of the need for documentation of the code itself. Documentation should be at the business level and I prefer it to be in the form of Acceptance Tests.
While having developers close to the customer improves with the iteration process, you need to protect the developer from the business circomventing the process by coming directly to the developer for additions/changes/scope creep. The Business still needs to follow the process through backlog grooming/prioritization etc.
By using release iterations along with development iterations you can maintain a flexible schedule of your iterations that works for the team. Currently we work on 1 week sprint iterations with a release sprint every 3 to 4 weeks.
The type of the meeting should dictate the frequency of the meeting. Daily standups need to be daily. They provide accountablity and transparency to the team which is vital in having a successful team. Retrospectives need to happen at the end of each iteration and that frequency is dictated by the size of your iteration. Other meetings such as code reviews, demo's should never be dictated on time but rather on need and completion.
Pair programming should never be nailed down to specific types. We do pair programming with our QA Testers, our BA team so that both sides have a better understanding of the UAT's and Stories. We also do pair programming for knowledge share, prototyping, investigational tasks etc. In our environment pair programming has become second nature.
Continuous improvement in Agile will become second hand nature as you learn to modify the practices of Agile to your business needs. So long as you don't stray from the Manifesto your Agile should be successful.
最后两点我有一个小问题。 每天的站立会议非常有益。 它让我们回顾前一天的工作，以及我们打算在下次会议（明天）之前做什么。 值得注意的是，每日站立会议应保持简短、切题。 我们遇到了这样一种情况，有些人喜欢提出有关该项目的各种问题，因此我们决定不能提出任何问题，只能提出生产力陈述。 如果有疑问，将安排与该部分的负责人举行进一步的会议。
此外，结对编程不应仅用于培训和研究任务。 结对编程有很多好处，例如知识共享/转移和代码所有权。 对一个问题有两种想法可以提出许多有趣的观点，并有助于隔离潜在的设计缺陷。 在我看来，结对编程被低估了，大多数自私的程序员不喜欢结对编程。 这是对项目和团队的好处，而不是对自己的好处。 好的软件是由协作团队编写的，而不是由一个书呆子编写的。
The last two points I have a small problem with. Daily stand up meetings are very beneficial. It lets us go over what we worked on the previous day, and what we intend to work on until the next meeting (tomorrow). It is important to note that daily standup meetings should be kept short and to the point. We got into a situation where some people enjoyed bringing up all sorts of questions about the project, so we decided that no questions can be asked, only productivity statements. If there are questions, a further meeting is scheduled with the person in charge of that component.
Also, pair programming should not be used JUST for training and investigational tasks. Pair programming has many benefits, such as knowledge sharing/transfer and code ownership. Two minds on one problem can bring out many interesting points of views and can help isolate potential design flaws. In my opinion, pair programming is underrated and most selfish programmers do not like pair programming. It is a benefit to the project and the team, not to one's self. Good software is written by collaborative teams, not one nerd.
作为博士论文的一部分，您还应该考虑如何在位于全球不同地区的团队之间使用敏捷方法。 因此，如果您在东海岸有产品团队，在印度和俄罗斯有开发团队，在新加坡有质量保证团队等等。 对我来说，这是一场完全不同的球赛，需要完全不同的模式。
例如，一些模式是：
根据时区，将世界一个地区的早起者与另一地区的深夜者配对，反之亦然。 这并不完全是结对编程，但您可以将其称为任何您想要的模式。
重点必须是使代码尽可能可读而不是可写。 这意味着我们可能必须强调统一的设计模式和流畅的命名。
以这样的方式创建团队，其中一个是你，一个是我们。 这意味着您将俄罗斯开发人员与印度开发人员配对，他们在一个模块上一起工作。
随着时间的推移发明自己的模式来实现敏捷工作确实很有趣，并且需要大量的耐心和努力。
希望这个新角度对您有所帮助。
As part of your PhD thesis, you should also consider how Agile is used across teams that are placed in different parts on the globe. So, if you have a product team on the east coast, development teams in India and Russia, QA team in Singapore and so on and so forth. This to me is a whole different ball game and needs completely different patterns.
For example, some of the patterns are:
Based on the time zone, pair the early risers in one part of the world with late nighters of the other part or vice-versa. This is not exactly pair programming but you can call this whatever pattern you want.
Emphasis must be to make the code as readable as possible as opposed to writable. What this means is we may have to put emphasis on uniform design patterns and fluent like naming.
Create teams in such a way that you have one of them and one of us. Which means you pair the Russsian developer with the Indian developer and they work together on a module.
Inventing your own patterns over time that make agile work is really fun and takes a lot of patience and hardwork.
Hope this new angle helps you in some way.
好家伙。 祝你好运。
我喜欢你的方法，尤其是从我们这些咕哝者而不是金表幻灯片集获得输入。
我想说，任何这样的做法都需要根据具体情况进行调整。 没有人应该做某事仅仅因为别人说他们应该这样做。 恕我直言，独立思考应该永远放在首位。
我已经有一段时间没有和斯隆管理学院的 MBA 一起工作了，但我清楚地感觉到，他们被教导说程序员应该被“管理”，而不是“培养”。 我们是一种令人不快的商品，而不是完整的团队成员。 我希望您有比这更好的体验。
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.
当软件可以在共享硬件环境上部署到生产时，我们在具有高度集成软件和预定窗口的大公司中实践敏捷。
我们开发了一套由 SCRUM（项目管理）实践和 XP（工程）实践组成的敏捷实践。 我们部署的许多系统都使用传统的瀑布流程
关于您的框架，我将回复每一项：
“更大、更分布式或更灵活的团队需要更严格的编码和测试标准，小团队可以（并且应该）使用 。
如果您所说的编码和测试标准指的是工程实践 (XP)，例如持续集成、结对编程、测试驱动开发、自动化功能和性能测试等，那么无论规模大小，我们都会采用所有相同的实践 团队或项目。 因此，我们经常发布在用户验收测试中发现的零缺陷的软件。 发布具有可塑性的高质量软件（低缺陷），以可持续的速度进行持续开发，推动了对工程实践的需求，而不是组织的规模。
“流程文档应该是最少的、实时的和最新的。”
如果您所说的流程文档是指敏捷流程文档，那么我们所有的文档都适合挂在墙上。 我们展示了宣言、12 条原则的映射以及我们员工的 21 项实践。 事实上，它们适合挂在墙上并且高度可见，使团队能够理解它们，更重要的是实际将它们付诸实践。
“详细的统计控制指标是不必要的开销：早期发布不完整的软件可以更好地指示进度。”
传统工作工件的完成百分比几乎没有价值。 每两周向我们的产品所有者/业务合作伙伴演示工作软件是进度的最佳指标。 跟踪实际速度（完成的故事卡单位）和缺陷率并将数据显示在大型可见图表上非常有帮助。 当向团队介绍某些实践时，展示进展是很有用的。 比如学习TDD时在代码之前写的单元测试的数量。
“理想情况下，开发人员应该接近客户，没有专门的中间角色。只有当客户专业化且阻止开发人员同时成为用户时，才应使用其他角色。”
如果可能的话，用户应该在开放的工作空间中与团队一起工作。 如果用户无法加入团队，那么用户代理是下一个在线的最佳人选。 没有人能比那些实际使用该软件完成工作的人提供更好的反馈。
“迭代应该是灵活的，除非它有利于与其他部门或其他流程的发布协调。”
更重要的是，各个团队的发布日期应该保持一致。 如果持续时间保持一致（我们每两周使用一次），迭代是最好的。 一致的迭代长度与时间盒和用于提交下一次迭代的故事卡的速度计算一致。
“开发人员应该能够轻松、定期地进行沟通，但会议应该不频繁（每月和每周，而不是每天）。”
团队应该参加每日站立会议，并且每次迭代都制定迭代计划会议、表演和 讲述会议、策划扑克会议和回顾会议。 每次发布团队都会参加发布计划会议。 鉴于用户/业务合作伙伴使用生产线工作，因此可以进行有关正在完成的工作的日常对话。
“结对编程只能用于培训和研究任务。”
使用结对编程的第一个原因是消除缺陷。 我写了一些关于结对编程的回复。 总而言之，结对不太可能被阻止，不太可能通过电子邮件或网络休假，提供转移业务领域、应用领域和工程实践技能的机制，消除知识孤岛（大型组织中的关键）等。
“这些指南只是一个起点：应该使用持续改进来进一步根据具体情况定制敏捷变体。”
回顾，计划每次迭代或当发生需要回顾的事件时，以及零心态缺陷推动持续改进。 员工 XP 工程实践使团队能够保持代码健康，从而能够轻松地无限期地添加新功能。 我们将瀑布式项目的可交付成果视为约束。 为了管理这些约束，我们提前要求这些团队开展工作，并使用模拟等工程技术来测试将与这些可交付成果集成的故事卡。
“当应用于具有现有传统（即 BDUF 或瀑布）模型的组织时，这些因素会发生变化，其中敏捷团队必须与使用非敏捷方法的团队共存或适应非敏捷方法：”
我们有敏捷团队生活在瀑布世界里。 我们邀请瀑布项目参加我们的发布和迭代计划会议（和回顾会）。 我们所取得的成功以及将继续取得的成功将继续为公司内部的敏捷实践带来新的转变。
“包含签核和结构化步骤的流程文档将帮助其他团队跟踪项目。”
不同意。 故事卡墙、迭代计划和发布计划都是团队内部或团队外部人员所需要的。
“统计指标（如速度）可以帮助非敏捷团队放心，流程处于控制之中。”
同意。 敏捷团队将使速度和缺陷率可见。 预算将在 1% 或 2% 之内，并且发布将按计划进行，因为它们是有时间限制的。
“固定迭代将有助于跨团队的协调。”
在高度集成的大型环境中需要。 还可以帮助团队根据速度构建迭代和发布计划。
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.
崇高的事业，祝你好运。 以上所有优点也是如此。 我只想补充一点：
敏捷是关于原则，而不是过程。
请参阅敏捷宣言。
改变企业行为是我们的目标，而不是改变一个经过验证的流程来与一个破碎的组织“合作”，因此强调每个实践背后的原则。 然后不要改变做法。 如果这些原则不适用，则放弃反映该原则的实践。 改变做法会损害原则并违背其目的。 这种“适应”的最终结果很可能是已经在使用的相同有缺陷的流程，现在包含在敏捷术语中，但缺乏使其发挥作用的原则。
流程文档是反敏捷的
我不得不对此说“不”。 文档将使敏捷性脱离流程（更不用说开发人员的生命和精力了）。 如果您想帮助其他团队跟踪项目，请在内网上发布迭代计划和速度。 请不要浪费开发人员的时间和客户的金钱来编写流程文档，尤其是为了所谓的非利益相关者且没有风险的其他人的利益。
当然，如果没有至少一个呆伯特引用，任何 MBA 候选人都无法逃脱程序员线程：
（来源：dilbert.com)
A noble cause, best of luck. All good points above as well. I would only add:
Agile is about the principles, not the process.
See the Agile Manifesto.
Changing corporate behavior is the goal, not altering a proven process to "work with" a broken organization, so emphasize the principles behind each practice. And then don't change the practices. If the principles don't apply, then drop the practice(s) that reflect the principle. Changing the practice compromises the principle and defeats its purpose. The end result of such "adaptations" is most likely the same flawed process already being used, now wrapped in agile terminology but lacking the principles that make it work.
Process Documentation is Anti-Agile
I'd have to say a big fat NO to this. Documentation will take the agile right out of the process (not to mention the life and energy out of the developers). If you want to help other teams track the project, publish the iteration schedule and velocity on the intranet. Please do not waste the developers' time - and the customers' money - writing process documentation, especially for the alleged benefit of other people who are not stakeholders and have no risk.
And of course, no MBA candidate can escape a programmer thread without at least one Dilbert reference:
(source: dilbert.com)
你所说的“最小”是什么意思？ 是指页数总和还是覆盖范围（例如标准文档、配置管理手册、设计文档）。
当您假设一个项目中团队没有人员流动时 - 并且在长期项目中这不是一个合理的假设，您需要一个有效的知识转移机制，而最有效的知识转移机制就是文档。
我见过一些项目，其中文档保持最少（从页数的意义上来说），因为开发文档太麻烦了。 但是，如果您可以在不进行任何更改或进行最少更改的情况下将文档从一个项目重复使用到另一个项目（这对于编程标准、配置管理手册等文档来说是合理的），那么就没有文档开发负担。
流程文档应涵盖所有软件开发流程，否则您将面临流程步骤执行不一致的风险。 敏捷团队拥有敏捷的软件流程。 我所说的软件开发流程是指管理代码、控制版本、控制审查、签入代码、修复错误等的清晰机制。
What do yo mean by "minimal"? Is it in the sense of say sum of the number of pages or in the sense of coverage (v.gr. standards doc, configuration management manual, design doc).
When you assume a project where there is no turnover in the team - and in long projects this is not a reasonable assumption, you need an efficient mechanism for knowledge transfer, and the most efficient mechanism for knowledge transfer is documentation.
I have seen projects where documentation is kept minimal (in the sense of number of pages) because it is too cumbersome to develop the documentation. But if you can re-use documentation from one project to another with no changes or minimal changes (and this is reasonable for documents like programming standards, configuration management manual) there is no documentation development burden.
Process documentation should cover all of the software development process or you will risk to have processes with steps that are executed in an inconsisten way. Agile teams have agile software processes. And by software development processes I mean clear mechanisms for managing code, controlling versions, controlling reviews, checking in code, fixing bugs, etc.
无论团队规模如何，持续测试都是无价的。 应该改变的是基于项目成熟度和组件关键性的测试量。
对于新产品，定期演示非常有助于鼓舞士气，并且足以向管理层传达进步的感觉。
对于成熟和运输的产品，至少定期对主要功能进行验收测试将跟踪产品的发布准备情况。
对于主要系统接口，单元测试具有说明性，有助于避免意外情况。 在处理合同子项目时，单元测试比文档更好，并且对于避免相互指责延迟至关重要。
对于繁重的代码片段来说，测试优先开发是一个值得尝试的实验。 如果您最有价值的资产是您的技术，那么应该对其进行极其彻底的测试。
统计控制指标对于及早识别项目超支至关重要，但最好将它们永久保留在“敏捷教练”或“Scrum Master”手中，或者直到整个团队严格遵守进度和延迟的准确统计。
当有效应用时，敏捷开发实践应该产生足够小的故事和任务，以便在几小时到几天内完成。 对导致单个任务超支的“计划游戏”和反馈进行有效管理可以最大限度地减少估计和收集进度数据的开销。
最后，客户（和/或管理）决策的历史记录以及对这些决策实际花费的时间（天）的统计将引导改进工程和业务流程。 受阻开发和花费时间的“泳道”或“甘特”图将表明“但我们很敏捷”并不是鲁莽的业务决策的借口。
这一次我同意了！ 单独的开发和管理会议可以很好地解决问题。
敏捷迭代是建立持续发布产品的宝贵开发节奏。 迭代结束时，可以实现功能决策，并且可以进行源代码控制更改以分支出不会达到目标的功能。
然而，当迭代不能满足业务需求时，这种做法对于团队来说可能很难实施。 应围绕演示和促销等业务需求安排迭代。
周一/周四的站立会议是个好主意。 然而，它需要严格的 15-30 分钟上限。 根据需要拆分会议以减少时间。 分开关注点以避免浪费开发人员的时间。
办公室狗可以帮助人们在会议期间保持注意力集中。 几声吠叫比人们打瞌睡或发短信要好。
结对编程、单元测试、无情的重构和测试驱动实践是团队最难采用的敏捷技能。 结对编程的好处是提高意识和知识，并防止工作孤立地完成，否则错误的决策和假设可能会持续存在并发生连锁反应。
Continuous testing is invaluable regardless of team size. What should vary is the amount of testing based on project maturity and component criticality.
For new products periodic demonstrations are great for morale and are adequate for delivering progress feel to management.
For mature and shipping products at minimum periodic acceptance testing of major features will track a product's readiness for release.
For major system interfaces unit testing is illustrative and helps avoid surprises. When working with contracted sub-projects unit tests are better than documentation and critical to avoid finger-pointing delays.
Test-first development is a worthy experiment for the heavy lifting pieces of code. If your most valuable asset is your technology then it should be extremely thoroughly tested.
Statistical control indicators are vital to early identification of project overrun, but they are best left in the hands of the "Agile Coach" or "Scrum Master" either permanently or until the entire team becomes disciplined at producing accurate accounting of progress and delays.
When effectively applied, agile development practices should produce stories and tasks which are small enough that they are completed in hours to days. Effective management of the "planning game" and feedback resulting in individual task overrun can minimize the overhead of estimation and collecting progress data.
Finally, a historical record of customer (and/or management) decisions and an accounting of where time (days) was actually spent in reaction to these decisions will lead the way to improving both engineering and business process. A "swim lane" or "gantt" chart of blocked development and time spent will show how "but we're agile" is no excuse for rash business decisions.
For once I agree! Separate dev and management meetings work well to separate concerns.
Agile iterations are a valuable development rhythm for establishing a continuously releasable product. The ends of iterations are when feature decisions can be implemented and source control changes can be made to branch off features which won't make the target.
However this practice may be difficult for teams to implement when iterations to not meet up with business needs. Iterations should be scheduled around business needs like demos and promotions.
Monday / Thursday standup meetings are a great idea. However it needs a hard 15-30 minute cap. Split the meeting as needed to reduce the time. Separate concerns to avoid wasting developer time.
An office dog can help keep people attentive during meetings. A few barks is better than people nodding off or texting.
Pair programming, unit testing, merciless refactoring, and test driven practices are some of the most difficult agile skills for teams for adopt. The benefits of pair programming are to increase awareness and knowledge and prevent work from being done in isolation where bad decisions and assumptions can linger and cascade.
无论团队规模如何，编码和测试标准都应该存在。 它们提高了代码的可维护性，并使新资源的更新变得更容易。
同意。
对于软件开发来说，始终有价值的统计控制指标并不多。 我会寻找时间和预算的差异、测试和生产中的缺陷率以及估计的差异。
通常这是不切实际或不可能的。 客户在自己的工作中要做的事情太多，以至于他们很少有时间与开发人员密切合作。 业务分析师拥有整合业务问题并更有效地获得清晰答案所需的技能。 如果您的发布周期足够短，客户将有很多机会获得反馈。
应该有一定的灵活性，但不多。 敏捷方法的好处之一是它迫使团队将范围限制在最有价值的需求上。 增加迭代计时的灵活性会增加范围蔓延的风险。
每日会议对于较大的团队来说是有效的。 它们让人们保持正轨并加强协作。 它们有助于防止团队成员在没有寻求帮助的情况下陷入问题。 它们还有助于维持对迭代的控制，考虑到缺乏其他可用的控制，这非常有用。
关于这个我没什么好说的。
完全正确！ 敏捷旨在适应组织的需求。 不断调整对于完善流程至关重要。
祝你论文顺利。
Coding and testing standards should exist regardless of the team size. They improve maintainability of the code, and make it easier to bring new resources up to speed.
Agreed.
There aren't many statistical control indicators for software development that are consistently valuable. I would be looking for variance to time and budget, defect rate in test and in production, and variance to estimates.
So often this is impractical or impossible. Customers have so much to do in their own jobs that they rarely have the time to be extremely hands on with development staff. Business Analysts have the skills necessary to consolidate business questions and get clear answers much more time effectively. If your release cycles are short enough, customers will have plenty of opportunity for feedback.
There should be some flexibility, but not much. One of the benefits of an agile approach is that it forces the team to limit scope to the most valuable requirements. Adding flexibility to iteration timing introduces increased risk of scope creep.
Daily meetings are effective with larger teams. They keep people on track and increase collaboration. They help prevent team members from getting stuck on a problem without asking for help. They also help maintain control around the iteration, which is very useful considering the lack of other controls available.
I don't have much to say about this one.
EXACTLY! Agile is meant to flex to the organization's needs. Constant tweaking is essential to perfecting the process.
Good luck to you on your thesis.