‫)ﻣﻨﮭﺠﯿﺎت ﺗﻄﻮﯾﺮ اﻟﺒﺮﻣﺠﯿﺎت (‬
‫ھﻧﺎك طرق ﻣﺧﺗﻠﻔﺔ ﻟﺗطوﯾر ﻧظﺎم ﺑرﻣﺟﻲ‪ .‬ﺑﺎﻟﺗﺄﻛﯾد‪ ،‬ﯾﻣﻛﻧك ﻓﻘط اﺟﻠس واﺑدأ ﻓﻲ ﻛﺗﺎﺑﺔ ﺷﻔرة اﻟﻣﺻدر‪ .‬ھذا ﯾﻌﻣل ﺣﺗﻰ ﻻ ﯾﻌﻣل‪.‬‬
‫ﻷي ﺷﻲء أﻛﺛر ﺗﻌﻘﯾدا ﻣن ﺗطﺑﯾق ‪ ،Hello World‬ﺳﺗﺣﺗﺎج إﻟﻰ طرﯾﻘﺔ ﻟﺗﻧظﯾم ﻋﻣﻠك‪ .‬وإذا ﻛﻧت ﻻ ﺗﻌﻣل ﺑﻣﻔردك‪ ،‬ﻓﺈن ﻋدم‬
‫وﺟود ﺳﺗؤدي اﻟﻌﻣﻠﯾﺔ اﻟﻣﺣددة ﺟﯾدا )ﺑﺷﻛل ﻣﻌﻘول( إﻟﻰ اﻟﻔوﺿﻰ‪.‬‬
‫ﻧظرا ﻟﺗﻌﻘﯾد اﻟﻣﺷروع وﻋدد اﻷﺷﺧﺎص اﻟﻣﻌﻧﯾﯾن ﺗزداد‪ ،‬وﺗﺻﺑﺢ اﻟﺣﺎﺟﺔ إﻟﻰ ﻋﻣﻠﯾﺔ اﻟﺗﻧﻣﯾﺔ أﻛﺛر ﻓﺄﻛﺛر ﺳﺎﺋد)ﻣﻧﺷر(‪.‬‬
‫ﺗم اﺧﺗراع أﺳﺎﻟﯾب ﻣﺧﺗﻠﻔﺔ‪ .‬ﺳﻧﺗﺣدث ﻋن اﺛﻧﯾن ﻣن ﻣﻧﮭﺟﯾﺎت اﻟﺗﻧﻣﯾﺔ اﻷﻛﺛر ﺷﻌﺑﯾﺔ‪ ،‬وھﻲ‪:‬‬
‫ﻧﻣوذج اﻟﺷﻼل‪ ،‬اﻟذي ﯾﺗطﻠب ﻣﻧك أن ﯾﻛون ﻟدﯾك ﺧطﺔ ﻣﻔﺻﻠﺔ ﻗﺑل اﺑدأ أي ﺗرﻣﯾز‪ .‬ﯾﺟب إﺻﻼح اﻟﻣﺗطﻠﺑﺎت‪ ،‬ﻟذﻟك ﻻ ﺗوﺟد‬
‫ﺗﻐﯾﯾرات ﻣن اﻟﻣﺗوﻗﻊ أﺛﻧﺎء اﻟﺗطوﯾر‪.‬‬
‫ﻧﮭﺞ ‪ Agile‬اﻟﺻدﯾق ﻟﻠﺗﻐﯾﯾر واﻟﻣﺗﺟﺎوب‪ ،‬واﻟذي ﯾﻌﻣل ﺑﺷﻛل راﺋﻊ ﻣن أﺟل اﻟﻣﺷﺎرﯾﻊ اﻟﺗﻲ ﯾﻣﻛن أن ﺗﺗﻐﯾر ﻓﯾﮭﺎ اﻟﺗوﻗﻌﺎت‬
‫ﺑﺳرﻋﺔ وﺑﺷﻛل ﻣﺗﻛرر‪.‬‬
‫ﻗﺑل أن ﻧﺗﻌﻣق ﻓﻲ ھذه اﻟﻣﻧﮭﺟﯾﺎت‪ ،‬ﯾﺟب أن أﺧﺑرك ﺑﺷﻲء واﺣد‪:‬‬
‫وأﺳس اﻟﺗﺻﻣﯾم اﻟﻣوﺟﮭﺔ ﻟﻠﻛﺎﺋﻧﺎت ‪UML‬‬
‫ﻻ ﯾﻣﻛن ﻷي ﻣن ھذه اﻷﻧظﻣﺔ أن ﯾﺻف ﺑدﻗﺔ ﻛل ﺧطوة ﻣن ﺧطوات اﻟﺑرﻧﺎﻣﺞ ﻋﻣﻠﯾﺔ اﻟﺗطوﯾر‪.‬‬
‫ﻟﻛﻧﻧﺎ ﻧﺣﺗﺎﺟﮭم ﺑﺎﻟﺗﺄﻛﯾد ﻟﻣزاﻣﻧﺔ وﺗﻧظﯾم اﻷﻧﺷطﺔ اﻟﻣﺗﻌﻠﻘﺔ ﺑﺎﻟﺗﻧﻣﯾﺔ؛ اﻷﻧﺷطﺔ اﻟﺗﻲ ﻻ ﺗﺷﻣل اﻟﺗرﻣﯾز ﻓﺣﺳب‪،‬‬
‫ﺑل ﺗﺷﻣل أﯾﺿﺎ اﻟﺗﺻﻣﯾم وإدارة اﻟﻣﻧﺗﺟﺎت واﻟﻣﯾزﻧﺔ واﻻﺧﺗﺑﺎر واﻟﺗوﺛﯾق‪ ،‬اﻹﻓراج واﻟﺻﯾﺎﻧﺔ‪.‬‬
‫)ﻧﻤﻮذج اﻟﺸﻼل(‬
‫اﻟﺷﻼل ھو ﻧﻣوذج ﺧطﻲ‪ .‬إﻧﮫ ﯾﺣدد ﺧطوات أو ﻣراﺣل اﻟﺗطوﯾر‪ .‬ﺗﺑدأ ﻓﻲ ﺗﻧﻔﯾذ ﺧطوة واﺣدة‪ ،‬وأﻛﻣﻠﮭﺎ ﺛم ﺗﺑدأ اﻟﺧطوة اﻟﺗﺎﻟﯾﺔ‪.‬‬
‫ﯾﻣﻧﺣﻧﺎ ھذا اﻟﻧﮭﺞ ﻧظﺎﻣﺎ ﺛﺎﺑﺗﺎ وﻧزوﻟﯾﺎ ً‪ .‬وﻣن ھﻧﺎ ﺟﺎء اﻻﺳم ﺷﻼل‪.‬‬
‫ﺗﺗدﻓق ﻋﻣﻠﯾﺔ اﻟﺗﻧﻣﯾﺔ ﻓﻲ اﻟﺷﻼﻻت‪ .‬ﻛل ﻣرﺣﻠﺔ ﻣن ﻣراﺣل اﻟﺗطوﯾر ﯾﺗطﻠب إﻛﻣﺎل اﻟﺳﺎﺑق ‪ .‬دﻋﻧﺎ ﻧﺗﺣدث ﻗﻠﯾﻼ ﻋن ھؤﻻء‬
‫اﻟﻣراﺣل‪.‬‬
‫أوﻻ‪ ،‬ﻧﻘوم ﺑﺟﻣﻊ وﺗﺣﻠﯾل اﻟﻣﺗطﻠﺑﺎت‪ .‬اﻟﻣﺗوﻗﻊ ﻣن ذﻟك ﯾﺟب ﺗوﺿﯾﺢ وظﺎﺋف اﻟﺗطﺑﯾق اﻟﻣﺳﺗﻘﺑﻠﻲ ﺑﺎﺳﺗﺧدام أﺻﺣﺎب اﻟﻣﺻﻠﺣﺔ‪ .‬ﯾﺟب ﺗوﺛﯾق‬
‫ﺟﻣﯾﻊ اﻟﺗﻔﺎﺻﯾل ﺑدﻗﺔ‪ .‬ھذا ﺟدا رﺑﻣﺎ ﺗﻛون اﻟﻣرﺣﻠﺔ اﻷوﻟﻰ ھﻲ اﻷﻛﺛر أھﻣﯾﺔ‪ .‬ﻋﻧدﻣﺎ ﯾﺗم ذﻟك ﺑﺷﻛل ﺻﺣﯾﺢ‪ ،‬ﺳﯾؤدي ﻧﻣوذج اﻟﺷﻼل إﻟﻰ‬
‫اﻟﻧﺗﯾﺟﺔ اﻟﻣﺗوﻗﻌﺔ‪.‬‬
‫ﺑﻌد ﺟﻣﻊ وﺗﺣﻠﯾل اﻟﻣﺗطﻠﺑﺎت‪ ،‬ﯾﻣﻛﻧﻧﺎ اﻟﻣﺗﺎﺑﻌﺔ إﻟﻰ اﻟﻣرﺣﻠﺔ اﻟﺗﺎﻟﯾﺔ‪ .‬إﻟﯾك اﻟﻣﻛﺎن اﻟذي ﻧﺣدد ﻓﯾﮫ اﻟﺗﺻﻣﯾم اﻟﻌﺎم ﻟﺑرﻧﺎﻣﺟﻧﺎ‪ .‬ﯾﺷﺑﮫ‬
‫ﺗﻌرﯾف اﻟﮭﻧدﺳﺔ اﻟﻣﻌﻣﺎرﯾﺔ إﻧﺷﺎء ﻣﺧطط ﻟﻠﻣﺑﻧﻰ‪ .‬وﺑﺎﻟﺗﺎﻟﻲ‪ ،‬ﯾﺟب أن ﯾﻛون اﻟﺗﺻﻣﯾم واﺿﺣﺎ وﻣﻔﺻﻼ ﻗدر اﻹﻣﻛﺎن‪ .‬اﻟﺧﻼﺻﺔ‬
‫اﻟﻘول ھﻲ‪ :‬ﯾﺟب أن ﯾﻛون اﻟﻔرﯾق ﻗﺎدرا ﻋﻠﻰ ﺗﻧﻔﯾذ اﻟﻣﻧﺗﺞ ﺑﻧﺎء ﻋﻠﻰ ھذه اﻟﺧطﺔ‪ .‬ﯾﺟب أن ﻧﺗﻧﺎول أﺳﺋﻠﺔ ﻣﺛل‪:‬‬
‫ﻣﺎھﻲ اﻟﺤﺰم او اﻟﻤﻜﻮﻧﺎت اﻟﺘﻲ ﺳﺘﺸﻜﻞ ﻧﻈﺎﻣﻨﺎ؟‬
‫ﻣﺎھﻲ اﻷﻧﻮاع اﻷﺳﺎﺳﯿﺔ ﻟﻜﻞ ﻣﻜﻮن؟‬
‫ﻛﯿﻒ ﺗﺘﻔﺎﻋﻞ ھﺬه اﻷﻧﻮاع ﻣﻊ ﺑﻌﻀﮭﺎ اﻟﺒﻌﺾ ﻟﺘﺤﻘﯿﻖ اﻟﻮظﺎﺋﻒ اﻟﻤﻄﻠﻮﺑﺔ ؟‬
‫ھﻞ ﺑﺮﻧﺎﻣﺠﻨﺎ أﻣﻦ؟ ﻣﺎذا ﻋﻦ اﻷداء؟‬
‫ﻛﯿﻒ ﯾﺴﺘﺠﯿﺐ ﺑﺮﻧﺎﻣﺠﻨﺎ ﻟﻸﺧﻄﺎء؟ ﻛﯿﻒ ﻧﻌﺎﻣﻞ ﺣﺎﻻت اﻟﺤﺎﻓﺔ ؟‬
‫ھﻞ ﯾﺠﺐ ان ﻧﻮﺳﻊ ﻧﻈﺎﻣﻨﺎ ﻓﻲ اﻟﻤﺴﺘﻘﺒﻞ ؟‬
‫ﻣﺎھﻲ ﺗﻮاطﺆات اﻟﻄﺮف اﻟﺜﺎﻟﺚ اﻟﺘﻲ ﻧﺴﺘﺨﺪﻣﮭﺎ؟‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫•‬
‫‪UML‬‬
‫اﻟﻤﻮﺟﮭﺔ ﻟﻠﻜﺎﺋﻨﺎت وأﺳﺲ اﻟﺘﺼﻤﯿﻢ‬
‫ﯾﻣﻛن أن ﺗﻧﻣو اﻟﻘﺎﺋﻣﺔ أو ﺗﺗﻘﻠص اﻋﺗﻣﺎدا ﻋﻠﻰ اﻟﻣﺗطﻠﺑﺎت اﻟﺗﻲ ﺣددﻧﺎھﺎ ﻓﻲ اﻟﻣرﺣﻠﺔ اﻟﺳﺎﺑﻘﺔ‪.‬‬
‫اﻟﺗﻧﻔﯾذ ﯾﺄﺗﻲ ﺑﻌد ذﻟك‪ .‬ﻣرﺣﻠﺔ ﺗطوﯾر اﻟﺑرﻣﺟﯾﺎت ھﻲ ﻋﺎدة ﻣﺎ ﺗﻧﻘﺳم إﻟﻰ وﺣدات أﺻﻐر‪ .‬ﺛم ﯾﺗم ﺗﻧﻔﯾذ ﻛل وﺣدة واﺧﺗﺑﺎرھﺎ ﻣن‬
‫ﻗﺑل اﻟﻣطورﯾن‪.‬‬
‫ﺑﻣﺟرد اﻻﻧﺗﮭﺎء ﻣن ﻣرﺣﻠﺔ اﻟﺗطوﯾر‪ ،‬ﯾﺧﺿﻊ اﻟﻣﻧﺗﺞ ﻟﻣرﺣﻠﺔ اﻟﺗﺣﻘق‪ .‬ﺧﻼل ھذه اﻟﺧطوة‪ ،‬ﯾﺗم ﺗﻘﯾﯾم اﻟﺑرﻧﺎﻣﺞ ﺑﻧﺎء ﻋﻠﻰ ﻣﻌﺎﯾﯾر‬
‫ﻣﺣددة ﻣﺳﺑﻘﺎ‪ .‬ﯾﺟب أن ﻧﺗﺣﻘق ﻣﻣﺎ إذا ﻛﺎن اﻟﻣﻧﺗﺞ ﯾوﻓر اﻟوظﺎﺋف اﻟﺗﻲ اﺗﻔﻘﻧﺎ ﻋﻠﯾﮭﺎ‪.‬‬
‫ﯾﺗم إﺟراء اﻻﺧﺗﺑﺎرات ﻟﻠﺗﺄﻛد ﻣن أن اﻟﺑرﻧﺎﻣﺞ ﯾﻌﻣل ﻛﻣﺎ ھو ﻣﺗوﻗﻊ‪ .‬ﻧﺣن ﻧﺧﺗﺑر ﻟﻠﻣﺷﻛﻼت اﻟوظﯾﻔﯾﺔ واﻷداء واﻷﻣﺎن وﺳﮭوﻟﺔ‬
‫اﻻﺳﺗﺧدام‪ .‬ﺗم اﻛﺗﺷﺎﻓﮫ ﯾﺗم ﺗﺳﺟﯾل اﻟﻣﺷﺎﻛل وإﺻﻼﺣﮭﺎ‪ .‬ﺗﺳﺗﻣر اﻟﻌﻣﻠﯾﺔ ﺣﺗﻰ ﻛل اﻷﺧطﺎء اﻟﺷدﯾدة ﺗم إﺻﻼﺣﮭﺎ‪.‬‬
‫ﻗد ﺗؤدي ﻣرﺣﻠﺔ اﻟﺗﺣﻘق أﯾﺿﺎ إﻟﻰ ظﮭور أﺧطﺎء أﻋﻣق وﺣرﺟﺔ اﻟﻘﺿﺎﯾﺎ اﻟﺗﻲ ﻗد ﺗؤﺛر ﻋﻠﻰ اﻹﻓراج اﻟﻣﺧطط ﻟﮫ‪.‬‬
‫ﺑﻣﺟرد اﻛﺗﻣﺎل ﻣرﺣﻠﺔ اﻻﺧﺗﺑﺎر وﺗﺳﻠﯾم اﻹﺻدار اﻟﻣﺣدد‪ ،‬ﯾدﺧل اﻟﺑرﻧﺎﻣﺞ ﻣرﺣﻠﺔ اﻟﺻﯾﺎﻧﺔ‪ .‬ﺑﺣﻛم اﻟﺗﻌرﯾف‪ ،‬ﺗﺗﻌﻠق ﻣرﺣﻠﺔ‬
‫اﻟﺻﯾﺎﻧﺔ ﺑﺈﺻﻼح اﻷﺧطﺎء اﻟﺻﻐﯾرة‪ .‬ﻟﻛن ﻓﻲ أﻛﺛر اﻷﺣﯾﺎن‪ ،‬إﻧﮫ ﻗد ﺗﺷﻣل أﯾﺿﺎ ﺗﺣﺳﯾﻧﺎت وظﯾﻔﯾﺔ‪.‬‬
‫ﻗد ﯾﺄﺗﻲ اﻟﻌﻣﯾل ﺑﻣﺗطﻠﺑﺎت ﺟدﯾدة ﺗﻧطوي ﻋﻠﻰ ﻣﺗطﻠﺑﺎت ﻛﺑﯾرة اﻟﺗﻐﯾﯾرات‪ .‬ﻗد ﺗﺷﻌر ﺑﺎﻹﻏراء ﻟﻠﺿﻐط ﻓﻲ "رﻗﻌﺔ واﺣدة أﺧرى‬
‫ﻓﻘط" ﻓﻲ ﻣرﺣﻠﺔ اﻟﺻﯾﺎﻧﺔ‪ .‬ﻋﺎدة ﻣﺎ ﺗﻛون ھذه ﻓﻛرة ﺳﯾﺋﺔ‪ .‬ﻓﻲ ھذه اﻟﺣﺎﻟﺔ‪ ،‬ﻧﺣﺗﺎج إﻟﻰ وﺿﻊ ﻗم ﺑﻣﺷروع ﺷﻼل ﺟدﯾد وﻛرر ﻛل‬
‫اﻟﺧطوات‪.‬‬
‫ﯾوﺿﺢ اﻟﺷﻛل اﻟﺗﺎﻟﻲ ﻣراﺣل ﻧﻣوذج اﻟﺷﻼل‪:‬‬
‫ﯾﺳﺗﺧدم ﻧﻣوذج اﻟﺷﻼل ﻟﻠﺳﯾطرة ﻋﻠﻰ اﻟﺣﯾﺎة واﻷﻧظﻣﺔ اﻟطﺑﯾﺔ واﻟﻌﺳﻛرﯾﺔ‪ .‬ﯾﺗطﻠب ﻣﻧﺎ ھذا اﻟﻧﻣوذج ﺗوﺿﯾﺢ ﺟﻣﯾﻊ اﻟﻣﺗطﻠﺑﺎت‬
‫وإﻧﺷﺎء ﻣﻔﺻل ﺧطط ﻣﻘدﻣﺎ‪.‬‬
‫اﻟﺷﻼل ھو اﻟﺧﯾﺎر اﻷﻣﺛل إذا ﺗم ﺗﺣدﯾد ﺟﻣﯾﻊ اﻟﻣﺗطﻠﺑﺎت ﺑدﻗﺔ وﻟن ﯾﺗﻐﯾر ﺑﻣرور اﻟوﻗت‪ .‬ﺗﻠﻘﻰ اﻟﺷﻼل ﺑﻌض اﻻﻧﺗﻘﺎدات ﺑﺳﺑب‬
‫ﻋدم ﻗدرﺗﮭﺎ ﻋﻠﻰ اﻻﺳﺗﺟﺎﺑﺔ ﻟﻠﺗﻐﯾرات‪ .‬ﻧظرا ﻟﮭﯾﻛﻠﮫ اﻟﺧطﻲ‪ ،‬اﻟﺟدﯾد ﻻ ﯾﻣﻛن اﻟﻧظر ﻓﻲ اﻟﻣﺗطﻠﺑﺎت ﻓﻲ اﻟﻣراﺣل اﻟﻼﺣﻘﺔ ﻣن‬
‫اﻟﺗطوﯾر ﻋﻣﻠﯾﺔ‪.‬‬
‫إذا ﻏﯾر اﻟﻌﻣﯾل رأﯾﮫ ﺑﺷﻛل ﻣﺗﻛرر‪ ،‬أو ﻓﻘد ﺗﺻﻣﯾﻣﻧﺎ ﺿرورﯾﺎ اﻟﺟواﻧب‪ ،‬ﺳﻧواﺟﮫ ﻣﺷﺎﻛل أﺛﻧﺎء اﻟﺗطوﯾر أو اﻻﺧﺗﺑﺎر‪ .‬ﻓﻲ ﻣﺛل‬
‫ھذا ﻓﻲ اﻟﺣﺎﻻت‪ ،‬ﯾﺟب أن ﻧﺗﺑﻊ ﻧﮭﺟﺎ ﻣﺧﺗﻠﻔﺎ‪.‬‬
‫‪ Agile‬ھو ﻧﮭﺞ ﺟدﯾد ﻧﺳﺑﯾﺎ ﻹدارة ﻣﺷﺎرﯾﻊ اﻟﺑرﻣﺟﯾﺎت‪ .‬ﻛل ﺷﻲء ﺑدأت ﺑﺎﻟﺑﯾﺎن اﻟرﺷﯾق ﻓﻲ ﻋﺎم ‪ .2001‬ﻛﺎن ھذا اﻟﺑﯾﺎن ﻣﺣﺎوﻟﺔ لإﻧﮭﺎء‬
‫اﻧﺗﺷﺎر اﻟﻣﻧﮭﺟﯾﺎت اﻟﺗﻲ ﺗطورت‬
‫ﯾﺤﺪد اﻟﺒﯿﺎن‬
‫اﻟﺮﺷﯿﻖ أرﺑﻊ ﻗﯿﻢ‪:‬‬
‫اﻷﻓراد واﻟﺗﻔﺎﻋﻼت ﺣول اﻟﻌﻣﻠﯾﺎت واﻷدوات‬
‫•‬
‫ھذا ﻻ ﯾﻌﻧﻲ أﻧﻧﺎ ﻟن ﻧﺳﺗﺧدم اﻟﻌﻣﻠﯾﺎت واﻷدوات ﺑطرﯾﻘﺔ رﺷﯾﻘﺔ ﻣﺷﺎرﯾﻊ‪ .‬ﻣﺎ زﻟﻧﺎ ﺑﺣﺎﺟﺔ إﻟﻰ أدوات وﻋﻣﻠﯾﺎت‪ ،‬وﻟﻛن ﻻ ﯾﻧﺑﻐﻲ‬
‫ﻟﮭم ذﻟك ﯾﻣﻧﻌﻧﺎ ﻣن ﺗﻧﻔﯾذ اﻟﻣﯾزات أو اﻟﺗﻐﯾﯾرات اﻟﻣطﻠوﺑﺔ‪ .‬ﺑدﻻ ﻣن إﺟﺑﺎر اﻟﻧﺎس ﻋﻠﻰ اﺗﺑﺎع ﻋﻣﻠﯾﺔ ﺟﺎﻣدة‪ ،‬ﻧﺣن ﺗﻧﻔﯾذ ﻋﻣﻠﯾﺔ‬
‫ﻗﺎﺑﻠﺔ ﻟﻠﺗﻛﯾف وﺗﺳﺗﺟﯾب ﻟﻠﺗﻐﯾﯾرات‬
‫• ﺑرﻧﺎﻣﺞ اﻟﻌﻣل ﻋﻠﻰ اﻟوﺛﺎﺋق اﻟﺷﺎﻣﻠﺔ‬
‫ھذا ﻻ ﯾﻌﻧﻲ أن اﻟﻣﺷﺎرﯾﻊ اﻟرﺷﯾﻘﺔ ﻻ ﺗﺳﺗﺧدم اﻟوﺛﺎﺋق ﻓﻲ ﻛل ﺷﻲء‪ .‬ﯾﺟب أن ﻧﻧﺷﺊ وﺛﺎﺋق‬
‫ﺣﯾث ﺗوﻓر ﻗﯾﻣﺔ‪ .‬ﻟﯾﺳت ھﻧﺎك ﺣﺎﺟﺔ ﻹﻧﺷﺎء وﺛﺎﺋق ﺷﺎﻣﻠﺔ ﻓﻘط ﻣن أﺟل ﻣن أﺟل ذﻟك‪.‬‬
‫•‬
‫ﺗﻌﺎون اﻟﻌﻣﻼء ﺑﺷﺄن اﻟﺗﻔﺎوض ﻋﻠﻰ اﻟﻌﻘود‬
‫ﻻ ﺗﻔﮭم ھذا اﻟﺧطﺄ أﯾﺿﺎ‪ .‬ﺗﺗطﻠب اﻟﻣﺷﺎرﯾﻊ اﻟرﺷﯾﻘﺔ أﯾﺿﺎ ﻋﻘودا ﻹدارة ﺗوﻗﻌﺎت اﻟﻌﻣﻼء ﺑﺷﺄن اﻟﺗﻛﺎﻟﯾف واﻟﺟداول اﻟزﻣﻧﯾﺔ‪.‬‬
‫وﻣﻊ ذﻟك‪ ،‬ﻋﻠﻰ ﻋﻛس اﻟﻣﺷﺎرﯾﻊ اﻟﻘﺎﺋﻣﺔ ﻋﻠﻰ اﻟﺧطﺔ‪ ،‬ھﻧﺎك روح اﻟﺷراﻛﺔ ﺑﯾن ﻓرﯾق اﻟﺗطوﯾر واﻟﻌﻣﯾل‪ .‬ﺑﺳﺑب اﻟطﺑﯾﻌﺔ ﻏﯾر‬
‫ﻣؤﻛدة إﻟﻰ ﺣد ﻣﺎ ﻟﻠﻣﺷﺎرﯾﻊ اﻟرﺷﯾﻘﺔ‪ ،‬ﻛﻼ اﻟطرﻓﯾن أﻗر ﺑﺄن ﺑﻌض اﻟﻣﺗطﻠﺑﺎت واﻟﺗﻔﺎﺻﯾل ﻗد ﺗﺣﺗﺎج إﻟﻰ إﻋﺎدة ﺗﻌرﯾﻔﮭﺎ أو‬
‫ﺗوﺿﯾﺣﮭﺎ ﺑﺷﻛل أﻛﺑر ﻣﻊ ﺗﻘدم اﻟﻣﺷروع‪ .‬ﺗﻘﻧﯾﺔ اﻟﻣﻌﻠوﻣﺎت وﻏﻧﻲ ﻋن اﻟﻘول أن ھذا اﻟﻧوع ﻣن اﻟﺷراﻛﺔ ﯾﺗطﻠب اﻟﺗﻌﺎون واﻟﺛﻘﺔ‪.‬‬
‫اﻻﺳﺗﺟﺎﺑﺔ ﻟﻠﺗﻐﯾﯾر ﻋﻠﻰ اﺗﺑﺎع ﺧطﺔ‬
‫ﺗﺧﺗﻠف ‪ Agile‬ﻋن اﻟﻧﮭﺞ اﻟﻘﺎﺋﻣﺔ ﻋﻠﻰ اﻟﺧطﺔ وﺗوﻓر اﻟﻣزﯾد اﻟﻣروﻧﺔ ﻣﻘﺎرﻧﺔ ﺑﻧﻣوذج اﻟﺷﻼل‪ .‬اﻟﻔرق اﻟرﺋﯾﺳﻲ ھل ﺗرﺣب‬
‫اﻟرﺷﯾﻘﺔ ﺑﺎﻟﺗﻐﯾﯾرات ﺣﺗﻰ ﻓﻲ اﻟﻣراﺣل اﻟﻼﺣﻘﺔ ﻣن دورة اﻟﺗﻧﻣﯾﺔ‪ .‬ﺑﻌض اﻟﺗﺧطﯾط ﻣطﻠوب أﯾﺿﺎ ﻟﻠرﺷﯾﻘﺔ‬
‫•‬
‫اﻟﻣﺷروع ﺑﺄﻛﻣﻠﮫ ﻗﺑل اﻟﺑدء ﻓﻲ أي أﻧﺷطﺔ ﺗﻧﻣوﯾﺔ‪ .‬ﻧﺗﯾﺟﺔ ﻟذﻟك‪ ،‬ﻟن ﯾﺗم ﺣظرﻧﺎ ﺣﺗﻰ ﺟﻣﯾﻊ اﻟﻣﺗطﻠﺑﺎت ﯾﺗم ﺗوﺿﯾﺣﮭﺎ وﯾﺗم‬
‫اﻹﺟﺎﺑﺔ ﻋﻠﻰ ﻛل ﺳؤال‪.‬‬
‫اﻵن دﻋوﻧﺎ ﻧﺗﺣدث ﻋن ﻛﯾﻔﯾﺔ ﺣل ﻧﮭﺞ رﺷﯾق ﻟﻠﻣﺷﻛﻠﺔ اﻟﺗﻲ رأﯾﻧﺎھﺎ ﻣﻊ اﻟﺷﻼل‬
‫اﻟﻔﻛرة اﻟرﺋﯾﺳﯾﺔ وراء ‪ Agile‬ھﻲ أﻧﮫ ﯾﻣﻛﻧﻧﺎ ﺗوﻓﯾر ﺑراﻣﺞ وظﯾﻔﯾﺔ ﺑﺷﻛل ﻣﺗﻛرر ﺑدﻻ ﻣن ﺗﺳﻠﯾم اﻟﻣﺷروع ﺑﺄﻛﻣﻠﮫ دﻓﻌﺔ واﺣدة‪.‬‬
‫اﻟﻌﻣل ﯾﺗم ﺗﻘﺳﯾﻣﮭﺎ إﻟﻰ ﻗطﻊ أﻗﺻر ﺗﺳﻣﻰ ﺳﺑﺎﻗﺎت اﻟﺳرﻋﺔ‪.‬‬
‫ﻋﺎدة ﻣﺎ ﯾﻛون طول ﺳﺑرﯾﻧت ﻣن أﺳﺑوﻋﯾن إﻟﻰ أرﺑﻌﺔ أﺳﺎﺑﯾﻊ‪ .‬ﻓﻲ ﻧﮭﺎﯾﺔ ﻛل ﺳﺑﺎق‪ ،‬ﯾﺟب ﻋﻠﻰ اﻟﻔرﯾق ﺗﻘدﯾم ﻧﺳﺧﺔ‬
‫ﺗﺣﺳﻧت ﻋن اﻟﻧﺳﺧﺔ اﻟﺳﺎﺑﻘﺔ ﻧﺗﯾﺟﺔ اﻟﻌدو‪.‬‬
‫ﯾوﻓر ھذا اﻟﻧﮭﺞ اﻟﺗﻔﺎﻋﻠﻲ ﻓرﺻﺔ ﻟﻠﻣراﺟﻌﺔ ﺑﺷﻛل ﻣﺗﻛرراﻟﻣﻧﺗﺞ اﻟذي ﯾﺗم ﺗطوﯾره‪ .‬ﻟدى أﺻﺣﺎب اﻟﻣﺻﻠﺣﺔ ﻓرﺻﺔ ﻟﺗﻘﯾﯾم‬
‫اﻟﺑرﻧﺎﻣﺞ وﺗﻘدﯾم ﻣﻼﺣظﺎﺗﮭم ﻓﻲ وﻗت ﻣﺑﻛر ﺑدﻻ ﻣن ﻓﻲ اﻧﺗظﺎر ﺗﺳﻠﯾم اﻟﻣﻧﺗﺞ اﻟﻧﮭﺎﺋﻲ‪ .‬ﻧﻘﺎط اﻟﺗﻔﺗﯾش اﻟﻣﺗﻛررة ھذه إﻧﮭﺎ ﻣﻔﯾدة‬
‫ﻟﻠﻐﺎﯾﺔ ﻷﻧﮭﺎ ﺗﺿﻣن ﺗطور اﻟﻣﺷروع ﻓﻲ اﻟﯾﻣﯾن اﻻﺗﺟﺎه‪.‬‬
‫ﻋﻠﻰ ﻋﻛس اﻟﺷﻼل‪ ،‬ﻻ ﺗﻔﺻل اﻟﻣﻧﮭﺟﯾﺎت اﻟرﺷﯾﻘﺔ اﻻﺧﺗﺑﺎر ﻋن اﻟﺗﻧﻣﯾﺔ‪ .‬ﯾﺗم دﻣﺞ اﻻﺧﺗﺑﺎر ﺑﺈﺣﻛﺎم ﻣﻊ اﻟﺗطوﯾر و‬
‫ﯾﺗﺣﻣل اﻟﻔرﯾق ﺑﺄﻛﻣﻠﮫ ﻣﺳؤوﻟﯾﺔ ﺟودة اﻟﻣﻧﺗﺞ‪ .‬أﯾﺿﺎ إن إﺷراك ﻣﺳﺗﺧدﻣﻲ‬
‫اﻷﻋﻣﺎل ﻓﻲ ﻋﻣﻠﯾﺔ اﻟﺗطوﯾر ﯾﻘف ﻓﻲ ﺟوھر اﻟﻧﮭﺞ اﻟرﺷﯾﻘﺔ‪.‬‬
‫ھﻧﺎك ﻋﻼﻗﺔ ﻗوﯾﺔ ﺑﯾن ﻓرﯾق اﻟﻣﺷروع وأﺻﺣﺎب اﻟﻣﺻﻠﺣﺔ وﻣﺳﺗﺧدﻣو اﻷﻋﻣﺎل‪ .‬ﯾﻌﻣل ھذا‬
‫اﻟﻧﻣوذج ﺑﺷﻛل أﻓﺿل ﻓﻲ اﻟﻣواﻗف ﺣﯾث ﻻ ﯾﻣﻛن ﺗﺣدﯾد اﻟﻣﺗطﻠﺑﺎت ﻣﻘدﻣﺎ‪.‬‬
‫رﺷﯾﻘﺔ ﻣﻧﺎﺳﺑﺔ ﺗﻣﺎﻣﺎ ﻟﻣﺷﺎرﯾﻊ اﻟﺑرﻣﺟﯾﺎت اﻟﺗﻲ ﺗﻌﺗﻣد ﻋﻠﻰ اﻟﻌدﯾد ﻣﻧﮭﺎ ﻣن اﻟﻣﺗوﻗﻊ ﺣدوث ﻋواﻣل وﺗﻐﯾﯾرات ﻏﯾر ﻣؤﻛدة‪.‬‬
‫واﺣدة ﻣن اﻟﻔواﺋد اﻟﻛﺑﯾرة ﻟﮭذا اﻟﻧﻣوذج اﻟﺗﻌﺎوﻧﻲ ھﻲ أﻧﮫ ﻋﺎدة ﻣﺎ ﯾؤدي إﻟﻰ ﻟزﯾﺎدة رﺿﺎ اﻟﻌﻣﻼء‪ .‬ﻣن اﻟﻣرﺟﺢ أﯾﺿﺎ أن ﯾﻛون‬
‫أﻋﺿﺎء اﻟﻔرﯾق أﻛﺛر ﺑداﻓﻊ ﻣن إﺷراك اﻟﻌﻣﻼء ﻣﺑﺎﺷرة‪.‬‬
‫ﻻﺣظ أن ‪ Agile‬ﻟﯾﺳت ﻣﻧﮭﺟﯾﺔ ﺑل طرﯾﻘﺔ ﺗﻔﻛﯾر ﻣﺣددة ﻣن ﺧﻼل ﻗﯾم وﻣﺑﺎدئ اﻟﺑﯾﺎن اﻟرﺷﯾق‪.‬‬
‫اﻟرﺷﯾﻘﺔ ھﻲ طرﯾﻘﺔ ﻟﻠﺗﻔﻛﯾر‪.‬‬
‫ﻋﺎدة ﻣﺎ ﯾﻧظر إﻟﻰ اﻟﺷﻼل ﻋﻠﻰ أﻧﮫ ﺟﺎﻣد وﺑﯾروﻗراطﻲ ﻣﻘﺎرﻧﺔ ﺑﻣﻧﮭﺟﯾﺎت رﺷﯾﻘﺔ‪ .‬وﻣﻊ ذﻟك‪ ،‬ﻛﻼھﻣﺎ ﻟﮭﻣﺎ‬
‫ﻣﻛﺎﻧﮭما‬
‫ھﻧﺎك ﺣﺎﻻت ﻟن ﺗﻧﺟﺢ ﻓﯾﮭﺎ اﻟﻣﻧﮭﺟﯾﺔ اﻟﻘﺎﺋﻣﺔ ﻋﻠﻰ اﻟﺧطﺔ‪ .‬إذا ﻛﺎن ﻣﺳﺗوى ﻋدم اﻟﯾﻘﯾن ﻣرﺗﻔﻊ وﻻ ﯾﻣﻛن اﻹﺟﺎﺑﺔ ﻋﻠﻰ ﺟﻣﯾﻊ‬
‫اﻷﺳﺋﻠﺔ ﺑﺷﻛل ﺻﺣﯾﺢ ﺑﻌﯾدا‪ ،‬رﺑﻣﺎ ﯾﺟب ﻋﻠﯾك اﺧﺗﯾﺎر ﻣﻧﮭﺟﯾﺔ رﺷﯾﻘﺔ‪ .‬ﻟﻶﺧرﯾن اﻟﻣﺷﺎرﯾﻊ‪ ،‬ﺳﯾﻛون اﻟﻧﮭﺞ اﻟﺷﺑﯾﮫ ﺑﺎﻟﺷﻼل‬
‫ﻣﻧﺎﺳﺑﺎ ﺑﺷﻛل أﻓﺿل‪.‬‬
‫دﻋﻧﻲ أﻋطﯾك ﺑﻌض اﻷﻣﺛﻠﺔ‪.‬‬
‫ﻋﻧد ﺗطوﯾر ﻧظﺎم ﻟﻣراﻗﺑﺔ اﻷﺳﻠﺣﺔ‪ ،‬ﯾﻧﺑﻐﻲ أن ﺗﻛون اﻟﻣﺗطﻠﺑﺎت ﺗم ﺗوﺿﯾﺣﮫ ﻣﺳﺑﻘﺎ وﯾﺟب أن ﯾﻛون ﻣﺳﺗﻘرا‪ .‬ﺗﻐﯾﯾر اﻟﻣﺗطﻠﺑﺎت‬
‫ﻓﻲ ﻣﻧﺗﺻف اﻟطرﯾق ﺳﯾزﯾد اﻟﺗﻛﺎﻟﯾف ﺑﺷﻛل ﻛﺑﯾر وھذه اﻷﻧواع ﻣن اﻟﻣﺷﺎرﯾﻊ ﺑﺎھظﺔ اﻟﺛﻣن ﻋﻠﻰ أي ﺣﺎل‪ .‬ﻧﮭﺞ اﻟﺷﻼل ﯾﺟﻌل‬
‫اﻟﻛﻣﺎل ﺑﻣﻌﻧﻰ ﻓﻲ ھذه اﻟﺣﺎﻟﺔ‪..‬‬
‫إﻟﯿﻚ ﻣﺜﺎل آﺧﺮ )ﺣﻘﯿﻘﻲ( ﻣﻦ ‪:Upwork‬‬
‫"أﺗﻄﻠﻊ إﻟﻰ إﻧﺸﺎء ﻣﻨﺼﺔ اﻟﺘﻮاﺻﻞ اﻻﺟﺘﻤﺎﻋﻲ اﻟﻜﺒﯿﺮة اﻟﺘﺎﻟﯿﺔ ل ‪ IOS‬و‬
‫أﻧﺪروﯾﺪ"‬
‫اﻟﺧروج ﺑﺧطﺔ ﻣﻔﺻﻠﺔ ﺗﺳﺗﻧد إﻟﻰ اﻓﺗراﺿﺎت ﻟن ﯾﺟﻌل ﺷﻌور‪ .‬اﻟوﺻف ﻏﺎﻣض‪ ،‬وﻟن ﯾﺗﻣﻛن اﻟﻌﻣﯾل ﻣن ذﻟك ﺻف ﺑﺎﻟﺿﺑط‬
‫ﻣﺎ ﯾﺣﺗﺎﺟون إﻟﯾﮫ‪ .‬ھذا اﻟﻣﺳﺗوى اﻟﻌﺎﻟﻲ ﻣن ﻋدم اﻟﯾﻘﯾن ﯾدﻋو إﻟﻰ ﻧﮭﺞ رﺷﯾق‪ .‬إﻧﺷﺎء ﺳﺗﺗطﻠب "اﻟﺷﺑﻛﺔ اﻻﺟﺗﻣﺎﻋﯾﺔ اﻟﻛﺑﯾرة‬
‫اﻟﺗﺎﻟﯾﺔ" ﺗﻛرارات ﻣﺗﻌددة‪.‬‬
‫ﻟذﻟك‪ ،‬ﻟﺗﻠﺧﯾص ذﻟك‪ ،‬ﯾﺟب ﻋﻠﯾك اﺳﺗﺧدام اﻟﺷﻼل ﻋﻧدﻣﺎ ﺗﻌرف ﻣﺎ ھو ﯾﺟب أن ﯾﻛون اﻟﻣﻧﺗﺞ اﻟﻧﮭﺎﺋﻲ‪ ،‬وﻻ ﯾﻣﻛن ﻟﻠﻌﻣﻼء ﺗﻐﯾﯾر‬
‫ﻧطﺎق ﻣﺷروع‪.‬‬
‫ﯾﺟب اﺳﺗﺧدام ﻣﻧﮭﺟﯾﺎت رﺷﯾﻘﺔ ﻋﻧدﻣﺎ ﯾﻛون ھﻧﺎك اﻟﻛﺛﯾر ﻣن ﻋدم اﻟﯾﻘﯾن اﻟﻣﻌﻧﯾﺔ‪ ،‬اﻟﻣﺗطﻠﺑﺎت ﻏﺎﻣﺿﺔ أو ﺳرﯾﻌﺔ اﻟﺗﻐﯾر‬
‫واﻟﻌﻣﻼء ﻻ ﯾﻣﻛن أن ﺗﺻف ﺑدﻗﺔ ﻣﺎ ﯾﺟب أن ﯾﻔﻌﻠﮫ اﻟﻣﻧﺗﺞ اﻟﻧﮭﺎﺋﻲ أو ﯾﺑدو ﻋﻠﯾﮫ‪.‬‬
CHAPTER 3 CORE OBJECT-ORIENTATION CONCEPTS
This Dilbert comic walks us through the history of programming. It's a
bit of an exaggeration, but programming was totally different a couple
of decades ago.
‫ لكن‬، ‫ إنه نوع من المبالغة‬.‫البمجة‬
‫عب تاري خ ر‬
‫ ر‬Dilbert ‫يرشدنا هذا الكتاب الهزل‬
ً ‫البمجة كانت مختلفة‬
.‫تماما قبل عقدين من الزمن‬
‫ر‬
Nowadays it is easy to get started with programming. There are various
visual tools and sophisticated development environments that make
learning fun.
‫ هناك العديد من األدوات المرئية‬.‫البمجة‬
‫ من السهل البدء ف ر‬، ‫ف الوقت الحاض‬
ً
‫ممتعا‬
‫وبيئات التطوير المتطورة الت تجعل التعلم‬.
We can program drones and robots, create 3D-games or augmented
reality apps. We can achieve all that without having to learn for years.
We’re lucky to have all these great tools today.
‫يمكننا برمجة الطائرات اآللية والروبوتات وإنشاء ألعاب ثالثية األبعاد أو تطبيقات‬
‫ نحن‬.‫ يمكننا تحقيق كل ذلك دون الحاجة إل التعلم لسنوات‬.‫الواقع المعزز‬
‫محظوظون ألن لدينا كل هذه األدوات الرائعة اليوم‬.
1
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Initially, computer programs were big, contiguous chunks of code. The
unstructured programming was the earliest programming paradigm.
The code consisted of sequentially ordered instructions. Each statement
would go in a new line. Source code lines were numbered or identified
by a label.
‫كببة ومتجاورة من التعليمات‬
‫ كانت برامج الكمبيوتر عبارة عن أجزاء ر‬، ‫ف البداية‬
‫ يتكون الكود من‬.‫للبمجة‬
‫غب المهيكلة ه أقدم نموذج ر‬
‫البمجة ر‬
‫ كانت ر‬.‫البمجية‬
‫ر‬
‫ تم ترقيم خطوط‬.‫ كل عبارة ستدخل ف سطر جديد‬.‫تعليمات مرتبة بشكل تسلسل‬
‫كود المصدر أو تحديدها بواسطة تسمية‬.
Here’s an example written in Sinclair Basic. This simple program
converts from Fahrenheit to Celsius degrees:
‫البنامج البسيط يتحول من درجة‬
‫هذا مثال مكتوب بلغة‬
‫ هذا ر‬.‫سنكلب بيسك‬
‫ر‬
: ‫فهرنهايت إل درجة مئوية‬
10 PRINT "Fahrenheit", "Celsius"
20 PRINT
30 INPUT "Enter deg F", F
40 PRINT F, (F-32)*5/9
50 GO TO 30
As the programs grew in complexity, the drawbacks of this approach
had become apparent. Maintaining or even understanding such a code
base was challenging. To make any changes or improvements, you had
to check the statements line by line.
‫ كان الحفاظ عل قاعدة‬.‫ أصبحت عيوب هذا النهج واضحة‬، ‫مع تزايد تعقيد ا رلبامج‬
ً
ً ‫الرموز هذه أو حت فهمها‬
‫ كان عليك‬، ‫تغيبات أو تحسينات‬
‫أمرا‬
‫ إلجراء أي ر‬.‫صعبا‬
ً
‫سطرا بسطر‬
‫التحقق من البيانات‬.
2
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
This task becomes more and more difficult as the number of code lines
increases. Non-structured programming was heavily criticized for
producing hardly readable, so-called “spaghetti” code.
‫ر‬
‫غب‬
‫البمجة ر‬
‫ تعرضت ر‬.‫تصبح هذه المهمة أكب صعوبة مع زيادة عدد أسطر الكود‬
ً
‫ ما يسىم برمز "السباغيت‬، ‫مقروءا‬
‫"المهيكلة النتقادات شديدة بسبب إنتاجها بالكاد‬.
The term spaghetti code is a pejorative description for complicated,
difficult to understand, and impossible to maintain, software.
‫ ومن المستحيل‬، ‫ يصعب فهمها‬، ‫تحقب رلبامج معقدة‬
‫مصطلح رمز السباغيت هو وصف‬
‫ر‬
‫صيانتها‬.
Structured programming emerged in the late 50s.
Structured programming languages break down code into logical steps.
They rely on subroutines, which contain a set of instructions to be
carried out. Here’s an example of a program written in C, which is a
procedural language:
‫البمجة المهيكلة ف أواخر الخمسينيات‬
‫ظهرت ر‬.
، ‫ أنها تعتمد عل اإلجراءات الفرعية‬.‫البمجة المهيكلة الكود إل خطوات منطقية‬
‫تقسم لغات ر‬
‫ ف ما يل مثال عل برنامج مكتوب‬.‫والت تحتوي عل مجموعة من التعليمات ليتم تنفيذها‬
:‫ وه لغة إجرائية‬، C ‫بلغة‬
#include<stdio.h> int
sum(int, int); int main()
{ int x, y;
int sum;
printf("Enter the first integer number: ");
&x);
scanf("%d",
printf("Enter the second integer number: ");
&y);
sum = sum(x, y);
printf("x: %d, y: %d\n", x, y);
printf("Sum: %d\n", sum);
3
scanf("%d",
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
return 0;
}
int sum(int x,int y)
{ int sum;
sum = x + y;
return sum;
}
The function called main() is the entry point of our program. It calls the
sum() function to add the two numbers entered by the user.
‫ إلضافة‬sum () ‫ يستدع الدالة‬.‫ ه نقطة دخول برنامجنا‬main () ‫الوظيفة المسماة‬
. ‫الرقمي اللذين أدخلهما المستخدم‬
‫ر‬
We can define additional methods. For example, if we need to calculate
the average of the two numbers, we could create a function like this:
‫ إذا احتجنا إل حساب متوسط‬، ‫ عل سبيل المثال‬.‫يمكننا تحديد طرق إضافية‬
:‫ فيمكننا إنشاء دالة مثل هذه‬، ‫العددين‬
float average(float x, float y)
{
return (x + y) / 2;
}
These subroutines operate on variables and data structures.
‫المتغبات وهياكل البيانات‬
‫تعمل هذه اإلجراءات الفرعية عل‬.
‫ر‬
A variable represents a value of a given type that can be identified using
a name.
‫معي يمكن تحديده باستخدام اسم‬
‫يمثل‬.
‫المتغب قيمة من نوع ر‬
‫ر‬
int x, y;
float salary;
4
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
We use the name of the variable to access the stored value. This lets us
modify the value during runtime.
‫ هذا يتيح لنا تعديل القيمة أثناء‬.‫المتغب للوصول إل القيمة المخزنة‬
‫نستخدم اسم‬
‫ر‬
‫وقت التشغيل‬.
int x = 10 // x has a value of 10 x =
42 // x is now 42 x = x + 1 // x is
now 43
A data structure is a way of organizing and storing data in a computer
program. Here’s a structure that aggregates the information needed to
represent an employee:
‫ إليك هيكل يجمع‬.‫بنية البيانات ه طريقة لتنظيم وتخزين البيانات ف برنامج كمبيوتر‬
:‫المعلومات الالزمة لتمثيل الموظف‬
struct employee {
int identifier;
char name[30];
float salary; };
Structured programming was a significant improvement compared to
the monolithic coding practices. Named functions improved the
readability of the computer programs. The development time could be
reduced substantially.
ً
ً
ً ‫تحسنا ر‬
‫ الوظائف‬.‫مب المتجانسة‬
‫البمجة المنظمة‬
‫كببا مقارنة بممارسات الب ر‬
‫كانت ر‬
‫كبب‬
‫ يمكن تقليل وقت التطوير بشكل ر‬.‫المسماة تحسن قابلية قراءة برامج الكمبيوتر‬.
Even with the improved quality, developers started to face new
challenges as the programs got bigger and bigger. Structured
programming could not address all the increased complexity.
‫ بدأ المطورون ف مواجهة تحديات جديدة حيث أصبحت‬، ‫حت مع الجودة المحسنة‬
‫للبمجة المنظمة معالجة كل التعقيد المبايد‬
‫ ال يمكن ر‬.‫وأكب‬
‫أكب ر‬
‫البامج ر‬
‫ر‬
.
5
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Object-orientation was the next big step in the evolution of the
programming paradigms. Object-oriented languages appeared in the
80s. The main idea was to split apart the program into self-contained
objects. Each object represents a part of the system that gets mapped
to a distinct entity. Basically, an object functions as a separate program
by itself. It operates on its own data and has a specific role.
‫ ظهرت اللغات‬.‫البمجة‬
‫كان توجيه الكائن هو الخطوة‬
‫الكببة التالية ف تطور نماذج ر‬
‫ر‬
‫البنامج إل كائنات قائمة‬
‫ كانت الفكرة الرئيسية ه تقسيم ر‬.‫الشيئية ف الثمانينيات‬
ً ‫ يمثل كل كائن‬.‫بذاتها‬
‫ يعمل الكائن‬، ‫ ف األساس‬.‫ممب‬
‫جزءا من النظام يتم تعيينه لكيان ر‬
‫ تعمل عل بياناتها الخاصة ولها دور محدد‬.‫كبنامج منفصل ف حد ذاته‬
‫ ر‬.
The objects that form the system interact with each other. Objectorientation aims to bring the world of programming closer to the real
world.
‫ يهدف التوجه الكائت إل‬.‫الكائنات الت تشكل النظام تتفاعل مع بعضها البعض‬
‫البمجة من العالم الحقيق‬
‫تقريب عالم ر‬.
6
SECTION 3.1 OBJECTS
While structured programming relies on actions, object-oriented
programming is organized around objects.
‫البمجة الموجهة للكائنات‬
‫ يتم تنظيم ر‬، ‫البمجة المهيكلة عل اإلجراءات‬
‫بينما تعتمد ر‬
‫حول الكائنات‬.
An object represents a thing. Just like in real life, objects can be simple
or complex.
‫البمجة للكائنات‬
‫ يتم تنظيم ر‬، ‫البمجة المهيكلة عل اإلجراءات‬
‫بينما تعتمد تعتمد ر‬
‫حول الكائنات‬.
A golf ball is an object, but so is Falcon Heavy. The way we define the
object depends on the level of detail we need.
‫ تعتمد الطريقة الت نحدد بها الكائن‬.‫ وكذلك فالكون هيق‬، ‫كرة الجولف ه شء‬
‫عل مستوى التفاصيل الت نحتاجها‬.
With the launch of the Falcon Heavy, they also sent the Tesla Roadster
with “Starman” in the driver’s seat toward Mars orbit. Objects may
contain or refer to other objects. This can also happen in the objectoriented world.
ً
‫ ف‬Starman ‫ مع‬Tesla Roadster ‫ أرسلوا أيضا سيارة‬، Falcon Heavy ‫مع إطالق‬
‫ يمكن‬.‫تشب إل كائنات أخرى‬
‫ قد تحتوي األشياء أو ر‬.‫مقعد السائق نحو مدار المري خ‬
ً
.‫أيضا ف العالم المعبض‬
‫أن يحدث هذا‬
7
We can describe objects using their properties. They can have attributes
like name, color, weight, velocity. A golf ball can be completely white,
colored or it may even glow in the dark. It has a weight and a price.
Some properties like its position, speed, and acceleration can change,
while other attributes (its color for example) will stay the same.
‫ يمكن أن يكون لها سمات مثل االسم‬.‫يمكننا وصف األشياء باستخدام خصائصها‬
‫ يمكن أن تكون كرة الجولف بيضاء بالكامل أو ملونة أو قد‬.‫واللون والوزن والرسعة‬
‫تتغب بعض الخصائص مثل موضعه‬
‫ يمكن أن ر‬.‫ لها وزن وسعر‬.‫تتوهج ف الظالم‬
‫ بينما تظل السمات األخرى (لونها عل سبيل المثال) كما ه‬، ‫ورسعته وتسارعه‬.
All these properties describe an object in the real world. This approach
works also in an object-oriented language.
ً
ً
‫ يعمل هذا النهج أيضا ف لغة‬.‫كل هذه الخصائص تصف كائنا ف العالم الحقيق‬
‫موجهة للكائنات‬.
8
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Objects have their identity, their own state. Changing the state of an
object doesn’t change the state of other objects. If we hit a golf ball, it
won’t affect all the other balls. Their state is independent, each has its
private identity.
‫تغيب حالة الكائنات‬
‫تغيب حالة الكائن إل ر‬
‫ ال يؤدي ر‬.‫ دولتها الخاصة‬، ‫األشياء لها هويتها‬
‫ دولتهم مستقلة‬.‫ فلن تؤثر عل جميع الكرات األخرى‬، ‫ إذا ضبنا كرة الجولف‬.‫األخرى‬
‫ لكل منها هويتها الخاصة‬،.
Besides properties and identity, an object has its own behavior. The
behavior of an object is what it can do.
‫ سلوك الكائن هو ما يمكنه‬.‫ الكائن له سلوكه الخاص‬، ‫إل جانب الخصائص والهوية‬
‫فعله‬.
“The black dog barks”
"‫"الكلب األسود ينبح‬
In this sentence, we identify one object: the dog.
“Bark” is the behavior, or the action performed by the “dog” object. And
“black” is its color, one of its attributes.
ً
ً
.‫ الكلب‬:‫ نحدد شيئا واحدا‬، ‫ف هذه الجملة‬
‫ و "األسود" لونه أحد‬."‫ أو اإلجراء الذي يقوم به كائن "الكلب‬، ‫"النباح" هو السلوك‬
.‫صفاته‬
We can identify the object easily since it’s the noun in the sentence. The
verb is the behavior, and the adjective is the property.
‫ والصفة ه‬، ‫ الفعل هو السلوك‬.‫يمكننا التعرف عل الكائن بسهولة ألنه االسم ف الجملة‬
‫الخاصية‬.
We describe an object using its properties, identity, and behavior.
ً
‫نحن نصف كائنا باستخدام خصائصه وهويته وسلوكه‬.
9
Quite straightforward, but how do we make this work in our code? For
that, we need to introduce a new concept, the class.
ً ‫واضح‬
‫ نحن بحاجة‬، ‫ ولكن كيف نجعل هذا يعمل ف الكود الخاص بنا؟ لذلك‬، ‫تماما‬
‫ وهو الفصل‬، ‫إل تقديم مفهوم جديد‬.
Section 3.2
The CLASS
Building an object-oriented system starts by identifying the potential
objects, their attributes, and responsibilities. We need to have a class
before we can create an object.
‫يبدأ بناء نظام موجه للكائنات من خالل تحديد الكائنات المحتملة وخصائصها‬
‫ نحتاج إل فصل دراش قبل أن نتمكن من إنشاء كائن‬.‫والمسؤوليات‬.
The class is the blueprint of an object. ‫الفئة ه مخطط كائن‬.
You can think of a class as a plan, a description of what an object will be.
An object is a realization of this blueprint.
ً
‫ الكائن هو‬.‫ ووصفا لما سيكون عليه الشء‬، ‫التفكب ف الفصل باعتباره خطة‬
‫يمكنك‬
‫ر‬
‫إدراك لهذا المخطط‬.
Let’s say you want to use a Pokémon in your program. A class called
Pokémon would provide a blueprint for what the Pokémon looks like
and what it can do.
Pokémon ‫ ستوفر فئة تسىم‬.‫لنفبض أنك تريد استخدام بوكيمون ف برنامجك‬
ً
.‫ وما يمكن أن يفعله‬Pokémon ‫مخططا لما يبدو عليه‬
The class tells us that each object has a name, armor level and hit
points. It doesn’t say what the name or the armor level is.
‫ ال يذكر االسم أو‬.‫يخبنا الفصل أن كل كائن له اسم ومستوى درع ونقاط إصابة‬
‫ر‬
‫مستوى الدرع‬
.
10
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
A Pokémon can attack, and it can defend itself. These two actions define
its behavior.
‫ يحدد هذان اإلجراءان سلوكه‬.‫ ويمكنه الدفاع عن نفسه‬، ‫يمكن لبوكيمون الهجوم‬.
We created a class by giving it a name, declaring its properties and
actions. We call these actions methods. Methods are blocks of code that
can be called to execute certain operations. They may take input
parameters and can also return values. Methods are like functions in
structured programming languages. The methods are basically functions
embedded in a class.
ً
ً ‫أنشأنا فئة بإعطائها‬
.‫ نسىم هذه األساليب اإلجراءات‬.‫معلنا خصائصها وأفعالها‬
، ‫اسما‬
‫البمجية يمكن استدعاؤها لتنفيذ عمليات‬
‫األساليب عبارة عن كتل من التعليمات ر‬
ً
‫ األساليب ه مثل‬.‫ قد يأخذون معلمات اإلدخال ويمكنهم أيضا إرجاع القيم‬.‫معينة‬
‫ الطرق ه ف األساس وظائف مضمنة ف الفصل‬.‫البمجة المهيكلة‬
‫الدوال ف لغات ر‬.
Given this class, we can create objects based on it. Upon object
creation, we provide the values for the attributes declared in the class.
Each object will have a name, armor level and hit points. The attack()
and defend() behavior is provided by the class
ً ‫ يمكننا إنشاء كائنات‬، ‫بالنظر إل هذه الفئة‬
‫ نقدم قيم‬، ‫ عند إنشاء الكائن‬.‫بناء عليها‬
‫ يتم‬.‫ سيكون لكل كائن اسم ومستوى درع ونقاط إصابة‬.‫السمات المعلنة ف الفصل‬
.‫توفب سلوك الهجوم () والدفاع () من قبل الفصل‬
‫ر‬
11
Given a blueprint, we can create as many instances as we need.
‫ يمكننا إنشاء العديد من األمثلة الت نحتاجها‬، ‫بالنظر إل المخطط‬.
Another big benefit of classes is that we can package them into libraries
or frameworks. This lets us reuse them in other programs as well.
‫ يتيح لنا‬.‫كببة أخرى للفصول ه أنه يمكننا تجميعها ف مكتبات أو أطر عمل‬
‫فائدة ر‬
ً
‫ذلك إعادة استخدامها ف برامج أخرى أيضا‬.
All modern object-oriented programming languages provide such builtin frameworks. We don’t have to reinvent the wheel and implement the
functionality that’s readily available. Instead, we can focus on creating
and using the objects in our programs.
‫ ال‬.‫البمجة الحديثة الموجهة للكائنات مثل هذه األطر المضمنة‬
‫توفر جميع لغات ر‬
ً
، ‫ بدال من ذلك‬.‫يتعي علينا إعادة اخباع العجلة وتنفيذ الوظائف المتاحة بسهولة‬
‫ر‬
‫كب عل إنشاء الكائنات واستخدامها ف برامجنا‬
‫يمكننا الب ر‬.
12
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Now each program has different requirements. The pre-made classes
will rarely cover all our needs. You’ll often find yourself creating your
own classes.
ً
ً .‫اآلن لكل برنامج متطلبات مختلفة‬
‫نادرا ما تغط الفصول المعدة مسبقا جميع‬
ً ‫ ستجد نفسك‬.‫احتياجاتنا‬
‫ئ‬
‫تنش فصولك الدراسية الخاصة‬
‫غالبا‬
We covered the object and the class. Next, we’ll take a look at the core
object-orientation principles.
‫ سوف نلق نظرة عل مبادئ توجيه الكائن األساسية‬، ‫ بعد ذلك‬.‫غطينا الكائن والفئة‬.
3.3
ABSTRACTION
Abstraction is a way of describing complex problems in simple terms, by
ignoring some details. Eliminating the nitty-gritty details let us focus on
the bigger picture. We can dig deeper once we have a broader
understanding.
‫ من خالل تجاهل بعض‬، ‫التجريد طريقة لوصف المشاكل المعقدة بعبارات بسيطة‬
‫ يمكننا‬.‫األكب‬
‫ التخلص من التفاصيل الدقيقة دعنا نركز عل الصورة‬.‫التفاصيل‬
‫ر‬
‫التعمق ر‬.
‫أكب بمجرد أن يكون لدينا فهم أوسع‬
How does abstraction work? ‫كيف يعمل التجريد؟‬
If I say cat, you know what I’m talking about. I don’t need to say I was
thinking of a male Persian cat, if it’s a kitten, if it’s big or small.
‫ لست بحاجة للقول إنت كنت أفكر ف ذكر قطة‬.‫ فأنت تعلم ما أتحدث عنه‬، ‫إذا قلت قطة‬
‫صغبة‬
‫ إذا كانت قطة‬، ‫فارسية‬.
‫كببة أو ر‬
‫ إذا كانت ر‬، ‫صغبة‬
‫ر‬
13
You understand that I was talking about a cat.
‫أنت تفهم أنت كنت أتحدث عن قطة‬.
We are naturally good at generalizing things. We skip the irrelevant
details, but people will still understand us. That’s because our brains are
wired to understand abstract ideas like cat, house or car.
، ‫غب ذات الصلة‬
‫ نتخط التفاصيل ر‬.‫نحن بطبيعة الحال جيدون ف تعميم األشياء‬
‫ ذلك ألن أدمغتنا مصممة لفهم األفكار المجردة مثل‬.‫لكن الناس ال يزالون يفهموننا‬
‫القط أو المبل أو السيارة‬.
Abstraction works the same way in the object-oriented world. When we
start defining a class, we focus on the essential qualities of that class.
‫ عندما نبدأ ف تحديد الفصل‬.‫يعمل التجريد بنفس الطريقة ف العالم الموجه للكائنات‬
‫ فإننا نركز عل الصفات األساسية لتلك الفئة‬،.
Focus on essential qualities, discard unimportant ones
‫غب المهمة‬
‫ركز عل الصفات األساسية وتجاهل الصفات ر‬
..
14
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Back to our Pokémon example: we started with the most important
attributes and methods. We don’t need details like age, weight or
height, so we can ignore them.
‫ ال نحتاج إل تفاصيل‬.‫ بدأنا بأهم السمات واألساليب‬:‫بالعودة إل مثال بوكيمون لدينا‬
‫ لذا يمكننا تجاهلها‬، ‫مثل العمر أو الوزن أو الطول‬.
These attributes are unessential in our current application.
‫غب ضورية ف تطبيقنا الحال‬
‫هذه الصفات ر‬.
So, that’s how abstraction works. We focus on what’s important and
ignore all the details we don’t need.
‫ نحن نركز عل ما هو مهم ونتجاهل كل‬.‫ هذه ه الطريقة الت يعمل بها التجريد‬، ‫إذن‬
‫التفاصيل الت ال نحتاجها‬.
15
3.4
ENCAPSULATION
The next fundamental idea to keep in mind when dealing with OOP and
classes is called encapsulation.
‫ والفئات‬OOP ‫الفكرة األساسية التالية الت يجب وضعها ف االعتبار عند التعامل مع‬
.‫تسىم التغليف‬
We encapsulate something to protect it and keep its parts together.
ً ‫نقوم بتغليف شء ما لحمايته والحفاظ عل أجزائه‬.
‫معا‬
Think of how medicine is enclosed in a shell called capsule.
‫فكر ف كيفية وضع الدواء ف غالف يسىم كبسولة‬.
In object-orientation, this translates to packing together our properties
and methods in a class. Encapsulation also means hiding the gears and
the levers.
ً ‫ ُيبجم هذا إل تجميع خصائصنا وطرقنا‬، ‫ف اتجاه الكائن‬
‫ يعت‬.‫معا ف الفصل‬
ً
‫التغليف أيضا إخفاء البوس والرافعات‬.
Here’s an example. We can use a phone without understanding
electronics. We don’t need to know how the touchscreen, the camera
or the logic board works.
‫ ال نحتاج إل معرفة كيفية‬.‫ يمكننا استخدام الهاتف دون فهم اإللكبونيات‬.‫هذا مثال‬
‫الكامبا أو لوحة المنطق‬
‫عمل شاشة اللمس أو‬.
‫ر‬
16
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Similarly, we don’t want to expose the inner workings of our class. An
object should only reveal the essential features. This concept is called
data hiding. By hiding its internal details, the object is protected from
external interference.
‫ يجب أن يكشف الكائن فقط‬.‫ نحن ال نريد فضح األعمال الداخلية لفصلنا‬، ‫وبالمثل‬
‫ من خالل إخفاء تفاصيله‬.‫ هذا المفهوم يسىم إخفاء البيانات‬.‫عن السمات األساسية‬
ً
‫الخارج‬
‫ر‬
‫محميا من التدخل‬
‫ يكون الكائن‬، ‫الداخلية‬.
We restrict clients from modifying the object in ways we did not
originally plan, whether it's intentional or accidental. Additionally, we
prevent other parts of the system from relying on properties or
behavior that may change.
‫ سواء كان ذلك‬، ‫نحن نمنع العمالء من تعديل الكائن بطرق لم نخطط لها ف األصل‬
ً
ً
‫ فإننا نمنع أجزاء أخرى من النظام من االعتماد‬، ‫ باإلضافة إل ذلك‬.‫عرضيا‬
‫مقصودا أو‬
‫يتغب‬
‫عل الخصائص أو السلوك الذي قد ر‬.
If you replace your phone’s battery, that won’t affect the way you use
your phone. That’s because you only interact with the touchscreen.
Changes in the inner workings of your phone don’t matter to you. Our
classes shouldn’t be any different either.
‫ هذا ألنك‬.‫ فلن يؤثر ذلك عل طريقة استخدامك للهاتف‬، ‫إذا استبدلت بطارية هاتفك‬
‫ ال ينبغ أن‬.‫التغيبات ف األعمال الداخلية لهاتفك‬
‫ ال تهمك‬.‫تتفاعل فقط مع شاشة اللمس‬
‫ر‬
ً
‫تكون فصولنا مختلفة أيضا‬.
If we expose unnecessary details, any changes to those attributes or
methods may affect other parts of the system. Whereas if we restricted
access to that data or behavior, we don’t have to worry about the ripple
effect of our changes.
‫تغيبات عل تلك السمات أو الطرق‬
‫ فقد تؤثر أي ر‬، ‫غب ضورية‬
‫إذا كشفنا عن تفاصيل ر‬
‫حي أننا إذا قيدنا الوصول إل تلك البيانات أو السلوك‬
‫ ف ر‬.‫عل أجزاء أخرى من النظام‬
‫لتغيباتنا‬
‫التأثب المضاعف‬
‫ فال داع للقلق بشأن‬،.
‫ر‬
‫ر‬
17
Data hiding is not about selfishly keeping stuff for ourselves. It's rather
about protecting our classes from unwanted external dependencies.
‫ إنها باألحرى حماية فصولنا‬.‫ال يعت إخفاء البيانات االحتفاظ باألشياء بأنانية ألنفسنا‬
‫غب المرغوب فيها‬
‫من التبعيات الخارجية ر‬.
‫ئ‬
As a rule of thumb: ‫ش متعارف عليه‬:
Expose only as much of your class properties and methods as needed for
normal usage.
‫اكشف فقط عن قدر ما يلزم من خصائص وطرق الفصل الدراش الخاص بك‬
‫لالستخدام العادي‬.
Data hiding plays an essential role in keeping the dependencies
between objects to a minimum.
ً ‫يلعب إخفاء البيانات‬
ً
‫أساسيا ف الحفاظ عل التبعيات ربي الكائنات عند الحد‬
‫دورا‬
‫األدن‬.
18
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
A tightly coupled system, with most of the objects depending on each
other, is the obvious sign of a bad design. Updating or maintaining such
a system is a pain. Any tiny modification will cascade down and require
you to change other parts of the system, too. It’s like a never-ending
nightmare.
‫ عالمة‬، ‫ مع اعتماد معظم الكائنات عل بعضها البعض‬، ‫يعد النظام شديد البابط‬
‫واضحة عل التصميم ر ئ‬
‫ أي‬.‫ تحديث أو الحفاظ عل مثل هذا النظام هو ألم‬.‫الست‬
ً
‫ إنه مثل‬.‫تغيب أجزاء أخرى من النظام أيضا‬
‫تعديل طفيف سيتدهور ويتطلب منك ر‬
‫كابوس ال ينته‬
Object-oriented programming principles are here to make our lives
easier. Next up is the idea of Inheritance.
‫المباث‬
‫ التال هو فكرة ر‬.‫البمجة الكينونية موجودة هنا لجعل حياتنا أسهل‬
‫مبادئ ر‬.
19
SECTION 3.5
INHERITANCE
Inheritance is a key concept in object-oriented programming. Without
inheritance, we’d end up writing similar code over and over again.
‫ سننته بكتابة رمز مشابه‬، ‫المباث‬
‫ بدون ر‬.‫البمجة الشيئية‬
‫الوراثة مفهوم أساش ف ر‬
‫مر ًارا وتكر ًارا‬.
Inheritance means code reuse. That is, reusing an existing class
implementation in new classes.
‫ أي إعادة استخدام تطبيق فئة موجود ف فئات‬.‫الوراثة تعت إعادة استخدام الكود‬
‫جديدة‬.
Let us start with an example. We modeled the Pokémon class with the
main properties and behavior in mind. Given this class, we were able to
create our Pokémon instances.
‫ قمنا بتصميم فئة بوكيمون مع وضع الخصائص الرئيسية والسلوك‬.‫دعونا نبدأ بمثال‬
‫ تمكنا من إنشاء نماذج بوكيمون الخاصة بنا‬، ‫ بالنظر إل هذه الفئة‬.‫ف االعتبار‬.
20
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Now, what if we need new types, like electric, water or flying
Pokémon? We will need new classes since these new types have
special abilities.
‫ مثل الكهرباء أو الماء أو بوكيمون الطائرة؟‬، ‫ ماذا لو احتجنا إل أنواع جديدة‬، ‫اآلن‬
‫سنحتاج إل فصول جديدة ألن هذه األنواع الجديدة لها قدرات خاصة‬.
The Pokémon class has the properties name, armor and hit points, and
it can attack and defend itself. The Electric, Water and Flying Pokémon
have all these properties, and they are also able to attack and defend
themselves. Additionally, they also have specialized functionality.
‫ ويمكنها مهاجمة نفسها‬، ‫فئة بوكيمون لها خصائص االسم والدروع ونقاط الضبة‬
‫ئ‬
‫ئ‬
‫ وهم‬، ‫والمان والطائر كل هذه الخصائص‬
‫الكهربان‬
‫ يمتلك البوكيمون‬.‫والدفاع عنها‬
ً
‫ لديهم‬، ‫ باإلضافة إل ذلك‬.‫قادرون أيضا عل مهاجمة أنفسهم والدفاع عن أنفسهم‬
ً
. ‫أيضا وظائف متخصصة‬
An Electric Pokémon has the ability to wild charge. This attack is only
available to Electric-type Pokémons. AquaTail is a damaging Water
Pokémon move, and Flying Pokémons can perform the dragon ascent
attack.
‫ئ‬
‫ هذا الهجوم متاح فقط للبوكيمونات‬.‫البي‬
‫بوكيمون كهربان لديه القدرة عل الشحن ر‬
‫ئ‬
‫ ويمكن ل‬، ‫ ضارة‬Water Pokémon ‫ عبارة عن حركة‬AquaTail .‫الكهربان‬
‫من النوع‬
.‫التني‬
‫ تنفيذ هجوم صعود ر‬Flying Pokémons
As you’ve probably realized, the three new classes are almost identical
to the Pokémon class. The only difference is the special attack type.
ً
‫تقريبا مع فئة‬
‫ فإن الفئات الثالثة الجديدة متطابقة‬، ‫كما كنت قد أدركت عل األرجح‬
‫ االختالف الوحيد هو نوع الهجوم الخاص‬.‫بوكيمون‬.
21
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
We could add all these new behaviors to the Pokémon class. If we did
that, we’d end up in a class that has too many responsibilities. Suddenly,
all Pokémon objects could swim and fly and discharge electricity.
‫ فسننته‬، ‫ إذا فعلنا ذلك‬.‫يمكننا إضافة كل هذه السلوكيات الجديدة إل فئة بوكيمون‬
‫ يمكن لجميع كائنات بوكيمون السباحة‬، ‫ فجأة‬.‫الكثب من المسؤوليات‬
‫ف فصل لديه‬
‫ر‬
‫والطبان وتفري غ الكهرباء‬.
‫ر‬
We definitely don’t want that. Our classes should be simple. They need
to have a well-defined purpose.
‫ يجب أن يكون لديهم‬.‫ يجب أن تكون فصولنا بسيطة‬.‫نحن بالتأكيد ال نريد ذلك‬
ً
‫غرض محدد جيدا‬.
Object-orientation is about granularity and separation of concerns. Each
class should focus on one set of specific functionalities and do that well
‫ يجب أن يركز كل فصل عل‬.‫التوجه الكائن يدور حول التفصيل وفصل االهتمامات‬
‫مجموعة واحدة من الوظائف المحددة ويقوم بذلك بشكل جيد‬.
Creating one-size-fits-all, monolithic classes is a major mistake in objectoriented software development.
ً
‫البامج‬
‫يعد إنشاء فئات متجانسة مقاس واحد يناسب الجميع خطأ فادحا ف تطوير ر‬
‫الموجهة للكائنات‬.
So, how about keeping these classes separate? That sounds better. But
now, we keep repeating the same code for the common functionality.
There must be a better way.
22
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
‫ نستمر ف تكرار‬، ‫ لكن اآلن‬.‫ ماذا عن إبقاء هذه الفئات منفصلة؟ أن يبدو أفضل‬، ‫إذن‬
‫ يجب أن تكون هناك طريقة أفضل‬.‫نفس الرمز للوظيفة المشبكة‬.
Indeed, object-oriented programming languages have a solution for this
kind of problem: Inheritance.
‫ الوراثة‬:‫البمجة الشيئية لديها حل لهذا النوع من المشاكل‬
‫ لغات ر‬، ‫ف الواقع‬.
A class can inherit all the attributes and behavior from another class. In
our case, we let ElectricPokémon, WaterPokémon, and FlyingPokémon
inherit from the Pokémon class. The data and the behavior from the
Pokémon class are now available to all these classes, without us having
to write a single line of code.
‫ تركنا‬، ‫ ف حالتنا‬.‫يمكن للفصل أن يرث جميع السمات والسلوك من فئة أخرى‬
‫ ترث من فئة‬FlyingPokémon ‫ و‬WaterPokémon ‫ و‬ElectricPokémon
، ‫ متاحة اآلن لجميع هذه الفئات‬Pokémon ‫ البيانات والسلوك من فئة‬.Pokémon
.‫البمجية‬
‫دون الحاجة إل كتابة سطر واحد من التعليمات ر‬
Now we can add specialized behavior or attributes to the classes that
inherit from Pokémon.
‫يمكننا اآلن إضافة سلوك أو سمات متخصصة إل الفئات الت ترث من بوكيمون‬.
If we enhance or modify the Pokémon class, all the other classes will
automatically receive those changes.
23
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
‫ فستتلق جميع الفئات األخرى هذه‬، ‫ أو تعديلها‬Pokémon ‫بتحسي فئة‬
‫إذا قمنا‬
‫ر‬
ً
.‫تلقائيا‬
‫التغيبات‬
‫ر‬
In object-oriented terms, Pokémon is a parent or superclass. Whereas
the ElectricPokémon, WaterPokémon, and FlyingPokémon are
subclasses or child classes.
‫ ف‬.‫ بوكيمون هو أحد الوالدين أو الطبقة العليا‬، ‫ف المصطلحات الموجهة للكائنات‬
‫ ه فئات‬FlyingPokémon ‫ و‬WaterPokémon ‫ و‬ElectricPokémon ‫حي أن‬
‫ر‬
.‫فرعية أو صفوف أطفال‬
Inheritance is a powerful idea which can save us from a lot of typing.
‫الكثب من الكتابة‬
‫المباث فكرة قوية يمكن أن تنقذنا من‬.
‫ر‬
‫ر‬
Besides, it paves the road to another handy feature called
Polymorphism.
‫لمبة مفيدة أخرى تسىم تعدد األشكال‬
‫ فإنه يمهد الطريق ر‬، ‫إل جانب ذلك‬.
24
SECTION 3.6
POLYMORPHISM
Here’s another term you’ll often hear when it comes to objectorientation: Polymorphism.
ً ‫إليك مصطلح آخر ستسمعه ر‬.
‫ئ‬
‫ تعدد األشكال‬:‫الشيت‬
‫كثبا عندما يتعلق األمر بالتوجه‬
The word has Greek origins, and it consists of two words: “polys”, which
means many, much and “morphé,” meaning form or shape.
‫ و‬، ‫الكثب‬
‫ والت تعت‬، "polys" :‫كلمتي‬
‫ وتتكون من‬، ‫الكلمة لها أصول يونانية‬
‫ر‬
‫ر‬
.‫ وتعت الشكل أو الشكل‬، "‫"مورف‬
If you look up the word polymorphism, you’ll find the following
definition:
:‫ ستجد التعريف التال‬، ‫إذا بحثت عن كلمة تعدد األشكال‬
The condition of occurring in several different forms.
‫حالة حدوثها بعدة أشكال مختلفة‬.
How does this apply to programming?
‫البمجة؟‬
‫كيف ينطبق هذا عل ر‬
To understand how polymorphism works, we have to revisit the idea of
inheritance.
‫ علينا إعادة النظر ف فكرة الوراثة‬، ‫لفهم كيفية عمل تعدد األشكال‬.
Here’s our Pokémon superclass and its subclasses.
‫ها ه فئة بوكيمون الفائقة وفئاتها الفرعية‬.
25
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
The Electric, Water and FlyingPokémon all inherit the data and the
behavior of their superclass. So, they have a name, armor, hit points and
they can attack and defend themselves.
.‫ البيانات وسلوك الطبقة الفائقة‬FlyingPokémon ‫ و‬Water ‫ و‬Electric ‫يرث كل من‬
.‫ لديهم اسم ودرع ونقاط إصابة ويمكنهم مهاجمة أنفسهم والدفاع عن أنفسهم‬، ‫لذلك‬
The WaterPokémon inherits the attack behavior from the Pokémon
superclass. Now, what if we need WaterPokémon types to cause more
damage than basic Pokémons?
‫ ماذا لو‬، ‫ اآلن‬.‫ سلوك الهجوم من فئة بوكيمون الفائقة‬WaterPokémon ‫يرث‬
‫ إلحداث أضار ر‬WaterPokémon ‫احتجنا إل أنواع‬
Pokémons ‫أكب من‬
‫األساسية؟‬
For that, we need to provide a specialized implementation of the attack
behavior. This is what we call method overriding.
‫ هذا ما نسميه تجاوز‬.‫توفب تنفيذ متخصص لسلوك الهجوم‬
‫ نحتاج إل ر‬، ‫لذلك‬
.‫الطريقة‬
26
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
By overriding a method of the superclass, we tell that we want a
different behavior in our subclass than the one we inherited.
ً
ً
‫ نقول إننا نريد سلوكا مختلفا ف فئتنا الفرعية‬، ‫من خالل تجاوز طريقة الطبقة الفائقة‬
‫عن السلوك الذي ورثناه‬.
Method overriding is straightforward: we re-implement the method
with the same name and parameters as the one defined in the parent
class and provide our own behavior
ً ‫يعد تجاوز الطريقة‬
ً
‫ فنحن نعيد تنفيذ الطريقة بنفس االسم والمعلمات‬:‫مبارسا‬
‫أمرا‬
‫كتلك المحددة ف الفئة األصلية ونقدم سلوكنا الخاص‬
By doing so, our WaterPokémon objects will have a different attack()
behavior than their Pokémon superclass. Calling the attack() method on
the Electric and Flying Pokémon objects will use the logic implemented
in their superclass, since we did not override the attack() method in
their case.
‫ الخاصة بنا سلوك‬WaterPokémon ‫ سيكون ألجسام‬، ‫من خالل القيام بذلك‬
‫ استدعاء طريقة الهجوم () عل‬.‫ الفائقة‬Pokémon ‫هجوم () مختلف عن فئة‬
، ‫كائنات البوكيمون الكهربائية والطائرة ستستخدم المنطق المطبق ف فئتهم الفائقة‬
.‫ألننا لم نتجاوز طريقة الهجوم () ف حالتهم‬
So, that’s method overriding. Polymorphism lets us work with objects
created from any of these classes. We don’t need to know whether its a
Water, Flying or Electric Pokémon instance to call any of the common
methods defined in the superclass.
27
‫‪UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS‬‬
‫لذلك ‪ ،‬هذه ه الطريقة الت تغلب عليها‪ .‬يتيح لنا تعدد األشكال العمل مع الكائنات‬
‫الت تم إنشاؤها من أي من هذه الفئات‪ .‬ال نحتاج إل معرفة ما إذا كان مثيل بوكيمون‬
‫‪ Water‬أو ‪ Flying‬أو ‪ Electric Pokémon‬الستدعاء أي من األساليب الشائعة‬
‫المحددة ف الطبقة الفائقة‪.‬‬
‫‪We could create an army of mixed Pokémons and tell them to attack at‬‬
‫‪once.‬‬
‫‪.‬يمكننا إنشاء جيش من البوكيمون المختلط ونطلب منهم الهجوم ف الحال‬
‫‪Each of them will execute the right attack() method without us having to‬‬
‫‪know their exact type. All we know is that they are all instances of the‬‬
‫‪Pokémon type or one of its subclasses.‬‬
‫سيقوم كل منهم بتنفيذ أسلوب الهجوم الصحيح () دون الحاجة إل معرفة نوعه‬
‫ً‬
‫جميعا أمثلة لنوع بوكيمون أو إحدى فئاته الفرعية‪.‬‬
‫بالضبط‪ .‬كل ما نعرفه هو أنها‬
‫‪28‬‬
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Polymorphism is about working freely with instances of many different
classes that share a common superclass.
‫يتعلق تعدد األشكال بالعمل بحرية مع حاالت من العديد من الفئات المختلفة الت‬
‫تشبك ف فئة فائقة مشبكة‬.
It’s probably easier to grasp it when using it in a real program, so let me
show you an example. I’m going to use Swift and Xcode on a Mac.
‫ لذا دعت أوضح لك‬، ‫ربما يكون من األسهل فهمه عند استخدامه ف برنامج حقيق‬
ً
Mac. ‫ عل جهاز‬Xcode ‫ و‬Swift ‫ سأستخدم‬.‫مثاال‬
We’ll implement the Pokémon class and all the subclasses. This is an
overly simplified example but it’s good enough to show you how
polymorphism works in a real program. So, here’s our Pokémon class.
The attack() method just displays a message to the console.
‫ هذا مثال مبسط للغاية ولكنه جيد بما‬.‫سنطبق فئة بوكيمون وجميع الفئات الفرعية‬
‫ ها هو فصل البوكيمون‬.‫يكق لتوضيح كيفية عمل تعدد األشكال ف برنامج حقيق‬
.‫ فقط رسالة إل وحدة التحكم‬attack )( ‫ تعرض طريقة‬.‫لدينا‬
class Pokémon {
var name: String
init(name: String) {
self.name = name
}
29
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
func attack() {
print("Pokémon attack!")
}
}
The Electric, Water and Flying Pokémon classes inherit from the
Pokémon class. This is how we do it in Swift: we put the name of the
superclass after the name of the child class separated by a colon.
‫ هذه ه الطريقة‬.‫ترث فصول البوكيمون الكهربائية والمائية والطائرة من فئة بوكيمون‬
ً
‫ نضع اسم الطبقة الفائقة بعد اسم فئة الطفل مفصوال‬:Swift ‫الت نقوم بها ف‬
.‫بنقطتي‬
‫ر‬
class ElectricPokémon: Pokémon {
}
class WaterPokémon: Pokémon {
}
class FlyingPokémon: Pokémon {
}
I override the attack method in the WaterPokémon class. To specify that
I’m overriding a method in the superclass I’m using the override
keyword. For this example, we’ll simply display a different message:
‫ لتحديد أنت أتجاوز طريقة‬.WaterPokémon ‫لقد تجاوزت طريقة الهجوم ف فصل‬
‫ سنعرض‬، ‫ ف هذا المثال‬.‫ فأنا أستخدم الكلمة الرئيسية لإللغاء‬، ‫ف الفئة الممتازة‬
:‫ببساطة رسالة مختلفة‬
class WaterPokémon: Pokémon {
override func attack() {
print("WaterPokémon attack!")
}
}
Next, I’ll create some Pokémon instances. One Pokémon object, a
WaterPokémon, then an Electric and a FlyingPokémon, too.
let eevie = Pokémon(name: "Eevie") let misty =
WaterPokémon(name: "Misty") let pikachu =
ElectricPokémon(name: "Pikachu") let charizard =
FlyingPokémon(name: "Charizard")
30
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Then, I define a list with these objects. Now, I can traverse this list and
call the attack() method on the objects in the list. We don’t need to
know the class they were instantiated from.
‫ يمكنت اجتياز هذه القائمة واستدعاء‬، ‫ اآلن‬.‫ أحدد قائمة بهذه الكائنات‬، ‫بعد ذلك‬
‫ ال نحتاج إل معرفة الفصل الذي‬.‫طريقة الهجوم () عل الكائنات الموجودة ف القائمة‬
.‫تم إنشاء مثيل له منه‬
let pokémons = [eevie, pikachu, misty, charizard]
for pokémon in pokémons {
pokémon.attack()
}
If I run the demo, we’ll see in the console that the attack method
produced the same output in the console for all the objects but one.
‫ فسبى ف وحدة التحكم أن طريقة الهجوم‬، ‫إذا قمت بتشغيل العرض التوضيح‬
‫أنتجت نفس اإلخراج ف وحدة التحكم لجميع الكائنات باستثناء كائن واحد‬.
Pokémon attack!
Pokémon attack!
WaterPokémon attack! Pokémon
attack!
That object was of type WaterPokémon, which overrides the attack()
method.
)( ‫ والذي يتجاوز طريقة الهجوم‬، WaterPokémon ‫كان هذا الكائن من النوع‬
31
32
CHAPTER 4 OBJECT-ORIENTED ANALYSIS AND DESIGN
Building an object-oriented application requires some preliminary steps.
These steps are similar regardless of the development methodology.
‫ هذه الخطوات‬.‫يتطلب إنشاء تطبيق موجه للكائنات بعض الخطوات األولية‬
‫متشابهة بغض النظر عن منهجية التطوير‬.
First, we need to collect the requirements. During the requirements
collection phase, we answer the following questions:
ً
‫ نجيب عىل األسئلة‬، ‫ خالل مرحلة جمع المتطلبات‬.‫ نحتاج إىل جمع المتطلبات‬، ‫أوال‬
:‫التالية‬
-
What’s the problem we're trying to solve?
‫الت نحاول حلها؟‬
‫ه المشكلة ي‬
‫ما ي‬
What does our app or framework need to do to accomplish that
functionality?
-
‫ما الذي يحتاج تطبيقنا أو إطار العمل الخاص بنا إىل القيام به إلنجاز هذه‬
‫الوظيفة؟‬
The requirements collection step involves a lot of brainstorming and
discussions. Once we come to an agreement, we need to document our
ideas. The requirements need to be as clear as possible.
‫ بمجرد أن‬.‫الذهت والمناقشات‬
‫الكثي من العصف‬
‫تتضمن خطوة جمع المتطلبات‬
‫ر‬
‫ي‬
‫ يجب أن تكون المتطلبات واضحة قدر‬.‫ نحتاج إىل توثيق أفكارنا‬، ‫نتوصل إىل اتفاق‬
‫اإلمكان‬.
Only write down the decisions that underline what the system is going to
do. Vague thoughts will lead to conflicts later on.
‫ ستؤدي األفكار الغامضة إىل‬.‫الت تحدد ما سيفعله النظام‬
‫اكتب فقط‬
‫القرارات ي‬
ً
‫رصاعات الحقا‬.
1
Once the requirements are clear, we come up with a description of the
software system. We should describe the app from the user’s
perspective.
‫ يجب أن نصف التطبيق‬.‫الينامج‬
‫ نخرج بوصف لنظام ر‬، ‫بمجرد أن تتضح المتطلبات‬
‫من وجهة نظر المستخدم‬.
Depending on the project, we may pick an agile or a waterfall
methodology. For agile projects, it is completely fine if we don’t provide
an accurate description. We can still fill the gaps or refine our thoughts
later on. The point here is to gain as much clarity as needed to start the
next step.
ً
‫اعتمادا عىل ر‬
‫ بالنسبة للمشاري ع الرشيقة‬.‫ قد نختار منهجية رشيقة أو شالل‬، ‫المشوع‬
ً
ً
ً ‫ فال بأس‬،
‫ ال يزال بإمكاننا سد الثغرات أو صقل أفكارنا‬.‫تماما إذا لم نقدم وصفا دقيقا‬
ً
.
‫أكي قدر من الوضوح حسب الحاجة لبدء‬
‫هنا‬
‫مهمة‬
‫ال‬
‫النقطة‬
‫ا‬
‫الحق‬
‫ه الحصول عىل ر‬
‫ي‬
‫الخطوة التالية‬.
This step of describing the app may include the creation of visual
mockups, wireframes or even prototypes. If it helps in communicating
your thoughts to the client, then do it.
‫قد تتضمن هذه الخطوة يف وصف التطبيق إنشاء نماذج باألحجام الطبيعية المرئية أو‬
، ‫ إذا كان ذلك يساعد يف توصيل أفكارك للعميل‬.‫إطارات سلكية أو حت نماذج أولية‬
‫فافعل ذلك‬.
I’ve used wireframes and nonfunctional prototypes for most of my
projects. These prototypes proved to be extremely useful. Especially if
the client was not familiar with the platform or he had no precise
expectations.
‫ر‬
‫ أثبتت‬.‫وعات‬
‫لقد استخدمت إطارات سلكية ونماذج أولية ر‬
‫غي وظيفية لمعظم مش ي‬
‫ خاصة إذا لم يكن العميل عىل دراية بالمنصة أو‬.‫هذه النماذج األولية أنها مفيدة للغاية‬
‫لم يكن لديه توقعات دقيقة‬.
2
Let’s say a customer asks you to create an iOS version of their Android
app. A prototype will help the client understand that the iOS version will
look and behave differently.
‫ الخاص‬Android ‫ من تطبيق‬iOS ‫لنفيض أن أحد العمالء يطلب منك إنشاء إصدار‬
‫ سيبدو ويترصف بشكل‬iOS ‫األوىل العميل عىل فهم أن إصدار‬
‫ سيساعد النموذج‬.‫به‬
‫ي‬
.‫مختلف‬
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
3
By communicating our vision precisely, we avoid surprises and false
expectations.
‫ نتجنب المفاجآت والتوقعات الخاطئة‬، ‫من خالل توصيل رؤيتنا بدقة‬.
Next comes the third phase. During this step, we aim to identify the
things that form our system. These are the potential players that have a
specific, well-defined role in our application.
‫الت‬
‫ نهدف إىل تحديد األشياء‬، ‫ خالل هذه الخطوة‬.‫تأت المرحلة الثالثة‬
‫بعد ذلك ي‬
‫ي‬
ً
‫ هؤالء هم الالعبون المحتملون الذين لديهم دور محدد ومحدد جيدا يف‬.‫تشكل نظامنا‬
‫تطبيقنا‬.
Picking the essential entities won't be challenging if we did a good job at
the previous two steps. We’ll realize that we need a class that
represents say an item that has a name, a price, and some other
attributes; or a class responsible for securely communicating with a
server. Another class may manage your local persistence, and so on.
ً
ً ‫لن يكون اختيار الكيانات األساسية‬
‫الخطوتي‬
‫صعبا إذا قمنا بعمل جيد يف‬
‫أمرا‬
‫ر‬
ً
‫عنرصا عىل سبيل المثال له اسم‬
‫ سوف ندرك أننا بحاجة إىل فئة تمثل‬.‫السابقتي‬
‫ر‬
‫ قد يتوىل‬.‫وسعر وبعض السمات األخرى ؛ أو فئة مسؤولة عن االتصال اآلمن بالخادم‬
‫ وما إىل ذلك‬، ‫المحىل‬
‫فصل آخر إدارة إرصارك‬.
‫ي‬
In the final phase, we describe the behavior of our system in a formal
way. This last step is about creating visual representations of our
classes, their attributes and behavior. We also model the interaction
between the objects.
‫األخية تتعلق‬
‫ هذه الخطوة‬.‫ نصف سلوك نظامنا بطريقة رسمية‬، ‫يف المرحلة النهائية‬
‫ر‬
ً
‫ نقوم أيضا بنمذجة التفاعل ربي‬.‫ وصفاتها وسلوكها‬، ‫بإنشاء تمثيالت مرئية لفصولنا‬
‫الكائنات‬.
We’ll rely on the Unified Modeling Language, in short, UML. UML is a
graphical notation that provides a set of standard diagrams. These
diagrams let us describe object-oriented systems in a standard way.
4
‫رسوم‬
‫سنعتمد عىل لغة النمذجة الموحدة باختصار ‪ UML. UML‬عبارة عن تدوين‬
‫ي‬
‫يوفر مجموعة من الرسوم البيانية القياسية‪ .‬تتيح لنا هذه المخططات وصف األنظمة‬
‫الموجهة بالكائنات بطريقة قياسية‪.‬‬
‫‪This may sound overwhelming now, but no worries. We’re going to‬‬
‫‪discuss each of these concepts in the upcoming chapters.‬‬
‫ً‬
‫داع للقلق‪ .‬سنناقش كل من هذه المفاهيم يف‬
‫قد يبدو هذا صعبا اآلن ‪ ،‬لكن ال ي‬
‫‪.‬الفصول القادمة‬
‫‪5‬‬
SECTION 4.1 COLLECTING REQUIREMENTS
The initial step of building a software system is crucial. It’s often called
requirement collection phase or requirements analysis. But regardless
of how we call it, it paves the road for all the other phases of the objectoriented software design.
ً
.‫الخطوة األوىل لبناء نظام برمجيات حاسمة‬
‫وغالبا ما يطلق عليه مرحلة تجميع‬
، ‫الت نسميها بها‬
‫ ولكن بغض النظر عن الطريقة ي‬.‫المتطلبات أو تحليل المتطلبات‬
‫الينامج الموجه للكائنات‬
‫فإنها تمهد الطريق لجميع المراحل األخرى من تصميم ر‬.
Requirement means “a thing that is needed or wanted.” And exactly
that’s what we need to focus on during this initial step:
‫المطلب يعت ر‬
‫كي عليه خالل‬
‫ وهذا بالضبط ما نحتاج إىل الي ر‬."‫"الشء المطلوب أو المطلوب‬
‫ي‬
‫ي‬
:‫هذه الخطوة األولية‬
We must clarify what’s needed or wanted in our application.
.‫يجب أن نوضح ما هو مطلوب أو مطلوب يف طلبنا‬
The features of the system are the so-called functional requirements.
Functional requirements represent what the app needs to provide
feature-wise, how it should react to a particular input, or what’s the
expected behavior in a specific situation.
‫ تمثل المتطلبات الوظيفية ما‬.‫ه ما يسىم بالمتطلبات الوظيفية‬
‫ر‬
‫ميات النظام ي‬
‫معي‬
‫ وكيف يجب أن يتفاعل مع إدخال ر‬، ‫الميات‬
‫يحتاجه التطبيق لتقديمه من حيث ر‬
‫معي‬
‫ أو ما هو السلوك المتوقع يف موقف ر‬،.
Let’s say you’re about to develop an app for runners. You should answer
questions like:
:‫ يجب أن تجيب عىل أسئلة مثل‬.‫للعدائي‬
‫لنفيض أنك عىل وشك تطوير تطبيق‬
‫ر‬
-
Should the actual speed always be visible on the main screen?
6
-
ً ‫هل يجب أن تكون الشعة الفعلية مرئية‬
‫دائما عىل الشاشة الرئيسية؟‬
Do we allow imperial and metric units?
‫اإلمييالية والميية؟‬
‫هل نسمح بالوحدات ر‬
Should we make this configurable by the user? Or automatically
adjust the units based on the phone's settings instead?
-
ً
‫هل يجب أن نجعل هذا قابال للتكوين بواسطة المستخدم؟ أو ضبط الوحدات‬
ً
ً ‫تلقائيا‬
ً
‫بناء عىل إعدادات الهاتف بدال من ذلك؟‬
We’ll usually also have nonfunctional requirements. These are the
requirements that are not directly related to a feature or behavior of
the software system but are important, nevertheless.
ً
.
‫ه المتطلبات ال يت ال تتعلق‬
‫هذه‬
‫وظيفية‬
‫غي‬
‫متطلبات‬
‫ا‬
‫أيض‬
‫عادة ما تكون لدينا‬
‫ر‬
‫ي‬
‫ر‬
‫ مع ذلك‬، ‫الينامج ولكنها مهمة‬
‫بمية أو سلوك نظام ر‬
‫مباشة ر‬.
Think of performance requirements: you don’t want to ruin the user
experience with an unresponsive app. Also, you may need to address
legal requirements. Does the app collect sensitive user data? Does it
allow users to browse the internet?
ً
‫ أيضا‬.‫غي مستجيب‬
‫ فأنت ال تريد إفساد تجربة المستخدم مع تطبيق ر‬:‫فكر يف متطلبات األداء‬
‫ هل يجمع التطبيق بيانات المستخدم‬.‫ قد تحتاج إىل معالجة المتطلبات القانونية‬،
‫للمستخدمي بتصفح اإلنينت؟‬
‫الحساسة؟ هل يسمح‬
‫ر‬
Documentation and support are also nonfunctional requirements. Your
software may need to adhere to certain standards or regulations.
7
‫غي وظيفية‪ .‬قد يحتاج برنامجك إىل االليام‬
‫ه أيضا متطلبات ر‬
‫التوثيق والدعم ي‬
‫‪.‬بمعايي أو لوائح معينة‬
‫ر‬
‫‪Nonfunctional requirements are equally important. Ignoring them may‬‬
‫‪cause serious legal issues and all sorts of other problems.‬‬
‫غي الوظيفية مهمة بنفس القدر‪ .‬قد يؤدي تجاهلها إىل مشاكل قانونية‬
‫المتطلبات ر‬
‫‪.‬خطية وجميع أنواع المشاكل األخرى‬
‫ر‬
‫‪Now, how do we handle this? There are different ways to gather the‬‬
‫‪requirements. The easiest way is just to write them down. Here’s an‬‬
‫‪example from a project I’ve been working on.‬‬
‫ه‬
‫اآلن ‪ ،‬كيف نتعامل مع هذا؟ هناك طرق مختلفة لجمع المتطلبات‪ .‬أسهل طريقة ي‬
‫كتابتها‪ .‬هذا مثال من ر‬
‫مشوع كنت أعمل عليه‬
‫‪.‬‬
‫‪8‬‬
Functional requirements
‫المتطلبات الوظيفية‬
-
-
-
The app must store travel expenses organized by trips.
‫يجب أن يخزن التطبيق نفقات السفر المنظمة حسب الرحالت‬.
Each trip must have a home currency. The default currency is
fetched from the phone’s settings. User setting must override
the default home currency.
‫ يتم جلب العملة االفياضية من إعدادات‬.‫يجب أن يكون لكل رحلة عملة محلية‬
‫ يجب أن يتجاوز إعداد المستخدم العملة المحلية االفياضية‬.‫الهاتف‬.
Expenses can be entered in any of the supported currencies.
The app must automatically convert the amounts to the home
currency.
‫ يجب أن يقوم التطبيق‬.‫يمكن إدخال المرصوفات بأي من العمالت المدعومة‬
ً
‫تلقائيا بتحويل المبالغ إىل العملة المحلية‬
.
9
Nonfunctional requirements
‫غي مجدية‬
‫متطلبات ر‬
-
The app must run on iOS 9 and newer versions.
. ‫ واإلصدارات األحدث‬iOS 9 ‫يجب أن يعمل التطبيق عىل نظام التشغيل‬
-
The app must avoid unnecessary network roundtrips to reduce
data roaming fees and preserve battery.
-
‫عي الشبكة لتقليل رسوم‬
‫غي الرصورية ر‬
‫يجب أن يتجنب التطبيق الرحالت ر‬
‫تجوال البيانات والحفاظ عىل البطارية‬.
-
The app must include the support email and the link to the
app’s website.
-
‫وت الخاص بالدعم والرابط إىل‬
‫يجب أن يشتمل التطبيق عىل ر‬
‫الييد اإللكي ي‬
‫موقع الويب الخاص بالتطبيق‬.
These are short, concise phrases in the form:
‫قصية وموجزة بالشكل‬
‫هذه عبارات ر‬:
“The app/system must do something.”
ً
"‫ النظام شيئا ما‬/ ‫يجب أن يفعل التطبيق‬."
You don’t want to write lengthy descriptions, and feel free to adapt this
format to your needs.
‫ وال تيدد يف تكييف هذا التنسيق مع احتياجاتك‬، ‫ال تريد كتابة أوصاف مطولة‬.
You should use some electronic form, but at early stages, pen and paper
or a whiteboard are also fine. Just make sure you store them somehow,
for example by taking photos.
‫ ال بأس‬، ‫ ولكن يف المراحل المبكرة‬، ‫يجب عليك استخدام بعض النماذج اإللكيونية‬
ً
‫ عىل‬، ‫ فقط تأكد من تخزينها بطريقة ما‬.‫أيضا باستخدام القلم والورق أو السبورة‬
‫سبيل المثال عن طريق التقاط الصور‬.
10
There are also more formal ways, tools, and systems that support the
requirements collection step. I won’t talk about these tools because this
book is not about tools, but rather about principles.
ً
‫أيضا طرق وأدوات وأنظمة ر‬
‫ لن‬.‫أكي رسمية تدعم خطوة جمع المتطلبات‬
‫هناك‬
‫ ولكن باألحرى عن‬، ‫أتحدث عن هذه األدوات ألن هذا الكتاب ال يتعلق باألدوات‬
‫المبادئ‬.
To summarize, the requirements collection step boils down to this:
:‫ تتلخص خطوة جمع المتطلبات يف هذا‬، ‫للتلخيص‬
We need to formulate what our software must do and which are the
constraints and boundaries we need to consider.
‫الت نحتاج إىل‬
‫ه القيود والحدود ي‬
‫نحتاج إىل صياغة ما يجب أن يفعله برنامجنا وما ي‬
‫مراعاتها‬.
If we’re using a Waterfall approach, we need to clarify all the
requirements in advance.
ً
‫ فنحن بحاجة إىل توضيح جميع المتطلبات مسبقا‬، ‫إذا كنا نستخدم نهج الشالل‬.
For Agile projects, it’s perfectly acceptable if we continue without
having all the answers. We may even miss some of the questions. Agile
lets us revisit and refine the requirements as we iterate through the
software development process.
11
ً ‫ من المقبول‬، Agile ‫بالنسبة لمشاري ع‬
‫تماما أن نستمر دون الحصول عىل جميع‬
‫ إعادة النظر يف المتطلبات‬Agile ‫ يتيح لنا‬.‫ قد نفوت حت بعض األسئلة‬.‫اإلجابات‬
.‫اليامج‬
‫وتحسينها بينما نكرر عملية تطوير ر‬
SECTION 4.2 MAPPING REQUIREMENTS TO TECHNICAL
DESCRIPTIONS
Once we’ve gathered the requirements, we can feed them to the next
step of the software design process. This is where we provide short,
accurate descriptions of our system’s functionality from the user’s
perspective.
‫ يمكننا إطعامهم إىل الخطوة التالية من عملية تصميم‬، ‫بمجرد أن نجمع المتطلبات‬
ً
‫قصية ودقيقة لوظائف نظامنا من‬
‫ هذا هو المكان الذي نقدم فيه أوصافا ر‬.‫الينامج‬
‫ر‬
‫منظور المستخدم‬.
One way of documenting our system’s features is through use-cases. A
use-case needs a title. Something like “Create New Trip,” “Edit Expense”
or “Convert Currencies.” Note that each use-case should represent a
distinct functionality.
12
‫ميات نظامنا يف حاالت االستخدام‪ .‬حالة االستخدام تحتاج‬
‫تتمثل إحدى طرق توثيق ر‬
‫ر‬
‫شء مثل "إنشاء رحلة جديدة" أو "تعديل النفقات" أو "تحويل‬
‫إىل عنوان‪ .‬ي‬
‫ممية‪.‬‬
‫العمالت"‪ .‬الحظ أن كل حالة استخدام يجب أن تمثل وظيفة ر‬
‫‪Next, we define the actor who’s using this functionality. We call it an‬‬
‫‪“actor” since it can represent a user who’s interacting with the app, but‬‬
‫‪also a non-human entity, like another system.‬‬
‫بعد ذلك ‪ ،‬نحدد الممثل الذي يستخدم هذه الوظيفة‪ .‬نطلق عليه اسم "ممثل" ألنه‬
‫ً‬
‫ً‬
‫ً‬
‫غي ر‬
‫بشي ‪،‬‬
‫يمكن أن يمثل مستخدما يتفاعل مع التطبيق ‪ ،‬ولكنه يمثل أيضا كيانا ر‬
‫مثل نظام آخر‪.‬‬
‫‪Then, we describe the details of this specific use-case. This is called the‬‬
‫‪scenario.‬‬
‫بعد ذلك ‪ ،‬نصف تفاصيل حالة االستخدام المحددة هذه‪ .‬هذا يسىم السيناريو‪.‬‬
‫‪Here we should write one or more sentences that explain what and how‬‬
‫‪the system works in this particular case. Here’s an example:‬‬
‫هنا يجب أن نكتب جملة واحدة أو ر‬
‫أكي ر‬
‫تشح ماذا وكيف يعمل النظام يف هذه الحالة‬
‫بالذات‪ .‬هذا مثال‪:‬‬
‫‪Create new trip - this is the title of our use case. The actor is the user of‬‬
‫‪the mobile app.‬‬
‫إنشاء رحلة جديدة ‪ -‬هذا هو عنوان حالة االستخدام الخاصة بنا‪ .‬الفاعل هو مستخدم‬
‫التطبيق المحمول‪.‬‬
‫‪The user can initiate the creation of a new trip from the main‬‬
‫‪screen.‬‬
‫‪-‬‬
‫‪.‬يمكن للمستخدم بدء إنشاء رحلة جديدة من الشاشة الرئيسية‬
‫‬‫‬‫‬‫‪-‬‬
‫‪The title is mandatory. All the other settings are optional.‬‬
‫ام‪ .‬جميع اإلعدادات األخرى اختيارية‬
‫‪.‬العنوان إلز ي‬
‫‪Optionally, the user can write a short description and set a start‬‬
‫‪and end date for the trip.‬‬
‫ً‬
‫قصي وتحديد تاري خ بدء الرحلة‬
‫اختياريا ‪ ،‬يمكن للمستخدم كتابة وصف ر‬
‫‪.‬وتاري خ انتهائها‬
‫‪13‬‬
‫‪-‬‬
-
-
The app assigns a default home currency based on the phone’s
settings. Users can override the default home currency with any
of the supported currencies.
ّ
ً ‫يعي التطبيق عملة رئيسية افياضية‬
‫ يمكن‬.‫بناء عىل إعدادات الهاتف‬
‫ر‬
‫للمستخدمي تجاوز العملة الرئيسية االفياضية بأي من العمالت المدعومة‬.
‫ر‬
-
The app allows setting a budget for the trip. This setting is
optional.
-
‫ هذا اإلعداد اختياري‬.‫ميانية للرحلة‬
‫يتيح التطبيق تحديد ر‬.
-
Also, the user can assign a custom thumbnail to a trip.
ً
‫تعيي صورة مصغرة مخصصة للرحلة‬
‫ يمكن للمستخدم ر‬، ‫أيضا‬.
-
And the user can save the trip or cancel the trip creation
process.
-
‫ ويمكن للمستخدم حفظ الرحلة أو إلغاء عملية إنشاء الرحلة‬.
You can write this as a paragraph or as a bulleted list. The format
doesn’t really matter. But it’s important to avoid technical terms. Again,
this description should be understood by all stakeholders, including the
end users.
ً
‫ لكن من‬.‫ ال يهم الشكل حقا‬.‫نقط‬
‫يمكنك كتابة هذا كفقرة أو كقائمة ذات تعداد‬
‫ي‬
‫ يجب فهم هذا الوصف من قبل جميع‬، ‫ مرة أخرى‬.‫المهم تجنب المصطلحات الفنية‬
‫النهائيي‬
‫المستخدمي‬
‫ بما يف ذلك‬، ‫أصحاب المصلحة‬.
‫ر‬
‫ر‬
The format of the use-case document may vary from company to
company. Some may include additional details, but that won’t change
the essence of it.
‫ قد يتضمن البعض‬.‫قد يختلف تنسيق مستند حالة االستخدام من رشكة إىل أخرى‬
‫يغي جوهرها‬
‫ لكن ذلك لن ر‬، ‫تفاصيل إضافية‬.
The use-case document aims to provide a clear and human-friendly
description. What a specific part of the software does and how the actor
interacts with it.And this is a textual description. We’ll talk about the
use-case diagrams later.
14
‫تهدف وثيقة حالة االستخدام إىل تقديم وصف واضح وسهل االستخدام‪ .‬ما يفعله‬
‫نص‪ .‬سنتحدث عن‬
‫الينامج وكيف‬
‫معي من ر‬
‫جزء ر‬
‫يتفاعل الممثل معه وهذا وصف ي‬
‫ً‬
‫‪.‬مخططات حالة االستخدام الحقا‬
‫‪User stories are another common way of describing certain features or‬‬
‫‪parts of our application. User stories are shorter than use-case‬‬
‫‪descriptions, usually only one-two sentence long. They typically follow‬‬
‫‪this format:‬‬
‫ميات أو أجزاء معينة من‬
‫تعد قصص المستخدم طريقة شائعة أخرى لوصف ر‬
‫تطبيقنا‪ .‬قصص المستخدم أقرص من أوصاف حالة االستخدام ‪ ،‬وعادة ما تكون‬
‫ً‬
‫جملتي فقط‪ .‬يتبعون عادة هذا التنسيق‪:‬‬
‫بطول جملة واحدة أو‬
‫ر‬
‫‪As a < type of user >, I want < some goal > so that < some reason >.‬‬
‫‪Examples:‬‬
‫‪“As a user, I want to add notes to my expenses, so that I can identify‬‬
‫”‪them later on.‬‬
‫ً‬
‫نفقات ‪ ،‬حت أتمكن من التعرف عليها‬
‫مستخدما ‪ ،‬أريد إضافة مالحظات إىل‬
‫بصفت‬
‫ي‬
‫" ً ي‬
‫الحقا"‪.‬‬
‫‪“As a power user, I want to retrieve the app’s database file, so that I can‬‬
‫”‪inspect it on any computer.‬‬
‫ً‬
‫ً‬
‫متمرسا ‪ ،‬أريد اسيداد ملف قاعدة بيانات التطبيق ‪ ،‬حت أتمكن‬
‫مستخدما‬
‫"بصفت‬
‫ي‬
‫من فحصه عىل أي جهاز كمبيوتر‪".‬‬
‫‪If you can’t describe a user story in one or two sentences, you may need‬‬
‫‪to split it into multiple, smaller user stories. These larger user stories are‬‬
‫‪known as epics. Epics cover a bigger chunk of functionality, like in the‬‬
‫‪following case:‬‬
‫جملتي ‪ ،‬فقد تحتاج إىل‬
‫إذا لم تتمكن من وصف قصة مستخدم يف جملة واحدة أو‬
‫ر‬
‫ُ‬
‫األكي هذه‬
‫تقسيمها إىل قصص مستخدم متعددة وأصغر‪ .‬تعرف قصص المستخدم‬
‫ر‬
‫بالمالحم‪ .‬تغط المالحم ً‬
‫أكي من الوظائف ‪ ،‬كما يف الحالة التالية‪:‬‬
‫جزءا ر‬
‫ي‬
‫‪15‬‬
“As a traveler, I want to track my expenses while abroad, so that I don’t
exceed my budget.”
ً
‫ حت ال أتجاوز‬، ‫نفقات أثناء تواجدي بالخارج‬
‫ أرغب يف تتبع‬، ‫مسافرا‬
‫"بصفت‬
‫ي‬
‫ي‬
".‫انيت‬
‫ر‬
‫مي ي‬
This epic could be split into many user stories including these:
:‫يىل‬
‫يمكن تقسيم هذه الملحمة إىل العديد من قصص‬
‫ر‬
‫المستخدمي بما يف ذلك ما ي‬
“As a user, I want to create new trips, so that I can track each of my
travels separately.”
ً
‫ حت أتمكن من تتبع كل رحلة من‬، ‫ أريد إنشاء رحالت جديدة‬، ‫مستخدما‬
‫"بصفت‬
‫ي‬
".‫رحالت عىل حدة‬
‫ي‬
“As a business traveler, I want to tag my business trips, so that I can
separate them from my private travels.”
ً
، ‫ أود وضع عالمات عىل رحالت العمل الخاصة ر يت‬، ‫مسافرا بغرض العمل‬
‫"بصفت‬
‫ي‬
".‫رحالت الخاصة‬
‫حت أتمكن من فصلها عن‬
‫ي‬
User stories are often written on sticky notes or index cards. You’ll see
them arranged on walls or tables during meetings and discussions.
‫ ستراها‬.‫غال ًبا ما تتم كتابة قصص المستخدم على مالحظات الصقة أو بطاقات فهرسة‬
‫ مرتبة على الجدران أو الطاوالت أثناء االجتماعات والمناقشات‬.
16
Unlike use-case descriptions, user stories don’t capture the feature
details. They serve as discussion starters instead.
‫ هم‬.‫المية‬
‫ ال تلتقط قصص المستخدم تفاصيل ر‬، ‫عىل عكس أوصاف حالة االستخدام‬
.‫بمثابة بداية مناقشة بدال من ذلك‬
User stories are about communication, and you’ll usually see them in
agile projects. Whereas use-case descriptions are preferably used by
Waterfall methodologies.
‫ بينما‬.‫ وعادة ما تراها يف مشاري ع رشيقة‬، ‫المستخدمي حول التواصل‬
‫تدور قصص‬
‫ر‬
.‫يفضل استخدام أوصاف حالة االستخدام بواسطة منهجيات الشالل‬
SECTION 4.3
WHY DO WE NEED A COMMON DESCRIPTIVE LANGUAGE?
The first two steps of the object-oriented analysis don’t require any
special tool or design language.
.‫خطوتي من التحليل الموجه للكائنات أي أداة خاصة أو لغة تصميم‬
‫ال تتطلب أول‬
‫ر‬
17
We only need some text-editing software. Even a piece of paper or a
whiteboard would be sufficient to collect the requirements and jot
down the use-cases or user stories.
‫ حت قطعة من الورق أو السبورة‬.‫نحتاج فقط إىل بعض برامج تحرير النصوص‬
.‫المستخدمي‬
‫ستكون كافية لجمع المتطلبات وتدوين حاالت االستخدام أو قصص‬
‫ر‬
The next steps require us to depict the classes that form our system.
How they behave and what attributes they need.
‫ه‬
‫ كيف يترصفون وما ي‬.‫الت تشكل نظامنا‬
‫تتطلب الخطوات التالية منا تصوير الفئات ي‬
.‫الت يحتاجون إليها‬
‫السمات ي‬
We also need to visualize how the objects interact with each other.
ً
.‫أيضا إىل تصور كيفية تفاعل الكائنات مع بعضها البعض‬
‫نحتاج‬
18
The development community faced this very same problem. The lack of a
commonly accepted design language lead to the proliferation of different
nonstandard approaches.
‫ يؤدي عدم وجود لغة تصميم مقبولة بشكل عام‬.‫واجه مجتمع التنمية هذه المشكلة نفسها‬
.‫إلى انتشار مناهج مختلفة غير قياسية‬
We could also try to come up with a way to draw everything from classes to
object interactions. Luckily, we don’t have to.
ً
‫أيضا محاولة التوصل إىل طريقة لرسم كل ر‬
.‫شء من الفئات إىل تفاعالت الكائن‬
‫يمكننا‬
‫ي‬
.‫ ليس علينا ذلك‬، ‫لحسن الحظ‬
The Unified Modeling Language is a common design language that was
released in 1997. UML provides a set of standard diagram types that can be
used to describe both the structure and the behavior of software systems.
UML ‫ يوفر‬.1997 ‫لغة النمذجة الموحدة هي لغة تصميم شائعة تم إصدارها في عام‬
‫مجموعة من أنواع المخططات القياسية التي يمكن استخدامها لوصف كل من بنية‬
‫وسلوك أنظمة البرامج‬
We’ll dig deeper into UML in the upcoming section.
‫سوف نتعمق ر‬
.‫ يف القسم القادم‬UML ‫أكي يف‬
19
CHAPTER 5
UML BASICS AND FUNDAMENTAL DIAGRAM TYPES
Understanding a software system just by looking at its source code can
be very time-consuming. And communicating ideas about software
design or business processes is even harder if there’s no commonly
accepted way to do it.
‫ ويكون‬.‫برمج بمجرد النظر إىل كود المصدر الخاص به مضيعة للوقت‬
‫قد يكون فهم نظام‬
‫ي‬
‫توصيل األفكار حول تصميم البامج أو العمليات التجارية ر‬
‫أكب صعوبة إذا لم تكن هناك طريقة‬
‫مقبولة بشكل عام للقيام بذلك‬.
The Unified Modeling Language - in short UML - was introduced to solve
this problem. UML is not a textual programming language, but rather a
graphical notation; a set of diagrams that help in designing and
communicating software systems.
‫ ليست لغة‬UML .‫ لحل هذه المشكلة‬- UML ‫ باختصار‬- ‫تم تقديم لغة النمذجة الموحدة‬
‫الت تساعد يف تصميم‬
‫ه رمز‬
‫ مجموعة من الرسوم البيانية ي‬.‫رسوم‬
‫ي‬
‫ بل ي‬، ‫برمجة نصية‬
.‫وتوصيل أنظمة البمجيات‬
We can use these diagrams to describe the objects that form a system
and their interactions. UML has many diagram types. We’ll be discussing
the most common ones.
‫ يوجد يف‬.‫الت تشكل النظام وتفاعالتها‬
‫يمكننا استخدام هذه المخططات لوصف الكائنات ي‬
ً
‫ سنناقش ر‬.‫ العديد من أنواع المخططات‬UML
.‫أكبها شيوعا‬
The use-case diagram describes the functional model of a system. That
is, the functionality of a system from the user’s point of view.
‫ وظيفة النظام من وجهة نظر‬، ‫ أي‬.‫الوظيف للنظام‬
‫يصف مخطط حالة االستخدام النموذج‬
‫ي‬
.‫المستخدم‬
1
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
To describe the structure of a system, UML provides structural
diagrams. We’ll talk about the class diagram, which can be used to
describe the structure of a system in terms of objects, attributes,
operations, and relations.
‫ والذي‬، ‫ سنتحدث عن مخطط الفصل‬.‫ مخططات هيكلية‬UML ‫ يوفر‬، ‫لوصف هيكل النظام‬
.‫يمكن استخدامه لوصف هيكل النظام من حيث العنارص والسمات والعمليات والعالقات‬
UML lets us model dynamic behavior, too. The behavioral diagrams
describe the functionality of the system, focusing on what happens and
the interactions between objects.
2
ً
، ‫ تصف المخططات السلوكية وظائف النظام‬.‫الديناميك أيضا‬
‫ نمذجة السلوك‬UML ‫يتيح لنا‬
‫ي‬
.‫مع البكب عىل ما يحدث والتفاعالت بي الكائنات‬
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
We’ll talk about the actual diagrams shortly.
ً ‫سنتحدث عن المخططات الفعلية‬
.‫قريبا‬
The best part about UML is that it’s independent of any particular
programming language. We can start coding an object-oriented
software based on UML diagrams. If those diagrams are detailed
enough, they can be converted to source code.
‫ يمكننا البدء يف ترمب برنامج‬.‫ هو أنه مستقل عن أي لغة برمجة معينة‬UML ‫أفضل جزء يف‬
ً
، ‫كاف‬
ٍ ‫ إذا كانت هذه المخططات مفصلة بشكل‬.UML ‫كائت المنج بناء عىل مخططات‬
‫ي‬
.‫فيمكن تحويلها إىل كود المصدر‬
3
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Now, let’s see some ways of using UML in real-life.We can quickly draw
a diagram to sketch a specific part of a software or a new functionality.
I did that myself on numerous occasions. Whenever something was
unclear, I started to sketch UML diagrams before writing a single line of
code.
‫ يمكننا برسعة رسم مخطط‬.‫ يف الحياة الواقعية‬UML ‫ دعنا نرى بعض طرق استخدام‬، ‫اآلن‬
‫ كلما‬.‫بنفس يف مناسبات عديدة‬
‫ فعلت ذلك‬.‫لرسم جزء معي من برنامج أو وظيفة جديدة‬
‫ي‬
‫ قبل كتابة سطر واحد من‬UML ‫ بدأت يف رسم مخططات‬، ‫شء غب واضح‬
‫كان هناك ي‬
.‫التعليمات البمجية‬
The benefit was that I not only understood what I should implement, I
also had a design. A documentation that could be used to communicate
my ideas with other team members.
ً
.‫أيضا‬
‫ بل كان لدي تصميم‬، ‫أنت لم أفهم فقط ما يجب أن أقوم بتنفيذه‬
‫ه ي‬
‫كانت الفائدة ي‬
.‫وثيقة يمكن استخدامها لتوصيل أفكاري مع أعضاء الفريق اآلخرين‬
Another frequent use of UML is drawing diagrams from existing code.
This technique is called reverse engineering, and it helps to understand
and document a system.
‫ تسىم هذه التقنية‬.‫ هو رسم مخططات من كود موجود‬UML ‫استخدام متكرر آخر لـ‬
. ‫وه تساعد عىل فهم النظام وتوثيقه‬
‫ ي‬، ‫بالهندسة العكسية‬
4
We can also use UML to create the detailed blueprint of a system. While
sketches focus only on the essential aspects of a system, the blueprint is
about completeness. Detailed UML blueprints are usually required for
software developed using a Waterfall-approach - and less frequently for
Agile projects.
ً
‫ بينما تركز الرسومات فقط عىل‬.‫تفصيىل للنظام‬
‫ إلنشاء مخطط‬UML ‫يمكننا أيضا استخدام‬
‫ي‬
ً
‫ عادة ما تكون مخططات‬.‫ فإن المخطط يدور حول االكتمال‬، ‫الجوانب األساسية للنظام‬
‫وف كثب من األحيان‬
‫ ي‬- ‫الت تم تطويرها باستخدام نهج الشالل‬
‫ المفصلة مطلوبة للبامج ي‬UML
.Agile ‫أقل لمشاري ــع‬
You can use UML diagrams to describe any system that’s developed
using an object-oriented programming language. UML has become so
popular that it's also used for non-object-oriented projects.
‫ لوصف أي نظام تم تطويره باستخدام لغة برمجة موجهة‬UML ‫يمكنك استخدام مخططات‬
ً ً
ً
‫شائعا جدا لدرجة أنه يستخدم أيضا للمشاري ــع غب الموجهة‬
UML ‫ أصبح‬.‫للكائنات‬
.‫للكائنات‬
5
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
SECTION 5.1 THE USE-CASE DIAGRAM
Let’s start with the use-case diagram. It’s one of the simplest UML
diagrams.
.UML ‫ إنه أحد أبسط مخططات‬.‫لنبدأ بمخطط حالة االستخدام‬
Its purpose is to visualize the functional requirements of the system.
Use-case diagrams show groups of related use-cases. Sometimes they
may include all the use-cases.
ُ
‫ تظهر مخططات حالة االستخدام‬.‫والغرض منه هو تصور المتطلبات الوظيفية للنظام‬
‫ يف بعض األحيان قد تشمل جميع حاالت‬.‫مجموعات من حاالت االستخدام ذات الصلة‬
.‫االستخدام‬
The result is an overview of the system that may include several written
use-cases. You’ll rarely create use-case diagrams for a single use-case
description.
ً .‫والنتيجة ه نظرة عامة عىل النظام قد تتضمن العديد من حاالت االستخدام المكتوبة‬
‫نادرا‬
‫ي‬
‫ئ‬
.‫ستنس مخططات حالة االستخدام لوصف حالة استخدام واحدة‬
‫ما‬
To represent a use-case, we draw an oval in the middle of the screen
and put the title of the use case in it.
‫ نقوم برسم شكل بيضاوي يف منتصف الشاشة ووضع عنوان حالة‬، ‫لتمثيل حالة االستخدام‬
.‫االستخدام فيه‬
“Create a Trip Entry,” “Edit Trip,” “Export App Database” - these are
examples of use-cases from our Travel Expense app mentioned before.
‫ هذه أمثلة‬- "‫ "تصدير قاعدة بيانات التطبيق‬، "‫ "تحرير الرحلة‬، "‫"إنشاء إدخال رحلة‬
ً
.‫لحاالت االستخدام من تطبيق مصاريف السفر المذكور سابقا‬
6
We use stick figures to represent the actors. As you may recall, actors
are human beings or other systems that may interact with our system.
‫ الممثلون هم برس أو أنظمة أخرى‬، ‫ كما قد تتذكر‬.‫نستخدم األشكال الالصقة لتمثيل الممثلي‬
.‫قد تتفاعل مع نظامنا‬
We draw the stick person to the left or the right of the diagram. The
actor’s name goes below the stick figure.
‫ اسم الممثل يذهب إىل ما دون‬.‫التخطيط‬
‫نرسم شخص العصا إىل يسار أو يمي الرسم‬
‫ي‬
.‫الشكل العصا‬
We usually draw the primary actors on the left side and the secondary
ones on the right side of the use-case diagram.
‫عادة ما نرسم الممثلي األساسيي عىل الجانب األيرس واألطراف الثانوية عىل الجانب األيمن‬
.‫من مخطط حالة االستخدام‬
Next, we draw lines to represent the interaction between an actor and a
use-case. A mobile user can create or edit a trip entry, but he cannot
export the app’s database. The power user can perform all these
actions.
7
‫‪UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS‬‬
‫ً‬
‫بعد ذلك ‪ ،‬نرسم خطوطا لتمثيل التفاعل بي الفاعل وحالة االستخدام‪ .‬يمكن لمستخدم‬
‫ّ‬
‫الجوال إنشاء إدخال رحلة أو تعديله ‪ ،‬لكن ال يمكنه تصدير قاعدة بيانات التطبيق‪ .‬يمكن‬
‫للمستخدم القوي تنفيذ كل هذه اإلجراءات‪.‬‬
‫‪We need to visualize our system’s boundaries if it interacts with other‬‬
‫‪systems. For that, we draw a frame around all use-cases and actors that‬‬
‫‪belong to a given system.‬‬
‫نحتاج إىل تصور حدود نظامنا إذا كان يتفاعل مع أنظمة أخرى‪ .‬لذلك ‪ ،‬نرسم ً‬
‫إطارا حول‬
‫تنتىم إىل نظام معي‪.‬‬
‫الت‬
‫ي‬
‫جميع حاالت االستخدام والجهات الفاعلة ي‬
‫‪Let’s say that we’re relying on an external iCloud-based storage. I’ll‬‬
‫‪represent this external system as a separate actor on the right side. I‬‬
‫‪even changed its visual representation to show that it’s not a human‬‬
‫‪actor. Most tools allow you to do that.‬‬
‫لنفبض أننا نعتمد عىل وحدة تخزين خارجية قائمة عىل ‪ .iCloud‬سأقوم بتمثيل هذا النظام‬
‫ئ‬
‫المرئ إلظهار أنه‬
‫أنت غبت تمثيله‬
‫الخارج‬
‫ي‬
‫كعنرص فاعل منفصل عىل الجانب األيمن‪ .‬حت ي‬
‫ي ً‬
‫ً‬
‫ليس ممثال برسيا‪ .‬تسمح لك معظم األدوات بفعل ذلك‪.‬‬
‫‪UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS‬‬
‫‪8‬‬
The “Create a Trip Entry” and the “Edit Trip” use cases would rely on the
cloud to back up their data. So, I connect these use-cases with the
external system.
‫تعتمد حاالت استخدام "إنشاء دخول رحلة" و "تحرير الرحلة" عىل السحابة لنسخ بياناتهم‬
ً
.‫الخارج‬
‫ أقوم بتوصيل حاالت االستخدام هذه بالنظام‬، ‫ لذلك‬.‫احتياطيا‬
‫ي‬
The frame makes it obvious where our app’s boundaries end. Use-case
diagrams provide a clear way to communicate the high-level features
and the scope of the system.
‫ توفر مخططات حالة االستخدام طريقة واضحة‬.‫تنته حدود تطبيقنا‬
‫يوضح اإلطار أين‬
‫ي‬
.‫لتوصيل المبات عالية المستوى ونطاق النظام‬
You can quickly tell what our system does just by looking at this usecase diagram.
.‫يمكنك معرفة ما يفعله نظامنا برسعة بمجرد النظر إىل مخطط حالة االستخدام هذا‬
9
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
This system lets users create new trips and edit existing ones. Power
users can even export the database. The app relies on an external cloud
system to store its data.
‫ يمكن‬.‫يتيح هذا النظام للمستخدمي إنشاء رحالت جديدة وتعديل الرحالت الحالية‬
‫سحائ‬
‫ يعتمد التطبيق عىل نظام‬.‫للمستخدمي المتمرسي حت تصدير قاعدة البيانات‬
‫ي‬
.‫خارج لتخزين بياناته‬
‫ي‬
Such a simple diagram makes it clear what the system does and what it
doesn’t do. A customer or a user can easily see if needed features are
missing. The absence of use cases shows what the system doesn’t do.
‫ يمكن للعميل أو‬.‫التخطيط البسيط ما يفعله النظام وما ال يفعله‬
‫يوضح هذا الرسم‬
‫ي‬
‫ يظهر غياب حاالت‬.‫المستخدم بسهولة معرفة ما إذا كانت المبات المطلوبة مفقودة‬
.‫االستخدام ما ال يفعله النظام‬
The UML use-case diagram includes other artifacts and relationships
between use-cases. We’re going to ignore them as they tend to
overcomplicate our design and the benefits are questionable.
‫ مصنوعات وعالقات أخرى بي حاالت‬UML ‫يتضمن مخطط حالة االستخدام يف‬
.‫ سوف نتجاهلها ألنها تميل إىل تعقيد تصميمنا بشكل مفرط والمزايا موضع شك‬.‫االستخدام‬
You can’t go wrong if you focus on the actors, the use-cases, and their
interactions. You’ll be able to easily create your own use-case diagrams
and communicate your ideas in a clear and concise way.
ً ‫ ستكون‬.‫تخط إذا ركزت عىل الممثلي وحاالت االستخدام وتفاعالتهم‬
‫ئ‬
‫قادرا عىل‬
‫ال يمكنك أن‬
.‫إنشاء مخططات حالة االستخدام الخاصة بك وإيصال أفكارك بطريقة واضحة وموجزة‬
10
Use-case diagrams provide an easy-to-understand overview of the
features of our system.
.‫توفر مخططات حالة االستخدام نظرة عامة سهلة الفهم عىل مبات نظامنا‬
They are not a replacement for written use-case descriptions, though.
Use-case descriptions include more information to ensure that we don’t
miss any of the important details or requirements.
ً
‫ تتضمن أوصاف حالة‬.‫فه ليست بديال عن أوصاف حالة االستخدام المكتوبة‬
، ‫ومع ذلك‬
ً‫ي‬
‫االستخدام مزيدا من المعلومات لضمان عدم تفويت أي من التفاصيل أو المتطلبات‬
.‫المهمة‬
11
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
SECTION 5.2 THE CLASS DIAGRAM
Without any doubt, class diagrams are the most frequently used UML
diagram types. After identifying the entities that form our system, we
start creating class diagrams for each of them.
ً
‫ فإن الرسوم البيانية للفئة ه ر‬، ‫بدون أدئ شك‬
‫ بعد‬.‫استخداما‬
UML ‫أكب أنواع مخططات‬
‫ي‬
.‫ نبدأ يف إنشاء الرسوم البيانية للفصول لكل منها‬، ‫الت تشكل نظامنا‬
‫تحديد الكيانات ي‬
A class is represented on the class diagram as a rectangle with three
compartments. First, we need to list the class’s name.
ً
‫ نحتاج إىل‬، ‫ أوال‬.‫يتم تمثيل فئة يف مخطط الفصل عىل شكل مستطيل مكون من ثالث أقسام‬
.‫رسد اسم الفصل‬
When naming our classes, we must adhere to some rules. These rules
are known as naming conventions. A class name should be a noun in the
singular, and it needs to start with an uppercase letter.
ُ
‫ تعرف هذه القواعد باسم اصطالحات‬.‫ يجب أن نلبم ببعض القواعد‬، ‫عند تسمية فصولنا‬
ً ‫ يجب أن يكون اسم الفصل‬.‫التسمية‬
.‫ ويجب أن يبدأ بحرف كبب‬، ‫اسما بصيغة المفرد‬
If the name consists of multiple words, we need to uppercase each
word, like in this example:
‫ كما‬، ‫ فنحن بحاجة إىل كتابة كل كلمة بأحرف كببة‬، ‫إذا كان االسم يتكون من كلمات متعددة‬
:‫يف هذا المثال‬
12
This style is called UpperCamelCase, which is CamelCase with the first
letter capitalized.
‫ مع كتابة الحرف‬CamelCase ‫ وهو عبارة عن‬، UpperCamelCase ‫يسىم هذا النمط‬
.‫األول بحرف كبب‬
CamelCase is the practice of starting each word in a compound word or
sentence with a capital.
.‫ه ممارسة بدء كل كلمة يف كلمة مركبة أو جملة بحرف كبب‬
‫ ي‬CamelCase
Why do we need rules? Why can’t we just use any character sequence
to name our classes? Well, we could do that.
ً
، ‫لماذا نحتاج القواعد؟ لماذا ال يمكننا استخدام أي تسلسل أحرف لتسمية فصولنا؟ حسنا‬
.‫يمكننا فعل ذلك‬
Yet, a naming convention lets us focus on important issues instead of
arguing over syntax and names. With a commonly accepted set of rules,
we can easily read the source code written by other developers, even if
they’re from another company, country or continent. Standards are
useful.
ً
‫ فإن اصطالح التسمية يتيح لنا البكب عىل القضايا المهمة بدال من الجدل حول‬، ‫ومع ذلك‬
‫ يمكننا بسهولة قراءة‬، ‫ من خالل مجموعة القواعد المقبولة بشكل عام‬.‫بناء الجملة واألسماء‬
.‫ حت لو كانوا من رسكة أو بلد أو قارة أخرى‬، ‫شفرة المصدر المكتوبة بواسطة مطورين آخرين‬
.‫المعايب مفيدة‬
13
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
All right, so our class name should be a noun in UpperCamelCase. Let’s
fill the other two compartments, too. The next one lists the attributes.
ً
ً ‫ يجب أن يكون اسم الفصل الخاص بنا‬، ‫حسنا‬
‫ دعونا نمأل‬.UpperCamelCase ‫اسما يف‬
ً
.‫التاىل يرسد السمات‬
.‫أيضا‬
‫المقصورتي األخريي‬
‫ي‬
The attribute names should be concise, and they should follow the
lowerCamelCase format, that is, with the first letter lowercase and the
first letters of subsequent words in uppercase.
‫ أي أن‬، ‫السفىل‬
‫السفىل‬
‫ ويجب أن تتبع تنسيق الحرف‬، ‫يجب أن تكون أسماء السمات موجزة‬
‫ي‬
‫ي‬
ً
.‫صغبا والحروف األوىل من الكلمات الالحقة بأحرف كببة‬
‫يكون الحرف األول‬
A Trip has a name, it has a creation date (createdAt); it needs to have a
home currency (homeCurrency), a start date (startsAt) and an end date
(endsAt).
‫ لها تاري ــخ إنشاء (تم إنشاؤها يف) ؛ يجب أن يكون لها عملة محلية (عملة‬، ‫رحلة لها اسم‬
.)‫(ينته‬
‫ وتاري ــخ بدء (بداية) وتاري ــخ انتهاء‬، )‫مبلية‬
‫ي‬
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
It’s useful to specify the type of the attribute. We can do that by writing
the data type after the attribute’s name separated by a colon. So, here’s
our Trip class with the attribute names and types:
‫ يمكننا القيام بذلك عن طريق كتابة نوع البيانات بعد اسم‬.‫من المفيد تحديد نوع السمة‬
ً
ً
:‫ إليك فئة الرحلة مع أسماء السمات وأنواعها‬، ‫حسنا‬
.‫السمة مفصوال بنقطتي‬
14
The data types need to be adjusted to whatever programming language
you’re using. This example makes perfect sense in Swift. For ObjectiveC, you may want to use different types, like NSString instead of String
and NSDate for dates.
ً ‫ هذا المثال منطف‬.‫يجب تعديل أنواع البيانات لتالئم أي لغة برمجة تستخدمها‬
‫تماما يف‬
‫ي‬
NSString ‫ مثل‬، ‫ قد ترغب يف استخدام أنواع مختلفة‬، Objective-C ‫ بالنسبة إىل‬.Swift
ً
.‫ للتواري ــخ‬NSDate ‫ و‬String ‫بدال من‬
Even if we leave it as it is, nobody will have issues understanding that
you refer to a String or a Date or an integer.
‫ فلن يواجه أي شخص مشكالت يف فهم أنك تشب إىل سلسلة أو تاري ــخ‬، ‫حت لو تركناه كما هو‬
.‫أو عدد صحيح‬
Next comes the operations compartment. This is where we list the
class’s methods. Method names should be verbs in lowerCamelCase.
‫ يجب أن تكون‬.‫ هذا هو المكان الذي نرسد فيه طرق الفصل‬.‫يأئ قسم العمليات‬
‫بعد ذلك ي‬
.LowerCamelCase ‫أسماء الطرق عبارة عن أفعال مكتوبة بأحرف‬
15
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
We can also specify method arguments. The parameters appear within
the parenthesis as name-data type pairs, like in setName(value: String)
ً
‫ تظهر المعلمات داخل األقواس كأزواج من نوع بيانات‬.‫يمكننا أيضا تحديد حجج الطريقة‬
. .)String :‫ (القيمة‬setName ‫ كما هو الحال يف‬، ‫االسم‬
To show that a method returns something, we add a colon after the
closing parenthesis followed by the return type:
ُ
ً
ً
:‫متبوعا بنوع اإلرجاع‬
‫ نضيف نقطتي بعد قوس اإلغالق‬، ‫لتوضيح أن العملية ترجع شيئا ما‬
getName(): String
And we can also have methods that have arguments and a return type.
ً
.‫أيضا أن يكون لدينا عمليات تحتوي عىل وسيطات ونوع إرجاع‬
‫ويمكننا‬
16
getEntries(from: Date, to: Date): List takes two arguments called
fromDate and endDate, both of type Date. The method returns a List of
entries. This list could contain multiple values or just a single value, or it
could even be empty. We don’t specify this in our class diagram.
‫ و‬fromDate ‫ تأخذ القائمة وسيطتي تسىم‬:to: Date) ،getEntries (from: Date
‫ يمكن أن تحتوي‬.‫ تقوم الطريقة بإرجاع قائمة اإلدخاالت‬.Date ‫ كالهما من النوع‬، endDate
‫ نحن ال نحدد هذا يف‬.‫ أو قد تكون فارغة‬، ‫هذه القائمة عىل قيم متعددة أو قيمة واحدة فقط‬
.‫مخطط الفصل لدينا‬
SECTION 5.3 VISIBILITY
Now, let’s talk about visibility. UML allows us control who can access the
attributes and the methods of our classes.
‫ التحكم يف من يمكنه الوصول إىل سمات وطرق‬UML ‫ يتيح لنا‬.‫ لنتحدث عن الرؤية‬، ‫اآلن‬
.‫فصولنا الدراسية‬
We have the following visibility levels in UML:
:UML ‫لدينا مستويات الرؤية التالية يف‬
•
+ means public visibility. A class method or attribute marked as
public can be used by code outside of the object.
‫الت تم تميبها‬
‫ يمكن استخدام طريقة الفئة أو السمة ي‬.‫تعت الرؤية العامة‬
‫) ي‬+ ( •
.‫عىل أنها عامة بواسطة رمز خارج الكائن‬
• - denotes private access. Private attributes and methods can
only be used within the class that defines them. Elements
marked as private can’t be accessed directly from other classes.
‫ ال يمكن استخدام السمات واألساليب الخاصة إال‬.‫) تشب إىل الوصول الخاص‬-( •
‫ العنارص الممبة عىل أنها خاصة ال يمكن الوصول إليها‬.‫داخل الفصل الذي يحددها‬
.‫مبارسة من الفئات األخرى‬
• UML uses # to mark an element as protected. Protected
visibility means that only child classes (and the defining class)
will be able to access that attribute or method.
17
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
‫تعت الرؤية المحمية أن الفئات‬
‫ لتميب عنرص عىل أنه‬# UML ‫• يستخدم‬
‫ ي‬.‫محىم‬
‫ي‬
‫الفرعية فقط (والفئة التعريفية) ستكون قادرة عىل الوصول إىل تلك السمة أو‬
.‫الطريقة‬
• ~ denotes package visibility, which makes sense in some
programming languages that let us group our code into logical
units and provide a namespace for this group. Using package
visibility, we make our elements available within its enclosing
package.
‫الت تسمح لنا‬
‫ وهو أمر‬، ‫يشب ~ إىل رؤية الحزمة‬
‫منطف يف بعض لغات البمجة ي‬
‫ي‬
.‫بتجميع الكود الخاص بنا يف وحدات منطقية وتوفب مساحة اسم لهذه المجموعة‬
.‫ نجعل عنارصنا متاحة داخل الحزمة المرفقة‬، ‫باستخدام رؤية الحزمة‬
•
UML provides these visibility tags, but it’s up to us to adapt it to the
language we’re using. There’s one rule that’s commonly applicable to all
object-oriented languages:
.‫الت نستخدمها‬
‫ ولكن األمر مبوك لنا لتكييفها مع اللغة ي‬، ‫ عالمات الرؤية هذه‬UML ‫توفر‬
:‫هناك قاعدة واحدة تنطبق بشكل عام عىل جميع اللغات الشيئية‬
Expose only as much as needed and hide everything else.
.‫شء آخر‬
‫فضح فقط قدر الحاجة وإخفاء كل ي‬
Class attributes will usually have private or protected access. We should
provide public setters and getters instead of allowing everybody to
access our class’s data. This lets us control what the callers do with our
class’s attributes.
ً
ُ ‫الم َحددين‬
ُ ‫ يجب أن نوفر‬.‫عادة ما يكون لسمات الفئة وصول خاص أو محىم‬
‫والمعرفي‬
ِ
‫ي‬
ً
.
‫العامي بدال من السماح للجميع بالوصول إىل بيانات صفنا يتيح لنا ذلك التحكم يف ما يفعله‬
.‫المتصلون بسمات صفنا‬
In our Trip class, we could make the name attribute public. Callers could
set and retrieve it, which seems to work as expected.
‫ والذي‬، ‫ يمكن للمتصلي ضبطه واسبداده‬.‫ يمكننا جعل سمة االسم عامة‬، ‫يف فصل الرحلة‬
.‫يبدو أنه يعمل كما هو متوقع‬
18
But, what if we need to make sure that a Trip’s name is never shorter
than say three characters?
‫ ماذا لو احتجنا إىل التأكد من أن اسم الرحلة ال يكون أقرص من ذكر ثالثة أحرف؟‬، ‫ولك ن‬
There’s no way to enforce this requirement.
.‫ال توجد طريقة لفرض هذا المطلب‬
Another example. The trip’s start date needs to be earlier than its end
date. Yet, callers can freely set any start or end date.
‫ يمكن للمتصلي‬، ‫ ومع ذلك‬.‫ يجب أن يكون تاري ــخ بدء الرحلة قبل تاري ــخ انتهائها‬.‫مثال آخر‬
.‫تعيي أي تاري ــخ بدء أو تاري ــخ انتهاء بحرية‬
19
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
I’m going to change the visibility of all these attributes to private. Now,
we can access them exclusively from within the class’s own methods.
After this change, other objects can’t set or retrieve these attributes.
ً ‫ يمكننا الوصول إليها ح‬، ‫ اآلن‬.‫سأقوم بتغيب مستوى رؤية كل هذه السمات إىل خاص‬
‫رصيا من‬
.‫داخل األساليب الخاصة بالفصل‬
.‫ ال يمكن للكائنات األخرى تعيي أو اسبداد هذه السمات‬، ‫بعد هذا التغيب‬
They are, well, private to the Trip class.
ً
.‫ خاصون بفئة الرحلة‬، ‫حسنا‬
، ‫هم‬
Awesome! But then, how do we set, retrieve or modify them?
‫ كيف يمكننا ضبطها أو اسبدادها أو تعديلها؟‬، ‫مدهش! ولكن بعد ذلك‬
Here’s the solution: I provide public getters and setters for each of these
attributes:
:‫ أقدم معلومات عامة ومحددات لكل سمة من هذه السمات‬:‫إليكم الحل‬
20
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Now we can check whether the name is at least three characters long
by validating the name parameter in the setName() method. If it’s
shorter, we just print a warning message and return.
‫يمكننا اآلن التحقق مما إذا كان االسم يتكون من ثالثة أحرف عىل األقل عن طريق التحقق من‬
‫ فنحن نطبع رسالة تحذير‬، ‫ إذا كانت أقرص‬.)( setName ‫صحة معلمة االسم يف طريقة‬
.‫ونرجع‬
class Trip {
public func setName(value: String) {
if value.count < 3 {
print("Name too short!")
return
}
//...
}
}
Also, we validate the start and the end date in the corresponding
setters.
ً
.‫ نتحقق من صحة تاري ــخ البدء واالنتهاء يف المحددات المقابلة‬، ‫أيضا‬
public func setStartDate(date: Date) {
if date > endDate {
print("Trip's start date > end date")
return
}
//...
}
public func setEndDate(date: Date) {
21
if date < startDate {
print("Trip's end date < start date")
return
}
//...
}
We are now in full control of our class’s internal data. Setters let us
check the input argument, and getters allow us to modify the value
before returning it. For example, we could return a date in the user’s
time zone.
‫ تسمح لنا الحروف بفحص وسيطة‬.‫نحن اآلن نتحكم بشكل كامل يف البيانات الداخلية لفصلنا‬
‫ يمكننا إرجاع‬، ‫ عىل سبيل المثال‬.‫ وتسمح لنا الحروف بتعديل القيمة قبل إعادتها‬، ‫اإلدخال‬
.‫تاري ــخ يف المنطقة الزمنية للمستخدم‬
So far, we’ve seen how to represent a single class. Class diagrams let us
also show the relationships between the classes in our system. We’ll
talk about relationships next.
ً
‫ تتيح لنا مخططات الفصل أيضا إظهار العالقات‬.‫لقد رأينا حت اآلن كيفية تمثيل فئة واحدة‬
.‫ سنتحدث عن العالقات بعد ذلك‬.‫بي الفئات يف نظامنا‬
SECTION 5.4
ASSOCIATIONS
The next logical step after identifying the key classes in our system is
figuring out the relationships between them. Use-cases or user stories
will help us during this process.
.‫ه معرفة العالقات بينها‬
‫الخطوة المنطقية التالية بعد تحديد الفئات الرئيسية يف نظامنا ي‬
.‫ستساعدنا حاالت االستخدام أو قصص المستخدم خالل هذه العملية‬
22
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Here’s one of the functional requirements of the TravelExpense app.
TravelExpense. ‫إليك أحد المتطلبات الوظيفية لتطبيق‬
“As a traveler, I want to track my expenses while abroad, so that I don’t
exceed my budget.”
ً
".‫انيت‬
‫ أرغب يف تتبع‬، ‫مسافرا‬
‫"بصفت‬
‫ي‬
‫ حت ال أتجاوز مب ي‬، ‫نفقائ أثناء تواجدي بالخارج‬
‫ي‬
We have a Trip and an Expense class. Each trip will include it’s travel
expenses. So, there needs to be some relationship between the Trip
and the Expense class.
‫ يجب أن تكون هناك‬، ‫ لذلك‬.‫ ستشمل كل رحلة نفقات السفر‬.‫لدينا فئة الرحلة والمرصوفات‬
.‫عالقة بي الرحلة وفئة المصاريف‬
To express this relationship, we draw a solid line between these classes.
ً
ً
.‫متينا بي هذه الفئات‬
‫ نرسم خط ا‬، ‫للتعبب عن هذه العالقة‬
This line represents an association. The association tells us that the
classes refer to each other.
.‫ تخبنا الجمعية أن الفصول تشب إىل بعضها البعض‬.‫هذا الخط يمثل ارتباط‬
We can be more specific here. The Trip class needs to know about its
expenses. Should the Expense class also know about the Trip class?
ً
‫يمكننا أن نكون ر‬
‫ هل يجب أن يعرف‬.‫ يحتاج فصل الرحلة إىل معرفة نفقاته‬.‫أكب تحديدا هنا‬
ً
‫فصل المصاريف أيضا عن فئة الرحلة؟‬
We’ve already talked about the drawbacks of tightly coupled systems.
Tight coupling is something that you should definitely try to avoid. Let
me illustrate the issue it causes.
23
‫شء يجب أن‬
‫ االقبان الضيق هو ي‬.‫لقد تحدثنا بالفعل عن عيوب األنظمة شديدة االقبان‬
.‫الت تسببها‬
‫ اسمحوا يىل أن أوضح المشكلة ي‬.‫تحاول بالتأكيد تجنبه‬
The Trip refers to the Expense class. That's fine, since a trip can have
expenses associated with it. What happens if also the Expense refers to
the Trip class?
.‫ ألن الرحلة يمكن أن يكون لها نفقات مرتبطة بها‬، ‫ ال بأس‬.‫تشب الرحلة إىل فئة المصاريف‬
ً
‫ماذا يحدث إذا كانت المصاريف تشب أيضا إىل فئة الرحلة؟‬
Because of this reference, if we tried to use the Expense class in other
parts of the system, we’d need to also bring the Trip class with it.
، ‫ إذا حاولنا استخدام فئة المصاريف يف أجزاء أخرى من النظام‬، ‫بسبب هذا المرجع‬
ً
.‫أيضا إىل إحضار فئة الرحلة معها‬
‫فسنحتاج‬
This doesn’t make sense, as we should be able to use an Expense
without a Trip.
.‫ حيث يجب أن نكون قادرين عىل استخدام المصاريف بدون رحلة‬، ‫منطف‬
‫هذا غب‬
‫ي‬
UML lets us express directed associations. By drawing a solid line that
ends with an open arrowhead, we show that only one of the classes
24
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
refers to the other one. The arrow points to the class that’s referred to
by the other class.
‫ينته برأس سهم‬
‫ من خالل رسم خط متصل‬.‫ التعبب عن االرتباطات الموجهة‬UML ‫يتيح لنا‬
‫ي‬
‫ يشب السهم إىل الفصل الذي يشب إليه‬.‫ نظهر أن فئة واحدة فقط تشب إىل األخرى‬، ‫مفتوح‬
.‫الفصل اآلخر‬
In our current example, the association is bi-directional. Let’s change it
to a directed association.
.‫ دعونا نغبها إىل ارتباط موجه‬.‫ تكون الرابطة ثنائية االتجاه‬، ‫الحاىل‬
‫يف مثالنا‬
‫ي‬
Now it shows that the Expense is associated with the Trip, but the
Expense class doesn’t know anything about the Trip class.
‫شء عن فئة‬
‫ لكن فئة المصاريف ال تعرف أي ي‬، ‫يظهر اآلن أن المصاريف مرتبطة بالرحلة‬
.‫الرحلة‬
A Trip will usually have multiple expenses. We can represent the
multiplicity of associated objects as follows:
:‫التاىل‬
‫ يمكننا تمثيل تعدد الكائنات المرتبطة عىل النحو ي‬.‫عادة ما يكون للرحلة نفقات متعددة‬
•
- a Trip can have zero or more Expenses
‫ يمكن أن تحتوي الرحلة عىل مصاريف صفرية أو ر‬‫أكب‬
-
1 - a Trip must have exactly one homeCurrency
‫ يجب أن تحتوي الرحلة عىل عملة مبلية واحدة بالضبط‬- 1 0..1 - a Trip may or may not have a single note
-
‫ قد تحتوي الرحلة أو ال تحتوي عىل مالحظة واحدة‬- 1..0 -
-
25
Associations can show multiplicities at both ends of the line. The default
multiplicity is one. So, if there’s no multiplicity shown, you can safely
assume it’s one.
‫ إذا لم‬، ‫ لذلك‬.‫اض هو واحد‬
‫يمكن أن تظهر الجمعيات تعدد يف‬
‫ التعدد االفب ي‬.‫طرف السطر‬
‫ي‬
.‫ فيمكنك افباض أنه واحد‬، ‫يكن هناك تعدد معروض‬
We can also display the name of the class property for the given
association.
ً
.‫أيضا عرض اسم خاصية الفئة لالرتباط المحدد‬
‫يمكننا‬
The association isn’t the only kind of relationship we can have between
classes. Next, we’re going to talk about generalization.
، ‫ بعد ذلك‬.‫الت يمكن أن تكون لدينا بي الطبقات‬
‫الرابطة ليست النوع الوحيد من العالقات ي‬
.‫سوف نتحدث عن التعميم‬
26
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
SECTION 5.5 GENERALIZATION
In UML, we use generalization to express that one model element is
based on another model element. Generalization is represented as a
solid line with a hollow arrowhead that points to the parent.
‫ نستخدم التعميم للتعبب عن أن عنرص نموذج واحد يعتمد عىل عنرص نموذج‬، UML ‫يف‬
.‫ يتم تمثيل التعميم كخط متصل برأس سهم مجوف يشب إىل األصل‬.‫آخر‬
Let’s say that we need a special Trip class for our business trips.
.‫لنفبض أننا بحاجة إىل فئة رحلة خاصة لرحالت العمل لدينا‬
BusinessTrip would inherit from the Trip class and this is how we
represent it in UML:
:UML ‫الت نمثلها يف‬
‫ه الطريقة ي‬
‫سوف ترث رحلة العمل من فئة الرحلة وهذه ي‬
Because BusinessTrip inherits everything from its parent, we must only
specify the attributes and operations that are specific to the child.
ً
‫ يجب علينا فقط تحديد السمات‬، ‫شء من الرسكة األم‬
‫ يرث كل ي‬BusinessTrip ‫نظرا ألن‬
.‫والعمليات الخاصة بالطفل‬
27
A parent can have multiple children.
.‫يمكن أن يكون للوالد عدة أطفال‬
And we can also have child classes that inherit from different parents.
ً
.‫أيضا أن نحصل عىل فصول أطفال ترث من آباء مختلفي‬
‫ويمكننا‬
Some programming languages support multiple inheritance; C++, Perl,
Python - just to name a few.
‫ عىل سبيل المثال ال‬- Python ،Perl ،C ++ ‫تدعم بعض لغات البمجة الوراثة المتعددة ؛‬
.‫الحرص‬
Many modern programming languages only allow single inheritance,
that is, inheriting from one parent class. Single inheritance reduces the
complexity and avoids the ambiguity that comes with multiple
inheritance.
‫ أي الوراثة من فئة أصل‬، ‫تسمح العديد من لغات البمجة الحديثة فقط بالمباث الفردي‬
.‫يأئ مع الوراثة المتعددة‬
‫ المباث الفردي يقلل من التعقيد ويتجنب الغموض الذي ي‬.‫واحد‬
28
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Some argue that multiple inheritance has more benefits than
drawbacks. However, it’s certainly easier to make mistakes when using
multiple inheritance.
‫يجادل البعض بأن الوراثة المتعددة لها فوائد ر‬
‫ فمن األسهل‬، ‫ ومع ذلك‬.‫أكب من العيوب‬
.‫بالتأكيد ارتكاب األخطاء عند استخدام الوراثة المتعددة‬
UML doesn’t restrict generalization to classes. It can also be used in
usecase or component diagrams. This lets us indicate that a child
element receives it’s parent’s attributes, operations and relationships.
ً
‫ يمكن استخدامه أيضا يف حالة االستخدام أو المخططات‬.‫ التعميم عىل الفئات‬UML ‫ال يقيد‬
.‫الفرع يتلف سمات وعمليات وعالقات الوالدين‬
‫ يتيح لنا هذا اإلشارة إىل أن العنرص‬.‫المكونة‬
‫ي‬
SECTION 5.6 DEPENDENCY, AGGREGATION, COMPOSITION AND
REALIZATION
We talk about a dependency relationship if changes in one of the
classes may cause changes to the other.
.‫نتحدث عن عالقة تبعية إذا كانت التغيبات يف أحد الفصول قد تسبب تغيبات يف اآلخر‬
In UML, dependency is represented as a dashed line that ends with
an open arrowhead. The arrow points to the dependency.
‫ يشب السهم إىل‬.‫ينته برأس سهم مفتوح‬
‫ يتم تمثيل التبعية كخط متقطع‬، UML ‫يف‬
‫ي‬
.‫التبعية‬
A dependency is a directed relationship.
.‫ه عالقة موجهة‬
‫التبعية ي‬
29
Dependency is often confused with Association, but there’s a big
difference. Association indicates that a class has an attribute of the
other class’s type.
ً
‫ يشب االرتباط إىل أن الفصل‬.‫ ولكن هناك فرق كبب‬، ‫غالبا ما يتم الخلط بي التبعية واالرتباط‬
.‫اش له سمة من نوع الفصل اآلخر‬
‫الدر ي‬
Whereas dependency is usually created when a class receives a
reference to the other class (for instance, through a member function
parameter).
ً
‫يف حي يتم إنشاء التبعية عادة عندما يتلف الفصل إشارة إىل الفئة األخرى (عىل سبيل المثال‬
.)‫ من خالل معلمة وظيفة العضو‬،
AGGREGATION AND COMPOSITION
Aggregation represents a part-whole relationship and is drawn as a solid
line with a hollow diamond at the owner’s end.
.‫كامل ويتم رسمه كخط متصل مع ماسة مجوفة يف نهاية المالك‬-‫يمثل التجميع عالقة جزء‬
30
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
This relationship is considered redundant because it expresses the same
thing as the association. So, these two diagrams are equivalent:
‫ هذين‬، ‫ إذن‬.‫السء مثل االرتباط‬
‫تعتب هذه العالقة زائدة عن الحاجة ألنها تعب عن نفس ي‬
:‫المخططي متكافئي‬
Composition is a stronger form of association. It shows that the parts
live and die with the whole. In other words, composition implies
ownership:
‫ بمعت‬.‫ يظهر أن األجزاء تعيش وتموت مع الكل‬.‫التكوين هو شكل أقوى من أشكال االرتباط‬
:‫يعت الملكية‬
‫ البكيب ي‬، ‫آخر‬
when the owning object is destroyed, the contained objects will be
destroyed, too.
ً
.‫أيضا‬
‫ سيتم تدمب الكائنات الموجودة‬، ‫عندما يتم تدمب الكائن المالك‬
31
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
The composition is represented as a filled diamond on the owner’s
end connected with a solid line with the contained class.
.‫يتم تمثيل التكوين كألماس معبأ يف نهاية المالك متصل بخط متصل مع الفئة المضمنة‬
32
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
The Expenses of a trip can’t exist without the Trip. If we delete the
Trip instance,
، ‫ إذا حذفنا مثيل الرحلة‬.‫ال يمكن أن توجد نفقات الرحلة بدون الرحلة‬
its expenses are going to be removed, too:
ً
:‫أيضا‬
‫ستتم إزالة نفقاتها‬
Realization indicates that a class implements the behavior specified
by another model element.
.‫يشب اإلدراك إىل أن الفئة تنفذ السلوك المحدد بواسطة عنرص نموذج آخر‬
It is represented as a hollow triangle on the interface end connected
with dashed lines with the implementer classes.
.‫يتم تمثيله كمثلث مجوف عىل نهاية الواجهة متصل بخطوط متقطعة بفئات المنفذ‬
33
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
We could specify an interface to ensure that all current and upcoming
trip classes provide a common set of methods. This is a useful feature
that allows polymorphic behavior.
‫يمكننا تحديد واجهة للتأكد من أن جميع فئات الرحالت الحالية والقادمة توفر مجموعة‬
.‫ هذه مبة مفيدة تسمح بالسلوك متعدد األشكال‬.‫مشبكة من األساليب‬
Here’s a quick summary of the relationships and their graphical
representation:
:‫الرسوم‬
‫يىل ملخص رسي ــع للعالقات وتمثيلها‬
‫ي‬
‫فيما ي‬
34
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
35
SECTION 5.7
SEQUENCE DIAGRAMS
Use case and class diagrams are static diagrams. They are great at
representing the structure of our system.
ُ
.‫ إنها رائعة يف تمثيل هيكل نظامنا‬.‫تعد مخططات الحالة والفئة مخططات ثابتة‬
What if we need to show how the objects interact with each other?
When are objects created and for how long are they around? Static
diagrams can’t answer these questions.
‫ماذا لو احتجنا إىل إظهار كيفية تفاعل األشياء مع بعضها البعض؟ مت يتم إنشاء األشياء وإىل‬
.‫مت تكون موجودة؟ الرسوم البيانية الثابتة ال يمكنها اإلجابة عىل هذه األسئلة‬
UML provides dynamic diagrams to represent how objects communicate
with each other. The most common dynamic diagram is the sequence
diagram.
‫ الرسم‬.‫ مخططات ديناميكية لتمثيل كيفية تواصل الكائنات مع بعضها البعض‬UML ‫يوفر‬
ً
‫ر‬
.‫شيوعا هو مخطط التسلسل‬
‫األكب‬
‫الديناميك‬
‫التخطيط‬
‫ي‬
‫ي‬
We use the sequence diagram to describe the flow of logic in one
particular scenario.
.‫نستخدم مخطط التسلسل لوصف تدفق المنطق يف سيناريو واحد معي‬
A sequence diagram starts by drawing boxes at the top of the page.
Each box represents an object. Since these are objects, we name them
differently. “aTrip” instead of “Trip” and “anExpense” rather than
“Expense.”
ً .‫ كل مربــع يمثل كائن‬.‫يبدأ مخطط التسلسل برسم مربعات ف أعىل الصفحة‬
‫نظرا ألن هذه‬
‫ي‬
ً
ً
‫" بدال من‬an Expense" ‫" و‬Trip" ‫" بدال من‬aTrip" .‫ فإننا نسميها بشكل مختلف‬، ‫كائنات‬
."Expense"
36
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
We can also display the type after the instance’s name separated by a
colon. This may be helpful in some cases:
ً
ً
ً
‫ قد يكون هذا مفيدا يف بعض‬.‫يمكننا أيضا عرض النوع بعد اسم المثيل مفصوال بنقطتي‬
:‫الحاالت‬
The lifeline of an object is represented by the dotted lines beneath each
box. This line shows the time the instance exists during the scenario.
‫ يوضح هذا الخط وقت وجود‬.‫يتم تمثيل شريان الحياة للكائن بالخطوط المنقطة أسفل كل مربع‬
.‫المثيل أثناء السيناريو‬
The sequence diagram also lets us show the messages sent from one
object to the other. A message is basically a method call.
ً
‫ه يف‬
‫ الرسالة ي‬.‫يتيح لنا مخطط التسلسل أيضا إظهار الرسائل المرسلة من كائن إىل آخر‬
.‫األساس استدعاء طريقة‬
Now, let me illustrate the various messages in a practical example. I’ll
be using StarUML, a UML diagramming software that can be
downloaded for free from www.staruml.io.
‫ وهو‬، StarUML ‫ سأستخدم‬.‫عمىل‬
‫ اسمحوا يىل أن أوضح الرسائل المختلفة يف مثال‬، ‫اآلن‬
‫ي‬
ً
www.staruml.io. ‫ يمكن تبيله مجانا من‬UML ‫تخطيط‬
‫برنامج رسم‬
‫ي‬
37
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Let’s assume that we have a persistenceManager object. This object is
responsible for storing and retrieving entities in the app’s local
database.
‫ هذا الكائن مسؤول عن تخزين واسبداد‬.persistentManager ‫لنفبض أن لدينا كائن‬
.‫الكيانات يف قاعدة البيانات المحلية للتطبيق‬
The persistenceManager needs to create and store a TripEntity instance.
First, I add the TripEntity object. The persistenceManager instance
sends a create message to initiate a tripEntity object. The create
message is represented as a dashed line with a stick arrowhead.
ً
‫ أقوم بإضافة‬، ‫ أوال‬.‫ وتخزينه‬TripEntity ‫ إىل إنشاء مثيل‬persistenceManager ‫يحتاج‬
.tripEntity ‫ رسالة إنشاء لبدء كائن‬persistentManager ‫ يرسل مثيل‬.TripEntity ‫كائن‬
.‫يتم تمثيل رسالة اإلنشاء عىل هيئة خط متقطع برأس سهم‬
Next, the persistenceManager sends a regular message to the already
created trip entity. This message corresponds to calling the
addNote(note: String) method on the TripEntity instance. A regular
message is shown as a solid line with a filled arrowhead. We can add
parameters to our messages if we wish:
‫ رسالة عادية إىل كيان الرحلة الذي تم إنشاؤه‬persistentManager ‫ يرسل‬، ‫بعد ذلك‬
‫ سلسلة) يف مثيل‬:‫ (مالحظة‬addNote ‫ تتوافق هذه الرسالة مع استدعاء طريقة‬.‫بالفعل‬
‫ئ‬
‫ يمكننا إضافة معلمات‬.‫ممتىل‬
‫ تظهر الرسالة العادية كخط متصل مع رأس سهم‬.TripEntity
:‫إىل رسائلنا إذا أردنا‬
38
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Although we could display the return message, only do it if it’s
important. Return messages are implicit for synchronous messages, so
we don’t have to display them.
‫ تعتب‬.‫ إال أنها ال تفعل ذلك إال إذا كانت مهمة‬، ‫عىل الرغم من أنه يمكننا عرض رسالة اإلرجاع‬
.‫ لذلك ال يتعي علينا عرضها‬، ‫رسائل اإلرجاع ضمنية للرسائل المبامنة‬
Asynchronous messages are drawn as solid lines with a stick arrowhead.
The controller object sends an asynchronous save(trip: Trip) message to
the persistenceManager. Disk operations are slow, so inserting a new
record into the database is a perfect candidate for an asynchronous call.
‫ يرسل كائن وحدة التحكم‬.‫يتم رسم الرسائل غب المبامنة كخطوط متصلة برأس سهم عصا‬
، ‫ عمليات القرص بطيئة‬.persistentManager ‫ رحلة) إىل‬:‫رسالة حفظ غب مبامن (رحلة‬
.‫مثاىل الستدعاء غب مبامن‬
‫لذا فإن إدخال سجل جديد يف قاعدة البيانات هو مرشح ي‬
When an object sends any async message, it doesn’t need to wait for a
response. The asynchronous call gets executed in the background, and it
39
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
returns once it completes. Unlike synchronous calls, it doesn’t block the
caller.
‫ يتم تنفيذ االستدعاء غب‬.‫داع النتظار الرد‬
‫ فال ي‬، ‫عندما يرسل كائن أي رسالة غب مبامنة‬
‫ فإنه ال يحظر‬، ‫ عىل عكس المكالمات المبامنة‬.‫ ويعود بمجرد اكتماله‬، ‫المبامن يف الخلفية‬
.‫المتصل‬
Asynchronous behavior stands at the core of modern software systems.
They improve responsiveness on multicore processors and provide better
user experience because lengthy operations won’t block the user
interface.
‫ تعمل عىل تحسي االستجابة عىل‬.‫السلوك غب المبامن هو جوهر أنظمة البمجيات الحديثة‬
‫المعالجات متعددة النواة وتوفر تجربة مستخدم أفضل ألن العمليات المطولة لن تمنع‬
.‫واجهة المستخدم‬
So, you’ll probably draw async messages a lot.
ً ‫ من المحتمل أن ترسم رسائل غب مبامنة‬، ‫لذلك‬
.‫كثبا‬
The issue is that the difference between regular and async messages is
very subtle: stick arrowhead instead of a filled arrowhead. To avoid
misunderstanding, you can add an extra note to make it visible it’s an
async message.
‫ قم بلصق رأس‬:‫تكمن المشكلة يف أن االختالف بي الرسائل العادية وغب المبامنة دقيق للغاية‬
ً
‫ يمكنك إضافة مالحظة إضافية‬، ‫ لتجنب سوء الفهم‬.‫السهم بدال من رأس السهم المملوء‬
.‫لجعلها مرئية عىل أنها رسالة غب مبامنة‬
We also have self-messages. These represent a method calling another
method of the same object.
ً
.‫ هذه تمثل طريقة استدعاء طريقة أخرى لنفس الكائن‬.‫أيضا رسائل ذاتية‬
‫لدينا‬
40
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
An object can also send a delete message to another object. The
persistenceManager sends a delete message to the tripEntity instance.
ً
‫ رسالة‬persistentManager ‫ يرسل‬.‫يمكن للكائن أيضا إرسال رسالة حذف إىل كائن آخر‬
tripEntity. ‫حذف إىل مثيل‬
The TripEntity gets destroyed, and its lifeline gets terminated by a cross
symbol.
.‫ ويتم إنهاء رسيان الحياة الخاص به بواسطة رمز متقاطع‬، TripEntity ‫يتم تدمب‬
Sequence diagrams should provide an overview of what’s going on in a
given scenario. We don’t try to represent all the method calls precisely.
Instead, we focus on the most relevant parts.
41
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
‫ ال نحاول‬.‫يجب أن تقدم مخططات التسلسل نظرة عامة عىل ما يحدث يف سيناريو معي‬
ً
‫ر‬
.‫األكب صلة‬
‫ نركز عىل األجزاء‬، ‫ بدال من ذلك‬.‫تمثيل جميع استدعاءات الطريقة بدقة‬
Sequence diagrams help us in clarifying the interactions between
objects in a specific scenario. By getting more profound insights into the
inner workings of our objects, we may need to refine their behavior. Or
even add new classes or establish new relationships between our
classes.
‫ من خالل‬.‫تساعدنا مخططات التسلسل يف توضيح التفاعالت بي الكائنات يف سيناريو محدد‬
ً
‫الحصول عىل رؤى ر‬
‫ قد نحتاج إىل تحسي‬، ‫أكب عمقا حول األعمال الداخلية ألجسامنا‬
.‫ أو حت إضافة فصول جديدة أو إنشاء عالقات جديدة بي صفوفنا‬.‫سلوكهم‬
And that’s perfectly fine. The process of designing a software system is
all about finding out what’s missing, what needs to be enhanced or
changed.
ً ‫وهذا جيد ت‬
‫برمج حول اكتشاف ما هو مفقود وما يحتاج‬
‫ تتمحور عملية تصميم نظام‬.‫ماما‬
‫ي‬
.‫إىل تحسي أو تغيب‬
42
SECTION 5.8
ACTIVITY DIAGRAMS
Activity diagrams can be used to describe workflows. The actions are
represented by nodes. We start an activity diagram with an initial node
drawn as a small, filled circle. We can then transition to the next node.
The transition is called flow, and it’s shown as a line that ends with an
open arrowhead. The arrow points the direction of the logic flow from
one action to the other.
‫ يتم تمثيل اإلجراءات بواسطة‬.‫يمكن استخدام مخططات النشاط لوصف مهام سب العمل‬
ً ‫ نبدأ‬.‫العقد‬
ً
‫ يمكننا بعد‬.‫تخطيطيا للنشاط مع عقدة أولية مرسومة كدائرة صغبة مملوءة‬
‫رسما‬
‫ينته برأس‬
‫ ويظهر كخط‬، ‫ ُيطلق عىل االنتقال اسم التدفق‬.‫ذلك االنتقال إىل العقدة التالية‬
‫ي‬
.‫المنطف من إجراء إىل آخر‬
‫ يشب السهم إىل اتجاه التدفق‬.‫سهم مفتوح‬
‫ي‬
Activity diagrams can also express conditional logic. We model a decision
node as a diamond. It has a single incoming flow and two or more
outbound flows.
ً
‫ لها‬.‫ نصمم عقدة القرار عىل أنها ماسة‬.‫ط‬
‫الرس‬
‫المنطق‬
‫عن‬
‫ا‬
‫أيض‬
‫يمكن أن تعب مخططات النشاط‬
‫ي‬
‫تدفق وارد واحد واثنان أو ر‬
.‫أكب من التدفقات الصادرة‬
43
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
Each outbound flow has a guard, which is a Boolean condition placed
inside square brackets. The guards need to be mutually exclusive.
Whenever we reach a decision, we can choose only one of the outbound
flows.
.‫ وهو عبارة عن حالة منطقية موضوعة داخل أقواس مربعة‬، ‫واف‬
‫يحتوي كل تدفق صادر عىل ي‬
‫ يمكننا اختيار واحد فقط من‬، ‫ عندما نتوصل إىل قرار‬.‫يجب أن يكون الحراس حرصيي‬
.‫التدفقات الصادرة‬
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
After a decision, the flows can be merged using a merge activity. A
merge has multiple input flows and a single output flow.
‫ يحتوي الدمج عىل تدفقات‬.‫ يمكن دمج التدفقات باستخدام نشاط الدمج‬، ‫بعد اتخاذ القرار‬
.‫إدخال متعددة وتدفق إخراج واحد‬
44
Activity diagrams support parallel behavior. To express concurrent flows,
we use a fork drawn as a thick horizontal line. A fork has one incoming
flow and several outgoing concurrent flows.
‫ نستخدم شوكة‬، ‫ للتعبب عن التدفقات المبامنة‬.‫مخططات النشاط تدعم السلوك الموازي‬
‫ تحتوي الشوكة عىل تدفق وارد واحد وعدة تدفقات مبامنة‬.‫مرسومة كخط أف يف سميك‬
.‫صادرة‬
We need to synchronize the tasks that execute concurrently. For
example, we can’t display the image while it’s being read from the local
persistence or downloaded from the server. A join represents a
synchronization point.
‫ ال يمكننا‬، ‫ عىل سبيل المثال‬.‫الت يتم تنفيذها بشكل مبامن‬
‫نحن بحاجة إىل مزامنة المهام ي‬
‫ تمثل الصلة نقطة‬.‫عرض الصورة أثناء قراءتها من المثابرة المحلية أو تبيلها من الخادم‬
.‫البامن‬
The final node represents the end of the workflow.
.‫تمثل العقدة النهائية نهاية سب العمل‬
45
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
The following activity diagram describes a simplified version of the trip
creation process.
.‫التاىل نسخة مبسطة من عملية إنشاء الرحلة‬
‫يصف مخطط النشاط ي‬
We begin with the initial node. The user decides to create a new trip.
.‫ يقرر المستخدم إنشاء رحلة جديدة‬.‫نبدأ بالعقدة األولية‬
46
Next, he’s asked to type the trip’s name. Now, the app needs to check
whether a trip with the same name already exists.
ُ
‫ يحتاج التطبيق إىل التحقق مما إذا كانت هناك‬، ‫ اآلن‬.‫ طلب منه كتابة اسم الرحلة‬، ‫بعد ذلك‬
. ‫رحلة بنفس االسم موجودة بالفعل‬
If it does, we prompt the user to enter a new name or cancel the trip
creation process. If he decides to cancel the flow, we end the activity.
Otherwise, we validate the name again.
‫ إذا قرر‬.‫ فإننا نطلب من المستخدم إدخال اسم جديد أو إلغاء عملية إنشاء الرحلة‬، ‫إذا حدث ذلك‬
.‫ نقوم بالتحقق من صحة االسم مرة أخرى‬، ‫ خالف ذلك‬.‫ننه النشاط‬
‫ فإننا ي‬، ‫إلغاء التدفق‬
47
UML AND OBJECT-ORIENTED DESIGN FOUNDATIONS
If the trip name isn't taken, we let the user fill the remaining trip data.
Finally, the user hits the save button. We may also want to let him cancel
the process here.
ً .‫ فسنسمح للمستخدم بملء بيانات الرحلة المتبقية‬، ‫إذا لم يتم أخذ اسم الرحلة‬
‫ يضغط‬، ‫أخبا‬
ً
.‫أيضا يف السماح له بإلغاء العملية هنا‬
‫ قد نرغب‬.‫المستخدم عىل زر الحفظ‬
Now, I’ll use a fork to show that we perform some actions in parallel.
Storing the new trip into the local persistence and uploading it to the cloud
server happen concurrently.
‫ يتم تخزين الرحلة الجديدة يف‬.‫ سأستخدم شوكة إلظهار أننا نقوم ببعض اإلجراءات بالتوازي‬، ‫اآلن‬
.‫السحائ بشكل مبامن‬
‫المثابرة المحلية وتحميلها عىل الخادم‬
‫ي‬
48
If both actions succeed, we inform the user about the successful trip
creation, and we’re done.
.‫ وقد انتهينا‬، ‫ فإننا نبلغ المستخدم بإنشاء رحلة ناجحة‬، ‫إذا نجح كال اإلجراءين‬
We can add more details and further actions to our activity diagram if
that’s useful.
ً
.‫مفيدا‬
‫يمكننا إضافة المزيد من التفاصيل واإلجراءات إىل مخطط أنشطتنا إذا كان ذلك‬
The activity diagram is a useful technique to represent behavioral logic.
I wouldn’t recommend it when working with nontechnical people,
though.
‫أوض به عند العمل مع أشخاص‬
‫ ال‬.‫السلوك‬
‫مخطط النشاط هو تقنية مفيدة لتمثيل المنطق‬
‫ي‬
‫ي‬
.‫غب تقنيي‬
49
SECTION 5.9
STATECHART DIAGRAMS
The Statechart or State Machine diagram models how an object
transitions from one state to another over its lifetime.
‫ كيف ينتقل كائن من حالة إىل‬State Machine ‫ أو مخطط‬Statechart ‫يوضح مخطط‬
.‫أخرى عىل مدار حياته‬
It describes the state changes of an object in response to certain events.
.‫يصف تغبات حالة كائن ما استجابة ألحداث معينة‬
A state is a condition in which an object exists. Think of object states like
New, Pending Changes or Completed.
‫ فكر يف حاالت الكائن مثل التغيبات الجديدة أو المعلقة أو‬.‫ه حالة يوجد فيها كائن‬
‫الحالة ي‬
.‫المكتملة‬
These states can change when some event gets triggered. The Pending
Changes state transitions to Saved after a successful save event.
‫ تنتقل حالة التغيبات المعلقة‬.‫يمكن أن تتغب هذه الحاالت عندما يتم تشغيل بعض األحداث‬
.‫إىل تم الحفظ بعد حدث حفظ ناجح‬
And the Saved state will change to the final Terminated state if the
object is deleted.
.‫وستتغب الحالة المحفوظة إىل حالة اإلنهاء النهائية إذا تم حذف الكائن‬
The state machine diagram starts with an initial state. This is not a real
state, but rather the entry point. States are drawn as rectangles with
rounded corners with the state’s name. The transitions from one state
to another are shown as lines that end in an open arrow.
‫ يتم‬.‫ه نقطة الدخول‬
‫ بل ي‬، ‫ هذه ليست دولة حقيقية‬.‫يبدأ مخطط آلة الحالة بالحالة األولية‬
‫ تظهر االنتقاالت من حالة إىل أخرى‬.‫رسم الحاالت كمستطيالت بزوايا دائرية مع اسم الوالية‬
.‫تنته بسهم مفتوح‬
‫كخطوط‬
‫ي‬
50
Each transition can be labeled with an event name and a guard.
.‫يمكن تسمية كل انتقال باسم حدث وحارس‬
The guard appears between angle brackets; it’s a Boolean condition that
needs to be true for the state change to occur.
‫يظهر الحارس بي قوسي زاوية ؛ إنها حالة منطقية يجب أن تكون صحيحة حت يحدث‬
.‫تغيب الحالة‬
Let’s assume that pending changes can only be saved if the device is
connected to the internet. We can represent conditional logic in
statechart diagrams as follows:
ً
‫ يمكننا تمثيل‬.‫لنفبض أنه ال يمكن حفظ التغيبات المعلقة إال إذا كان الجهاز متصال باإلنبنت‬
:‫التاىل‬
‫ عىل النحو ي‬statechart ‫ط يف مخططات‬
‫المنطق الرس ي‬
The final state shows that the state machine is completed, and it also
implies the deletion of the object.
. ‫تعت حذف الكائن‬
‫ كما أنها ي‬، ‫توضح الحالة النهائية أن آلة الحالة قد اكتملت‬
Use statechart diagrams to describe the object states of a system while
identifying the events responsible for the state changes.
‫استخدم مخططات الحالة لوصف حاالت كائن النظام أثناء تحديد األحداث المسؤولة عن‬
. ‫تغيبات الحالة‬
51
1 great software development
Pleasing your customer
I used to think all programmers got
paid in bananas for their projects...
but now that I’m developing great
software, I get cold, hard cash.
If your customer’s unhappy, everyone’s unhappy!
Every great piece of software starts with a customer’s big idea. It’s your job as
a professional software developer to bring that idea to life. But taking a vague
idea and turning it into working code—code that satisfies your customer—isn’t
so easy. In this chapter you’ll learn how to avoid being a software development
casualty by delivering software that is needed, on time, and on budget. Grab
your laptop, and let’s set out on the road to shipping great software.
!‫ فالجميع غير سعيد‬،‫إذا كان عميلك غير سعيد‬
‫ لكن أخذ فكرة غامضة وتحويلها إلى رمز عمل‬.‫كل برنامج رائع يبدأ بفكرة العميل الكبيرة إنها وظيفتك كمطور برامج محترف إلحياء هذه الفكرة‬
‫يرضي عميلك ليس باألمر السهل في هذا الفصل ستتعلم كيفية تجنب الوقوع ضحية لتطوير البرمجيات عن طريق تقديم البرامج المطلوبة وفي‬
‫ ودعونا ننطلق على طريق شحن برامج رائعة‬،‫الوقت المحدد وعلى الميزانية االستيالء على الكمبيوتر المحمول الخاص بك‬
this is a new chapter
1
Tom’s Trails
Tom’s Trails is going online
Trekkin’ Tom has been providing world-famous trail guides and
equipment from his shack in the Rockies for years. Now, he wants
to ramp up his sales using a bit of the latest technology.
‫مسارات توم تسير على اإلنترنت‬
،‫ في جبال روكي لمدة عام‬lus shack ‫ من‬qupinent‫ يقرب أدلة درب رائعة عالميا وم‬Trekkin' Tom ‫كان‬
‫اآلن؛ إنه يريد زيادة مبيعاته باستخدام القليل من أحدث التقنيات‬
No one does trail guides
like mine...But the big TrailMix
Conference is coming, and I want
to show everybody what the next
evolution in hiking looks like, Webstyle.
2
Chapter 1
great software development
Most projects have two major concerns
Talk to most customers and, besides their big idea,
they’ve probably got two basic concerns:
‫معظم المشاريع لديها شاغالن رئيسيان‬
‫ ربما لديهم شاغالن أساسيان؛‬،‫ وإلى جانب فكرتهم الكبيرة‬،‫تحدث إلى معظم العمالء‬
How much will it costY
No surprise here. Most customers want to figure out
how much cash they’ll have to spend. In this case,
though, Tom has a pile of money, so that’s not much
of a concern for him.
‫كم ستتكلف؟‬
،‫ لدى توم كومة من المال‬،‫ على الرغم من ذلك‬،‫ في هذه الحالة‬.‫ يرغب معظم العمالء في معرفة مقدار النقود التي سيتعين عليهم إنفاقها‬.‫ال عجب هنا‬
‫لذلك هذا ليس مصدر قلق كبير بالنسبة له‬
How long will it takeY
The other big constraint is time. Almost no customer
ever says, “Take as long as you want!” And lots of the
time, you have a specific event or date the customer
wants their software ready for.
In Tom’s case, he wants his website available in three
months’ time, ready for the big TrailMix Conference
coming up.
‫كم من الوقت سوف يستغرق؟‬
‫ تقريبا ال يوجد‬.‫القيد الكبير اآلخر هو الوقت‬
‫ "خذ الوقت الذي‬، ‫زبون من أي وقت مضى‬
‫ لديك حدث معين أو‬، ‫تريده!" والكثير من الوقت‬
ً
‫جاهزا لـ‬
‫تاريخ العميل يريد برنامجهم‬
‫ يريد موقعه اإللكتروني متا ًحا في‬.‫في حالة توم‬
‫ وجاهزة لمؤتمر تريل ميكس العالي‬، ‫ثالثة شهور‬
.‫قادم‬
‫ النقد هو قيد في هذا‬، ‫عادة‬
‫ توم لديه المال‬، ‫حالة‬
‫ و األرقام‬، ‫لتجنيبه‬
‫سيتحول إلى ما ينفقه‬
‫كومة أكبر‬
the Big Bang approach
The Big Bang approach to development
With only a month to get finished, there’s no time to waste.
The lead developer Tom hired gets right to work.
‫نهج االنفجار الكبير للتنمية‬
‫ ليس هناك‬، ‫مع وجود شهر واحد فقط على االنتهاء‬
.‫وقت نضيعه‬
‫ يحصل على‬Tom ‫"المطور الرئيسي الذي عينه‬
‫الحق في العمل‬
Here are my rough ideas
for you to get started on.
Some HTML, CSS, a little
backend Java...this will be
a piece of cake.
Code...
...code...
4
Chapter 1
great software development
Flash forward: two weeks later
Tom’s lead developer has pulled out all the stops to build
Tom’s Trails Online, putting all her finest coding skills into
play and producing what she thinks Tom wants her to build.
‫فالش إلى األمام؛ بعد أسبوعين‬
‫ الرئيسي كل ما في وسعه للبناء‬Tom ‫لقد بذل مطور‬
‫ تضع فيها أفضل مهارات‬، Tom's Trails Online
‫البرمجة‬
‫د أن توم يريد‬.‫تلعب وتنتج ما تعتقد أن توم يريد منها أن تبنيها‬
.‫منها أن تبنيها‬
Whew! That was hard work!
I’ve been coding like crazy,
working stupid hours, but at
least now it’s time to collect
that paycheck...
...Deliver!
...more
code...
‫ ثم‬، ‫كثيرا‬
ً ‫ اعمل‬:Big Bang
‫ شيء ضخم و المعقدة يخرج من العمل كله مره‬، ‫بانغ‬
.‫و احده‬
‫المعروف أيضا باسم "الذهاب إلى الظالم" كما يراك‬
‫ و ثم تختفي حتى البرنامج‬، ‫العميل في بداية المشروع‬
‫يتم تسليمها في النهاية‬
you are here
5
the Big Bang ends with a big mess
Big bang development usually ends
up in a BIG MESS
‫عادة ما ينتهي تطور االنفجار العظيم يصل في رسالة كبيرة‬
‫ إال أن توم لم يفعل‬، ‫على الرغم من بذل الكثير من العمل في المشروع‬
.‫ذلك رأيت أي ًا من األعمال المنجزة التي نأمل أن تكون قد اكتملت حتى اآلن‬
‫دعونا نرى ما يفكر فيه حول الموقع المكتمل‬
Even though a lot of work went into the project, Tom hasn’t
seen any of the (hopefully) completed work yet. Let’s see what
he thinks about the completed website.
What the heck is this? The site isn’t
anything like I thought it would be.
You couldn’t have taken a little more
time and gotten it right? It’s like you
didn’t even know what I wanted...
If your customer isn’t happy, you
built the wrong software.
Big bang software usually means working a
whole lot, but it also means not showing the
customer much until your work is done. The risk
with that approach is you think you’re building
what the customer wants with no real feedback
until you think you’re finished.
And, no matter how great YOU think your
software is, it’s the customer you have to make
happy. So if the customer doesn’t like what
you’ve built, don’t waste time trying to tell them
they’re wrong. Just get ready to do some rework.
But how do you figure out what the customer
really wants? It’s not always easy...
6
Chapter 1
.‫ فأنت بناء البرنامج الخاطئ‬، ‫إذا لم يكن عميلك سعيد ًا‬
‫ العمل بملف‬Big bang ‫عادة ً ما يعني برنامج‬
‫ضا عدم عرض ملف‬
ً ‫ ولكن هذا يعني أي‬، ‫الكثير‬
‫ الخطر‬.‫كثيرا حتى يتم االنتهاء من عملك‬
ً ‫العميل‬
‫مع هذا االمتياز تعتقد أنك تبني ما يريده العميل دون أي ردود فعل حقيقية حتى تعتقد أنك‬
.‫انتهيت‬
، ‫ إنه العميل الذي يتعين عليك تكوينه سعيد‬، ‫وبغض النظر عن مدى روعة رأيك البرنامج‬
‫ ال تضيع الوقت في محاولة تفجيرهم إنهم‬، ‫لذلك إذا كان الكاستامر ال يحب ماذا أنت تبني‬
‫مخطئون فقط استعد للقيام ببعض إعادة العمل ولكن كيف تحدد ما هو الزبون‬
.‫اريد حقا؟ ليس من السهل دائما‬
‫هل يمكنك معرفة أين سارت األمور بشكل خاطئ؟ فيما يلي ثالثة‬
‫ مهمتك هي اختيار‬.‫أشياء قالها توم أراد أن يسمح موقعه بذلك‬
.‫الخيار أدناه كل عنصر يتطابق بشكل وثيق مع ما يعنيه توم‬
‫ حظ سعيد‬.‫ عليك أن تكتشف ما يعنيه بنفسك‬، ‫وللثالث‬
Can you figure out where things went wrong? Below are three things Tom said
he wanted his site to allow for. Your job is to choose the option underneath
each item that most closely matches what Tom means. And for the third one,
you’ve got to figure out what he means on your own. Good luck!
1 Tom says, “The customer should be able to search for trails.”
The customer should see a map of the world and then enter an addressto search for trails near a
particular location.
The customer should be able to scroll through a list of tourist spots and find trails that lead to and from
those spots.
The customer should be able to enter a zip code and a level of difficultyand find all trails that match that
difficulty and are near that zip code.
".‫قادرا على البحث عن الممرات‬
ً ‫يقول توم "يجب أن يكون العميل‬
‫ يجب على العميل رؤية خريطة العالم ثم إدخال العنوان للبحث عن مسارات بالقرب من‬o
.‫موقع معين‬
‫قادرا على التجول في قائمة المواقع السياحية و العثور على السمات‬
ً ‫ يجب أن يكون العميل‬o
.‫التي تؤدي من وإلى تلك المواقع‬
‫قادرا على إدخال الرمز البريدي ومستوى الصعوبة والعثور على‬
ً ‫ يجب أن يكون العميل‬o
.‫جميع المسارات التي تتطابق مع تلك الصعوبة وتقع بالقرب من الرمز البريدي‬
2
Tom says, “The customer should be able to order equipment.”
The customer should be able to view what equipmentTom has and thencreate an order for items that are
in stock.
The customer should be able to order any equipment they need, but depending on stock levels the order
may take longer if some of theitems are back-ordered.
".‫قادرا على طلب المعدات‬
ً ‫يقول توم "يجب أن يكون العميل‬
‫قادرا على عرض المعدات التي يمتلكها توم وبعد ذلك إنشاء طلب للعناصر‬
ً ‫ يجب أن يكون العميل‬o
.‫الموجودة في المخازن‬
، ‫ ولكن اعتمادًا على مستويات المخزون‬، ‫قادرا على طلب أي معدات يحتاجها‬
ً ‫ يجب أن يكون العميل‬o
.‫قد يستغرق األمر وقتًا أطول إذا كان بعض من تم طلب العناصر مرة أخرى‬
3
Tom says, “The customer should be able to book a trip.”
‫ فقط‬... ‫هل أنت محتار بشأن ما قصده توم حقًا؟ ال بأس‬
‫ إذا كنت تواجه صعوبة في معرفة‬.‫ابذل قصارى جهدك‬
‫ افعل أفضل ما‬، ‫ هذا طبيعي تما ًما‬، ‫أي ملف اختيار‬
‫ وسوف نقضي الكثير من الوقت في الحديث في‬، ‫لديكم‬
، ‫هذا الفصل حول كيفية معرفة ما يعنيه العميل‬
Confused about what Tom really meant?
It’s okay... just do your best.
If you’re having a hard time figuring out which
option to choose, that’s perfectly normal. Do
your best, and we’ll spend a lot more time in this chapter talking
about how to figure out what the customer means.
great software development is...
Can you figure out where things went wrong? Your job was to choose
the option underneath each item that most closely matches what Tom
means. And for the third one, you had to figure out what he means on
your own.
‫هل يمكنك معرفة أين سارت األمور بشكل خاطئ؟‬
‫كانت مهمتك أن تختار الخيار الموجود أسفل كل‬
‫عنصر يتطابق بشكل وثيق مع ما يعنيه توم وبالنسبة‬
.‫ كان عليك معرفة ما يعنيه بنفسك‬، ‫للثالث‬
A big question mark? That’s your answer?
How am I supposed to developgreat
software when I don’t even knowfor
sure what the customer wants?
If you’re not sure what the customer
wants, or even if you think you’re sure,
always go back and ask
When it comes to what is needed, the customer is king.
But it’s really rare for the customer to know exactly
what he wants at the beginning of the project.
‫إذا لم تكن متأكدًا من ماهية العميل‬
، ‫ أو حتى إذا كنت تعتقد أنك متأكد‬، ‫يريد‬
‫دائما ارجع واسأل عندما يتعلق األمر بما‬
‫ يكون الزبون هو الملك لكن‬، ‫هو مطلوب‬
‫من النادر حقًا أن يعرف العميل ذلك‬
.‫بالضبط ماذا يريد في بداية المشروع‬
، ‫عندما تحاول فهم ما لديك يريد العميل‬
‫ ال يوجد حتى حق‬، ‫في بعض األحيان‬
‫ ناهيك عن‬، "‫اإلجابة في "رأس العميل‬
‫الخاص بك! إذا تختفي بسرعة وتبدأ في‬
‫ أو‬.‫ ربما فقط نصف القصة‬، ‫البرمجة‬
‫ لكن البرامج ال ينبغي أن تكون‬.‫حتى أقل‬
‫ تحتاج تأكد من أنك تطور برامج‬.‫تخمينية‬
‫رائعة حتى عندما ما هو مطلوب ليس‬
‫ لذا اذهب واسأل العميل‬.‫واضحا مقدما‬
‫ اطلب منهم المزيد‬.‫ماذا يقصدون‬
‫ اسألهم عن خيارات حول كيف‬.‫التفاصيل‬
‫يمكنك ذلك يطالب حول أفكارهم الكبيرة‬
When you’re trying to understand what your
customer wants, sometimes there’s not even a right
answer in the customer’s head, let alone in yours! If
you disappear in a hurry and start coding, you may
only have half the story... or even less.
But software shouldn’t be guesswork. You need to
ensure that you develop great software even when
what’s needed is not clear up front. So go ask the
customer what they mean. Ask them for more
detail. Ask them for options about how you might
implement about their big ideas.
‫برمجة التنمية‬
‫ال تخمين‬
‫تحتاج إلى االحتفاظ بها العميل في‬
‫الحلقة المراد صنعها متأكد أنك على‬
.‫المسار الصحيح‬
Software
deveLopment is
NOT guesswork.
You need to keep
the customer in
the Loop to make
sure you’re on
the right path.
great software development
.. ‫تطوير البرمجيات الرائع هو‬
‫لقد تحدثنا عن العديد من األشياء التي ستحتاجها أو‬
‫تحتاجها برامج ناجحة‬
We’ve talked about several things that you’ll need for successful software.
‫ وأموالهم التي‬، ‫لديك أفكار كبيرة للعمالء للتعامل معها‬
You’ve got the customer’s big ideas to deal with, their money you’re spending,
‫ عليك أن‬.‫ وجدول زمني يجب أن تقلق بشأنه‬.‫تنفقها‬
and a schedule you’ve got to worry about. You’ve got to get all of those things
‫إنشاء‬
‫تحصل على كل هذه األشياء صحيح إذا كنت تنوي‬
right if you’re going to build consistently great software.
.‫برامج رائعة باستمرار‬
Great software development is...
Great software development delivers...
‫يسلم تطوير البرمجيات العظيم‬
What is needed,
‫ خالف ذلك يسمى‬، ‫ما يحتاجه العميل‬
‫ سنتحدث أكثر‬.‫البرنامج المتطلبات‬
‫حول المتطلبات في اليوم التالي‬
‫الفصل‬
On Time,
‫عندما اتفقنا مع الزبون أن‬
‫البرنامج سينتهي‬
and
On Budget
‫عدم فوترة العميل للحصول‬
‫على أموال أكثر من تم االتفاق‬
‫عليه‬
Can you think of three examples of software
you’ve been involved with where at least one of
these rules was broken?
‫‪delivering with iteration‬‬
‫الوصول إلى الهدف مع ‪ITERATION‬‬
‫سر تطوير البرمجيات الرائع هو التكرار‪ .‬لقد رأيت‬
‫ذلك بالفعل ال يمكنك ببساطة تجاهل العميل أثناء‬
‫التطوير‪ .‬لكن التكرار يوفر طريقة لطرح السؤال ‪ ،‬في‬
‫كل خطوة من خطوات التطوير ‪" ،‬كيف أنا تفعل؟ "في‬
‫ما يلي مشروعان‪ :‬أحدهما بدون تكرار واآلخر به‬
‫‪Getting to the goal with ITERATION‬‬
‫‪The secret to great software development is iteration. You’ve already seen that‬‬
‫‪you can’t simply ignore the customer during development. But iteration provides‬‬
‫‪you a way to actually ask the question, at each step of development, “How am I‬‬
‫‪doing?” Here are two projects: one without iteration, and one with.‬‬
‫حتى اآلن ‪ ،‬سواء عن طريق الحظ أو المهارة‬
‫‪ ،‬ظل التطور مع المسار األمثل إلى حد كبير‬
‫‪Without iteration...‬‬
‫—‪Suppose you take the Big Bang approach to development‬‬
‫‪or any other approach where you’re not constantly checking‬‬
‫‪in with the customer. The likely outcome? Missing what the‬‬
‫‪customer wanted, and by a lot, not just a little.‬‬
‫مسار التنمية لقد أخت بالفعل‬
‫بدون تكرار‪.‬‬
‫لنفترض أنك أخذت تقييم بيغ بانغ‬
‫للتطويرأو أي طريقة أخرى ال تتحقق فيها‬
‫باستمرار مع العميل النتيجة المحتملة؟ في‬
‫عداد المفقودين ما أراد العميل ‪ ،‬وبالكثير ‪،‬‬
‫ليس فقط القليل‪.‬‬
‫‪Start‬‬
‫يتغير كل مشروع بمرور‬
‫الوقت ‪ ،‬مع متطلبات‬
‫الحصول بمهارة تغيرت‬
‫‪ ،‬أو قرارات بشأن ماذا‬
‫للعمل على جعل كل‬
‫زمن‪.‬‬
‫الطريق لك يجب أن تأخذ‬
‫زمن‬
‫في وقت مبكر‬
‫التجريبي لمعرفة‬
‫ما يعتقد العميل‬
‫غير الزبون رأيهم‬
‫حول ميزة هنا ‪ ،‬ولكن منذ ذلك‬
‫الحين‬
‫كنت تقوم بتسجيل الوصول ‪،‬‬
‫قمت بعمل ملف تعديل صغير‬
‫وكيبل ذاهب‪.‬‬
‫‪With iteration...‬‬
‫‪This time, you decide that every time you make significant‬‬
‫‪progress you’ll check with the customer and refine‬‬
‫‪what you’re working on. You also don’t make any major‬‬
‫‪decisions without incorporating customer feedback.‬‬
‫مع التكرار‪.‬‬
‫هذه المرة ‪ ،‬قررت أنه في كل‬
‫مرة تكون فيها ذات أهمية التقدم‬
‫سوف تحقق مع العميل وتحسن ما‬
‫تعمل عليه‪ .‬أنت أيضا ال تجعل‬
‫أي تخصص القرارات دون دمج‬
‫آراء العمالء‪.‬‬
‫‪Start‬‬
‫بعد أيام قليلة فقط ‪ ،‬أوضحت‬
‫ما قصده العميل فيما يتعلق بميزة معينة‪.‬‬
‫‪Chapter 1‬‬
‫‪10‬‬
‫‪great software development‬‬
‫بحلول الوقت الذي تقدم فيه‬
‫البرنامج الخاص بك ‪ ،‬تكون‬
‫متوقفًا عن متطلبات العميل‬
‫ثم نفذت بعض الميزات األخرى‬
‫في بطريقة مختلفة عما قصده‬
‫العميل‬
‫وبنا ًء على ذلك ‪ ،‬تم‬
‫اتخاذ بعض قرارات‬
‫التصميم المختلفة‬
‫???‬
‫لكن بعد ذلك أنت‬
‫نفذت ميزة بشكل‬
‫مختلف عما يريده‬
‫العميل حقًا‪.‬‬
‫لم تقم بتسجيل الوصول مع‬
‫العميل ‪ ،‬وتزداد الفجوة بين‬
‫برامجهم المثالية‬
‫وما تقوم ببنائه‬
‫‪The Goal‬‬
‫ما الفرق الذي يحدثه‬
‫التكرار! نقطة النهاية‬
‫الخاصة بك وما كان يبحث‬
‫عنه العميل في‬
‫‪Converge Payday‬‬
‫استمر في التكرار‬
‫حتى النهاية‬
‫التكرار هو بمثابة‬
‫فحص متكرر‬
‫لبرنامجك‪ .‬ستعرف‬
‫دائ ًما كيف حالك‪.‬‬
‫‪The Goal‬‬
‫‪Iteration is Like a‬‬
‫‪frequent checkup‬‬
‫‪for your software.‬‬
‫‪You’LL aLways know‬‬
‫‪how you’re doing.‬‬
‫في بعض األحيان ‪ ،‬تكون على‬
‫الطريق الصحيح ‪ ،‬لكنك تكرر‬
‫على أي حال ‪ ،‬فهذا يعزز أن ما‬
‫تعمل عليه هو مجرد إثبات‬
‫لكن التكرار يبقيك‬
‫على المسارالصحيح‬
‫كان من الممكن أن‬
‫تتخذ نفس القرار‬
‫السيئ كما هو‬
‫موضح أعاله‬
an iteration delivers working software
Q:
Q:
A:
more time getting to know what the
customer really wants, really getting the
requirements down tight, than always
letting the customer change their mind
midstream?
What if I’m sure that I know what
the customer wants at the beginning of a
project? Do I still need to iterate?
Absolutely. Iteration and getting
feedback from your customer is important
especially when you think you know it all up
front. Sometimes it can seem like a complete
no-brainer on a simple piece of software, but
checking back with the customer is ALWAYS
worth it. Even if the customer just tells you
you’re doing great, and even if you actually
do start out with all the right requirements,
iteration is still a way to make sure you’re
on the right track. And, don’t forget, the
customer can always change their mind.
Q:
My entire project is only two
months long. Is it worth iterating for such
a short project?
A:
Yep, iteration is still really useful even
on a very short project. Two months is a
whopping 60 days of chances to deviate
from the customer’s ideal software, or
misunderstand a customer’s requirement.
Iteration lets you catch any potential
problems like this before they creep into
your project. And, better yet, before you look
foolish in front of your customer.
Wouldn’t it just be better to spend
A:
You’d think so, but actually this is
a recipe for disaster. In the bad old days,
developers used to spend ages at the
beginning of a project trying to make sure
they got all the customer’s requirements
down completely before a single line of code
or design decision was made.
Unfortunately, this approach still failed. Even
if you think that you completely understand
what the customer needs at the beginning,
the customer often doesn’t understand. So
they’re figuring out what they want as much
as you are.
You need a way of helping your team and
your customer grow their understanding
of their software as you build it, and you
can’t do that with a Big Bang, up-front
requirements approach that expects
everything to be cast in stone from day one.
Q:
A:
Who should be involved in an
iteration?
Everyone who has a say in whether
No matter how big the
team, or how Long the
project, iteration is
ALWAYS one of the
keys to buiLding great
software.
12
Chapter 1
your software meets its requirements,
and everyone who is involved in meeting
those requirements. At a minimum, that’s
usually your customer, you, and any other
developers working on the project.
Just read.
Q:
But I’m only a team of one, do I still
need to iterate?
A:
Good question, and the answer is
yes (starting to detect a theme here?). You
might only be a development team of one,
but when it comes to your project there are
always, at a minimum, two people who have
a stake in your software being a success:
your customer and you. You still have two
perspectives to take into account when
making sure your software is on the right
path, so iteration is still really helpful even in
the smallest of teams.
Q:
How early in a project should I start
iterating?
A:
As early as you have a piece of
software running that you can discuss with
your customer. We normally recommend
around 20 work days—1 calendar month, per
iteration as a rule of thumb—but you could
certainly iterate earlier. One- or two-week
iterations are not unheard of. If you aren’t
sure about what a customer means on
Day 2, call them. No sense waiting around,
guessing about what you should be doing,
right?
Q:
What happens when my customer
comes back with bad news, saying I’m
way off on what I’m building. What do I
do then?
A:
Great question! When the worst
happens and you find that you’ve deviated
badly during an iteration, then you need to
bring things back into line over the course of
the next couple of iterations of development.
How to do this is covered later on, but if you
want to take a peek now, fast-forward to
Chapter 4.
‫‪great software development‬‬
‫‪OK, I get it, iteration‬‬
‫‪is important. But you said I should‬‬
‫‪iterate every time I have working software,‬‬
‫‪around every 30 calendar days, or 20 work‬‬
‫‪days. What if I don’t have anything that can run‬‬
‫‪after a month? What can I show the‬‬
‫?‪customer‬‬
‫‪ 20‬يوم عمل ليست‬
‫سوى دليل‪ .‬قد تختار‬
‫أن يكون لديك تكرارات‬
‫أطول أو أقصر‬
‫_شروعك‬
‫حسن ًا ‪ ،‬فهمت ‪ ،‬التكرار‬
‫أنه مهم‪ .‬لكنك قلت إنني يجب أن أكرر في كل مرة لدي‬
‫برنامج عمل ‪ ،‬كل ‪ 30‬يو ًما تقريبًا أو ‪ 20‬يوم عمل‪ .‬ماذا لو‬
‫لم يكن لدي أي شيء يمكنه الركض‬
‫بعد شهر؟ ماذا يمكنني أن أظهر‬
‫عميل؟‬
‫‪An iteration produces working software‬‬
‫‪With the old Big Bang approach to developing software, you‬‬
‫‪probably wouldn’t have any software ready until the end‬‬
‫‪of the project, which is the worst time to realize that you’ve‬‬
‫!‪gone wrong‬‬
‫تم تناول البناء‬
‫وا‪a‬ختبار ا_ستمر‬
‫في الفصل‪ 6 b‬و‬
‫‪7‬‬
‫‪With iteration, you check every step of the way that you’re‬‬
‫‪going in the right direction. That means making sure your‬‬
‫‪software builds from almost day one (and more like hour‬‬
‫‪one if you can manage it). You shouldn’t have long periods‬‬
‫‪where code doesn’t work or compile, even if it’s just small‬‬
‫‪bits of functionality.‬‬
‫‪Then you show your customer those little pieces of‬‬
‫‪functionality. It’s not much, sometimes, but you can still get‬‬
‫‪an OK from the customer.‬‬
‫يُحدث بناء العمل ً‬
‫أيضا‬
‫كبيرا في إنتاجية‬
‫فر ًقا‬
‫ً‬
‫فريقك ‪j‬نه ‪ a‬يتع‪ b‬عليك‬
‫قضاء الوقت في إص‪l‬ح‬
‫رمز شخص آخر قبل أن‬
‫تتمكن من متابعة مهامك‬
‫الخاصة‬
‫تمكن توم من رؤية‬
‫برنامج يعمل ‪ ،‬وقدم‬
‫بعض التعليقات ا_همة‬
‫التي يمكنك معالجتها‬
‫على الفور‬
‫‪Hey, that’s looking good.‬‬
‫?‪But can we go with rounded tabs‬‬
‫‪Oh, and I’d rather call it “Get in‬‬
‫‪touch” than “Contact Us.” Last‬‬
‫‪thing... can we add an option for‬‬
‫”?‪“Order Status‬‬
‫ينتج عن التكرار برنامج عمل‬
‫مع نهج ‪ Big Bang‬القديم لتطوير البرامج ‪ ،‬ربما لن يكون لديك أي‬
‫برنامج جاهز حتى نهاية ا_شروع ‪ ،‬وهو أسوأ وقت }دراك أنك أخطأت!‬
‫باستخدام التكرار ‪ ،‬تتحقق من كل خطوة في الطريق الذي تسير فيه في‬
‫ا‪a‬تجاه الصحيح‪ .‬هذا يعني التأكد من أن برنامجك يبني من اليوم‬
‫ا‪j‬ول تقريبًا )وأكثر مثل الساعة ا‪j‬ولى إذا كان بإمكانك إدارتها(‪a .‬‬
‫ينبغي أن يكون لديك فترات طويلة حيث ‪ a‬تعمل الشفرة أو يتم تجميعها ‪،‬‬
‫حتى لو كانت مجرد أجزاء صغيرة من الوظائف‪.‬‬
‫كثيرا ‪ ،‬في‬
‫ثم تُظهر لعميلك تلك ا‪j‬جزاء الصغيرة من الوظائف‪ .‬ليس‬
‫ً‬
‫بعض ا‪j‬حيان ‪ ،‬ولكن ‪ a‬يزال بإمكانك الحصول على موافقة من العميل‪.‬‬
‫إليك جزء بسيط ج ًدا من موقع ‪Tom's Trails‬‬
‫على الويب‪ .‬إنه يحتوي على ميزة التنقل فقط ‪،‬‬
‫ولكن ‪ a‬يزال من الجدير رؤية ما يعتقده توم‬
‫‪13‬‬
‫‪you are here‬‬
‫بد‪ ًa‬من بناء ا_وقع بالكامل مرة واحدة ‪ ،‬قمنا‬
‫بتقسيم ا_شكلة إلى أجزاء أصغر من الوظائف‪.‬‬
‫يمكن بعد ذلك عرض كل قطعة للعميل على حدة‬
‫كل تكرار هو مشروع صغير‬
‫باستخدام التكرار ‪ ،‬تتخذ الخطوات التي تتبعها لبناء ا_شروع بأكمله ‪،‬‬
‫وتضع هذه الخطوات في كل تكرار‪ .‬في الواقع ‪ ،‬كل تكرار عبارة عن مشروع‬
‫صغير ‪ ،‬له متطلباته الخاصة وتصميمه وترميزه واختباره وما إلى ذلك ‪ ،‬وقد‬
‫تم تضمينه بشكل صحيح‪ .‬لذا فأنت ‪ a‬تعرض الرسائل غير ا_رغوب فيها‬
‫لعميلك ‪ ...‬فأنت تعرض عليهم وحدات بت مطورة جي ًدا من البرنامج النهائي‪.‬‬
‫فكر في كيفية تطوير معظم البرامج‪ :‬تقوم بجمع ا_تطلبات )ما يريده‬
‫عميلك( ‪ ،‬وإنشاء تصميم للمشروع بأكمله ‪ ،‬ووضع التعليمات البرمجية لفترة‬
‫طويلة ‪ ،‬ثم اختبار كل شيء‪ .‬يبدو قلي‪ l‬مثل هذا‪:‬‬
‫‪an iteration is a complete development cycle‬‬
‫‪Each iteration is a mini-project‬‬
‫‪With iteration, you take the steps you’d follow to build the entire project,‬‬
‫‪and put those steps into each iteration. In fact, each iteration is a mini‬‬‫‪project, with its own requirements, design, coding, testing, etc., built right‬‬
‫‪in. So you’re not showing your customer junk... you’re showing them well‬‬‫‪developed bits of the final software.‬‬
‫هذا تصميم رئيسي ‪ ...‬عليك بناء بنية‬
‫لكل ميزة في ا_شروع بأكمله‪ .‬قد‬
‫يستغرق أسابيع ‪ ...‬أو شهور!‬
‫‪Think about how most software is developed: You gather requirements‬‬
‫‪(what your customer wants), build a design for the entire project, code for a‬‬
‫‪long time, and then test everything. It looks a bit like this:‬‬
‫كم من الوقت سيستغرق ا_حاولة والحصول‬
‫‪Design‬‬
‫‪Requirements‬‬
‫‪Each iteration is QUALITY software‬‬
‫يعني تشغيل البرنامج الكامل‬
‫في نهاية كل تكرار أنه يمكننا‬
‫أن نسأل العميل "هل نحن‬
‫بخير؟" غالبا‬
‫‪D‬‬
‫‪Ideas in..‬‬
‫‪But suppose you didn’t look at iteration as just a way to‬‬
‫‪write big software. Think of iteration as little cycles, where‬‬
‫‪you’re gathering requirements, designing, writing code,‬‬
‫‪and testing. Each cycle produces working, quality software:‬‬
‫‪R‬‬
‫‪T‬‬
‫‪C‬‬
‫‪D‬‬
‫‪R‬‬
‫‪T‬‬
‫‪C‬‬
‫‪D‬‬
‫يحتوي التكرار على جميع مراحل العملية‬
‫الكاملة‬
‫‪R‬‬
‫‪Ideas in..‬‬
‫كل تكرار عبارة عن برنامج عالي الجودة‬
‫لكن لنفترض أنك لم تنظر إلى التكرار على‬
‫أنه مجرد طريقة لكتابة برامج كبيرة‪ .‬فكر في‬
‫التكرار على أنه دورات صغيرة ‪ ،‬حيث تقوم‬
‫بجمع ا_تطلبات والتصميم وكتابة التعليمات‬
‫‪14‬برامج عمل‬
‫تنتج كل دورة‬
‫البرمجية ‪1‬وا‪a‬ختبار‪.‬‬
‫‪Chapter‬‬
‫عالية الجودة‪:‬‬
‫‪great software development‬‬
‫أنت ا•ن تختبر كل شيء‪ .‬يمكن أن تستمر هذه‬
‫ا_رحلة ‪j‬سابيع أو أكثر من تلقاء نفسها ً‬
‫أيضا‪.‬‬
‫ويفترض أنك حصلت على جميع ا_تطلبات‬
‫بشكل صحيح‬
‫هذه هي ا_رة ا‪j‬ولى التي يمكن‬
‫لعميلك أن يقدم لك م‪l‬حظات‬
‫ها هو ‪ ...‬الجزء الذي تكتب فيه كل سطر‬
‫من كل جزء من الوظائف‪ .‬طن من‬
‫التعليمات البرمجية‬
‫‪Final Software Out‬‬
‫‪Code‬‬
‫‪Test‬‬
‫بعد فوات ا‪j‬وان }جراء‬
‫تغييرات ا•ن ‪ ،‬من ا‪j‬فضل أن‬
‫صحيحا‬
‫يكون هذا‬
‫ً‬
‫‪Final Software Out‬‬
‫‪T‬‬
‫‪You’ve checked this software at‬‬
‫‪the end of every iteration, so‬‬
‫‪there’s a much better chance this‬‬
‫‪is what the customer wants.‬‬
‫‪15‬‬
‫‪you are here‬‬
‫‪C‬‬
‫‪D‬‬
‫‪R‬‬
‫لقد قمت بفحص هذا البرنامج في‬
‫نهاية كل تكرار ‪ ،‬لذلك هناك فرصة‬
‫أفضل بكثير ‪j‬ن هذا هو ما يريده‬
‫العميل‬
‫‪T‬‬
‫‪C‬‬
‫‪D‬‬
‫‪R‬‬
‫‪T‬‬
‫‪C‬‬
‫‪build a plan out of iterations and features‬‬
‫‪It’s time to bring iterations into play on Tom’s Trails. Each of the features that Tom wants for Trails‬‬
‫‪Online has had estimates added to specify how long it will take to actually develop. Then we‬‬
‫‪figured out how important each is to Tom and then assigned a priority to each of them (10 being‬‬
‫‪the highest priority, 50 being the lowest). Take each feature and position them along the project’s‬‬
‫‪timeline, adding an iteration when you think it might be useful.‬‬
‫حان الوقت لتطبيق التكرارات على ‪ .Tom’s Trails‬تمت إضافة تقديرات لكل من ا_يزات التي يريدها توم لـ ‪ Trails Online‬لتحديد ا_دة‬
‫التي سيستغرقها التطوير الفعلي‪ .‬ثم اكتشفنا مدى أهمية •‬
‫كل منهما بالنسبة إلى توم ثم قمنا بتعي‪ b‬أولوية لكل منهما )‪ 10‬تمثل ا‪j‬ولوية‬
‫القصوى ‪ ،‬و ‪ 50‬هي ا‪j‬قل(‪ .‬خذ كل ميزة ووضعها على طول الجدول الزمني للمشروع ‪ ،‬مع إضافة تكرار عندما تعتقد أنه قد يكون مفي ًدا‬
‫يتوافق كل صندوق‬
‫مع ميزة واحدة‬
‫يحتاجها توم‬
‫تم بالفعل إضافة هذه ا_يزة‬
‫والتكرار لك‬
‫ما مدى أهمية هذه ا_يزة لتوم‪ .‬يعني الرقم‬
‫"‪ "10‬أنه أمر بالغ ا‪j‬همية ح ًقا‬
‫احتفظ بالتكرار حوالي ‪ 20‬يوم‬
‫عمل إن أمكن‪ .‬تذكر أننا نعمل‬
‫خارج أشهر التقويم ‪ ،‬وبأخذ‬
‫عط‪l‬ت نهاية ا‪j‬سبوع في‬
‫ا‪a‬عتبار ‪ ،‬يكون هذا على ا‪j‬كثر‬
‫‪ 20‬يوم عمل في كل تكرار‬
‫‪Chapter 1‬‬
‫‪16‬‬
‫‪great software development‬‬
‫أوه ‪ ،‬شيء واحد آخر‪ a .‬يريد توم أن يتمكن العم‪l‬ء من شراء ا_عدات إ‪ a‬إذا قاموا بتسجيل الدخول إلى‬
‫موقع الويب‪ .‬تأكد من أخذ ذلك في ا‪a‬عتبار في خطتك‪.‬‬
‫‪Oh, one other thing. Tom doesn’t want customers to be able to buy equipment unless they’ve logged in‬‬
‫‪to the web site. Be sure and take that into account in your plan.‬‬
‫تحتوي كل ميزة على ‪5‬‬
‫تقديرات }ظهار ا_دة التي‬
‫يجب أن يستغرقها تطوير هذه‬
‫ا_يزة في أيام العمل الفعلية(‬
‫‪ 10‬ذات أولوية عالية ‪ ،‬و ‪50‬‬
‫منخفضة ‪ ،‬سننظر في سبب زيادة‬
‫هذه ا‪j‬ولويات بمقدار ‪ 10‬في‬
‫الفصل ‪3‬‬
‫‪ a‬تنس إضافة العديد من‬
‫التكرارات التي تعتقد أنها‬
‫ستكون مفيدة‬
‫‪17‬‬
‫‪you are here‬‬
‫‪deciding on a iteration tempo for your project‬‬
‫كانت مهمتك إنشاء خطة تكرار _سارات توم‪ .‬كان يجب أن تكون قد‬
‫توصلت إلى شيء مثل ما فعلناه أدناه‪:‬‬
‫‪Your job was to build an iteration plan for Tom’s Trails. You should have come‬‬
‫‪up with something like we did, below:‬‬
‫كان علينا وضع ميزة ذات أولوية أقل في مكانها‬
‫هنا ‪j ،‬ن ا_يزة ذات ا‪j‬ولوية العالية لدينا تعتمد‬
‫عليها‬
‫قصيرا ‪ ،‬و‪ a‬بأس‬
‫كان التكرار ا‪j‬خير‬
‫ً‬
‫بذلك ً‬
‫أيضا‬
‫‪Your project ends‬‬
‫‪with an iteration,‬‬
‫‪where the customer‬‬
‫‪gets to “sign off” on‬‬
‫‪what you’ve built.‬‬
‫ينتهي مشروعك بتكرار ‪ ،‬حيث‬
‫يحصل العميل على "تسجيل‬
‫الخروج على ما قمت بإنشائه‬
‫حوالي ‪ 20‬يوم عمل لكل تكرار‬
‫سيستغرق اكتمال هات‪ b‬ا_يزت‪ 17 b‬يوم‬
‫عمل ‪ ...‬هذا قريب من شهر تقويمي ‪،‬‬
‫لذلك نكررها عندما ننتهي هنا‬
‫ربما تكون هذه هي الخطة الوحيدة التي‬
‫تخدم أولويات العميل ‪ ،‬وتحافظ على‬
‫التكرارات بطول يمكن التحكم فيه ‪ ،‬وتنجز‬
‫ا_همة‪ .‬إذا توصلت إلى شيء مختلف ‪ ،‬فقم‬
‫بإلقاء نظرة فاحصة على سبب قيامك‬
‫بخيارات مختلفة عما اتخذناه‬
‫‪Chapter 1‬‬
‫‪18‬‬
‫ يساعدك التكرار على‬.‫يجب أن يكون طول التكرار با}يقاع ا_ناسب _شروعك‬
‫ وبالتالي قد تقرر إجراء تكرارات أقصر أو أطول‬، ‫البقاء على ا_سار الصحيح‬
‫ت‬l‫ ولكن ضع في اعتبارك عط‬، ًl‫ثون يو ًما قد تبدو وقت ًا طوي‬l‫ ث‬.‫ يو ًما‬30 ‫من‬
‫ يو ًما من العمل‬20 ‫رجح على‬j‫ وهذا يعني أنك ستحصل على ا‬، ‫سبوع‬j‫نهاية ا‬
‫ يو ًما تقويميًا لكل‬30 ‫فجرب‬
، ‫ إذا لم تكن متأك ًدا‬.‫ا}نتاجي الفعلي لكل تكرار‬
ّ
‫ت على مشروعك حسب‬l‫ وبعد ذلك يمكنك إجراء تعدي‬، ‫تكرار كنقطة بداية جيدة‬
.‫الحاجة‬
‫كثيرا بما يكفي ل—مساك بنفسك عندما تنحرف عن‬
‫التكرار‬
‫هو‬
‫هنا‬
‫ا_فتاح‬
ً
‫ستعداد لنهاية‬a‫كثيرا لدرجة أنك تقضي كل وقتك في ا‬
‫ ولكن ليس‬، ‫الهدف‬
ً
‫مر وقت ًا }ظهار ما قمت به للعميل ثم إجراء تصحيحات‬j‫ يستغرق ا‬.‫التكرار‬
‫ لذا تأكد من مراعاة هذا العمل عند تحديد ا_دة التي يجب أن‬، ‫للمسار‬
.‫تستغرقها عمليات التكرار‬
great software development
I decided to have the customer check
on the project after each feature.
That’s even better than iterating every
calendar month, right?
‫قررت أن أجعل العميل يتحقق‬
.‫من ا_شروع بعد كل ميزة‬
‫هذا أفضل من التكرار كل‬
‫ أليس كذلك؟‬، ‫شهر تقويمي‬
Your iteration length should be at the
right tempo for YOUR project
An iteration helps you stay on track, and so you might decide to
have iterations that are shorter or longer than 30 days. Thirty
days might seem like a long time, but factor in weekends, and that
means you’re probably going to get 20 days of actual productive
work per iteration. If you’re not sure, try 30 calendar days per
iteration as a good starting point, and then you can tweak for your
project as needed.
The key here is to iterate often enough to catch youself when
you’re deviating from the goal, but not so often that you’re
spending all your time preparing for the end of an iteration. It
takes time to show the customer what you’ve done and then make
course corrections, so make sure to factor this work in when you
are deciding how long your iterations should be.
Q:
The last feature scheduled for my iteration will push the
time needed to way over a month. What should I do?
A:
Consider shifting that feature into the next iteration. Your
features can be shuffled around within the boundaries of a 20-day
iteration until you are confident that you can successfully build an
iteration within the time allocated. Going longer runs the risk of
getting off course.
Q:
Ordering things by customer priority is all fine and
good, but what happens when I have features that need to be
completed before other features?
A:
When a feature is dependent on another feature, try to group
those features together, and make sure they are placed within the
same iteration. You can do this even if it means doing a lower-priority
feature before a high-priority one, if it makes the high-priority feature
possible.
This occurred in the previous exercise where the “Log In” feature was
actually a low customer priority, but needed to be in place before the
“Buy Equipment” feature could be implemented.
Q:
A:
If I add more people to the project, couldn’t I do more in
each of my iterations?
Yes, but be very careful. Adding another person to a project
doesn’t halve the time it takes to complete a feature. We’ll talk more
about how to factor in the overhead of multiple people in Chapter 2,
when we talk about velocity.
Q:
What happens when a change occurs and my plan needs
to change?
A:
Change is unfortunately a constant in software development,
and any process needs to handle it. Luckily, an iterative process has
change baked right in...turn the page and see what we mean.
you are here
19
change happens
‫شياء‬j‫العميل سوف يغير ا‬
‫ لقد‬.Iteraton 1 ‫ واكتمل‬، ‫وقع توم على خطتك‬
‫مور‬j‫وصلت ا•ن إلى التكرار الثاني للتطوير وا‬
... ‫ ثم يتصل توم‬.‫تسير على ما يرام‬
The customer WILL change things up
Tom signed off on your plan, and Iteraton 1 has been completed.
You’re now well into your second iteration of development and
things are going great. Then Tom calls...
Things are really starting to look great,
but I had some thoughts after that last
iteration. I think it’s really important that
Tom’s Trails Online has a mailing list, so my
customers can communicate with each other.
‫ لكن‬، ‫مور تبدو رائعة ح ًقا‬j‫بدأت ا‬
‫فكار بعد ذلك‬j‫كان لدي بعض ا‬
‫ أعتقد أنه من ا_هم‬.‫خير‬j‫التكرار ا‬
Tom’s Trails ‫ح ًقا أن يكون لدى‬
‫ لذا فأنا‬، ‫ قائمة بريدية‬Online
‫ء التواصل مع بعضهم‬l‫يمكن للعم‬
.‫البعض‬
a ‫ إذا كان برنامجك‬، ‫ تذكر‬‫ فلن‬، ‫يفعل ما يريده العميل‬
‫تذهب بعي ًدا في تطوير‬
‫البرمجيات‬
It’s up to you to make adjustments
Tom’s new idea means three new features, all high-priority.
And we don’t even know how long they’ll take, either. But
you’ve got to figure out a way to work these into your projects.
‫ت‬l‫مر متروك لك }جراء التعدي‬j‫ا‬
‫ جميعها ذات أولوية‬، ‫ث ميزات جديدة‬l‫تعني فكرة توم الجديدة ث‬
‫ لكن‬.‫ نعرف حتى كم من الوقت سيستغرقون‬a ‫ كما أننا‬.‫عالية‬
.‫عليك اكتشاف طريقة للعمل بها في مشاريعك‬
But there are some BIG problems...
20
Chapter 1
‫‪great software development‬‬
‫أنت بالفعل في طريق طويل نحو التطور ‪...‬‬
‫الهدف ا‪j‬صلي ‪..‬‬
‫‪You’re already a long way into development...‬‬
‫أنت على هذا الطريق البعيد‬
‫نحو تقديم برامج رائعة‬
‫لقد كنت تكرر التصويب‬
‫نحو الهدف ‪....‬‬
‫ولكن ا•ن انتقل الهدف!‬
‫‪ ...‬و‪ a‬يزال لديك ميزات أخرى يمكنك إنشاؤها ‪...‬‬
‫‪... and you’ve still got other features to build...‬‬
‫‪These features are‬‬
‫‪still in the pipeline.‬‬
‫هذه ا_يزات ‪ a‬تزال في‬
‫طور ا}عداد‬
‫‪ ...‬ولم يتغير ا_وعد النهائي‪.‬‬
‫‪... and the deadline hasn’t changed.‬‬
‫ما يزيد قلي‪ ًl‬عن‬
‫شهر واحد حتى‬
‫مؤتمر ‪!TrailMix‬‬
‫تذكر ا_وعد النهائي من‬
‫الصفحة ‪3‬؟ لم يتغير ‪،‬‬
‫على الرغم من تغير عقل‬
‫توم‬
‫‪21‬‬
‫‪you are here‬‬
handle change with iteration
Iteration handles change automatically
Your iteration plan is already structured around short cycles, and is
built to handle lots of individual features. Here’s what you need to
do:
1
‫تتغير مقابض التكرار تلقائيًا‬
‫تم تصميم خطة التكرار الخاصة بك بالفعل حول دورات قصيرة‬
‫ إليك ما‬.‫ وهي مصممة للتعامل مع الكثير من ا_يزات الفردية‬،
:‫عليك القيام به‬
Estimate the new features
1
First, you need to estimate how long each of the new features is going
‫ تحتاج إلى تقدير ا_دة التي‬، ًa‫تقدير ا_يزات الجديدة أو‬
to take. We’ll talk a lot more about estimation in a few chapters, but for
‫كثيرا عن التقدير في‬
‫ سنتحدث‬.‫ستستغرقها كل ميزة جديدة‬
ً
now, let’s say we came up with these estimates for the three new features: ‫ لنفترض أننا توصلنا‬، ‫ ولكن في الوقت الحالي‬، ‫بضعة فصول‬
:‫ثة الجديدة‬l‫إلى هذه التقديرات للميزات الث‬
2
22
Have your customer prioritize the new features
Tom already gave everything a priority of “20,” right? But you really
need him to look at the other features left to implement as well, and
prioritize in relation to those.
Chapter 1
2
‫ولوية للميزات الجديدة أعطى توم‬j‫اطلب من عميلك إعطاء ا‬
‫ أليس كذلك؟ لكنك تحتاجه‬، "20" ‫ولوية لكل شيء‬j‫بالفعل ا‬
ً ‫خرى ا_تبقية للتنفيذ‬j‫ح ًقا للنظر في ا_يزات ا‬
‫ وتحديد‬، ‫أيضا‬
.‫ولويات فيما يتعلق بها‬j‫ا‬
great software development
3
3
‫ الترتيب بنا ًء على تحديد‬b‫ يتم تعي‬.‫أعد صياغة خطة التكرار‬
‫ مع‬، ‫ لذا ا•ن تقوم بتغيير خطتك‬.‫ توجد أي تبعيات‬a‫ و‬، ‫ولويات‬j‫ا‬
.‫مراعاة طول التكرار والجدول العام‬
Rework your iteration plan
The ordering is set based on prioritization, and there aren’t any
dependencies. So now you change your plan, keeping your iteration
length and the overall schedule in mind.
O
4
Check your project deadline
Remember the TrailMix Conference? You need to see if the work
you’ve got left, including the new features, still can get done in time.
Otherwise, Tom’s got to make some hard choices.
‫؟‬TrailMix ‫حقق من ا_وعد النهائي _شروعك هل تذكر مؤتمر‬
‫ بما في ذلك‬، ‫تاج إلى معرفة ما إذا كان العمل الذي تركته‬
.‫ يزال من ا_مكن إنجازه في الوقت ا_ناسب‬a ، ‫يزات الجديدة‬
ً
‫بعضا‬
‫ يجب أن يصنع توم‬، ‫ف ذلك‬l
(Days of work Left)
Organize a Trekking
Group
(Days Left before deadLine)
View
=
Can you do it?
you are here
23
use the right process for you
‫ حصلت‬، ‫العملية هي في الحقيقة مجرد سلسلة من الخطوات‬
‫ العملية‬.‫ على سمعة سيئة‬، ‫ خاصة في تطوير البرمجيات‬، ‫العملية‬
‫هي مجرد سلسلة من الخطوات التي تتبعها من أجل القيام بشيء‬
‫ لذلك عندما كنا نتحدث عن‬.‫ تطوير البرامج‬، ‫ في حالتنا‬- ‫ما‬
‫ كنا نتحدث بالفعل عن عملية‬، ‫ولويات والتقدير‬j‫التكرار وتحديد ا‬
‫ً من أن تكون أي مجموعة رسمية من القواعد‬a‫ بد‬.‫تطوير البرامج‬
‫ختبار الذي يجب عليك‬a‫حول ا_خططات أو التوثيق أو حتى ا‬
، (!‫ختبار شيء نوصي به بالتأكيد‬a‫إجراؤه )على الرغم من أن ا‬
.‫فإن العملية هي في الحقيقة ما يجب القيام به ومتى يتم القيام به‬
‫ نهتم‬a ‫ نحن‬.‫ فقط يجب أن تعمل‬... ‫ تحتاج إلى اختصار‬a ‫وهي‬
‫ طا_ا أنها تحتوي على ا_كونات‬، ‫ح ًقا بالعملية التي تستخدمها‬
‫التي تضمن لك الحصول على برامج رائعة وعالية الجودة في نهاية‬
.‫دورة التطوير الخاصة بك‬
‫ أليس‬، ‫أنت على وشك أن تصدمني بعملية تطوير خيالية كبيرة‬
‫ أو أيًا‬DRUM ‫ أو‬Quick ‫ أو‬RUP ‫كذلك؟ كما لو كنت أستخدم‬
‫ سأبدأ بطريقة سحرية في ا}نتاج‬، ‫كان‬
‫ أليس كذلك؟‬، ‫برنامج رائع‬
You’re about to hit me with a big fancy
development process, aren’t you? Like if I
use RUP or Quick or DRUM or whatever,
I’m magically going to start producing
great software, right?
A process is really just a sequence of steps
Process, particularly in software development, has gotten
a bit of a bad name. A process is just a sequence of steps
that you follow in order to do something—in our case,
develop software. So when we’ve been talking about iteration,
prioritization, and estimation, we’ve really been talking about
a software development process.
Rather than being any formal set of rules about what
diagrams, documentation, or even testing you should
be doing (although testing is something we’d definitely
recommend!), a process is really just what to do, and when to
do it. And it doesn’t need an acronym...it just has to work.
We don’t really care what process you use, as long as it has
the components that ensure you get great, quality software at
the end of your development cycle.
‫ أليس كذلك؟‬، ‫يبدو أنه يمكن تطبيق التكرار على أي عملية‬
The right
software
deveLopment
process for YOU
is one that heLps
YOU deveLop
and deLiver great
software, on time
and on budget.
24
Chapter 1
It seems like iteration could be
applied to any process, right?
Iteration is more than a process
Regardless of the actual steps involved in the
process you choose, iteration is a best practice.
It’s an approach that can be applied to any
process, and it gives you a better chance of
delivering what is needed, on time and
on budget. Whatever process you end up
using, iteration should be a major part.
‫عملية تطوير البرامج ا_ناسبة لك هي‬
‫عملية تساعدك على تطوير برامج‬
‫رائعة في الوقت ا_حدد وفي حدود‬
.‫ا_يزانية‬
‫التكرار هو أكثر من مجرد عملية بغض‬
‫النظر عن الخطوات الفعلية ا_تضمنة في‬
‫ فإن التكرار هو‬، ‫العملية التي تختارها‬
‫ إنه نهج يمكن تطبيقه على‬.‫أفضل ممارسة‬
‫ ويمنحك فرصة أفضل لتقديم ما‬، ‫أي عملية‬
‫ في الوقت ا_حدد وفي حدود‬، ‫هو مطلوب‬
‫ مهما كانت العملية التي تنتهي‬.‫ا_يزانية‬
‫ يجب أن يكون التكرار جز ًءا‬، ‫باستخدامها‬
.‫رئيسيًا‬
great software development
Your software isn’t complete until
it’s been RELEASED
‫لم يكتمل برنامجك حتى يتم إصداره‬
‫ وا•ن انتهيت أنت وفريقك ا_شروع في‬، ‫لقد أضفت ا_يزات الجديدة‬
‫ كنت‬، ‫ في كل خطوة على الطريق‬.‫الوقت ا_حدد وفي ا_وعد ا_حدد‬
‫ مع دمج تلك‬، ‫تحصل على تعليقات من العميل في نهاية كل تكرار‬
‫ ا•ن يمكنك تسليم‬.‫التعليقات وا_يزات الجديدة في التكرار التالي‬
.‫ ومن ثم تدفع لك‬، ‫البرنامج الخاص بك‬
You added the new features, and now you and your team have finished
the project on time and on schedule. At every step of the way, you’ve
been getting feedback from the customer at the end of each iteration,
incorporating that feedback, and new features, into the next iteration.
Now you can deliver your software, and then you get paid.
، ‫ أتلقى مكا_ات بالفعل‬.‫ممتاز‬
.‫والناس يحبون ا_وقع الجديد‬
، ‫سبوع‬j‫وارتفعت طلباتنا هذا ا‬
‫ء الجدد الذين‬l‫معظمها من العم‬
‫شاهدوا عرضنا التوضيحي عبر‬
.TrailMix ‫ا}نترنت في‬
.‫عمل جيد‬
Excellent. I’m already getting calls, and
people love the new site. And our orders are
up this week, mostly off of new customers
that saw our online demo at TrailMix.
Nice work.
"
The Goal
Q:
What happens when the customer comes up with new
requirements and you can’t fit all the extra work into your
current iteration?
A:
This is when customer priority comes into play. Your customer
needs to make a call as to what really needs to be done for this
iteration of development. The work that cannot be done then needs
to be postponed until the next iteration. We’ll talk a lot more about
iteration in the next several chapters.
Q:
What if you don’t have a next iteration? What if you’re
already on the last iteration, and then a top priority feature
comes in from the customer?
A:
If a crucial feature comes in late to your project and you can’t
fit it into the last iteration, then the first thing to do is explain to the
customer why the feature won’t fit. Be honest and show them your
iteration plan and explain why, with the resources you have, the work
threatens your ability to deliver what they need by the due date.
The best option, if your customer agrees to it, is to factor the
new requirement into another iteration on the end of your project,
extending the due date. You could also add more developers, or
make everyone work longer hours, but be wary of trying to shoehorn
the work in like this. Adding more developers or getting everyone
to work longer hours will often blow your budget and rarely if ever
results in the performance gains you might expect (see Chapter 3).
you are here
25
‫أدوات _ربع أدوات تطوير البرمجيات الخاص بك‬
‫تطوير البرمجيات هو كل شيء عن تطوير وتقديم برامج رائعة‪ .‬في هذا الفصل‪،‬‬
‫لقد تعلمت العديد من التقنيات }بقائك على ا_سار الصحيح‪ .‬للحصول على‬
‫قائمة كاملة من ا‪j‬دوات في الكتاب ‪ ،‬انظر ا_لحق الثاني‪.‬‬
‫‪your software development toolbox‬‬
‫‪Tools for your Software Development Toolbox‬‬
‫‪The feedback that comes‬‬
‫‪out of each iteration is the‬‬
‫‪best tool for ensuring that‬‬
‫‪your software meets the‬‬
‫‪needs of your customers.‬‬
‫■‬
‫‪An iteration is a complete‬‬
‫‪project in miniature.‬‬
‫■‬
‫‪Successful software is not‬‬
‫‪developed in a vacuum. It‬‬
‫‪needs constant feedback‬‬
‫‪from your customer using‬‬
‫‪iterations.‬‬
‫■‬
‫‪Good software development‬‬
‫‪delivers great software, on‬‬
‫‪time and on budget.‬‬
‫■‬
‫‪It’s always better to deliver‬‬
‫‪some of the features‬‬
‫‪working perfectly than all‬‬
‫‪of the features that don’t‬‬
‫‪work properly.‬‬
‫■‬
‫‪Good developers develop‬‬
‫‪software; great developers‬‬
‫!‪ship software‬‬
‫■‬
‫■ ردود الفعل التي تأتي من كل تكرار هو‬
‫أفضل وسيلة لضمان ذلك يلتقي برنامجك مع احتياجات عم‪l‬ئك‪.‬‬
‫■ التكرار هو كامل مشروع في صورة مصغرة‪.‬‬
‫■ البرامج الناجحة ليست كذلك وضعت في فراغ‪ .‬هو ‪ -‬هي يحتاج إلى م‪l‬حظات مستمرة من عميلك‬
‫باستخدام التكرارات‪.‬‬
‫■ تطوير برمجيات جيد يسلم برامج رائعة ‪ ،‬على‬
‫الوقت وا_يزانية‪.‬‬
‫دائما التسليم بعض ا_يزات‬
‫■ من ا‪j‬فضل‬
‫ً‬
‫تعمل بشكل مثالي أكثر من الجميع من ا_يزات التي ‪a‬‬
‫اعمل جيدا‪.‬‬
‫■ ا_طورون الجيدون يطورون البرمجيات؛ مطورين رائع‪ b‬برنامج السفينة!‬
‫مبادئ التنمية‬
‫قم بتوصيل البرامج ا_طلوبة‬
‫تسليم البرنامج في الوقت ا_حدد‬
‫تقديم البرامج على ا_يزانية‬
‫‪CHAPTER 1‬‬
‫‪Software Development is all about developing‬‬
‫‪and delivering great software. In this chapter,‬‬
‫‪you learned about several techniques to keep‬‬
‫‪you on track. For a complete list of tools in the‬‬
‫‪book, see Appendix ii.‬‬
‫تقنيات التنمية‬
‫التكرار يساعدك على البقاء في ا_سار الصحيح‬
‫قم بالتخطيط والتوازن ب‪ b‬التكرارات الخاصة بك‬
‫عندما )‪ a‬يحدث( التغيير‬
‫ينتج عن كل تكرار برنامج عمل ويجمع تعليقات‬
‫من عميلك في كل خطوة على الطريق‬
‫‪Chapter 1‬‬
‫‪26‬‬
great software development
Software Development Cross
Let’s put what you’ve learned to use and stretch out your
left brain a bit. All of the words below are somewhere in
this chapter. Good luck!
1
2
4
3
5
6
7
8
9
10
11
12
13
14
15
16
17
Across
Down
2. I'm the person or company who ultimately decides if your
software is worth paying for.
4. Good Developers develop, great developers .........
6. An iteration produces software that is .........
7. Aim for........... working days per iteration.
9. The number of development stages that are executed within
an iteration.
12. I am one thing that your software needs to do.
13. The date that you need to deliver your final software on.
15. Iteration is ........... than a process.
16. The single most important output from your development
process.
17. Software isn't complete until it has been .........
1. A .......... is really just a sequence of steps.
3. When a project fails because it costs too much, it is .........
5. I contain every step of the software development process in
micro and I result in runnable software.
8. The minimum number of iterations in a 3 month project.
10. Software that arrives when the customer needs it is .........
11. An iteration is a complete mini-.........
14. The types of software development projects where you
should use iteration.
you are here
27
exercise solutions
Software Development Cross
Solution
1
2
P
C
U
S
T
R
4
S
H
C
T
W
E
5
I
N
6
W
8
T
O
E
Y
9
F
H
R
S
R
A
D
E
T
G
E
E
Q
U
I
R
28
Chapter 1
E
R
K
I
N
E
O
M
14
A
D
L
I
N
L
S
E
E
10
N
D
D
P
N
R
T
O
I
J
M
O
11
O
15
C
A
G
R
E
16
E
U
T
L
R
E
B
O
17
R
S
R
D
M
E
P
T
12
13
O
V
O
7
3
E
O
R
E
C
T
‫‪2 gathering requirements‬‬
‫‪Knowing what the‬‬
‫‪customer wants‬‬
‫‪I know I said I wanted a Mustang,‬‬
‫‪but I was really looking for the five‬‬‫‪liter, turbocharged model...‬‬
‫دائما على ما تريده ‪...‬‬
‫دائما الحصول على ما تريد ‪ ...‬ولكن يجب على العميل أ‪ 3‬تحصل‬
‫‪ 3‬يمكنك‬
‫ً‬
‫ً‬
‫ولكن يجب على العميل أن يقدم التطوير الرائع للبرامج ما يريده العميل‪ .‬يدور هذا الفصل حول‬
‫التطوير الرائع للبرامج ويقدم ما يريده العميل‪ .‬يتعلق هذا الفصل بالتحدث إلى العم‪R‬ء ‪P‬عرفة‬
‫متطلباتهم لبرنامجك‪ .‬التحدث إلى العم‪R‬ء ‪P‬عرفة متطلباتهم لبرنامجك‪ .‬سوف تتعلم كيف تساعدك‬
‫قصص ا‪P‬ستخدم‪ ، d‬والعصف الذهني ‪ ،‬ولعبة التقدير في فهمك‪ .‬وستتعلم كيف تساعدك قصص‬
‫ا‪P‬ستخدم ‪ ،‬والعصف الذهني ‪ ،‬ولعبة التقدير في الوصول إلى ذهن العميل‪ .‬بهذه الطريقة ‪ ،‬بحلول‬
‫الوقت الذي تنتهي فيه من مشروعك ‪ ،‬ستكون داخل رأس عميلك‪ .‬بهذه الطريقة ‪ ،‬بحلول الوقت الذي‬
‫تنتهي فيه من مشروعك ‪ ،‬ستكون واث ًقا من أنك قمت ببناء ما يريده عميلك ‪ ...‬وليس مجرد تقليد سيء‪.‬‬
‫واثق من أنك بنيت ما يريده عميلك ‪ ...‬وليس مجرد تقليد سيء‪.‬‬
‫!‪You can’t always get what you want...but the customer should‬‬
‫‪Great software development delivers what the customer wants. This chapter is all about‬‬
‫‪talking to the customer to figure out what their requirements are for your software.‬‬
‫‪You’ll learn how user stories, brainstorming, and the estimation game help you get‬‬
‫‪inside your customer’s head. That way, by the time you finish your project, you’ll be‬‬
‫‪confident you’ve built what your customer wants...and not just a poor imitation.‬‬
‫‪29‬‬
‫‪this is a new chapter‬‬
‫‪Download at WoweBook.Com‬‬
orion’s orbits
‫مدارات أوريون قيد التحديث‬
Orion’s Orbits is modernizing
Orion’s Orbits provides quality space shuttle services to discerning clients, but
their reservation system is a little behind the times, and they’re ready to take
the leap into the 21st century. With the next solar eclipse just four weeks away,
they’ve laid out some serious cash to make sure their big project is done right,
and finished on time.
، ‫ميزين‬P‫ء ا‬R‫ خدمات نقل فضائية عالية الجودة للعم‬Orion’s Orbits ‫توفر‬
‫تخاذ‬3 ‫ وهم على استعداد‬، ‫ً عن العصر‬R‫ولكن نظام الحجز لديهم متأخر قلي‬
‫ مع اقتراب الكسوف الشمسي القادم‬.‫قفزة في القرن الحادي والعشرين‬
‫موال الجادة للتأكد من أن‬x‫ فقد وضعوا بعض ا‬، ‫بأربعة أسابيع فقط‬
.‫حدد‬P‫ وانتهى في الوقت ا‬، ‫مشروعهم الكبير قد تم بشكل صحيح‬
‫ لذلك‬، d‫وظف‬P‫ ا‬d‫ ذوي الخبرة من ب‬d‫برمج‬P‫ فريق من ا‬Orion ‫ يوجد لدى‬3
‫قاموا بتعيينك أنت وفريقك من خبراء البرمجيات للتعامل مع تطوير نظام‬
‫مر متروك لك للقيام بذلك بشكل صحيح وتسليمه في‬x‫ ا‬.‫الحجز الخاص بهم‬
.‫حدد‬P‫الوقت ا‬
Orion’s doesn’t have an experienced team of programmers on staff, though, so
they’ve hired you and your team of software experts to handle developing their
reservation system. It’s up to you to get it right and deliver on time.
We need a web site showing our current deals, and we want
our users to be able to book shuttles and special packages,
as well as pay for their bookings online. We also want to
offer a luxury service that includes travel to and from the
spaceport and accommodation in a local hotel...
‫ ونريد‬، ‫نحن بحاجة إلى موقع ويب يعرض صفقاتنا الحالية‬
‫ت مكوكية وباقات خاصة‬R‫أن يتمكن مستخدمونا من حجز رح‬
‫ نريد‬.‫ با‚ضافة إلى الدفع مقابل حجوزاتهم عبر ا‚نترنت‬،
ً
‫أيضا تقديم خدمة فاخرة تشمل السفر من وإلى‬
... ‫ميناء فضائي وا‚قامة في فندق محلي‬
How close do you think your final
software will be to what the CEO of
Orion Orbits wants?
30
‫إلى أي مدى تعتقد أن برنامجك النهائي سيكون قريبًا مما‬
‫؟‬Orion Orbits ‫يريده الرئيس التنفيذي لشركة‬
Chapter 2
Download at WoweBook.Com
gathering requirements
Your job is to analyze the Orion’s CEO’s statement, and build some
initial requirements. A requirement is a single thing that the software
has to do. Write down the things you think you need to build for
Orion’s Orbits on the cards below.
. Here’s one torted.
‫ وبناء‬، Orion ‫مهمتك هي تحليل بيان الرئيس التنفيذي لشركة‬
‫طلب هو شيء واحد يجب على‬P‫ ا‬.‫ولية‬x‫تطلبات ا‬P‫بعض ا‬
‫شياء التي تعتقد أنك بحاجة إلى‬x‫ اكتب ا‬.‫البرنامج القيام به‬
.‫ على البطاقات أدناه‬Orion’s Orbits ‫بنائها من أجل‬
get you sta
Sh ow cu rre nt de als
ll
.‫ هذه واحدة لتبدأ بها‬Description: Th e we b site wi
sh ow cu rre nt de als to Or ion’s
Or bit s use rs.
Title:
Title:
Description:
Title:
Description:
Title:
Description:
Title:
Title:
Description:
Description:
Remember, each requirement should
be a single thing the system has to
do.
.‫تذكر أن كل متطلب يجب أن يكون شيئ ًا واح ًدا على النظام فعله‬
.‫تطلبات‬P‫ فهي مثالية لتدوين ا‬، ‫إذا كان لديك بطاقات فهرسة‬
If you’ve got index cards,
they’re perfect for writing
requirements down.
you are here 4
Download at WoweBook.Com
31
‫تطلبات مما يطلبه الرئيس التنفيذي‬P‫لنبدأ بكسر ا‬
‫ خذ أفكاره الفضفاضة‬.Orbit's Orbits ‫لشركة‬
‫ مع كل مقتطف يلتقط شيئ ًا‬، ‫وح ّولها إلى مقتطفات‬
... ‫واح ًدا تعتقد أن البرنامج سيحتاج إلى فعله‬
requirements start with customer ideas
Let’s start by breaking out the requirements from what the Orion’s
Orbits CEO is asking for. Take his loose ideas and turn them into
snippets, with each snippet capturing one thing that you think the
software will need to do...
Sho w cur ren t dea ls
site wil l
Description: The web
sho w cur ren t dea ls to Ori on’s
Orbits use rs.
Title:
Boo k pac kage
An Ori on’s Orbits
Description:
use r wil l be able to boo k a spe cial
pac kage wit h ext ras onl ine .
Book a shut tle
An Orion’s Orbit s user
will be able to book a shut tle.
Title:
Description:
Each card
captures one
thing that the
software will
need to provide.
Title:
Arrange travel
Orbits use r
Description: An Ori on’s
wil l be able to arrange travel to
and from the spacep ort.
Title:
Q:
Pay online
Description: An Orion’s Orbits
user will be able to pay for their
bookings online
Title:
Book a hotel
Description: An Orion’s Orbits user
will be able to book a hotel.
Title:
Q:
Should we be using a specific
format for writing these down?
Aren’t these requirements just user
stories?
A:
A:
No. Right now you’re just grabbing and
sorting out the ideas that your customer has
and trying to get those ideas into some sort
of manageable order.
32
You’re not far off, but at the moment
they are just ideas. In just a few more pages
we’ll be developing them further into fullfledged user stories. At the moment it’s just
useful to write these ideas down somewhere.
Chapter 2
Download at WoweBook.Com
Q:
These descriptions all seem really
blurry right now. Don’t we need a bit
more information before we can call them
requirements?
A:
Absolutely. There are lots of gaps in
understanding in these descriptions. To fill in
those gaps, we need to go back and talk to
the customer some more...
gathering requirements
‫علومات‬P‫تحدث إلى عميلك للحصول على مزيد من ا‬
Talk to your customer to get
MORE information
There are always gaps in your understanding of what your software is supposed to do,
especially early in your project. Each time you have more questions, or start to make
assumptions, you need to go back and talk with the customer to get answers to
your questions.
:‫ول مع الرئيس التنفيذي‬x‫سئلة التي قد تطرحها بعد اجتماعك ا‬x‫فيما يلي بعض ا‬
Here are a few questions you might have after your first meeting with the CEO:
1
How many different types of shuttles does the software have to support?
2
Should the software print out receipts or monthly reports (and what
should be on the reports)?
3
Should the software allow reservations to be canceled or changed?
4
Does the software have an administrator interface for adding new types
of shuttles, and/or new packages and deals?
5
Are there any other systems that your software is going to have to talk to,
like credit card authorization systems or Air/Space Traffic Control?
6
‫ا يفترض‬P ‫دائما فجوات في فهمك‬
‫هناك‬
ً
‫ خاصة في وقت مبكر‬، ‫أن يفعله برنامجك‬
‫ في كل مرة يكون لديك‬.‫من مشروعك‬
‫ أو تبدأ في وضع‬، ‫سئلة‬x‫زيد من ا‬P‫ا‬
‫ تحتاج إلى العودة والتحدث‬، ‫افتراضات‬
.‫سئلتك‬x ‫مع العميل للحصول على إجابات‬
‫ختلفة التي يجب أن يدعمها‬P‫كوكات ا‬P‫كم عدد أنواع ا‬1
‫البرنامج؟‬
‫ت أو التقارير الشهرية‬3‫ هل ينبغي للبرنامج طباعة ا‚يصا‬2
‫)وماذا يجب أن يكون في التقارير(؟‬
‫ هل يجب أن يسمح البرنامج بإلغاء الحجوزات أو تغييرها؟‬3
‫ هل يحتوي البرنامج على واجهة مسؤول ‚ضافة أنواع‬4
‫ أو حزم وصفقات جديدة؟‬/ ‫كوكات و‬P‫جديدة من ا‬
‫ على برنامجك التحدث‬d‫ هل هناك أي أنظمة أخرى سيتع‬5
‫ئتمان أو التحكم في‬3‫ مثل أنظمة ترخيص بطاقات ا‬، ‫إليها‬
‫ الفضائية؟‬/ ‫رور الجوية‬P‫حركة ا‬
6
Can you come up with
another question you
might want to ask
the CEO?
OK, thanks for coming back to me. I’ll get to
those questions in just a bit, but I thought of
something else I forgot to mention earlier...
Try to gather additional requirements.
Talking to the customer doesn’t just give you a chance
to get more details about existing requirements. You also
want to find out about additional requirements the
customer didn’t think to tell you about earlier. There’s
nothing worse than finishing a project and the customer
saying they forgot some important detail.
So how do you get the customer to think of everything you
need to know, before you start building their software?
‫ يمنحك التحدث‬3 .‫تطلبات ا‚ضافية‬P‫حاول جمع ا‬
‫إلى العميل فقط فرصة للحصول على مزيد من‬
ً ‫ تريد‬.‫تطلبات الحالية‬P‫التفاصيل حول ا‬
‫أيضا‬
‫تطلبات ا‚ضافية التي لم يفكر العميل‬P‫التعرف على ا‬
‫ يوجد أسوأ من إنهاء‬3 .‫في إخبارك بها مسب ًقا‬
‫شروع ويقول العميل إنه نسى بعض التفاصيل‬P‫ا‬
‫ إذن كيف تجعل العميل يفكر في كل ما‬.‫همة‬P‫ا‬
‫ قبل البدء في إنشاء برامجهم؟‬، ‫تحتاج إلى معرفته‬
you are here 4
Download at WoweBook.Com
33
‫ العصف الذهني‬.‫ فكر جي ًدا‬، ‫عندما تتكرر مع العميل بشأن متطلباته‬
‫ بشرط أن يشعر‬، d‫ وعشرة رؤوس أفضل من رأس‬، ‫مع أناس آخرين؛ رأسان أفضل من رأس‬
.‫ فقط التقط كل شيء‬- ‫ تستبعد أي أفكار في البداية‬3 .‫ساهمة دون نقد‬P‫الجميع أنه يمكنهم ا‬
‫ا أنتم جمي ًعا ما زلتم نسمي هذا اللون‬P‫ طا‬، ‫فكار الجامحة‬x‫ بأس إذا توصلت إلى بعض ا‬3
‫ وهذا ما يسمى‬.‫ساسية التي يحاول البرنامج تلبيتها‬x‫حتياجات ا‬3‫زرق الذي يركز على ا‬x‫ا‬
.‫بلوسكيينج للمتطلبات‬
capturing what’s in your customer’s heads
Bluesky with your customer
When you iterate with the customer on their requirements, THINK BIG. Brainstorm
with other people; two heads are better than one, and ten heads are better than two, as long as
everyone feels they can contribute without criticism. Don’t rule out any ideas in the beginning—
just capture everything. It’s OK if you come up with some wild ideas, as long as you’re all still
focusing on the core needs that the software is trying to meet. This is called blueskying for
requirements.
We call this blue
skying because the
sky’s the limit.
Uses Ajax for a
slick user interface.
Pay with a credit
card and PayPal.
Write a review
of a flight.
Order a DVD of
my shuttle flight.
Your developm
en
t team
The developer
The customer’s
team
You can include the
users themselves.
Order in-flight
drinks or meals.
Avoid office politics.
Nothing will stifle creative bluesky
thinking like a boss that won’t let people
speak up. Try as much as possible to
leave job descriptions and other baggage
at the door when blueskying requirements. Everyone
should get an equal say to ensure you get the most
out of each brainstorming session.
34
Chapter 2
Download at WoweBook.Com
Choose aisle or
window seating.
.‫كتب‬P‫تجنب سياسات ا‬
‫ شيء سيخنق موسيقى البلوز ا‚بداعية‬3
‫ يسمح للناس‬3 ‫يفكر مثل رئيس‬
‫ستطاع ل‬P‫ حاول قدر ا‬.‫تكلم‬
‫خرى‬x‫متعة ا‬x‫وصاف الوظيفية وا‬x‫اترك ا‬
‫ يجب أن يكون لكل‬.blueskying ‫عند الباب عند متطلبات‬
‫شخص رأي متساو لضمان حصولك على أقصى استفادة‬
.‫ذهني‬the
‫من كل جلسة عصف‬
Never forget to include
customer in these sessions.
‫زرق وأنشئ بطاقة‬x‫خذ أربعة أفكار من العصف الذهني ا‬
ً ‫ تحقق‬.‫جديدة لكل متطلب محتمل‬
‫أيضا مما إذا كان يمكنك‬
.‫ بك‬d‫ خاص‬d‫ إضافي‬d‫الخروج بمتطلب‬
Take four of the ideas from the bluesky brainstorm and
create a new card for each potential requirement. Also,
see if you can come up with two additional requirements
of your own.
Title:
gathering requirements
We can refer to each
requirement easily by
using its title.
Pay with Visa/MC/PayPal
Users will be able to
pay for their bookings by credit
card.
Description:
Title:
Title:
Description:
Title:
Description:
Description:
Make these two
your own.
Title:
Title:
Description:
Description:
Answers on page 38.
you are here 4
Download at WoweBook.Com
35
getting more with role playing and observation
... ‫أحيانًا تبدو جلستك الزرقاء هكذا‬
Sometimes your bluesky session looks like this...
Sometimes, no matter how hard you try, your bluesky sessions can be as muffled as a
foggy day in winter. Often the people that know what the software should really do
are just not used to coming out of their shell in a brainstorming environment, and you
end up with a long, silent afternoon.
Some people will
give you lots of
information...
...and others will clam up and
give you the silent treatment.
‫ بغض النظر عن مدى‬، ‫حيان‬x‫في بعض ا‬
‫ يمكن أن تكون جلساتك‬، ‫حاولة‬P‫صعوبة ا‬
.‫الزرقاء مكتومة مثل يوم ضبابي في الشتاء‬
‫شخاص الذين يعرفون ما‬x‫غالبًا ما يكون ا‬
‫يجب أن يفعله البرنامج ح ًقا غير معتادون‬
‫على الخروج من قوقعتهم في بيئة العصف‬
‫مر بقضاء فترة ما‬x‫ وينتهي بك ا‬، ‫الذهني‬
.‫بعد الظهيرة طويلة صامتة‬
< Nothing >
Order in-flight
drinks or meals.
‫تطلبات‬P‫عاليات مفتاح تحديد ا‬P‫تطلبات الجيدة الطرق لجمع ا‬P‫زن ا‬
‫ إذا كان‬.‫صلحة‬P‫الجيدة هو إشراك أكبر عدد ممكن من أصحاب ا‬
‫ اطلب منهم تبادل‬، ‫ يعمل‬3 ‫الحصول على الجميع في نفس الغرفة‬
‫فكار بشكل فردي ثم اجتمعوا م ًعا وطرحوا كل أفكارهم على السبورة‬x‫ا‬
‫ ابتعدوا وفكروا في ما حدث وعدوا سويًا في‬.ًR‫أفكارا أكثر قلي‬
‫وطرحوا‬
ً
‫اجتماع ثان‬
The zen of good requirements
The key to capturing good requirements is to get
as many of the stakeholders involved as possible. If
getting everyone in the same room is just not working,
have people brainstorm individually and then come
together and put all their ideas on the board and brainstorm a bit
more. Go away and think about what happened and come back
together for a second meeting.
36
Chapter 2
Download at WoweBook.Com
‫هناك الكثير من الطرق لجمع‬
‫ إذا لم ينجح‬.‫تطلبات الجيدة‬P‫ا‬
‫ فما عليك سوى‬، ‫ساليب‬x‫أحد ا‬
‫تجربة طريقة أخرى‬
There are LOTS of
ways to gather good
requirements. If one
approach doesn’t work,
simply TRY ANOTHER.
gathering requirements
‫اكتشف ما يفعله الناس ح ًقا‬
‫قي وقانوني( هو لعبة عادلة إلى حد كبير عندما تحاول‬R‫كل شيء )هذا أخ‬
‫ هناك طريقتان مفيدتان بشكل‬.‫الوصول إلى رأس عميلك لفهم متطلباته‬
.‫راقبة‬P‫دوار وا‬x‫خاص تساعدك على فهم العميل وهما لعب ا‬
Find out what people REALLY do
Everything (that’s ethical and legal) is pretty much fair game when
you’re trying to get into your customer’s head to understand their
requirements. Two particularly useful techniques that help you
understand the customer are role playing and observation.
‫دوار إذا كان عميلك يجد صعوبة في تصور كيف يحتاج‬x‫لعب ا‬
‫ أنت تتظاهر بأنك البرنامج ويحاول‬.‫ فقم بذلك‬، ‫برنامجه للعمل‬
‫ ثم اكتب كل شيء يحتاج‬.‫عميلك إرشادك إلى ما يود أن تفعله‬
‫تطلبات الخاصة‬P‫البرنامج إلى القيام به على إحدى بطاقات ا‬
.‫بك‬
Role playing
If your customer is finding it hard to visualize how they need their software to work, act
it out. You pretend to be the software and your customer attempts to instruct you in
what they would like you to do. Then write down each thing the software needs to do
on one of your requirement cards.
And now I’d select the dates
for the booking...
You pretend to
“be” your software.
OK, so now I display a calendar
widget (and add display dates to
my “Create a booking” card...)
Your customer
pretends that you ar
the software and tr e
ies
to do their job.
‫شخاص مع برنامجك هي مشاهدتها‬x‫ تكون أفضل طريقة لفهم كيفية عمل ا‬، ‫حيان‬x‫حظة في بعض ا‬RP‫ا‬
‫حظة ح ًقا‬RP‫ ويمكن أن تساعد ا‬، ‫باشرة‬P‫دلة ا‬x‫ شيء يتفوق على ا‬3 .‫ناسب لبرنامجك‬P‫كان ا‬P‫ ومعرفة ا‬،
‫زرق أو حتى في لعب‬x‫في إبراز القيود والتفاصيل التي ربما تكون قد فاتتك في العصف الذهني ا‬
ً ‫ حاول‬.‫دوار‬x‫ا‬
‫ تكتسب انطبا ًعا لدى‬3 ‫ حتى‬d‫ت أكثر من مرة مع عدة مراقب‬R‫أيضا مراقبة نفس التفاع‬
.‫شخص واحد عن حدث ما‬
Observation
Sometimes the best way to understand how people will work with your software is to watch them,
and figure out where your software will fit in. Nothing beats firsthand evidence, and observation
can really help to bring out constraints and details that might have been missed in bluesky
brainstorming or even in role playing. Also, try to observe the same interactions more than once
with multiple observers so you don’t just gain one person’s impression of an event.
Yes, we offer a selection of
different types of seats...
If you can, try three
people observing on
around three occasions
Hmm, that requirement
hasn’t come up before...
ion
Try to keep your observbleat.
as unobtrusive as possi
you are here 4
Download at WoweBook.Com
37
customer-oriented requirements
‫كانت مهمتك أن تأخذ كل فكرة من جلسة‬
‫ وإنشاء بطاقة‬35 ‫ في الصفحة‬bluesky
.‫جديدة لكل متطلب محتمل‬
Our
Your job was to take each of the ideas from the bluesky session on
page 35 and create a new card for each potential requirement.
You should also role
play and observe.
Pay with Visa/MC/PayPal
Users will be able to
Description:
pay for their book ings by credi t
card or PayPal.
A nonfunctional constraint,
but it is still captured as a
user story
Title:
Order Flight DVD
A user will be able to
Description:
order a DVD of a flight they have
been on.
Review flight
Description: A user will be able to
leave a review for a shuttle flight
they have been on.
Title:
Order in-flight meals
to
Description: A user will be able
they
s
drink
and
speci fy the meals
want during a flight.
Title:
Support 3,000 concurren t
users
Description:
The traffic for Orion’s
Orbits is expected to reach 3,000
users, all using the site at the
same time.
We’ve added to our cards
from page 32 after the
brainstorming with the customer.
Title:
Title:
Bo ok a sh ut tle
utab
A usBoerokwaillshbe
tlele
le:
to
scrip
tion: A Bo
bo okDeaTit
ok
a sh
ut
sh ut
usify
er wi
tle
ll
sp
be
ec
ab
ing th etle
De
daleteto
rip
okescaof
tio
shth
an d bo
A
utn:
us
tle
tim
er
sp
wi
ec
ll be
ify ing
leta
th eabda
to
ok a sheutfligh t.
anbo
d tim
DescTit
riple:
tion:
e of thtle
ec ify ing th e data
e flispgh
an d time of th e fli t.
gh t.
These were the
requirements we came
up with; yours could
have been different.
Choose seating
A user will be able to
choose aisle or window seating.
Title:
Description:
Us e Aj ax fo r th e UI
Th e us er in te rf ac e
Description:
lo gies to
w ill us e Aj ax te ch no
sl ic k on line
prov ide a co ol an d
ex pe rien ce .
And we’ve added more detaroilugh
where it was uncovered thg, or
brainstorming, role playin
observation.
Title:
These are really
looking good, but what’s Ajax?
Isn’t that a kitchen cleaner or
something?
The boss isn’t sure he
understands what this
requirement is all about.
38
Title:
Chapter 2
Download at WoweBook.Com
gathering requirements
‫يجب أن تكون متطلباتك موجهة نحو العميل‬
Your requirements must be CUSTOMER-oriented
‫ تمت كتابة متطلبات كبيرة من منظور عميلك‬، ‫في الواقع‬
3 ‫ تعتبر أي متطلبات‬.‫تصف ما سيفعله البرنامج للعميل‬
A great requirement is actually written from your customer’s perspective
‫نها‬x ‫نظرا‬
ً ، ‫مة تحذيرية فورية‬R‫يفهمها العميل بمثابة ع‬
describing what the software is going to do for the customer. Any requirements that
.‫ليست أشياء يمكن أن يطلبها العميل‬
your customer doesn’t understand are an immediate red flag, since they’re not things that
:‫طلب بلغة العميل وقراءته كقصة مستخدم‬P‫يجب كتابة ا‬
the customer could have possibly asked for.
‫ مع البرنامج الذي تقوم‬d‫ستخدم‬P‫قصة حول كيفية تفاعل ا‬
A requirement should be written in the customer’s language and read like a user story: ‫ عند تحديد ما إذا كانت لديك متطلبات جيدة أم‬.‫بإنشائه‬
:‫ احكم على كل واحد وف ًقا للمعايير التالية‬، 3
a story about how their users interact with the software you’re building. When deciding
if you have good requirements or not, judge each one against the following criteria:
‫ستخدم‬P‫يجب أن قصص ا‬
User stories SHOULD...
.‫صف شيئ ًا واح ًدا يحتاج البرنامج إلى فعله للعميل‬
... describe one thing that the software needs to do for the customer.
.‫أن تكتب بلغة يفهمها العميل‬
You should be
able to check
each box for
each of your
user stories.
... be written using language that the customer understands.
.‫أن يكتب من قبل العميل‬
... be written by the customer.
.‫ث جمل‬R‫ يزيد عن ث‬3 ‫ تهدف إلى ما‬.‫ كن قصيرا‬...
This means the customer
drives each one, no matter
who scribbles on a notecard.
... be short. Aim for no more than three sentences.
If a user story is lon
you should try and g,
break it up into mult
smaller user stories (seiplee
page 54 for tips).
... ‫ستخدم‬P‫ تكون قصص ا‬3‫يجب أ‬
User stories SHOULD NOT...
.‫يكون مقال طويل‬
... be a long essay.
.‫ استخدم مصطلحات فنية غير مألوفة للعميل‬...
... use technical terms that are unfamiliar to the customer.
... mention specific technologies.
Us e Aj ax fo r th e UI
Th e us er in te rf ac e
Description:
lo gies to
w ill us e Aj ax te ch no
sl ic k on line
prov ide a co ol an d
ex pe rien ce .
Title:
.‫ أذكر تقنيات محددة‬...
This card is not a user
story at all; it’s really a
design decision. Save it
for later, when you start
implementing the software.
DESIGN IDEAS
Think “by the
customer, for
the customer”
‫ستخدم مكتوبة من وجهة‬P‫قصة ا‬
‫ يجب أن تفهم أنت‬.‫نظر العميل‬
‫ستخدم‬P‫وعميلك ما تعنيه قصة ا‬
A user story is
written from the
CUSTOMER’S
PERSPECTIVE.
Both you AND your
customer should
understand what a
user story means.
you are here 4
Download at WoweBook.Com
39
‫ إن الشيء العظيم في‬.(‫ مرة أخرى‬، ‫اسأل العميل )نعم‬
keep your customer in the loop
‫ هو أنه من السهل عليك وعلى العميل‬d‫ستخدم‬P‫قصص ا‬
‫ عندما تكتب‬.‫قراءتها ومعرفة ما قد يكون مفقو ًدا‬
‫ ستجد غالبًا أنهم يقولون أشياء‬، ‫ء‬R‫القصص مع العم‬
ً ‫ نحن نفعل هذا‬، ‫مثل "أوه‬
، ‫ أو "في الواقع‬، "... ‫أيضا‬
‫" هذه رائعة فرص‬... ًR‫نفعل ذلك بطريقة مختلفة قلي‬
‫ إذا وجدت أنك غير‬.‫ وجعلها أكثر دقة‬، ‫ متطلباتك‬d‫تحس‬
‫ فقد حان الوقت ‚جراء مناقشة‬، ‫واضح بشأن أي شيء‬
‫ عد واسألهم مجموعة أخرى من‬.‫أخرى مع عميلك‬
‫رحلة التالية‬P‫نتقال إلى ا‬R‫ أنت مستعد فقط ل‬.‫سئلة‬x‫ا‬
‫سئلة ويكون عميلك‬x‫زيد من ا‬P‫ يكون لديك ا‬3 ‫عندما‬
ً ‫سعي ًدا‬
‫ تلتقط كل ما‬d‫ستخدم‬P‫ن جميع قصص ا‬x ‫أيضا‬
.‫ في الوقت الحالي‬- ‫يحتاجون إلى البرنامج للقيام به‬
Great, so now you’ve created more user stories,
and gotten a bunch more questions. What do you do
with all these things you’re still unclear about?
Ask the customer (yes, again).
The great thing about user stories is that it’s easy for both you and
the customer to read them and figure out what might be missing.
When you’re writing the stories with the customer, you’ll often
find that they say things like “Oh, we also do this...”, or “Actually,
we do that a bit differently...” Those are great opportunities to
refine your requirements, and make them more accurate.
If you find that you are unclear about anything, then it’s time
to have another discussion with your customer. Go back and
ask them another set of questions. You’re only ready to move
on to the next stage when you have no more questions and
your customer is also happy that all the user stories capture
everything they need the software to do—for now.
Q:
What’s the “Title” field on my user
stories for? Doesn’t my description field
have all the information I need?
A:
The title field is just a handy way to
refer to a user story. It also gives everyone
on the team the same handy way to refer
to a story, so you don’t have one developer
talking about “Pay by PayPal,” another
saying, “Pay with credit card,” and find out
they mean the same thing later on (after
they’ve both done needless work).
Q:
Won’t adding technical terms
and some of my ideas on possible
technologies to my user stories make
them more useful to me and my team?
A:
No, avoid tech terms or technologies
at this point. Keep things in the language
of the customer, and just describe what
the software needs to do. Remember, the
user stories are written from the customer’s
perspective. The customer has to tell you
whether you’ve gotten the story right, so
a bunch of tech terms will just confuse
them (and possibly obscure whether your
requirements are accurate or not).
If you do find that there are some possible
technical decisions that you can start to add
when writing your user stories, note those
ideas down on another set of cards (cross
referencing by title). When you get to coding,
you can bring those ideas back up to help
you at that point, when it’s more appropriate.
Q:
And I’m supposed to do all this
refining of the requirements as user
stories with the customer?
40
Chapter 2
Download at WoweBook.Com
A:
Yes, absolutely. After all, you’re
only ready for the next step when both
you and the customer finally decide that
you completely understand the software
requirements. You can’t make that decision
on your own, so keeping your customer in
the loop is essential.
Q:
This seems like a lot of
requirements work up front at the
beginning of the project. What about
when things change?
A:
The work you’ve done so far is just
your first attempt at gathering requirements
at the beginning of your prject. You’ll
continue to refine and capture new
requirements throughout your project,
feeding those requirements where necessary
into your project’s iterations.
‫فكار في‬x‫ تلك ا‬d‫ء وتحس‬R‫كانت الخطوات التي اتبعناها حتى ا—ن تدور حول استيعاب أفكار العم‬
‫ في بداية كل تكرار للتأكد من أن‬، ‫ بشكل أو بآخر‬، ‫ تقوم بتنفيذ هذه الخطوات‬.d‫ستخدم‬P‫قصص ا‬
‫ دعونا نرى كيف تبدو هذه‬.‫ تنتقل إلى التكرار التالي‬gathering
‫يزات التي‬P‫من ا‬requirements
‫جموعة الصحيحة‬P‫دائما ا‬
‫لديك‬
ً
... ‫العملية حاليًا‬
‫ء‬R‫حظات العم‬R‫ل م‬R‫طور متطلباتك من خ‬
Develop your requirements with customer feedback
The steps we’ve followed so far have been all about coming to grips with the customer’s ideas and
refining those ideas into user stories. You execute these steps, in one form or another, at the beginning
of each iteration to make sure that you always have the right set of features going into the next
iteration. Let’s see how that process currently looks...
2
1
?
?
Remember, this process happens at
the beginning of each iteration, not
just the beginning of your entire
project.
Bluesky Brainstorming
Capturing basic ideas
Customer ideas...
3
You keep the
customer involved
at each step.
Constructing User Stories
Title:
Bo ok a sh ut tle
utab
A usBoerokwaillshbe
tlele
le:
to
scrip
tion: A Bo
bo okDeaTit
ok
a
sh
ut
sh ut
us
tle
er
tle
wi
ll th
sp
be
ec
ify
in
g
De
eabdaletato
sc
rip
oke aof
tio
shth
an d bo
A
utn:
us
tle
tim
er
sp ec ifywi
ll be
ing
leta
th eabda
to
ok a sheutfligh t.
anbo
d tim
DescTit
riple:
tion:
e of thtle
ec ify ing th e data
e flispgh
an d time of th e fli t.
gh t.
??
4
Refining your initial
set of user stories
Your first set of re ire
ments;
you’ll add and clarifyquth
es
further throughout your e
project’s iterations.
Finding holes and adding clarity on
details using the customer’s feedback
Choos e seating
Bo okwill
A user
a sh
beutable
tle to
Boerok
aillshbe
choos e aisle or windo
utab
A
tle
us
w
seatin
g. le to
w
le:
scrip
tion: A Bo
bo okDeaTit
ok
a sh
ut
sh ut
usify
tle
er wi
tle sp ec
ll
be
in
g
th
De
eabdaletato
rip
okescaof
tio
shth
an d bo
Aspus
utn:
tle
tim
er
wi
ec
ll
ify
be
ing
e
fli
leta
th
to
eabda
ok ae sh ut gh t.
anbo
d tim
Title:
Title:
Description:
DescTit
riple:
tion:
of thtle
ec ify ing th e data
e flispgh
an d time of th e fli t.
gh t.
oal
This is the g
this stage.
at
5
Clear, customer-focused user stories
you are here 4
Download at WoweBook.Com
41
user stories capture what your software needs to do
User Story Exposed
This week’s interview:
The many faces of a User Story
Head First: Hello there, User Story.
User Story: Hi! Sorry it’s taken so long to get an
interview, I’m a bit busy at the moment...
Head First: I can imagine, what with you and your
friends capturing and updating the requirements for
the software at the beginning of each iteration, you
must have your hands pretty full.
User Story: Actually, I’m a lot busier than that. I
not only describe the requirements, but I’m also the
main technique for bridging the gap between what
a customer wants in his head and what he receives
in delivered software. I pretty much drive everything
from here on in.
Head First: But don’t you just record what the
customer wants?
User Story: Man, I really wish that were the case.
As it turns out, I’m pretty much at the heart of an
entire project. Every bit of software a team develops
has to implement a user story.
Head First: So that means you’re the benchmark
against which every piece of software that is
developed is tested?
User Story: That means if it’s not in a user story
somewhere, it ain’t in the software, period. As you
can imagine, that means I’m kept busy all the way
through the development cycle.
Head First: Okay, sure, but your job is essentially
done after the requirements are set, right?
User Story: I wish. If there’s anything I’ve learned,
requirements never stay the same in the real world. I
might change right up to the end of a project.
42
Head First: So how do you handle all this pressure
and still keep it together?
User Story: Well, I focus on one single thing:
describing what the software needs to do from the
customer’s perspective. I don’t get distracted by the
rest of the noise buzzing around the project, I just
keep that one mantra in my head. Then everything
else tends to fall into place.
Head First: Sounds like a big job, still.
User Story: Ah, it’s not too bad. I’m not very
sophisticated, you know? Just three lines or so of
description and I’m done. The customers like
me because I’m simple and in their language,
and the developers like me because I’m just a
neat description of what their software has to do.
Everyone wins.
Head First: What about when things get a bit more
formal, like with use cases, main and alternate flows,
that sort of thing? You’re not really used then, are
you?
User Story: Heck, I can smarten myself up with
some more details to be a use case if that’s what you
need, and lots of people do dress me up that way
for their bosses. The important thing is that we all
describe what a piece of software needs to do, no
matter how we look. Use cases are more or less user
stories in a tuxedo.
Head First: Well, you heard it here first folks. Next
week we’ll be catching up with Test to see how he
guarantees that software does what a user story
requires. Until then, take care and remember, always
do only what your user story says, and not an ounce
more!
Chapter 2
Download at WoweBook.Com
gathering requirements
‫ تحدد التقديرات متى‬... ‫ ماهية مشروعك‬d‫ستخدم‬P‫تحدد قصص ا‬
User stories define the WHAT of your project...
estimates define the WHEN
After your initial requirement-capture stage you will have a set of clear,
customer-focused user stories that you and the customer believe capture
WHAT it is you’re trying to build, at least for the first iteration or so.
But don’t get too comfortable, because the customer will want to know
WHEN all those stories will be built.
This is the part where the customer asks the big question: How long
will it all take?
‫ سيكون لديك مجموعة من‬، ‫ولية‬x‫تطلبات ا‬P‫بعد مرحلة التقاط ا‬
‫ستخدم الواضحة التي تركز على العميل والتي‬P‫قصص ا‬
‫قل‬x‫ على ا‬، ‫تعتقد أنت والعميل أنها تلتقط ما تحاول بناءه‬
‫ن العميل‬x ، ‫كثيرا‬
‫ ترتاح‬3 ‫ لكن‬.‫ول أو نحو ذلك‬x‫للتكرار ا‬
ً
.‫سيرغب في معرفة متى سيتم إنشاء كل هذه القصص‬
‫ كم من‬:‫هذا هو الجزء الذي يطرح فيه العميل السؤال الكبير‬
‫مر كله؟‬x‫الوقت سيستغرق ا‬
Hmm, great. Now what do I do? How do I
figure out how long everything is going to take
when all I have so far is a pack of user stories?
‫ستخدم الخاصة بك‬P‫تقدير مشروعك هو مجموع تقديرات قصص ا‬
Your project estimate is the sum of the
estimates for your user stories
To figure out how long it will take to complete all of
the requirements captured in your user stories, you
need to use a two-step process.
You need to:
‫دة التي سيستغرقها إكمال جميع‬P‫عرفة ا‬P
‫تطلبات التي تم التقاطها في قصص‬P‫ا‬
‫ تحتاج إلى استخدام‬، ‫ستخدم الخاصة بك‬P‫ا‬
.d‫عملية من خطوت‬
:‫تحتاج إلى‬
If you can get
‫تقديرا لكل قصة مستخدم للمدة التي تعتقد أنها ستستغرق لتطوير‬
‫أضف‬
ً
.(‫ختبار وتقديم‬3‫هذه الوظيفة )أي التصميم والتشفير وا‬
figured out...
this
Add an estimate to each user story for how long you think it
will take to develop (that is, design, code, test, and deliver)
that functionality.
Add up all the estimates to get a total estimate for how long
your project will take to deliver the required software.
‫اجمع جميع التقديرات للحصول على تقدير إجمالي للمدة‬
.‫طلوبة‬P‫التي سيستغرقها مشروعك لتقديم البرامج ا‬
...then this will be a
piece of cake.
you are here 4
Download at WoweBook.Com
43
estimates come with assumptions
Welcome to the Orion’s Orbits Development Diner. Below is the menu...your job is to choose
your options for each dish, and come up with an estimate for that dish—ahem—user story.
You’ll also want to note down any assumptions you made in your calculations.
Entrées
Pay Credit Card or Paypal
Visa .......................................2 days
Mastercard ............................2 days
PayPal ...................................2 days
American Express .................5 days
Discover ................................4 days
Order Flight DVD
Stock titles with standard
definition video .....................2 days
Provide custom titles .............5 days
High Definition video ...........5 days
Order In-Flight Meals
Choose Seating
Choose aisle or
window seat ..........................2 days
Choose actual seat
on shuttle ........................... 10 days
Select from list of three meals
& three drinks .......................5 days
Allow special dietary needs
(Vegetarian, Vegan) ...............2 days
Desserts
Create Flight Review
Create a review online ..........3 days
Submit a review by email .....5 days
44
Chapter 2
Download at WoweBook.Com
gathering requirements
Pay with Visa/MC/PayPal
Users will be able to
Description:
pay for their book ings by credi t
card or PayPa l.
Estimate for each
user story in days
Assumptions?
Title:
Write your estimate
for the user story here.
Order Flight DVD
A user will be able to
Description:
of a flight they have
DVD
a
order
been on.
Title:
Jot down any assumptions
you think you’re making
in your estimate.
Cho ose seating
will be able to
Description: A user
seating .
dow
cho ose aisle or win
Title:
Order in-flight meals
A user will be able to
speci fy the meals and drink s they
want during a flight.
Title:
Description:
Review flight
A user will be able to
leave a review for a shuttle flight
they have been on.
Title:
Description:
you are here 4
Download at WoweBook.Com
45
assumptions kill confidence in your user stories
What did you come up with? Rewrite your estimates here. Bob and Laura also did
estimates...how did yours compare to theirs?
Your estimates
Bob’s estimates
Laura’s estimates
Put your estimates here.
Title:
Title::
Title::
Title::
Title::
Pay with Visa/MC/PayPal
Order Flight DVD
Cho ose seating
Order in-flight meals
Review flight
10
15
2
20
12
2
2
7
3
3
Well, at least we
seem to agree here...
It looks like everyone has a different idea for
how long each user story is going to take.
Which estimates do you think are RIGHT?
46
Chapter 2
Download at WoweBook.Com
gathering requirements
Cubicle conversation
So Laura, we can’t both be totally
wrong. But how did we get such
completely different estimates?
Laura: Well, let’s start with the first user story. How did you come up with 10
days?
Bob: That’s easy, I just picked the most popular credit cards I could think of, and
added time to support PayPal...
Laura: But lots of high-end executives only use American Express, so my
assumption was that we’d have to cope with that card, too, not just Visa and
MasterCard.
Bob: Okay, but I’m still not feeling entirely happy with that. Just that one
assumption is making a really big difference on how long it will take to develop
that user story...
Laura: I know, but what can you do, we don’t know what the customer expects...
Bob: But look at this...you came up with 20 days for “Ordering a Flight DVD,”
but even with all the options, that should be 14 days, max!
‫فتراضات هو أهم نشاط للتوصل إلى‬3‫التخلص من ا‬
.‫تقديرات تؤمن بها‬
Getting rid of
assumptions
is the most
important
activity for
coming up with
estimates you
believe in.
Laura: I was actually being on the conservative side. The problem is that creating
a DVD is a completely new feature, something I haven’t done before. I was
factoring in overhead for researching how to create DVDs, installing software, and
getting everything tested. Everything I thought I’d need to do to get that software
written. So it came out a lot higher.
Bob: Wow, I hadn’t even thought of those things. I just assumed that they’d been
thought of and included. I wonder if the rest of the estimates included tasks like
research and software installation?
Laura: In my experience, probably not. That’s why I cover my back.
Bob: But then all of our estimates could be off...
Laura: Well, at least we agree on the “Create a Flight Review” story. That’s
something.
Bob: Yeah, but I even had assumptions I made there, and that still doesn’t take
into account some of that overhead you were talking about.
Laura: So all we have are a bunch of estimates we don’t feel that confident about.
How are we going to come up with a number for the project that we believe when
we don’t even know what everyone’s assumptions are?
you are here 4
Download at WoweBook.Com
47
‫فتراضات التي تعرض تقديراتك‬3‫ تحتاج إلى التخلص من كل تلك ا‬، ‫للتوصل إلى تقديرات دقيقة‬
highlighting assumptions and obtaining confident estimates with
‫في‬planning
‫الجميع ويثقون‬poker
‫ أنت تريد مجموعة من التقديرات التي يؤمن بها‬.‫لخطر الوقوع في الخطأ‬
‫فتراضات‬3‫قل تريد مجموعة من التقديرات التي تتيح لك معرفة ا‬x‫ أو على ا‬، ‫قدرتها على تقديمها‬
‫ستحواذ على كل من‬R‫ حان الوقت ل‬.‫نقط‬P‫التي يتخذها الجميع قبل التوقيع على الخط ا‬
‫ستعداد للعب‬3‫ والجلوس حول طاولة وا‬، ‫ستخدم الخاصة بك‬P‫سيشارك في تقدير قصص ا‬
."‫"التخطيط للبوكر‬
‫لعب البوكر التخطيط‬
Playing planning poker
To come up with accurate estimates, you need to get rid of all those assumptions that put
your estimates at risk of being wrong. You want a set of estimates that everyone believes in
and are confident that they can deliver, or at the very least you want a set of estimates that let
you know what assumptions everyone is making before you sign on the dotted line. It’s time
to grab everyone that’s going to be involved in estimating your user stories, sit them around a
table, and get ready to play “planning poker.”
‫ستخدم في منتصف الجدول‬P‫ضع قصة ا‬
Place a user story in the middle of the table
This focuses everyone on a specific user story so they can get their heads around
what their estimates and assumptions might be. ‫يركز هذا الجميع على قصة مستخدم معينة حتى يتمكنوا من فهم‬
1
.‫ما قد تكون عليه تقديراتهم وافتراضاتهم‬
Pay with Visa/MC/PayPal
Users will be able to
Description:
pay for their booki ngs by credit
card or PayPa l.
Title:
We want a solid esti
how long it will takematote for
this story. Don’t forg develop
development should inclet that
designing, coding, testinude
delivering the user stor g, and
y.
‫ كل بطاقة لها تقدير مكتوب على‬.‫ بطاقة‬13 ‫يحصل كل شخص على مجموعة من‬
.‫جانب واحد‬
Everyone is given a deck of 13 cards. Each card has an
estimate written on one side. :‫نح الناس عدة خيارات‬P ‫ يكفي فقط‬، ‫تحتاج فقط إلى سطح صغير‬
You only need a small deck, just enough to give people several options:
2
This card
means “It’s
already done.”
0
days
8
days
13
days
Everyone has each of these cards.
48
1/2
day
1
day
20
days
2
days
3
5
days days
40 100
days days
Hmmm...any thoughts on what it
means if someone plays one of these
cards for their estimate?
Chapter 2
Download at WoweBook.Com
All of these
estimates are or
developer-days (finstance, two mann
days split betwee ill
two workers is st
two days).
?
If any player uses
Don’t have enough
this card, you need
info to estimate? You to take
might consider using estimatinag break from
for a bit.
this card.
gathering requirements
‫ستخدم ويضع ملف‬P‫تقديرا لقصة ا‬
‫يختار الجميع‬
ً
.‫سفل على الطاولة‬x ‫قابلة‬P‫وجه البطاقة ا‬
3
Everyone picks an estimate for the user story and places the
corresponding card face down on the table.
You pick the card that you think is a reasonable estimate for the user story.
Don’t discuss that estimate with anyone else, though.
.‫ستخدم بالكامل هذا التقدير مع أي شخص آخر‬P‫ يناقش ا‬3 .‫ستخدم‬P‫أنت تختار البطاقة التي تعتقد أنها تقدير معقول لقصة ا‬
Make sure your
estimate is for
the whole user
story, not just
a part of it.
The user story
is still in the
middle... still
the focus.
Place your choice
face-down so you e
keep your estimat
from everyone else
.‫يقوم الجميع بعد ذلك بتسليم بطاقاتهم في نفس الوقت بالضبط‬
4
Everyone then turns over their cards at exactly the same time.
Each player at the table shows their hand, which gives their honest estimate
for the user story.
.‫ستخدم‬P‫ مما يعطي تقديره الصادق لقصة ا‬، ‫عب على الطاولة يده‬3 ‫يظهر كل‬
These almostatch
never all m okay.
up... that’s
.‫مة أسفل السبريد عبر كل من التقديرات‬4‫يضع التاجر ع‬
5
The dealer marks down the spread across each of the estimates.
Whoever is running the game notes the spread across each of the estimates that
are on the cards. Then you do a little analysis:
Ask
‫ ثم تقوم‬.‫وجودة على البطاقات‬P‫نتشار عبر كل من التقديرات ا‬3‫حظ ا‬R‫كل من يدير اللعبة ي‬
:‫ببعض التحليل‬
an accurate
re
It’s probably safe to fiinguthis range.
e
er
wh
estimate is some
8
13
20
100
the d
card whatetveloper who played th
about; don’t hey were thinking is
pull out the ignore them, try to
assumptions
they made.
The larger the difference between the estimates, the less confident you
are in the estimate, and the more assumptions you need to root out.
‫فتراضات التي تحتاج إلى‬3‫ وزادت ا‬، ‫ قلت ثقتك في التقدير‬، ‫ التقديرات‬d‫ف ب‬R‫خت‬3‫كلما زاد ا‬
.‫استئصالها‬
Download at WoweBook.Com
you are here 4
49
assumptions are killed or become risks
How does this help with assumptions?
And what about that guy who chose
100? We can’t just ignore him, can we?
‫سعار الكبيرة يمكن أن تكون سوء فهم‬x‫فروق ا‬
Large spreads can be a misunderstanding
When you see large gaps between the estimates on a particular
user story’s spread, something is probably missing. It could be
that some of your team misunderstood the user story, in which
case it’s time to revisit that story. Or it could be that some
members of your team are just unsure of something that another
part of your team is completely happy with.
In either case, it’s time to look at the assumptions that your team
is making and decide if you need to go back and speak to the
customer to get some more feedback and clarification on your
user stories—and the assumptions you’re making about them.
In fact, even if everyone’s estimate is within the same narrow
range, it’s worth asking for everyone’s assumptions to make sure
that EVERYONE is not making the same wrong assumption.
It’s unlikely that they are, but just in case, always discuss and
document your assumptions after every round of planning poker.
‫ التقديرات حول انتشار قصة‬d‫عندما ترى فجوات كبيرة ب‬
‫ قد‬.‫حتمل أن يكون هناك شيء مفقود‬P‫ فمن ا‬، d‫مستخدم مع‬
‫يكون السبب هو أن بعض أعضاء فريقك أساءوا فهم قصة‬
‫ وفي هذه الحالة حان الوقت ‚عادة النظر في تلك‬، ‫ستخدم‬P‫ا‬
‫ أو قد يكون بعض أعضاء فريقك غير متأكدين من‬.‫القصة‬
، d‫ في كلتا الحالت‬.‫شيء يسعد به جزء آخر من فريقك تما ًما‬
‫فتراضات التي يضعها فريقك وتحديد‬3‫حان الوقت للنظر في ا‬
‫ما إذا كنت بحاجة إلى العودة والتحدث إلى العميل للحصول‬
‫ستخدم‬P‫على مزيد من التعليقات والتوضيحات حول قصص ا‬
، ‫ في الواقع‬. ‫فتراضات التي تضعها عنها‬3‫ وا‬- ‫الخاصة بك‬
‫ فمن‬، ‫حتى لو كان تقدير الجميع ضمن نفس النطاق الضيق‬
3 ‫الجدير طلب افتراضات الجميع للتأكد من أن الجميع‬
‫حتمل أن يكونوا‬P‫ من غير ا‬.‫فتراضات الخاطئة‬3‫يتخذون نفس ا‬
‫دائما‬
‫ ناقش‬، ‫ ولكن فقط في حالة حدوث ذلك‬، ‫كذلك‬
ً
.‫افتراضاتك ووثقها بعد كل جولة تخطيط بوكر‬
50
Try writing your
assumptions on the back
of your user story cards.
Chapter 2
Download at WoweBook.Com
gathering requirements
‫حاكمة على حياتهم‬P‫فتراضات قيد ا‬3‫ضع ا‬
Put assumptions on trial for their lives
When it comes to requirements, no assumption is a good
assumption. So whenever planing poker turns up your team’s
assumptions, don’t let that assumption into your project without first
doing everything you can to beat it out of your project...
‫ يوجد‬3 ، ‫تطلبات‬P‫مر با‬x‫عندما يتعلق ا‬
‫ عندما تؤدي لعبة‬، ‫ لذلك‬.‫افتراض جيد‬
3 ، ‫البوكر إلى عرض افتراضات فريقك‬
‫فتراض يدخل في مشروعك‬3‫تدع هذا ا‬
‫ً كل ما في وسعك‬3‫دون أن تفعل أو‬
... ‫للتغلب عليه خارج مشروعك‬
Put every assumption on trial
You’re aiming for as few assumptions as possible
when making your estimates. When an assumption
rears its head in planning poker, even if your entire
team shares the assumption, expect that assumption to
be wrong until it is clarified by the customer.
As opposed to not knowing what
you don’t know...
At least you know what you don’t know
No matter how hard you try, some assumptions really will survive clarification with
the customer. That’s OK. Sometimes the customer doesn’t have a great answer to
a particular assumption at the beginning of a project, and in those cases you need
to live with the assumption. The important thing is that you know that there is an
assumption being made, and you can write it down as a risk for that user story (like on
the back of your user story card). This helps you keep an eye on and track your risks,
knocking them out at a later stage in your project.
‫ تعرفه بغض النظر عن مدى صعوبة‬3 ‫قل أنت تعرف ما‬x‫على ا‬
‫فتراضات حقا ً موضع توضيح مع‬3‫ ستظل بعض ا‬، ‫حاولة‬P‫ا‬
‫ يكون لدى العميل‬3 ‫حيان‬x‫ في بعض ا‬.‫ هذا حسن‬.‫العميل‬
‫ وفي هذه‬، ‫شروع‬P‫ في بداية ا‬d‫فتراض مع‬3 ‫إجابة جيدة‬
‫هم هو‬P‫ الشيء ا‬.‫فتراض‬3‫ت تحتاج إلى التعايش مع ا‬3‫الحا‬
ً
‫ ويمكنك كتابته على‬، ‫افتراضا يتم إجراؤه‬
‫أنك تعرف أن هناك‬
‫ستخدم‬P‫ستخدم )مثل ظهر بطاقة قصة ا‬P‫أنه خطر على قصة ا‬
‫ يساعدك هذا في مراقبتها وتتبع إخراجها في‬.(‫الخاصة بك‬
‫حقة من مشروعك‬3 ‫مرحلة‬
، ‫فتراضات‬3‫دائما التخلص من جميع ا‬
‫ يمكنك‬3 ‫بينما‬
ً
‫فإن الهدف أثناء التقدير هو التخلص من أكبر عدد‬
‫ل توضيح تلك‬R‫فتراضات من خ‬3‫ممكن من ا‬
‫ ثم تصبح أي افتراضات باقية‬.‫فتراضات مع العميل‬3‫ا‬
.‫مخاطر‬
Depending on customer
priority, you might even
decide to delay the
development of a user er of
story that has a numb til
surviving assumptions un
they can be clarified.
While you can’t always get rid of all
assumptions, the goal during estimation
is to eliminate as many assumptions as
possible by clarifying those assumptions
with the customer. Any surviving
assumptions then become risks.
you are here 4
Download at WoweBook.Com
51
use your customer effectively
With all this talk of customer
clarification, it seems to me that you could
be bothering the customer too much. You
might want to think about how you use the
customer’s time effectively...
‫ يمكن أن يصبح وضع جميع افتراضاتك قيد التجربة‬.‫قدر وقت عميلك‬
ًR‫طوال حياتهم وطلب التوضيح من العميل عم‬
‫ يمكنك بسهولة‬.‫كثيرا‬
ً
‫ قد يكون هذا جي ًدا‬.‫ من وقتك مع عميلك‬، ‫ إن لم يكن كله‬، ‫قضاء الكثير‬
3 ‫ ج ًدا بحيث‬d‫شغول‬P‫ء ا‬R‫ ولكن ماذا عن العم‬، ‫ء‬R‫مع بعض العم‬
‫ تحتاج إلى‬، ‫ت‬3‫ دقيقة؟ في هذه الحا‬15 ‫يمكنهم التحدث معك كل‬
‫ على الرغم من أنك تحاول التأكد من صحة‬.‫ل وقت عميلك بعناية‬R‫استغ‬
‫ تريد أن تصادف أنك لست على‬3 ‫ أنك‬3‫ إ‬، ‫مور في مشروعهم‬x‫ا‬
‫ تأكد من أن‬، ‫ لذلك عندما تقضي وقت ًا مع عميلك‬.‫مستوى الوظيفة‬
‫ حاول جمع مجموعة من‬.‫الوقت منظم وفعال ومستهلك جي ًدا‬
‫ً من‬3‫ بد‬.‫فتراضات م ًعا ثم توضيحها م ًعا مرة واحدة مع العميل‬3‫ا‬
‫ حدد‬، ‫ت التخطيط للعبة البوكر‬3‫إزعاج العميل في نهاية كل جولة من جو‬
‫فتراضات التي تم‬3‫فتراضات حيث تأخذ ا‬3‫موع ًدا لجلسة لكسر ا‬
.‫جمعها وحاول تفجير أكبر عدد ممكن منها بعي ًدا‬
Value your customer’s time.
Putting all your asssumptions on trial for their life and seeking
clarification from the customer can become a lot of work. You can
easily spend a lot, if not all, of your time with your customer. That
might be OK with some customers, but what about the ones that are
too busy to talk with you every 15 minutes?
In those cases you need to use your customer’s time carefully. Even
though you’re trying to make sure you’ve gotten things right on their
project, you don’t want to come across as being not up to the job. So
when you do spend time with your customer, make sure that time is
organized, efficient, and well-spent.
Try gathering a collection of assumptions together and then clarifying
those all at once with the customer. Rather than bothering the
customer at the end of every round of planing poker, schedule an
assumption-busting session where you take in the collected
assumptions and try to blast as many of them away as possible.
Once you have your answers, head back for a
final round of planning poker.
Once you’ve gotten a significant number of your assumptions
beaten out in your assumption-busting session with the customer,
it’s time to head back and play a final round of planning poker
so that you and your team can come up with estimates that
factor in the new clarifications.
‫خيرة من‬x‫ عد للجولة ا‬، ‫بمجرد حصولك على إجاباتك‬
‫ بمجرد حصولك على عدد كبير من‬.‫التخطيط للبوكر‬
‫افتراضاتك التي تم التغلب عليها في جلسة تحطيم‬
‫ فقد حان الوقت للعودة ولعب‬، ‫فتراضات مع العميل‬3‫ا‬
‫خيرة من التخطيط للبوكر حتى تتمكن أنت وفريقك‬x‫الجولة ا‬
‫ التوضيحات‬.‫من التوصل إلى تقديرات لهذا العامل‬
.‫الجديدة‬
52
Chapter 2
Download at WoweBook.Com
gathering requirements
Q:
Why is there a gap between 40 and
100 days on the planning poker cards?
A:
Well, the fact is that 40 is a pretty
large estimate, so whether you feel that the
estimate should be 41 or even 30 days is
not really important at this point. 40 just says
that you think there’s a lot to do in this user
story, and you’re just on the boundary of not
being able to estimate this user story at all...
get caught up in the game. However, every
estimate, particularly ones that are out of
whack with the rest of the player’s estimates,
should come under scrutiny after every
round to highlight the assumptions that are
driving those estimates.
Q:
After a few rounds where you start to realize
that those wacky estimates are not really
backed up by good assumptions, you can
either think about removing those people
from the table, or just having a quiet word
with them about why they always insist on
being off in left field.
A:
Should we be thinking about who
implements a user story when coming up
with our estimates?
100 days seems really long; that’s
around half a year in work time! Why have
100 days on the cards at all?
Absolutely, 100 days is a very long
time. If someone turns up a 100-days
card then there’s something seriously
misunderstood or wrong with the user story.
If you find that it’s the user story that’s
simply too long, then it’s time to break that
user story up into smaller, more easily
estimatable stories.
Q:
What about the question-mark
card? What does that mean?
A:
That you simply don’t feel that you
have enough information to estimate this
user story. Either you’ve misunderstood
something, or your assumptions are so big
that you don’t have any confidence that any
estimate you place down on the table could
be right.
Q:
Some people are just bound to pick
nutty numbers. What do I do about them?
A:
Good question. First, look at the trends
in that individual’s estimates to see if they
really are being “nutty,” or whether they in
fact tend to be right! However, some people
really are inclined to just pick extremely high
or very low numbers most of the time and
Q:
A:
No, every player estimates how long
they think it will take for them to develop
and deliver the software that implements the
user story. At estimation time you can’t be
sure who is going to actually implement a
particular user story, so you’re trying to get
a feel for the capability of anyone on your
team to deliver that user story.
Of course, if one particular user story is
perfect for one particular person’s skills, then
they are likely to estimate it quite low. But
this low estimate is balanced by the rest of
your team, who should each assume that
they are individually going to implement that
user story.
In the end, the goal is to come up with an
estimate that states “We as a team are all
confident that this is how long it will take any
one of us to develop this user story.”
Q:
Each estimate is considering more
than just implementation time though,
right?
A:
Yes. Each player should factor in how
much time it will take them to develop and
deliver the software including any other
deliverables that they think might be
needed. This could include documentation,
testing, packaging, deployment—basically
everything that needs to be done to develop
and deliver the software that meets the user
story.
If you’re not sure what other deliverables
might be needed, then that’s an assumption,
and might be a question for the customer.
Q:
What if my team all agree on
exactly the same estimate when the cards
are turned over. Do I need to worry about
assumptions?
A:
Yes, for sure. Even if everyone agrees,
it’s possible that everyone is making the
same wrong assumptions. A large spread
of different estimates indicates that there
is more work to be done and that your
team is making different and possibly large
assumptions in their estimates. A tiny spread
says that your team might be making the
same assumptions in error, so examining
assumptions is critical regardless of the
output from planning poker.
It’s important to get any and all assumptions
out in the open regardless of what the
spread says, so that you can clarify those
assumptions right up front and keep your
confidence in your estimates as high as
possible.
‫ تصنع‬3
Don’t make
assumptions about
your assumptions...
talk about
EVERYTHING.
‫افتراضات حول‬
‫ تحدث‬... ‫افتراضاتك‬
.‫عن كل شيء‬
you are here 4
Download at WoweBook.Com
53
keep estimates small
‫ستخدم هو تقدير سيء‬P‫التقدير الكبير لقصة ا‬
‫ستخدم‬P‫لقصة ا‬
A BIG user story estimate is
a BAD user story estimate
We all agree, we don’t need any
more information. This user story
will take 40 days to develop...
Remember this
from Chapter 1?
If you have to have
long estimates like
this, then you need
to be talking as a
team as often as
possible. We’ll get to
that in a few pages.
، ‫ يو ًما هي فترة طويلة‬40 .‫ستخدم الخاصة بك كبيرة ج ًدا‬P‫قصة ا‬
.‫ يو ًما هي شهرين من وقت العمل‬40 ‫ تذكر أن‬.‫ويمكن أن يتغير الكثير‬
‫ خذ‬.‫ يجب أن تكون مدة التكرار بالكامل حوالي شهر تقويمي واحد‬7
‫ إذا كان‬.‫ يوم عمل‬20 ‫ وهذا حوالي‬، ‫ت‬R‫سبوع والعط‬x‫ت نهاية ا‬R‫عط‬
‫ فلن تتناسب حتى مع‬، ‫ يو ًما لقصة مستخدم واحدة فقط‬40 ‫تقديرك‬
‫ن على ذلك! كقاعدة‬R‫تكرار واحد للتطوير ما لم يكن لديك شخصان يعم‬
‫ يو ًما‬15 ‫رجح أن تكون التقديرات التي تزيد مدتها عن‬P‫ من غير ا‬، ‫عامة‬
‫ يو ًما‬15 ‫دقيقة من التقديرات التي تقل عن‬
Your user story is too big.
40 days is a long time, and lots can change.
Remember, 40 days is 2 months of work time.
An entire iteration should ideally be around
1 calendar month in duration. Take out
weekends and holidays, and that’s about 20
working days. If your estimate is 40 days for
just one user story, then it won’t even fit in one
iteration of development unless you have two
people working on it!
As a rule of thumb, estimates that are longer
than 15 days are much less likely to be accurate
than estimates below 15 days.
In fact,
:‫ يمكنك إما‬، ‫ يو ًما‬15 ‫ستخدم قاعدة الـ‬F‫عندما يخالف تقدير قصة ا‬
some people believe that
estimates longer than seven days
should be double-checked.
When a user story’s estimate breaks the
1
15-day rule you can either:
‫تقديرا‬
‫قسم قصصك إلى قصص أصغر وأسهل‬
ّ
ً
1
Break your stories into smaller, more easily
estimated stories
Apply the AND rule. Any user story that has an “and” in
its title or description can probably be split into two or
more smaller user stories.
‫ يمكن تقسيم أي قصة مستخدم تحتوي على "و" في عنوانها أو‬.AND ‫طبق قاعدة‬
.‫ستخدم\ ا[صغر‬F‫وصفها إلى قصت\ أو أكثر من قصص ا‬
2
Starting to sense
a pattern?
Talk to your customer...again.
Maybe there are some assumptions that are pushing
your estimate out. If the customer could clarify things,
those assumptions might go away, and cut down your
2
estimates significantly.
.‫ مرة أخرى‬... ‫تحدث إلى عميلك‬
‫ إذا تمكن العميل من‬.‫فتراضات التي تدفع بتقديراتك للخارج‬g‫ربما هناك بعض ا‬
.‫فتراضات وتقليل تقديراتك بشكل كبير‬g‫ فقد تختفي هذه ا‬، ‫توضيح ا[مور‬
54
Chapter 2
Download at WoweBook.Com
‫ يو ًما‬15 ‫تتيح التقديرات التي تزيد عن‬
‫لكل قصة مستخدم مساحة كبيرة ج ًدا‬
.‫للخطأ‬
Estimates greater
than 15 days per
user story allow too
much room for error.
When an estimate is
too long, apply the
AND rule to break
the user story into
smaller pieces.
‫ قم‬، ‫ً ج ًدا‬R‫عندما يكون التقدير طوي‬
‫ لتقسيم قصة‬AND ‫بتطبيق قاعدة‬
.‫ستخدم إلى أجزاء أصغر‬P‫ا‬
gathering requirements
The two user stories below resulted in estimates that broke the 15-day rule. Take the two
user stories and apply the AND rule to them to break them into smaller, more accurately
estimatable stories.
Choos e seati ng
Description: A user will choos e
aisle or window seati ng, be able
to select the seat they want, and
change that seat up to 24 hours
before the flight.
Title:
Title:
Description:
Orde r in-f light mea ls
Description: A user will choo se
which mea l opti on they wan t,
from a choice of thre e, and be able
to indic ate if they are vege tari an
or vega n.
Title:
Title:
Description:
Title:
Title:
Description:
Description:
Title:
Title:
Description:
Description:
you are here 4
Download at WoweBook.Com
55
aim for estimates you and your team believe in
Your job was to take the longer user stories at the top of each column and turn them into
smaller, easily estimatable user stories.
Choos e seati ng
Description: A user will choos e
aisle or window seati ng, be able
to select the seat they want, and
change that seat up to 24 hours
before the flight.
Title:
Choose aisle/w indow seat
Description: A user can choose
either aisle or window seating .
Title:
Choose specific seat
Description: A user can choose the
actual seat that they want for a
shuttle flight.
Title:
Change seating
Description: A user can change
their seat up to 24 hours before
launch, provided other seat
options are available.
Title:
56
Orde r in-f light mea ls
Description: A user will choo se
which mea l opti on they wan t,
from a choice of thre e, and be able
to indic ate if they are vege tari an
or vega n.
Title:
Select from meal options
Description: A user can choose
the meal they want from a set of
three meal options.
Title:
Specify vegetarian meal
Description: A user will be able to
indicate that they are vegetarian
when selecting their meal options.
Title:
Specify vegan meal
Description: A user will be able
to indicate that they are vegan
when selecting their meal options.
Title:
Chapter 2
Download at WoweBook.Com
gathering requirements
The goal is convergence
After a solid round of planning poker, you should not only have estimates
for each user story but be confident in those estimates. The goal now is to
get rid of as many assumptions as possible, and to converge all of the
points on each user story’s spread of estimates.
‫الهدف هو التقارب‬
‫ يكون‬3‫ يجب أ‬، ‫بعد جولة قوية من التخطيط للعبة البوكر‬
‫ بل يجب أن‬، ‫لديك تقديرات لكل قصة مستخدم فحسب‬
‫ الهدف ا—ن هو التخلص‬.‫تكون واث ًقا من هذه التقديرات‬
‫ وتقريب جميع‬، ‫فتراضات‬3‫من أكبر عدد ممكن من ا‬
.‫النقاط حول انتشار تقديرات قصة كل مستخدم‬
ty
These estimates are pret
close to one another.
8 10
The estimate you
and your team
reach consensus on.
13
15
You’ve gotten rid of .
any outlying estimates
:‫قم بتشغيل هذه الدائرة من الخطوات حتى تصل إلى توافق في ا—راء‬
Run through this cycle of steps till you reach a consensus:
1
1
‫علومات وقم بإزالة أكبر عدد‬F‫ احصل على أكبر قدر من ا‬، ‫ً وقبل كل شيء‬g‫تحدث إلى العميل أو‬
.‫ل التحدث إلى عميلك‬4‫فتراضات وسوء الفهم من خ‬g‫ممكن من ا‬
Talk to the customer
First and foremost, get as much information and remove as many assumptions
and misunderstandings as possible by talking to your customer.
‫ ستتعلم بسرعة‬.‫ع أي افتراضات خفية‬4‫قت‬g ‫ستخدم الخاصة بك‬F‫ العب بوكر التخطيط العب بوكر التخطيط مع كل قصة من قصص ا‬2
‫ وضح افتراضاتك‬.‫مدى ثقتك في قدرتك على تقدير العمل الذي يجب القيام به‬
2
Play planning poker
Play planning poker with each of your user stories to uproot any hidden
assumptions. You’ll quickly learn how confident you are that you can
estimate the work that needs to be done.
‫ وأين يلزم توضيح إضافي‬، ‫ستخدم‬F‫ ستتمكن من معرفة أين أساء فريقك فهم قصص ا‬، ‫ باستخدام نتائج التخطيط للعبة البوكر‬3
3
Clarify your assumptions
Using the results of planning poker, you’ll be able to see where your
team may have misunderstood the user stories, and where additional
clarification is needed.
‫ستخدم‬F‫ اتفق على رقم لتقدير قصة ا‬، ‫ تعال إلى توافق في ا•راء بمجرد اقتراب تقديرات الجميع‬4 .
4
Come to a consensus
Once everyone’s estimates are close, agree on a figure for the user
story’s estimate.
How close is “close enough”?
if you
Head back to Step 1at only
find assumptions thanswer.
the customer can
to
It can also be usefulerged,
note the low, conv to
and high estimates the
give you an idea ofse
best and worst ca
scenarios.
Deciding when your estimates are close enough for consensus is really up to you.
When you feel confident in an estimate, and you’re comfortable with the
assumptions that have been made, then it’s time to write that estimate down on
your user story card and move on.
‫ما مدى قرب "قريبة بما فيه الكفاية"؟ إن تحديد متى تكون تقديراتك قريبة بما يكفي لتحقيق توافق في‬
‫ فقد‬، ‫فتراضات التي تم إجراؤها‬4‫ وأنت مرتاح ل‬، ‫ عندما تشعر بالثقة في التقدير‬.‫ ا•راء متروك لك ح ًقا‬you are here 4
.‫ضي قد ًما‬F‫ستخدم وا‬F‫حان الوقت لكتابة هذا التقدير على بطاقة قصة ا‬
Download at WoweBook.Com
57
your estimates are your promise
Q:
How can I tell when my estimates are close enough,
and have really converged?
A:
Q:
I’m finding it hard to come up with an estimate for my
user story, is there a way I can better understand a user story
to come up with better initial estimates?
Estimates are all about confidence. You have a good
estimate if you and your team are truly confident that you can
deliver the user story’s functionality within the estimate.
A:
I have a number of assumptions, but I still feel
confident in my estimate. Is that okay?
Sometimes a user story is just a bit blurry and complicated.
When that happens, try breaking the user story into tasks in your
head—or even on a bit of paper—you’ve got next to you at your
planning poker sessions.
Q:
A:
Really, you should have no assumptions in your user
stories or in you and your team’s understanding of the customer’s
requirements.
Every assumption is an opportunity to hit unexpected problems
as you develop your software. Worse than that, every assumption
increases the chances that your software development work will
be delayed and might not even deliver what was required.
Even if you’re feeling relatively confident, knock out as many of
those assumptions as you possibly can by speaking to your team
and, most importantly, speaking to your customer.
With a zero-tolerance attitude to assumptions, you’ll be on a
much more secure path to delivering your customer the software
that’s needed, on time and on budget. However, you will probably
always have some assumptions that survive the estimation
process. This is OK, as assumptions are then turned into risks
that are noted and tracked, and at least you are aware of those
risks.
Your estimates are your
PROMISE to your customer
about how long it will take you
and your team to DELIVER.
First, if your user story is complicated, then it may be too
big to estimate confidently. Break up complex stories into simpler
ones using the AND rule or common sense.
Think about the jobs that will be needed to be done to build that
piece of software. Imagine you are doing those jobs, figure out
how long you would take to do each one, and then add them all
up to give you an estimate for that user story.
Q:
How much of this process should my customer
actually see?
A:
Your customer should only see and hear your questions,
and then of course your user stories as they develop. In particular,
your customer is not involved in the planning poker game.
Customers will want lower-than-reasonable estimates, and can
pressure you and your team to get overly aggressive.
When there is a question about what a piece of the software is
supposed to do in a given situation, or when an assumption is
found, then involving the customer is absolutely critical. When
you find a technical assumption being made by your team that
you can clarify without the customer, then you don’t have to go
back and bother them with details they probably won’t understand
anyway.
But when you’re playing planning poker, you are coming up with
estimates of how long you believe that your team will take to
develop and deliver the software. So it’s your neck on the line,
and your promise. So the customer shouldn’t be coming up with
those for you.
‫دة التي‬F‫تقديراتك هي وعدك لعميلك حول ا‬
.‫ستستغرقها أنت وفريقك للتسليم‬
58
Chapter 2
Download at WoweBook.Com
‫ بالزي‬، ‫تطلبات‬F‫مجموعة من التقنيات للعمل مع ا‬
‫ "من أنا؟" سوف‬، ‫ تلعب لعبة جماعية‬، ‫الكامل‬
‫يعطونك فكرة ثم تحاول تخم\ من هم بنا ًء على ما‬
‫دائما يقولون الحقيقة عن‬
‫ افترض أنهم‬.‫يقولون‬
ً
‫وجودة بجوار كل عبارة‬F‫ الفراغات ا‬Š‫ ام‬.‫أنفسهم‬
‫صحيحا‬
‫باسم )أو أسماء( كل حاضر يكون البيان‬
ً
‫ يمكن استخدام الحضور في أكثر من‬.‫بالنسبة له‬
:‫إجابة واحدة للحاضرين الليلة‬
A bunch of techniques for working with requirements, in full
costume, are playing a party game, “Who am I?” They’ll give you
a clue and then you try to guess who they are based on what
they say. Assume they always tell the truth about themselves. Fill
in the blanks next to each statement with the name (or names)
of each attendee that the statement is true for. Attendees may be
used in more than one answer
Tonight’s attendees:
gathering requirements
W ho a
m I?
‫حظة‬4F‫ ا‬- ‫ لعب ا[دوار‬- ‫البلوز‬
‫ تخطيط لعبة البوكر‬- ‫ تقدير‬- ‫ستخدم‬F‫قصة ا‬
Blueskying – Role playing – Observation
User story – Estimate – Planning poker
You can dress me up as a use case for a
formal occasion.
The more of me there are, the clearer
things become.
I help you capture EVERYTHING.
I help you get more from the customer.
In court, I’d be admissible as firsthand
evidence.
Some people say I’m arrogant, but really I’m
just about confidence.
Everyone’s involved when it comes to me.
Answers on page 62.
you are here 4
Download at WoweBook.Com
59
‫شرط تقدير دورة التكرار‬
‫ دعونا نلقي نظرة‬.‫تطلبات‬F‫لقد أضفنا ا•ن بعض الخطوات الجديدة في نهجنا التكراري لتطوير ا‬
... ‫على كيفية تناسب التقدير مع عمليتنا‬
develop your estimates cyclically
The requirement to estimate iteration cycle
We’ve now added some new steps in our iterative approach to requirements
development. Let’s look at how estimation fits into our process...
2
1
Capturing basic ideas
Customer ideas...
3
?
?
Constructing User Stories
Bluesky Brainstorming
Title:
Bo ok a sh ut tle
utab
A usBoerokwia llshbe
tlele
to
Bo
bo ok a sh ut tle sp
okr wi
a sh
Aec
ut
use
tle
ll th
be
ab
ify
leteto
ing
e
da
ok
a
sh
an d bo
A
ut
use
time of th etle
spe
wi llg be
cifr yin
leta
th eabda
to
ok a sh utfligh t.
anbo
d tim
DescTit
riple:
tion:
DeTit
scrle:
iption:
Description:
e of thtle
e flispe
ghcif ying th e data
an d time of th e fli t.
gh t.
8 10 15
13
converged, and you
Your spreads are now ea
user story.
have an estimate for ch
We’re now ready to
estimate how long
the project as a
whole is going to take.
E st i m ate !
Select from meal options
Choose
can choose
seatingthe
A user
3 to
of ttle
Booawill
from
kset
user
a shu
meal they want A
be
able
Boo
a shu
choose
aisle
A use r kwil
meal options. Titleor: window
seating.
l bettle
able
boo kDes
k will
a shubettle to
a crip
A Boo
shution
user
ttle: spe
cify
ing theable
Des
datto
a
tion: A user
ke crip
aofshu
and boo
tim
spe
cifywill
thettle
ing be
flig
theable
ht.
datto
a
boo
and tim
k a shu
Title:
8
Title:
Description:
Title
Descriptio:n:
Title:
Descrip
tion:
Estimate how long all of the
customer’s requirements will take
ttleflig
e of the
speht.
cify ing the dat a
and time of the flig
ht.
7
60
Get any missing information
from the customer, and break up
large user stories
Chapter 2
Download at WoweBook.Com
gathering requirements
4
??
Finding holes in clarity
Refining your user
stories
Always keeping the
customer in the loop
5
Working with
your team
Clear, Customer-Focused User Stories
Choos e seating
Bo okwill
A user
a sh
beutable
tle to
Boerok
aillshbe
choos e aisle or windo
utab
A
tle
us
wwseatin
g. le to
Tit
le:
tion: A Bo
bo okDeascshriput
ok
a sh
ut
usify
tle
er wi
tle
ll
sp
be
ec
in
g
th
De
eabdaletato
sc
bo
rip
ok
tio
an d time aofshth
Aspus
utn:
tle
er
ec
ll be
ifywi
ing
e
fli
leta
th
gh
to
eabda
t.
ok ae sh ut
anbo
d tim
Title:
Title:
Description:
DescTit
riple:
tion:
of thtle
ec ify ing th e data
e flispgh
an d time of th e fli t.
gh t.
6
Play planning poker
you are here 4
Download at WoweBook.Com
61
sum your estimates to find out your total project duration
W ho a
m I?
Solutio
ns
A bunch of techniques for working with requirements, in full
costume, are playing a party game, “Who am I?” They’ll give you
a clue and then you try to guess who they are based on what
they say. Assume they always tell the truth about themselves. Fill
in the blanks next to each statement with the name (or names)
of each attendee that the statement is true for. Attendees may be
used in more than one answer
Tonight’s attendees:
Blueskying – Role playing – Observation
User story – Estimate – Planning poker
You can dress me up as a use case for a
formal occasion.
The more of me there are, the clearer
things become.
I help you capture EVERYTHING.
I help you get more from the customer.
User Story
User Story
Blueskying, Observation
Role playing, Observation
Observation
In court, I’d be admissible as firsthand
evidence.
Estimate
Some people say I’m arrogant, but really I’m
just about confidence.
Blueskying
Everyone’s involved when it comes to me.
Did you say planning
poker? Customers aren’t
involved in that activity.
62
Chapter 2
Download at WoweBook.Com
gathering requirements
Finally, you’re ready to estimate the whole project...
... ‫شروع بأكمله‬F‫ أنت جاهز لتقدير ا‬، ‫أخيرا‬
ً
You’ve got short, focused user stories, and you’ve played planning
.‫ ولعبت لعبة البوكر التخطيطية في كل قصة‬، ‫لديك قصص مستخدم\ قصيرة ومركزة‬
poker on each story. You’ve dealt with all the assumptions that you and ‫ وا•ن‬، ‫فتراضات التي كنت تقوم بها أنت وفريقك في تقديراتك‬g‫لقد تعاملت مع جميع ا‬
your team were making in your estimates, and now you have a set of
‫ لقد حان الوقت للعودة إلى العميل‬.‫لديك مجموعة من التقديرات التي تؤمنون بها جمي ًعا‬
estimates that you all believe in. It’s time to get back to the customer
... ‫شروع‬F‫بإجمالي تقدير ا‬
with your total project estimate...
timate
You’ve got an yesnow.
for each stor
.‫تقديرا لكل قصة مستخدم للمدة التي تعتقد أنها ستستغرق لتطوير هذه الوظيفة‬
‫أضف‬
ً
Add an estimate to each user story for how long you think it
will take to develop that functionality.
‫اجمع جميع التقديرات للحصول على تقدير إجمالي للمدة التي سيستغرقها مشروعك لتقديم‬
up all the estimates to get a total estimate for how .‫طلوبة‬F‫البرامج ا‬
Add
long your project will take to deliver the required software.
Now you can get a
total estimate.
And the total project estimate is...
Add up the each of the converged estimates for your
user stories, and you will find the total duration for your
project, if you were to develop everything the customer
wants.
15
16
20
19
12
15
2
7
‫ أضف كل التقديرات‬... ‫والتقدير ا‘جمالي للمشروع هو‬
‫دة‬F‫ وستجد ا‬، ‫ستخدم الخاصة بك‬F‫تقاربة لقصص ا‬F‫ا‬
‫ إذا كنت ستقوم بتطوير كل ما يريده‬، ‫شروعك‬F ‫ا‘جمالية‬
.‫العميل‬
Sum of user story estimates
=
489 days!
you are here 4
Download at WoweBook.Com
63
when your project is too long
489 days for the project?
That’s almost two years!!!
No kidding! That’s way too long,
By the time you’ve developed the
software, my competition will
have beaten us into the ground!
What do you do when your estimates
are WAY too long?
You’ve finally got an estimate you believe in, and
that takes into account all the requirements that the
customer wants. But you’ve ended up with a monster
project that is just going to take too long.
Is it time to go back to the drawing board? Do you
admit defeat and hand the work over to someone
else? Or do you just ask the customer how long he
thinks would work, forgetting about all your hard
work to come up with you estimates in the first place?
You’ll have to solve a crossword puzzle and work
your way to Chapter 3 to find out how to get Orion’s
Orbits back on track.
64
‫أخيرا على‬
‫ماذا تفعل عندما تكون تقديراتك طويلة ج ًدا؟ لقد حصلت‬
ً
.‫تطلبات التي يريدها العميل‬F‫عتبار جميع ا‬g‫ ويأخذ في ا‬، ‫تقدير تؤمن به‬
.ً4‫لكن انتهى بك ا[مر بمشروع وحش سيستغرق وقت ًا طوي‬
‫هل حان الوقت للعودة إلى لوحة الرسم؟ هل تعترف بالهزيمة وتسليم‬
‫دة التي يعتقد أنها‬F‫العمل لشخص آخر؟ أو هل تسأل العميل فقط عن ا‬
‫قام‬F‫ متناسيا ً كل عملك الشاق للتوصل إلى تقديراتك في ا‬، ‫ستنجح‬
‫ا[ول؟‬
‫تقاطعة والعمل في طريقك إلى الفصل‬F‫سيتع\ عليك حل لغز الكلمات ا‬
.‫سار الصحيح‬F‫ إلى ا‬Orion ‫كتشاف كيفية إعادة مدارات‬g 3
Chapter 2
Download at WoweBook.Com
gathering requirements
Requirements
and Estimation Cross
Untitled Puzzle
Header
Let’s put what you’ve learned to use and stretch out your left brain
a bit. Info 1
Header
Info 2
All of the words below are somewhere in this chapter: Good luck!
etc...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Across
Down
2. When you and the customer are really letting your ideas run
wild you are ..... .....
3. When coming up with estimates, you are trying to get rid of as
many ......... as possible.
4. None of this language is allowed in a user story.
7. If a requirement is the what, an estimate is the .... ....
9. Requirements are oriented towards the .........
12. The best way to get honest estimates and highlight
assumptions.
14. A User Story is made up of a ......... and a description.
15. ......... is a great way of getting first hand evidence of exactly
how your customer works at the moment.
18. The goal of estimation is .........
1. When you just have no idea how to estimate a user story, use
a card with this on it.
5. User stories are written from the perspective of the .........
6. When you and the customer act out a particular user story,
you are .... ....
8. When everyone agrees on an estimate, it is called a .........
10. An estimate is good when eveyone on your team is
feeling .........
11. The maximum number of days that a good estimate should
be for one user story.
13. A great user story is about ......... lines long.
16. After a round of planning poker, you plot all of the estimates
on a .........
17. You can use the ......... rule for breaking up large user
stories.
you are here 4
Download at WoweBook.Com
65
your software development toolbox
Tools for your Software Development Toolbox
CHAPTER 2
Software Development is all about developing and
delivering the software that the customer actually
wants. In this chapter, you learned about several
techniques to help you get inside the customer’s head
and capture the requirements that represent what they
really want... For a complete list of tools in the book,
see Appendix ii.
‫ربع أدوات تطوير البرمجيات الخاص بك‬F ‫أدوات‬
‫تطوير البرمجيات هو كل شيء عن تطوير وتقديم‬
‫البرامج التي يستخدمها العميل في الواقع‬
‫ تعرفت على العديد من‬، ‫ في هذا الفصل‬.‫يريد‬
‫ساعدتك في الوصول إلى رأس العميل‬F ‫ا[ساليب‬
... ‫تطلبات التي تمثل ما يريده ح ًقا‬F‫والتعرف على ا‬
، ‫للحصول على قائمة كاملة با[دوات في الكتاب‬
.‫لحق الثاني‬F‫راجع ا‬
‫تقنيات التنمية‬
Bluesky ، ‫راقبة‬F‫ستخدم الخاصة با‬F‫وقصص ا‬
‫ولعب ا[دوار‬
Development Techniques
Bluesky, Observation and Roleplay
• .‫ عميلك يفكر بشكل كبير عند تلبية متطلباته‬Blueskying ‫يجعل‬
ً
• .‫ واح ًدا مع البرنامج من منظور العميل‬4‫تفاع‬
‫ستخدم‬F‫تلتقط قصة ا‬
• .‫ث جمل تقريبًا‬4‫ بطول ث‬، ‫ستخدم قصيرة‬F‫يجب أن تكون قصص ا‬
• .‫ستخدم القصيرة هي قصة مستخدم يمكن تقديرها‬F‫قصة ا‬
• .‫ يو ًما‬15 ‫مطورا واح ًدا أكثر من‬
‫ستخدم‬F‫ يستغرق تسليم قصة ا‬g‫يجب أ‬
ً
• ‫قم بتطوير متطلباتك بشكل متكرر مع عميلك ‘بقائها في الحلقة في كل خطوة من العملية‬
User Stories
Blueskying gets your
customer to think big
when coming up with their
requirements.
Planning poker for estimation
Development Principles
The customer knows w
but sometimes you needhat they want,
to help them
nail it down
Keep requirements cust
omer-oriented
Develop and refine your
iteratively with the cu requirements
stomer
‫مبادئ التنمية‬
‫شكلة‬F‫ ولكن في بعض ا[حيان تحتاج إلى مساعدته في حل ا‬، ‫يعرف العميل ما يريده‬
‫ء‬4‫تطلبات موجهة للعم‬F‫اجعل ا‬
‫قم بتطوير وتحس\ متطلباتك بشكل متكرر مع العميل‬
66
Chapter 2
Download at WoweBook.Com
A user story captures
one interaction with the
software from the customer’s
perspective.
User stories should be
short, around three
sentences in length.
A short user story is an
estimatable user story.
A user story should not take
one developer more than 15
days to deliver.
Iteratively develop your
requirements with your
customer to keep them in
the loop at every step of the
process.
3 project planning
Planning for success
Really darling, my software
development is so well planned I’ll
be home on time every day for us
to watch NASCAR together!
‫يبدأ كل برنامج رائع بخطة رائعة‬.
‫ ستتعلم‬.‫ستتعلم في هذا الفصل كيفية إنشاء تلك الخطة‬
.‫كيفية العمل مع العمالء لتحديد أولويات متطلباتهم‬
‫ستحدد التكرارات التي يمكنك أنت وفريقك العمل‬
‫ ستنشئ خطة تطوير قابلة‬، ‫أخيرا‬
.‫عليها بعد ذلك‬
ً
.‫للتحقيق يمكنك أنت وفريقك تنفيذها ومراقبتها بثقة‬
‫ ستعرف بالضبط‬، ‫بحلول الوقت الذي تنتهي فيه‬
‫كيفية االنتقال من المتطلبات إلى أول منتج لك‬.
Every great piece of software starts with a great plan.
In this chapter you’re going to learn how to create that plan. You’re going to learn how to
work with the customer to prioritize their requirements. You’ll define iterations that you
and your team can then work toward. Finally you’ll create an achievable development
plan that you and your team can confidently execute and monitor. By the time you’re
done, you’ll know exactly how to get from requirements to your first deliverable.
this is a new chapter
69
deliver what you can, when it’s needed
Customers want their software NOW!
Customers want their software when they need it, and not a moment later. You’ve
come to grips with the customer’s ideas using brainstorming, you’ve got a set of user
stories that describe everything the customer might need the software to do, and
you’ve even added an estimate to each user story that helped you figure out how long
it will take to deliver everything the customer wants. The problem is, developing
everything the customer said they needed will take too long...
‫!العمالء يريدون برامجهم اآلن‬
‫ لقد توصلت إلى فهم أفكار العميل باستخدام‬.‫ وليس بعد لحظة‬، ‫يريد العمالء برامجهم عندما يحتاجون إليها‬
‫ ولديك مجموعة من قصص المستخدمين التي تصف كل شيء قد يحتاج العميل إلى البرنامج‬، ‫العصف الذهني‬
‫تقديرا لكل قصة مستخدم ساعدتك في تحديد حدد الوقت الذي سيستغرقه تقديم كل ما يريده‬
‫ وقد أضفت‬، ‫للقيام به‬
ً
ً‫ تكمن المشكلة في أن تطوير كل شيء قال العميل إنه بحاجة إليه سيستغرق وقتًا طويال‬.‫ العميل‬...
Our Estimate
What the customer wants
489 days
90 days!
The total after summing up all the
estimates for your user stories
‫اإلجمالي بعد تلخيص جميع التقديرات‬
‫لقصص المستخدم الخاصة بك‬
Well you obviously can’t do everything
that the customer wants in 90 days. Why
not just cut back and prioritize?
‫ من الواضح أنه ال يمكنك فعل‬، ‫حسنًا‬
.‫ يو ًما‬90 ‫كل ما يريده العميل خالل‬
‫لماذا ال تقلل فقط وترتيب األولويات؟‬
70
Chapter 3
project planning
Orion’s Orbits still wants to modernize their booking system; they just can’t wait almost
two years for the software to get finished. Take the following snippets from the Orion’s
Orbits user stories, along with their estimates, and circle the ones you think you should
develop to come up with a chunk of work that will take no longer than 90 days.
‫ال تزال مدارات ريون ترغب في تحديث نظام الحجز الخاص بها ؛ ال يمكنهم‬
‫ خذ المقتطفات التالية‬.‫االنتظار لمدة عامين تقريبًا حتى يتم االنتهاء من البرنامج‬
‫ من قصص مستخدمي‬Orion's Orbits ‫ وضع‬، ‫ جنبًا إلى جنب مع تقديراتهم‬،
‫دائرة حول تلك التي تعتقد أنه يجب عليك تطويرها للتوصل إلى جزء كبير من‬
‫ يو ًما‬90 ‫العمل لن يستغرق أكثر من‬.
Total Estimate:
Problems?
Assumptions?
you are here 
71
priorities come from your customer
‫ال تزال مدارات ريون ترغب في تحديث نظام الحجز الخاص بها ؛ ال يمكنهم االنتظار لمدة عام ونصف‬
‫ واالحتفاظ بالمقتطفات التي تعتقد أنه‬71 ‫ كانت مهمتك هي أخذ المقتطفات في الصفحة‬.‫حتى يظهر البرنامج‬
‫ هذه هي القصص التي احتفظنا بها‬.‫يجب عليك تطويرها‬:
Orion’s Orbits still wants to modernize their booking system; they just can’t wait for a year and
a half for the software to turn up. Your job was to take the snippets on page 71 and keep the
ones you think you should develop. Here are the stories we kept:
These are the
user stories
we picked.
Title:
ial offers
Our Total Estimate:
84
But that’s not what I
wanted at all!
‫يحدد العميل األولويات يبدو أن الرئيس التنفيذي‬
‫ لشركة‬Orbit's Orbits ‫ وهل‬، ‫ليس سعيد ًا‬
‫يمكنك إلقاء اللوم عليه؟ بعد كل هذا العمل الشاق‬
‫ لدينا‬، ‫لمعرفة ما يحتاجه‬
‫تجاهله تما ًما عند تحديد قصص المستخدمين‬
‫التي تحظى باألولوية في المشروع‬.
، ‫عندما يتم إعطاء األولوية لقصص المستخدم‬
ً
‫ فقط العميل‬.‫مركزا على العميل‬
‫يجب أن تظل‬
‫ لذلك عندما يتعلق‬.‫يعرف ما هو مطلوب حقًا‬
‫ قد‬، ‫األمر بتحديد ما هو داخل وما هو خارج‬
‫قادرا على تقديم بعض المساعدة من‬
ً ‫تكون‬
‫اختيارا‬
‫هذا‬
‫يكون‬
‫النهاية‬
‫في‬
‫ولكن‬
، ‫الخبراء‬
ً
‫يتعين على العميل اتخاذه‬.
72
Chapter 3
The customer sets the priorities
Seems like the CEO of Orion’s Orbits is not
happy, and can you blame him? After all that
hard work to figure out what he needs, we’ve
ignored him completely when deciding which
user stories take priority for the project.
When user stories are being prioritized, you
need to stay customer-focused. Only the
customer knows what is really needed. So when
it comes to deciding what’s in and what’s
out, you might be able to provide some expert
help, but ultimately it’s a choice that the
customer has to make.
project planning
Prioritize with the customer
It’s your customer’s call as to what user stories take priority. To help the
customer make that decision, shuffle and lay out all your user story cards on
the table. Ask your customer to order the user stories by priority (the story
most important to them first) and then to select the set of features that need
to be delivered in Milestone 1.0 of their software.
Order Flight DVD
A
Description:
of
a
DVD
order
been on.
Review Flight
A user will be able to
leave a review for a shuttle flight
they have been on.
Title:
Title:
Est:
‫إعطاء األولوية مع العميل‬
.‫إنها دعوة عميلك فيما يتعلق باألولوية لقصص المستخدمين‬
‫ قم بتبديل ورسم جميع‬، ‫لمساعدة العميل في اتخاذ هذا القرار‬
‫ اطلب من‬.‫بطاقات قصة المستخدم الخاصة بك على الطاولة‬
‫عميلك ترتيب قصص المستخدمين حسب األولوية (القصة‬
‫األكثر أهمية بالنسبة لهم أوالً) ثم تحديد مجموعة الميزات‬
‫ التي يجب تسليمها في‬Milestone 1.0 ‫من برامجهم‬.
Title:
Description:
12 days
Est:
Choose seating
will be able to
dow seating.
13 days
Pay
Us
pay for their b
card or PayPal.
uttle
will be able
ecifying the
e flight.
Title:
Description:
"Milestone 1.0" Y‫ما هو‬
15 days
13 days
Est:
‫ على عكس‬.‫ هو أول إصدار رئيسي من البرنامج للعميل‬Milestone
‫ من‬1.0 ‫يعد اإلصدار‬
‫ ستكون هذه هي‬، ‫التكرارات األصغر حيث ستعرض للعميل برنامجك للحصول على تعليقات‬
.)‫المرة األولى التي تقدم فيها برنامجك بالفعل (وتتوقع الحصول على أموال مقابل التوصيل‬
Milestone 1.0:‫بعض اإلجراءات والنواهي عند التخطيط لتطبيق‬
Est:
Est:
15 days
What is “Milestone 1.0”Y
Milestone 1.0 is your first major release of the software to the customer. Unlike
smaller iterations where you’ll show the customer your software for feedback, this
will be the first time you actually deliver your software (and expect to get paid for
the delivery). Some Do’s and Don’ts when planning Milestone 1.0:
Do... balance functionality with customer impatience
Don’t...
‫ بموازنة الوظائف مع نفاد صبر العميل‬... ‫قم‬
‫ساعد العميل على فهم ما يمكن عمله في ذلك الوقت‬
‫ ال يتم تجاهل أي قصص مستخدمين ال تصل‬.‫متوفر‬
‫ بل يتم تأجيلها حتى‬، Milestone 1.0‫إلى‬
...3 ‫ أو‬، Milestone 2
Help the customer to understand what can be done in the time
‫ ننشغل بتخطيط األشياء اللطيفة‬... ‫ال‬
available. Any user stories that don’t make it into Milestone 1.0 are not
Milestone ‫ من‬1.0 ‫يتمحور اإلصدار‬
ignored, just postponed until Milestone 2, or 3...
‫ وهذا يعني‬، ‫حول تقديم ما هو مطلوب‬
‫مجموعة‬
get caught planning nice-to-haves
‫من الوظائف التي تلبي أهم احتياجات‬
Milestone 1.0 is about delivering what’s needed, and that means a set
.‫العميل‬
of functionality that meets the most important needs of the customer.
Don’t... worry about length (yet)
)‫ال تقلق بشأن الطول (حتى اآلن‬
‫ أنت تسأل عميلك فقط‬، ‫في هذه المرحلة‬
‫ ال تنشغل‬.‫عن أهم قصص المستخدمين‬
‫بالوقت الذي سيستغرقه تطوير قصص‬
‫ أنت تحاول فقط فهم‬.‫المستخدمين هذه‬
.‫أولويات العميل‬
At this point you’re just asking your customer which are the most important
user stories. Don’t get caught up on how long those user stories will
take to develop. You’re just trying to understand the customer’s priorities.
you are here 
73
building Milestone 1.0
We know what’s in Milestone 1.0
(well, maybe)
From all of the user stories developed from the customer’s ideas, organized into prority
order, the customer then selects the user stories that they would like to be a part of
Milestone 1.0 of the software...
Book a shuttle
Title:
Est:
Description:
15 days
Est:
Description:
13 days
Est:
Description:
14 days
Est:
Take pet reservation
Title:
Description:
Description:
12 days
Est:
15 days
14 days
Pay with Space Miles
Title:
Est:
13 days
Description:
Est:
Order in-flight meals
Est:
View Space Miles Account
Description:
Est:
Take pet reservation
Description:
Est:
12 days
Review flight
Title:
Description:
Order flight DVD
Description:
Choose seating
Order in-flight
15 daysmeal
Title:Description:
Est:
Title:
Title:
Book a shuttle
15 days
Description:
Est:
days
Pay with15Visa/MC/PayPal
Description:
Est:
Desc riptio n:
Est:
Est:
Est:
74
15 days
15 days
15 days
Chapter 3
Add together aLL
of the user story
estimates for
MiLestone 1.0
Est:
Take pet reservation
12 days
Now that you know what features the customer wants in Milestone 1.0,
it’s time to find out if you now have a reasonable length of project if you
develop and deliver all of those most important features...
Title:
15 days
Apply for “frequent
astronaut” card
Title:
Description:
12 days
Book Segway in space-port
transport
Description:
Sanity-check your Milestone 1.0 estimate
Title:
Est:
Choose seating
Title:
13 days
Title:
12 days
Title:
Est:
Description:
Est:
Or der Flight DV D
Description:
14 days
Title:
Est:
Description:
13 days
Review flight
Title:
Description:
15 days
Title:
Description:
Title:
Pay with Visa/MC/PayPal
Title:
15 days
Title:
Est:
Apply for “frequent
astronaut” card
Title:
Est:
Est:
Book Segway in space-port
transport
Description:
12 days
Est:
13 days
Title:
Book a shuttle
Title:
Description:
Description:
12 days
Est:
Take pet reservation
Title:
Choose seating
Title:
Description:
Est:
Description:
12 days
Est:
View Space Miles Account
Title:
Or der Flight DV D
Title:
Description:
Review flight
Title:
Description:
15 days
Est:
Order in-flight meals
Title:
Pay with Visa/MC/PayPal
Title:
Description:
، ‫ (حسنًا‬Milestone 1.0 ‫نحن نعلم ما يوجد في‬
)‫ربما‬
‫من بين جميع قصص المستخدمين التي تم‬
‫ والمرتبة حسب‬، ‫تطويرها من أفكار العمالء‬
‫ يختار العميل بعد ذلك قصص‬، ‫ترتيب التناسبية‬
‫المستخدمين التي يرغبون في أن تكون جز ًءا من‬
... ‫ من البرنامج‬Milestone 1.0
14 days
Manage special offers
Title:
Description:
Est:
13 days
Milestone 1.0
‫ الخاص بك‬Milestone 1.0 ‫ تحقق من تقدير‬Sanity
‫اآلن بعد أن عرفت الميزات التي يريدها العميل في‬
‫ فقد حان الوقت لمعرفة ما إذا كان لديك‬، Milestone 1.0
‫اآلن مدة معقولة للمشروع إذا قمت بتطوير وتقديم كل هذه‬
... ‫الميزات األكثر أهمية‬
= 273 days
‫اجمع كل من تقديرات‬
‫قصة المستخدم لـ‬
MiLestone 1.0
‫ فقم بإعادة ترتيب األولويات‬، ‫إذا كانت الميزات غير مناسبة‬
‫ التسليم في‬Orion’s Orbits ‫ وتريد‬، Milestone 1.0 ‫ يوم عمل لـ‬273 ‫لديك‬
‫ عادة ً ما يريد العمالء أكثر مما يمكنك‬.‫ هذا شائع جدًا‬، ‫ ال تقلق‬.‫ يو ًما‬90 ‫غضون‬
‫ ومن وظيفتك أن تعود إليهم وتعيد ترتيب األولويات حتى تتوصل إلى‬، ‫تقديمه‬
‫ إلعادة ترتيب أولويات قصص المستخدم الخاصة بك‬.‫مجموعة ميزات قابلة للتطبيق‬
... ‫ مع العميل‬Milestone 1.0 ‫لـ‬
You’ve got 273 days of work for Milestone 1.0, and Orion’s Orbits want delivery in 90 days.
Don’t worry, this is pretty common. Customers usually want more than you can deliver, and it’s
your job to go back to them and reprioritize until you come up with a workable feature set.
‫قطع المزيد من الوظائف‬
‫الوقت‬
‫لتقصير‬
‫به‬
‫أول شيء يمكنك القيام‬
To reprioritize your user stories for Milestone 1.0 with the customer...
‫ هو قطع بعض‬Milestone 1.0 ‫الالزم لتقديم‬
‫الوظائف عن طريق إزالة قصص‬
1
Cut out more FUNCTIONALITY
‫المستخدمين التي ليست بالغة األهمية لعمل‬
The very first thing you can look at doing to shorten the time to delivering Milestone 1.0 is to cut out
.‫البرنامج‬
some functionality by removing user stories that are not absolutely crucial to the software working.
If the features don’t fit, reprioritize
2
Ship a milestone build as early as possible
Aim to deliver a significant milestone build of your software as early as possible. This keeps your
development momentum up by allowing you and your team to focus on a deadline that’s not too far off.
‫شحن بناء معلم في أقرب وقت ممكن‬
‫ يحافظ هذا على زخم التطوير لديك من خالل السماح‬.‫تهدف إلى تقديم بناء هام من برنامجك في أقرب وقت ممكن‬
.‫لك ولفريقك بالتركيز على موعد نهائي ليس بعيد المنال‬
3
Focus on the BASELINE functionality
Milestone 1.0 is all about delivering just the functionality that is needed for a
working version of the software. Any features beyond that can be scheduled for later
milestones.
Q:
A:
What’s the difference between a
milestone and a version?
Not much. In fact you could call your
first milestone “Version 1” if you like. The
big difference between a milestone and a
version is that a milestone marks a point at
which you deliver signficant software and get
paid by your customer, whereas a version
is more of a simple descriptive term that is
used to identify a particular release of your
software.
The difference is really quite subtle, but the
simple way to understand it is that “Version”
is a label and doesn’t mean anything more,
whereas “Milestone” means you deliver
signficant functionality and you get paid. It
could be that Version 1.0 coincides with
Milestone 1.0, but equally Milestone 1.0
could be Version 0.1, 0.2 or any other label
you pick.
BASELINE ‫ركز على وظيفة‬
‫ حول تقديم الوظائف‬Milestone ‫ من‬1.0 ‫يتمحور اإلصدار‬
Q:
A:
So what exactly is
my software’sbaseline
functionality?
‫ يمكن جدولة أي ميزات‬.‫المطلوبة فقط إلصدار العمل من البرنامج‬
.‫تتجاوز ذلك للمعالم الالحقة‬
The baseline functionality of your
software is the smallest set of features that
it needs to have in order for it to be at all
useful to your customer and their users.
Think about a word processing application.
Its core functionality is to let you load, edit,
and save text to a file. Anything else is
beyond core functionality, no matter how
useful those features are. Without the ability
to load, edit, and save a document with text
in it, a word processor simply is not useful.
That’s the rule of thumb: If you can get
by without a feature, then it isn’t really
baseline functionality, and it’s probably a
good candidate for pushing out to a later
milestone than Milestone 1.0 if you don’t
have time to get everything done.
Q:
e done the math and no matter how I cut
the user stories up, I just can’t deliver
what my customer wants when they
want me to. What can I do?
A:
It’s time to confess, unfortunately. If
you really can’t build the software that is
required in the time that it’s needed by, and
your customer simply won’t budge when it
comes to removing some user stories from
the mix, then you might need to walk away
from the project and know that at least you
were honest with the customer.
Another option is to try to beef up your team with
new people to try and get more work done
quicker. However, adding new peopleto the team
will up the costs considerably, and won’t
necessarily get you all the advantages that you’d
think it might.
I
’
v
factoring in team performance
Hello?! Can’t we just add some more people to cut down
our estimates? Add two developers, and we’ll get done
in 1/3 the time, right?
‫األمر يتعلق بأكثر من مجرد وقت للتطوير‬
‫بينما يمكن أن تبدو إضافة المزيد من األشخاص‬
‫ إال أنها في الحقيقة ليست‬، ‫جذابة حقًا في البداية‬
‫ خفض‬، ‫بهذه البساطة مثل "مضاعفة األشخاص‬
."‫التقدير إلى النصف‬
‫يحتاج كل عضو جديد في الفريق إلى التعجيل‬
‫بالمشروع ؛ إنهم بحاجة إلى فهم البرامج‬
، ‫والقرارات الفنية وكيف يتالءم كل شيء معًا‬
‫وأثناء قيامهم بذلك ال يمكن أن يكونوا منتجين‬
.٪100 ‫بنسبة‬
‫ثم تحتاج إلى إعداد هذا الشخص الجديد باألدوات‬
‫ قد يعني هذا‬.‫والمعدات المناسبة للعمل مع الفريق‬
، ‫شراء تراخيص جديدة وشراء معدات جديدة‬
‫ولكن حتى لو كان ذلك يعني فقط تنزيل بعض‬
‫ فإن األمر‬، ‫البرامج المجانية أو مفتوحة المصدر‬
‫كله يستغرق وقتًا ويجب أخذ هذا الوقت في‬
.‫االعتبار عند إعادة تقييم تقديراتك‬
‫ كل شخص تضيفه إلى فريقك يجعل مهمة‬، ‫أخيرا‬
ً
‫الحفاظ على تركيز الجميع ومعرفة ما يفعلونه‬
‫ يمكن أن يصبح إبقاء الجميع‬.‫أكثر صعوبة‬
‫يتحركون في نفس االتجاه وفي نفس الصفحة‬
‫ ستجد أن‬، ‫ ومع نمو فريقك‬، ‫وظيفة بدوام كامل‬
‫هذا االتصال المعقد يمكن أن يبدأ في التأثير على‬
‫قدرة فريقك اإلجمالية على أن يكون منت ًجا ويطور‬
.‫برامج رائعة‬
‫ هناك حد أقصى لعدد األشخاص الذين‬، ‫في الواقع‬
‫ لكن‬، ‫يمكن لفريقك احتوائهم وال يزالون منتجين‬
‫ذلك سيعتمد إلى حد كبير على مشروعك وفريقك‬
‫ أفضل طريقة هي‬.‫واألشخاص الذين تضيفهم‬
‫ وإذا بدأت في رؤية أن إنتاجية‬، ‫مراقبة فريقك‬
‫ على الرغم من وجود عدد أكبر من‬، ‫فريقك أقل‬
‫ فقد حان الوقت‬، ‫األشخاص‬
‫إعادة تقييم مقدار العمل الذي يتعين عليك القيام به‬
.‫أو مقدار الوقت الذي يتعين عليك القيام به‬
76
Chapter 3
If it takes you 273 days, with 2 more
people like you, that would reduce the
overall development time by a factor
of 3, right?
It’s about more than just development time
While adding more people can look really attractive at first, it’s really not
as simple as “double the people, halve the estimate.”
Every new team member needs to get up to speed on the project;
they need to understand the software, the technical decisions,
and how everything fits together, and while they’re doing that they
can’t be 100% productive.
Then you need to get that new person set up with the right tools and
equipment to work with the team. This could mean buying new licenses
and purchasing new equipment, but even if it just means downloading
some free or open source software, it all takes time and that time
needs to be factored in as you reassess your estimates.
Finally, every person you add to your team makes the job of keeping
everyone focused and knowing what they are doing harder. Keeping
everyone moving in the same direction and on the same page can
become a full-time job, and as your team gets larger you will find that
this complex communication can start to hit your team’s overall ability to
be productive and develop great software.
In fact, there is a maximum number of people that your team can
contain and still be productive, but it will depend very much on your
project, your team, and who you’re adding. The best approach is to
monitor your team, and if you start to see your team actually get less
productive, even though you have more people, then it’s time to
re-evaluate the amount of work you have to do or the amount of time in
which you have to do it.
‫يعني المزيد من الناس في بعض األحيان تناقص العوائد‬
‫ يو ًما إلكمال‬273 ‫ إذا استغرق شخص واحد‬.‫ال تعمل إضافة المزيد من األشخاص إلى فريقك دائ ًما كما كنت تتوقع‬
‫ ال‬... ‫ في الواقع قد يستغرقون وقتًا أطول بكثير! ألق نظرة‬.91 ‫ أشخاص بالضرورة‬3 ‫ فلن يستغرق‬، Milestone 1.0
:‫يزداد األداء دائ ًما مع زيادة حجم فريقك‬
project planning
More people sometimes means diminishing returns
Adding more people to your team doesn’t always work as you’d expect. If 1 person
takes 273 days to complete Milestone 1.0, then 3 people won’t necessarily take 91. In
fact they could actually take much longer! Take a look...performance doesn’t always
increase with the size of your team:
0
1
2
5
9
15
20+
Q:
Is there a maximum team size that I should
never go over?
A:
Not really. Depending on your experience you
may find that you can happily handle a 20-person team,
but that things become impossible when you hit 21.
Alternatively you might find that any more than three
developers, and you start to see a dip in productivity. The
best approach is to monitor performance closely and
make amendments based on your observations.
Do you think the size of your project affects
this graph? What about if you broke your
project up into smaller sub-projects?
you are here 
77
1.0 ‫اعمل في طريقك نحو إنجاز معقول‬
‫ عن طريق إضافة مطورين‬- ‫ يمكن أن يكون لالنتقال من شخص إلى ثالثة‬، Orbit’s Orbits ‫باستخدام‬
:‫ لذلك دعونا نرى كيف يتم ذلك‬.‫ تأثير إيجابي‬- ‫آخرين‬
building achievable milestones
Work your way to a reasonable Milestone 1.0
... ‫أوال تضيف شخصين جديدين إلى فريقك‬
With Orion’s Orbits, going from one person to three—by adding two
‫ لكنه‬، )‫تساعد إضافة مطورين اثنين إلى فريقك (ثالثة بما فيهم أنت‬
more developers—can have a positive impact. So let’s see how that
‫ يمكن لمطورين اثنين إضافة الكثير من وقت العمل‬.‫ليس حال ً سحريًا‬
works out:
‫ ولكن ال يزال هناك عمل متبقي‬، ‫إلى مشروعك‬
First you add two new people to your team...
Adding two developers to your team (that’s three including you) helps, but it’s not a magical
solution. Two developers can add a lot of work time to your project, but there’s still work left:
Review flight
Title:
Title:
Title:
Description:
Order flight DVD
Description:
Choose seating
Order in-flight
15 daysmeal
Title:Description:
Est:
Book a shuttle
15 days
Pay with Visa/MC/PayPal
Description:
Title:
Title:
Description:
Est:
15 days
15 days
Est:
Description:Est:
15 days
15 days
Est:
Est:
-
= 190 days
273 days of
work to do
= 83 days
of work left
to do!
3 developers
‫ثم تعيد ترتيب أولوياتك مع العميل‬
‫ يوم‬190 ‫ لدينا‬.‫اآلن لديك طريقة جيدة لمعرفة ما يجب إزالته‬
‫ لذلك نحتاج إلى التحدث إلى العميل‬.‫ يوم عمل‬273 ‫عمل و‬
‫ يو ًما من العمل عن طريق نقل بعض‬83 ‫وإزالة حوالي‬
...then you reprioritize with the customer
.Milestone 1.0 ‫قصص المستخدمين من‬
Now you’ve got a nice way to figure out what has to be removed. We’ve got 190 days of work
time, and 273 days of work. So we need to talk to the customer and remove around 83 days
of work by shifting out some user stories from Milestone 1.0.
Review flight
Title:
Title:
Title:
Description:
Order flight DVD
Description:
Choose seating
Order in-flight
15 daysmeal
Title:Description:
Est:
Title:
Title:
Book a shuttle
15 days
Description:
Est:
Description:
Est:
15 days
Pay 15
with
Visa/MC/PayPal
days
Description:Est:
Est:
15 days
Est:
15 days
273 days of
work to do
-
Order flight DVD
Description:
15 days
15 days
Est:
Est:
Customer removed features
Q:
But 184 days of work is less than the 190 days that our
three-developer team can produce, shouldn’t we add some
more features with the customer?
A:
The overall estimate doesn’t actually have to be exactly 190
days. Given that we’re dealing with estimates anyway, which are
rarely 100% accurate, and that we tend to be slightly optimistic in
our estimates, 184 days is close enough to the 190-day mark to be
reasonably confident of delivering in that time.
78
Chapter 3
= 184 days
Review flight
Title:
Description:
Title:
Q:
How did you come up with 190 days when you added
two new developers?
A:
At this point this number is a guesstimate. We’ve guessed
that adding two people to build a team of three will mean we can
do around 190 days of work in 90 calendar days. There are ways
to back up this guess with some evidence using something called
“team velocity,” but we’ll get back to that later on in this chapter.
project planning
BE the Customer
‫كن الزبون‬
‫ تحتاج إلى‬.‫إنها فرصتك اآلن لتكون العميل‬
‫إنشاء خطة للوقت الذي ستقوم فيه بتطوير كل‬
‫ وللقيام‬، Milestone 1.0 ‫قصة مستخدم لـ‬
‫ عليك أن تسأل العميل عن الميزات‬، ‫بذلك‬
.ً‫األكثر أهمية حتى تتمكن من تطويرها أوال‬
‫مهمتك هي لعب دور العميل من خالل تعيين‬
.Milestone 1.0 ‫أولوية لقصص مستخدم‬
‫ قم بتعيين ترتيب لها في‬، ‫لكل قصة مستخدم‬
‫ اعتمادًا على مدى أهمية‬، ‫المربع المقدم‬
.‫استخدام هذه الميزة للمفتاح في أسفل الصفحة‬
Now it’s your chance to be the customer. You need to build
a plan for when you are going to develop each of the user
stories for Milestone 1.0, and to do that you need to ask
the customer what features are most important so that you
can develop those first. Your job is to play the customer
by assigning a priority to the Milestone 1.0 user stories.
For each user story, assign it a ranking in the square
provided, depending on how important you think that
feature is using the key at the bottom of the page.
Login to “Frequent
Astronaut” account
Title:
Order In-flight meals
Title:
Est:
13 days
Est:
15 days
Priority:
Priority:
Title:
Review flight
Manage special
offers
Title:
Est:
13 days
Priority:
Title:
Est:
View “Space Miles”
account
14 days
View flight
reviews
Title:
Est:
12 days
Priority:
Priority:
Priorities Key
10
20
30
40
50
- Most Important
View shuttle deals
Title:
Est:
- Least Important
12 days
Priority:
you are here 
79
your customer decides priority
BE the Customer Solution
Your job was to play the customer and prioritize the
Milestone 1.0 user stories. Here are the priorities
that we assigned to each of the user stories.
We also laid out the user stories in order of
priority...
View shuttle deals
Title:
12 days
Est:
10
Priority:
Book a shutt
View flight reviews
Title:
30
Priority:
Pay with Visa/
Title:
Manage special
offers
Title:
Est:
10
Priority:
Choose seating
Title:
Login to “Frequent
Astronaut” account
Title:
Est:
13 days
Apply for “frequent
Title:
15 days
View “Space Miles”
account
Title:
Est:
14 days
Priority:
Order In-flight
meals
Title:
Est:
13 days
Priority:
80
20
Chapter 3
Why are the priorities 10, 20, 30,
40, and 50?
A:
Powers of ten get the brain thinking
about groupings of features, instead
of ordering each and every feature
separately with numbers like 8 or 26 or
42. You’re trying to get the customer to
decide what is most important, but not
get too hung up on the exact numbers
themselves. Also, powers of ten allow
you to occasionally specify, say, a 25
for a particular feature when you add
something in later, and need to squeeze
it between existing features.
Q:
If it’s a 50, then maybe we can
leave it out, right?
No, 50 doesn’t mean that a user
story is a candidate for leaving out. At
this point, we’re working on the user
stories for Milestone 1.0, and so these
user stories have already been filtered
down to the customer’s most important
features. The goal here is to prioritize,
not figure out if any of these features
aren’t important. So a 50 just says it can
come later, not that it’s not important to
the customer
Q:
What if I have some non–
Milestone 1.0 user story cards?
50
Priority:
Q:
A:
12 days
Est:
‫كن حل العميل‬
‫كانت مهمتك هي لعب العميل وإعطاء األولوية‬
‫ ها هي‬.Milestone 1.0 ‫لقصص مستخدم‬
‫األولويات التي خصصناها لكل قصة من قصص‬
‫ لقد وضعنا أيضًا قصص المستخدم‬.‫المستخدمين‬
... ‫بترتيب األولوية‬
50
Pay using “S
A:
Assign a priority of 60 to those
cards for now, so they don’t get mixed in
with your Milestone 1.0 features.
Q:
And the customer does all this
work?
A:
You can help out and advise,
maybe mentioning dependencies
between some of the user stories. But
the final decision on priorities is always
the customer’s to make.
project planning
Now that you have your user stories for Milestone 1.0 in priority order, it’s time to
build some iterations. Lay out the user stories so they make iterations that make
sense to you. Be sure and write down the total days of work, and how long that
will take for your team of three developers.
‫ فقد‬، ‫ بترتيب األولوية‬Milestone 1.0 ‫اآلن بعد أن أصبح لديك قصص المستخدمين الخاصة بك لـ‬
‫ رتب قصص المستخدم حتى يصنعوا تكرارات منطقية بالنسبة‬.‫حان الوقت إلنشاء بعض التكرارات‬
.‫ تأكد من كتابة أيام العمل اإلجمالية والمدة التي سيستغرقها فريقك المكون من ثالثة مطورين‬.‫لك‬
Iteration 1
View shuttle deals
Title:
Est:
12 days
Priority:
10
Total Days:
Divide by 3 developers:
Iteration 2
Total Days:
Divide by 3 developers:
Total Days:
What do you think you should do at the
end of an iteration? ‫ما الذي تعتقد أنه يجب عليك فعله في‬
‫?نهاية التكرار‬81
Divide by 3 developers:
Answers on page 84.
Iteration 3
milestone = paid, iteration = on track
Tonight’s talk: A sit-down discussion between an iteration
and a milestone.
‫ مناقشة جلوس بين تكرار وحدث‬:‫حديث الليلة‬
‫هام‬.
Milestone: ‫معلما‬
Hello there, iteration, seems like it’s only been a
month since I saw you last.
‫ يبدو أنه قد مر شهر واحد فقط منذ أن‬، ‫ التكرار‬، ‫مرحبًا‬
.‫رأيتك آخر مرة‬
So how are things going on the project? It seems
like you’re always showing up, and I just arrive for
the big finish. Actually, what’s your purpose?
، ‫إذن كيف تسير األمور في المشروع؟ يبدو أنك تحضر دائ ًما‬
‫ ما هو‬، ‫ في الواقع‬.‫وقد وصلت للتو من أجل النهاية الكبيرة‬
‫هدفك؟‬
Naive? Look, just because I’ve had a few customer
run-ins before doesn’t mean I’m not important. I
mean, without me, you wouldn’t have software at all
,let alone get paid! Besides, just because I’ve shown
up and surprised the occasional customer from time
to time...
‫ ال يعني مجرد إجراء بعض جوالت العمالء اإلضافية من قبل‬، ‫ساذج؟ انظر‬
‫ لن يكون لديك برنامج على اإلطالق‬، ‫ بدوني‬، ‫ أعني‬.‫أنني لست مه ًما‬
‫ لمجرد أنني حضرت‬، ‫ ناهيك عن يتقاضون رواتبهم! عالوة على ذلك‬،
... ‫وفاجأت العمالء العرضيين من وقت آلخر‬
I used to try that, too. I’d try and soften the blow by
explaining to the customer that all of their problems
would be fixed in the next version of the software,
but that wasn’t what they wanted to hear. Lots of
yelling, and I’d slink off, ready to go back to work
for a year or so, and see if the customer liked me
better next time.
Iteration: ‫تكرار‬:
Almost exactly a month. And you’ll see me again
next month, I can guarantee it. About three times,
and we’re ready for you, Milestone 1.0.
‫ يمكنني‬، ‫ وستراني مرة أخرى الشهر المقبل‬.‫تقريبا شهر بالضبط‬
، ‫ ونحن جاهزون من أجلك‬، ‫ حوالي ثالث مرات‬.‫أن أضمن ذلك‬
.1.0 ‫مايلستون‬
To make sure things go great, of course. That’s my
job really, to make sure that every step of the way
from day 1 to day 90, the project stays on track.
What, you thought you could just show up three
months into the project and everything would be just
like the customer wants it? A bit naive, aren’t you?
‫ للتأكد من أن‬، ‫ هذا هو عملي حقًا‬.‫ بالطبع‬، ‫للتأكد من أن األمور تسير على ما يرام‬
‫ يظل المشروع على المسار‬، 90 ‫كل خطوة على الطريق من اليوم األول إلى اليوم‬
‫ ماذا تعتقد أنه يمكنك الظهور لمدة ثالثة أشهر فقط في المشروع وكل‬.‫الصحيح‬
‫ أليس كذلك؟‬، ‫شيء سيكون تما ًما كما يريده العميل؟ قليال ساذج‬
Oh, I really sympathize with you there. I hate it
when the customer isn’t happy with me. But then
again, there’s a lot more time to fix things. I mean,
we get together, you know, me and the customer, at
least once a month. And, if things are bad, I just let
the customer know it’ll be better next time.
.‫ أكره عندما ال يكون العميل سعيدًا معي‬.‫ أنا حقا أتعاطف معك هناك‬، ‫أوه‬
‫ نحن‬، ‫ أعني‬.‫ هناك الكثير من الوقت إلصالح األمور‬، ‫ولكن مرة أخرى‬
‫ وإذا‬.‫ مرة واحدة في الشهر على األقل‬، ‫ أنا والعميل‬، ‫ كما تعلم‬، ‫نجتمع‬
‫ فأنا فقط أخبر العميل أنه سيكون أفضل في المرة‬، ‫كانت األمور سيئة‬
.‫القادمة‬
But you’re shorter than a year now, right?
‫‪Chapter 3‬‬
‫‪82‬‬
‫اعتدت أن أجرب ذلك أيضًا‪ .‬سأحاول تخفيف الضربة‬
‫من خالل التوضيح للعميل أنه سيتم إصالح جميع‬
‫مشاكلهم في اإلصدار التالي من البرنامج ‪ ،‬ولكن هذا لم‬
‫يكن ما يريدون سماعه‪ .‬الكثير من الصراخ ‪ ،‬وكنت‬
‫أنسل بعيدًا ‪ ،‬مستعد ًا للعودة إلى العمل لمدة عام أو نحو‬
‫ذلك ‪ ،‬ومعرفة ما إذا كان العميل يحبني بشكل أفضل‬
‫في المرة القادمة‪.‬‬
‫لكنك أقصر من عام اآلن ‪ ،‬أليس كذلك؟‬
‫‪:‬تكرار ‪Iteration:‬‬
‫نعم ‪ ،‬ال أحد ينسى عني‪ .‬في كل شهر تقريبًا ‪ ،‬أحضر ‪ ،‬وأقوم‬
‫بأداء أغنية وأرقص ‪ ،‬إلرضاء العميل‪ .‬حقًا ‪ ،‬ال أستطيع أن‬
‫أتخيل كيف مررت بدوني‪.‬‬
‫‪Yeah, nobody forgets about me. Around every‬‬
‫‪month, there I am, showing up, putting on a song‬‬
‫‪and dance, pleasing the customer. Really, I can’t‬‬
‫‪imagine how you ever got by without me.‬‬
‫أوه ‪ ،‬إنه أكثر من ذلك بقليل ‪ ،‬أال تعتقد ذلك؟ أين ستكون بدون أن أمهد الطريق ‪،‬‬
‫والتأكد من أننا نسير على الطريق الصحيح ‪ ،‬ونتعامل مع التغييرات والميزات‬
‫الجديدة ‪ ،‬وحتى إزالة الميزات الحالية التي لم تعد بحاجة إليها بعد اآلن‪.‬‬
‫?‪Oh, it’s a little more than that, don’t you think‬‬
‫‪Where would you be without me paving the way,‬‬
‫‪making sure we’re on track, handling changes and‬‬
‫‪new features, and even removing existing features‬‬
‫‪that aren’t needed any more.‬‬
‫نأمل العمل؟ ?‪...hopefully working‬‬
‫حسنًا ‪ ،‬لقد حصلت على الجزء الصغير بشكل صحيح‪ .‬لماذا ال تتوقف عن‬
‫العمل لمدة ‪ 30‬يو ًما أخرى أو نحو ذلك ‪ ،‬سنتصل بك عندما ينتهي العمل‪ .‬ثم‬
‫سنرى من هم بيرة الجمعة ‪ ،‬حسنًا؟‬
‫‪Well, you got the little part right. Why don’t you just‬‬
‫‪shuffle off for another 30 days or so, we’ll call you‬‬
‫‪when all the work’s done. Then we’ll see who Friday‬‬
‫?‪beers are on, OK‬‬
‫بالتأكيد ‪ ،‬وبما أنني أقوم بعملي ‪ ،‬فأنا متأكد من أنك ستعمل بشكل جيد‪ .‬أنا خارج هنا ‪،‬‬
‫الكثير من العمل المتبقي إلنجازه ‪...‬‬
‫‪Sure thing, and since I do my job, I’m sure you’ll work‬‬
‫‪just fine. I’m outta here, plenty of work left tobe done..‬‬
‫‪:‬معلما ‪Milestone:‬‬
‫‪Well, I try to be, but sometimes that’s just how long‬‬
‫‪it takes, although I just love seeing the customer‬‬
‫‪more often. At least once a quarter seems to line up‬‬
‫‪with their billing cycles. And not so long that I get‬‬
‫‪forgotten about; there’s nothing worse than that.‬‬
‫حسنًا ‪ ،‬أحاول أن أكون كذلك ‪ ،‬لكن في بعض األحيان يكون هذا هو‬
‫الوقت الذي يستغرقه األمر ‪ ،‬على الرغم من أنني أحب رؤية العميل‬
‫كثيرا‪ .‬يبدو أن ربعًا على األقل يتوافق مع دورات الفواتير الخاصة بهم‪.‬‬
‫ً‬
‫ولم يمض وقت طويل حتى أنساه ؛ ال يوجد شيء أسوأ من ذلك‪.‬‬
‫‪Are you kidding? You’re not even an alpha or a‬‬
‫‪beta. .. just some code glued together, probably an‬‬
‫‪excuse for everyone to wear jeans to work and drink‬‬
‫‪beer on Friday afternoon.‬‬
‫إصدارا تجريبيًا أو ألفا‪ .‬فقط‬
‫أنت تمزح؟ أنت لست حتى‬
‫ً‬
‫بعض التعليمات البرمجية التي تم لصقها معًا ‪ ،‬ربما يكون‬
‫ملف عذرا للجميع الرتداء الجينز للعمل وشرب الجعة بعد‬
‫ظهر يوم الجمعة‪.‬‬
‫‪Ha! Where would I be? Same place I am right now,‬‬
‫‪getting ready to show the customer some real...‬‬
‫ها! حيث أن أكون؟ في نفس المكان الذي أتواجد فيه اآلن ‪ ،‬أستعد ألظهر للعميل‬
‫بعضًا حقيقيًا ‪...software. Hey, wait. Hopefully? I’ve got a few...‬‬
‫‪hopes for you, you little...‬‬
‫البرمجيات‪ .‬مهال انتظر‪ .‬أمالً؟ لدي بعض اآلمال بالنسبة لك ‪ ،‬يا‬
‫صغيرتي ‪...‬‬
‫قليال فاسق جاحد !‪Ungrateful little punk. release this‬‬
‫!الجميل‪ .‬االفراج عن هذا‬
‫كانت مهمتك هي وضع‬
‫حتى‬
‫قصص المستخدمين‬
continuously
buildable and runnable
.‫يصنعوا تكرارات منطقية‬
‫ الحظ‬... ‫إليك ما توصلنا إليه‬
Your job was to lay out the user stories so they make iterations that make
‫أن جميع التكرارات الخاصة‬
sense. Here’s what we came up with... note that all our iterations are within one
‫بنا تتم في غضون شهر‬
calendar month, about 20 working days (or less).
20 ‫ حوالي‬، ‫تقويمي واحد‬
.)‫يوم عمل (أو أقل‬
Manage special
offers
Title:
Est:
13 days
Priority:
Est:
10
Total Days:
Order In-flight
meals
Title:
13 days
Est:
Priority:
Title:
Est:
55
Total Days:
Est:
15 days
50
Iteration 3
12 days
Priority:
50
Est:
19
View flight reviews
Title:
Title:
10
Divide by 3 developers:
20
Login to “Frequent
Astronaut” account
Priority:
30
Divide by 3 developers:
17
View “Space Miles ”
account
days
Total14Days:
50
Priority:
‫ماذا تعتقد أنك يجب أن تفعل في نهاية‬
‫التكرار؟‬
What do you think you should do at the
end of an iteration?
Show the customer and
‫احتفظ ببرنامجك بشكل مستمر وتشغيل برامجك دائ ًما حتى‬
Q:‫تتمكن‬.‫التكرار‬
‫دائ ًما من الحصول على تعليقات من العميل في نهاية‬
What if I get to the end of an iteration, and I don’t have
anything to show my customer?
A:
12 days
Priority:
Iteration 1
Iteration 2
View Shuttle
deals
Title:
Actually, the answer here
is 18.333, but the general
rule is to round up your
estimates to make sure you
haven’t chopped off time
that you are going to need.
The only way you should end up at the end of an iteration and
not have something to show the customer is if no user stories were
completed during the iteration. If you’ve managed to do this, then your
project is out of control and you need to get things back on track as
quickly as possible.
Divide by 3 developers: 20
58
‫أظهر للعميل واحصل على مالحظاتهم‬
get their feedback
Keep your software continuousLy
buiLding and your software
aLways runnabLe so you can
aLways get feedback from the
customer at the end of an
iteration.
project planning
Iterations should be short and sweet
So far Orion’s Orbits has focussed on 30-day iterations, with 3
iterations in a 90-day project. You can use different size iterations,
but make sure you keep these basic principles in mind:
‫يجب أن تكون التكرارات قصيرة وحلوة‬
30 ‫ حتى اآلن على عمليات التكرار لمدة‬Orbit's Orbits ‫ركزت‬
‫ يمكنك استخدام‬.‫ يو ًما‬90 ‫ تكرارات في مشروع مدته‬3 ‫ مع‬، ‫يو ًما‬
‫ ولكن تأكد من مراعاة هذه المبادئ‬، ‫تكرارات مختلفة الحجم‬
:‫األساسية‬
‫اجعل التكرارات قصيرة‬
Keep iterations short
The shorter your iterations are, the more chances you get to
find and deal with change and unexpected details as they
arise. A short iteration will get you feedback earlier and bring
changes and extra details to the surface sooner, so you can
adjust your plans, and even change what you’re doing in the
next iteration, before you release a faulty Milestone 1.0.
‫ زادت فرصك في العثور على‬، ‫كلما كانت التكرارات أقصر‬
.‫التغييرات والتفاصيل غير المتوقعة والتعامل معها عند ظهورها‬
‫مبكرا وإدخال‬
‫سيؤدي التكرار القصير إلى الحصول على تعليقاتك‬
ً
‫ حتى‬، ‫التغييرات والتفاصيل اإلضافية إلى السطح في وقت أقرب‬
‫ وحتى تغيير ما تفعله في التكرار التالي‬، ‫تتمكن من تعديل خططك‬
.‫ الخاطئ‬Milestone 1.0 ‫ قبل إصدار‬،
Keep iterations baLanced
Each iteration should be a balance between dealing with change,
adding new features, beating out bugs, and accounting for real
people working. If you have iterations every month, that’s not
really 30 days of work time. People take weekends off (at least
once in a while), and you have to account for vacation, bugs,
and things that come up along the way. A 20-work-day iteration
is a safe bet of work time you can handle in an actual 30-day,
calendar-month iteration.
‫حافظ على التكرارات متوازنة‬
، ‫يجب أن يكون كل تكرار متوازنًا بين التعامل مع التغيير‬
‫ ومحاسبة‬، ‫ والتغلب على األخطاء‬، ‫وإضافة ميزات جديدة‬
‫ إذا كان لديك تكرارات كل‬.‫األشخاص الحقيقيين الذين يعملون‬
‫ يأخذ الناس‬.‫ يو ًما من وقت العمل‬30 ‫ فهذا ليس في الواقع‬، ‫شهر‬
‫ وعليك‬، )‫عطلة نهاية األسبوع (مرة واحدة على األقل كل فترة‬
، ‫ والبق‬، ‫حساب اإلجازة‬
20 ‫ يعد التكرار لمدة‬.‫واألشياء التي تظهر على طول الطريق‬
‫يوم عمل رهانًا آمنًا لوقت العمل الذي يمكنك التعامل معه في‬
.‫ يو ًما في التقويم‬30 ‫تكرار فعلي لمدة‬
‫تساعد التكرارات القصيرة على إقصاء التغيير وتبقيك أنت وفريقك متحفزين‬
.‫ومركزين‬
SHORT iterations heLp you
deaL with change and keep
you and your team motivated
and focused.
bringing reality to your plan
Below is a particular aspect of a user story, iteration, milestone...or
perhaps two, or even all three! Your job is to check off the boxes for
the different things that each aspect applies to.
User story
Iteration
fiilestone
I result in a buildable and runnable bit
of software.
I’m the smallest buildable piece of
software.
In a full year, you should deliver me a
maximum of four times.
I contain an estimate set by your team.
I contain a priority set by the customer.
When I’m done, you deliver software to
the customer and get paid.
I should be done and dusted in 30 days.
Answers on page 88.
86
Chapter 3
project planning
Comparing your plan to reality ‫مقارنة خطتك بالواقع‬
It looks like we’ll be doing fine on the plan as
long as we can all fit in a full five-day week.
Bob: Oh, just so you know, Nick is coming in at 11 today,
he’s got a doctor’s appointment...
Laura: What?
Bob: And while we’re talking, the IT guys are installing
Oracle 9 on my machine this afternoon, so you might
want to keep that in mind, too.
Laura: Oh great, any other nasty surprises in there that I
should be aware of ?
Bob: Well, I have got a week of vacation this month, and
then there’s Labor Day to take into account...
Laura: Perfect, how can we come up with a plan that
factors all these overheads in so that when we go get
signoff from the CEO of Orion’s Orbits we know we
have a plan we can deliver?
See if you can help Bob out. Check all the things that you need to
account for when planning your iterations.
Paperwork
Equipment failure
Holidays
Sickness
Software upgrades
Frank winning the lottery
you are here 
87
velocity applies your real performance
Below is a particular aspect of a user story, iteration, milestone...or
perhaps two, or even all three! Your job is to check off the boxes for
the different things that each aspect applies to.
User Story
Iteration
fiilestone
I result in a buildable and runnable bit
of software.
I’m the smallest buildable piece of
software.
In a full year, you should deliver me a
maximum of four times.
I contain an estimate set by your team.
I contain a priority set by the customer.
When I’m done, you deliver software to
the customer and get paid.
I should be done and dusted in 30 days.
See if you can help Bob out. Check all the things that you need to
account for when planning your iterations.
88
Chapter 3
Paperwork
Equipment failure
Holidays
Sickness
Software upgrades
Frank winning the lottery
project planning
Velocity accounts for overhead in your estimates
It’s time to add a little reality to your plan. You need to factor in all those annoying
bits of overhead by looking at how fast you and your team actually develop software.
And that’s where velocity comes in. Velocity is a percentage: given X number of
days, how much of that time is productive work?
.0.7 ‫ابدأ بسرعة‬
‫ من العدل أن‬، ‫في التكرار األول مع فريق جديد‬
٪70 ‫نفترض أن وقت عمل فريقك سيكون حوالي‬
‫ هذا يعني أن سرعة فريقك تساوي‬.‫وقتهم المتاح‬
‫ أيام من وقت‬10 ‫ مقابل كل‬، ‫ بمعنى آخر‬.0.7
‫ أيام تقريبًا في أيام العطالت‬3 ‫ سيتم قضاء‬، ‫العمل‬
‫ والمكالمات‬، ‫ واألعمال الورقية‬، ‫ وتثبيت البرامج‬،
.‫ ومهام أخرى غير متعلقة بالتطوير‬، ‫الهاتفية‬
، ‫ وقد تجد أنه بمرور الوقت‬، ‫هذا تقدير متحفظ‬
‫ إذا كان هذا هو‬.‫تكون السرعة الفعلية لفريقك أعلى‬
‫ ستقوم بضبط‬، ‫ ففي نهاية التكرار الحالي‬، ‫الحال‬
‫سرعتك واستخدام هذا الرقم الجديد لتحديد عدد أيام‬
.‫العمل التي يمكن أن تنتقل إلى التكرار التالي‬
‫أفضل ما في األمر هو أنه يمكنك تطبيق السرعة‬
‫ والحصول على تقدير واقعي‬، ‫على مقدار عملك‬
.‫للمدة التي سيستغرقها هذا العمل بالفعل‬
‫السرعة تحسب النفقات العامة في تقديراتك‬
.‫حان الوقت إلضافة القليل من الواقع إلى خطتك‬
‫تحتاج إلى التعامل مع كل تلك األجزاء المزعجة‬
‫من النفقات العامة من خالل النظر في مدى سرعة‬
‫ وهنا‬.‫قيامك أنت وفريقك بالفعل بتطوير البرامج‬
:‫ السرعة هي نسبة مئوية‬.‫يأتي دور السرعة‬
‫ ما مقدار الوقت الذي‬، ‫ عدد األيام‬X ‫بالنظر إلى‬
‫يكون فيه العمل المنتج؟‬
But how can I know how fast
my team performs? We’ve only
just gotten started!
Start with a velocity of 0.7.
On the first iteration with a new team it’s fair to assume
that your team’s working time will be about 70% of
their available time. This means your team has a velocity
value of 0.7. In other words, for every 10 days of work
time, about 3 of those days will be taken up by holidays,
software installation, paperwork, phone calls, and other
nondevelopment tasks.
That’s a conservative estimate, and you may find that over
time, your team’s actual velocity is higher. If that’s the case,
then, at the end of your current iteration, you’ll adjust
your velocity and use that new figure to determine how
many days of work can go into the next iteration.
Best of all, though, you can apply velocity to your amount
of work, and get a realistic estimate of how long that
work will actually take.
‫أيام سرعة العمل‬
days of work = days required to
get work done
velocity
‫= األيام المطلوبة‬
‫إلنجاز العمل‬
you are here 
89
from ideal to real estimates
Programmers think in UTOPIAN days...
Ask a programmer how long it takes to get something done, like writing a PHP
interface to a MySQL database, or maybe screen-scraping World Series scores from
espn.com. They’re going to give you a better-than-best-case estimate.
Here’s what a programmer SAYS... ‫هذا ما يقوله المبرمج‬
... UTOPIAN ‫يفكر المبرمجون في أيام‬
‫اسأل أحد المبرمجين عن المدة التي يستغرقها إلنجاز‬
‫ في قاعدة بيانات‬PHP ‫ مثل كتابة واجهة‬، ‫شيء ما‬
World Series ‫ أو ربما حذف نتائج‬، MySQL
‫تقديرا أفضل من‬
‫ سوف يعطونك‬.espn.com ‫من‬
ً
.‫أفضل الحاالت‬
...
Sure, no problem, I can crank
through that in two days.
...but here’s what he’s really THINKING
‫ولكن هذا ما يفكر فيه حقًا‬
I’ll grab a Monster on the way home, program till 3
A.M., take a Halo break, then work through the morning.
Sleep a few hours, get the guys over to hack with me,
and finish at midnight. As long as nothing goes wrong...
and Mom doesn’t need me to pick up dinner.
90
Chapter 3
project planning
... ‫يعتقد الفيلوبرز في أيام العالم الحقيقي‬
‫ عليك أن تتعامل مع‬، ‫لكي تكون مطور برامج‬
، ‫ ربما يكون لديك فريق من المبرمجين‬.‫الواقع‬
‫ عالوة على‬.‫ولديك عميل لن يدفع لك إذا تأخرت‬
‫ قد يكون لديك أشخاص آخرون يعتمدون‬، ‫ذلك‬
ً ‫ لذا فإن تقديراتك أكثر تحف‬- ‫عليك‬
‫ وتأخذ في‬، ‫ظا‬
:‫االعتبار الحياة الواقعية‬
Developers think in REAL-WORLD days...
To be a software developer, though, you have to deal with reality. You’ve probably
got a team of programmers, and you’ve got a customer who won’t pay you if you’re
late. On top of that, you may even have other people depending on you—so your
estimates are more conservative, and take into account real life:
1 calendar month
You start with a month, but
takeaway weekends and holidays.
20 workable days
velocity
14 days of REAL work
Order in-flight meal
Title:
Title:
Title:
Description:
Book a shuttle
Description:
Pay with Visa/MC/PayPal
Desc ription:
Est:
15 days
15 days
15 days
Est:
Est:
Take your original estimates for each iteration from the solution on
page 84 and apply a 70% velocity so that you can come up with a
more confident estimate for all the work in Milestone 1.0.
Iteration 1
55 days of work / 0.7 =
Review flight
Title:
Description:
Title:
Order flight DVD
Title:
Description:
Choose seating
Order in-flight
15 daysmeal
Title:Description:
Est:
Review flight
Title:
Title:
Description:
Order flight DVD
Description:
Title:
Choose seating
15 days
15 days
Est:
15 days
Des cription:
Est:
Est:
Review flight
Title:
Title:
Description:
Order flight DVD
Description:
Title:
Choose seating
15 days
15 days
Est:
15 days
Des cription:
Est:
Est:
Iteration 2
50 days of work / 0.7 =
Iteration 3
58 days of work / 0.7 =
Book a shuttle
15 days
Description:
Title:
Est:
Title:
days
Pay with15
Visa/MC/PayPal
Description:
Est:
Desc ription:
Est:
15 days
15 days
15 days
Est:
Est:
Milestone 1.0 =
you are here 
91
Y ‫متى يكون التكرار طويالً جدًا‬
confidence comes at a price
When is your iteration too longY
‫ هذا يعني أنه‬.0.7 ‫افترض أن لديك ثالثة مطورين في فريقك يعملون بسرعة‬
‫ تحتاج إلى تطبيق سرعتك على‬، ‫لحساب المدة التي سيستغرقها التكرار حقًا لفريقك‬
:‫تقدير التكرار‬
Suppose you have three developers on your team who are working at a velocity of 0.7. This
means that to calculate how long an iteration will really take your team, you need
to apply your velocity to the iteration’s estimate:
Order in-flight meal
Title:
Title:
Title:
Book a shuttle
Description:
Pay with Visa/MC/PayPal
Desc ription:
Est:
15 days
15 days
days
15
Est:
Est:
Review flight
Title:
Title:
Description:
Order flight DVD
Description:
Title:
Choose seating
15 days
15 days
Est:
15 days
Description:
Est:
Est:
Review flight
Title:
Title:
Titl e:
Description:
Order flight DVD
Description:
C hoose seating
15 days
15 days
15 days
Description:
Est:
Est:
Est:
Iteration 1
Description:
55 days / 0.7 =
Iteration 2
50 days / 0.7 =
79 days
72 days
Iteration 3
58 days / 0.7 =
83 days
= 234 days of work
So if you have 3 developers, each of them has to work 78
days in 3 months... but there are only 60 working days.
3 ‫ يو ًما في‬78 ‫ يجب على كل منهم العمل‬، ‫ مطورين‬3 ‫لذلك إذا كان لديك‬
.‫ يوم عمل فقط‬60 ‫ ولكن هناك‬... ‫أشهر‬
How would you bring your estimates
back to 20 work-day cycles so you
can deliver Milestone 1.0 on time,
without working weekends?
99
Deal with velocity BEFORE you break into iterations
‫تعامل مع السرعة قبل اقتحام التكرارات‬
‫كان من الممكن بالفعل تجنب الكثير من هذا‬
‫األلم إذا كنت قد طبقت السرعة في بداية‬
، ‫ من خالل تطبيق السرعة مقد ًما‬.‫مشروعك‬
‫يمكنك حساب عدد أيام العمل التي يمكنك أنت‬
‫ بعد ذلك‬.‫وفريقك إنتاجها في كل تكرار‬
‫ستعرف بالضبط ما يمكنك تحقيقه حقًا في‬
First, apply your team velocity to each iteration
.Milestone 1.0
By taking the number of people in your team, multiplied by the number of actual working
days in your iteration, multiplied finally by your team’s velocity, you can calculate how ‫ قم بتطبيق سرعة فريقك على كل تكرار‬، ً‫أوال‬
many days of actual work your team can produce in one iteration:
‫ مضروبًا في‬، ‫بأخذ عدد األشخاص في فريقك‬
A lot of this pain could actually have been avoided if you’d applied velocity at the
beginning of your project. By applying velocity up front, you can calculate how many
days of work you and your team can produce in each iteration. Then you’ll know exactly
what you can really deliver in Milestone 1.0.
3 x 20 x 0.7 = 42
‫ مضروبًا‬، ‫عدد أيام العمل الفعلية في التكرار‬
‫ يمكنك حساب عدد أيام‬، ‫أخيرا في سرعة فريقك‬
ً
‫العمل الفعلي التي يمكن لفريقك إنتاجها في تكرار‬
:‫واحد‬
20 working days in
your iteration
Add your iterations up to get a total milestone estimate
Now you should estimate the number of iterations you need for your milestone. Just
multiply your days of work per iteration by the numbe r of iterations, and you’ ve got the
number of working days you can devote to user stories for your milestone:
42 x 3
=
Q:
That sucks! So I only have 14 days of actual productive
work per iteration if my velocity is 0.7?
A:
0.7 is a conservative estimate for when you have new members
of your team coming up to speed and other overheads. As you and
your team complete your iterations, you’ll keep coming back to that
velocity value and updating it to reflect how productive you really are.
126
Q:
‫أضف التكرارات للحصول على تقدير‬
‫إجمالي للحدث‬
‫اآلن يجب عليك تقدير عدد التكرارات‬
‫ ما عليك‬.‫التي تحتاجها لمعلمك الرئيسي‬
‫سوى مضاعفة أيام عملك لكل تكرار في‬
‫عدد أيام العمل التي يمكنك تخصيصها‬
‫لقصص المستخدمين من أجل إنجازك‬
:‫الرئيسي‬
With velocity, my Milestone 1.0 is now going to take 79
working days, which means 114 calendar days. That’s much
more than the 90-day/3-month deadline that Orion’s Orbits set,
isn’t that too long?
A:
Yes! Orion’s Orbits need Milestone 1.0 in 90 calendar days, so
by applying velocity, you’ve now got too much work to do to meet that
deadline. You need to reassess your plan to see what you really can
do with the time and team that you have.
you are here 
93
iterations with velocity
When your iterations contain too much work for your team, there’s nothing else to
do but reshuffle work until your iterations are manageable. Take the Orion’s Orbits
Milestone 1.0 user stories and organize them into iterations that each contain no
more than 42 days of work.
View shuttle
deals
Title:
Est:
12 days
Priority:
Est:
10
Est:
Order In-flight
meals
10
Est:
Est:
20
Login to “Frequent
Astronaut” account
Title:
15 days
Priority:
12 days
Priority:
View “Space Miles ”
account
Title:
Est:
50
View flight reviews
Title:
13 days
Priority:
Chapter 3
13 days
Priority:
Title:
94
Manage special
offers
Title:
14 days
Priority:
50
30
project planning
Iteration 1
Total Days of work:
Iteration 2
Total Days of work:
Iteration 3
Total Days of work:
User stories that won’t fit
you are here 
95
reality means being honest
Your job was to to take the Orion’s Orbits user stories and aim for
iterations that contain no more than 42 days of work each.
View shuttle
deals
Title:
12 days
Est:
10
Priority:
Iteration 1
Manage special
offers
Title:
Est:
Est:
10
Iteration 3
15 days
Priority:
50
Total Days of work:
39
View “Space Miles”
account
Title:
Est:
38
30
Priority:
Est:
Total Days of work:
12 days
Est:
Login to “Frequent
Astronaut” account
14 days
Priority:
50
User stories that won’t fit
96
Chapter 3
20
View flight reviews
Title:
Title:
13 days
Priority:
Iteration 2
42
Order In-flight
meals
Title:
13 days
Priority:
Total Days of work:
‫حان الوقت إلجراء تقييم‬
Time to make an evaluation
‫إذن ماذا بقي؟ من المحتمل أن يكون لديك الكثير من قصص‬
... Milestone 1.0 ‫المستخدمين التي ال تزال تتناسب مع‬
‫ هذا ألننا لم نحسب سرعتنا قبل التخطيط‬.‫وربما القليل منها ال‬
.‫للتكرار‬
project planning
So what’s left? You’ve probably got a lot of user stories that still fit
into Milestone 1.0...and maybe a few that don’t. That’s because we
didn’t figure out our velocity before our iteration planning.
Title:
Title:
Est:
View Shuttle
Take
shutSpecif
MC/PayPa
tle l y window o r
deals Title:
Est: booki
aisle
seat
pecial
ng
s
15
Manage
days
14 days Title: View
flight reviews
Est:
15
Est:
days
offers
15
offersand
days
Priority:
Title:
Est:
Est:
20
Priority:
15Est:
days 13 days
Priority:
12 days
Est:
14 days
Priority:
Login to “Frequent
View “Space Miles”
Title:
Title:
10 10
15 days
Choos e seatingInAppl
1220
Space
days
10 y for
Miles Loyalty
Priority:
10 Priority:
Priority:
Est:
Priority:
Title:Priority: Title:
Est:
Priority:
40
Milestone .Next
Milestone 1.0
Deliver the bad news to the customer
It’s the time that every software developer dreads. You’ve
planned out your iterations, factored in the velocity of your
team, but you still can’t get everything your customer wants
done in time for their deadline. There’s nothing else to do
but come clean...
‫توصيل األخبار السيئة للعميل‬
‫ لقد‬.‫إنه الوقت الذي يخاف فيه كل مطور برامج‬
‫ ولكن‬، ‫ مع مراعاة سرعة فريقك‬، ‫خططت لتكراراتك‬
‫ال يزال يتعذر عليك الحصول على كل ما يريده‬
‫ ال يوجد‬.‫عميلك في الوقت المناسب للموعد النهائي‬
... ‫شيء آخر لتفعله سوى النظرة‬
That sucks! So you can do
everything except the online
“Space Miles” features.
Hmm...Let me think about it...
you are here 
Download at WoweBook.Com
97
breaking realistic but bad news
‫إدارة العمالء الغاضبين‬
Managing pissed off customers
Customers usually aren’t happy when you tell them you can’t get everything done
in the time they want. Be honest, though; you want to come up with a plan for
Milestone 1.0 that you can achieve, not a plan that just says what the customer
wants it to say.
‫ال يشعر العمالء بالرضا عادة عندما تخبرهم أنه ال‬
‫ كن‬.‫يمكنك إنجاز كل شيء في الوقت الذي يريدونه‬
Milestone ‫ مع ذلك ؛ تريد وضع خطة لـ‬، ‫صري ًحا‬
‫ وليست خطة تقول فقط ما يريده‬، ‫ يمكنك تحقيقها‬1.0
.‫العميل أن يقوله‬
So what do you do when this happens?
It’s almost inevitable that you’re not going to be able to do everything, so it helps to be
prepared with some options when you have to tell the customer the bad news...
1
‫تكرارا إلى‬
‫) أضف‬1
ً
Milestone 1.0
‫اشرح أنه يمكن القيام‬
‫بالعمل اإلضافي إذا تمت‬
‫إضافة تكرار إضافي إلى‬
‫ هذا يعني جدول‬.‫الخطة‬
‫ لكن‬، ‫تطوير أطول‬
‫العميل سيحصل على ما‬
Milestone ‫يريد في‬
.1.0
2
‫إذن ماذا تفعل عندما يحدث هذا؟‬
‫قادرا على فعل‬
‫تكون‬
‫يكاد يكون من الحتمي أنك لن‬
ً
‫ لذلك من المفيد أن تكون مستعدًا ببعض‬، ‫كل شيء‬
‫الخيارات عندما يتعين عليك إخبار العميل باألخبار‬
Add an iteration to Milestone 1.0
... ‫السيئة‬
Explain that the extra work can be done if an additional iteration is added to the plan. That
means a longer development schedule, but the custo
y want in Milestone 1.0.
me r will get what the
42 x 3
‫)تحلى بالشفافية فيما يتعلق بالطريقة التي‬3
‫توصلت بها إلى األرقام الخاصة بك قد يبدو األمر‬
‫ ولكن عميلك لديه كلمتك فقط بأنه ال يمكنك‬، ‫غريبًا‬
‫تقديم كل ما يريده خالل الموعد النهائي الذي حدده‬
‫ لذلك من المفيد أحيانًا توضيح المكان الذي‬، ‫لك‬
‫ أظهر لهم الحسابات التي‬، ‫ إذا استطعت‬.‫أتيت منه‬
.‫تدعم سرعتك وكيف يتناسب ذلك مع احتياجاتهم‬
، ‫وأخبر عميلك أنك تريد تقديم برامج ناجحة له‬
‫ولهذا السبب كان عليك التضحية ببعض الميزات‬
.‫لمنح نفسك خطة تثق في قدرتك على تنفيذها‬
Title:
Est:
Title:
126
View Shuttle
MC/PayPa
Take
shuttle
l window or
Specify
deals Title:
Est: booking
s15pecial
Manage
days aisle seat
14 days
View
flight reviews
Est:
Title:
15Est:days15 days
andPriority:
offers
Title:
15 days 10 10
10
Priority:
Est:
Priority:
e seatingInChoos
Title:
Priority:
Apply
Title:
Est: for Space
Priority:
Est:
10
1220
days
Miles Loyalty
Priority:
12 days
Est:
14 days
Priority:
3
=
‫)اشرح أن العمل‬2
‫ بل تم‬، ‫الفائض لم يضيع‬
‫تأجيله‬
‫أحيانًا يكون من المفيد‬
‫اإلشارة إلى أن قصص‬
‫المستخدم التي ال يمكنها‬
‫الوصول إلى‬
‫ ال‬Milestone 1.0
‫تضيع ؛ يتم وضعهم فقط‬
Explain that the overflow work is not lost, just postponed
‫على الموقد الخلفي حتى‬
Sometimes it helps to point out that the user stories that can’t make it into Milestone 1.0 are not
.‫المرحلة التالية‬
lost; they are just put on the back burner until the next milestone.
20
Priority:
Login to “Frequent Miles”
Title: View “Space
Title:
Est:
15Est:
days 13 days
Priority:
Priority:
40
Milestone 1.0
Milestone .Next
Be transparent about how you came up with your figures
It sounds strange, but your customer only has your word that you can’t deliver everything
they want within the deadline they’ve given you, so it sometimes helps to explain where you’re
coming from. If you can, show them the calculations that back up your velocity and how this
equates to their needs. And tell your customer you want to deliver them successful software,
and that’s why you’ve had to sacrifice some features to give yourself a plan that you are
confident that you can deliver on.
Q:
Q:
If I’m close on my estimates, can I fudge a little and
squeeze something in?
0.7 seems to add up to a LOT of lost time. What sorts of
activities could take up that sort of time?
A:
A:
We REALLY wouldn’t recommend this. Remember, your
estimates are only educated guesses at this point, and they are
actually more likely to take slightly longer than originally thought than
shorter.
It’s a much better idea to leave some breathing room around your
estimates to really be confident that you’ve planned a successful set
of iterations.
Q:
I have a few days left over in my Milestone 1.0. Can’t I add
in a user story that breaks my day limit just a little bit?
A:
0.7 is a safe first guess at a team’s velocity. One example is
where you are installing a new piece of software, like an IDE or a
database (naming no specific manufacturers here, of course). In
cases like these two hours of interrupted work can actually mean
FOUR hours of lost time when you factor in how long it can take a
developer to get back in “the zone” and developing productively.
It’s also worth bearing in mind that velocity is recalculated at the
end of every iteration. So even if 0.7 seems low for your team right
now, you’ll be able to correct as soon as you have some hard data.
In Chapter 9 we’ll be refining your velocity based on your team’s
performance during Iteration 1.
Again, probably not a good idea. If your stories add up to leave
you one or two days at the end of the iteration, that’s OK. (In Chapter
9 we’ll talk about what you can do to round those out.)
Q:
OK, without squeezing my last user story in I end up
coming under my work-day limit by a LONG way. I have 15 days
free at the end of Milestone 1.0! Is there anything I can do about
that?
A:
To fit a story into that space, try and come up with two simpler
stories and fit one of those into Milestone 1.0 instead.
‫ يجب‬.‫كن واثقًا من قدرتك على إنجاز العمل الذي اشتركت فيه‬
.‫عليك أن تعد وتكفِر بدالً من المبالغة في الوعود واإلحباط‬
Alright, it’s worth it to me to
lose space miles in Milestone
1.0 to keep things moving.
Let’s do it.
Stay confident that you can achieve
the work you sign up for. You shouLd
promise and deLiver rather than
overpromise and faiL.
you are here 
99
introducing the big board
The Big Board on your wall
‫اللوحة الكبيرة على الحائط الخاص بك‬
‫ فقد حان الوقت إلعداد لوحة تحكم تطوير البرامج‬، ‫بمجرد أن تعرف بالضبط ما تقوم ببنائه‬
‫ لوحة القيادة هي في الواقع مجرد لوحة كبيرة على جدار مكتبك يمكنك‬.‫ من التطوير‬1 ‫للتكرار‬
.‫استخدامها لمراقبة العمل قيد التنفيذ وما يجري وما تم إنجازه‬
Once you know exactly what you’re building, it’s time to set up your software development
dashboard for Iteration 1 of development. Your dashboard is actually just a big board on the wall
of your office that you can use to keep tabs on what work is in the pipeline, what’s in progress,
and what’s done.
User stories
View shuttle
deals
Title:
Est:
12 days
Priority:
100
Chapter 3
10
project planning
Burn Down
44
Work
left
0
20
15
10
Days left
5
0
Next
Completed
you are here 
101
happiness is a project that can be achieved
You may have noticed a graph at the top right of your development dashboard, but what is it
for? Take a few minutes to glance over the burn-down graph below and write on it what you
think the different parts of the graph are for and how it is one of the key tools for monitoring
your software development progress and ensuring that you deliver on time.
‫ربما الحظت رس ًما بيانيًا في الجزء العلوي األيمن من لوحة‬
‫ ولكن ما الغرض منه؟ خذ بضع دقائق‬، ‫معلومات التطوير‬
‫إللقاء نظرة على الرسم البياني المحترق أدناه واكتب عليه ما‬
‫تعتقد أنه من أجله األجزاء المختلفة من الرسم البياني وكيف أنه‬
‫أحد األدوات الرئيسية لمراقبة تقدم تطوير البرامج لديك والتأكد‬
. ‫من أنك تقدمه في الوقت المحدد‬
Burn Down
44
Work
left
0
15
20
10
5
0
Days left
Answers on page 104.
What do you think would be measured on
this graph, and how?
، ‫ما الذي تعتقد أنه سيقاس في هذا الرسم البياني‬
‫وكيف؟‬
102
Chapter 3
‫كيف تدمر حياة فريقك‬
‫ "يمكن لفريقي‬، ‫ والبدء في التفكير‬، ‫ وتقليل دورات التكرار‬، ‫ والتقديرات المتزايدة‬، ‫من السهل إلقاء نظرة على تلك الجداول الطويلة‬
.‫ فأنت على األرجح تجهز نفسك لبعض المشاكل في المستقبل‬، ‫العمل ألسابيع أطول!" إذا كنت قد جعلت فريقك يوافق على ذلك‬
project planning
How to ruin your team’s lives
It’s easy to look at those long schedules, growing estimates, and
diminishing iteration cycles, and start to think, “My team can
work longer weeks!” If you got your team to agree to that, then
you’re probably setting yourself up for some trouble down the line.
‫كن واثقًا في خططك من خالل تطبيق السرعة‬
‫وعدم إرهاقك وفريقك‬
PersonaL Lives matter
Long hours are eventually going to affect your personal
life and the personal lives of the developers on your team.
That might seem trite, but a happier team is a more
productive team.
‫حياة األشخاص مهمة‬
‫ستؤثر ساعات العمل الطويلة في النهاية على حياتك الشخصية والحياة الشخصية للمطورين‬
.‫ لكن الفريق األكثر سعادة هو فريق أكثر إنتاجية‬، ً‫ قد يبدو هذا مبتذال‬.‫في فريقك‬
Fatigue affects productivity
Tired developers aren’t productive. Lots of studies suggest
that developers are really only incredibly productive for
about three hours a day. The rest of the day isn’t a loss,
but the more tired your developers are, the less likely
they’ll even get to that three hours of really productive
time.
Be confident
in your pLans
by appLying
veLocity
and not
overworking
yourseLf and
your team.
‫يؤثر التعب على اإلنتاجية‬
‫ تشير الكثير من الدراسات إلى أن المطورين ال ينتجون إال بشكل ال‬.‫المطورون المتعبون ليسوا منتجين‬
‫ قل‬، ‫ ولكن كلما زاد إرهاق مطوريك‬، ‫ ما تبقى من اليوم ليس خسارة‬.‫يصدق لمدة ثالث ساعات في اليوم‬
.‫احتمال وصولهم إلى تلك الساعات الثالث من الوقت المنتج حقًا‬
■
The first step to planning what you are going to develop
is to ask the customer to prioritize their requirements.
■
Milestone 1.0 should be delivered as early as you can.
■
During Milestone 1.0 try to iterate around once a
month to keep your development work on track.
■
When you don’t have enough time to build everything,
ask the customer to reprioritize.
■
■
■
Plan your iterations by factoring in your team’s velocity
from the start.
If you really can’t do what’s needed in the time allowed,
be honest and explain why to the customer.
Once you have an agreed-upon and achievable set of
user stories for Milestone 1.0, it’s time to set up your
development dashboard and get developing!
you are here 
103
performance and burn down
You were asked to take a few minutes to glance over the burn-down graph below and describe
what you think the different parts of the graph are for and how it is one of the key tools for
monitoring your software development progress and ensuring that you deliver on time.
Burn Down
44
Work
left
0
15
، ‫ما الذي تعتقد أنه سيقاس في هذا الرسم البياني‬
20
‫وكيف؟‬
What do you think would
be measured on this
graph, and how?
This graph monitors how quickly you and
your team are completing your work,
measured in days on the vertical axiick
off your work remaining against the
number of days left in your iteration.
104
Chapter
10
5
0
Days left
‫يرصد هذا الرسم البياني مدى سرعة إكمالك أنت وفريقك لعملك‬
‫ ثم يوضح هذا الرسم‬.‫ ويتم قياسه باأليام على المحور الرأسي‬،
‫البياني مدى سرعة وضع عالمة على عملك المتبقي مقابل عدد‬
.‫األيام المتبقية في التكرار‬
We’ll talk a lot more about burndown in the next few chapters.
Don’t worry if you’re still a little fuzzy
on how burn-down rates work, and how
to track it. You’ll start creating a chart of your own in the
next chapter, tracking your project’s progress.
your software development toolbox
CHAPTER 3
Tools for your Software Development Toolbox
Software Development is all about developing
and delivering great software. In this chapter,
you added several new techniques to your
toolbox... For a complete list of tools in the book,
see Appendix ii.
‫أدوات لمربع أدوات تطوير البرمجيات الخاص بك‬
‫تطوير البرمجيات هو كل شيء عن تطوير وتقديم برامج‬
،‫ في هذا الفصل‬.‫رائعة‬
‫لقد أضفت العديد من التقنيات الجديدة إلى صندوق األدوات‬
‫ للحصول على قائمة كاملة باألدوات في‬... ‫الخاص بك‬
.‫ راجع الملحق الثاني‬، ‫الكتاب‬
Milestone ‫■ يعطي عميلك األولوية لما هو موجود وما هو خارج لـ‬
.1.0
‫ يو ًما‬20 ‫ و‬، ‫■ قم بإنشاء تكرارات قصيرة لمدة شهر تقويمي واحد تقريبًا‬
.‫من العمل‬
ً
.‫ يجب أن يكون برنامجك قابال للبناء والتشغيل‬، ‫■ طوال فترة التكرار‬
‫■ تطبيق سرعة فريقك على تقديراتك لمعرفة مقدار العمل الذي يمكنك‬
.‫إدارته بشكل واقعي في التكرار األول‬
‫ الذي‬Milestone 1.0 ‫■ حافظ على سعادة عمالئك من خالل الخروج بـ‬
.‫يمكنك تحقيقه حتى تكون واثقًا من إمكانية التسليم والحصول على األموال‬
‫ سيكونون أكثر سعادة‬، ‫ثم إذا كنت تقديم المزيد‬
■
Your customer prioritizes
what is in and what is out for
Milestone 1.0.
■
Build short iterations of
about 1 calendar month, 20
calendar days of work.
■
Throughout an iteration
your software should be
buildable and runnable.
■
Apply your team’s velocity to
your estimates to figure out
exactly how much work you
can realistically manage in
your first iteration.
■
Keep your customers
happy by coming up with a
Milestone 1.0 that you can
achieve so that you can be
confident of delivering and
getting paid. Then if you
deliver more, they’ll be even
happier.
‫تقنيات التنمية‬
‫* يجب أال يزيد التكرار بشكل مثالي عن شهر‪ .‬هذا يعني أن لديك ‪ 20‬يوم عمل لكل تكرار‪.‬‬
‫* يتيح لك تطبيق السرعة على خطتك الشعور بمزيد من الثقة في قدرتك على الوفاء بوعود‬
‫التطوير الخاصة بك لعمالئك‪.‬‬
‫* استخدام (حرفيا) لوحة كبيرة على الحائط الخاص بك لتخطيط ومراقبة التكرار الحالي‬
‫الخاص بك هو العمل‪.‬‬
‫* احصل على موافقة العميل عند اختيار قصص المستخدم التي يمكن إكمالها لـ‬
‫‪ ، Milestone 1.0‬وعند اختيار التكرار ‪ ،‬سيتم تضمين قصة المستخدم‪.‬‬
‫مبادئ التنمية‬
‫* اجعل التكرارات قصيرة ويمكن التحكم فيها‪.‬‬
‫* في النهاية ‪ ،‬يقرر العميل ما هو موجود وما هو خارج ‪.Milestone 1.0‬‬
‫* الوعد والوفاء‪.‬‬
‫* كن دائما صادقا مع العميل‬
4 user stories and tasks
Getting to the real work
I’m sure that eighth layer of wax is
important, but couldn’t we get going?
We should already be there...
‫ تسجّل قصص المستخدمين ما تحتاج‬.‫حان وقت الذهاب إلى العمل‬
‫ ولكن حان الوقت اآلن للتركيز على العمل الذي يجب‬، ‫إلى تطويره‬
‫القيام به واستنباطه حتى تتمكن من‬
‫ ستتعلم في‬.‫يمكن أن تجعل قصص المستخدمين هذه تنبض بالحياة‬
‫ وكيف‬، ‫هذا الفصل كيفية تقسيم قصص المستخدمين إلى مهام‬
.‫تساعدك تقديرات المهام في تتبع مشروعك من البداية إلى النهاية‬
‫ ونقل المهام من قيد التقدم إلى اكتمالها‬، ‫ستتعلم كيفية تحديث منتداك‬
، ‫ على طول الطريق‬.‫ إلى إكمال قصة مستخدم كاملة في النهاية‬،
‫ستتعامل مع العمل غير المتوقع الذي ال مفر منه والذي سيضيفه‬
.‫عميلك إلى قائمة أولوياتك‬
It’s time to go to work. User stories capture what you need to develop, but now
it’s time to knuckle down and dish out the work that needs to be done so that you
can bring those user stories to life. In this chapter you’ll learn how to break your user
stories into tasks, and how task estimates help you track your project from inception
to completion. You’ll learn how to update your board, moving tasks from in progress to
complete, to finally completing an entire user story. Along the way, you’ll handle and
prioritize the inevitable unexpected work your customer will add to your plate.
this is a new chapter
Download at WoweBook.Com
109
introducing iSwoon
Introducing iSwoon
iSwoon ‫تقديم‬
‫ الذي سيصبح قريبًا أفضل مخطط مواعيد‬، iSwoon ‫مرحبًا بك في‬
‫ المحملة بالفعل‬، ‫على سطح المكتب في العالم! ها هي اللوحة الكبيرة‬
:‫ يوم عمل‬20 ‫بقصص المستخدمين مقسمة إلى تكرار لمدة‬
Welcome to iSwoon, soon to be the world’s finest desktop date
planner! Here’s the big board, already loaded with user stories broken
down into 20-work-day iterations:
Order flowers
k restaurant
r cab
110
Chapter 4
Download at WoweBook.Com
‫ خذ كل‬.‫حان الوقت لجعلك أنت وفريقك من المطورين يعملون‬
‫ وقم بتعيين كل منها لمطور‬1 ‫ للتكرار‬iSwoon ‫قصص مستخدم‬
... ‫عن طريق رسم خط من قصة المستخدم إلى المطور الذي تختاره‬
user stories and tasks
It’s time to get you and your team of developers working. Take each of
the iSwoon user stories for Iteration 1 and assign each to a developer
by drawing a line from the user story to the developer of your choice...
you are here 
Download at WoweBook.Com
111
break up user stories into tasks
‫عملك أكثر دقة من قصص المستخدم‬
.‫الخاصة بك‬
‫كانت قصص المستخدم الخاصة بك للمستخدم‬
‫الخاص بك ؛ لقد ساعدوا في وصف ما تحتاجه‬
‫ ولكن‬.‫البرامج بالضبط من وجهة نظر العميل‬
‫ فربما تحتاج‬، ‫اآلن حان الوقت لبدء الترميز‬
‫ كل‬.‫إلى النظر إلى هذه القصص بشكل مختلف‬
، ‫قصة عبارة عن مجموعة من المهام المحددة‬
‫أجزاء صغيرة من الوظائف التي يمكن أن تتحد‬
.‫لتشكل قصة مستخدم واحد‬
‫تحدد المهمة جز ًءا من عمل التطوير الذي يجب‬
‫أن يقوم به مطور واحد من أجل تكوين جزء‬
‫ كل مهمة لها عنوان لذلك‬.‫من قصة المستخدم‬
‫ ووصف تقريبي‬، ‫يمكنك الرجوع إليها بسهولة‬
‫يحتوي على تفاصيل حول كيفية تطوير هذه‬
‫ كل مهمة لها تقديرها الخاص‬.‫ وتقدير‬، ‫المهمة‬
‫ أفضل طريقة للتوصل إلى هذه‬-‫ خمن ما‬-‫و‬
‫التقديرات هي عن طريق التخطيط للعب البوكر‬
.‫مرة أخرى مع فريقك‬
Wait a second, we can’t just assign user stories to
developers; things aren’t that simple! Some of those
user stories have to happen before others, and what if
I want more than one developer on a single story?
Your work is more granular than your user stories.
Your user stories were for your user; they helped describe exactly what you
software needed to do, from the customer’s perspective. But now that it’s
time to start coding, you’ll probably need to look at these stories differently.
Each story is really a collection of specific tasks, small bits of functionality
that can combine to make up one single user story.
A task specifies a piece of development work that needs to be carried out
by one developer in order to construct part of a user story. Each task has a
title so you can easily refer to it, a rough description that contains details
about how the development of that task should be done, and an estimate.
Each task has its own estimate and—guess what—the best way to come up
with those estimates is by playing planning poker again with your team.
Now it’s your turn. Take the user story of creating a date and break it into tasks
you think you and your team need to execute. Write one task down on each of
the sticky notes, and don’t forget to add an estimate to each task.
112
Answers on page 114.
Chapter 4
Download at WoweBook.Com
‫هل تضيف مهامك؟‬
‫ لكننا اآلن نضيف تقديرات جديدة إلى‬، ‫هل الحظت مشكلة محتملة في تقديراتك؟ لدينا قصة مستخدم بتقدير‬
‫ ماذا يحدث عندما ال تتفق مجموعتا التقديرات؟‬.‫مهامنا‬
user stories and tasks
Do your tasks add upY
Did you notice a possible problem with your estimates? We’ve got a user
story with an estimate, but now we’re adding new estimates to our tasks.
What happens when the two sets of estimates don’t agree?
Task 5
Task SQL scripts
Create
adding,SQLfinding
forCreate
scripts
and
finding
adding, date
forupdating
records
and updating date 3
records
4
‫تضيف تقديرات المهام الثقة إلى تقديرات قصة المستخدم‬
‫لقد أبقتك تقديرات قصة المستخدم الخاصة بك في الملعب الصحيح‬
‫ ولكن المهام تضيف حقًا مستوى آخر من‬، ‫عندما كنت تخطط للتكرار‬
.‫التفاصيل الخاصة بالترميز الفعلي الذي ستفعله لقصة المستخدم‬
‫ غالبًا ما يكون من األفضل فصل المهام من قصص‬، ‫في الواقع‬
‫ بهذه‬.‫ إذا كان لديك الوقت‬، ‫المستخدمين مباشرة ً في بداية عملية التقدير‬
‫ من‬.‫الطريقة ستضيف المزيد من الثقة إلى الخطة التي تمنحها لعميلك‬
‫ تصف المهام العمل‬.‫األفضل دائ ًما االعتماد على تقديرات المهام‬
‫الفعلي لتطوير البرامج الذي يتعين القيام به وهي أقل بكثير من‬
.‫التخمينات من تقدير قصة المستخدم الرديئة‬
Task estimates add confidence to user
story estimates
Your user story estimates kept you in the right ballpark
when you were planning your iterations, but tasks really add
another level of detail specific to the actual coding you’ll do
for a user story.
?
‫قسّم قصص‬
‫المستخدم إلى مهام‬
‫إلضافة الثقة‬
‫لتقديراتك ولوحة‬
.‫التحكم الخاصة بك‬
In fact, it’s often best to break out tasks from your user
stories right at the beginning of the estimation process, if
you have time. This way you’ll add even more confidence
to the plan that you give your customer. It’s always best
to rely on the task estimates. Tasks describe the actual
software development work that needs to be done and are
far less of a guesstimate than a coarse-grained user story
estimate.
Break user
stories into
tasks to add
CONFIDENCE
to your estimates
and your pLan.
you are here 
Download at WoweBook.Com
113
tasks have estimates
You were asked to take the user story of creating a date and break
out the tasks that you think you and your team will need to execute
to develop this user story, not forgetting to add task estimates...
Q:
My tasks add up to a new estimate for my user story, so
were my original user story estimates wrong?
A:
Well, yes and no. Your user story estimate was accurate
enough in the beginning to let you organize your iterations. Now, with
task estimates, you have a set of more accurate data that either
backs up your user story estimates or conflicts with them.
You always want to rely on data that you trust, the estimates that you
feel are most accurate. In this case, those are your task estimates.
Q:
A:
How big should a task estimate be?
Your task estimates should ideally be between 1/2 and 5 days
in length. A shorter task, measured in hours, is too small a task. A
task that is longer than five days spreads across more than one
working week, and that gives the developer working on the task too
much time to lose focus.
114
Q:
A:
What happens when I discover a big missing task?
Sometimes—hopefully not too often—you’ll come across a
task that just breaks your user story estimate completely. You might
have forgotten something important when first coming up with the
user story estimates, and suddenly the devil in the details rears its
ugly head, and you have a more accurate, task-based estimate that
completely blows your user story estimate out of the water.
When this happens you can really only do one thing, and that’s adjust
your iteration. To keep your iteration within 20 working days, you
can postpone that large task (and user story) until the next iteration,
reshuffling the rest of your iterations accordingly.
To avoid these problem, you could break your user stories into tasks
earlier. For instance, you might break up your user stories into tasks
when you initially plan your iterations, always relying on your task
estimates over your original user story estimates as you balance out
your iterations to 20 working days each.
Chapter 4
Download at WoweBook.Com