2019-01-07 21:14:45 weixin_44167572 阅读数 14
  • 2019年C语言基础教程【源码,笔记,软件,案例】

    C语言概述 什么是C语言 一提到语言这个词语,自然会想到的是像英语、汉语等这样的自然语言,因为它是人和人交换信息不可缺少的工具。 而今天计算机遍布了我们生活的每一个角落,除了人和人的相互交流之外,我们必须和计算机角落。

    10671 人正在学习 去看看 传智

敏捷开发宣言:
1.个体和交互胜过过程和工具
2.可工作的软件胜过面面俱到的文档
3.客户协作胜过合同谈判
4. 响应变化胜过遵循计划,从上面的宣言可以看出,敏捷开发的核心是人 、协作、时刻可运行的软件、变化。
敏捷宣言》背后的12准则
我们遵循以下准则:
1、我们的最高目标是,通过尽早和持续地交付有价值的软件来满足客户。
2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更,帮助客户获得竞争优势。
3、要不断交付可用的软件,周期从几周到几个月不等,且越短越好。
4、项目过程中,业务人员与开发人员必须在一起工作。
5、要善于激励项目人员,给他们以所需要的环境和支持,并相信他们能够完成任务。
6、无论是团队内还是团队间,最有效的沟通方法是面对面的交谈。
7、可用的软件是衡量进度的主要指标。
8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9、对技术的精益求精以及对设计的不断完善将提升敏捷性。
10、要做到简洁,即尽最大可能减少不必要的工作。这是一门艺术。
11、最佳的架构、需求和设计出自于自组织的团队。
12、团队要定期反省如何能够做到更有效,并相应地调整团队的行为。
如果用一段话来简单明了的描述一下SCRUM,应该是这样的:
1、我们需要把人进行分割,所以我们建议会组建一些小的团队,人数最好是在3-7人。
2、我们需要把任务切小,拆分成故事卡。
3、团队在一个sprint周期内权利冲刺去完成计划的故事卡。
4、做持续集成去从整体上把握任务的完成情况和风险。
相比较而言,看板的具体实践就没有那么多的限制,看板主要强调以下几个方面:
1、流程的可视化。
2、限制并发。(在制品的数量)
3、优化交互时间。
相对于一个需要转型的团队来讲,SCRUM是相对比较激进一些的,因为这个框架告诉了你说SCRUM需要在迭代周期内开几个会,且时间盒(迭代周期)内完成的故事卡尽可能在开了计划会承诺交互会,就在迭代周期内完成(否则团队响应变化的能力就会变弱),且迭代周期内要完成的事,在这一个迭代周期就尽可能保持不变,以免引发一起不必要的浪费。而看板是一个比较渐进式的变革,它一开始的时候可能没有那么多的条条框框,是一个更加轻量级的方法,但真正在现实的应用中,想要把看板方法实践得很好,反而是比SCRUM更加困难的一件事情。
下面就着重的讲一下SCRUM相关的一些知识:
从整体上来讲,SCRUM这个框架里面包含了这几个核心的要素:
1、3个角色:SM、PO、开发团队(自然包括了我们的开发人员和QA)。
2、3个产出物:Product Backlog、Sprint Backlog、交互的可用软件工件。
3、5个活动:计划会、sprint评审会、回顾会、每日立会、Product Backlog的梳理(发生在整个SCRUM周期的任何时间)。每一个会议都有自己的时间盒,其长短在SCRUM中都有比较明确的建议。当你召开某一个会议的时候,超出了这个时间盒或者召开某个会议的时候出现一些问题,也是一种有问题的信号。一个团队在冲刺的周期内,去充分的暴露问题,然后在回顾会上去分析问题,再进行改进。在每日立会上比较强调的是,根据昨天完成的情况来做出新的调整,我们每日立会上所描述的,一定是对有助于完成当前sprint目标的事情。同时,特别需要强调的是,在sprint评审会上,团队除了对当前sprint完成的故事进行show case还需要对剩余的任务卡进行梳理,可以让团队有机会去回顾和识别版本发布的风险。
4、5个价值观:公开、专注、勇气、承诺、尊重。
另外,还讲到了SCRUM最重要的时间盒,这个是我之前所理解的SCRUM里面,没有发现它竟然是如此重要的。还学到一个新的理论:番茄工作法是一个人的SCRUM,SCRUM是一群人的番茄工作法;理解到跨职能是团队层面的概念,而一专多能是每个团队成员层面的概念。现在回过头来看,发现曾经团队在尝试SCRUM的过程中,对有些方面是理解得不够的,包括为什么最终团队放弃了SCRUM转向看板,其缘由也不完全是曾经以为的迭代周期的问题,需要系统的来看待这个问题。不管一套理论是如何的完善,结合到实际的工作中的时候总会遇到这样和那样的问题,但抓住最本质的东西才是最重要的,抓住其精髓的部分,然后再加以灵活应用,以问题为出发点,能够真正的解决实际的问题才能给大家带来信心。
最后,分享一下SM的一些相关知识:
一、SM应该在团队承担的几种角色:
1、引导者,就像一个出租车司机,需要去哪儿,是由团队来决定的,作为引导者,带领团队到达他们想去的地方。引导团队建立团队规则,维护团队和指导团队外部成员遵守团队的规则。作为引导者需要特别注意的是,不能把自己的价值观强加于团队,让团队成员尽量表述自己的意见。
相信大众智慧—得到“最佳方案”
相信大众参与—得到“最佳执行力”
2、教练:指导团队和PO遵循SCRUM的价值观。教练作为一面镜子,在每日立会和回顾会等会议上,只陈述事实,在日常工作中尽量多去收集一些数据,通过陈述事实和提问让团队去思考,通过这种方式让问题的解决达成一致。(如果当前的陈述让团队意识不到问题的存在,那么建议继续守望,继续收集数据,再陈述事实,通过反射让团队去发现问题)
3、移除团队障碍。
二、SM的几个发展方向:
1、敏捷/教练:推荐《敏捷开发的艺术》和《用户故事与敏捷方法》。
2、技术(CI、TDD、重构等):最重要是去做周计划,去与别人结对或者做练习。
3、业务(PO):帮助团队的PO去切分故事,推荐《精益创业》和《用户故事与敏捷方法》。同时,建议QQ邮箱PO的千百十工作法:得到1千个用户反馈,选一百客户进行沟通,再从中选择10个沟通结果作为下一个迭代的故事。这样做,既有广度也有深度,能够持续不断地保证团队做对用户最后价值的事情。
4、转型:从A----B点,往往SM需要考虑,不止一种方法,需要多种方法,灵活运用。
5、教练:推荐《敏捷教练》,这一项要坚持实践PDCA,做周计划,比如:回顾会、心情曲线、跨团队指导等实践活动。
6、导师。
7、引导。
8、演讲。
后三者都是属于纯实践型的活动,需要多演练。大家可以基于目前的现状对上述8个维度进行一个打分,形成当前的雷达图,然后再做短中期计划,三个月后再去绘制新的雷达图,每一个短周期内,建议是集中精力对某一项进行实践和提高。做周计划是一个非常好的实践技巧,比如:阅读一本书,可以精细到每周阅读多少页。这样比起做月度计划,会让你的可操作性和跟踪性,能有更短的一个反馈周期,更容易实践下来。
如何让敏捷落到实处,下面是我理解的敏捷。
小功能点代码设计,以及小的功能点的代码开发,开发自测。
小的功能点测试设计,测试开发,测试执行。
敏捷包含结对编程,结对测试,结对工作。
包括测试设计时交叉执行,交叉设计,交叉评审。
保证分组开发过程中,各组工作对接上,所以各小组一起开发,统一意见。
持续部署。
测试驱动开发。先写测试用例,在开发功能代码之前。
鼓励项目开发着,QA,非技术人员之间的协作,包括验收测试和客户测试驱动。
持续集成。

