必发365手机版登录 > 国内 > 日事清——敏捷的项目管理方式

原标题:日事清——敏捷的项目管理方式

浏览次数:116 时间:2019-11-08

不关注员工的老板不是好老板

老板可以在公司中查看员工的工作计划、任务执行情况,以及他们的工作总结,及时发现员工工作中出现的问题。

今天这文章是我在简述写的最长的了。到最后有点小建议,与诸君共勉。

团队、项目管理人优先而非事优先,管理的是人心,如果让大家能认同你这个领导或者认同这个项目为由重要。所以讲一个开发需求的时候不要干巴巴只讲我们要做什么,更重要的是要讲清楚我们为什么要做这个,我们要实现什么目标!再者就是多鼓励,我是做产品的,很多时候技术在与我对接过程中会提出针对该需求的优秀产品体验建议,我就会鼓励赞美他们,无论你的赞美是多么的拙劣,别人听到都会高兴的。往复循环,整个团队都会为优秀的产品而工作,而不是干巴巴的对接、干巴巴的开发。

最近王者农药异常激烈呀,大概是高考生们玩疯了,回想起我的高考,分数线只比清华差了一点,可惜啦~当初我考几分来着?哦~~~~·是68.8呀————虽然是老梗了,不过发朋友圈装装逼还是挺爽的。

套用一句比较俗气的话,敏捷不是放诸四海而皆准的通用理论;敏捷不是玄而又玄的文化;敏捷不是在传统项目合作模式下包治百病的金丹;敏捷不是抛开纪律盲目求快。除了这些,敏捷还不是什么?那么,今天你真的“敏捷”了吗?

多种格式的文档云端存储

文件支持多种格式的文档上传到云端,还支持多终端在线预览,你可以随身携带,随时查看

Agile是指企业能够对外部环境做出速捷、有效的反应,是未来企业的必备素质。21世纪企业面临的竞争环境将是一个不断变化、不可预测的环境。由 于高新技术的出现和更迭越来越快,产品的生命周期日益缩短,企业要面对这样的新的竞争环境,抓住市场机遇,迅速开发出用户所需要的产品,就必须实现敏捷反 应。

思考一个问题:如何提高项目开发效率?

①最核心功能

管理过项目或者做开发的朋友是否有遇到这样一种情况,经常快到上线的时候,项目经理会说保证流程能走通,基本功能可行,其他细节不影响使用就行。后面再完善。那么反过来想,一开始就得从核心功能出发。也许一开始觉得项目时间够,但是实际中遇到什么技术难点或者某处逻辑出错,导致全盘推翻的情况比比皆是。且作者在这里谈论是使用快速开发方式,基本上是项目进度是很紧急的,这时候更应该从核心功能出发,首先确保基本功能和业务流程能走通。

《精益创业》这本书大家都听过吧,里面的核心想法就是快速开发出最简可行产品投入市场,并且不断迭代更新。这里的产品指互联网产品,app/PC站点等。最简核心产品简单来说就是指用最快、最简明的方式开发出一个能够让用户去使用的产品。比如,我要开发一个购物app,最核心的需求就是能购物,那么像评论、积分体系什么的我就可以先不用开发。

②减少等待时间

团队之间开发很多时候时间都是浪费在等待面上,比如前端等待后端的接口,前端等待UI/UE的效果,UI/UE等待产品的原型...可能你给每一个模块都安排了固定的开发时间,但保不准,突然间某个模块遇到技术难题了,而延误了下一步的对接。

因此做好的项目管理,就得将项目逐步分解,然后按照开发的对接次序进行排序,确保不要出现等待的情况,项目分的越细致,越不容易出现等待的情况。

团队之间一定要重视对接,不要一声不吭等待上家主动对接,也不要一声不吭等待下家找你对接。

接下来再说说敏捷开发的概念以及核心内容

敏捷开发就是以用户的核心需求为中心,横向将项目细分解为许多的子项或者模块开发,纵向根据实际的运作需求不断更新迭代。

而敏捷开发中一个核心内容就是看版。项目参与者通过看板的方式来协作整个项目的开发。

直接上场景吧,了解过敏捷开发的朋友应该有见过以下内容:

提出开发需求:

上图就是每日的站立会议了,参会人员可以随意姿势站立,任务看板要保证让每个人看到,当每个人发言完后,要走到任务版前更新自己的燃尽图。

任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。

每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)

接下来讲讲看板的在线版,虽然交流上不如办公室白板会议式的看板,但是却胜在灵活,信息更全,容量更大。

