Project PitBull - Development proper kicked off
After over a week out of the country due to family bereavement I am back on project PitBull.
Development
- Ward has made great progress on the steps and navigating back an forth.
- I am on the learning curve with dust and using partials. Yesterday I figured out partials and passing data. A question in my mind is how best to call the partials? from within another template or from within a backbone view? and when to do which.
- I needed to support a list of lists of models. Backbone.js collection is for models not for a collection of collections. I could override parse in the collection and build the hierarchy out or I could use a plugin (tbd) to support. But for now I will just take the simpler route and code a Backbone Model object on which I call fetch and that model object will store the hierarchy. It's aint Backbone classes but perhaps I don't need such classes if its all just for display purposes on the ui. I can still navigate the object hierarchy using object notation.
- We have a new hire client side dev started last week and another ramping up next week. It's alot to take on but given the aggressive deadline then it is a case of adding bodies. But I think we're at the limit now on client side.
- Code walkthrough completed this week. Went very well I think. Have to code walkthrough new devs code today.
Planning
- the planning effort is consuming alot alot of dev cycles from another dev and I. So that must stop because we have code to write. A plan is just a plan, it will change and it doesn't have to be perfect, it will be more ambiguous the further out you go. If you need to give a plan to the Client to ensure they have confidence in our approach then be careful to provide the right level of information and to under-promise and over-deliver.
- the challenge with Agile and forecasting to an end date is there is an inherent conflict. Forecasting to an end date needs detailed planning based on designs, Agile is more concerned with the here and now, the next few sprints. I think you need to be able to project ahead for many reasons (budget, resources and organization, setting expected launch etc) but again, it has to be realized in Agile the plan becomes much more volatile.
- I would organize such a plan as follows
Development
- Ward has made great progress on the steps and navigating back an forth.
- I am on the learning curve with dust and using partials. Yesterday I figured out partials and passing data. A question in my mind is how best to call the partials? from within another template or from within a backbone view? and when to do which.
- I needed to support a list of lists of models. Backbone.js collection is for models not for a collection of collections. I could override parse in the collection and build the hierarchy out or I could use a plugin (tbd) to support. But for now I will just take the simpler route and code a Backbone Model object on which I call fetch and that model object will store the hierarchy. It's aint Backbone classes but perhaps I don't need such classes if its all just for display purposes on the ui. I can still navigate the object hierarchy using object notation.
- We have a new hire client side dev started last week and another ramping up next week. It's alot to take on but given the aggressive deadline then it is a case of adding bodies. But I think we're at the limit now on client side.
- Code walkthrough completed this week. Went very well I think. Have to code walkthrough new devs code today.
Planning
- the planning effort is consuming alot alot of dev cycles from another dev and I. So that must stop because we have code to write. A plan is just a plan, it will change and it doesn't have to be perfect, it will be more ambiguous the further out you go. If you need to give a plan to the Client to ensure they have confidence in our approach then be careful to provide the right level of information and to under-promise and over-deliver.
- the challenge with Agile and forecasting to an end date is there is an inherent conflict. Forecasting to an end date needs detailed planning based on designs, Agile is more concerned with the here and now, the next few sprints. I think you need to be able to project ahead for many reasons (budget, resources and organization, setting expected launch etc) but again, it has to be realized in Agile the plan becomes much more volatile.
- I would organize such a plan as follows
- - I'd have tasks listed separately
- - then milestones for each sprint which lists dependent tasks
- - likewise milestones for QA which list dependent sprints/tasks
- - likewise milestones (more coarse) for Client
- that way the plan is more flexible to change. I would not organize tasks under sprints.
Comments
Post a Comment