1.记录问题(bug,缺陷)的解决方式:
问题发生日期,
问题简述,
解决方案详细描述,
引用文章或网址,以提供更多细节或相关信息。
任何代码片段、设置或对话框的截屏,只要他们是解决方案的一部分,或者可以
帮助更深入地理解相关细节。
2.异常信息的展示:在界面中显示清晰的错误说明信息。该错误信息不只是简单
的文本,还包括了一个超链接。用户、开发人员、测试人员都可以由此链接得到
更多信息。如:Couldn't login[details...],点击链接看到:Error:Eorror
validating password.
3.敏捷协作:
scrum meeting: 昨天有什么收获?今天计划要做哪些工作?面临着哪些障碍?
只能给予每个参与者很少的时间发言(大约两分钟)。如果要详细讨论某些问题
,可以在立会结束之后,再召集相关人员(在会议中说“我需要跟Tom和Kate讨论
下数据库”是没有问题的,但是不要深入讨论细节)。
通常,立会都是在每个工作日的早些时候,且大家都在上班时举行。但是不要把
它安排为上班后的第一件事。要让大家有机会从刚才混乱的交通情况中恢复状态
,喝点咖啡,删除一些垃圾邮件什么的。要保证会议结束后有足够的时间,让大
家在午餐之间做不少工作。一般来说,在大家到公司之后的半个小时到一个小时
之内举行,是个不错的选择。
4.架构师要编程:优秀的设计从积极的程序员那里开始演化,积极的编程可以带来
深入的理解。不要使用不愿意编程的架构师--不知道系统的真实情况,是无法展
开设计的。
架构、设计、编码和测试,这些工作给人地感觉就像是同一个活动--开发的不同
方面,感觉他们彼此之间应该是不可分割的。
要强调代码的集体所有制,让开发人员轮换完成系统不同领域中不同模块的不同
任务。