2014-11-30 15:33:17 u010191243 阅读数 1710
  • Access高效开发视频教程【初级篇】

    16年Access的开发经验沉淀 10年连续微软有价值讲师 近百种行业开发经验积累 打造完全不同的智能 高效 开发模式 你如果正在学习Access,或已经开发多年,都可以来感受一下 完全不一样的玩法,让你打开完全不同的开发思路。 独立Access开发 使用平台 或不使用平台的学员均可适用,让你即时突破传统开发的套路,提高行业开发的效率

    10742 人正在学习 去看看 王宇虹
    用了3天,充分挤完了海绵里的时间,看了《轻松Scrum之旅:敏捷开发故事》这本书,觉得写得很好,有意思,找到了当时看大话设计模式时候的感觉。
    从书的题目可以看出,这本书主要是讲敏捷开发的,我也是第一次接触,理解的不好还请读者见谅。
    一、从技术角度看:传统的瀑布模型由于在前期花费了大量时间去分析需求和准备文档,导致在产品模型在时间上的每一次迭代都会很漫长。而这其中很可能会发生需求的不断变化,甚至产品完成后早已和时代脱节,失去了其本应产生的作用。造成的后果很明了:用户不满意,而且耗资很大。
    而敏捷开发显得更为轻灵多变一些。首先,轻量级的文档使我们不再需要准备一些多年无人问津的复杂分析和记录;另外,对变化的充足准备使得需求的频繁变动不再成为程序员的噩梦。
    二、从组织管理角度来看,1、我们传统的团队开发很可能存在以下现象。如:部门之间不协调,缺乏充分的沟通,人际交流成为一纸空谈;小组内各成员也常常是各自开发自己的部分,对项目整体或与自己相关的部分也不很了解;沟通渠道缺乏导致上传下达和团队交流出现一些不必要的问题,甚至引发矛盾。
     这些问题的根源就来自于缺乏相应的机制进行组织和交流,把大家的意见和想法充分表达出来是敏捷开发中以人为本、团队合作的宗旨。
     2、在项目把控上,传统的开发都是定义好的,根据计划把整体的任务都一次性定好,缺乏灵活性,难以应对内外部环境的变化。但敏捷开发中的Backlog—Story—Task任务划分机制很好的解决了这个问题,使得在项目需求有较大变化时通过先急后缓的方式充分应对。
     3、在部门划分上,敏捷开发提倡按产品划分,而不是部门。把编码和测试人员绑定在一起,使整个开发的过程成为一个流畅的整体,避免了出现相互争资源;把单元测试放到每一个Sprint阶段之后进行,减轻了集成测试的压力,缓和了测试人员由于不理解需求,测试不彻底或描述不准确与程序员产生分歧。
    三、从学习角度看,我们可以借鉴敏捷开发中的一些优秀经验和思想。平时兼顾整体规划和细节规划,在应对变化上要做到灵活,给自己预留足够的缓冲时间。
     做好人际交流,了解集体状况、优秀的或与自己紧密相关的个人的状况,这是自我调整的强有力参考。
     最后,要做好选择,找到适合自己的环境和方法。踩在如此多的“关毅”的肩膀上,我们已经有足够的知识水平和认知能力去适应这个世界的节奏了。
    
    
2008-09-25 18:46:00 comeyes 阅读数 480
  • Access高效开发视频教程【初级篇】

    16年Access的开发经验沉淀 10年连续微软有价值讲师 近百种行业开发经验积累 打造完全不同的智能 高效 开发模式 你如果正在学习Access,或已经开发多年,都可以来感受一下 完全不一样的玩法,让你打开完全不同的开发思路。 独立Access开发 使用平台 或不使用平台的学员均可适用,让你即时突破传统开发的套路,提高行业开发的效率

    10742 人正在学习 去看看 王宇虹

        从以前的项目过度到现在的项目,已经几个月了,scrum开发方式大体已经熟悉!才有感(敢)而发写点东西。

        接触敏捷开发也有一段时间了,总体感觉还是不错的!对于需求变化太快的项目来说,这种与传统开发方式有很大区别的项目开发与管理方式,的确是有很强的适应性!光从开发效率上讲,提高会很大,这种提高可能不是针对个人,更多的应该是对整个团队而言。因为这正是scrum的最终目标:团队战斗!似乎与狼道有异曲同工之处!

