设计师应该拥有的敏捷思维学UI好吗

UI / UI设计教程 / UI教程 /      

uimaker
UI设计师 / 江苏 南京

来源:网络   作者:佚名

关键词

设计师应该拥有的敏捷思维



敏捷基础知识

敏捷开发是一个灵活的开发方法,用于在一个动态的环境中向干系人快速交付价值。其主要特点是关注的持续的交付价值,通过迭代和快速用户反馈管理不确定性和拥抱变更。


敏捷概念


敏捷核心思维


• 价值驱动-关注高优先级目标、要事

• 适应变化-频繁的交付可见成果,频繁确认,确保交付正确的成果

• 自组织团队-目标驱动、共享责任


敏捷宣言


• 个体和交互 重于 过程和工具(Individuals and interactions over processes and tools)

• 可用的软件 重于 完备的文档(Working software over comprehensive documentation)

• 客户协作 重于 合同谈判(Customer collaboration over contract negotiation)

• 响应变化 重于 遵循计划(Responding to change over following a plan)


虽然右项也具有价值,但我们认为左项具有更大的价值。


更进一步的解读参见:


敏捷宣言遵循的原则


我们遵循以下原则: 


• 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

• 欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。

• 经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

• 业务人员和开发人员必须相互合作,项目中的每一天都不例外。

• 激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。

• 不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。

• 可工作的软件是进度的首要度量标准。

• 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

• 坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

• 以简洁为本,它是极力减少不必要工作量的艺术。

• 最好的架构、需求和设计出自自组织团队。

• 团队定期地反思如何能提高成效,并依此调整自身的举止表现。


Scrum的价值观


• 承诺:自组织团队开始的时候做出承诺,并在迭代期间尽全力完成履行承诺。

• 专注:一段时间内只专注于少数几件事情。Stop Starting, Start Finishing。团队的能力(精力)是有限的,在有限能力和有限时间范围内,专注于最有价值的事情,以取得更好的成果。

• 公开:在团队中公开进展(Progress),即可视化、透明,这样可以很容易的暴露出风险问题和障碍。并且透明也是尊重、信任的基础。

• 尊重:团队是坐在一起的,长期稳定的,这有助于加深彼此的尊重和了解。

• 勇气:(最缺的)我们需要勇气去迎接各种挑战,以及有足够的勇气去说NO。


更多敏捷知识可参见Scrum中文网


设计师应该拥有的敏捷思维



敏捷开发流程


强调事项


设计师应该拥有的敏捷思维



核心角色


• Product Owner负责敲定要开发什么、以什么顺序开发

• Scrum Master负责指导团队在通用的Scrum框架上建立并遵循自己的过程

• 开发团队负责确定如何交付Product Owner要求的产品


01、ProductOwner 


PO的职责:


• 确定产品的功能,为团队澄清产品需求

• 决定发布的日期和发布内容

• 为产品的profitability of the product (ROI)负责

• 根据市场价值确定功能优先级

• 每个Sprint,根据需要调整功能和优先级(每个Sprint开始前调整)

• 根据验收标准,接受或拒绝接受开发团队的工作成果

设计师应该拥有的敏捷思维


02、ScrumMaster 


ScrumMaster的核心职责:


• 保证团队资源完全可被利用,并且全部是高产出的;

• 和Product Owner紧密地工作在一起,及时地为团队成员提供帮助;

• 肩负在团队中的敏捷推广工作,让团队按照敏捷的做法来运作,保证开发过程在Scrum框架下按计划进行;

• 维护和提高团队士气和氛围,保证各个角色及职责的良好协作;

• 协调解决团队开发中的障碍;

• 做为团队和外部的接口,屏蔽外界对团队成员的干扰。


对于任职SM,我们希望你具备以下特征:

• 对敏捷感兴趣,能够主动进行敏捷推广,有意愿在敏捷领域深入发展;

• 主动性强,积极承担相应职责,并努力做到最好,不等不靠;

• 沟通影响力强,敢于发表个人意见和提问,能够有效影响他人观点;

• 执行力强,能够推动事情落地,并及时解决问题。


Scrum Master需要保持警惕的几件事


• 在Scrum的推行过程中,Scrum Master是团队的保护者,也是团队严格、认真遵循Scrum流程、实践和原则进行开发的教练。

• 欣然面对需求变化,即使在开发后期也一样。

• 遗留的用户故事

有时候,在一个迭代结束时,某个用户故事只完成了一部分,这样的用户故事被称为“遗留故事”。这是前次迭代没有完成的工作,通常会被自动添加到下一个迭代中,继续开发。但千万别这么做。

• 我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

对客户来说,在上一次迭代进行中,Product Backlog中的最有价值需求可能会发生变化。在上一次迭代中被认为是最有价值、优先级高的需求,随着外部环境的变化,可能会出现变化而降低了价值和优先级。如果我们自动将这些未完成的工作放入下一次迭代,有可能我们所做的工作并不是最有价值、优先级高的需求。

Scrum中,Product Owner的责任之一是维护Product Backlog,确保Product Backlog中的用户故事,都是经过了严格、认真的评估,是已经按照对客户的价值高低而拍好了顺序和优先级的。

所以,对于前次迭代没有完成的故事,Scrum Master要鼓励团队对未完成的用户故事进行分析,从中找出没有完成的原因,并在回顾会议中进行分析,拟定改进措施。同时,要从中学会如何在单次迭代中完整地完成用户故事,而不是只完成一部分。