2009-04-03 15:41:00 wuqinglianga 阅读数 401
  • 2019年C语言基础教程【源码,笔记,软件,案例】

    C语言概述 什么是C语言 一提到语言这个词语,自然会想到的是像英语、汉语等这样的自然语言,因为它是人和人交换信息不可缺少的工具。 而今天计算机遍布了我们生活的每一个角落,除了人和人的相互交流之外,我们必须和计算机角落。

    10671 人正在学习 去看看 传智
           敏捷开发笔记一

     做了一些项目后,自己也有一定的积累了。自己所担心的问题也开始变了,逐渐由原来的担心能否成功开发出来,到了现在担心项目是能在规定的时间内完成和代码是否精炼。
    带着问题,去看了《敏捷开发》一书。
    得到以下三句话:一,一个类应该完成特定的某种功能;二,一个类应该能够适应一定的变化;三,一个类应该能够很好被理解。
    学编程之始,担心功能是否能够实现。现在开始担心开发是否快速,代码重用性是否足够好,代码可扩展性是否良好等等。说实话,我现在很厌恶敲重复的代码,实在是无趣的很。
    路还很长,勉记。
2012-09-10 23:52:46 ckl881003 阅读数 137
  • 2019年C语言基础教程【源码,笔记,软件,案例】

    C语言概述 什么是C语言 一提到语言这个词语,自然会想到的是像英语、汉语等这样的自然语言,因为它是人和人交换信息不可缺少的工具。 而今天计算机遍布了我们生活的每一个角落,除了人和人的相互交流之外,我们必须和计算机角落。

    10671 人正在学习 去看看 传智

  1. 客户合作重于合同谈判
  2. 为下周做详细激活,为下3个月做粗略计划,在以后做极为简略的计划。

