Management Problems and Solutions Tryouts

1. Management Problems and Solutions Tryouts

2. 名言 • 貝律銘 (世界名建築師) • 風格來自解於問題 • 我的名言 • 管理方法來自解決實際的問題 • Each team or company culture has its uniqueness. For example, it is unnecessary to apply CMMI or RUP to a small startup team.

3. Story • You start a project, as a project leader • You got 10 people to work on your project, you have a one-year schedule plan • Some programmers comes and leaves • Some programmers with talent, some do not • You have them work as a team. Most of the time, you communicate with them via meeting and face to face

4. You roughly plot the design • You expect the programmers to work smartly, more importantly, you believeyour programmers understand and remember your idea and hopefully they can smartly transfer your idea into programs. • You think you just need to do the coordinating work, managing resources and monitor the schedule

5. The hard time #1 • When programmers begin to merge and integrate their code. • programmer A said “Oh ! I don’t know I need to write that part !, when did we have a deal?” • The missing pieces of his work delays your project for one month • What is your management solution if you have chance to repeat your project?.

6. Suggested Management Solutions • Every meeting minutes should be recorded (in a system or document) • If there is a task, there is an action item. • Each task and action item must be acknowledge by someone. That is, you need to find a owner. • Action items must be checked periodically • Recap in next meeting • Send notification to the owner • Ask owners to write status reports. • Review the reports and verify the reports.

7. The hard time #2 • When integration begins, programmer B complains to you and to others “We have an agreement (in words) on the interface and specifications, when did program X change that?” • In a lucky case, this won’t cost you much • In a unlucky case, this may cost you weeks to fix the problem What is your management solution if you have chance to repeat your project?.

8. Suggested Management Solutions Design must be written down and reviewed. Strictly following the design is a discipline. (Assume your design team produce effective design) Solution 1: A elite design team is formed (includes experienced programmers, software architect, project managers) to plot the design and module interface. Detailed descriptions should be included in the document so that programmers can begin their work simply by reading the documents. A formal meeting is called to dispatch the work to programmers Solution 2: In the design stage, you want to initiate a series of formal meeting called “work breaking and module interface design meeting”. In the meeting, you want programmers to participate and discuss how to break their work and write down their module interface. In this way, programmers can participate the design. After the meeting, someone good at writing documents should write the meeting minutes into a design document which again solidify the idea and communication in the meeting. The document should be detailed enough so that programmers can program solely by the documents. Any change of the design should be notified to all members and ask all members to acknowledge.

9. The hard time #3 • The integration has been delayed. When you investigate the problem, programmer C complains: “Many bugs were found in programmer X’s module which cost us a lot of time to find it and fix it.” • What is your management solution if you have chance to repeat your project?.

10. Suggested Management Solutions • Solution 1:You lay down a rule. “Before integration testing, each programmer should fully test their module. A test report should be released by the programmer to show how much they have tested their module”Most importantly the reports should be verified by someone. • Implement unit testing (test driven development)

11. The hard time #4 • The integration has been delayed. When you investigate the problem, programmer D complains: “Finding the bugs in whose module takes a lot of time, the progress has been very slow. In addition, fixing the bug causes new bugs in other modules, classes, subsystems” • What is your management solution if you have chance to repeat your project?.

12. Suggested Management Solutionsfor #4 • Enforce incremental testing • Introduce defensive programming • Assert • Log

13. The hard time #5 • The integration has been delayed. When you investigate the problem, programmer E complains: “A serious bug is eventually found but this cost a lot of time. The bug is in programmer Y’s module. His module can do different things when called several times” • What is your management solution if you have chance to repeat your project?.

14. Suggested Management Solutionsfor #5 • Enforce incremental testing • Introduce defensive programming • Assert • Log

15. The hard time #6 • programmer E is in charge of debugging and he complains:“When we trace a bug into programmer X ‘s class. His code is very difficult to read to find the bugs. Eventually, it costs us a lot of time” • What is your management solution if you have chance to repeat your project?.

