软件开发践行录——ThoughtWorks中国区文集 - (EPUB全文下载)

文件大小：0.36 mb。
文件格式：epub 格式。
书籍内容：

软件开发践行录——ThoughtWorks中国区文集
第一篇 过程改进
看板任务管理（黄亮）
实战：持续交付中的业务分析（夏洁）
建设DevOps能力，实现业务敏捷（熊节）
自我成长时考虑精益的方式（熊子川）
运用系统思考，走上改善之路（李剑）
分布式开发（李响）
精益创业和敏捷（施韵涛）
我和敏捷团队的五个约定（覃其慧）
第二篇 工程实践
运用四色建模法进行领域分析（徐昊）
对象已死？（徐昊）
企业系统集成点测试策略（熊节）
架构腐化之谜（陈金州）
Mock不是测试的银弹（胡凯）
GUI应用的若干问题和模式（李光磊）
软件开发地基（郑晔）
敏捷中的QA（林冰玉）
Android中的单元测试（张磊）
使用云和虚拟化技术实现持续交付（冯智超）
遗留系统的技术栈迁移（张逸）
案例分析：基于消息的分布式架构（张逸）
使用功能开关更好地实现持续部署（崔力强）
如何在敏捷开发中做好数据迁移（章昱恒）
响应式布局在邮件中的实现（魏广程）
迈向企业级移动之路（刘宇峰 曾学海）
Android敏捷开发指南（上）（王哲）
Android敏捷开发指南（下）（王哲）
以自动化测试撬动遗留系统（胡振波）
持续集成理论和实践的新进展（肖鹏）
第三篇 团队建设
建设全功能团队——实践篇（胡凯）
建设全功能团队（胡凯）
高杠杆敏捷团队中的团队建设实践（刘尧）
全功能团队——数据篇（吴少博）
第四篇 体验设计
从敏捷宣言理解敏捷交互设计（熊子川）
看完了
第一篇　过程改进
看板任务管理（黄亮）
作为一个开发团队的管理者，例如当你是一个团队的项目经理的时候，任务的完成情况通常是你最关心的内容之一，比如说分配的任务是否能够按时间完成，整个项目的进度是否尚在计划之中，团队内的人是不是都在高效地工作，大家有没有什么困难，等等。在软件开发团队中，任务的分配、跟踪和管理通常是这个团队管理者的一个重要的工作内容。
1．从问题谈起
我曾经碰到过一个项目经理，她管理一个团队开发一个Web应用，团队里开发人员大概10个，测试人员3个，业务分析师1个人。对于任务的管理她是这样做的。通常，她会将需求分析人员分析得到的需求给每个人分一些。然后每个人在领到任务之后会给她承诺一个大致的时间点。整个项目大致的交付计划用一个Excel表管理，根据客户要求的交付时间点，同时考虑到一些需求之间的集成测试关系，她定出了每个需求的大致交付时间点。只要每个开发人员承诺的时间点和期望的相差不大，她都可以接受，这样每个开发人员就知道自己应该在什么时间点交付什么东西。
一切本该很完美，但是不和谐的问题不断出现。最经常发生的事情就是大家在承诺的时间点到来的时候不能按时交付，每次她询问进度的时候，都会被告知还差一点就完成了。通常的说法是“底层部分已经做完了”或“还差页面部分就可以搞定了”，然而实际情况是又过了相当长的时间才真正完成。当然也有按时交付的需求，但是她发现也许是大家经常加班，已经开始疲倦了，有时候明明很简单的、可以提前完成的需求，大家还是到最后一刻才交给测试。
也有的开发人员拿到自己的那一批需求之后，会批量工作，把若干个类似需求的底层逻辑全部实现，然后再实现上层内容。她默认了这种做法，就像这位开发人员说的“这几个需求都差不多，只要底层做好了，基本上就都完成了”。虽然这部分工作早点和其他人一起集成测试会比较好，但是他这样做也只能推后集成测试的时间点了。还好她承诺给测试团队的交付时间点还在1个月之后，只要1个月之内能够完成这些需求就可以了。
项目执行过程中还有一些其他的问题，比如有的新人经常碰到问题，但是出了问题并不主动问其他人，而是在胡乱尝试中浪费了时间；还有个别开发人员非常激进，经常花时间去重构代码，追求完美的架构设计，进度很让人担忧。组内的开发人员还经常被其他项目的事情打扰，因为有几个人刚刚从之前一个项目中调过来，前一个项目的有些问题只有他们熟悉并有能力解决。她就不止一次发现有一个开发人员在修复其他项目的bug。
她会不定时地去询问每个开发人员的开发进度，当需求的计划交付时间点逼近的时候，这种检查会越来越频繁。开发人员感受到压力，有时候甚至需要加班来完成开发工作。尽管她花了很多精力去跟踪和检查每个需求的完成情况，还是有很多出乎意料的事情在不断发生。尽管她一直相信，只要开发人员能够完成任务，采用什么方式她都不干预，而具体的时间也是由他们自己分配的。但是她渐渐感觉到任务越来越不可控，计划通常无法按时完成，每天对大家的检查花费了大部分时间，然而却不能揭示出真正的问题。
运转良好的项目都差不多，而问题项目的问题各有各的不同。虽然每个团队的问题可能不完全相同，但是当我们审视这些项目的运作和管理方式的时候，不难发现一些诸如多任务并行等共性的问题，这些问题给软件项目带来了各种各样的浪费。当一个团队采用瀑布开发模式的时候，开发阶段全部结束之后测试人员才会介入，开展测试活动，在一个通常很漫长的开发阶段内，各种开发活动中的浪费、估计不准确以及成员自己的拖沓、被打扰、问题阻塞等，都被掩盖了。只要在最终时间点前能够全部开发完成，不管是前松后紧还是加班熬夜，都已经成了项目开发的常态。项目经理只能看到交付的最终时间点，问题不能及时地解决，而等到问题暴露的时候，可以使用的调整手段也非常有限。
这样的一种团队生存状态在外部环境要求短交付周期、需求允许经常变化的情况下显示出了极度的不适应。市场环境的变化驱动了软件需求的变化，这种变化催生了缩短交付周期的诉求，较短的交付周期使得人们不必去预期过于长远的需求，具备根据市场的变化快速地制定和调整软件需求的能力。而当交付模型由几个月的瀑布模型转变为数周甚至更短的迭代模型的时候，我们在前面谈到的团队中的各种浪费、低效、半成品堆积等问题，就会急剧地爆发出来。
熟悉敏捷方法的读者可能知道，敏捷方法包含一系列实践，来帮助团队实现短周期快速交付，更好地响应需求变化。比如说用户故事（User Story）方法将需求从用户价值的角度进行组织，避免将需求从功能模块角度划分。小粒度的用户故 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。