Provide market and technical leadership - your company can be successful by producing innovative and technologically advanced products but you must understand what your customers value and you know what technology you're using can deliver
Create nothing but value - you have to be careful with all the processes you follow i.e. be sure that all of them are required and they are focused on creating value
Write less code - the more code you have the more tests you need thus it requires more work and if you're writing tests for features that are not needed you are simply wasting time
Create Knowledge
Create design-build teams - leader of the development team has to listen to his/her members and ask smart questions encouraging them to look for the answers and to get back with encountered problems or invented solutions as soon as possible
Maintain a culture of constant improvement - create environment in which people will be constantly improving what they are working on - they should know that they are not and should not be perfect - they always have a field to improve and they should do it
Teach problem-solving methods - development team should behave like small research institute, they should establish hypotheses and conduct many rapid experiments in order to verify them
Build Quality In
Synchronize - in order to achieve high quality in your software you should start worrying about it before you write single line of working code - don't wait with synchronization because it will hurt
Automate - automate testing, building, installations, anything that is routine, but do it smartly, do it in a way people can improve the process and change anything they want without worrying that after the change is done the software will stop working
Refactor - eliminate code duplication to ZERO - every time it shows up refactor the code, the tests, and the documentation to minimize the complexity
Defer Commitment
Schedule Irreversible Decisions at the Last Responsible Moment - you should know where you want to go but you don't know the road very well, you will be discovering it day after day - the most important thing is to keep the right direction
Break Dependencies - components should be coupled as loosely as possible to enable implementation in any order
Maintain Options - develop multiple solutions for all critical decisions and see which one works best
Optimize the Whole
Focus on the Entire Value Stream - focus on winning the whole race which is the software - don't optimize local inefficiencies, see the whole and optimize the whole organization
Deliver a Complete Product - teams need to have great leaders as well as great engineers, sales, marketing specialists, secretaries, etc. - they together can deliver great final products to their customers
Deliver Fast
Work in small batches - reduce projects size, shorten release cycles, stabilize work environment (listen to what your velocity tells you), repeat what's good and eradicate practices that creates obstacles
Limit work to capacity - limit tasks queue to minimum (one or two iterations ahead is enough), don't be afraid of removing items from the queue - reject any work until you have an empty slot in your queue
Focus on cycle time, not utilization - put in your queue small tasks that cannot clog the process for a long time - reduce cycle time and have fewer things to process in your queue
Respect People
Train team leaders/supervisors - give team leaders the training, the guidance and some free space to implement lean thinking in their environment
Move responsibility and decision making to the lowest possible level - let your people think and decide on their own - they know better how to implement difficult algorithms and apply state-of-the-art software frameworks
Foster pride in workmanship - encourage passionate involvement of your team members to what and how they do
My point is that you can certainly adopt engineering practices like automated testing, refactoring, coding standards, pair programming, code reviews, continuous integration, etc. They will definitely not hurt. But they should be part of a bigger plan that involves organizational practices and, ultimately, the way your company drives the business. Agile is actually a business oriented thing, engineering practices and tools are just a small part of the story and won't be enough by themselves to save hundreds of thousands of dollars.
In short, whatever you'll use, if your current (probably sequential and defined) process produces poor results, not changing the process won't drastically change the results.
I thus believe that enabling "inspect and adapt" cycles and feedback loops would be the most important thing to do.
最后，与敏捷实践（我毫不犹豫地推荐）相比，它似乎还很初级，但我认为 Joel Test 仍然相关（我会因为提及而获得奖励积分吗？）。我不知道您的组织排名有多高，但是无论您是单个开发人员还是管理层的一部分，都有许多关于您可以做的事情的好建议。
In my experience, it is difficult to be the single driver of change. And it is much worse if you do not have the support of management. If you don't have management support, you need a dual pronged attack: a) to recruit developers to strive to be better, and b) to demonstrate to management how your improvements are affecting the bottom line. If you feel that you do have management support (or can get it), then you still need the support of the people on your team(s).
You should introduce tools (as others have suggested), such as Hudson and unit testing frameworks that make it easier to do the right thing. But introducing tools that only you use gets frustrating after a while. You also need to introduce the ideas to the other developers in the organization and hope that they have the desire to learn something new and apply to make their (work) life better.
Start a weekly brown bag to review tools, new languages, problem solving approaches, and review papers. Basically anything to introduce new ideas and get people thinking beyond the scope of their next bug fix. (This will also tell you who is going to be receptive to better practices.)
Show off your workflow. Pair programming probably has a bad name in your organization, but getting someone to occasionally "help me with this" (even if you don't really need the help) gives you an opportunity to show them something new. This can happen the other way around too. When you see someone struggling with some manual task that could be automated, offer to teach them a new trick. (Anecdotally, I think it's more likely to be have an impact when they are the ones asking, "Nice. How did you do that so easily?")
Demonstrate pride in your own work and try to encourage the same from your team. Keep asking your team and peers questions like "how would you want this to work if you were using it?" and "how can we make this more maintainable / easier to extend?"
Hire good developers. Get involved in the hiring process and make sure new hires demonstrate their ability to code and a willingness to learn.
Finally, it may seem rudimentary compared to the Agile practices (which I do not hesitate to recommend), but I think the Joel Test is still relevant (do I get bonus points for the mention?). I don't know how highly your organization ranks, but there are a number of good suggestions about things that you can do whether you're a single developer or part of management.
Yes, Hudson and co are good. Continuous builds run together with tests are very, very helpful for a variety of reasons.
Git or other distributed tools are good (after you learn them). It allows people and groups to be far more independent in experimentation while they develop something.
Clean-cut building tools are good. Maven, sbt, buildr, cmake - anything. You should be able to send the projects around to other people and they can immediately build & execute it with one command or two.
Sane documentation practices: Use lax internal documentation standards (customers of course still need the full course, but internally you don't). However, you need some "most encouraged" place / utility to share documentation in case your teams need it. Jira(and co.), a wiki, trac... whatever you like. There just needs to be one or two places where people can go and look for documentation on things - if its not there, its probably nowhere. Fast failover.
Maybe look into functional programming or adapt the "as functional as possible" paradigm. If everything is small, manageable, and predictable, you'll have a real reduction in complexity that leads to error and poor code reuse.
By the way, "tool-assisted" accountability "in the workflow" is a bad, bad idea. It stifles innovation and leads to them wasting much (and I mean much) time on producing signs that they worked. Bloated documentation, inflated commit logs, ... those kind of things. Minimal and not really electronically rigidly enforced accountability is much better. Your workers already know what they're hired to do, and you can for the most part limit yourself to controlling the quality of intermediate and end results of their work.
If you want to do something about overly lax work practices, sometimes walk to people's offices with an appointment and maybe rarely without appointment to discuss their problems and current work and ideas. Maybe bring some food and other treats occasionally... Anything that credibly shows "you" or any of the managers or staff actually care about work and staff will make the remainder of the team care more as well - and that's what helps the most when dealing with skilled workers.
在团队中，首席开发人员担任集成经理的角色，这听起来很不错。如果您的管理不安全，您还可以使用“集成协调器”。他的工作实际上只是在开发，当 CI 服务器闪烁红色时大喊大叫，并且（这很重要）每周从 CI 服务器发送声纳报告的打印输出以及一些计划与实际情况给管理层。他们会感到一切尽在掌握，并会花整整一周的时间尝试完成所有数字。
I would start building teams, introducing continuous integration servers and distributed version control.
Your company management apparently does not believe in agile, chances are the believe in control(tm) (or at least the illusion of control). Chances are your management likes hierarchy, because nothing gives better illusion of control than hierarchies.
In the teams a lead developer takes the role of Integration Manager, this has a nice ring to it. You can also use 'Integration Coordinator' if you have insecure management. His job is actually just developping, yelling when the CI-server is blinking red and (this is important) send a weekly printout of the sonar report from the CI-server and some plan vs actuals to management. They'll feel in control and spend a full week trying to get through all the numbers.
Another task is to meet with the other Integration Coordinators to discuss integration of the different teams work. Here is where the distributed VCS comes in because it allows flexible, process driven change flows.
(make sure your management does not read the rest)
Your management now see a classical hierarchy, are informed and hopefully see enough progress to leave devs alone.
The devs have now an environment where agile practices can be deployed. You already have a prototype scrum-of-scrums structure to start from.
It is important to build confidence with your management. It will not last without management support in the long run. If your management does not want to take a leap of faith you can convince them by giving them what they want, but on your terms. It is relatively easy to influence management by being proactive and 1 step in front. If demonstrable results can be shown, most managers will find something better to do than meddle with development.
Now there are managers which are so insecure they need to micromanage everything and make sure everyone is even more insecure.
发布评论
评论（5）
对于精益软件开发七项原则来说，这是一个完美的问题：
是，您当然可以采用自动化测试、重构、编码标准、结对编程、代码审查、持续集成等工程实践。它们肯定不会造成伤害。但它们应该是更大计划的一部分，该计划涉及组织实践，并最终涉及公司推动业务的方式。敏捷实际上是面向业务的事情，工程实践和工具只是故事的一小部分，它们本身不足以节省数十万美元。
简而言之，无论您使用什么，如果您当前的（可能是连续的和定义的）流程产生的结果很差，那么不更改流程不会彻底改变结果。
因此，我认为启用“检查和调整”周期和反馈循环将是最重要的事情。
但变革通常涉及管理层。
另请参阅
This is the perfect question for a plug of the Seven Principles of Lean Software Development:
My point is that you can certainly adopt engineering practices like automated testing, refactoring, coding standards, pair programming, code reviews, continuous integration, etc. They will definitely not hurt. But they should be part of a bigger plan that involves organizational practices and, ultimately, the way your company drives the business. Agile is actually a business oriented thing, engineering practices and tools are just a small part of the story and won't be enough by themselves to save hundreds of thousands of dollars.
In short, whatever you'll use, if your current (probably sequential and defined) process produces poor results, not changing the process won't drastically change the results.
I thus believe that enabling "inspect and adapt" cycles and feedback loops would be the most important thing to do.
But change usually involves the management.
See also
根据我的经验，成为变革的单一推动者是很困难的。如果没有管理层的支持，情况会更糟。如果您没有管理层的支持，则需要双管齐下：a）招募开发人员以努力做到更好，b）向管理层展示您的改进如何影响底线。如果您认为自己确实获得了管理层的支持（或可以获得），那么您仍然需要团队成员的支持。
您应该引入工具（正如其他人所建议的那样），例如 Hudson 和单元测试框架，以便更轻松地做正确的事情。但引入只有你自己使用的工具一段时间后就会变得令人沮丧。您还需要向组织中的其他开发人员介绍这些想法，并希望他们有学习新东西并应用的愿望，以使他们的（工作）生活变得更好。
开始每周进行一次棕色包审查工具、新语言、解决问题的方法和审查论文。基本上任何可以引入新想法并让人们思考超出下一个错误修复范围的事情。 （这也会告诉你谁会接受更好的实践。）
展示您的工作流程。结对编程在您的组织中可能名声不好，但是让某人偶尔“帮助我”（即使您并不真正需要帮助）可以让您有机会向他们展示新的东西。反过来也可能发生这种情况。当你看到有人正在努力完成一些可以自动化的手动任务时，主动教他们一个新技巧。 （有趣的是，我认为当他们问“很好。你是如何轻松做到这一点的？”时，这更有可能产生影响。）
表现出对自己工作的自豪感，并尝试鼓励你的同事也这样做团队。不断询问您的团队和同事问题，例如“如果您使用它，您希望它如何工作？”以及“我们如何才能使其更易于维护/更易于扩展？”
聘请优秀的开发人员。参与招聘流程，确保新员工展示出他们的编码能力和学习意愿。
最后，与敏捷实践（我毫不犹豫地推荐）相比，它似乎还很初级，但我认为 Joel Test 仍然相关（我会因为提及而获得奖励积分吗？）。我不知道您的组织排名有多高，但是无论您是单个开发人员还是管理层的一部分，都有许多关于您可以做的事情的好建议。
In my experience, it is difficult to be the single driver of change. And it is much worse if you do not have the support of management. If you don't have management support, you need a dual pronged attack: a) to recruit developers to strive to be better, and b) to demonstrate to management how your improvements are affecting the bottom line. If you feel that you do have management support (or can get it), then you still need the support of the people on your team(s).
You should introduce tools (as others have suggested), such as Hudson and unit testing frameworks that make it easier to do the right thing. But introducing tools that only you use gets frustrating after a while. You also need to introduce the ideas to the other developers in the organization and hope that they have the desire to learn something new and apply to make their (work) life better.
Start a weekly brown bag to review tools, new languages, problem solving approaches, and review papers. Basically anything to introduce new ideas and get people thinking beyond the scope of their next bug fix. (This will also tell you who is going to be receptive to better practices.)
Show off your workflow. Pair programming probably has a bad name in your organization, but getting someone to occasionally "help me with this" (even if you don't really need the help) gives you an opportunity to show them something new. This can happen the other way around too. When you see someone struggling with some manual task that could be automated, offer to teach them a new trick. (Anecdotally, I think it's more likely to be have an impact when they are the ones asking, "Nice. How did you do that so easily?")
Demonstrate pride in your own work and try to encourage the same from your team. Keep asking your team and peers questions like "how would you want this to work if you were using it?" and "how can we make this more maintainable / easier to extend?"
Hire good developers. Get involved in the hiring process and make sure new hires demonstrate their ability to code and a willingness to learn.
Finally, it may seem rudimentary compared to the Agile practices (which I do not hesitate to recommend), but I think the Joel Test is still relevant (do I get bonus points for the mention?). I don't know how highly your organization ranks, but there are a number of good suggestions about things that you can do whether you're a single developer or part of management.
一些想法：
顺便说一句，“工作流程中”的“工具辅助”问责制是一个非常非常糟糕的主意。它扼杀了创新并导致他们浪费大量（我的意思是大量）时间来制作他们有效的标志。臃肿的文档、膨胀的提交日志……诸如此类的事情。最小化且不是真正以电子方式严格执行的问责制要好得多。您的员工已经知道他们被雇用来做什么，并且您在很大程度上可以限制自己控制他们工作的中间和最终结果的质量。
如果你想对过于宽松的工作习惯采取一些措施，有时可以预约去人们的办公室，也许很少没有预约去讨论他们的问题以及当前的工作和想法。也许偶尔带一些食物和其他零食……任何能够可信地表明“你”或任何经理或员工真正关心工作和员工的东西都会让团队的其他成员更加关心——这就是最有帮助的时候与熟练工人打交道。
Some ideas:
By the way, "tool-assisted" accountability "in the workflow" is a bad, bad idea. It stifles innovation and leads to them wasting much (and I mean much) time on producing signs that they worked. Bloated documentation, inflated commit logs, ... those kind of things. Minimal and not really electronically rigidly enforced accountability is much better. Your workers already know what they're hired to do, and you can for the most part limit yourself to controlling the quality of intermediate and end results of their work.
If you want to do something about overly lax work practices, sometimes walk to people's offices with an appointment and maybe rarely without appointment to discuss their problems and current work and ideas. Maybe bring some food and other treats occasionally... Anything that credibly shows "you" or any of the managers or staff actually care about work and staff will make the remainder of the team care more as well - and that's what helps the most when dealing with skilled workers.
我将开始组建团队，引入持续集成服务器和分布式版本控制。
您的公司管理层显然不相信敏捷，很可能相信控制（或者至少是控制的幻觉）。您的管理层很可能喜欢等级制度，因为没有什么比等级制度更能给人以控制的错觉了。
在团队中，首席开发人员担任集成经理的角色，这听起来很不错。如果您的管理不安全，您还可以使用“集成协调器”。他的工作实际上只是在开发，当 CI 服务器闪烁红色时大喊大叫，并且（这很重要）每周从 CI 服务器发送声纳报告的打印输出以及一些计划与实际情况给管理层。他们会感到一切尽在掌握，并会花整整一周的时间尝试完成所有数字。
另一项任务是与其他整合协调员会面，讨论不同团队工作的整合。这就是分布式 VCS 的用武之地，因为它允许灵活的、流程驱动的变更流。
（确保你的管理层不会阅读其余部分）
你的管理层现在看到了一个经典的层次结构，了解情况，并希望看到足够的进展，让开发人员独自一人。
开发人员现在拥有一个可以部署敏捷实践的环境。您已经有了一个原型 scrum-of-scrums 结构可以开始。
与管理层建立信心非常重要。从长远来看，如果没有管理层的支持，它就不会持续下去。如果你的管理层不想冒险，你可以通过给他们想要的东西来说服他们，但要按照你的条件。通过积极主动、领先一步来影响管理层是相对容易的。如果能够显示出明显的结果，大多数管理者都会找到比干预发展更好的事情去做。
现在有些管理者非常没有安全感，他们需要对一切进行微观管理，并确保每个人都更加没有安全感。
I would start building teams, introducing continuous integration servers and distributed version control.
Your company management apparently does not believe in agile, chances are the believe in control(tm) (or at least the illusion of control). Chances are your management likes hierarchy, because nothing gives better illusion of control than hierarchies.
In the teams a lead developer takes the role of Integration Manager, this has a nice ring to it. You can also use 'Integration Coordinator' if you have insecure management. His job is actually just developping, yelling when the CI-server is blinking red and (this is important) send a weekly printout of the sonar report from the CI-server and some plan vs actuals to management. They'll feel in control and spend a full week trying to get through all the numbers.
Another task is to meet with the other Integration Coordinators to discuss integration of the different teams work. Here is where the distributed VCS comes in because it allows flexible, process driven change flows.
(make sure your management does not read the rest)
Your management now see a classical hierarchy, are informed and hopefully see enough progress to leave devs alone.
The devs have now an environment where agile practices can be deployed. You already have a prototype scrum-of-scrums structure to start from.
It is important to build confidence with your management. It will not last without management support in the long run. If your management does not want to take a leap of faith you can convince them by giving them what they want, but on your terms. It is relatively easy to influence management by being proactive and 1 step in front. If demonstrable results can be shown, most managers will find something better to do than meddle with development.
Now there are managers which are so insecure they need to micromanage everything and make sure everyone is even more insecure.