Comments on: 天天Deadline http://www.robinlu.com/blog/archives/46 Robin Lu's weblog Thu, 02 Jun 2011 06:41:00 +0000 hourly 1 http://wordpress.org/?v=3.1 By: 枯藤老树 http://www.robinlu.com/blog/archives/46/comment-page-1#comment-23365 枯藤老树 Mon, 30 Jul 2007 15:05:36 +0000 http://www.robinlu.com/blog/archives/46#comment-23365 You may be agile, but you are still dog... 呵呵 You may be agile, but you are still dog…

呵呵

]]> By: 石锅拌饭 » You may be agile, but you are still dog http://www.robinlu.com/blog/archives/46/comment-page-1#comment-753 石锅拌饭 » You may be agile, but you are still dog Sun, 04 Jun 2006 11:46:35 +0000 http://www.robinlu.com/blog/archives/46#comment-753 [...] 五一放假结束后的第一周，在一位经验丰富的美国同事带领下进行了一周的敏捷开发实践。在此之前的半年时间里也试过scrum，并且体会到了一些好处，但那一周不仅让我们体会到了好处，可以看到了敏捷开发的力量。很多书本上早读过的观点和方法在他的帮助下确确实实为我们解决了实际问题，很让人兴奋。 此后将近一个月的时间里，我们尝试延续第一周的方法，必须承认我们还不是实施敏捷开发的专家，但还是取得了以前无法想象的成果。下面是一些体会： 1。短而递进的开发周期。我在以前也提过，现在能比以前更好的采用分而治之的方法。对于一个需求，如果需要十二天来完成，那么两天我们能完成到一个什么程度，或者是一个简化的需求，或者是这个需求的一部分，只要实现的完成度可以拿出来衡量，我们就制定一个两天的计划，两天后验收，然后一步一步做下去而不是“这是需求，十二天后见！”。 2。更准确的估计工作量。估计工作量对我来说一直是一个难题。当这次我又对一个work item给出不很确定的估计时，我被反问“哪些不确定因素造成了这些不确定地工作量”，我回答那里那里可能有潜在的问题可能会导致工作量的增加，“那么如果目前不去考虑这些潜在的问题，你对工作量的估计是多少？”，我的答案马上变的确定了。对于不确定的问题，我们只需要把它记下来，在问题浮现或者变得确定后再解决，而不是把它变成包袱背在身上。能绕过这个槛是我这次最大的收获。 3。分清什么是需求，什么是实现。工程师在讨论问题的时候很容易陷入细节，以至于忘记了事情的根源，即需求。我不止一次的被提醒“你现在讨论的是需求还是具体实现”，在回答了这个问题后，很多诸如“做什么”“怎么做”的问题自然就得到了答案。 4。unit test。没有UT就不是敏捷开发，不光是为了测试，有时候只有UT才能确定你工作是否完成，才能使短而递进的开发成为可能。在这一点上我还欠缺不少。 教训也是有的，最大的教训就是我们把计划定得太激进以至于经过这三个星期我们越来越不敏捷了。40小时每周是敏捷开发的核心，此话一点不假。 最后是同事发给我们的一副图片，最真实地再现了我们的工作： Tags:agile, pm [...] [...] 五一放假结束后的第一周，在一位经验丰富的美国同事带领下进行了一周的敏捷开发实践。在此之前的半年时间里也试过scrum，并且体会到了一些好处，但那一周不仅让我们体会到了好处，可以看到了敏捷开发的力量。很多书本上早读过的观点和方法在他的帮助下确确实实为我们解决了实际问题，很让人兴奋。 此后将近一个月的时间里，我们尝试延续第一周的方法，必须承认我们还不是实施敏捷开发的专家，但还是取得了以前无法想象的成果。下面是一些体会： 1。短而递进的开发周期。我在以前也提过，现在能比以前更好的采用分而治之的方法。对于一个需求，如果需要十二天来完成，那么两天我们能完成到一个什么程度，或者是一个简化的需求，或者是这个需求的一部分，只要实现的完成度可以拿出来衡量，我们就制定一个两天的计划，两天后验收，然后一步一步做下去而不是“这是需求，十二天后见！”。 2。更准确的估计工作量。估计工作量对我来说一直是一个难题。当这次我又对一个work item给出不很确定的估计时，我被反问“哪些不确定因素造成了这些不确定地工作量”，我回答那里那里可能有潜在的问题可能会导致工作量的增加，“那么如果目前不去考虑这些潜在的问题，你对工作量的估计是多少？”，我的答案马上变的确定了。对于不确定的问题，我们只需要把它记下来，在问题浮现或者变得确定后再解决，而不是把它变成包袱背在身上。能绕过这个槛是我这次最大的收获。 3。分清什么是需求，什么是实现。工程师在讨论问题的时候很容易陷入细节，以至于忘记了事情的根源，即需求。我不止一次的被提醒“你现在讨论的是需求还是具体实现”，在回答了这个问题后，很多诸如“做什么”“怎么做”的问题自然就得到了答案。 4。unit test。没有UT就不是敏捷开发，不光是为了测试，有时候只有UT才能确定你工作是否完成，才能使短而递进的开发成为可能。在这一点上我还欠缺不少。 教训也是有的，最大的教训就是我们把计划定得太激进以至于经过这三个星期我们越来越不敏捷了。40小时每周是敏捷开发的核心，此话一点不假。 最后是同事发给我们的一副图片，最真实地再现了我们的工作： Tags:agile, pm [...]

]]>