用于Agilo技术的开源工具 [英] Opensource tools for Agilo technology
问题描述
嗨..我们需要一个开源工具来改进我们的敏捷模型。这个工具必须是企业范围的.pl建议。
Hi..we need one open source tool to improve our agile model.this tool must be enterprise wide.pl suggest.
推荐答案
你可以使用任何问题跟踪器或错误跟踪器工具 [ ^ ]你可以找到（这个 [ ^ ]也很有帮助）。但是你看migh上的这些 [ ^ ]这些工具专门用于敏捷方法。敏捷项目管理是一种有趣的方法，因为敏捷性与gnatt图表和此类概念不一致。所以实际上你需要开发自己的方法来使用一个或另一个工具来更好地支持你的过程。
You can use much any issue-tracker or bug-tracker tool[^] you can find (this[^] is also helpful). But you migh look on these[^] which are tools made especially for agile method. Agile project management is an interesting approach as agility is not in line with gnatt charts and such concepts. So actually you will need to develop your own way to use one or th eother tool to better support your process.
嗨......谁能给我一些特定的工具？
Hi... can anyone give me some specific tool?
请看我对解决方案1的评论。
现在我想要发表一个单独的答案，解释为什么特定工具会是一件坏事，非特定工具会更好。一个简单的原因：敏捷或其他方法来了和离开，你的工作工具，开发断言长期与你在一起。
在所有情况下，你应该从非特定工具开始：修订控制，问题跟踪，单击批量自动重建，一些测试工具，开发方法和原型支持（这是一个非常常见的错误，当他们已经玩过他们的原型时不支持原型原型设计角色），开发和支持测试项目和设施。我还要补充：良好的内容管理系统用于记录，因此每个人都会以与代码库集成的方式进行记录，而不仅仅是技术编写者。 （从软件开发的角度来看，人们很痛苦地看到他们已经在Office中记录了敏捷，这是最不合适的工具之一，完全没有结构化。）
现在，我想每个人都应该明白那些开发方法文献，无论是否敏捷，都是......纯粹的伪科学。不要误会我的意思：阅读它是非常有用的：作者分享了认真的经验并给出了非常好的，通常是明智的（通常不是）的想法。分享想法和经验是一个非常非常好的主意。正式开发和执行某些学科是一个好主意。但这些作者并不只是分享，他们决定。再一次，我觉得他们了解自己这是错的，他们只是没有说清楚。太多的开发人员和管理人员误导了这种文学的严格科学风格，忽视了根本没有科学方法的事实，并且没有可靠的，甚至是实验证据。实际上，敏捷性思想是一个相当积极的步骤，但仍然没有任何科学性;而且没有银弹。开发人员需要使用更多的大脑，常识，了解目标的具体情况，发展经验和批判性思维。变得清醒！
Please see my comments to Solution 1.
Now I want to post a separate answer, to explain why "specific tool" would be a bad thing, and non-specific one would be much better. By one simple reason: Agile or other methods come and leave, and your working artifact, development asserts stays with you for a long time.
In all cases, you should start from non-specific tools: revision control, issue tracking, single-click batch automatic re-build, some testing facility, the method of development and support of prototypes (it's a very common mistake, not to support prototypes when they already played their prototyping roles), development and support if test projects and facilities. I would also add: good content management system for documenting, so every one would document in the ways integrated with the code base, not just technical writers. (It's pain to see that people thing they have gone "Agile" yet documenting in Office, one of the most inappropriate tools, totally unstructured, from the point of view of software development.)
Now, I think everyone should understand that those development method literature, Agile or not, is the… pure pseudo-science. Don't get me wrong: it's very useful to read it: the authors share serious experience and give very good, often wise (and often not) ideas. It's a very, very good idea to share ideas and experience. It's a great idea to formalize development and enforce some disciplines. But those authors don't just share, they dictate. Again, I feel that they understand themselves that this would be wrong, they just fail to make it clear. Too many developers and managers have been mislead by "strict" science-like style of this literature, ignoring the fact that there is no scientific methods at all, and there is no solid, even experimental proof. Actually, agility ideas is a considerable positive step, but still there is nothing scientific; and there is not a silver bullet. Developers need to use more of their brains, common sense, understanding specifics of their goals, develop experience and critical thinking. Get sober!
这篇关于用于Agilo技术的开源工具的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
