Six Sigma works well with reproducible processes. By that, I mean pure process that consistently produces (or is supposed to produce) the same output. Given that software development rarely produces the same output, SS is not really applicable, IMO. This is because software development is more a practice than a process.
That being said, it doesn't hurt to read about it and try to see what top-level ideas can be put into software development...
If I understand it correctly, six sigma depends on having meaningful, measurable metrics. What will yours be? KLOC? Classes checked into your archive? Agile velocity?
Six sigma works great on shop floors, but I don't believe that software development is sufficiently "widget-like" to lend itself to such an approach.
It is definitely possible as long as you aren't developing a new product.
Just follow these steps.
1) Create a bug free version of the application. This may take a considerable amount of effort thus it is best to select an application that is trivial in scope. 2) Recreate the application from scratch and compare the iteration to the ideal created in step 1 to create a metric. 3) Tweak your process to acheive closer alignment next to the metric on the next iteration. 4) Go to step 2.
What? You don't create the same application over and over in your shop? Hmm, I don't think six sigma is going to be much use in that scenario.
I've used a wide range of methodologies, Six Sigma, Agile etc. Really the success of quality management on software development is dependent on one key thing. The quailty of the team. It all boils down to that. A good team can work within a horrible methodology and make it work. That's why they are good. Process is important, and you can make a bad process more efficient, but it's all dependent on the team.
Six Sigma can be a good fit for maintenance teams that have a big backlog of discrete work items.
Design for Six Sigma has some elements that can be applied to building a new software product.
And since most software is an enabler to a business process, and that business process may be a highly repeated process where the statistics tools of six sigma can be applied, six sigma can have a role in determining what the highest value software feature is to deliver maximal business value. It can take the emotion out of the decision making process for feature prioritization. If you have an environment where the product manager/stakeholder who yells loudest or most eloquently got their stuff built, six sigma can be applied to fix that unhealthy aspect of your development process by putting some rational measurement behind the prioritization process.
There are parts of software development that don't fit well, as they do not provide a process with a normal distribution of results. On the other hand, the focus on risk, value and doing the right things is essential
[edit] Take a look at the Cynefin model (on wikipedia) to understand why large parts of software development are in the complex domain.
SixSigma is a is a methodology to manage process variations that uses data and statistical analysis to measure and improve a company's operational performance.
So take any process (SDP or other), choose what you want to measure, identify the issues, plan the solutions, evaluate the impacts.
The SixSigma projects I have participated were all fairly transversal and not linked to a software life cycle.
By transversal, I mean transversal to the "product design-development-construction-delivery" process that is software development.
For example, in an environment were we need to produce a set of programs running on our internal production platform, most of our SixSigma projects are centered around Operational Architecture, that is "making operational an execution environment" (how to set up servers and networks in order to stop, update, install and launch a set of executables, and that for many projects each with their own SDP). That is a notion transversal to any SDP you want, since in the end, all those "Development Processes" have but one goal in common: put your software into production.
The criteria to measure were precise and reproducible, going from the time to manage the merges needed to consolidate a final executable to the number of merge errors to the deployment errors (because of an incorrect labels or a faulty release notes).
All those missteps were noted release after release, and the goal was to reduce them. One side-effect was to identify an inadequate merge workflow, workflow which, once fixed, allowed us to greatly reduce the errors in the final set of deliveries.
I had a professor in a class that taught six sigma and other manufacturing efficiency techniques, and after telling him I was in the software development field he suggested the book Lean Software Development. Unforunately I haven't read it, but it seems to deal with applying some of the applicable concepts of six sigma and lean manufacturing to producing software (like eliminating waste, reducing defects, continuous improvement). Here's a short white paper describing lean software development.
I have used Six Sigma for specific performance testing projects which begin with a specific measurable problem statement and end with a counter measure that is again measurable. The DMAIC lends itself to performance tuning, as do the tools and techniques of Causal Analysis, Design of Experiments etc.
发布评论
评论（10）
六西格码适用于可重复的流程。 我的意思是，持续产生（或应该产生）相同输出的纯过程。 鉴于软件开发很少产生相同的输出，在我看来，SS 并不真正适用。 这是因为软件开发更多的是一种实践而不是一个过程。
话虽这么说，阅读它并尝试看看可以将哪些顶级想法放入软件开发中并没有什么坏处......
Six Sigma works well with reproducible processes. By that, I mean pure process that consistently produces (or is supposed to produce) the same output. Given that software development rarely produces the same output, SS is not really applicable, IMO. This is because software development is more a practice than a process.
That being said, it doesn't hurt to read about it and try to see what top-level ideas can be put into software development...
如果我理解正确的话，六西格玛取决于有意义的、可衡量的指标。 你的会是什么？ 克罗克？ 课程已存入您的档案吗？ 敏捷速度？
六西格玛在车间中效果很好，但我不认为软件开发足够“像小部件”，适合这种方法。
If I understand it correctly, six sigma depends on having meaningful, measurable metrics. What will yours be? KLOC? Classes checked into your archive? Agile velocity?
Six sigma works great on shop floors, but I don't believe that software development is sufficiently "widget-like" to lend itself to such an approach.
只要你不开发新产品，这绝对是可能的。
只需按照以下步骤操作即可。
1) 创建应用程序的无错误版本。 这可能需要花费大量的精力，因此最好选择范围较小的应用程序。
2) 从头开始重新创建应用程序，并将迭代与步骤 1 中创建的理想迭代进行比较以创建指标。
3) 调整您的流程，以在下一次迭代中实现与指标更接近的对齐。
4) 转到步骤 2。
什么？ 您不会在您的商店中一遍又一遍地创建相同的应用程序吗？ 嗯，我认为 6 西格玛在这种情况下不会有多大用处。
It is definitely possible as long as you aren't developing a new product.
Just follow these steps.
1) Create a bug free version of the application. This may take a considerable amount of effort thus it is best to select an application that is trivial in scope.
2) Recreate the application from scratch and compare the iteration to the ideal created in step 1 to create a metric.
3) Tweak your process to acheive closer alignment next to the metric on the next iteration.
4) Go to step 2.
What? You don't create the same application over and over in your shop? Hmm, I don't think six sigma is going to be much use in that scenario.
为了使六西格码有用，您需要易于比较的指标或程序。
软件太抽象，无法提供所需的指标类型。
也许要问的一个好问题是
For Six Sigma to be useful you need easily comparable metrics or procedures.
Software is too abstract to have the type of metrics needed.
Maybe a good question to ask would be
我使用过多种方法，如六西格码、敏捷等。软件开发质量管理的成功实际上取决于一个关键因素。 团队的素质。 这一切都归结为这一点。 一个好的团队可以在一个可怕的方法中工作并使其发挥作用。 这就是为什么他们很好。 流程很重要，你可以让糟糕的流程变得更有效率，但这一切都取决于团队。
I've used a wide range of methodologies, Six Sigma, Agile etc. Really the success of quality management on software development is dependent on one key thing. The quailty of the team. It all boils down to that. A good team can work within a horrible methodology and make it work. That's why they are good. Process is important, and you can make a bad process more efficient, but it's all dependent on the team.
六西格码非常适合积压大量离散工作项目的维护团队。
六西格码设计有一些可应用于构建新软件产品的元素。
由于大多数软件是业务流程的推动者，并且该业务流程可能是一个高度重复的过程，其中可以应用 6 sigma 的统计工具，因此 6 sigma 可以在确定要提供的最高价值软件功能方面发挥作用。最大的商业价值。 它可以将情感从功能优先级的决策过程中剔除。 如果您的环境中产品经理/利益相关者喊得最响亮或最有说服力地构建了他们的产品，则可以应用六西格玛通过在优先级确定过程中添加一些合理的衡量标准来修复开发过程中不健康的方面。
Six Sigma can be a good fit for maintenance teams that have a big backlog of discrete work items.
Design for Six Sigma has some elements that can be applied to building a new software product.
And since most software is an enabler to a business process, and that business process may be a highly repeated process where the statistics tools of six sigma can be applied, six sigma can have a role in determining what the highest value software feature is to deliver maximal business value. It can take the emotion out of the decision making process for feature prioritization. If you have an environment where the product manager/stakeholder who yells loudest or most eloquently got their stuff built, six sigma can be applied to fix that unhealthy aspect of your development process by putting some rational measurement behind the prioritization process.
软件开发的某些部分不太适合，因为它们没有提供结果呈正态分布的流程。 另一方面，关注风险、价值和做正确的事情至关重要
[编辑]看看 Cynefin 模型（在维基百科上）以了解为什么大部分软件开发都在复杂领域中。
There are parts of software development that don't fit well, as they do not provide a process with a normal distribution of results. On the other hand, the focus on risk, value and doing the right things is essential
[edit] Take a look at the Cynefin model (on wikipedia) to understand why large parts of software development are in the complex domain.
我不确定是否会跟随你。
SixSigma 是一种使用数据来管理流程变化的方法统计分析来衡量和提高公司的运营绩效。
因此，采取任何流程（SDP 或其他），选择您想要衡量的内容，识别问题，规划解决方案，评估影响。
我参与过的 SixSigma 项目都是相当横向的，并且与软件生命周期无关。
我所说的横向是指横向于“产品设计-开发-构建-交付”过程，即软件开发。
例如，在我们需要生成一组在我们的内部生产平台上运行的程序的环境中，我们的大多数 SixSigma 项目都以 操作架构，即“使操作成为执行环境”（如何设置服务器和网络以停止、更新、安装和启动一组可执行文件，以及对于许多每个项目都有自己的 SDP）。
这是一个横向于您想要的任何 SDP 的概念，因为最终，所有这些“开发流程”只有一个共同目标：将您的软件投入生产。
衡量标准是精确且可重复的，从管理合并最终可执行文件所需的合并时间到合并错误数量再到部署错误（由于不正确的标签或错误的发行说明）。
所有这些失误都会在一次又一次的发布中被记录下来，我们的目标是减少这些失误。
一个副作用是发现了一个不充分的合并工作流程，一旦修复，我们就可以大大减少合并工作流程中的错误。最后一组交付。
I am not sure to follow you.
SixSigma is a is a methodology to manage process variations that uses data and statistical analysis to measure and improve a company's operational performance.
So take any process (SDP or other), choose what you want to measure, identify the issues, plan the solutions, evaluate the impacts.
The SixSigma projects I have participated were all fairly transversal and not linked to a software life cycle.
By transversal, I mean transversal to the "product design-development-construction-delivery" process that is software development.
For example, in an environment were we need to produce a set of programs running on our internal production platform, most of our SixSigma projects are centered around Operational Architecture, that is "making operational an execution environment" (how to set up servers and networks in order to stop, update, install and launch a set of executables, and that for many projects each with their own SDP).
That is a notion transversal to any SDP you want, since in the end, all those "Development Processes" have but one goal in common: put your software into production.
The criteria to measure were precise and reproducible, going from the time to manage the merges needed to consolidate a final executable to the number of merge errors to the deployment errors (because of an incorrect labels or a faulty release notes).
All those missteps were noted release after release, and the goal was to reduce them.
One side-effect was to identify an inadequate merge workflow, workflow which, once fixed, allowed us to greatly reduce the errors in the final set of deliveries.
我的课堂上有一位教授教授六西格玛和其他制造效率技术，在告诉他我从事软件开发领域后，他推荐了这本书 精益软件开发。 不幸的是我还没有读过它，但它似乎涉及将六西格玛和精益制造的一些适用概念应用于生产软件（例如消除浪费、减少缺陷、持续改进）。 这是一份描述精益软件开发的简短白皮书。
I had a professor in a class that taught six sigma and other manufacturing efficiency techniques, and after telling him I was in the software development field he suggested the book Lean Software Development. Unforunately I haven't read it, but it seems to deal with applying some of the applicable concepts of six sigma and lean manufacturing to producing software (like eliminating waste, reducing defects, continuous improvement). Here's a short white paper describing lean software development.
我已将六西格码用于特定的性能测试项目，该项目以特定的可测量问题陈述开始，以再次可测量的对策结束。 DMAIC 适合于性能调整，因果分析、实验设计等工具和技术也是如此。
I have used Six Sigma for specific performance testing projects which begin with a specific measurable problem statement and end with a counter measure that is again measurable. The DMAIC lends itself to performance tuning, as do the tools and techniques of Causal Analysis, Design of Experiments etc.