2012-01-19 20:38:19 mqbtjcyts 阅读数 1020
  • Access高效开发视频教程【初级篇】

    16年Access的开发经验沉淀 10年连续微软有价值讲师 近百种行业开发经验积累 打造完全不同的智能 高效 开发模式 你如果正在学习Access,或已经开发多年,都可以来感受一下 完全不一样的玩法,让你打开完全不同的开发思路。 独立Access开发 使用平台 或不使用平台的学员均可适用,让你即时突破传统开发的套路,提高行业开发的效率

    10742 人正在学习 去看看 王宇虹

工作一年多了,所在的公司采用敏捷开发。作为小团队里一名普通的开发者, 既体会到了敏捷的优点,也收获了很多经验教训。在此记录一下自己地感悟,如果有朝一日自己去领导一个敏捷开发团队,要尽量想办法避免和解决这些问题。

背景介绍:

公司的开发进度是大概每5-7周发布一个小版本,这里面包括了1周的各种测试时间和1周的上过渡服务器的时间,所以实际上code freeze一般是每个开发周期开始后的3-5周。本人所在的小团队大约有5到6名开发,其中包括一名Team Leader,4名QA。 团队也有一名PM, 但是远在美国,一年见面沟通时间不足一个月。公司采用JIRA作为项目管理和追踪的系统。每个开发周期会有很多Feature, 通常是每个Feature由一名开发负责coding,一名QA负责测试,而每名开发和QA会负责多个Feature. 某些非常大的Feature, 会由多名开发和QA组成一个更小的团队共同开发。

Feature的复杂度和开发时间评估

在我加入公司的前半年,正好团队在进行人事调整,除了Team Leader外,其他开发人员对每个Feature几乎都没有背景知识,更无从评估复杂度和所需时间, 所以所有Feature的评估几乎都依赖于Team Leader一人。Team Leader经常性地估少了Feature所需时间(或者高估了开发的能力),过分乐观的结果是开发和测试人员经常性地加班或者赶工,背负了过多的压力。另一方面,因为开发时间的仓促,也导致了Feature质量不高。

在后半年,由于Team Leader管理能力地提升,团队成员逐渐了解自己负责的各个模块,加上团队成员对之前评估不准确的种种抱怨,在Feature评估上有了一些改善。在每个开发周期开始前的例会上,Team Leader会和开发人员一个个地过这些Feature, 开发人员如果认为评估时间不准确,会给出自己的意见,然后Team Leader再跟高层管理者沟通,进行Feature的调整。个人认为,这件事情说明高质量高效率的敏捷开发对Team Leader和团队成员的个人能力要求很高,并不是一个低门槛的开发方式。

与PM的沟通

团队的PO (Product Owner) 职责主要由 PM 来担任。我记得以前在看敏捷开发的一些成功经验时,其中很重要的一条是说PO要和团队天天在一起工作。但公司的情况是,PM都在美国,虽然会通过邮件甚至skype来联络,但是总有时间上的延迟以及沟通上的误会和信息的缺失。对于一些小Feature还没有太大的影响,但是本人亲身经历了2个需求复杂,工程量和时间跨度巨大的Feature, 无法和PM在一起工作就带来了各种个样的问题。有一次,按照需求文档花了2周时间做完的部分,在和PM电话讨论时被告知文档写错了,因而对底层代码又花了1周时间进行了大换血,浪费了宝贵的时间。更经常的场景是,因为无法实时地面对面地与PM沟通,当Feature大体完工后,PM会对各种细节给出超过20个修改意见,又是本可避免的巨大的时间开销。 个人曾经非常希望在做其中一个大型Feature的时候去美国与PM一起工作,不过公司似乎完全没有考虑过,所以只能咬牙坚持。不过如果以后自己做事情的话,一定会尽量避免这种“异地”问题。

团队激励与士气

这是所在团队最严重的问题之一。管理者没有做出足够的努力去了解每个团队成员,很少进行team building之类的活动(一年好像只有2次),更没有采用任何有效的激励方式,直接造成了一些成员没有积极性、情绪低落,甚至对工作完全失去兴趣。所表现出来的就是产品质量低、效率差、不稳定。如果我是管理者,哪怕自己掏钱,也要隔一小段时间就带其他成员去吃饭喝酒谈心,去了解他们的想法和情绪,然后在工作中做出适当调整。如果有条件,更会给予优秀者丰厚的激励,给非常不上进的人严厉地处罚,保持团队士气向上。

