project based course

gets real-world experience for software development

Design-centered, release-driven

project-success is primary goal

delivers innovative solutions

get to know who's who

Requires each to select interesting projects, select 8

presentations are a detailed reference, will be on canvas

attendance will be taken via N card

announcements will be in slack

• public channel course_announcements – faculty/staff postings, reply via threads

• private channel for teams – use for team, keep professional

• private channels can be created as needed

• public random channel for anything else

Project assignments – submit the damn survey.

• team assignments on or by the fourth

• give highest possible preference

• maximize preferences for class as a whole

apply software development expertise towards creation of solution to specific problem

Coach

• missing element of experience for teams

• students caught between faculty and sponsor for grading

• take advantage

• unbiased advocate for the team

• can provide feedback

• keep an open mind, no direct stake in the project

• provide support

Faculty/Staff

• help each team succeed

• tech manager

  • help with dev support, github, azure, slack, website, box

  • equipt mgr

• tribe lead

  • representative to work with dev squads

  • reviews activities, quality

  • provide guidance, direction

  • project management

  • design/architecture

  • product development

  • cs topics/areas of expertise

  • grading

  • team instruction

  • status reporting

• project manager

  • meet with squads, reports status, track progress against processes

  • provide more structure

  • invisible connection across all squads

• sponsors

  • decisions by business value

  • keep big picture in the squad's sight

  • makes decisions as they arise

• squad

  • cross-functional, self-contained

  • select goal, results

  • processes are provided – expect to use these

  • work an hour a week with assigned project manager

• squad lead

  • directly responsible for project team

  • ensures processes and agile values and practices are applied appropriately and followed

  • know and reinforce project and iteration vision and goal

  • lead by serving, serve by leading

• product manager

  • vision, requirements, feature prioritization, scope

  • conceptual integrity

  • kills features

  • manages stories, story maps, product backlog

• dev manager

  • the how

  • design integrity

  • code quality/reviews

  • integration

  • tooling

• need help

  1. project manager

  2. faculty member

• space and equipment

  • shared team rooms – 28d

  • reservable space

    • 110 – W 08:00–11:20, 15:30–18:20

    • 119 – TTh 15:30–18:20

    • 347 – T 15:30–10:30

  • will have to work together during team-time ; critical to work together as a team, even if in another location

  • meeting rooms available in avery, schorr, union, love

  • virtual machines, some laptops will be provided

  • laptops will require extensive check-out

  • will need to be in working order on return

  • virtual machine server

  • instructions will be provided next week

  • azure resources can be provisions as needed

  • to be used only for senior design

• Other policies

  • can go to sponsor

  • if in lincoln, go as needed on own

  • trip insurance needed > 50 miles

  • travel further, requires more work

assignments made

initial meeting/project kickoff

• everyone must make it

• on campus, avery/schorr/library/union

• between 9 and 5, not overlapping with class time

• Business Formal

• must reserve rooms/faculty

spaces – see previous lecture notes

agenda

• intros

• general overview, may need to go through processes

• project vision

• initial plans

• share team time schedule

• determine regular meeting time

• setup next steps

  • next meeting, tour facilities?

weekly meetings

• can't overlap, between 9 and 5

• have agenda

• take notes, track action items

• use invites

assume confidentiality

• very serious – failure to conduct in professional matter results in failure

• return or destroy all information

team times

• optimize for all

• 8 to 10 hrs

• 1.5 hr blocks, ideally 2-4

• at least one during business hours

• no times with <2 members

• work only on projects

• send team times to everyone involved

28d will be assigned to projects needing VR/AR equipment

not a course, an experience, should feel like an internship

collaborate!

process

• some agile methods will be obvious

• some methods are course-wide

• releases will be at 6 times throughout the year

Initiation

• initial sponsor meeting

• team/sponsor bonding

• common understanding

agile methodologies

• scrum

• extreme programming

• RUP

maps to industry best practices

Agile manifesto

• Values

  • individuals and interactions over processes and tools

  • working software over comprehensive documentation

  • customer collaboration over contract negotiation

  • responding to change over following a plan

• Principles

  • customer satisfaction through early, continueous delivery

  • welcome changing requirements, late in development

  • working software measures progress

  • face-to-face conversations

  • attention to technical excellence and good design

  • simplicity is essential

  • self-organization

Scrum

• not a process or technique, framework to use process and techniques

• product back log, sprint backlog, daily scrum meeting, potentially shippable increment

• self-directed, self-organizing

