-
I am Dave Jing Tian, an Assistant Professor in the Department of Computer Science at Purdue University working on system security. My research involves embedded systems, operating systems, trusted and confidential computing, and hardware security and trust. All opinions are my own.
Shoot me:
root@davejingtian.org Categories
Resource
Tags
- ABNF
- agile
- AI/ML
- Alcatel-Lucent
- android
- arp
- asn1c
- assembly
- bash
- ber
- bison
- BNF
- build
- C
- CentOS
- CIS122
- Coverity
- crypto
- csv
- cuda
- DCA
- ddclient
- debugfs
- DH
- Diffie-Hellman
- drd
- drig
- elixir
- fedora
- fedup
- flex
- fsck
- gcc
- gdb
- GFW
- git
- github
- gnome
- gprof
- gpu
- guitar
- gumstix
- helgrind
- intel
- itevad
- Java
- jmgsim
- JVM
- kenai
- kernel
- kill
- ksh
- kvm
- ld
- Linux
- list
- netbeans
- netlink
- nvidia
- OS
- overo
- Python
- relay
- security
- selinux
- sgx
- socket
- ssh
- Ubuntu
- UO
- USB
- valgrind
- x86
- x86_64
- yocto
Blog Stats
- 236,456 hits
-
All blogs on this website are licensed under a Creative Commons Attribution 4.0 International License.
Tag Archives: agile
happy chinese new year – do the right thing – some thoughts on software
(The pic above was taken on Feb 3, 2011 – Chinese New Year, Spring Festival – my Jackson and Squier) Happy Chinese New Year – the year of rabbit 过年好, my dear friends:) though it seems a little late…I have … Continue reading
Essential Essence of Agile/Scrum
近期参加了公司组织的风险管理培训,结合Agile/Scrum,总结了一下自己对Why Agile/Scrum的理解,以下仅为个人见解,如有雷同,只能说英雄所见略同:) Essential Essence of Agile by Dave Tian 1. 挖掘客户的need而不是want - 通过与PO的及时、按时沟通,以最低风险达到客户最大满意度和最大收益 2. 软件开发从功能层面转向业务层面 - 通过捆绑PO、dev、tester,使团队整体感知客户的业务,高屋建瓴领,而不是仅仅专注于feature层面 3. 应对客户需求的多变 - 通过PO和短期迭代,随时交付可用产品(demo),客户可随时根据自身情况作出需求调整 4. 应对现代软件管理的滞后与盲目预测 - 混沌告诉我们超过24小时的天气预报是扯淡,那么在软件项目开始前就做出的任何预测也将在短期内失效,通过Scrum每天的例会和短期迭代,把大计划分化成阶段计划,并可以根据backlog里feature的prio随时更新计划 5. 应对软件开发人员水平的参差不齐 - 通过Scrum的例会,随时总结个人项目中的问题并分享与团队,以期团队整体在项目中最大化技术提升和团队战斗力而不是重在个人 6. 应对软件测试的资源浪费和事倍功半 - 忘了谁说的这句话(大概意思),软件测试不是用来发现bug的。个人非常同意,dev应当是自己code的最好tester,于是在agile中,dev应当充分利用新的UT技术或者其他自动化测试技术来完成对自己code的测试;而tester将从功能测试的层面转向业务层面,而业务层面的测试又要求新技术TDD、BDD、ATDD的应用(如果以现在FT、ST、NLT的架构来看,那么dev将负责FT和ST,tester会直接专注于NLT-业务层面)
agile tour 2010 – Qingdao
Some personal feeling after agile tour 2010 – Qingdao, China. 今天有幸参加了agile tour 2010青岛站的会议(http://agiletourchina.agilewizard.org/qingdao/),很棒,无论是speaker的演讲主题还是下午的分会场,都能看出组委会的用心。如果明年有机会,我想我还会来参见的。我是一个agile或scrum的门外汉,更没有几十年的coding经验,以下只是个人对agile的一些思考或看法: 1. agile作为一种方法论,无疑是软件工程的一种回归,回归到人而不是软件开发过程本身。套用nokia的一句广告词:科技以人为本。个人非常同意这一点,软件的附加值应该在dev上体现,而不是靠市场来体现,虽然QQ已经用行动说明其实人并不重要,重要的是走别人的路,让别人无路可走……(这又是另一个话题。) 2. agile作为一种生活哲学,无疑是人生理性规划的一种回归,回归到原始单纯的驱动。我至今都记得大学时我们理学院院长曾经真诚的说的一句话:当你不知道干什么的时候,就学习。(也至今记得当时自己讽刺嘲笑的表情……) 即便是到现在,或者是由于处女座的因素,总是在试图完美的design自己的人生,等待完美的机遇,后果是突然发现自己快30了,依然一事无成。或许这是agile给我的最大提醒,套用Bill Li先生会上引用功夫熊猫里乌龟大师的一句话:Yesterday is history; tomorrow is mystery; today is a gift. 3. agile做为一种新的软件工程方法,对整个软件行业的影响将是异常深远。我能体味agile发起者的野心,一种试图在资本盈利和软件工程之间建立完美连接。至少听起来是这样,充分信任scrum team并赋予自管理的权利和免收外部干涉的环境,同时又能保证最低的风险的最高的盈利。我的问题很简单,如何改造现有的大型企业的管理架构模式(例如,经理可能比dev还要多)使之适应agile?或者换一个角度来说,agile对大企业来说更合适于小部门团体的改造或者小公司的改造。我始终觉得在有一种新的管理模式与agile能配合之前,对于大型企业,agile的问题太多,不实用 (当然这是管理者的问题,我只是一名普通民工)。 4. agile作为一种新的研发团队模式,无疑更是影响可怕,Eric在会中说到,至今没有agile tester宣言。a. tester还有必要吗?毫无疑问,tester永远都是需要的,只不过其智能与技术讲与目前完全脱离,有一点我赞同:testing不是来发现bug的(虽然作为一个dev我做不到这一点)。在agile下,bug的testing的实现者无疑最好是dev,只要有足够的时间buffer,我相信dev本人才能写出最好的针对其code的测试case,UTcode,tool,anyway。而此时的tester则更需要向业务层面进行转移,随之的新技术TDD,ATTD,BDD。b. 研发经理变成了PO(scrum)或者变成◎#¥%……※×,anyway。c. scrum master应该是独立于任何研发项目并专注于agile实践的指导者(从这里你能看出scrumAlliance的野心,有点大学四六级证的意思,另一个方面,创造了一个新的职业,开拓了职业转型与从业方向)。 5. … Continue reading