Management - Request agile developer to submit a feature spec and design spec before beginning a new story

In an agile development environment, developer will collect story owner feature requirement and then design the way to implement. To overview the job to be carry out by developer, team leader have to get a sense of what has been requested and what is being prepared and designed.

Project management - decide a story's point on task board

When it comes to review stories on task board and have to decide the
complexity points on every story, one approach is for every developer
and lead to think on their own without communicate with each other.
Then after everyone is ready, show the estimated points to all and
discuss the reason behind it. It would be quite a effective way.

Project - Enhancement on website to provide online application and facebook integration

On this story, we are going to enhance our current company website to support online application.  Within the application, we will correct client's personal information together with their Facebook authentication for further user information collection.

Requirements:

1. Online application in a secured channel.
2. Uploaded application and attached document needs to be secured.
3. Collect Facebook authentication token.
4. Access to submitted application from our internal staff in secure way.

What we are having now:

1. The current website was design and created by a website design house.  Mainly static contents.
2. We have an internal system which stores all client's sensitive information.
   
3. We have register company domain and website is hosting on a shared hosting plan.  i.e. Many other outside domains are hosted together, sharing resources and IP.  This was fine at the moment since we only serves static information on our website.
   
4. Website contents is managed by Modx.
5. Design house will be responsible for creating new application form on our website.
6. We will setup the environment for new website deployment and make sure the security of application data.

Considerations:

1. Since our online application need to be secured, we needs https on application pages.
2. Internal system should be separated from website for security concerns.
   
3. Application data will be stored on hosting server database and file system.
   
4. The application data on website should only be a temporary storage.  Once it's retrieved from our staff, it should be cleanup from website database.
5. Application data should not be accessible by Design house personnel.  We should only provide minimal access for their deployment.  Once done, we should restrict their access.
6. Access to application data on website should be granted only to IPs from office and internal system servers.

Things to do:

1. Move web hosting to VPS so as to get a dedicated IP and server resource.
2. Setup VPS and grant required access to design house for their deployment.
3. Create access point on getting the Facebook authentication token and applications into our internal system.

Story daily:

1. The original communication between us and design house was handle by another colleague who didn't say anything about online application security concerns.  No HTTPS was plan in the implementation.
   
2. Raise security concern to product director.
3. Agreed on we should make all application form secured.  Using HTTPS and SSL connections.
4. Secure points: submission of form; Storage of application data on web server;  Secure retrieval of data from web server to our internal system.
   
5. Coordinate with design house to make sure we are on the same picture and they know what they're going to do.
6. Coordinate with developer on the way to get access Facebook token that will be stored on web site database.
   
7. Apply VPS hosting plan.  Pay the bill, get access to VPS.
8. Setup VPS for Modx deploy.
9. ....

Management practice - Set deadline for every task

No matter which development methodology is using, whether it is Scrum or Kanban, it's a good idea to set a date on which a task should be finished. For Scrum, within a sprint, 2 weeks or 3 weeks, certain PBIs/stories have to be completed. This can push or encourage developers to aim tasks for the deadline. Otherwise, developers may try to refactor and refactor for a better solution or test again and again. There's no perfect solution. Just set a date and let stories be closed on that date. Then start new tasks on next cycle.

Another advantage is to provide a product road map for product owner to foresee and expect certain features to be done on certain milestones.

See also for Scrum

Kanban - http://en.wikipedia.org/wiki/Kanban_(development)
Lean - http://en.wikipedia.org/wiki/Lean_software_development

Run multiple Jenkins Rails test simultaneously

Under the continuous integration platform Jenkins, there can be multiple build projects that may run at the same time.  For example, unit tests, functional tests and integration tests. 

By default, all projects may have database.yml configurations that points to the same test database.  This may lead to failure like this:

...

DETAIL:  There are 1 other session(s) using the database.  : DROP DATABASE IF EXISTS "test_db">  test_db already exists

...

To allow simultaneously tests, database yml should be modified to use different database:
/var/lib/jenkins/jobs/[Project Name]/workspace/config/database.yml


* Set the max number jobs to be run concurrently on Jenkins' settings.

General procedures for system feature enhancement

Feature Spec - Identify the goal.

• Feature(s) request received.
• Breakdown requests into small request items.
• Clarity requirements if necessary.

