前段时间换工作到新公司，发现新公司内部完全没有任何的专案管理流程。为了说服老板导入软体专案管理以及建立好管理体制的好处，因此写了下面这篇文章。 虽然我的观点不一定正确，但这篇文章是我思索了好几天的结果。 若有任何指教，欢迎一起讨论 :) 部落格版本： http://dorgon.horizon-studio.net/archives/747 =============本文开始================= 最近陆陆续续的花了一些时间导入专案软体开发工具跟流程进到现在的公司中，我想就藉由这次的机会来描述我想像中一个软体专案应该要有的体制。当然，这些都是基於我过去在其他公司参与游戏开发专案所得出的结论，或许很多并不是最佳解，但我想里面应该有一些可以参考的观点。 基本上，我所认为一个好的软体专案开发体制需要能解决以下这三个主要的问题： 一、工作要能够连续，不要轻易的被打断：尤其是当一个人才刚进入工作的状态却被其他的临时事项或沟通所打断时，要再重新进入原本的任务内容所耗费的时间与心神劳力在无形之中都是个浪费。 二、任务内容要能够有效传达：由於软体开发在本质上复杂与不可见的特性，很多时候口头上所讨论的内容每个人所理解的都不尽相同。又尤其开发过程中肯定会有不少任务内容展开，而开发人员肯定是一件一件的对於这些任务进行消化。而在这期间，软体需求的各种修改与追加其实会是一种常态，特别是对於新创公司而言，要如何让这些任务内容有效的传达到所有相关的参与者身上，而不是藉由开会来占用人员宝贵的开发时间，则是一件软体专案管理上必须要思考的议题。 三、软体设计过程要能够追踪：软体开发不同於其他产业，它很难用任何量化的指标去评估。公司的价值基本上就是围绕在里面成员的技能与组成，因此，要如何将开发经验传承下去则是每个软体公司都会面临到的挑战。这点在程式人员中通常都是使用版本控制软体(如Git)，但只有这个是远远不够的。程式码无法体现想要达成的使用者经验以及其他各种功能面上的决策与情境，因此如何为这些东西提供一个互相参照的机制，则会直接影响到公司的体质。体质好的公司，这些开发经验是要能有系统的累积下来的。人员若能够藉由这个机制而能简单且快速的存取到跟手 边任务相关的资讯，则能够大大的提升软体开发与维护的效率。 其实，上面这些问题在本质上都是怎麽「沟通」。要怎麽让这件事更有效率的被执行，其实在软体界中有一门叫「软体工程」的理论专门在探讨相关专案管理的开发议题，从各种从上千人参与的软体开发专案到十人以下的小团队都有提出一些方法论来解决各种软体开发上所会面临到的情境。其中一套被称作agile的方法论普遍被世界上各个开发团队所采用，其核心思想便是藉由每天不断的沟通、频繁的交付版本来快速的适应需求的变化。 然而，沟通是有成本的，因为沟通需求而被中断的开发时间意味着时间的浪费。因此在agile中的 「scrum」框架下才会有每天的站立会议的出现。藉由每天在进入工作之前跟成员间互相分享彼此在任务上的状况与需要协助的地方，以解决当面互相沟通的需求。 当然，就如同人月神话一书中所提到：「没有银弹」──软体开发并没有一套完美的方法论可以完美的套用。各个软体专案管理必须要根据人员的组成与专案的特质进行不同的管理流程，一切都要以如何进行有效与简洁的沟通为基础来进行发展。 基於上面的需求，市面上其实也已经有几套专案软体系统可以用来协助我们减轻成员间沟通的负担。 其中最有名的是jira( https://www.atlassian.com/software/jira )，它是目前公认做的最好的专案软体管理工具，只是如果要完整的使用该公司的方案的话，在价格上会有些昂贵。 再来就是redmine( http://www.redmine.org/ )，由於这套解决方案是免费的，因此在市场上占有不小的份量。只不过我个人用过的感觉是缺乏了不少关键性的整合能力，而且server必须要自己架设，适合有专门资讯人员在管理的团队。 接下来便是微软的vsts( https://www.visualstudio.com/team-services/ )，由於其完整度还蛮高的，各种整合跟服务都很不错，而且5人以下免费，git跟git lfs的空间无上限，因此作为startup使用的专案软体管理工具是蛮适合的。 另外也有不少小团队采用Trello( https://trello.com/ )，只是我觉得这套系统作为个人使用的任务管理工具虽然还蛮完美的，但当团队成员扩张到5个人以上的时候就会开始显得有些零乱，到10个人以上时基本上就会呈现一种无法管理的状态。 当然，除了使用专案管理系统之外，还是会有即时沟通的需求。基本上，市面上的专案管理系统会在每天汇整当天的任务资讯并寄到你的email，但若我们在专案管理上的任何更动或任务的指派都能够即时通知到相关人员的话，那麽团队就能够更敏捷的去处理各种突发状况。 通常大部份的人想到的都会是建立一个line或Skype群组并手动的通知对方相关的任务变更，但「手动」这件事其实是一件劳心劳力的事，若能够自动化的话该有多好？而且建立line或skype群组意味着公司需要再去寻问员工私下个人的帐号资讯，这对於一些重要资讯的控管与流程的制度化其实是不好的。 这就是为何市面上会有slack、hipchat或microsoft teams……这些群组聊天软体出现，它们不仅仅跟专案软体系统有一些自动化机制上的整合，更重要的是如果这们软体是直接跟公司的email帐号绑在一起，就能够让员工们做到公私分离，在公事上分享相关机密资讯时就不会有太多的疑虑。 最後，根据agile的精神，我们必须要频繁的交付版本以达到快速适合需求变更。但交付版本这件事其实是一件劳心劳力的事，若是每几天都要缴交一个版本的话，那麽就会必须要配置一个工程师整天都在做这件事。这其实也是一种浪费，若是这件事也能够自动化的话该有多好？ 其实所谓的持续集成(Continuous Integration)就是在处理这件事。基本上要做的事情就是一套自动化建置与布署的流程，撰写自动化的测试程式以确保基本的软体质量，并在每天晚上自动执行这些自动化出版的脚本。其中这套持续集成系统最有名的是jenkins( https://jenkins.io/ )。这套流程虽然一开始的建置需要花费一些时间，但是当整个机制完成之後，团队成员每天能够拿到一个最新的版本以检视其前一天的工作成果，而且最大的好处是能够让各种潜在的议题在软体实作的初期就浮现出来。一个好的CI流程能够体现软体专案的心跳声，若是我们能够越早倾听出专案中各种潜在的病症，那麽便能让我们後期专案的开发与维护成本降至最低。 -- Sent from my Windows --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 219.70.222.43 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1491217470.A.FD6.html ※ 编辑: dorgonman (219.70.222.43), 04/03/2017 19:56:28 在我主推并导入vsts後，目前团队中的成员已经慢慢的开始会用开票的方式来指派任务了 之前是每想到一个想做的东西就直接跟跑过来问我能不能做 每次写code写到一半一直被打断实在很不爽 虽然没有CTO这个位置，但我是第一个加入公司的软体工程师 基本上我们是新创公司小团队，但就是因为小，所以我现在推动这些事没什麽阻力 ※ 编辑: dorgonman (219.70.222.43), 04/04/2017 08:54:37