2017-08-04 10:21:47 tooky_poom 阅读数 229
  • 2019年C语言基础教程【源码,笔记,软件,案例】

    C语言概述 什么是C语言 一提到语言这个词语,自然会想到的是像英语、汉语等这样的自然语言,因为它是人和人交换信息不可缺少的工具。 而今天计算机遍布了我们生活的每一个角落,除了人和人的相互交流之外,我们必须和计算机角落。

    10671 人正在学习 去看看 传智

1.      极限编程(XP)、Scrum、精益软件开发、动态系统开发方法(DSDM)、特征驱动开发、水晶开发(Crystal Clear)

2.      敏捷开发注重沟通,对需求、变更积极

3.      个体和交互重于过程和工具,可工作的软件重于面面俱到的文档,客户合作重于合同谈判、响应变化重于遵循计划

4.      Scrum是一个增量、迭代的开发过程。整个开发过程分成若干个小的迭代周期,每一个小的迭代周期成为Sprint,每个Sprint的长度建议为2-4周。Scrum中,用Backlog来管理产品或项目的需求,产品Backlog是一个按照商业价值排序的需求列表,列表条目的体现通常为用户故事。在每个Spring中,从Backlog中挑选对用户具有较高价值的需求。Spring挑选的需求将经过Spring计划会议上的分析、讨论和估算得到一个Spring 的计划列表,成为Sprint Backlog。在每个迭代周期,团队交付一个产品增量。

5.      Scrum术语解释

Sprint:原意为冲刺,Scrum指Sprint为一个迭代周期,即一个交付周期一般2-3周为宜,特别是互联网项目

Backlog:待办列表,既等待认领或者开发的任务列表

Product Backlog:产品待办列表,指产品的需求列表

User Story:用户故事,指一条需求,也就是一个功能点

Story Point:衡量用户故事的工作量大小的计量单位。一般为天/小时

Product Owner:产品负责人,简称PO。就是产品经理,即需求提出方,需求决定着。

Sprint Task:实现一条需求需要做的一个技术任务

6.      贯穿Scrum的三种角色

Product Owner(OP,产品经理)、Scrum Master(项目经理)、Scrum Team(开发团队)

7.      Scrum过程中的四种会议

Sprint Planning Meeting(Sprint计划会议)

Daily Scrum Meeting(每日站会)

Sprint Review Meeting(Sprint的评审会议,演示)

Sprint Retrospective Meeting(Sprint回顾会议)

8.      Scrum健康状态显示的两个工具