Design & Planning - Draw a direction map.

• List out the required changes.
• List out new functionality/methods needed.
• List out side effects.
• Reuse existing functionalities if possible.
• Ensure DRY (Don't repeat yourself)
• Open for future changes.
• Double check all usage scenarios.
• Run new features on mind map.
• Feasibility studies if necessary.
• Division of Labour.
• Estimate schedule.

Implementation - Work through the map.

• Create test cases.
• Implementation.
• Refine the feature and details during implementation.

Testing

• QA test
• User Acceptance test

Demo

• User demo
• Get user feedback
• Go back to feature spec cycle upon user feedback.

Staging Release

• Deployment to stage server
• Pre-release final checks.

Production Release

• Release to production.

User Training

• Conduct user training on new features.

Practices of Agile Development

Attitudes

• Blame doesn't fix bugs. 
  
• Don't code in isolation, do code reviews.
• Use unit tests.
• Do not code in quick and dirty ways.

Continuous Learning

• No need to be specialized on every technologies.  But need to known the industry trend.
• Share knowledge with the team.  Let everyone learn from each other.
  
• Learning new technologies may have to give up the old ones.
• Ask why and dig into the root of solution.
• Keep development cycle in a good pace.  Design -> Implementation -> Testing -> Code Review -> Release.

Customer Oriented

• Let customer do the business decisions.  Understand customers needs.
  
• Design in two phrases:
• Macro design:  Give the direction of implementations.  Not down to the details.
  
• Micro design:   Ways on solve problems during implementation.
• A good design should be correct but not precise.
• Blindly picking a framework is like having kids to save taxes.
• Don't build what you can download.
• Base on project requirement, select the right tools and technologies.
• Checked-in code (on master branch) is always ready for action.
• Never accept big-bang integration.  Should integrate codes more often.
  
• Automate QA testing.
• Get continuous feedback from customers.  Ensure the project is on the right direction.
• Release the smallest usable feature in project development life cycle.
  

Feedback

• Use unit tests to provide coding feedback.
• TDD - Write tests before writing code.
• Good design doesn't mean more classes.
• Target for simple design.
• Ensure code works on different platform (if applicable).

Agile

• Write clean code when speaks its purpose or function.
• PIE - Program Intently and Expressively.
  
• Let code speak for itself.  Comments only helps.  Don't comment to cover up.
  
• DRY - Don't Repeat Yourself.
• Carefully pick meaningful variable and method names.
• No best solution.
• Always code in clean, simple and easy for maintenance way.
• Simple is not simplistic.
• Do not use complicated design pattern unless it's absolutely necessary and with good reasons.
• Use inheritance for is-a; Use delegation for has-a or uses-a.

Daily Practice

• Don't get burn twice.  Keep a log book.
• Treat warning as an error.  Solve it.

Collaboration

• Daily short (stand) meeting (10 - 15 minutes).
• Always know what others are working on.
  
• Simple questions for everyone:
• What's yesterday achievements?
• What's today's plan?
• Any obstacles?
• Do not discuss the questions during meeting.  Details should be discussed after meeting.
  
• Meeting holds in the morning after everyone settle down.
• Advantages of daily meetings:
• Know the existing problems and progress.
• May reallocate resources if needed.
• Let everyone know what others are doing.
• May know who can provide a quick solution to a problem.
• Keep everyone in a good working pace.
• You can't code in PowerPoint.
  
• Architect should be able to code.
• Code should be reviewed and refactored if necessary.
• Every project member should shift to handle different part of the project.
• Knowledge grows when given.
• Inspire rather than given instructions.
• Code review basic check points:
• Easily readable and understandable?
• Any obvious mistakes?
• Is the code give negative effect on other functionality?
• Any repeated code?
• Can be improved or refactored?
• Unless there's obvious improvement after refactoring, do not change others code.
• Report progress and problems.

General guidelines for team software development

Development Environment

• Source control - e.g. Git (preferred choice) , Csv, Svn
• May use internal server or public source controls (e.g. Github/ Unfuddle)
• Team members should receive notification whenever there's new push/commit to the server repository.
• Knowledge base - Wiki
• Team members should try to contribute on:
• Project documentations
• Technical know-hows
• Workflow control for agile development.  Some choices:
• Simple and easy to use - Pivotal Tracker
• More comprehensive one - Atlassian JIRA  
• Continuous integration - Build and test server.  For example:
• Jenkins - For Ruby on Rails developments
• CuriseControl.NET - For .NET developments
• Test Automation
• Browser test - Selenium IDE

General Coding Practices

• DRY - Don't repeat yourself.  Never copy and paste same (similar) block of code in multiple places within the project.  Instead, common functionalities should be "extracted" to a single access point like a helper function or by other means.
• Coding conversions - Team members should follow a single set of coding conversion.
• Try to keep each line under 120 to 150 chars.
• Code with comments.
• Should always keep the code clean and easy for maintenance.
• Should keep small code source files.  Every source code file should in general not more than 500 or even 300 lines (excluding large blocks of comments).
• Should keep small functions - not more than 30 to 50 lines.
• Should keep functions as private/protected as possible.  Only expose a function to public whenever necessary.
• Every single function/method should be unit tested.
• Regular code coverage test.
• Developers may keep a work diary to log everyday's work done.

Daily Collaboration Practices

• Team members MUST complete test (unit, functional, integration test) and make sure there's no unexpected error before pushing code to repository.
• The build server (e.g. Jenkins/CuriseControl.NET) should run complete test whenever there's code update on repository.  In this way, whoever broke any tests can be clearly identified.
• If there's unexpected errors (except explicit NotImplementedError) reported by build server, whom pushed the related code should fix the errors ASAP.
• Responsibilities - whenever a feature raised a issue/bug need to be fixed/enhanced, the team member(s) who contributed to that feature should be have the priority to follow the case.
• Communications
• Better communications between team members always save development time and avoid unnecessary bugs.
• Always let other team members know what you're working on.
• Pending or unfinished feature can be marked as "NotImplementedException" and let the corresponding test fail.  Then commit code to repository.
• Any bug reported from QA Engineers should state as much details as possible including the environment and steps to reproduce a bug.
• Code review
• Team members should review each others' code.
• For any problem spotted, one should inform the author of that code.  In addition, adding unit tests to indicate the problem may also helps.
• It there's no QA team in the group.  Developer should write additional test cases for each other!  It's always better for a developer to find a bug before the end users!
• All developers should stand by when a new release is deployed to production.
• Business logic and any updates should be kept in a centralized repository such as work flow control or wiki.
• Every developer should try their best to commit/push the work done on that day before leaving the office.

Source Control Usage Practices

• New project feature should be developed on a separated branch.  Then merge back to master/main trunk when finished and tested.
• Project releases should be tagged.

Unfuddle

Software Project Management

https://unfuddle.com/

Pivotal Tracker

Build better software, faster.
Collaborative, lightweight agile project management tool, brought to you by the experts in agile software development.

    Increase Visibility and Collaboration

    Bring everyone, even distributed teams into the same virtual room. Enable a more efficient way to agree on priorities and stay aligned with the entire team.
    Plan Based on Realistic Estimates

    Stay on target with Tracker's continuous, automatic prediction of milestone completion dates, based on your team's performance.

    Deliver on Customer Feedback

    Get the right product to the market sooner, based on continuous feedback and prioritization. Respond to changing needs and new requirements easily.
    Transform How You Build Software

    Supercharge your agile project teams with focused, real time collaboration. Accelerate agile adoption with a simple, proven process.

http://www.pivotaltracker.com/

JIRA - Project management

Your Development Process, Your rules

JIRA is the project tracker for teams planning, building and launching great products.

Thousands of teams choose JIRA to capture and organize issues, work through action items, and stay up-to-date with team activity.

http://www.atlassian.com/software/jira/overview

Scrum - Agile development

Scrum is an iterative and incremental agile software development method for managing software projects and product or application development. Scrum has not only reinforced the interest in project management,[citation needed] but also challenged the conventional ideas about such management. Scrum focuses on project management institutions where it is difficult to plan ahead. Mechanisms of empirical process control, where feedback loops that constitute the core management technique are used as opposed to traditional command-and-control oriented management.[citation needed] It represents a radically new approach for planning and managing projects, bringing decision-making authority to the level of operation properties and certainties.

http://en.wikipedia.org/wiki/Scrum_(development)