以上是日事清看板的截图。在线看板可以将每个事件排序,让开发者明确优先级以及上下层的对接关系。

并且还能看到预计事件与完成情况。让所有参与者能够对项目一目了然。自然开发起来就不容易出现断层的情况了。

除此之外,日事清还有很多的功能:

1、天报制度

今天推荐的不仅是一种工具,更多是推荐一种项目管理方式。如何合理协调开发团队快速开发完成一个项目。今天就分享一种针对小型求快速的项目管理方式和工具。

3、版本控制

实时跟踪每项工作的进度

你可以直观的了解每个员工的工作进度,并且可以通过甘特图查看项目的进度安排

敏捷开发,看到过这个词时,很多人一直没有什么深刻的体会,也没有仔细去研究到底什么才是敏捷开发。而一直在很多人的思想里,敏捷开发的印象就是, 开发速度比较快。没错,做互联网的,快确实是一个制胜的法宝,那么敏捷开发似乎也就是在互联网应用的开发中最适合的方法了。那么敏捷开发中的参与者应该是 什么状态?这似乎成了一直以来困扰很多管理者的严重问题。可以说,在敏捷开发中,并没有觉得有多敏捷,进度一拖再拖,问题一个接着一个,让我觉得我们是在 进行慌乱开发。为什么会这样?

就算是进行远程开发或是两地使用开发,项目组的成员每天至少碰一次,不管是当面的,还是通过其它方式,如通过电话、email、Skype或其它。进行敏捷开发的时间,任何团队都不能以任何理由进行孤立的开发。

如果没有一台干净的电脑来进行团队代码管理的话,则很有可能导致代码的混乱。而每天只须花很少的时间,哪怕一天一次,进行及时的数据提交与代码提交,则可以有效的保证团队之前代码的同步及代码的备份。

绝对不会错过的任务提醒

你可以为任意一条任务设置提醒,提醒会在多端同步,你可以随时随地收到提醒

7、项目进度风险控制

轻松分享工作生活的点滴

可以使用笔记与同事共享你的工作资料、学习心得,并且可以随时与你的同事展开讨论

4、需求失灵

2、例会制度

9、牵一发而动全身

目前项目中,开发者或者说参与人的状态是混乱的,或者说是慌乱的。那问题在哪里呢?是工作流程出了问题?不应该啊!在项目启动前已经定了一个看似美 好的流程,而且是经过参与人讨论一致通过的。那么问题在哪里呢?原来是沟通、传达出了问题,执行力不够。那么,就必须加大执行力,今日事今日毕,这是必须 的。

即使手里拿着30页且客户进行了签字的需求说明,有可能仍然不知所措。相对起那些良好的设计、精确的分析等,与客户持续的沟通、及时的反馈、不断的演示这些工作显得更加的有效果。可以有效的获得需求变化,减少误解,更加准确的把握用户的需求。

敏捷是大家在一起高效率地工作,清除所有沟通上的障碍,关注于增值的活动,从而使得开发更加成功。敏捷是大家肩并肩地工作,而不是什么都通过文档。 敏捷是管理者积极地参加到项目管理中而不是整天去写状况报告,用那个来监督到底发生了什么事情。敏捷是开发人员和涉众(项目开发中涉及的从需求到最后交付 的各种人员)在一起制定实际的计划,而不是用复杂的微软Project去制定一些几乎没人看的进度表。

很多时间,在功能上做了一个很小的变动,往往导致花费好几天的功夫来进行软件的集成与整合。如果没有持续的整合、及时的回归测试、可靠的整体设计,一些看起来非常微小的修改都有可能导致很大的麻烦。

8、架构师身体力行

很多开发人员,甚至一些高级的软件开发人员,对于单元测试没有足够的认识,在行动上也没有足够的注意。大家都一致的认为那是QA的事情。就开发人员 来讲,单元测试应该是一种白箱测试,能从功能上充分的测试软件的功能性。而对QA来说,只能是一种黑箱测试,无法深入的去分析代码的优势,只是从用户的角 度进行功能上的测试而已。

5、单元测试是QA的工作

敏捷开发(Agile Development)在国内越来越红火,随着“敏捷”一词出现在越来越多的项目中,于是,敏捷开发本身也被赋与了越来越多的意义,而敏捷的真正内涵反 而变得越来越模糊。如何迈出敏捷开发第一步?是按照敏捷宝典、操作指南或是教父语录,还是因地制宜、因项目定方法?完成所有这些工作后,我们就真的“敏 捷”了吗?