Backlog(待办列表):Sprint Backlog(Sprint的需求列表)和Product Backlog(产品的需求列表)

Burn-down chart(燃尽图、进度图):Sprint燃尽图和发布燃尽图(releaseburn-down chart)

9.      Sprint Planning Meeting(计划会议,需求会议)

在每个Sprint前召开,一般为2-3小时。就是团队确认和沟通的过程。

会议上主要解决两个问题:1.决定在Sprint中完成哪些工作? 2.决定如何完成这些工作,需要多长时间?

会议内容:

1.      分析和评估产品Backlog

2.      确定Sprint目标

3.      决定如何达到Sprint目标(设计)

4.      根据产品Backlog条目创建Sprint Backlog

5.      为Sprint Backlog每个条目做预估,用小时算。

会议注意事项:

A. 需求整理

1.      Scrum的理念是解放产品经理写复杂的详细的prd文档,当然一些业务场景的原型图还是需要的。

2.      Backlog要简单明了,没必要写详细的描述文字,开发过程中要注意实时沟通。

3.      召开Planning Meeting之前产品经理整理好需求列表,及其排好一个大概优先级。需求由产品负责人负责。

B. 任务拆分

1.      Backlog要停留在业务需求层面上

2.      把用户story拆分成合理的需求,产品经理要提前做好拆分的功课。

3.      超过5天或者10天以上的任务要拆成小需求,降低估算难度。

4.      任务的开发时间由team决定。

C. 估算时间

1.      永远不要站在牺牲内部质量的基础上。

2.      估算方式可以用Scrum纸牌,所有人一起出牌,求平均,单位最好是小时。

3.      尊重每一个选择,当差距过大时,问清楚原因,但不要指责。

4.      估算时间的时候每个人都没有发言和干预权,有干活的人一起评估。

一旦确定Sprint的周期后,如果由紧急的任务加进来,根据优先级,将低优先级的需求下降,或者将时间长的任务拆分或化解。

10.  Daily Meeting。每日立会,就像每日工作报告。由Scrum Master(项目经理)组织,由每个团队成员轮流回答三个问题

昨天我做了什么?今天我计划做什么?我遇到了哪些问题?

         注意事项:

1.      不可以干预,只说与这三个问题有关的内容。由需要讨论的内容,记录下来稍后讨论。

2.      Scrum Master 和 ProductOwner必须要参加

3.      团队成员互相交流,不是向Scrum Master报告

4.      一个自组织的团队有一个非常明显的每天的节奏:Daily Scrum之前非常安静,每日站会之后有一段活跃的讨论,到午饭之前慢慢安静下来。午饭之后会有另一个阶段的活跃讨论,当下班前慢慢的安静下来。这就是一个自组织团队的脉冲。如果你能感受到这个节奏,说明这个团队是健康的,每日立会起到了效果。

意义所在:

1.      团队商量决定谁来做什么,为当天排一个计划。

2.      每日立会是团队面对面沟通和团队自组织的体现

3.      团队沟通状态,了解现状,发现障碍。

4.      每日立会是Scrum过程进行每天的检查和调整的环节。团队回顾昨天的工作,做调整,持续的改进。

5.      Scrum的理论基础是保持过程的透明性让参与过程的所有人了解真实状况

6.      同时可以更新Sprint Backlog和Sprint燃尽图

11.  Sprint Demo Meeting/SprintReview Meeting

全体参加,还可以找公司的得利益者和很多外援,旁听的人越多越好。阐述Sprint的目标,大概描述一下,在开始之前。不要做花里胡哨的演讲,演示可以工作的实际代码。注意力放在我做了什么,而不是我怎么做的。Demo这一定是开发者,要给所有人展示和show的机会,不要越俎代庖。尽量1小时解决,控制在2小时内。

一定要做Demo Meeting,一定要有时间概念。

意义:

1.      促使Team真正的完成工作(如果工作没有真正完成,Demo时自己就会过意不去)。

2.      增加开发人员的快感,使之得到大家的认同感。

3.      同时让其他工作人员了解到你的成果。

4.      有助于提高开发者的工作积极性,都会想做更多的东西,以至于下次Demo时有更多的东西。

