Project path-Agile Development Rookie Edition

Flash is one months later, to the management side, the mind is how to make a mess of things orderly arrangement, so that the team's continuous output. Although the basic need not knock code, but at the same time participate in 3 projects, feel slightly tired, this is a marathon, either go through the end of the breath, or go mad.

After about one months of preparation, a formal start-up project in August was finally finalized and entered the development phase.

Although the technical difficulty is not high, the project belongs to the vertical field of products, but there are big challenges.

Our Advantages:

The offline operations team has been in combat for two years, and has a number of customers, leading eldest brother also has a strong market to push ability.

There are 2 technical members and are familiar with the business, and there are 1 designers with an international perspective.

Our challenge:

We are a student team. Technology is not strong enough, external recruitment and unrealistic.

Solution:

I came forward to find more capable students to participate, the final project members have 7 people; one-person design, one-person app interface, one-person app integration, one-person app interaction, one-person web front-end, one-person Java backend, and I do Architecture & project management.

OK, simple pre-bedding is here, followed by the theme of this article, according to the Agile Development Manifesto route.

Agile Development Manifesto:
The greatest difficulty in teamwork between individuals and interactions over processes and tools is not technology, but people. For the team that we immediately pull from the outside and start immediately, agile development is right for us. To know, agile development is the most important is the team tacit understanding, followed by the individual comprehensive ability, finally is the specialty. At this point, there is a relatively mature routine, that is a few minutes a day of standing meetings, we come to heart, what did yesterday, what to do today, what problems encountered & solve ideas. But we can't use this routine because we're too free to work (not a company system). In the beginning, I told you how we would work in the computer room every afternoon. Free arrangements at other times. But only 3 said they could do it. Reason is not said, no problem, sometimes need to assemble, and then come together on the line. In agile development, team collaboration tools are for communication & interaction. Our technical department has set up QQ group, can be released in time, we test & exchange; I added all the others fetion, need to assemble the appropriate, will send a message to everyone, and then use the Worktile, to do the assignment.
The main individual interaction points are as follows: Design &app interface implementation, app integration &app interaction, Web front end &java backend; I & everyone; but there are no extreme programming elements.

work-ready software trumps all-encompassing documentation

We only have a rudimentary version of the document, using the Word table to draw the interface that flags its associated database tables.

I also only through the processon.com to make a simple conceptual framework diagram, the description of each module clearly, the specific design & implementation of the relevant responsible person (of course, not lost it is ~)

It turns out that in the development process, the requirements are still changing, sometimes subtraction, and sometimes improvement, because of limited capacity and no way to get the best solution in advance.

Can work software, not necessarily integrated, different people at different times to do out of the module, are "Can work software", the software came out, think about the point immediately clear. Of course, the weekly task delivery, is not so easy to achieve, I designed the first iteration of the task, it can not be completed, so now, early into the big chaos stage, integration work put, enhance communication, to prevent the battlefield scattered too badly. customer cooperation is better than contract negotiation

We are developed for ourselves, and of course there are customers, because the project is not our technical team-led, but the market operations personnel. But even in-house people can't work together, they often run and we don't want to get out of the dorm. Developers generally do not like meetings, so I will meet with customers two times a week, discuss progress & various situations, come back may adjust the download work plan. Responding to change is better than following plan

Although this is the benefit of agile development, who wants to hear the word "change". Need to "change", who is wrong.

A complete development, is a war, bang, and then decline, three and exhausted.

So the response to change, can only come out of my link now. Before the development of the main system to separate, in the process of the first iteration, the customer must determine the second iteration of the content, of course, the customer is not understand the design of the content of the iteration, so I have to prioritize, the most uncertain, the most likely to change, do not do first. (It is generally recommended that the most important, the simplest to do first, but I will add more consideration, whether it is easy to change). Conclusion Agile Development The first suggestion, the team will sit together, next to have whiteboard stickers ... And this first small step, we did not do, but the progress of the development can be promoted, although unpleasant, I do not know whether it is agile, but at present is smooth, no big bug appeared. Plan to complete the initial work of the project September 15, September 25 released ...