技术转管理，是很多技术人员的梦想，所以经常有人问我，怎么样才能转型管理？
项目管理，是最基础的管理，既要管理一个项目，又要协调整个团队一起，完成共同的目标。
我的管理转型就是从项目管理开始的，在从技术转型项目管理的过程中，让我从以前专注于局部技术实现，逐步转向关注项目整体；从个人的单打独斗，到借助整个团队的力量一起完成一个项目。
如果你随手拿起本软件工程教材翻翻，第一章一般都是讲“可行性研究”的，呈现顺序仅次于“绪论”，可见其重要性。
“可行性研究”通常讲的是如何科学地论证项目的可行性，以及这个项目是不是值得做。这个知识点比较简单，落实到期末考试的题目上，一般只是一道像这样的选择题或填空题：
“可行性研究主要从哪几个方面进行？”
专栏已经上线更新一段时间，看到同学们对软件工程有了更深刻的理解和思考，我很受感触。
有些人说走了很多弯路，日常搬砖，增删改查；也有的同学跟我一样“野路子”程序员出身，非常困惑希望建立自信；还有的同学发表上千字的学习心得，可以说非常用心。
编码的最终目的还是为了实现一整个软件的开发，在程序员的晋升之路上，总有单独挑大梁负责项目的时候。你会发现软件开发中的很多问题，都是可以通过软件工程的知识来解决的。
在《从软件工程的角度解读任正非的新年公开信》这篇文章中，我已经提到了“软件项目管理金三角”的概念。由于这个内容对于软件工程来说，非常之重要，所以我今天特别展开再讲一下。
你会发现，在实际的软件项目中不乏这样的例子：
- 一个项目，正常估算，要三个月才能完成，但是老板或客户要压缩到一个月完成，而你不知道如何说服他们；
在上一篇文章中，我们一起看了一下大厂和敏捷相关的一些流程规范，同时也为你留了一道思考题：
如果每周一个Sprint，怎么保证每周都有交付，还能保证产品质量？
所以在这一篇中，我们就以每周一个Sprint的小项目组为例，看看它的日常是怎么应用敏捷开发的。
在我还是一个野路子程序员，到处接私活做网站时，就开始好奇：大厂都是怎么开发软件项目的？直到毕业后，我前前后后加入了若干大中小型企业，包括这些年在美国高校、公司的一些经历，对大厂的项目开发有了比较多的了解。
其实大厂做项目也没有什么特别的，无非就是工程中常见的“分而治之”的策略：大项目拆成小项目，大服务拆成小服务，大团队拆成小团队。
服务之间通过商定好的标准协议进行通信，架构上将大的服务拆分隔离成微服务，大团队按照业务或者服务拆分成小组，按照一定的流程规范保障协作。最终，各个小组要负责的内容其实就不多了。
关于敏捷开发的实际应用，现在无外乎有以下几种常见的情形：
- 很多团队想敏捷开发，但不知道该怎么上手；
- 有的团队已经应用了一些敏捷开发的实践，然而效果不理想，不知道是敏捷开发的问题，还是自己实践方式不得当；
- 有的团队听说了敏捷开发，但是并不知道它是什么。
在上一篇文章中，我重点介绍了瀑布模型。你现在知道了，瀑布模型简单易行，对于软件质量是有比较高保障的。但是瀑布模型对于前期需求不明确的项目，很难开展需求分析，后续如果有需求变更，瀑布模型便很难响应。
而且，每个软件项目的情况各不相同，都有自己的特点。比如说：
- 有的项目风险很高，客户可能随时不给你钱了，得要做好准备，随时止损；
可以这么说：瀑布模型算是现代软件工程的起源，软件工程的发展，很大部分都是构建于瀑布模型的基础之上的。 我们后面所学的软件工程的很多内容，都是源自瀑布模型的衍生，或者其中某个阶段的细分。
我在上大学期间，还并不懂软件工程瀑布模型这些知识。当时我自学了点编程知识，然后开始在外面接点做网站的小活，开发模式非常简单，接到活直接写代码，有问题就改。这样下来居然也做了不少小网站，但是大一点的网站项目就搞不定了，甚至手头的小网站项目，找个同学帮忙都不知道大家该怎么分工。
所以当时我也很好奇，大的软件系统是如何开发出来的？那么多人一起开发一个软件，系统是如何分工协作的？
软件工程是一门用工程化方法解决软件项目问题的学科，其本质也是一门工程学科，这门课的知识在学完后，不仅可以应用在软件项目中，还可以应用于日常生活中遇到的一些问题，Everything is a project。
这句话对我影响很大。我真的开始在日常生活中尝试应用“Everything is a project”的概念，小到做作业，大到完成工作中的复杂项目。
解决这些问题的方式，就是参考软件生命周期和瀑布模型，把一件事情分成几个阶段：分析、设计、实施、测试、完成 ，然后制定相应的计划。这种方法不仅非常有效，让我的做事效率大幅提高，而且让我在看待事情上，能够更全面地、站在更高的角度去思考。