也许一个项目需要18个月左右才能完成,但在没完成之前,谁也无法进行比较准确的时间估计。无法确定需要多长的时间进行设计、编码及软件组件的组 合。但进行项目设计、实现及融合的人应该相对比较准确的掌握与估计项目的时间。因此,需要进行项目进度的风险控制,风险总是存在的,但要进行有力与及时的 控制。充分意识到项目中可能会存在的风险因素,在制定计划时预留一定的时间,如果在项目进行中出现了没有想到的问题,根据其重要性,考虑压后解决,要在计 划的时间内把计划的事情完成好,并为后续解决问题争取更多的时间。

另外,在一些产品级的软件开发中,觉得要实施敏捷式开发,我觉得也有一个不好解决的问题:没有具体的客户!没有具体的客户,那你的沟通去哪里寻找 呢?一般的做法也是给一些有兴趣的用户发布Alpha版本,或者是beta版本的软件。可是当软件都到了Alpha/beta版本的时候,软件还有迭代的 余地吗?未必!从我个人理解的角度来看,敏捷开发的适用范围还是很有局限性的。个人认为最适合使用敏捷开发的软件必须要有非常明确的客户才能进行,而有明 确客户的情况以定制型软件为主。所以,我觉得最适合用敏捷方式开发的软件应该是——定制软件!

四、小结

记得Jim Highsmith在他的《敏捷项目管理》一书中这样写道:敏捷是指在动荡的业务环境中,适应变化并创造变化,从而获得价值的一种能力。同时敏捷是平衡灵 活性和稳定性的一种能力。由此可见,望文生义地把“敏捷”理解为“做得快”也颇可商榷。如果缺乏有效的实施指导、忽视严格的敏捷实践,单凭着高层面的理解 甚至“文化”就开始盲目前行,往往会因为缺乏对质量的有力保障而失去平衡,最终欲速则不达。

三、敏捷十戒

即使每天通过Email给主管汇报工作,但有时主管还是无法及时准确的掌握项目组成员的状况及工作量。此时,通过每周一小时左右的例会将会有效的解决此问题。通过例会,大家面对面的就某些问题进行共同的探讨与讨论,找到共同的解决方案。

公平地说,很难设想敏捷术能如何发挥作用,尤其是在一些软件开发本身都问题重重的传统组织中,被误导过的敏捷更是难以帮上什么忙。

很多软件架构师基本上不写代码,这也许是好事。软件架构师嘛,当然是比较高级的,他们对环境、语言、类库方面都可能比软件开发人员要更加在行,但他们一般不编码。这样的架构师是危险的,特别是那些基本上不与首席开发人员进行沟通或咨询的架构师,离项目失败可能已经不远了。

另外,关于实施敏捷的效果也是充满置疑之声。我们经常看到一些号称Agile的国内项目,按照菜谱、操作指南和教父语录的提示,采用了许多花哨的技 巧和实践(做法),是啊,表面上确实Agile了,那么结果呢?项目还是不能按时完成,甚至严重超支和超时,这能叫“敏捷”吗?

二、变味的敏捷

自从有了质量管理这个词以及后来产生的质量管理部门后,很多开发人员就理所当然的认为质量保证是QA的责任了。其实每一个人都需要对软件的质量负责,特别是开发人员。Bug越最早发现,那么解决它的成本就越低。

狭义地讲,敏捷企业就是将柔性的先进制造技术、熟练掌握生产技能、有知识的劳动力以及促进企业内部和企业之间的灵活管理三者集成在一起,对千变万化 的市场机会做出快速、有效的响应。敏捷企业强调人、组织和技术的有机结合。通过这三者的紧密结合,敏捷企业可以发挥最佳的整体效益。评价一个企业敏捷性的 具体指标是时间、成本、稳健性(Robustness)和适应范围。对敏捷企业的广义理解,可以认为敏捷企业是一个CIMS(计算机集成制造系统)、动态 联盟、并行工程、仿真制造、高素质员工等多方面的系统集成,是一个基于CIMS、在CMS基础上发展起来的一个更高层次的集成大系统。

6、质量保证是QA的责任

10、加大管理执行力

一、前言

本文由必发365手机版登录发布于国内,转载请注明出处:日事清——敏捷的项目管理方式

关键词:

上一篇:日事清——敏捷的项目管理方式

下一篇:日事清——敏捷的项目管理方式