Scrum Master要确保这些用户故事被重新放入Product Backlog,和Product Owner一道,对这些用户故事重新进行价值评估并排序。这样,下一次迭代规划时,团队拿到的就是一份完整的、经过了价值评估的、排好了顺序和优先级的Product Backlog。因而,下次迭代选中的工作,也都是对用户最有价值的需求。

当用户故事只是部分完成了但其优先级仍然是最高的,可以基于剩余的工作,对用户故事重新估算。基于团队的“速度”来决定团队在单次迭代中到底能完成多少工作,而不是只完成一部分。

• 迭代期间出现变化

通常情况下,迭代期间出现的变化与“范围蔓延”类似,因而处理措施也基本相同。Scrum Master务必要竭尽所能地与Product Owner 就迭代期间如何完成用户故事达成一致,确保团队不受外界干扰。

项目进行期间,务必要避免出现大规模、批量的需求变更。出现这样的变更,肯定会影响整个迭代进程。那最好的处理措施可能就是,立刻停止当前的迭代,重新审视、梳理Product Backlog。该增加新故事就增加,该删除无效故事的就删除。等整个Product Backlog重新梳理完成后,重新开始迭代开发。

Scrum Master一定要确保,团队当前手头的工作,对客户来说,是最有价值、优先级最高的。

• 软件缺陷

发现软件缺陷(Defect、Bug)是不可避免的。

当在在线系统中发现缺陷时,要立刻停掉手头的工作,优先修复软件缺陷。直到发现的缺陷修复了之后,再继续之前的工作,或者开始新的工作。

当修复了缺陷之后,还有做两件事情:

其一,进行一次根本原因分析,以确定这些缺陷是如何从最初的工作中遗漏出来的。这种缺陷在PMI-ACP中被称之为遗漏缺陷,又称逃逸缺陷。

其二,对当初的工作疏忽或不足进行改进,以弥补工作中的漏洞,避免同样或类似的缺陷再次出现。

敏捷团队并不以延长工作时间而获得更多产出,我们时刻聚焦于软件质量,以减少不必要的重复、返工的数量而提高生产率。但发现软件缺陷时,我们要立刻修复缺陷。如果某个用户故事还有很多已知的缺陷没有修复,那最好不要把这样的用户故事算作完成。如果团队低估了完成工作所需要的时间,Scrum Master要确保在迭代回顾的时候,团队对此进行讨论,并切实采取措施避免同样或类似的事情再次发生。

• 迭代气味

同很多事物一样,但出现不期望的事情时,一定有很多这样或那样的征兆。我称这些异样的征兆为迭代气味,或者更直观地,迭代臭味。这些现象可以通过观察团队的每日站会(我称之为每天碰头会)而清晰地识别出来。

• 有团队成员缺席会议。每日站会是团队的会议,每个人都应该出席。

• 重复任务。当每日站会上,uimaker,问那三个经典问题时,如果某个人每天的答案都是一样的话,那一定有问题,Scrum Master需要对此做一番调查。如果一名团队成员在某个任务上被block了,这个团队成员应该尽快寻求帮助。其他团队成员应该尽快帮助他解决问题。敏捷开发中,团队是一体的,是一损俱损、一荣俱荣的。

• 没有提出问题。如果每日站会上,团队没有提出什么障碍、问题,这时Scrum Master也要特别注意,尤其是当团队的燃尽显示毫无进展时。

• 每次提出的问题都一样。与上述类似,如果一天又一天,团队提出的问题都一样时,Scrum Master就需要特别留心了。

• 领导安排任务。敏捷团队是自组织的团队。千万不要让领导或项目经理为团队成员安排任务,哪怕只有一次。

• 领导管理团队。与上面类似,团队需要领导来管理时,Scrum Master就一定要出面干预了。敏捷团队应该管理他们自己。

• 工作角色过于明确、行动起来不像个团队。如果某个团队成员提出了一个问题,而其他成员觉得这不是自己或者团队的问题。Scrum Master这时候要进行干预。敏捷团队是一个完整的集体,集体、共同为完成交付目标而责任均担。


总结


我们已经讨论了敏捷团队经常出现的几种现象,Scrum Master需要对这些现象格外留心,如果真的出现,要及时采取措施。

• 范围蔓延

• 遗留故事

• 迭代期间的项目变化

• 软件缺陷

• 迭代臭味


原文出处可参见:


03、开发团队 


团队的职责:


• 一般由3-9个人组成的多样化跨职能团队,每个人都参与产品的设计、构建和测试

• 进行自我组织,确定采用哪种最佳方式来实现目标,共同决定如何规划、管理、执行和沟通工作

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

• 团队成员构成在sprint内不允许变化。

• 迭代规划

• 参加Sprint计划会,与ProductOwner共同确定迭代目标

• 将产品特性分解为一系列经过估算的任务,为达成迭代目标制定实施计划

• 每日检视和调整

• 参加每日站会,共同检视迭代目标的进展情况,

•根据当天工作情况调整计划

• 检视和调整产品与过程

•参加Sprint评审会,向PO和干系人演示当前迭代完成的产品成果,用来指导下一步的计划

•参加Sprint回顾会,检视和调整自己的Scrum过程

 收藏