基础系统总结一

      我第一次知道敏捷开发是在2013年的5月份,那个时候为了开发人事档案管理系统,米老师向我提出了使用敏捷开发思想来开发,然后在八期师哥的博客中和晚上看到过一些关于敏捷开发的理论知识,由于人事档案管理系统一直拖着迟迟没有完成,最后还是以最原始的的方法来开发了.

      本次作为教务系统的负责人之一,我负责的主要的是基础系统,在最开始的时候,我有一段迷茫事情,没有一个长远的计划,不知道该干什么,不知道如何去做.这个问题和米老师说过,同时也有其他的同学给老师发邮件,说在这个项目中感到很迷茫,感觉自己没有学到新的内容.然后老师安排了八期的赵帅师哥给我们分析我们的问题所在,他一步步的把我们带进入到敏捷开发的思想中.我很感谢给老师发送邮件的同学.说句实话,负责人都是感觉迷茫的,不知道如何去安排自己的组员去做工作,组员也肯定是迷茫的.

      3月10号晚上我在基础系统中开了一个会议,让大家对说说自己对于敏捷开发的一些感受.我主要是从以下四个方面入手.

问题一:<<火星人敏捷开发>>这本书看 了没有.

      从大家反映上来的情况,都觉得这本书看着很难懂,而且看不进去.因为这部书很多东西都是指导性的理论内容,没有亲身的实践,看着很难懂,而且没有人给我大家讲解关于敏捷开发的内容,所以看着费解是可以理解的.现在看不懂,但是通过看这本书可以解决大家就怕不知道的问题.我要做的就是让大家知道关于敏捷开发的理论知识.

问题二.对目前每天早上5-15分钟的晨会,大家赶紧如何.

      从交流中可以知道,大家都比较喜欢这样的会议,每天早上的站立晨会时间短,主要是对昨天做一个总结,对今天做一个计划,自己能够对其他的进度有一个大概的掌握,还能明确知道自己的任务.感觉目标很明确.大家都对长时间的会议比较厌烦,长时间的会议让人感觉很无聊,而且还是很浪费时间,而且效果还不好.站立晨会我觉得是敏捷开发中最成功的地方.所以在基础系统的开发中,站立晨会继续坚持下去.

第三.敏捷开发实施有一周的时间,大家对现有的站立晨会有什么好的意见?

      每天早上基础系统开发人员都会进行5-15分钟不等的站立晨会,每周会进行一个大的晨会,主要是对上一周工作的总结和对下一周工作的安排.对于这个安排,开发团队感觉一周才进行一次集体人员的晨会时间有点长,集体的站立晨会可以一周进行2次,时间可以为3-4天这样进行一次集体的晨会.我很感谢我的队友提出的这个建议,我一定会对集体站立晨会进行调整.

第四.谈谈对敏捷开发的一些看法和感受

      也许在敏捷开发中学习的时间过于短,加上对敏捷开发的理解很浅,这部分的话题进行的效果不是特别好,但是以后的继续开发实践中,还有更多的机会接触到敏捷开发,所以这个类似的讨论,还会有很多的.

 

以上的四个问题是我想的入手点,同时在这个讨论中,我的队友还提出了几个很有代表性的问题.

问题一:在敏捷开发中,有必要一个团队做到一起开发吗?

      在敏捷开发中,讲究的是有问题及时交流及时解决.一个团队做到一块开发,可以随时交流,而且做到一块一起开发,开发的氛围会变得相对来说比较好,更加有利于团队的开发.美国互联网三巨头的办公室不是一个个的小格子,每一个人占一个小格子进行开发,而是一个圆桌,一个开发团队围着这张圆桌进行开发,如:

现在微信总部开始模仿美国互联网三巨头的办公室,家里硅谷式loft办公楼.所以说敏捷开发中一个开发团队坐在一起开发是一件比较好的事情,前提是条件允许.