5.      同时可以让同伴增加沟通和了解,同时可以锻炼程序员的口才能力。

注意事项:

1.      当细节太多的时候,不要演示一大堆琐碎的Bug修复h额微不足道的特性。

2.      想办法让“无法演示的东西”变得可以演示,这是一个show的机会。

12.  Sprint Retrospective Meeting(Sprint回顾会议)

目的是回顾一下团队在流程人际关系和工具方面做的如何,团队意识出哪些做得好,哪些做的不好,并找出潜在的改进事项,为将来的改进制定计划。

团队的定期自我检视,什么是好的,什么是不好的。

每个Sprint都要做

每个人都要参加

开始的时候轮流发言,而不是主动发言。

记录问题,总结,并讨论改进的方法,放在回顾看板上

每人三个磁铁,将最重要的2-3个需求,成为下一轮的产品需求

13.  Scrum会议执行的五种价值观

1.      承诺——愿意对目标做出承诺

2.      专注——把你的心思和能力都用到你承诺的工作上去

3.      开放——Scrum把项目中的一切开放给所有人看

4.      尊重——每个人都有他独特的背景和经验

5.      勇气——有勇气做出承诺,履行承诺,接受别人的尊重

14.  Product Owner职责

1.      确定产品的功能。

2.      决定发布的日期和发布内容。

3.      为产品的profitability of the product负责。

4.      根据市场价值确定功能优先级。

5.      每个Sprint,根据需要调整功能和优先级。(每个Sprint前调整)

6.      接受或拒绝开发团队的工作成果。

7.      产品负责人是管理产品待办事项(Product Bakclog)的唯一负责人。

8.      任何人都不得要求开发团队按照另一套需求开展工作,开发团队也不允许听从任何其他人的指令。

PO的品质:

1.      确保对Product Backlog的每个条目都达到一定程度的理解

2.      任何时候都在,随时沟通需求

3.      懂业务,逻辑清晰

4.      善于沟通

5.      果断,提供需求边界

6.      得到授权

7.      全能型产品经理

8.      一个Team只有一个产品经理

9.      PO当然也可以由自己的需求团队

15.  Scrum Master 的职责:

1.      保证团队资源完全可被利用并且全部是高产出的。

2.      作为团队和外部的接口,屏蔽外界对团队成员的干扰。

3.      保证开发过程按计划进行,组织Daily Scrum,Sprint Review and Sprint Planning Meeting,推动Scrum活动。

4.      保证各个角色及职责的良好协作。

5.      解决团队开发中的障碍。

6.      对团队产出的最大化负责人。

7.      发起能提升Scrum团队生产力的变革。

Scrum Master的品质:

1.      Scrum Master 是Scrum团队中的服务式领导。

2.      Scrum Master是Scrum教练,非常熟练运用Scrum。

3.      一个敢于向老板等人说NO的人,保证开发tean不受打扰。

4.      负责,最大化的对团队产出负责。

5.      谦逊、协作、投入、有影响力。

6.      始终贯穿One Team,One Dream

16.  Scrum Team

1.      一般情况下人数在5-9人左右。

2.      团队要跨职能(包括开发人员、测试人员、用户界面设计师等)。

3.      团队成员需要全职。(有些情况例外,例如数据库管理员)。

4.      在项目向导范围内有权利做任何事情以确保达到Spring的目标。

5.      高度的自我组织能力。

6.      向Product Owner演示产品功能。

7.      团队成员构成在Sprint 内不允许变化。

8.      Scrum不认可开发团队成员的头衔,无论承担哪种工作,他们都是开发者。此规则无一例。

17.  Sprint Backlog示例

Task

Owner

Planning hours

Status

开发图片上传后台程序

小华

8h

Done

18.  Scrum的工具

1.      JIRA是Atlassian公司出品的项目与事务跟踪工具,被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

2.      Leankit使用一个基于云基础的whiteboard来称述组织流程。每一个图卡代表工作项目,并且提供状态更新选项。团队使用Leankit就可以看到工作负载分布,也能导出历史数据。

