Your iteration went great, and you’re delivering working software on time. Time for the next iteration? No problem, right? Unfortunately, not right at all. Software development is all about change, and moving to your next iteration is no exception. In this chapter you’ll learn how to prepare for the nextiteration. You’ve got to rebuild your board and adjust your stories and expecations based on what the customer wants NOW, not a month ago.
What we can do for Next iteration?
When you come to the end of an iteration, you should have a buildable piece of software. But complete software is more than just code. It’s also...
- Completing your iteration’s work
- Passing all your tests
- Satisfying your customer
You need to plan for the next iteration :
Before diving into the next iteration, there are several things that all play a crucial part in getting ready. Here are the key things to pay attention to:
- Additional user stories
- Burn Down
- “Next” user stories
You need to revise your story and task estimates and your team’s velocity :
When originally planning Orion’s Orbits, you and your team came up with estimates for each of the user stories for Version 1.0, and then the tasks associated with each of those user stories. Now that it’s time to kick off another iteration, you have a lot more knowledge about how things will work. So it’s time to revisit those estimates for the remaining user stories and tasks.
Also, when you originally calculated how much work you could complete in the first iteration, you didn’t know how fast your team could develop software and complete their tasks. You probably used an initial value of something like 0.7 for your team’s velocity. But that was just a rough guess...now, you and your team have completed an iteration. That means you’ve got hard data you can use for recalculating velocity, and getting a more accurate figure.
Remember, your estimates and your velocity are about providing confident statements to your customer about what can be done, and when it will be done. You should revise both your estimates and your velocity at every iteration.
1. Calculate your new velocity
Take your team’s performance from the previous iteration and calculate a new value for this iteration’s velocity :
2. Calculate the work days you have available
Now that you have your team’s velocity, you can calculate the maximum number of work days that you can fit into this iteration :
3. Fill up the board with new work
You know how many work days you’ve got, so all that’s left is to take the candidate user stories and bugs, as well as stories left over the last iteration, and add them to your board—make sure you have a manageable work load :
Velocity accounts for... the REAL WORLD :
Velocity is a key part of planning out your next iteration. You’re looking for a value that corresponds to how fast your team actually works, in reality, based on how they’ve worked in the past. This is why you only care about what was done, and how long it took to get done. That’s the
key information that tells you what to expect in the next iteration.
And it’s STILL about the customer :
Let’s say you’ve calculated your new velocity. You collected bugs and put them all in a bug tracker. You waded through all the piles of unfinished and delayed tasks and stories, and had the customer reprioritize those along with stories planned for the next iteration. You’ve got your board ready to go. You still have to go back and get your customer’s approval on your overall plan. And that’s when things can go really wrong...
In this case, you are required to integrate some codes from other company for your customer. That means the original code for next iteration may not be available and so as the user stories and estimation. Software is still about CHANGE. Sometimes the customer is going to come up with a big change at the last minute. Or your best plans break down when your star programmer takes a new job...
But even though what you’re working on has changed, the mechanics of planning haven’t. You have a new velocity, and you know how many days of work your team has available. So you simply need to build new user stories, reprioritize, and replan :
Someone else’s software is STILL just software :
Even though the Mercury Meals library is not code you have written, you still treat the work necessary to integrate the code into Orion’s Orbits as you would do for software development activities. You’ll need to tackle all the same basic activities :
- User stories
Once again, you’ve got to get customer approval once everything’s planned out. And this time, there aren’t any surprises... (No news is good news)
Integrating 3'rd party source code :
When it comes to code that someone else has written, it’s all about trust, and the real lesson here is to trust no one when it comes to code. Unless you’ve seen a piece of code running, or run your own tests against it, someone else’s code could be a ticking time bomb that’s just waiting to explode—right when you need it the most.
When you take on code from a third party, you are relying on that code to work. It’s no good complaining that it doesn’t work if you never tried to use it, and until you have seen it running, it’s best to assume that third-party code doesn’t really work at all.
A third party is not you. That might sound a little obvious, but it’s really important when you’re tempted to assume that just because you use a great testing and development process, everyone else does, too.
You with your process :
It’s not a perfect world. When your code—or someone else’s code you depend on—isn’t working, and your customer is breathing down your neck, it’s easy to panic or catch the next flight to a non-extradition country. But that’s when a good process can be your best friend :
Dealing with code that doesn’t work is part of software development! In Chapter 11, you’ll see how your process can handle the heat.
Tools for your Software Development Toolbox :
- [ 英文學習 ]
- [ 計算機概論 ]
- [ 深入雲計算 ]
- [ 雜七雜八 ]
- [ Algorithm in Java ]
- [ Data Structures with Java ]
- [ IR Class ]
- [ Java 文章收集 ]
- [ Java 代碼範本 ]
- [ Java 套件 ]
- [ JVM 應用 ]
- [ LFD Note ]
- [ MangoDB ]
- [ Math CC ]
- [ MongoDB ]
- [ MySQL 小學堂 ]
- [ Python 考題 ]
- [ Python 常見問題 ]
- [ Python 範例代碼 ]
- [C 常見考題]
- [C 範例代碼]
- [C/C++ 範例代碼]
- [Intro Alg]
- [Java 代碼範本]
- [Java 套件]
- [Linux 命令]
- [Linux 小技巧]
- [Linux 小學堂]
- [ML In Action]
- [Python 學習筆記]
- [Quick Python]
- [Software Engineering]
- [The python tutorial]
- ActiveMQ In Action
- Big Data 研究
- Design Pattern
- Device Driver Programming
- Docker 工具
- Docker Practice
- English Writing
- ExtJS 3.x
- Git Pro
- Hadoop. Hadoop Ecosystem
- Java Framework
- Java UI
- Learn Spark
- ML Udemy
- node js
- Python Std Library
- Python tools
- Ruby Packages
- Windows 技巧
Source From Here Preface While I don’t consider myself a functional programming guru, all those hours spent in Haskell, Lisp and Scheme...
來源自 這裡 前言 : Thread 是 threading 模塊中最重要的類之一，可以使用它來創建線程。有兩種方式來創建線程：一種是通過繼承Thread 類，重寫它的 run 方法；另一種是創建一個 threading.Thread 對象，在它的初始化...
Preface: 在這個階層中，我們只需考慮電路模組的功能，而不需考慮其硬體的詳細內容. Verilog 的時序控制為以事件為基礎的時序控制: * 接線或暫存器的值被改變。 * 模組的輸入埠接收到新的值 * 正規...
轉載自 這裡 前言 : 這裡簡單說明了 #define 的幾種使用方法. 簡單的define定義 : #define MAXTIME 1000 一個簡單的MAXTIME就定義好了，它代表1000，如果在程序裡面寫 : int i = MAXTIME; ...