大脑学习规则
大脑总是渴求新奇的事物, 搜索和等待不平常的事情出现.
1)理解越多, 需要记忆的越少 2)多做练习和笔记 3)阅读问题,解答问题 4)睡前阅读,消化处理 5)多喝水补充水分 6)讨论和谈论,解释给他人 7)注意大脑运转效率 8)感受事物,融入情景 9)Coding exercise
Codes: http://www.headfirstlabs.com/books/hfsd/
---大脑学习规则 End---
Section1 Software Development
让客户满意 花多少钱, 花多长时间
Wrong (X)BigBang -> going dark
Correct 不确定用户想要什么, 问客户(即使知道也需要确认)
常常在客户大脑中并没有正确答案, 需要和客户沟通,确认细节, 将可以实现的实施方式表达给客户, 让客户决定, 需要让客户融入进开发过程,不能猜测
Keys >What is needed(requirement) >On Time(schedule) >On Budget(consuming control)
Iteration/Sprint(about 20d) Usually check with customs, demo, discuss about the draft ideas.
Adjust the functions according to custom's new thoughts.
Keep updating in the process of development wuth clients.
Show functions to the client Implement the part of the software, do presentation and demo to client, listen to the opinion
What to be done Each Iteration is a tini projects, finish some tasks. Each Iteration need RDCT: requirement, design, coding, testing
After each Iteration, the product is getting bigger and closer to the prefect. Set priority for each tasks and set timeline for them. Do the estimation for each task
Make the related tasks(have dependency) in same iteration
New tasks Custom added new idea during the develop process. Estimation and rearrange the priority for the tasks, put the low priority tasks in the end of the iterations
Caculate the time, remove the un-necessary tasks/functions, discussing by custom
>To deliver the product in time and match the requirement. "shoehorn" new tasks come late in the end of the iterations, you have to explain to custom: plan, resource,
why you can't make it in time, you need more iterations or resources(devs)
Summary
>开发技术 开发循环帮助你保持在正确轨道, 需求变化时. 重新规划和均衡开发循环. 每个开发循环都产生有效的软件, 从客户那里收集反馈意见.
>开发原则 交付客户需要的软件, 按时交付, 符合预算.
>本章要点 每个开发循环获得的客户意见, 保证软件与客户需求一致的最好手段. 开发循环是完整项目的缩影.
软件需要开发循环经常从客户那得到意见. 预订时间和预算内交付软件. 有些功能正常工作的软件比功能很多但不能正常使用的软件好. 好的开发人员开发软件, 伟大的开发人员交付软件.
Process, Customer, Ship, Released, Deadline, Overbudget, On time, Drawing board
---Section1 End---
Section 2 Collect Requirement
使用情节 User Stories 头脑风暴 Brain Storming 估计游戏 Estimation Game
Brain Storming >索引卡 每一张卡片捕捉一个软件系统需要提供的事情, 单一的
>Meeting BlueSky 每个人平等的发表意见, 尝试考虑额外需求
如果BrainStroming当时没有效果, 可以分组进行(开发和客户...), 再集中起来, 把IDEA写上白板(散会休息思考再开第二次)
理解客户的方式 >角色扮演 Role Playing 演示软件, 扮演软件, 客户提出要求, 在需求卡片上记录软件需要做的事情
>观察 Observation 多个观察者观察客户的工作流程以及方式
User Stories(US) 站在客户的角度, 你和客户都能理解
>YES -描述软件为客户做的一件事, 从用户的观点角度 -用客户能理解的语言撰写 -源自客户 -简短
>NOT -长篇大论 -使用客户不熟悉的技术术语 -提及特别的技术
区分UserStory和DesignDecision, 询问, 提问, 修改, 保证所有的事情都讨论清晰
>标题栏 方便寻找参考 >如果有技术性的决策需要增加到US, 写在另外一组需求卡片上, 用标题交叉参考
>将需求提炼成US >项目过程中继续提炼和捕捉新的需求, 加入Iteration, 对每个US增加时间估计(设计, 编码, 测试, 交付), 然后总的时间估计
>获得可信的时间估计: 排除假设
扑克牌游戏 估计值是整个US的, 不是其中的一部分
>把US放在桌子中间 >每个人发13张牌, 每张牌上有一个估计值 0 1/2 1 2 3 5 8 13 20 40 100 ? TeaBreak
>每个人选择估计值, 把牌反过来凡在桌上 >一起吧牌反过来 >询问差距大的, 弄清假设, 在相似分布区间找到合理估计值, 讨论及统一理解, 在卡片反面记录
验证假设 不要轻信假设, 弄清那些是不知道的, 保留假设, 可以延迟低优先级的US, 直到假设得以澄清
在Estimation期间的目标是通过客户澄清假设, 排除尽可能多的假设, 任何残存下来的假设都是风险
珍惜客户的时间 组织好时间, 有技巧的提问 排除假设的会议 Assumption-busting session. 试着一次收集好所有的假设, 集中全面的澄清
>可以就新的澄清事项进行新一轮的扑克游戏
没有愚蠢的问题 40, 表明这个US包含许多工作. 100, 有误解或者错误, 可以把US分解成更小的, 方便估计的US. ？, 没有信心, 误解, 不确定
稀奇古怪的数字, 询问沟通, 是否有遗漏的信息. 私下沟通, 询问理由. 估计值应该是整个团队统一的, 整个团队有信心说满足团队中任何一个人去开发所需要的时间
Estiamtion包括文档 测试报告 Packaging 部署Deployment
>不要对假设再做假设, 一切都应该讨论清晰
>US越长, 估计越容易不准确 当US超过15天, 1) 把US分解为多个更容易估计的US, find out 'AND' of the US. 2) 与客户交流沟通, 澄清一些假设, 减小估计值
目标-收敛 得到每个US的估计值, 对估计值的信心, 排除假设, 把估计值的分布收敛在一个点
1) 与客户交流, 排除假设, 误解 2) 进行计划扑克牌游戏, 处理每个US, 挖出任何的隐含假设
3) 利用扑克牌游戏的结果, 了解团队成员是否理解US, 哪些地方需要澄清 4) 达成一致(估计值都接近, 可以相信的估计值)
>对假设采取 zero-tolerance attitude, 对于暂时无法确定的假设, 标注并且跟踪这些风险
估计值是对客户的承诺 说明团队需要多久来交付软件 >客户应该只是接收到你的问题, 看到US, 估计值应该由团队给出
1) 捕捉基本想法 2) 共筑远景的头脑风暴 3) 构建US 4) 在澄清中发现漏洞 5) 精炼US 6) 扑克游戏 7) 从客户反馈的到丢失的信息, 分解大的US [->4)] 8) 收敛估计值
估计项目 每个US增加估计值(开发功能的时间), 相加得到总估计值(交付软件的时间)
Summary
>开发技术 共筑远景, 观察, 角色扮演, US, 扑克游戏, 估计值
>开发原则 帮助客户确定他们想要什么, 需求总是面向客户, 与客户一起反复发掘提炼需求
>本章要点 与客户一起讨论可以是客户考虑更周全. US应该从客户观点出发, 一个循环完成, 语句简短, <3句, 是可估计的, 应当小于15天/人. 与客户多交流需求, 使客户参与其中
BlueSky, Assumptions, Technical, PlanningPoker, Observation, Convergence, QuestionMark, Spread, RolePlay, Cofident, Consensus
---Section2 End---
Section 3 Project Planning
tip: 人/天 公历日
与客户一起确定优先级 等级由客户决定, 提出专业建议帮助
Mailstone 1.0 向客户发布的第一个主要版本
在系统的功能和客户的渴望之间取得平衡 推迟一些功能到2.0, 3.0. 1.0功能满足客户最重要的需求. 暂时不担心时间, figure out what is the most important firstly
将US按照优先级排列, 由客户选择需要在1.0完成, 如果功能多过开发时间安排, 重新排列优先级.
1) 缩减更多的功能, 去掉没有绝对必要的US 2) 尽早交付M1.0 3) 关注基本功能
Mailstone 发布给客户 Version 功能更新
>经过计算, 无法在预订时间内交付客户需求的全部功能, 可能要放弃这个项目, 可以增加开发人员, 这样会加大成本
增加开发人员, 新增人员需要理解软件,需求,技术, 安装开发环境, 需要时间融入, 所以并不是100%的立即生产力.
并非开发越多越好, 人数越多, 所需要的沟通通道Communication Path消耗越大, 可以使用60%的计算量, 其中包括了沟通学习会议等消耗
>扮演客户 给M1.0中的US分配优先级 10 20 ...50(偶尔可以有例如25), 其中没有可舍弃的US, 优先级代表开发次序
和客户讨论优先级, 解释功能之间的关联性, 由客户决定级别
>每个Iteration结束, Demo and get feedback from customer, 保证软件连续不断的构建并且可运行Continuous Build
Iteration保持简短 循环越短, 越有机会处理变更和细节问题
Iteration保持均衡 处理需求变更, 增加功能, 发现漏洞, 开发真实情况
将计划内的事情考虑进Iteration: Document, Vacation, Software/Binary/3rdParty Upgrating
Velocity 时间效率值 0.6 可以在Iteration迭代过程中修改
SWD × Workday × veloctiy = Real Workload (per Iteration/Sprint) × number = Total time
将多出预算时间, 优先级低的US放入Backlog, 和客户沟通, 哪些会推迟完成
Solution 1) 为Milestone 1.0增加一个循环, 完成Backlog内的US 2) 时间上的推迟, 其他US需要在下一个Milestone发布 3) 将时间计算过程解释给客户, 推迟某些US的理由, 交付产品的时间限制
不要在计划内挤时间, 如果时间内剩余, 可以选择简单的US插入Milestone
>对许诺需要信心, 谨慎承诺, 成功交付, 不可过度承诺导致失败
SW Dashboard 白板: US - In progress - Done, Burndown map: x-day, y-workload(h)
个人生活很重要: 快乐的团队有生产力, 避免加班
疲劳影响生产力: SWD每天只有三小时最有生产力
>要点 客户按照需求排US优先级, Milestone 1.0尽早交付, 开发循环尽量短, 时间不够时请客户再次排优先级, 时间效率值, 向客户解释时间需求, 设定开发计划表
Summary
>开发技术 短循环, 时间效率, 使用白板计划和监控项目, 选择Milestone 1.0的US, 安排开发循环的US, 征求客户意见
>开发原则 短循环可管理, 由客户决定哪些US在循环和Milestone中完成, 谨慎承诺, 成功交付, 诚信于客户
>本章要点 客户决定优先级, 短循环在一个月内, 软件的可构建可运行, 计算和调整时间效率, 规划切实可行的Milestone 1.0.
Feedback, Suprised Event, Velocity, Priority/Prioritizing, Burndown, Honest, Baseline, Runnable
---Section3 End---