Года четыре назад, когда мы с коллегами только начали погружаться в мир гибких методологий, наше реальное знакомство на деле с этим миром началось с внедрения модульного тестирования. Один заразился и понеслось – через некоторое время у нас уже был даже свой фреймворк для тестирования хранимых процедур на Oracle и автоматизированный сервер сборок.
Дальше настала очередь требований – очень уж привлекательно выглядели User Stories из книжки, по сравнению с нашими 20-50 страничными описаниями требований, созданные по шаблонам, с какими-то незаполненными разделами и частично утратившие актуальность. Не претендуя на звание настоящей XP команды (а про Scrum мы тогда еще вообще не знали), мы не стали стремиться к использованию маленьких карточек с историями пользователей. Нашей целью было минимизировать затраты на написание и поддержание требований в актуальном состоянии, сделать работу с требованиями удобной и приятной, особенно для разработчиков (инициатива шла оттуда :) ).
Итак, мы с командой обсудили проблемы с существующими требованиями и создали наше общее видение – как бы нам было хорошо и удобно работать.
Создали простейший шаблон в Word на полстраницы с полями: название фичи, имя аналитика, имя человка от заказчика, поле для планируемой трудоемкости и основное поле для описания самой фичи. И стали называть это User Story. Немного позже мы еще добавили одно поле для функционального теста – это существенно повысило ценность каждой истории.
Что представлял собой текст описания истории? Иногда история была оформлена в виде варианта использования, иногда в виде фраз «должно быть это, это и это», иногда еще как-то. Но всегда эти описания были сформулированы бизнес-языком, понятным пользователям; в них не было ни одного предложения технического характера. Конечно, если была такая необходимость, там описывались конкретные алгоритмы, но опять же, только на языке бизнеса.
И истории эти были короткими – на одну страницу. Иногда на две, очень-очень редко на три. Потому что не нужно писать мелкие или очевидные детали – мы предпочитали их выяснять при личном общении, укрепляя отношения в команде. И, конечно же, совсем не нужно пытаться в один документ запихнуть требования ко всей системе – его все равно никто не будет потом читать.
User stories оказались действительно очень эффективным инструментом управления требованиями – из-за их размеров они были приятны для прочтения, легки для изменений; из-за отсутствия технических деталей – проще и понятнее, они давали возможность разработчикам самим думать над реализацией, повышая уровень их ответственности и уменьшая трудоемкость описания аналитикам. И, конечно же, самому заказчику было гораздо удобнее общаться с командой с использованием таких историй.
В одном из блогов нашел Best Practices, с которыми полностью согласен:
- Make them customer-focused. The easiest way to do this is to have the customer write them. If this isn't practical, then you'll have to role-play. An example of a developer-focused story is "Add clustered index to the Orders table." This doesn't mean much to most customers, and a real customer (unless they are a DBA), would probably never write this. Instead, something like "Improve Order reporting performance", captures the same information, but is understandable to everyone on the team.
- Make them elevator-friendly. A good story should be something you could explain on an elevator in 30 seconds or so to a team member. Don't write a novel. Remember, this is just a placeholder for more detailed conversations, not a specification or requirements document.
- Make them the right size. Not too big, and not too small, just like Goldilocks said when she visited a tough bear hangout. For me, the right size is usually under 40 ideal hours (1 ideal week) of estimated effort. Small stories aren't usually a problem, but if they get to be under an hour or so, you probably want to batch them up. Defects are usually good candidates for batching into a single story, as long as they are small and easy to implement.
- Make them testable. An untestable story might be something like "Make the order screen easy to use." It sounds nice, but no one really knows what this means, or how to objectively verify it. A better wording choice might be: "A novice user be able to load, enter information, and submit an order within 5 minutes." Hmmm...still seems a little questionable, but I can probably write a test like "Given a sample group of 10, 8 of these users should be able to complete an order for a book in 5 minutes."
Если вам интересно узнать больше о User Stories, рекомендую отличную книгу Mike Cohn - User Stories Applied: For Agile Software Development.
0 коммент.:
Отправить комментарий