Last week, software architect Raffaele Garofalo hosted a Typemock webinar on Agile architecture. There were lots of questions and we weren’t able to get to all of them in the webinar, so Rafe generously agreed to answer the questions after the webinar.
You can watch the webinar here.
Patrik asked:
Q: Can you elaborate on what you mean with the "design phase"_
Ok, during the first iteration, the envision, there is a light design phase. You should design some scratches of your envision, representing the architecture and the UI, but you should not invest too much time.
Design phase while modeling means adopting UML to design your models.
Q: I didn’t quite catch the TFS workflow and how Raf used it.. Can you show it again? (also, is that view new in the tfs preview? Looks awesome)
The TFS I was working with is the new version called 2011 preview. The workflow has been adapted by me, I will publish the Agile Architecture workflow for TFS in the future.
Q: How does your "Iter: 0" relate to the PO, backlog and sprint planning?
Ah ah, interesting. The envision or iteration 0 is tricky to fit into SCRUM. Take the classic meter to measure an iteration, like 1 or 2 weeks. Inside this timeframe you should have enough space and time to prepare the necessary analysis and mocks required by next steps. So you may consider iter 0 like a beginning sprint.
Q: Couldn’t the use-case diagram be enough for the modeling phase? I’m interested in hearing your reasoning because I’m currently in this situation in my current project. What level of detail is enough when it comes to architecture that lets developers use their brain and problem solving power?
No, the use case is not enough because it may incur into personal interpretation. With the use case and the acceptance you and your team are ready for the modeling phase, where you create the architectural style for that feature. The modeling should be enough to represent the current feature and it should not be implemented, the implementation occurs in the next phase where you apply TDD against the model discussed in the previous part. It is hard to keep the model the blueprint of the code and often it doesn’t provide value. It is important that the model represents what you are delivering.
Q: Does the Process workflow you describe impact the philosophy of embracing change? How can we perform radical change when we get a bigger up-front model?
No, it doesn’t because Agile Architecture pretends the flexibility into your model. Model just enough to represents the feature and remember that you can always come back and re-model and re-factor. Embracing Agile Architecture will force you to have a dynamic more agnostic and flexible model than using a classic architecture approach.
Why would you get a radical change request with a radical model upfront? Of you adopt Agile you should structure these changes into small iterations.
Q: How can it be TDD when you have specified the methods/attributes before writing tests that requires them?
I still believe that you are applying TDD and XP in the most strictly way. You can model UML and decide the behaviors of your model, Then with TDD you will implement the model. I don’t think that TDD should drives your naming convention or model terminology.
Huet asks:
"Q: Shouldn’t the arrow be going from the support team to the team members?
If you mean the dependency adopted in UML, yes the arrow should be in that way. My intention was to represent the transfer of knowledge between the various members of the various teams.
Q: Acceptance Tests should have been written before the model.
Not really, if you adopt the strict TDD all the acceptance tests should be written before, but when you envision the architecture, it is too early to write acceptance tests. When you start the iteration and you have your requirements define, you may start to model against the acceptance criteria for that iteration. But remember that the modeling part should be light enough to provide value for the next step.
Q: These tests should be built to support the acceptance tests.
Again, you are referring to a strictly TDD approach, which is not wrong but differ a little bit from the entire Agile Architecture process.
Q: ATDD – Acceptance Test Driven Development
In the webinar I was talking about Agile Model Driven Development.
http://www.agileModeling.com/essays/amdd.htm
Q: the functions of the architect are clear, but it is not clear how these functions are intended to fit into the Sprints.
The sprint is composed by three parts, modeling, brainstorm and coding. The architect will perfectly fit into each of this phase. I think I have explained this concept during the webinar, but just to be sure. During modeling and brainstorm the architect should help with his knowledge and collaborate in the modeling, during the coding he should be an active coder too and contribute to the technical decisions providing knowledge and expertise.
Q: What is a "mock"? – do you mean a wireframe mock-up?
A: Typemock will be hosting several webinars on mock objects. Check out https://www.typemock.com/webinars/
Thanks Rafe!
For more Typemock webinars, or to watch past webinars, and learn how to start unit testing go to https://www.typemock.com/webinars/
