《软件开发践行录——ThoughtWorks中国区文集》一一2.1 项目背景

2.1 项目背景

ABC公司是一家知名的国际性会计师事务所,业务规模庞大,分支机构遍布全球170多个国家。

ThoughtWorks受邀对公司“全球派遣服务(International Assignment Service)”业务部门提供IT解决方案以及软件系统的开发服务。该系统包括收集公司客户的全球派遣雇员的报税数据,同时管理ABC公司税务咨询师对这些数据进行审核、汇算和出具报告的业务流程;逐步替换它目前远远不能满足业务和性能需求的遗留系统。

该系统主要有两类用户,一类是ABC公司客户方被派往不同国家工作的雇员(以下简称Mary),这些雇员使用该系统填入报税需要的数据;另一类用户是ABC公司的税务咨询师(以下简称Kim),负责审核、处理Mary提交的数据。

时间: 2024-08-06 22:55:59

《软件开发践行录——ThoughtWorks中国区文集》一一2.1 项目背景的相关文章

《软件开发践行录——ThoughtWorks中国区文集》一一第一章看板任务管理(黄亮)

第一章看板任务管理(黄亮) 软件开发践行录--ThoughtWorks中国区文集作为一个开发团队的管理者,例如当你是一个团队的项目经理的时候,任务的完成情况通常是你最关心的内容之一,比如说分配的任务是否能够按时间完成,整个项目的进度是否尚在计划之中,团队内的人是不是都在高效地工作,大家有没有什么困难,等等.在软件开发团队中,任务的分配.跟踪和管理通常是这个团队管理者的一个重要的工作内容.

《软件开发践行录——ThoughtWorks中国区文集》一一第二章 实战:持续交付中的业务分析 夏洁

第二章 实战:持续交付中的业务分析 夏洁 软件开发践行录--ThoughtWorks中国区文集在需要频繁交付.不断收集用户反馈.拥抱变化.追求业务敏捷的项目中,软件的开发和交付是迭代式进行的.在这样的项目团队中,业务分析师(BA)通常需要在一个开发迭代开始之前完成该迭代开发任务的分析.但在特殊情况下,从收集客户需求到将功能细节传达给开发团队的周期会缩短到一至两天.BA可以用于思考和分析的时间远远少于可以预先做出所有设计的瀑布式项目. 那么在这样的敏捷项目中,BA如何能够适应这种交付模式.完成高质

《软件开发践行录——ThoughtWorks中国区文集》导读

前言 软件开发践行录--ThoughtWorks中国区文集关于本文集三年前因缘际会,我加入了ThoughtWorks中国公司.在这之前,参与线上和线下社区的我,已经认识了不少早期的TWer,而加入之后更是近水楼台,我跟他们在一个项目工作,听他们的分享,得以从更近距离学习和体会他们身上似乎与生俱来的价值观和对软件构建本身的独到认识.也是一直以"程序员中的编辑,编辑中的程序员"自诩的我,从一开头就认定,传播这群人的意识和经验对于我来说责无旁贷,而这样的贡献也权当是允许自己滥竽充数混迹其中的

《软件开发践行录——ThoughtWorks中国区文集》一一2.6 结语

2.6 结语 业务分析是困难的,特别是当我们面对未知领域的时候.如果只是简单地按照客户的具体需求进行软件开发,那么我们交付给客户的产品价值将非常有限.然而识别业务价值.帮助客户分析需求优先级.保障团队协作,将有效提升团队的软件设计能力,解决客户真正的业务问题,实现更大价值. 作为一名业务分析人员,当您在尝试以上实践时,可能会发现自己对客户业务的理解变得更加深刻.在与客户的沟通中,也能够更加容易地提出有价值的问题以及建议,从而提升客户对项目团队的信任,为成功交付项目打下良好基础.

《软件开发践行录——ThoughtWorks中国区文集》一一2.5 发挥团队其他成员在业务分析中的作用

2.5 发挥团队其他成员在业务分析中的作用 在频繁交付的项目中,如果BA独自承担业务分析工作,难免会出现疏漏.ThoughtWorks曾与ABC公司的IT部门合作完成其业务系统的一些集成工作.在合作过程中发现,ABC公司IT部门的开发人员在业务分析中参与度很低,由此造成了如下问题. (1)BA需要写大量需求文档,所以从需求分析到软件交付的周期较长. (2)设计缺陷的发现滞后. (3)在需要频繁交付的情况下,解决方案质量较差,方案优化能力较弱. 而ThoughtWorks的开发人员在业务分析中的参

《软件开发践行录——ThoughtWorks中国区文集》一一2.2 BA在该项目中面临的主要挑战

2.2 BA在该项目中面临的主要挑战 该项目为分布式开发,ABC公司的决策方在美国,而ThoughtWorks的开发团队在中国,沟通反馈周期有时较长. 由于ABC公司对用户体验的重视,开发团队需要频繁交付软件,以便收集用户反馈并及时调整解决方案和后续开发计划.这大大缩短了从收集需求.开始分析到进入开发的周期,增加了分析中出现缺陷的风险. 当开发过程中发现问题时,开发团队无法马上与客户取得沟通,开发进度可能会受到影响.

《软件开发践行录——ThoughtWorks中国区文集》一一2.3 识别业务价值

2.3 识别业务价值 业务分析的重要性在于首先做正确的事情.理解客户的业务,关注需求背后的价值可以帮助项目团队在软件的设计方面做出正确的选择. 而我们面临的困难是,客户提出的需求往往都是直接的软件功能,而不是需要解决的业务问题.如果BA只专注于针对客户需要的功能进行系统分析,就丧失了帮助客户优化解决方案以及改进业务流程的机会. 如何寻找业务价值?以敏捷开发方法中的用户故事为例,找出客户要解决的业务问题的一个简单办法是,用以下方式概括每个用户故事的内容. As-(角色),I want to-(完成

《软件开发践行录——ThoughtWorks中国区文集》一一1.2可视化看板任务管理

1.2可视化看板任务管理 看板源于精益生产实践,敏捷将其背后的可视化管理理念借鉴过来,经过一番改造,形成了有自己独特风格的可视化管理工具.曾有人总结过scrum和kanban的使用[1],而很多时候,我们也将它叫作迭代状态墙. 我们先来看看怎样用这个状态墙来管理迭代任务.说起来其实是一个很简单的东西. 通常一个迭代的状态墙反映了某一个迭代的计划和任务进展情况.状态墙按照一个迭代内团队的典型开发活动分成几栏,例如"待开发"."开发中"."待测试".

《软件开发践行录——ThoughtWorks中国区文集》一一1.11.从问题谈起

1.11.从问题谈起 我曾经碰到过一个项目经理,她管理一个团队开发一个Web应用,团队里开发人员大概10个,测试人员3个,业务分析师1个人.对于任务的管理她是这样做的.通常,她会将需求分析人员分析得到的需求给每个人分一些.然后每个人在领到任务之后会给她承诺一个大致的时间点.整个项目大致的交付计划用一个Excel表管理,根据客户要求的交付时间点,同时考虑到一些需求之间的集成测试关系,她定出了每个需求的大致交付时间点.只要每个开发人员承诺的时间点和期望的相差不大,她都可以接受,这样每个开发人员就知道