3.      Rally Platform for AgileLifecycle Management这是一个基于云技术的敏捷生命周期管理平台,在无数个团队里扩展使用,带有自定义界面、还能够自定义显示面板的功能,以达到自动化控制各种开发流程。

4.      Trello的目标是提供简洁清晰的团队协作工具。在Trello里面,有三个最基本的元素:Board、List和Card

5.      国内由禅道等。

19.  Scrum 实施过程中的注意事项

1.      如果在每个迭代中,我们对“完成”的要求比较低,那将会造成我们会有很多遗留的完成外工作。完成外工作持续累计会增加项目的风险,有可能导致产品负责人决定发布的时候,产品却因为积累了太多的完成外工作而无法发布,以至于我们还需要一个额外的Sprint来使它稳定。

2.      开发团队在每个Sprint交付产品功能增量。这个增量是可用的,所以产品负责人可以选择立刻发布它。每个增加都附加于之前的所有增量并经过充分测试,以此保证所有增量都能工作。

3.      Sprint的长度越长,我们需要预测的就越多,复杂度会提高、风险也会增加,所以Sprint的长度最好不要超过4周。越来越多的团队使用2周的Sprint,很多市场变化快、竞争激烈的领域,比如互联网和移动互联网开发团队也会使用1周的迭代。

4.      无休止的Sprint开发的同时,切勿忽略了团队的培养和培训方面的工作。

5.      Scrum 的四个特点:迭代开发、增量交付、高优先级的需求驱动、自组织团队

20.  敏捷开发并不完全是反文档的,敏捷团队要确定哪些知识需要显性化,既文档化,哪些知识保持隐形即可,这样可以节省文档化的工作量。

2010-03-14 10:32:00 serverxp 阅读数 497
  • 2019年C语言基础教程【源码,笔记,软件,案例】

    C语言概述 什么是C语言 一提到语言这个词语,自然会想到的是像英语、汉语等这样的自然语言,因为它是人和人交换信息不可缺少的工具。 而今天计算机遍布了我们生活的每一个角落,除了人和人的相互交流之外,我们必须和计算机角落。

    10671 人正在学习 去看看 传智

 

敏捷开发一直是我很欣赏的工作指导,可惜工作这么多年,都没有哪一个项目可以说“我们的项目正在敏捷开发”,原因?领导通常比较相信CMMI这样庞大,但是产出详细的过程(大家都觉得最详细的是文档,呵呵)。

 

以下内容只是自己在学习敏捷过程中的一些想法和要点的记录,不是展示给大家的作文,如果被你凑巧看见了可笑的部分,请不要介意。

 

 

原则,模式,实践都是重要的,但是使它发挥作用的是人。。。非常经典的一句话,也正是敏捷开发的核心,人才是一切的来源。。。

 

失控的过程膨胀,形容的非常贴切的项目开发描述,我参与的几个中型项目,都经历了这样一个过程。

 

敏捷开发宣言

 

 


  • 个体和交互, 胜过 过程和工具
  1.  
    • 团队的构建要重过环境构建--很多团队都是先构建了环境,再希望工具来让团队自动适应,工具很难让团队自动凝聚在一起。
  • 可以工作的软件, 胜过 面面俱到的文档
    • 没有文档的系统是一种灾难,代码无法传递系统原理和结构这些重要信息。
    • 过多的文档就更好吗?首先要花大量的时间去编写,而且系统一旦变化,还要保持文档与系统变化的同步,如果没有保持同步怎么办?那更麻烦了,这会对其他看文档的人产生重大的误导。
    • 所以编写和维护一份系统原理和结构文档更有意义。
    • 新进入项目,不了解项目的开发人员,应该是大家工作在一起,面对面的为他解答。
  • 客户合作, 胜过 合同谈判
  1.  
    • 与客户真诚的合作,而不是有了合同,就各自做各自的事情,然后等着合同到期的时候再来验收。
  • 响应变化, 胜过 遵循计划
    • 计划不要考虑的过远
    • 可以对近期(2周左右),做一个很详细的计划,对较远(3个月内)有个大概的计划,一年后?有个想法就可以了

 

原则

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