个人英雄主义完全不可取?

几乎每个公司都在说要注重团队合作,杜绝个人英雄主义,但本人的实践感悟是,普通情况下团队合作是对的,但是在一些时间紧、项目大的场景,个人英雄主义可能更能带来更好的结果。从最后一个季度,我主要做了两个大项目。第一个用时一个开发周期,只有我一个人负责。第二个用时3个周期,第一个周期主要我一个人,第二个周期4个开发人员,第三个开发周期还在进行中。因为第一个项目和第二个项目的第一个周期基本上就我一人,所以不存在什么‘不同意见’的情况,都是我自己思考和做决定。虽然也会犯错误,但是都能保证在最短的时间完成最多的Feature,同时保证系统的performance和stability维持在一个高标准上。

问题就出在第二个项目的第二个开发周期,这时候其他几位成员陆续进入共同开发,本以为能为我分担很多工作,让我更专心攻坚一些框架上的问题。结果由于大家在一些问题上的见解非常不一致,同时因为我没有任何权力和资历去做任何决定,所以造成了在很多问题上无休止地争吵,以及一些实现上地互相妥协和返工,完全打乱了我自己的计划和节奏。就个人标准而言,对第二阶段的产品非常不满意,在accuracy, performance, stability上都远没有达到我的预期。思考良久,觉得如果当初让我主做这个项目时,赋予我一票决定权、一票否定权,然后给每个人的工作职责一个非常明确的划分,不允许大家越界干扰其他人的工作,只可以定义‘接口‘来沟通,相信会比现在有一个更好的结果。

一言堂固然不可取,但过度Team Work有时带来的更是负面作用,不仅耽误了时间和进度,同时使产品因为各人不同的理念而变得四不像。其实敏捷开发很像打仗,因为要在有限时间和资源下攻取一个个阵地。这时,如果要派人带兵去作战,就一定要赋予这个人兵权,否则如果因大家意见不同而不听命,互相扯皮,甚至互相拖后腿的话,会陷入很尴尬的境地。


2019-03-01 12:07:38 weixin_44606268 阅读数 162
  • Access高效开发视频教程【初级篇】

    16年Access的开发经验沉淀 10年连续微软有价值讲师 近百种行业开发经验积累 打造完全不同的智能 高效 开发模式 你如果正在学习Access,或已经开发多年,都可以来感受一下 完全不一样的玩法,让你打开完全不同的开发思路。 独立Access开发 使用平台 或不使用平台的学员均可适用,让你即时突破传统开发的套路,提高行业开发的效率

    10742 人正在学习 去看看 王宇虹

敏捷开发与DevOps的一些随想

这是笔者第一次在 CSDN上发文章,估计可能读者寥寥。无妨无妨。

最近一直在从事DevOps项目,并且公司层面也是敏捷开发的推动者之一,所以对于DevOps和敏捷有了一些自己的感受:

今早看了王晔倞在CSDN上发问《为什么都敏捷开发了项目还会延期?》,我有感而发。

敏捷开发的根本是满足的灵活性,而非效率的提升。或者换句话说:业务需求和人员投入始终是成正比的,换了啥方式都是一样的,不是说敏捷成了银弹。这是产品经理或业务人员需要明白的问题。所以对于产品需求的取舍、用户倾向的试探就显得尤为重要,或者换句话说,码农们是产品实现的工具,是手和脚,但真正要去哪、干些啥、怎么干还需要产品经理这个大脑来决策。

敏捷开发来满足快速交付,但只是软件生产全流程中的一段,即:由idea到安装介质包的阶段(可能只作为单元测试,或者单元测试都还没做过)。离产品上线产生价值还远了去了。所以接下来的加速,就需要DevOps以及云的助力,例如:云的编排模块能不能做到自动资源供给,DevOps能不能实现各个环境的自动化部署,能不能将自动化回归测试一并结合进来,等等。

