企业中对人才的需求永不停止，对人才的浪费恨之入骨。
在敏捷软件开发中，所有提倡的并不是一个企业完可以照做的，在实际应用中适之存之。
模块化的分隔和尽快提交功能思想是本人最推荐的也是最喜欢的。在接到项目和对一个项目进行分析时应尽量的将其模块化和独立化，提高我们项目子模块的低偶合和高内聚。同时在编写程序时应尽快完成子模块的编写，并将独立的子模块提交并让和户试用，这样可以使模块尽快得到使用，同时也第一时间于用户交互。让用户尽早的提出修改和功能的不足之处。使问题在第一时间得以解决。
其实在模块化的结构思想中的关键是降低程序的复杂度将问题的粒度最小化。这样即可使问题清晰化同时大大的降低了问题的复杂度，同时将问题单一化。这一思想和数据仓库中的粒度化数据是一思想。粒度的确定是比较难的也是比较重要的，一个合适的粒度即可以回答很多问题，也可以大大减少数据的汇总和拆分运算。在软件架构中引进粒度的思想也是尝试多次，在多次的尝试是得到的结果是，引进粒度对架构是有很大的好处。即粒度可以清楚的表现出现有的架构中整个框架所表现出的分散性和即将展现出的偶合度。一个清楚的架构可以让程序员方便的添砖加瓦而不是让其苦思冥想的去实现程序。让程序员把更多的精力放在业务流程和整个企业内的数据整合中。
当然对于结队编程，这也许是一种富人的游戏。在现行的编程中都是个人手持牛刀。当然个人的刀是用来砍一个个微模块的，整个程序的成功是整个团队的砖块搭建的。结队编程在一定的程度上增强了程序的可读性，在长远的路上提高了编程效率，同时降低了逻辑性和一般性的程序错误率。如果接到的是一个大型项目（至少在五六年以上的项目）可以尝试差去实现结队编程的思想。如航天飞行的模拟系统、大气地理等自然环境的三维模拟等大型的高复杂度的系统中这也许是一种不错的选择。但是像这样的系统则更注重的是模块化的划分。如果把整个系统进行粒度解体，一定会在某一粒度将一个异常复杂的计算变的非常简单的。当然这期间粒度则起着订海神针的作用。这也往往是最让框架师和分析师们头痛的问题之一。
其中有一点在开发的过程当中业务人员和开发人员天天在一起这条原则性的东西，不能说错，但可行性则要考虑再考虑。天天在一起难免有其它嫌疑，最至少有一点频繁的沟通则是必需的。本人认为至少保持两天之内对新的进展向业务人员报告并则客户进行试测试那怕是对界面的欣赏，这样有利于对现有模块的设计方案让用户进行肯定或提出更改见意。这样有利于后期的大规模的修改软件，甚至重新设计一个模块。这样可以大大减少开发的反复性周期。但在一个团队的内部最需要的正如他所提出的面对面交谈一样。可以交谈自己的设计方案或开发模型或模式的套用等。同时要不间断的向上级报告自己的最新进展，以便上级做出更正确的分工于工作分配以及整个系统的进展。当然报告最新的进展不仅仅是自己的编程量的进展，编程量的推前是无法清晰的反应整个工程的进展。需要报告的则是工作中的模块的整体进度。编程量进展再快没有几个运行中的模块当然整体项目的进展还是不能前进。因为一个项目的进展则是需要运行中的模块来反应。
同时敏捷开发中较大的削弱了文档和加班。当然对于文档还是需要的，至少在前期的设计文档是必须的没有一个完整的设计文档大家行云流水最后只有草原放马了。在后期的开发当中可以考虑减少文档的书写，应该只记录一下大体的业务流程和个别模块的实现方案，而其它的细节性的东西则可不必书写对应的文档。而加班的问题则应项目的进展而进行。但过度的加班有可能换来的则是反复的开发周期，甚至延缓整个项目的整体进度，让开发周期进入反复的循环阶段。
在开发过程中还是需要注意一下新的技能和设计，这一点是值得肯定的。因为新的技能的设计可以保证软件的高质量、简洁、健壮。这样有助于提高软件的快速开发，有效的缩短开发周期以及提高后期软件的运行质量。当然在设计过程当中，敏捷开发不推荐存在过度设计。其理由是明天的变化永远比今天快，当然变化是永恒的。如果想的太多就存在着过度设计，如果早早结案则存在设计不足问题。本质是简单没错，把复杂的问题分解进行简单化，这是软件设计的最高境界也是最大的艺术。其实软件的设计并不是孤立不可预测的，我们完全可以通过现有的数据和基本流程完全可以预测未来的某一时期内的发展，甚至我们可以预留接口，但必定我们不是写操作系统。这样有可能存在过度设计的嫌疑。而上上策则是满足现行系统要求，而预留一定的可扩展接口。进行一个合理的设计，当然这也是设计师最头痛的问题。
在一个团队里，各个团队不需要在强迫的管理下完成各自的工作，最大化的优化则是团队内部各自完成自己的工作。在一个团队里有一个良好的协作则是重中之重。在内部进行任务分析和模块化工作则是最大的消化。在一定的时期内团队内部应该进行有效的交流。进行工作上的总结和改进。则是循序改进的最有效的方法。