• no external addition of work to a sprint

• daily meetings

• demo to external stakeholders at end of sprint

Extreme programming

• quick, early collaboration

execution is the focus

Messaging w/ Slack

Docs and Storage, Box

Source Control w/ GitHub

ZenHub for Project tracking

Resharper/SQL server for windows dev

Github and Zenhub

• broduct backlog, release backlog, sprint backlog, issues, feature, epic, story, task, bug, hotfix

• issues get tagged

• zenhub integrates with the github interface

• labels can be used for issues and pull requests

• consistent across projects

• labels are grouped by color, according to broad themes

  • type – what is it

  • size – how big is it/how many things does it affect

  • value – how important is it

  • flag – things like bugs, change requests (not features/stories), features (things to be done), stories (an action a user might do), tasks (discrete parts of a story)

• sprint planning

• branch names should be specific and mappable to a specific issue

  • names should be standardized

  • single branch per task

  • single master branch

  • all sub branches need to be pr'd into branch

  • pull latest into the branch

• PRs are to be reviewed by the DM

  • PR should include briefe overview of feature/bug fix

  • link to relevant github issue

  • db server if applicable

  • review the code, ident violations of architecture

  • review db changes

  • check for minor bugs

  • review corresponding backlog

• check for hosting etc

  • azure/aws

  • db

  • mobile dev

• VM ware

  • thinclients

  • vmware horizon client

can't force it

teach practices and value

continuous improvement and support

continuous plans are hierarchical

stories and epics

project vision

• determine description

• organizational processes

• sign offs

• tech requirements

• collaboratively with customer taking the lead and team taking it to heart

• not an artifact, a process

  • To do – what to do

  • in what way – success criteria

  • so that – why it's being done

• Only use what helps!

release planning

• what gets done and when

• more releases, more value

create a strategic release plan

• market map, feature menefit map, market events/rhythms, architecture map

• makes it easier to change direction

• avoid last/loud priority problem

• publish/perish

under promise, over deliver

make plans for transitions

finding and measuring value

backlog – orderd list of ideas for product, kept in order expected to do them

Stories

• as a user-type, I want to do this-function so that I get specific-benefit

• in order to deliver-some-value, as a user-role, I want some-feature

• written by customers, estimated by developers, prioritized by customers

• priortized ast beginning of each iteration is based on value, risk, dependency

• epics,/stories/bugs/other items

• management objectives

• should be simple, easy to understand

• when large and fuzzy, are epics

Story mapping

• backlogs can make it hard to start, what first deliverable will look like, what happens if a story is missed, where the project is

• github issues aren't perfect, use zenhub instead

• story mapping aranges work into a helpful shape

• horizontal axis, order of priority

• vertical axis, increasing sophistication

• first horizontal row is the first woring item

Process

• determine vision

• break down into components

• collect major features

• create stories

• add details

• fill in build estimates

• …

People involved

• SMEs

• testers

• UI designers

• stakeholders

• developers

entry level enginerrs spend 40% of time writing, manegerial even more

your name is your most valuable asset

make sure whatever you put your name on deserves your name

first rule of tech comm is know your audience

and they aren't you

don't make assumptions, learn

start and finish professional

learn the norm

it's all about the people

background

• education

• profession

• culture

• personal

purpose

Experts – highly trained, understand, have experience – get right to the details

technicians – practical skils, gets things done, short-medium length sentences, common vocab – no complex theoretical discussion, schematic diagrams, parts lists, step-by-step

Manager – coordinates, supervices, doesn't care about theory – determine vocab, make job easy, exec summary, info may be used for higher-level execs

Lay person – curiosity, self-interest – simple, jargon in English, analogies and examples, discuss human angle, concentrate on implications

Accomodate multiple audience members – use a modular structure

presentations

• highly personal, a few tips

• plan

• design

• deliver

Melanie Kugler-Wright

• Project Manager

• 20 years w/ Hewlett Packard

• Worked w/ SAP

• Financial Systems, Mergers and acquisitions, ecommerce, healthcare, insurance

Releases

DEEP

• Appropriately detailed

• estimated – more than just a to-do list, a planning tool

• emergent – time, budget, qquality are fixed, scope is not – backlogs arre emergent, issues are frozen until more is learned

• prioritized – issues should be vertically arranged according to business value

prioritization

more organization

planning efficiency

Use story formats, etc

not mini usecases

not complete specs

not a contract

inteded to be interp'd w/o product owner

not tasks

