Add a comment

 

Re: The conflict between agile and architecture (part 1)

Off the top of my head (normally I'd sit down with the client/team to hash a lot of this out) I think the pain points are: * Transactional read/write access to the banks internal systems (is there a layer API already or do we have to build one) * Security (it's banking!) * Possibly the W3C stds, depending on which ones they mean. More importantly what browsers and clients are we expected to support? IE6 or a mobile phone browser could be a pain point. * Branding I'm not too concerned about depending on how far advanced they are with the design of the new brand. * Better usability I'm not so concerned about, I'd try to make sure we have a focus group of users + I'm assuming we've got a Ux/UI expert on the team + some enthusiastic end to end developers. If not I'll hire some :) * Last but not least, what features does the new system really need? Was the old site well thought out from a business perspective? If it was then we can focus on the technology, else we need to really get some core user stories worked out. As to the "Why the pain points first". You always want to identify (if possible) the biggest areas of risk, the items that are make or break for the project. For example, if one particular web stack didn't support txns properly, I'd want to find that out in my 1st week during a prototype, not in month 2 when the first user testing fails...

Re: The conflict between agile and architecture (part 1)


Title
Body
HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).