When it comes to agile development, it is not agile because of agility. In recent years, agile development has been a myth of many agile consulting service providers. This thing is not an artifact. It can solve the problems of all software companies when it is implemented. Instead, it is necessary to combine the characteristics and problems of your company to find a set that suits you. model.
We all know that start-up companies need to develop a product that can make money for the company at the beginning. However, most start-up companies can’t make it so easily. Many companies have not yet succeeded in the product capital chain. The company also died. Our company is in such a situation, there is a product line that can maintain the company's expenses and only just enough to make a profit. It is not enough to expand and develop rapidly. There is no point in starting a business if it is maintained for a long time. Another line is to make technological innovations to explore for the development of a popular product in the future, but it cannot be developed on an empty stomach. How do we combine our own characteristics to implement agile development? A problem, a big problem!
Our technical team is configured like this: 1 technical director, 2 senior development engineers, 1 senior development engineer, 2 potential development engineers, 1 front-end developer, and 1 tester. The technical director needs to deal with a lot of team management and customer management work, and can participate in the project for up to one-half of the day. 2 senior developers need to be responsible for mentoring other engineers, and participate in the development of new projects for about 80% of the time. Senior engineers should reserve time for project learning, and participate in the project for about 90% of the time. Potential development engineers need some time to learn technologies and projects, but they can basically devote 70% of their time to projects. Front-end development and testing are revolutionized wherever there is a need, and they belong to the mobile force.
There are now a total of six old projects under maintenance and two new projects to be developed. The maintenance of the six projects requires a total of 4 person-days per week (person-day means it takes 1 person 4 days to complete a task). One of the new projects, "Project 1", has an estimated development time of 120 man-days and will be completed within 1 month. "Project 2" is estimated to take about 40 person-days of development time, and it will take 2 weeks to complete the development. And the current manpower is calculated according to the time that can be invested, the total resources are (1 * 1/2 + 2 * 8/10+1 * 9/10+2 * 7/10) 30 days = 132 man-days, 6 old The project requires 4 person days per week, 4 weeks in a month, 4 * 4 = 16 person days. The resources that can be invested in the project are 132 – 16 = 116 man-days, and a total of 120 + 40 = 160 days are required, which is a full 44 man-days, which seems to be an impossible task.
But in the end, we still used agile development to complete these two projects without affecting the maintenance of the old projects. How do we operate? At the beginning, the two of us developed. At this time, as long as two people can cooperate well to develop the product, no model is needed. With the expansion of personnel, it is necessary to think carefully about how to collaborate among teams to complete tasks on time, with quality and quantity.
Try one, the traditional software development model. The whole process includes requirements analysis, system design, task breakdown planning, development and design, coding, testing, delivery, acceptance, and maintenance. This mode is also the most commonly used mode, but this is what we do when applying it to our company.
As the company started, the boss had an idea, but could not describe the requirements well, so the task of requirements analysis fell on the technical director. System design and task decomposition are initially completed by the technical director, and later senior development engineers can undertake part of it. Development and design can be completed by various development engineers, senior engineers will check, then testers will test, and finally they will be delivered to users for acceptance and technical maintenance. It seems to be a good model. Several products have been developed and some products are delayed and some products are far from the expectations of users. The confidence of the people involved in the project team has been frustrated.
Why would it fail? After thinking about these questions:
1. The technical director is not a product manager and cannot assume responsibility for product design. The boss trusts the technical director to make a good product, so he will do it. But a concept is confused here, product manager and project manager, technical director should play the role of project manager and architect. The project manager controls the project schedule and plan, and the architect grasps the overall technical issues. When the technical director received this task, he had to do it well, which is the responsibility. In the final analysis, the mechanism does not separate product design and project manager, which does not mean that the technical implementer is the product designer. More should let the boss or other business personnel undertake the work of product design.
2. The demand is unstable, and the change after the change is costly . Due to entrepreneurship, the demand will be adjusted frequently in order to adapt to the market, but once adjusted, many development plans will be adjusted accordingly. If some functions are already under development, a lot of work needs to be restarted after adjusting the requirements, which seriously affects the enthusiasm of technical colleagues. It is impossible for businesses not to adjust their needs. They are to meet the requirements of users. Only when users are satisfied can they bring value to the enterprise. However, if the adjustment is too expensive, and a lot of code needs to be rewritten, everyone will blame the technical director or project leader for not grasping the requirements.
3. The team often works overtime, but the combat effectiveness is not strong . The core team is tired of responding to demand, technology development, and maintenance of the old system, and has no time to guide new colleagues to learn technology, and the skills of new colleagues have not been fully utilized for the time being. Work efficiency is low, tasks are often delayed, and there is no sense of accomplishment. The core team has a lot of things to do, there is no time to organize project documents, and new employees are slow to get started without documents. Everyone needs to work overtime to complete a lot of things every day, and they are more tired. Everyone has a lot of things to do besides work, such as going home and watching TV, spending time with family members, reading books and studying, etc. If an employee is allowed to work 24 hours a day, he can agree, and his family may not agree. The development that makes everyone happy is much more efficient than the tired work.
4. The quality of the delivered software is poor, and there is a big gap from user expectations . When starting a business, everyone's ideas are good, go hard and make a product that everyone loves to use. The reality is cruel. For what everyone has worked so hard to make, the boss is not satisfied, the user does not pay the bill, and no one recognizes the effort. The delivered software does not have time to self-test, or the self-testing is insufficient, and handing over to the test is a whole lot of problems. Some companies haven't tested it yet, and go out directly to users, which is quite dangerous. The company handed over in this way not only affects the use of users, but also affects the reputation of the entire company.
It's not that the traditional software development model is not good, it's just that it's not suitable for startups like us. Start to try other models, if you don't have a good system, you can't bring out the maximum productivity of everyone.
Try two, agile development mode . Agile development is a human-centered, iterative, step-by-step development method. Agile methods emphasize people-centricity and focus on delivering software that is valuable to customers. In a highly collaborative development environment, incremental development is carried out in an iterative manner, and feedback is often used for reflection, reflection and summary, and self-adjustment and improvement are constantly carried out.
The main idea of agile development :
One: Individuals and interactions are more valuable than processes and tools
Two: Available software is more valuable than lengthy documentation
Three: Collaboration with customers is more valuable than contract negotiation
Four: Responding to change is more valuable than following a plan
And our previous problems, customer dissatisfaction, delays, and high cost of changing requirements for delivering software, seem to be able to be solved. Such a good model should be tried quickly, first look at a flow chart of agile development.
Simple process of agile development :
1. The product owner designs the entire product into a product backlog. A product backlog is a list of requirements. ( backlog can be understood as a requirement or something to do)
2. Hold a product backlog planning meeting, estimate the time of each backlog, and determine which backlogs need to be completed in the first sprint, that is, the backlog of the sprint. ( Sprint can be understood as a set of tasks developed by a team)
3. Write the backlog of the sprint on a note and paste it on the task wall for everyone to claim the assignment. (The task wall is to post the status of unfinished, in-progress, and completed work on a wall, so that everyone can see the status of the task)
4. Hold a daily standing meeting , and let everyone summarize what they did yesterday at the daily meeting. What happened, what difficulties did you encounter, and what tasks did you carry out today. (Daily stand-up meeting is to discuss with everyone standing in front of the task wall every morning, and the time is controlled within 15 minutes)
5. Draw a burndown chart to ensure that the overview of the task can be clearly seen. (The burndown chart draws the current total number of tasks and the date together, and records it every day, you can see how many tasks are left every day, until the number of tasks is 0, the sprint is completed)
6. The sprint review meeting is when the sprint is completed. Held, to demonstrate their completed software products to customers.
7. The last is the sprint summary meeting , which takes turns to speak, everyone has to speak, summarize the problems encountered in the last sprint, improve and share and discuss with everyone.
我们怎么结合敏捷开发解决现有项目的问题，要记得任何措施都是为了保证按时按质按量把软件交付给用户，不要为了敏捷而教条实施敏捷，公司不能产生商业价值，任何先进的理念或者技术都是无意义的。我们做了这些措施：
1、推广敏捷开发理念。不管是大公司还是小公司强制推行一项制度效果一般都不怎么好。要能推行下去的任何东西一定要大家接受的，才能被认可。
- 首先培养测试小妹学习敏捷开发，后续让她承担部分产品责任人和敏捷指导者的角色，原因有：
a、测试要验收功能，必须理解业务需求。
b、测试也是QA质量体系的一块，学习好了对于软件质量有个更深的认识。
c、团队大部分是男生，女生推广更有亲和力一些。 - 召集所有技术团队开会准备推广。开始和测试小妹好好讨论下，怎么给大家说更有效，更容易接受。她要讲解一定要自己非常清楚敏捷开发，并且准备充分知识点。开会时先指出我们现在问题，让大家看看有什么想法解决问题吗？现在我们做的产品，客户不认可、老板不满意、自己很累没有成就感，有什么办法解决。在大家讨论后，抛出敏捷开发的优势，一般情况下大家都会认可的。大家可能会问到如何执行、落地，可以尝试找一个项目试点，如果实施成功就可以让大家全面推广，不成功也只影响了部分项目。
2、搭建敏捷开发环境。大家要实施敏捷开发，需要比较好的基础条件保证敏捷开发顺利进行。主要几个关键的软件：nexus 搭建仓库依赖中心、maven 管理工程的依赖、jenkins 持续集成和自动编译发布、svn 集中代码管理、jira 记录需求和状态。具体参考《敏捷开发环境搭建》。
3、敏捷项目实施。整个公司建立以业务目标为导向的氛围。就以“项目1”来说，目的是完成这个项目，需要进行这几步：
先根据各自的能力和意向聚集一批完成这个目标的勇士，不管技术和非技术。如果聚集的人不够，技术总监可以根据总体项目的投入机动调整资源以支持，不过条件允许的话还是根据大家意愿来聚集。最终“项目1”召集了一个技术总监、一个资深开发、两个潜力开发、一个前端、一个测试，除去大家做其他事情的时间，总共可以算作4个人。
充分调动客户（老板和业务同事）参与进项目，他们的参与直接决定了项目成功与否。结合之前的经验，如果他们参与不够，最终做出来的东西就不是他们要的，或者离他们要的差距很大。他们刚开始加入的时候，很迷茫有时会表现的比较抗拒，这个时候一定要耐心坚持让大家把第一个sprint开发成功，使大家尝到甜头。让他们全程参与项目也是表示了我们拥抱变化，如果有需求变化，就添加任务到任务墙，大家可以对所有任务的时间有个全面了解，如果超过sprint结束时间就需要业务决策哪些功能不在这个sprint周期加入。
技术总监安排和客户沟通，客户这里指老板和业务。测试小妹负责和客户沟通记录，技术总监辅助。多次沟通后，尝试让测试把需求原型用最简单的工具绘制出来，技术总监审核通过后和客户沟通确认，反复迭代，直到整个需求大家没有异议。很多公司这种需求是有一个专门产品负责人来执行，但按照我们目前的人力是没办法做到的。这里没有让技术总监做主要是为了避免之前出现的问题，过度技术设计产品。
产品设计出来后，召集项目成员分解任务，确定每个任务的时间，可以使用敏捷扑克牌来估计。任务分解尽量控制在1-2天的粒度，这样大家1-2天就可以做出一个能测试的原型，尽早可以集成测试发现问题。一个sprint的任务集合尽量控制在1-2周，不能太长，也不能太短。太长会出现疲劳，太短的sprint会让大家觉得工作太多，做完一个又一个。“项目1”估算结果为120人天，总共投入4个人，需要30天4周时间，我们切成了4个sprint，差不多1个月时间完成，满足业务的时间要求。
分阶段实施sprint，绘制任务墙，划分未开始、已计划、进行中、完成、燃尽图。把要做的sprint任务上墙，贴到未开始的地方。
- 每日站立会议大家认领任务。包括业务任务、开发设计、开发编码、前端设计开发、测试等都是一个个任务，统一管理起来。强调的是一个团体，如果有同事请假，其他同事可以顶上完成任务。站立会议总结昨天的任务是否有问题，对于当前的任务有什么建议，尽量控制在15分钟内，有效会议。这里不会像以前业务或者项目经理追着大家屁股要结果，而是团队驱动，每天大家做的事情都反映在墙上，谁出现了什么状况，大家都会帮他想办法，保证整个项目能够成功。每一个任务完成，由项目执行者把任务从进行中贴到完成区域。再从未分配区域认领新任务贴到进行中的区域。
- 软件开发过程。认领任务后，怎么保证大家开发有质量的代码？团队有资深点的工程师，不需要太多指导，直接可以参与项目的开发。而学习型工程师，需要指导帮助才能一步步做用例、系统分析。技术总监不建议认领太多开发任务，他负责开发团队的概要设计审核，没有审核通过的设计不能开发，并指导大家分析和设计系统。大家都知道，系统思路有了，剩下就是技术实现的过程，只要技能掌握熟练实现基本难度不大。大家可能会问，敏捷开发不是强调软件开发的产品是软件，而不是文档吗？我们这里也不是像传统开发软件一样为了文档而文档，只是让大家把自己的设计思路写下来，只有经过自己仔细设计后才能把思路清晰的写下来。大家写的时候也不需要长篇大论，这样的文档是不欢迎的，受欢迎的文档只需写出用例分析，表设计，复杂的逻辑需要画出流程序列图。
- 结对编程。之前这个编程模式被无数人调侃过，其实也不可能让每一个项目全程都是两个人结对编程。这个不现实也浪费资源。我们的结对是在大家开发一个难点模块时，会给结对的人增加一项任务去配合其他开发一起完成这个任务。其实我们在开发时，很多时候都会结对，比如指导新同事、讨论设计模块，而之前这些都没有算在我们的开发工作量里。
- 项目演示和总结会议。在项目结束后，让所有参与项目的成员都参加，一起演示给客户展示，并解答客户的问题，充分让大家感受到收获的果实。总结会议主要对于这个sprint中大家遇到的问题和经验分享，并为下一个sprint做准备。
经过敏捷实施后，我们的生产力提高了很多，员工的积极性提高了，业务的参与使整体需求把控也很好，大家沟通多了，30天的任务提前了5天完成。我们多出来的时间，让大家每周有一天或者半天研究自己感兴趣的领域，但是这些研究最终必须体现出成果。比如后台开发想研究一个新技术，最后做完需要写个ppt给大家分享下。既能让大家做自己想做的事情，也给大家创造了一个互相学习的氛围。
ps: All modes should not be dogmatic modes, advanced modes are not good modes, and what suits you is the best. To paraphrase a saying: no matter the black cat or the white cat, the good cat is the one who can catch the mouse.
Another exposure of the participating members of Project 1:
Original article, please indicate: reprinted from LANCEYAN.COM
Link to this article: How startups implement agile development