Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would say the main topic that you need to focus on in order to convince your friend is "Agile Estimating and Planning". Many people believe that being Agile means strictly no planning, which is not true. Scrum - a Software Development framework based on Agile principles suggests that every project start with a Release Plan. Most of your questions will be answered based on the Scrum Guide.</p> <blockquote> <p>How much prep is too much</p> </blockquote> <p>Let's take a step back to understand what "prep" means, it has a more deeper meaning than just one huge planning and design session. Prep would mean - Scrum Release Planning, Sprint or Iteration Planning, Daily Scrum Meeting Planning. You really never stop your "prep" work, it goes on. The moment you fail to plan, that is the moment you plan to fail. The Scrum release planning usually requires no more than 15-20% of the time an organization consumed to build a traditional release plan. In this meeting I suggest you write up an Business EPIC user story, and Technical EPIC User story as well, and break them down into chunks fairly quickly. You don't need to go into detail, the details will be taken care of in Sprint Planning. During Sprint Planning, just groom the high priority user stories to the right detail level and commit to completing them in your current iteration. Sprint Planning should not be more than 4 hours for a 2 week iteration. And the daily Scrum sync up meetings would only last 15 minutes, since it is just the 2 of you, it could be shorter.</p> <blockquote> <p>how little is too little?</p> </blockquote> <p>You would know you've "prep"ed too little when you get blasted with impediments when actually trying to do the work, during the iteration. When things go just enough smoothly, you know you spent the right amount of time prepping.</p> <blockquote> <p>What high-payoff things should we be focusing on at the start of our project?</p> </blockquote> <p>Try focusing on answering this simple question below: “How can we turn the vision into a winning product in best possible way?, The Business EPIC User Story, Technical EPIC Story- this would be your product vision from a technical and infrastructure standpoint. For example - are you going to use TDD, Continuous Integration plan, Version control plan, etc. You can never ignore these, how much ever you try. Another thing is figure out who are your products users. ROI, and penalty of high priority User Stories. Done Criteria for your product, which would also apply to a small slice of your product. I can go on and on, so I will stop here.</p> <blockquote> <p>How should we judge what is worth working on, code wise (not features), at this stage of development?</p> </blockquote> <p>Code wise, the most worthy thing to work on would be, the piece of code required to be coded, to get the most high valued feature working and shippable. You can do this by calculating ROI and the penalty of not getting it done. You will have to know who the users will be, the benefit of the feature for the users, and the impact on the users if the feature is or is not delivered. Higher the ROI and Penalty - higher the value. I know this is easier said than done, but who said the software business was easy?</p> <blockquote> <p>Is it worth spending the time implementing things like xCSS and other systems that would make it easier to write clean code from the start?</p> </blockquote> <p>If you want to be Agile then yes. Clean code means lesser technical debt and higher quality of software. Agile suggests that developers pay constant attention to quality of code. Why? Because the people who wrote the Agile principles had seen far too many projects fail because of not taking care of technical debt early on in the software development process.</p> <blockquote> <p>How would you explain to him the value of fine-grain tasks and committing small atomic changes.</p> </blockquote> <p>A collection of fine grained tasks associated with a User Story, which when done based on the done criteria, would produce a shippable slice of software.</p> <p>I would explain it like so: Think of your product as a multi layered cake. Before you start to build the whole cake, you need to know what flavor cake it is going to be, and how many different kinds of layers it will have. The flavor are the mock up screens and the EPIC user stories, and the layers come up from the Technical EPIC story. The layers would be Database, middle ware, server side code, html, skins etc. Now building the complete cake at one go would be a bad idea because the cake loving customers often change their mind on what kind of cake they want to eat. A whole cake might take longer to build than a small slice, and what if after you build the whole, say a Chocolate cake, the customer asks for a carrot cake? That would make for some throw away cake or code :) Instead why not build one small vertical slice at a time, let the customer taste it, get some feedback, modify the next piece accordingly, and keep adding slice by slice to create a whole cake, which the customer really wants!!</p> <blockquote> <p>What things have you done with your code that have lead to a sooner ship time?</p> </blockquote> <p>Used decoupled designs, used interface inheritance more than class inheritance, code review, TDD, PMD, Checkstyle, Pair programming, Collaboration with customer, the list goes on. All these things lead you to your product being "Done". The more of the above items you skip for later, the farther you are pushing your ship date. I would rather deliver a delicious and high quality small slice of cake to the customer, rather than a low quality, not yet done slice.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhat is worth spending time upfront when starting a new project
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USsjt
    1. USsjt
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTDownMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThank you for explaining it from the agile method and perspectives. This has helped us form a good dialog for expressing our concerns with each other. The cake description especially fits well with the idea of "half a product, not half assed product" from the book.
      singulars
      1. PO
      1. USApe-inago
    2. CONo problem. Glad it helped.
      singulars
      1. PO
      1. USsjt
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload