Congratulations! You made it! The official lecture of the program is now officially complete, and it's time to go gangbusters on your final projects. I can't wait to see what you'll build! Before you get started, though, here are some points about logistics.
Here's how this will work...
You'll organize yourselves around project teams Startup Weekend style. Everyone who wants to gets 1 minute -- exactly 60 seconds -- to pitch their idea to the group. Include a name (which can change), your name, the basic elevator pitch, any technical direction, and what you lack to execute. After the pitches, everyone gets 3 votes that they can place on one or more of those ideas, helping choose the projects that everyone will work on. You're free (and encouraged) to ask clarifying questions of the founders or even abandon your own idea because you like someone else's better.
After the voting, Susanna, Brian, and I will select the top 3 or 4 projects based on votes and feasibility. Once we announce the winners, it's time to start dating! As the pitching founder, you have to convince others to participate in your crazy idea, and each team can only have 3 members. Time to practice some diplomacy!
Additional Logistics
For these projects, you should create a Github Organization to contain your project code. The founding team member should create the Org and invite the rest of the team as members of the "Owners" team for simplicity. Everyone should maintain their own fork of the project from there and open PRs to request merges with the 2x :thumbsup: policy. You should create a Github Pages repository for the Organization separate from the project repository. The Github Pages repo should contain a simple one-page product site explaining your project. Keep it up-to-date. The final deployment destination of your project should be the gh-pages branch of the code repo, unless your team needs additional functionality that would be difficult with Github Pages.
Once you have your teams, your Github Organization, and your repos setup, you start work immediately on User Stories, mockups, prototypes, wireframes, paper mache models, Legos... whatever will help solidify your idea. You must have User Stories to describe your project, and you must review those with me before you proceed, incorporating any changes I recommend. Therefore, record them in your repository and open a PR for discussion.
After you have User Stories, assign estimates as a team. I have my deck of Planning Poker cards, which you are free to use, and I encourage you to utilize something more complex than T-shirt sizes for this project. Before you create Github Issues, record estimates for all your User Stories and discuss them with me. Additionaly, estimate how many points / things you'll be able to accomplish in a day, a week, and for the whole project. Add those estimates to the User Stories documentation and discuss them with me.
Discuss your technology stack -- Angular, Firebase, and Bootstrap? jQuery, SASS, and Bourbon? Vanilla JS Chrome Extension? -- and start breaking down the User Stories into the MVC component architecture that we discussed in class. Identify the Nouns, Verbs, and Workflows of the application and how each will be displayed with whiteboard wireframes or using a wireframing tool like InVision or Proto.IO. Review these with me and incorporate feedback (you should be noticing a pattern).
Split the work into features. Create Milestones and Issues assigned to the appropriate Milestones to track your work and reflect progress. Use git-flow to track features and releases. Make sure that you release often (at least once per day) and notify me of open release PRs to review. When you show me working code, it should always be in a release; when you show me work-in-progress code, it might be anywhere.
I expect to see many multiple commits per contributor per day, and everyone should take turns managing the release process, merging, and updating. If I start to see a member flagging, I reserve the right to pull them off the team, so commit and push often. Don't make me come down there.
LoganArnett
commented
10 years ago
It's The Final Countdown
Congratulations! You made it! The official lecture of the program is now officially complete, and it's time to go gangbusters on your final projects. I can't wait to see what you'll build! Before you get started, though, here are some points about logistics.
Here's how this will work...
You'll organize yourselves around project teams Startup Weekend style. Everyone who wants to gets 1 minute -- exactly 60 seconds -- to pitch their idea to the group. Include a name (which can change), your name, the basic elevator pitch, any technical direction, and what you lack to execute. After the pitches, everyone gets 3 votes that they can place on one or more of those ideas, helping choose the projects that everyone will work on. You're free (and encouraged) to ask clarifying questions of the founders or even abandon your own idea because you like someone else's better.
After the voting, Susanna, Brian, and I will select the top 3 or 4 projects based on votes and feasibility. Once we announce the winners, it's time to start dating! As the pitching founder, you have to convince others to participate in your crazy idea, and each team can only have 3 members. Time to practice some diplomacy!
Additional Logistics
For these projects, you should create a Github Organization to contain your project code. The founding team member should create the Org and invite the rest of the team as members of the "Owners" team for simplicity. Everyone should maintain their own fork of the project from there and open PRs to request merges with the 2x :thumbsup: policy. You should create a Github Pages repository for the Organization separate from the project repository. The Github Pages repo should contain a simple one-page product site explaining your project. Keep it up-to-date. The final deployment destination of your project should be the
gh-pagesbranch of the code repo, unless your team needs additional functionality that would be difficult with Github Pages.Once you have your teams, your Github Organization, and your repos setup, you start work immediately on User Stories, mockups, prototypes, wireframes, paper mache models, Legos... whatever will help solidify your idea. You must have User Stories to describe your project, and you must review those with me before you proceed, incorporating any changes I recommend. Therefore, record them in your repository and open a PR for discussion.
After you have User Stories, assign estimates as a team. I have my deck of Planning Poker cards, which you are free to use, and I encourage you to utilize something more complex than T-shirt sizes for this project. Before you create Github Issues, record estimates for all your User Stories and discuss them with me. Additionaly, estimate how many points / things you'll be able to accomplish in a day, a week, and for the whole project. Add those estimates to the User Stories documentation and discuss them with me.
Discuss your technology stack -- Angular, Firebase, and Bootstrap? jQuery, SASS, and Bourbon? Vanilla JS Chrome Extension? -- and start breaking down the User Stories into the MVC component architecture that we discussed in class. Identify the Nouns, Verbs, and Workflows of the application and how each will be displayed with whiteboard wireframes or using a wireframing tool like InVision or Proto.IO. Review these with me and incorporate feedback (you should be noticing a pattern).
Split the work into features. Create Milestones and Issues assigned to the appropriate Milestones to track your work and reflect progress. Use
git-flowto track features and releases. Make sure that you release often (at least once per day) and notify me of open release PRs to review. When you show me working code, it should always be in a release; when you show me work-in-progress code, it might be anywhere.I expect to see many multiple commits per contributor per day, and everyone should take turns managing the release process, merging, and updating. If I start to see a member flagging, I reserve the right to pull them off the team, so commit and push often. Don't make me come down there.
The Checklist
gh-pagesbranch?