“自由与束缚的哲学统一”或许不该放到标题上去，毕竟它只是我灵光一闪的感悟。但这个spark让我感到高中到大学的哲学应该也没有白学，这是让人非常兴奋的一件事。
所以我还是把它放到了标题上。
来谈敏捷软件开发（Agile Software Development）。
由于在课堂上，老师已经介绍了敏捷开发、极限编程等概念，所以看到这些概念时，并没有过于激动。
但在了解这一开发方法产生的过程中，还是不由得想向用于叛逆于“繁文缛节”的人们致敬。
看到对“需求的不可预见性”的认同，以及对“不可预见活动不能按照可预见活动的那套方式干活”的认定时，我实在是又激动又感动，还要表示深深的认同。因为它表述出了我苦恼了一学期才得出的结论“日常计划不能定的太死”。
我曾经一度将一周的课表打印出来，花两个小时的时间来填满课表上的每一个空位，甚至把睡眠的起始时间也固定其中，好让自己又踏实又满足。但实践的结果是，我总是被各种突如其来的事情打乱节奏，我还在想怎么去补昨天没完成的计划时，现在又因为一件急事要放弃当前的计划了。
这简直是最让人depressed的事情之一了。
能发现问题的所在实在是一件伟大的事：我们不能把土木工程的方法论拿到软件工程来用。
也即，我不能将不可预见的每周日程死死的写在课表上，还期望实现这一周的计划。
看到这里，我又要热泪盈眶了，因为这简直是血的教训啊——我曾自愿为我航某个亚洲级的辩论比赛做开幕式视频，连续工作17个小时连续工作做出了成果，最终却被“用户”嫌弃了。
我的“引以为豪”成了别人眼中的“不合适"。主办方也为我的工作没能一次通过而遗憾。
"There is nothing more frustrating to a developer than seeing their hard work go to waste."
最终解决这一问题的办法就是，我找到看我的视频不爽的人，一起工作，他想要什么样的我就给他做成什么样的。
适应性客户确实有助于提高软件开发的有效性。
我想我一定也是Agile Software Development的忠实用户者，因为自己用亲身体会验证了其观点的可贵。
这个想法非常有趣。
大家早都习惯了工厂式的工作方法，码农只是流水线上的一名工人，只需要完成某些相应的工作就好，就像软件工程中我们分PM，engineer，test三个部分一样，每个人只需要各司其职就好。可是这却忽略了非常重要的一点：软件开发是一件极富创造力与灵活性的活动。
深表赞同。
文章读到这里，我对所有敢于跳出当前窘境、站在更高层次看待问题的人产生了深深的敬意。
因为在大二下学期我们完成一门叫“面向对象建模”的课程时，老师要求我们先完成需求文档，再根据文档来完成我们的软件开发。而我们实际的过程是，先完成软件开发，再按照我们写好的软件去画UML图，去写各种需求分析，去设计测试用例等等。结果我们的文档写了70多页，想想如果先写70多页的文档再去开发软件，程序员早都没耐心了吧。
当时我们还在讨论“实际工作中一定也是这样，大家都是先开发再写文档”，却没有想到改变这一现状，只是觉得“要写文档？好吧我写。”
这种容易接受problem的态度真让人后怕。
联想到我们这次的软件工程小组的分工，其实还是认为每个人都是部件，而不是灵活具有创造力的软件开发人员。其实这也未尝不可，因为大家还没有到登峰造极的码神阶段。
另一方面，其实对整个队伍的分工进行设定其实也有其好处。“有序”在某些情况下，是可以保证高效的。
“The first part of self-adaptivity is regular reviews of the process.”
这一点又让我联想到自己惨不忍睹的时间管理经历。我试图review自己一周的时间开销，从而使得我对下一周的时间计划设定得更为合理。
但时间一下过去了两个小时……
所以写日记不是要所有事情都一点一点回顾然后记下来啊！所以review也一定要注重效率啊！
看完整个敏捷编程的叙述与思考，这个问题提的不能再好。是啊，我是否真的要用Agile Software Development？
回想一下敏捷编程的每个过程，灵活性，或者说对变化的适应性实在是太突出了。这种灵活会对实际的开发过程带来极大的不确定性，一定会影响整个项目的进展。
所以我们还得遵循敏捷编程的规则与价值观。
只有在一定的约束下，我们才能更自由。
相关文章