defining done

Iteration processes

• protection

• aggre on a definition of done

• plan your own work

guidelines dev'd by a team describing how the team works together

different backgrounds

different generational attidutes

different cultural norms

built by the team

everyone agrees and supports the decisions

no do this from on high

how should the team behave?

how will we know if we're working well?

how are disagreements and conflicts handled?

interpersonal problems?

connection?

a crock of it

Can't force agile

teach pratices and value

continuous improvement and support

standups and burn down

• internal

status reporting

• radiating status outward

program status – tribe lead and PM

releases

• stable code to validate a solution

• release planning gives context to stable units

• subset of application functionality is made available outside of the development team for uncontrolled use

• not all releases are equal and type of system built has significant impact on how releases are planned

• code names – have fun

"I have always found tthat plans are useless, but planning is indispensable." – Dwight D. Eisenhower

Planning

• discover

• deliver

• from delivery

General estimation

• why estimate – what is he expected margin of error

• what have you committed to

• based on things that are measurable

• average multiple

• compare previous

• expert estimation

• be consistent

• analyze large errors in retrospectives

Agile Estimation

• velocity

• not time

• buy-in

• limits time investment

• story points

Planning Poker

• estimate indepentently

• share estimates, high and low explain reasoning

• repeat until convergence

many issues with software

Behaviors:

1. Testing

   • unit and integration testing

   • individual and combined units of source code

   • part of the process

   • automated testing

2. Working Build

   • Always have a working build

   • demonstrateable build

   • automated build process

3. Static analysis

   • remove errors and warnings

   • promotes readable code

   • verification in source code

4. Story mapping

   • maintain a story map using design studio sory format

   • arrange stories into a helpful shape

5. Definition of done

   • mainain an up-to-date definition of done

   • may have different criteria for different portions of the system

6. Estimation

   • estimate stories and assign points in context of design

7. Releases

   • Release milestones

   • plan well

   • use git tagging, etc

8. Security plan

   • have a security plan for the high risk areas

9. Telemetry

   • track performance, use telemetry to inform decisions

10. Cadence/Rhythm

    • Maintain consistency

Review engineering ethics – challenger, hyatt walkway

Review google maps 2010, Nicaragua/Costa Rica

personal dimension

• comfortable with it later

• family pride/shame

• looking back is it a better moment or a worse moment

Integrity in coding practices

be careful of how one does things

Acceptance criteria

define tests

doing so has high return

Integrate testing with development

each team member is responsible for testing, including writing tests

why

• to teach

• gain further expertise

• higher salary

• Pursue interests in more depth in researrch, contribute to human knowledge

the Matt Might slides

Masters degrees take less time

PhDs take 4-6 years

Many different areas

How?

• Jan 15 for financial consideration, fall

• September 1 for Springs

• Resume

• 3 reference letters

• transcripts and GRE scores

• statement of purpose

Grad Info Day is December 1, email LaRita Lang

be ready to do peer review process

testing is a part of development

code coverage requirements are useful

continuous design improvement

Know what code smells are

science of gathering data and transmitting to a distant reciever for interpretation and analysis

Why?

• How is the system running

  • resource usage

  • error rates

  • request/ops rates/volumes

  • crash reportv

  • performance metrics

  • exec timing/profile

  • active db connections

  • infrastructure config

• What are users doing

  • login attemts

  • content access

  • uploads

  • cart added

  • connection established

  • review submitted

  • rotated

  • inactivity

• Who are users?

  • lecation

  • age

  • generation

  • gender

  • language

  • education level

  • field

  • school

  • ethnic affinity

  • income/net worth

  • ownership

  • etc – facebook list

Telemetry is determined by business needs

Help to diagnose errors

Pair programming

Driver and Navigator, programmers switch roles frequently

navigator considers direction of work

Can benefit in many different ways

Can have issues – i.e., work preference, intimidation, cost, ego, personal habits, etc.

All production code, both parties contribute, change pairs, develop comfortably, end when tired

start reasonably, rely on and support your partner, talk a lot

continuous integration – merge all workspaces with shared mainline regularly

entinsification of periodic integration with incremental/iterative development

small pieces of effort, applied frequently

unit tests, integration tests, static and dynamic checks

Nice jab at Project managers

personal integrity and professional obligations

Ethics goes both ways

Discovering expectations – unknown to understood

Consider rotating organizational positions

more releases create more value

mvp is minimum viabele product – feedback for where to go next

Know expectations

Collaborate well