问题二:在敏捷开发中,文档还需要写吗?

      文档不管是在传统开发中还是在敏捷开发中,都是不可以缺少的一部分.文档是一个项目的精髓,如果一个很棒的项目,趋势了必要的问题,做的再好,除了问题,需要人员问题维护的 时候,没有文档,都不知道如何下手,最后还是得高昂的维护费用,最后由于无法进行拓展,不就就会被淘汰掉.

      在回答这个问题的是,我用了一个自己经历过的两个例子,一个是我在做人事档案管理系统的时候,做完的时候,给客户部署的时候,客户就开始说这个软件这部分他们的要求了,那里不符合了.一会又是这个软件不能用了,让人听着特别的没有成就感,客户只是看到了我们给他们做的项目不行,但是没有看到我们给他做的项目的功劳.后来拿着我们写的<<需求文档>>,<<概要文档>>,<<数据库设计说明文档>>,<<详细设计说明文档>>去和客户交流的时候,客户说没想到你们的软件做了如此多的功夫.如果没有下功夫,这些文档是无法出来的.听到的时候心里是开心的,至少客户肯定了我的开发团队的功劳.文档是开发人员和客户之间的交流桥梁,文档可以让客户肯定你的苦劳,也可以避免很多客户与开发人员之间不必要的矛盾,文档可以让客户和开发人员成为好朋友.这是我个人的例子,离大家最近的就是考试系统了.

      在考试系统完成之后是没有文档的,后期优化的时候,进行得特别困难,这个是大家深有感受的.文档是一个软件的精髓,文档是一个软件的心脏,文档用文字记录着一个软件的生命.所以在敏捷开发中,文档是不可少的,但是相对于传统的开发,文档只写最主要的文档,写的语言也更加明确精简了.

问题三:在敏捷开发中,如果一个问题长时间以内没有有头绪,该如何解决.

      在敏捷开发中,讲究的是每天做一个任务,一个任务的完成不能超过2天,如果一个需求过于大的时候,可以细分为任务.在做任务的时候,一个问题在你思考了你的工期的1/2时间后还是没有头绪,不知道如何下手的情况,你应该请教别人了,可以请教你的开发队友,也可以请教团队以为的高手,就是不要自己死磕着一个问题不放,这样影响的不单单是自己的进度,影响着一个开发团队的问题.在一个团队中,自己遇到的问题,不再是自己的问题了,而且一个团队的问题.

      教务系统之基础系统到现在有一段时间了,从最开始的需求了解迷茫时期,到现在的任务明确,有计划的进行下去,我学会了很多,一个软件的前期开发不是我一个人在努力,而且我和我队友一起都在努力.

      在这段时间内容,在管理上面我学会了一下几点:

      1.如果想要自己的队友不迷茫,首先要领导人不迷茫,作为一个领导人,如果感到迷茫的时候,不要慌张,你需要找方法解除掉自己茫,然后再一点点的把自己的队友带出迷茫区.对自己所负责的项目,最开始要把整个项目的大体计划告诉队友,让他们知道这个项目为什么要做,需要做什么.大致完工时间.

      2.布置任务,要规定好完成时间,并要求有反馈.不能布置下去的任务只是流于形式,布置下去了不闻不问的.

      3.可以通过日报来了解自己组员的工作进度,但是不能太过于依赖日报来决定,还需要不定期的去查看自己组员的进行和成果,做到心中有数.

      4.在和组员讨论问题的时候,多个人提出的想法都很好,一直做不了决定,这个时候就可以通过让组员把自己的想法画出来,然后来决定谁的想法更好.当自己在画出来的时候,就是把自己的想法整理好了.

      5.作为一个项目负责人,需要处理得事情比较多,这个时候可以把自己的事情罗列成一个清单放在桌面上,每完成一件事打一个勾,表示自己完成了,这样既可以知道一天要做那些事情,不会出现忘记没有做的情况,而且还可以给自己成就感,发现自己一天下来做了很多事.不会出现晚上睡觉的时候发现自己很多事情没有做,同时也感觉自己一天什么事情没有,失落是小事.没做的事情一天拖着一天,最后拖延症就这么出来了.