所以总结下个人观点:

  1. 工具做好工具的事情,但工具只能帮助决策,不能替代决策;
  2. DevOps在传统企业落地,极有可能是Dev和Ops分期来实现,时机成熟时,才串起全流程;
  3. 敏捷、DevOps确实是天生一对,但要一起上,还得看时机才成,但无论是敏捷、DevOps都需要持续的度量、反馈、优化、改进,对流程、对工艺、也是对产品都是一样一样的。
2019-05-05 20:27:37 hy_coming 阅读数 80
  • Access高效开发视频教程【初级篇】

    16年Access的开发经验沉淀 10年连续微软有价值讲师 近百种行业开发经验积累 打造完全不同的智能 高效 开发模式 你如果正在学习Access,或已经开发多年,都可以来感受一下 完全不一样的玩法,让你打开完全不同的开发思路。 独立Access开发 使用平台 或不使用平台的学员均可适用,让你即时突破传统开发的套路,提高行业开发的效率

    10742 人正在学习 去看看 王宇虹

前言

最近公司搞了一个敏捷开发的平台,需要我们开发需求人员熟悉怎么操作,说实话在这之前虽然也或多或少的知道一点敏捷开发,但是对其没有更加深层次的理解,而且每家公司的要求也是不一样的,另外今天在开会的时候也是受益匪浅,感觉从大佬们那里偷学了很多的知识,所以现在才会迫不及待的开始记录下自己学习的心得吧,下面先来看看什么是敏捷开发吧

一、敏捷开发

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

上面的这句话是从百度百科上面摘抄下来的,其实随着现在微服务架构的兴起,同时也是未来的趋势,他是将大服务拆分成很多小的服务或者叫做微服务都行,这样做的一个很大的好处就是服务与服务之间的耦合性越来越低了,部署起来也是越来越灵活,其实对于开发人员来说也是一种福音,至少我们开发的时候关注的点更加细致了,更加明确了,所以我认为敏捷开发是对微服务架构的一种补充,或者可以说是相辅相成吧。

二、平台

其实上面说了这么多最终的目的还是怎么让开发的流程更加的专业化,首先对于公司来说开发的流程更加专业化,从需求提出到开发到测试到验收的一整套流程在这个平台里面都可以很好的展现,并且还有各种各样的提醒和统计,同时也为公司人员的KPI衡量提供了一个很大的参考,对于个人来说你的需求也变的更加的专业化,有了这一套东西的存在,你的需求变得更加的稳定,从某种程度上来说对程序员也是一种保护。所以好好的用好这个工具是当前的一个重要任务。

三、规划

在开会的时候的时候大佬也跟我们分享了一下怎么使自己进步,一个人进步的最大标志就是不会单打独斗了,开始学会怎么去带领一个团队,不管是一个人还是几个人的团队,这是需要我们考虑更多的,大佬说了,你们在需求讨论后定计划的时候是怎么样去计算开发时间的呢?可能很多的人都是随便估计一个时间,有的根本就不知道需要多少时间,所以就胡乱说了一个数字,其实这个时间是可以比较准确的计算出来的,你可以从以下几个方面去入手:1.需要创建几张表或者几个字段;2.需要写几个接口(前后端分离开发);3.有没有逻辑特别复杂的需求;4.加上改bug的时间;5.另外在前面的基础上增加一点“意外”时间。通过上面的几点的分析你基本上就能够比较准确的知道这个需求需要的开发时间了,然后将自己的排期弄好,这样就能够不慌不忙的把事情完成了。

四、成长

还有一个问题就是很多人都是喜欢做专一的事,这个我不是很反对,对于年轻人来说更多的是深度,特别是对做技术更是这样,只有你的深度有了之后,然后再去追求广度的事,当然如果你希望成为专家,那就另当别论,更多的发展到最后还是需要走向管理岗的,那么这个时候就是需要你得广度了,因为专的那一部分其实已经有人在帮你在做了,其实这个时候的你也没有时间来做专的事了,所以在我们的日常工作中需要在各个方面去学习,不管是是自己的事还是不是自己的事,我说的是留心,不是抢别人饭碗啊,记得头条的张一鸣就说过自己年轻的时候不管是什么事基本上都是主动去干的,所以成功的人绝对不是偶然。所以需要处处留心,处处学习,这样才能有所收获,最后来一句共勉:不要在该奋斗的年龄选择了安逸!

没有更多推荐了,返回首页