Poster

From ZenWiki

--Poster points--

• Architecture centric process
  • Stabilizing requirements and architecture
  • Identifying experiments early in the life cycle
  • Scoping out work to be done and components
  • Assigning to components to owners
  • Identifying integration points between components

• Client interaction
  • Technical client, positive because they communicate exactly what they want and understand what we have to say, negative because they have an idea in mind and are satisfied only when that idea is achieved
  • Constant interaction and feedback from client is very important for work to progress and also acts a good motivator
  • Our communication and delivery strategy worked well with the client
• Mentor interaction
  • Pointed out when we are going to trip and fall
  • Interfered whenever we were falling to get us back on track
  • Keeping them on the loop on everything especially when major decisions are to be taken, it is better to keep them on the loop while the discussions are going on so that they know what we considered and what we eliminated.
• Team interaction
  • If you dont know something ask!
  • If you think you know something and all the rest tell you you're wrong, ask!
• What we would do differently?
  • Get detailed requirements
  • More detail; especially doing detailed design after completing architectural design.
  • More detail design
  • Ask for demonstration/proof
  • Reassign work/shift roles as needed
• 1 line, 1 piece of advice to the incoming class (put on poster)
  • If you are committed, you will succeed; if you manage to come through it, you will be the better for it
  • Interact more with team members, find out where they're coming from, learn to interact with your team, learn to understand your team; stick to your goals; hang in there
  • Always try to learn something from others; if you commit more, you will learn more
  • Murphy is out there; don't let people tell you that you can't
  • Learn from others; however, if you have a concern regarding something tell everyone where your opinion is coming from (and why?) sometimes you are right, while at other times you are wrong -- both cases lead to better learning (and ultimately, to a better decision)

--Older--

• Conducting QAW very early helped in
  • Identifying quality attributes very early
  • Collecting requirements
• Impact of open source
  • Business constraint
  • Experiments play an important role in choosing open source, the more we experiment we can know how mature the open source product is and whether relevant information is readily available via documentation, sample code or active developer forums.
  • Minimize ground up development and leverage off the shelf product features
  • Architecture had to be changed to ensure different open source products interacted