16. Suggested Management Solutionsfor #6 • Code must be reviewed to prevent bad or poor programming habits, such as using global variables. • Use static analysis tools to scan programmers’ source code to prevent programmers from using dangerous programming • The non-reentrance property is tested by QA team.

17. The hard time #7 • Programmers G complains: “ We follow the design to begin programming. However, we eventually find out the design has serious flaw. Correct the problem and make the design back to the right track involving a lot of refactoring of the developing code” • What is your management solution if you have chance to repeat your project?.

18. Suggested Management Solutionsfor #7 • Design must be reviewed and discussed thoroughly. In best cases, all the members should participate. Remember, fixing a problem is a design document may only need to change a few words. However, it could takes days when the code is written. • Design should be done by elite and experienced members such as architect.

19. The hard time #8 • Programmer H complains: “The specifications are continuously changed during the development. While making progress of the project, we need to go back and fix or makes patches for the changed specifications. Eventually, the architecture is a chaos.” • What is your management solution if you have chance to repeat your project?.

20. Suggested Management Solutionsfor #8 • Every time the specs or design is changed, a review meeting should be held to assess the risk and evaluate whether the previous architecture or design can be changed dramatically. • Once the change is inevitable, make sure the affected personals got the message. • Specifications should be freezed after a critical date to make sure the success of the project.

21. The story continues • You went through all the troubles • You got controlled by the superman • You got controlled by the poor programmers (you know his leave can hurt your project) • You really got hurt by the programmers who leave in the middle of projects

22. Final result • A poor quality product is produced. Bug number is beyond reasonable level • Your product is difficult to maintain. Maintenance tasks are left to rookie programmers because the original developer knows the truth! • Your project delayed • Your project exceeds budge limits • Customer is unhappy • Programmers are sad and ask for transfering to other teams

23. Now, you are again in charge of another project. • 10 new people again is under your supervision • What will you do to avoid the mess of last project?

24. Presumably • Your new project should proceeds much smoothly • Your schedule planning ONLY make sense by controlling and suppress possible 突發事件 in the development as much as possible. These 突發事件 can cause schedule delay and exceed budget limits.

25. How to control and monitoring a software project is also called Software Process

26. What is software process • if I say 製造流程, you should be able to guess what is roughly about • If you want to do software project management, software process is a must-know term. • In manufacturing • process is important to guarantee product quality • QC (Quality Control is a well known discipline in manufacturing)

27. What is a process? • A process is like how to prepare a meal • Cook always describe the process in a recipe • Small difference in recipe or secrete can cook two different meal, although the material are the same

32. Software Processes • DEFINITION：Coherent sets of activities for specifying, designing, implementing and testing software systems • Software processes are hard to apply in general. • You need to modify your process to suit your needs: concerning • Your type of software • 你的軟體當掉會死人還是不會？ • 你的軟體當掉會損失大錢還是不會？ • 你的軟體release 之後立即修改並立即上線的機率？ • Your type of programmers • Your interval of job switch • Your company organization

33. Software Processes • DEFINITION：Coherent sets of activities for specifying, designing, implementing and testing software systems • Software processes are hard to apply in general. • You need to modify your process to suit your needs: concerning • Your type of software • 你的軟體當掉會死人還是不會？ • 你的軟體當掉會損失大錢還是不會？ • 你的軟體release 之後立即修改並立即上線的機率？ • Your type of programmers • Your interval of job switch • Your company organization

34. Software process 光譜 • No process • Chaos – • Project success depends on personal skill and talent of programmers. • Yes, your project may still succeed. • Heavy process – • CMMI,RUP • Suitable for OEM software company • Drawbacks – can easily become do process for process and forget that process is used to help software development. It is not the major body of software process

35. In reality • Programmers hate process because process can limit their creativity and constrain their way of programming • Some of them believe implementing software process means writing non-sense documents to satisfy management bureaucracy • Many programmers believe SE documents are non-sense • Programmers like to 虛應故事 and play fake.

36. It is true • Too much nonsense process can decrease the productivity • Too little process brings chaos • Effective process make project progress slow in the beginning but speed up project progress in the end process process Real work Real work Bad process example Ideal process

