会编程的小逸

摘要： 第9章 方法 结构化编程以防御式下蹲的姿势提出建议，尽力让可能犯错的程序员自避气短。 缺陷总是存在。祖尔测试的12个问题：1） 你们使用源代码控制吗？2）你们一步就能完成构建吗？3）你们做每日构建吗？4）你们有缺陷数据库吗？5）你们会在写新代码之前修复缺陷吗？6）你们有与当前工作吻合的进度安排吗... 阅读全文

摘要： 第5章 管束奇客和狗 管理的任务就是让人能协同工作，益其长处、弱其短处。数字只是管理的一个起点，并非终点。 用代码行数计算软件生产力不太可靠。 非正式机制总是存在，而且如果没真正理解就改变他是很危险的，要避免扰乱原来运行畅通而且你无法以同等代价替换的系统。第6章 搞掂设计方案 别做大项目。从... 阅读全文

摘要： 第0章 软件时间看到第0章，似乎不符合套路，却又是程序员们都能意会的。第1章 死定了 对软件延误的问题很普遍。布鲁克斯法则暗示最理想的开发团队模式是一个人——无需停下工作与同事沟通的单个开发者。第2章Agenda之魂 每个项目都有不同之处。第3章 原型与Paython 做软件的人喜欢讨论垒砖头... 阅读全文

摘要： 第12章：故事是什么用户故事有别于IEEE 830软件需求规格、用例和家傲虎设计场景。考虑用户的目标比列出方案的特性更重要。用户故事与用例场景类似。他们的完整性和寿命不同。他们以不同的目的编写。第13章：用户故事的优势用户故事促使我们重视口头交流，这一转变提供了迅速的反馈周期。用户故事的典例范围比用... 阅读全文

摘要： 第8章 估算用户故事使用故事点 我们用“速率”（velocity）来代表一个团队在一轮迭代中完成（或期望完成）的故事点数。因此，务必保证每次迭代的故事点的度量是一致的。 如果用结对编程呢？ 团队用不用结对编程，对故事点估算并没有影响。团队可以采用理想结对日或理想个人日来估算故事点，区别会表现在速率值... 阅读全文

摘要： 第一章：概览1.故事卡包含对用户或者客户价值的功能的简短描述，是故事的课件部分，但客户团队和开发人员关于故事的对话更重要，有任务团队编写，因为他们最了解如何表达需要实现的需求。2.按照故事对客户的价值来安排故事的优先级顺序。3.速率是开发人员可以在一轮迭代中完成的工作量。4.放入一轮迭代的故事估计综... 阅读全文

摘要： 第五篇：问题是从哪儿来的？1.问题的根源常常在自己的身上。第六篇：我们真的想解决问题吗？1.我们永远没有足够的时间来考虑我们是否真的需要他，但是我们总有足够的时间来位置后悔。2.如果沉浸在问题当中，解决者就会冒着忽略其他重要因素的风险，在你着迷于解决问题时，可能会忘记考虑你是否应该从道德上支持一个解... 阅读全文

摘要： 第三篇：什么是真正的问题1.每种解决办法都会带来新的问题。2.问题最难以处理的部分恰恰是去意识到他们的存在。3.如果你对问题的理解中，想不出至少3个可能出错的东西，那么你并没有真正的理解这个问题。4.不要轻易下结论，但也不要忽略你对第一印象。5.每一种新的观点都会带来新的不对称。6.注意你表述的意思... 阅读全文

摘要： 《你的灯亮着吗？》共分为六个主题，每个主题都有一个问题，我今天就先说说前两个问题。第一篇：问题是什么？ 这一篇讲了一个信差的故事。在信差解决了一个问题之后，就又出现了一个新的问题，当彼得满意的以为解决了一个问题之后就会出现一个新的问题，一直到真正来修电梯的人来解决这个“电梯慢”的问题，却最终阴... 阅读全文

摘要： 一、典型用户名字刘洪阳性别、年龄男，21岁收入0知识层次和能力大学时，软件工程专业，可编程，玩游戏，玩的基本是网络竞技游戏生活/工作情况未婚动机，目的，困难有时很无聊，找个小游戏找点，趣味用户偏好大型网络竞技游戏，网页小游戏用户比例？用户场景上小游戏网页浏览小游戏典型描述这个会更有趣吗？二、场景描述... 阅读全文