37. The suggestion • Choose and develop your own process with minimum efforts but maximum benefits to your projects. • Educate programmers to follow these processes strictly. DISCIPLINE is the word. • Modify, improve, and evaluate process and tools once a product cycle is ended.

38. Process Improvement • Process 最怕的是變成虛應故事變成WOT(waste of time) 反而減低development的效應 • 例如：當有人辛苦的產生設計文件。但是最後卻沒有人看或review。Forexample, 程式人員只有粗略的閱讀甚至瞄一下，而不是當作藍圖般的閱讀。可能的問題是? • Iwouldsay – SOMETHING BIG ISWRONG.

39. Summary • Process needs improvement • Process needs enforcing discipline on programmers (you need to believe it first then to enjoy it – do you believe in god?) • Face with process with honestyand transparency. When it is a WOT, it should be open discussed. • Especially to inexperienced programmers, make sure they understand that they do not see far enough before rejecting any process measures.

40. Standard software process activities • Requirement analysis • The process to understand what customer needs and what features you wanna build • Determine what to build • Specification (Specs) • The process to write requirement and system features into a formal documents. • The documents can be used as contract and the guidelines for programmers. It is the document for testers to decide if a program behaves correctly. • Specifications should be written in a way that is implementation independent

41. Standard software process activities • Analysis and Design • The process to decide how to build the system described by the specs. • Decide what kind of software/hardware technology is used • Architecture design • Module interface design • e.g., Object-oriented analysis and design (OOAD) decide how the program should be implemented by classes. The cooperation of class behaviors constitutes the program eventually.

42. Standard software process activities • Implementation • Also known as coding + debugging • Validation and Verification • The process to assure the quality of code • Maintainability (how program structure react to requirement changes) • Completeness (how program, specification, or design meet user needs) • total correctness (how program react to total inputs) • Readability (how program react to program tracing) • evolvability (how program react to new requirements

43. Testing • The process to assure correctness of program ‘s runtime behaviors (similar to validation) • Maintenanceand software evolution • The process to modify program to answer requirement change

44. Software process model • Now you know the standard activities in the software development. • Suppose you are in charge of a project. • How do you plan to build your systems? • Let’s see some metaphor

45. 1st choice – Ad hoc approach亂無章法 • 蓋一步算一步 • 寫一步算一步 • 適合小程式，家庭作業，學習作業

46. 2nd choice –珍珠養殖 • 灑下一粒砂於貝殼內 • 層層包覆，層層建構 • Incremental approach • Pros: 適合有風險之軟體專案，每一次小心的新增一部份功能到系統中，並確保系統運作正常 • Cons: 一旦發現系統設計有問題，由於每一層的建構是覆蓋在另外一層之上，有邏輯設計等等的依存性。不容易應付 requirement change 與演化。

47. 3rd Choice –植物種植 • 規劃並種下種子之後，讓每個種子自行成長成植物。 • A plan is laid out to construct many subsystems. Let each subsystem grows and form a whole system • Suitable for system with subsystems which barely communicate and interact between each other. • Suitable for system whose requirement and specification are not well known in the beginning • Pros: Only simple planning is needed. • Cons: 每一顆植物可能成長的速度不同，複雜度不同，植物的成長也可能不可預期，開始超出規劃範圍與相鄰的植物有所干擾。

48. 4th choice – mimic building construction • The project is carefully planned • Blue print is produced – analysis and design documents • Suitable for large-scale project and technical risks are not high. • Suitable for systems with clear requirement and specification • Pros: the project can be carefully planned • Cons: lack of flexibility to requirement change in the middle of development.

49. Software process model • What is software process model? • an abstract representation of a process. It presents a description of a process from some particular perspective • 白話 ─ 製造流程的泛用標準模型(generic software process model) • 例如：生產電腦主機板的製造流程可能都包含幾個主要的基本步驟稱之為標準模型。但是每個製造商在生產的時候都會在這個標準模型下自行更改生產流程

50. Well known software process model – waterfall • Waterfall model • First software process model in human history